If JAMES (and this should apply to pretty much any project) is going to "standardize" on a particular user repository (or any subsystem) then the operative word in my mind is "standard".
In the case of user repositories, the operative standards are LDAP (meaning JNDI in the case of java) and JAAS. I would also want to see the further step of using a standard LDAP schema. I am no expert in this area, but I believe rfc2256 and rfc3377 address this topic.
Naturally, a facade can (and, IMHO, should) be build on top of the underlying JAAS/JNDI code to simplify it for authors of client code.
Any effort toward achieving this should, I believe, have a goal of providing a realistically interoperable single sign-on capability.
ADK
Noel J. Bergman wrote:
Nicola, I agree with your and Stefano's basic premise of code reuse, however I would also point out that there are already Java standard technologies for these sorts of things: JNDI and JAAS.Beyond the consideration that standards exist, and Turbine isn't one of them, there are some technical problems with Turbine. The Turbine User interface appears to be unacceptable in its current incarnation. It is, as is not uncommon for Turbine, tightly tied to the Servlet API and it is based upon a static set of bean properties. Both of these are critical flaws. The James project has already tentatively agreed to use a dynamic attributes model, which fits with X.500 (JNDI/LDAP) and T-space data models. If I were not to expose JNDI directly for some reason, such as perceived learning curve, I'd consider an EzJNDI-lite layer that used other services, such as JNDI itself, underneath. It really would amount to little more than a higher level wrapper with simplified interfaces. Perhaps Quinton McCombs can clarify the picture regarding the apparent technical problems with Turbine that would need to be cleared up: 1) Servlet API inheritance 2) Static, not dynamic, attribute set plus the fact that JNDI and JAAS are the standard technologies implementing those features in Java, and there is no indication how Turbine uses/integrates those standards. Clearing those issues by documentation, refactoring, or new code would be acceptable. If the Turbine folks want to do it, fine. If not, and Avalon wants to do it, fine. If no one else wants to do it, James needs it anyway. Again, I agree with the idea of sharing common code, but it has to be the right common code. --- Noel ref: http://java.sun.com/products/jaas/ http://java.sun.com/products/jndi/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
