geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Proposal for login modules for a GenericSecurityRealm
Date Fri, 29 Apr 2005 12:06:52 GMT
	Are we strongly opposed to one GBean calling for another to be
started?  For example, the realm looks up the login modules, if they're
not available dies, if they're available but not started starts them, and
if they're available and started continues...  I guess this could cause
problems where a number of GBeans are "half started" while waiting for
others to start -- but it would be a third option.  Still, I like #2 the
best.  It could be just a "list" of GBeans rather than a "collection" of 


On Thu, 28 Apr 2005, David Jencks wrote:
> 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