You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/01/14 16:08:20 UTC
Re: [Jam3s][RT] Turbine for User Repository?
Nicola Ken Barozzi wrote:
>
> - crosspost, please keep CCed --
>
> Some thoughts...
>
> Many Apache Java projects have their own user repository and
> authentication-authorization system, and this sucks.
> Turbine has its own services about this.
> Turbine is being Avalonized.
>
> James has it's on system.
> James uses Avalon.
> James could use Turbine services for this.
>
> Cocoon has it's own system.
> Cocoon uses Avalon.
> Cocoon could use Turbine services for this.
>
> XXX has it's own system.
> XXX uses Avalon.
> XXX could use Turbine services for this.
>
> Thoughts?
The day I see this happening I'll be a very happy man.
The concept of converging to one server framework was *exactly* made in
order to allow components to be used across different server applications.
Turbine, James and Cocoon are different beasts, do different things
since they have different goals, but this doesn't mean that pieces can't
be factored out and reused across projects.
I think I can speak for the Cocoon community when I say that if a
Turbine component that does user authentication and authorization gets
avalonized (thus more easily integrated with cocoon), it will something
that will interest us very much.
Personally, I'm willing to help pushing this forward.
Hope this helps.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Noel has taken the words right out of my mouth.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>