You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2005/11/30 04:29:34 UTC
Configuration start order
I have been hacking on the configuration code, and I think I have
stumbled into an unrelated bug.
The problem I'm having is caused by the org/apache/geronimo/Console/
Jetty configuration starting before the org/apache/geronimo/Security
configuration. Which mean when the console starts and attempts to
initialize JACC is gets "java.lang.ClassNotFoundException: Property
javax.security.jacc.PolicyConfigurationFactory.provider not set"
because the provider system property is set in the security
configuration.
Should I make the security configuration a parent of the j2ee-server?
-dain
Re: Configuration start order
Posted by Jeff Genender <jg...@apache.org>.
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.
>
What ever the solution, forcing an import in each plan is a bit much.
If you have a better solution, lets implement it (probably post 1.0?).
But I am as much against forcing the import in the plans as it will open
up a lot of potential issues/JIRAs down the road. The import will be
very easy to forget in the plan as we are now encountering.
> I also hope you will correct the configId before you commit.
>
> thanks
> david jencks
>
Re: Configuration start order
Posted by David Jencks <da...@yahoo.com>.
On Nov 30, 2005, at 9:03 AM, Aaron Mulder wrote:
> On 11/30/05, David Jencks <da...@yahoo.com> wrote:
>> 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.
>
> Sorry, do you mean the security policy as in
> "jre/lib/security/java.policy"? What is the "security policy class"?
implementation of interface java.security.Policy
david jencks
>
> Thanks,
> Aaron
>
Re: Configuration start order
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/30/05, David Jencks <da...@yahoo.com> wrote:
> 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.
Sorry, do you mean the security policy as in
"jre/lib/security/java.policy"? What is the "security policy class"?
Thanks,
Aaron
Re: Configuration start order
Posted by David Jencks <da...@yahoo.com>.
On Nov 30, 2005, at 8:44 AM, Aaron Mulder wrote:
> On 11/30/05, David Jencks <da...@yahoo.com> 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?
yes
> 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.
thanks
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
>>>
>>
>>
>
Re: Configuration start order
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/30/05, David Jencks <da...@yahoo.com> 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?
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?
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
> >
>
>
Re: Configuration start order
Posted by David Jencks <da...@yahoo.com>.
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. 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.
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
>
Re: Configuration start order
Posted by Jeff Genender <jg...@apache.org>.
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
Re: Configuration start order
Posted by Dain Sundstrom <da...@iq80.com>.
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?
-dain
Re: Configuration start order
Posted by David Jencks <da...@yahoo.com>.
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.
I also hope you will correct the configId before you commit.
thanks
david jencks
>
> Dain Sundstrom wrote:
>> That was the problem. I added the following to
>> webconsole-jetty-plan.xml and webconsole-tomcat-plan.xml:
>> <import>
>> <uri>org/apache/geronimo/Security</uri>
>> </import>
>> and the problem went away. Is this something we want in the console
>> plans or in the j2ee-server plan?
>> -dain
>> On Nov 29, 2005, at 7:29 PM, Dain Sundstrom wrote:
>>> I have been hacking on the configuration code, and I think I have
>>> stumbled into an unrelated bug.
>>>
>>> The problem I'm having is caused by the
>>> org/apache/geronimo/Console/Jetty configuration starting before the
>>> org/apache/geronimo/Security configuration. Which mean when the
>>> console starts and attempts to initialize JACC is gets
>>> "java.lang.ClassNotFoundException: Property
>>> javax.security.jacc.PolicyConfigurationFactory.provider not set"
>>> because the provider system property is set in the security
>>> configuration.
>>>
>>> Should I make the security configuration a parent of the j2ee-server?
>>>
>>> -dain
>
Re: Configuration start order
Posted by Jeff Genender <jg...@apache.org>.
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.
Dain Sundstrom wrote:
> That was the problem. I added the following to
> webconsole-jetty-plan.xml and webconsole-tomcat-plan.xml:
>
> <import>
> <uri>org/apache/geronimo/Security</uri>
> </import>
>
> and the problem went away. Is this something we want in the console
> plans or in the j2ee-server plan?
>
> -dain
>
> On Nov 29, 2005, at 7:29 PM, Dain Sundstrom wrote:
>
>> I have been hacking on the configuration code, and I think I have
>> stumbled into an unrelated bug.
>>
>> The problem I'm having is caused by the
>> org/apache/geronimo/Console/Jetty configuration starting before the
>> org/apache/geronimo/Security configuration. Which mean when the
>> console starts and attempts to initialize JACC is gets
>> "java.lang.ClassNotFoundException: Property
>> javax.security.jacc.PolicyConfigurationFactory.provider not set"
>> because the provider system property is set in the security
>> configuration.
>>
>> Should I make the security configuration a parent of the j2ee-server?
>>
>> -dain
Re: Configuration start order
Posted by Dain Sundstrom <da...@iq80.com>.
That was the problem. I added the following to webconsole-jetty-
plan.xml and webconsole-tomcat-plan.xml:
<import>
<uri>org/apache/geronimo/Security</uri>
</import>
and the problem went away. Is this something we want in the console
plans or in the j2ee-server plan?
-dain
On Nov 29, 2005, at 7:29 PM, Dain Sundstrom wrote:
> I have been hacking on the configuration code, and I think I have
> stumbled into an unrelated bug.
>
> The problem I'm having is caused by the org/apache/geronimo/Console/
> Jetty configuration starting before the org/apache/geronimo/
> Security configuration. Which mean when the console starts and
> attempts to initialize JACC is gets
> "java.lang.ClassNotFoundException: Property
> javax.security.jacc.PolicyConfigurationFactory.provider not set"
> because the provider system property is set in the security
> configuration.
>
> Should I make the security configuration a parent of the j2ee-server?
>
> -dain