geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Genender" <>
Subject Re: Proposal for login modules for a GenericSecurityRealm
Date Thu, 28 Apr 2005 20:52:34 GMT

-1 on option 1...this can get really messy and ugly with many plans and
many login modules.

+1 on number 2.  It would be nice to have support for a model that allows
a dependency on several gbeans to ensure they have started.  I think this
would have been very helpful in a number of areas, and especially would
have been helpful for the tomcat plan.  Therefore this would be good not
just for the Security objects...we could use this functionality in other

> At the moment there is a problem with GenericSecurityRealm.  The
> loginModuleConfiguration attribute takes, effectively, a list of login
> domain gbeans, and GenericSecurityRealm expects them all to be started.
>   There is no way at the moment to constrain them to be started:
> sometimes it works and sometimes it doesn't.
> I can think of 2 approaches to solve this problem.
> (1) (can be implemented now).  Write a LoginModuleHolder gbean that has
> a reference to the login domain gbean and a next LoginModuleHolder,
> thus forming a linked list.  The GenericSecurityRealm gets a reference
> to a LoginModuleHolder, so it won't start until all the login modules
> have started.  Additional attributes such as the
> REQUIRED/OPTIONAL/SUFFICIENT flag can be included in the
> LoginModuleHolder gbean.
> advantages:  can be done now fairly simply.
> disadvantages: creates a lot of gbeans with no function except
> dependency management, will be a real nuisance to set up without some
> kind of builder support.  It might be possible to use an xml-attribute
> on the GenericSecurityRealm to generate the extra gbeans.
> (2) (would require kernel changes)  Add a new reference collection type
> that is something like an ordered list of explicitly named references.
> If the objects in the list could be something with additional
> attributes, perhaps even something described by  a GBeanInfo, that
> would be even better.
> advantages: avoids extra gbeans that don't really do anything.  Elegant
> solution.
> disadvantages: complicates kernel and may be difficult to implement.
> Anyway it requires new functionality.
> There's already a similar situation in the Jetty integration with
> filter holders, which are a linked list of gbeans with little function
> other than to make things happen in a particular order.  So, there are
> at least 2 places that would benefit from (2).
> While we discuss this I plan to implement (1) for the
> GenericSecurityRealm.
> thanks
> david jencks

View raw message