>I have a similar problem with the generic handling of the modules (Action, Screen and friends). I guess this is what annotations were invented for in the first place. My suggestion would be to do only the things absolutely necessary to get the milestone 1 out of the door and postpone the "real" solution to >milestone 2 where the security stuff is about to be replaced anyway. Rather put your energy into tuning the fulcrum-security stuff. LDAP needs some testing, for example.
The thing is... Like I said in my introduction when i became a Turbine comitter, I run a company where we develop a web-app that is now 2 years old based on turbine. I intend to test Turbine4 through our web-app. If we don't generify turbines security model before the release of M1 I would have to change a lot in our code just to make it compile. I'm not sure that I want to put my time there. I'd rather develop turbine one step further to test it. And as you say, I'd probably focus on fulcrum security. I have no experience of LDAP however and I would probably but all my energy into torque. >> There is also a "trick" that I found in the book Effective Java by >> Joshua Bloch (which I very much recommend btw). >> >> You can create a general method that looks like this: >> >> public <U> UserManager<U> getUserManager(Class<U> type) > I like this one. That's how ArrayList.toArray(T[]) works. Maybe this can help me with the AssemblerBrokerService. If the team feels that this is a good solution I will start working on it as fast as I can. If you still want to release M1 my vote will be [0] and I don't think I will be giving feedback this round. I will on the next though. /Ludwig --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
