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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
