geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Configuration start order
Date Wed, 30 Nov 2005 16:56:21 GMT

On Nov 30, 2005, at 8:44 AM, Aaron Mulder wrote:

> On 11/30/05, David Jencks <> wrote:
>> I don't think it's possible
>> to move security as a parent of j2ee-server and still have the tck 
>> test
>> what we ship.
> Why's that?

Roughly speaking, because the security service gbean installs the 
security policy and the security policy class has to be in the 
classpath of the configuration holding the security service gbean.  So, 
whenever a user wishes to use a different security policy, they need to 
  modify the security  configuration.  If the security configuration is 
a parent of the basic configurations such as j2ee-server, they will 
need to replace all of those as well.
> I would think we should put the common security plumbing
> (JaasLoginManager, etc.) in the core parent path, and leave specific
> realms out (that is, in separate configurations).  Would that cause
> problems with the TCK?

> Or would that not fix the original problem
> because you'd still need a dependency between your WAR and the
> configuration holding the specific realm?

I think it would fix the original problem, but prevent us from running 
the tck.

david jencks

> Thanks,
>     Aaron
>> If you guys insist on this, I'd prefer to break things by including 
>> the
>> security config in the web builder default parentId rather than change
>> our basic classloader heirarchy.  Please open a jira indicating what
>> needs to be done in the future, and thoroughly check that the tck 
>> still
>> passes.  I think there will be problems.
>> david jencks
>> On Nov 30, 2005, at 8:00 AM, Jeff Genender wrote:
>>> Dain Sundstrom wrote:
>>>> On Nov 30, 2005, at 1:31 AM, David Jencks wrote:
>>>>> On Nov 29, 2005, at 7:52 PM, Jeff Genender wrote:
>>>>>> I think it should go in the j2ee-server plan.  IMHO the security
>>>>>> should be available for all web apps, whether its used or not.  I
>>>>>> think it will be a PITA if every web app requires that import.
>>>>> I strenuously object to foisting security onto every configuration
>>>>> whether or not it is wanted.  A more appropriate solution is to 
>>>>> make
>>>>> the security builder into a real gbean and let it add to the
>>>>> parentId if it is called.  Please don't push us back into the 
>>>>> miasma
>>>>> of a single plan.
>>>> How about we add this to the server plan for 1.0, and when the
>>>> security builder is cleaned up, we remove it?
>>> +1...lets get this out the door and fix it post 1.0 release.
>>>> -dain

View raw message