geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [jira] Closed: (GERONIMO-639) GenericSecurityRealm doesn't express its gbean dependencies
Date Sun, 01 May 2005 02:13:01 GMT
I have got the impression from the mail discussions that this is a 
temporary solution.  If that is the case it would be a good idea to raise 
another JIRA issue so that the need for a long term solution isn't 

Should we be aiming to have a long term solution in place before we get to 
a 1.0 release so that security plans will be upwardly compatible?


This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.

"David Jencks (JIRA)" <> wrote on 30/04/2005 
07:31:57 AM:

>      [ ]
> David Jencks closed GERONIMO-639:
> ---------------------------------
>      Resolution: Fixed
>     Fix Version: 1.0-M4
> fixed in geronimo rev 165344 and in openejb using the "lots of 
> little linked gbeans" solution.
> > GenericSecurityRealm doesn't express its gbean dependencies
> > -----------------------------------------------------------
> >
> >          Key: GERONIMO-639
> >          URL:
> >      Project: Geronimo
> >         Type: Bug
> >   Components: security
> >     Versions: 1.0-M3
> >     Reporter: David Jencks
> >     Assignee: David Jencks
> >      Fix For: 1.0-M4
> >
> > A GenericSecurityRealm depends on a bunch of LoginModuleGBeans to 
> express the login modules that must be logged into to log into the 
> realm.  Currently these are listed by gbean name + other info in a 
> properties file format.  This does nothing to assure that the login 
> modules are in fact started before the GSR is started, although the 
> LMs are used in the GSR constructor.
> > Sometimes the GSR will start, but the same configuration sometimes
> will not start due to system variations in gbean start order.
> > One solution is to make a LoginModule holder gbean that forms a 
> linked list of gbeans, similar to the JettyFilterMapping.  This can 
> be implemented easily with no core changes, but it results in a 
> profusion of gbeans that do almost nothing.
> > Another possible solution is to introduce a core gbean feature 
> that lets you have something like an ordered list of explicit 
> references, all of which must be started for the gbean to start. 
> This would be of more general use but would require some thought to 
> figure out the best functionality.
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> -
> For more information on JIRA, see:

View raw message