You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by ApolloX <sc...@selikoff.net> on 2008/04/03 16:46:20 UTC
Genimo + Quartz = No Security Context
Hi All,
I've added quartz scheduling tool my Geronimo 1.2 server. I've created
servlet with start-on-startup property set in the web xml so that on server
start, the servlet issues a call to a session bean that initializes the
scheduler on the EJB tier/level.
The scheduling mechanism starts and works properly, the problem I'm having
is tasks in the schedular are unable to access CMP2 entity beans. Any
attempt to access the persistent layer ends with a NullPointerException in
the geronimo security context manager as show below.
Is there a way to provide the tasks in the schedule with a proper context so
that the processes can run? I checked and the initial call to start the
scheduler has access to this layer, but this information is not available to
the threads the scheduler spawns.
Caused by: java.lang.NullPointerException
at
org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:167)
at
org.apache.openejb.security.EjbSecurityInterceptor.invoke(EjbSecurityInterceptor.java:65)
at
org.apache.openejb.security.EjbRunAsInterceptor.invoke(EjbRunAsInterceptor.java:50)
at
org.apache.openejb.security.PolicyContextHandlerEJBInterceptor.invoke(PolicyContextHandlerEJBInterceptor.java:64)
at
org.apache.openejb.naming.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:51)
at
org.apache.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:56)
at
org.apache.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:110)
at
org.apache.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:60)
at
org.apache.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:50)
at org.apache.openejb.transaction.TxRequired.invoke(TxRequired.java:74)
at
org.apache.openejb.transaction.TransactionPolicyInterceptor.invoke(TransactionPolicyInterceptor.java:50)
at
org.apache.openejb.NoConnectionEnlistingInterceptor.invoke(NoConnectionEnlistingInterceptor.java:68)
at
org.apache.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:35)
at
org.apache.openejb.entity.cmp.DefaultCmpEjbContainer.invoke(DefaultCmpEjbContainer.java:150)
at
org.apache.openejb.entity.cmp.DefaultCmpEjbContainer$$FastClassByCGLIB$$e128ff0b.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.openejb.BmpEjbContainer$$EnhancerByCGLIB$$821fbd47.invoke(<generated>)
at
org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
at
org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
--
View this message in context: http://www.nabble.com/Genimo-%2B-Quartz-%3D-No-Security-Context-tp16467530s134p16467530.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Genimo + Quartz = No Security Context
Posted by ApolloX <sc...@selikoff.net>.
I ended up finding a solution, er, workaround, by moving the Quartz scheduler
into the Web layer instead of the EJB layer. In this regard, the threads
running in the servlet layer establish new remote connections to trigger the
EJB process. Slows down performance since it has to cross layers every time
the job is activated, but at least it works.
--
View this message in context: http://www.nabble.com/Genimo-%2B-Quartz-%3D-No-Security-Context-tp16467530s134p16495642.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Genimo + Quartz = No Security Context
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 4, 2008, at 1:14 PM, David Jencks wrote:
<snip>
>
> Hope we can get you onto 2.x soon :-)
Agreed. If there's a test app that can demonstrate your CMP/flush
issue that you can share with us, that would be great.
Create a Jira ( https://issues.apache.org/jira/browse/GERONIMO ) and
attach the app to it.
--kevan
Re: Genimo + Quartz = No Security Context
Posted by David Jencks <da...@yahoo.com>.
On Apr 4, 2008, at 9:05 AM, ApolloX wrote:
>
>
> Dan Becker wrote:
>>
>> Quick question. Are you running with Java 2 security enabled?
>> (-Djava.security.manager)? If so, what policies are you running with?
>>
>> There are some areas in Geronimo where security AccessControllers
>> must
>> be added, so this could be an area where privileged code is run
>> without
>> the proper control blocks (see
>> https://issues.apache.org/jira/browse/GERONIMO-3938).
>>
>
> No I'm not but adding that switch produces the error on startup
> shown in the
> ticket issue. Should I be running with the security manager?
no, g. won't work as you have discovered through experiment.
>
> It seems like my system isn't configured for a default security
> role in the
> event a thread tries to access the EJB layer without a user context.
exactly correct
> Is
> there a way to configure the geronimo files to make such a context
> available
> for quartz threads?
You could try setting up a default principal in the geronimo security
configuration. I'm not confident that will help. IIRC I made it
more likely there would be a suitable "no permissions" subject
available in 2.x.
> In theory I could pass the initialization servlet's
> context at the time the threads are created, but it seems like that
> would
> (and probably should) expire while the threads are sleeping.
Have you tried having the quartz task make a remote call to the ejb?
That _should_ go through the code that sets up an appropriate
security context for the thread. If the default principal doesn't
work this may be your best option in 1.x.
Hope we can get you onto 2.x soon :-)
thanks
david jencks
> --
> View this message in context: http://www.nabble.com/Genimo-%2B-
> Quartz-%3D-No-Security-Context-tp16467530s134p16492621.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>
Re: Genimo + Quartz = No Security Context
Posted by ApolloX <sc...@selikoff.net>.
Dan Becker wrote:
>
> Quick question. Are you running with Java 2 security enabled?
> (-Djava.security.manager)? If so, what policies are you running with?
>
> There are some areas in Geronimo where security AccessControllers must
> be added, so this could be an area where privileged code is run without
> the proper control blocks (see
> https://issues.apache.org/jira/browse/GERONIMO-3938).
>
No I'm not but adding that switch produces the error on startup shown in the
ticket issue. Should I be running with the security manager?
It seems like my system isn't configured for a default security role in the
event a thread tries to access the EJB layer without a user context. Is
there a way to configure the geronimo files to make such a context available
for quartz threads? In theory I could pass the initialization servlet's
context at the time the threads are created, but it seems like that would
(and probably should) expire while the threads are sleeping.
--
View this message in context: http://www.nabble.com/Genimo-%2B-Quartz-%3D-No-Security-Context-tp16467530s134p16492621.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Genimo + Quartz = No Security Context
Posted by Dan Becker <da...@gmail.com>.
ApolloX wrote:
> I've added quartz scheduling tool my Geronimo 1.2 server. I've created
> servlet with start-on-startup property set in the web xml so that on server
> start, the servlet issues a call to a session bean that initializes the
> scheduler on the EJB tier/level.
>
> The scheduling mechanism starts and works properly, the problem I'm having
> is tasks in the schedular are unable to access CMP2 entity beans. Any
> attempt to access the persistent layer ends with a NullPointerException in
> the geronimo security context manager as show below.
>
> Is there a way to provide the tasks in the schedule with a proper context so
> that the processes can run? I checked and the initial call to start the
> scheduler has access to this layer, but this information is not available to
> the threads the scheduler spawns.
>
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:167)
Hello ApolloX,
Quick question. Are you running with Java 2 security enabled?
(-Djava.security.manager)? If so, what policies are you running with?
There are some areas in Geronimo where security AccessControllers must
be added, so this could be an area where privileged code is run without
the proper control blocks (see
https://issues.apache.org/jira/browse/GERONIMO-3938).
--
Thanks, Dan Becker
Re: Genimo + Quartz = No Security Context
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 3, 2008, at 10:35 PM, ApolloX wrote:
>
>
> djencks wrote:
>>
>> Is moving to geronimo 2.x an option for you?
>>
>
> No, as I've previously mentioned (with zero helpful responses)
> moving to
> G2.x significantly slows down my CMP2 beans.
I'd tried to forward your CMP performance problem to dev@openejb.apache.org
a while back. Checking my sent mail log -- looks like I sent to a
bad email address. I've resent...
--kevan
Re: Genimo + Quartz = No Security Context
Posted by ApolloX <sc...@selikoff.net>.
djencks wrote:
>
> Is moving to geronimo 2.x an option for you?
>
No, as I've previously mentioned (with zero helpful responses) moving to
G2.x significantly slows down my CMP2 beans.
--
View this message in context: http://www.nabble.com/Genimo-%2B-Quartz-%3D-No-Security-Context-tp16467530s134p16479033.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Genimo + Quartz = No Security Context
Posted by David Jencks <da...@yahoo.com>.
I think if you moved to geronimo 2.1 we would provide a security
context with no permissions to the quartz thread. If you used a
remote connection to the ejb from the quartz task then you should get
a security context.
If you used an ejb timer it would handle this.
There's a (proposed?) ee conncurrency spec that we are working on
implementing that should also provide means to supply a security
context.
Do you need access to the ejb to be secured or do you just want it to
work :-)
Is moving to geronimo 2.x an option for you?
thanks
david jencks
On Apr 3, 2008, at 7:46 AM, ApolloX wrote:
>
> Hi All,
>
> I've added quartz scheduling tool my Geronimo 1.2 server. I've
> created
> servlet with start-on-startup property set in the web xml so that
> on server
> start, the servlet issues a call to a session bean that initializes
> the
> scheduler on the EJB tier/level.
>
> The scheduling mechanism starts and works properly, the problem I'm
> having
> is tasks in the schedular are unable to access CMP2 entity beans. Any
> attempt to access the persistent layer ends with a
> NullPointerException in
> the geronimo security context manager as show below.
>
> Is there a way to provide the tasks in the schedule with a proper
> context so
> that the processes can run? I checked and the initial call to
> start the
> scheduler has access to this layer, but this information is not
> available to
> the threads the scheduler spawns.
>
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.geronimo.security.ContextManager.getCurrentContext
> (ContextManager.java:167)
> at
> org.apache.openejb.security.EjbSecurityInterceptor.invoke
> (EjbSecurityInterceptor.java:65)
> at
> org.apache.openejb.security.EjbRunAsInterceptor.invoke
> (EjbRunAsInterceptor.java:50)
> at
> org.apache.openejb.security.PolicyContextHandlerEJBInterceptor.invoke(
> PolicyContextHandlerEJBInterceptor.java:64)
> at
> org.apache.openejb.naming.ComponentContextInterceptor.invoke
> (ComponentContextInterceptor.java:51)
> at
> org.apache.openejb.ConnectionTrackingInterceptor.invoke
> (ConnectionTrackingInterceptor.java:56)
> at
> org.apache.openejb.entity.EntityInstanceInterceptor.invoke
> (EntityInstanceInterceptor.java:110)
> at
> org.apache.openejb.entity.cmp.InTxCacheInterceptor.invoke
> (InTxCacheInterceptor.java:60)
> at
> org.apache.openejb.transaction.TransactionContextInterceptor.invoke
> (TransactionContextInterceptor.java:50)
> at org.apache.openejb.transaction.TxRequired.invoke
> (TxRequired.java:74)
> at
> org.apache.openejb.transaction.TransactionPolicyInterceptor.invoke
> (TransactionPolicyInterceptor.java:50)
> at
> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
> (NoConnectionEnlistingInterceptor.java:68)
> at
> org.apache.openejb.SystemExceptionInterceptor.invoke
> (SystemExceptionInterceptor.java:35)
> at
> org.apache.openejb.entity.cmp.DefaultCmpEjbContainer.invoke
> (DefaultCmpEjbContainer.java:150)
> at
> org.apache.openejb.entity.cmp.DefaultCmpEjbContainer$
> $FastClassByCGLIB$$e128ff0b.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:122)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at
> org.apache.openejb.BmpEjbContainer$$EnhancerByCGLIB$$821fbd47.invoke
> (<generated>)
> at
> org.apache.openejb.AbstractEjbDeployment.invoke
> (AbstractEjbDeployment.java:195)
> at
> org.apache.openejb.proxy.EJBMethodInterceptor.intercept
> (EJBMethodInterceptor.java:145)
> --
> View this message in context: http://www.nabble.com/Genimo-%2B-
> Quartz-%3D-No-Security-Context-tp16467530s134p16467530.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>