Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
ok it's bug 558362 * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14829 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
I'm using 2.4.5/jetty4 final release (dated 2002-05-10) and I'm still getting this problem. I get it on sfsb passivation, however. Testcase can be supplied on demand (the forums don't want to upload the attachment, and since the bug is closed sf won't accept attachments): 2 stateful beans, one bean holds a reference to the other. When the first bean is passivated, the passivation thread has no security association (i.e. SecurityAssociation.getPrincipal() returns null) therefore the ejbPassivate() method - which attempts to remove its reference to the other EJB - fails because the remove() requires authenticating. I added some logging to ejbPassivate() and found that while sessionContext.getCallerPrincipal() returned the correct principal, SecurityAssociation.getPrincipal() returned null. This seems to me to be purely because the principal and credentials are associated with the thread, and the passivator background thread is obviously unauthenticated. I'm using the apparently-fixed version of StatefulSessionInstanceInterceptor (cvs ver 1.15.6.6, the one in the release) but no joy. Stack trace is: [ScratchStatefulReferringBean] Creating bean: com.lombardrisk.scratch.ScratchStatefulReferringSession [ScratchStatefulReferredBean] Creating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [ScratchStatefulReferredBean] Passivating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [ScratchStatefulReferredBean] getCallerPrincipal is guest [ScratchStatefulReferredBean] SecurityAssociation.getPrincipal()=null [ScratchStatefulReferringBean] Passivating bean: com.lombardrisk.scratch.ScratchStatefulReferringSession [ScratchStatefulReferringBean] getCallerPrincipal is guest [ScratchStatefulReferringBean] SecurityAssociation.getPrincipal()=null [ScratchStatefulReferredBean] Activating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [SecurityInterceptor] Authentication exception, principal=null [ScratchStatefulReferred] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null java.lang.SecurityException: Authentication exception, principal=null at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:167) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:116) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:255) at com.lombardrisk.jbossinfra.audit.AuditTrailInterceptor.invoke(AuditTrailInterceptor.java:175) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:347) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:506) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:335) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136) at $Proxy230.remove(Unknown Source) at com.lombardrisk.scratch.ScratchStatefulReferringBean.ejbPassivate(ScratchStatefulReferringBean.java:73) at com.lombardrisk.scratch.ScratchStatefulReferringSession.ejbPassivate(ScratchStatefulReferringSession.java:34) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.jav :278) at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:79) at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache.java:622) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) at java.lang.Thread.run(Thread.java:479) [ScratchStatefulReferringBean] Couldn't remove javax.transaction.TransactionRolledbackException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception,
Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
Create a new bug with the testcase as this is a different scenario. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Chris Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 20, 2002 10:15 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails I'm using 2.4.5/jetty4 final release (dated 2002-05-10) and I'm still getting this problem. I get it on sfsb passivation, however. Testcase can be supplied on demand (the forums don't want to upload the attachment, and since the bug is closed sf won't accept attachments): 2 stateful beans, one bean holds a reference to the other. When the first bean is passivated, the passivation thread has no security association (i.e. SecurityAssociation.getPrincipal() returns null) therefore the ejbPassivate() method - which attempts to remove its reference to the other EJB - fails because the remove() requires authenticating. I added some logging to ejbPassivate() and found that while sessionContext.getCallerPrincipal() returned the correct principal, SecurityAssociation.getPrincipal() returned null. This seems to me to be purely because the principal and credentials are associated with the thread, and the passivator background thread is obviously unauthenticated. I'm using the apparently-fixed version of StatefulSessionInstanceInterceptor (cvs ver 1.15.6.6, the one in the release) but no joy. Stack trace is: [ScratchStatefulReferringBean] Creating bean: com.lombardrisk.scratch.ScratchStatefulReferringSession [ScratchStatefulReferredBean] Creating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [ScratchStatefulReferredBean] Passivating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [ScratchStatefulReferredBean] getCallerPrincipal is guest [ScratchStatefulReferredBean] SecurityAssociation.getPrincipal()=null [ScratchStatefulReferringBean] Passivating bean: com.lombardrisk.scratch.ScratchStatefulReferringSession [ScratchStatefulReferringBean] getCallerPrincipal is guest [ScratchStatefulReferringBean] SecurityAssociation.getPrincipal()=null [ScratchStatefulReferredBean] Activating bean: com.lombardrisk.scratch.ScratchStatefulReferredSession [SecurityInterceptor] Authentication exception, principal=null [ScratchStatefulReferred] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null java.lang.SecurityException: Authentication exception, principal=null at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityI nterceptor.java:167) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:11 6) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess ionInstanceInterceptor.java:255) at com.lombardrisk.jbossinfra.audit.AuditTrailInterceptor.invoke(AuditTrailInte rceptor.java:175) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java: 347) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI nvoker.java:506) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr oxy.java:335) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSe ssionProxy.java:136) at $Proxy230.remove(Unknown Source) at com.lombardrisk.scratch.ScratchStatefulReferringBean.ejbPassivate(ScratchSta tefulReferringBean.java:73) at com.lombardrisk.scratch.ScratchStatefulReferringSession.ejbPassivate(Scratch StatefulReferringSession.java:34) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession (StatefulSessionFilePersistenceManager.jav :278) at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSession InstanceCache.java:79) at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache. java:622) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) at java.lang.Thread.run
[JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
Bugs item #552157, was opened at 2002-05-03 19:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=552157group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Victor Langelo (vlangelo) Assigned to: Scott M Stark (starksm) Summary: Stateful session activation fails Initial Comment: JDK 1.3.1_03 Windows NT and RedHat Linux 7.0 JBoss version 2.4.5RC3+ (branch_2_4 checkout 5/3/02) and in JBoss 2.4.4 This is really the same as bug 441165. When a stateful session bean with referenced entity bean is reactivated, there is no security context associated with the thread. Hence an Authenication exception is thrown by an attempt to call the entity bean's findByPrimaryKey method. As shown in the following log excerpt, AbstractInstanceCache.get is called before the security interceptor has associated the caller principal with the current context. [ClientEditBean,2002-05-03 22:29:45,672] ejbPassivate called for com.eclipseservices.adpro.customer.ClientEditBean@2b436d [DBConnectionProvider,2002-05-03 22:29:58,711] Getting data source from environment. [DBConnectionProvider,2002-05-03 22:29:58,721] getDBConnection: creating connection spec. [SecurityInterceptor,2002-05-03 22:30:29,435] Authentication exception, principal=null [ClientEdit,2002-05-03 22:30:29,465] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException; nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:182) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:194) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:347) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:412) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- Comment By: Scott M Stark (starksm) Date: 2002-05-06 16:16 Message: Logged In: YES user_id=175228 The 3.0 mechanism of associating the caller identity with the thread prior to obtaining the session context from the cache has been back ported. Submit a testcase if this does not resolve your issue. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=552157group_id=22866 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
I'm willing to work on this problem, since I've already spent some time studying the relevant code. However, my first attempt was not spec compliant. So I though it might be a good idea to bounce a couple of solutions off the general dev group. The general problem is that passivated stateful session beans are activated in the StatefulSessionInstanceInterceptor. The instance interceptor sits before the security interceptor in the interceptor chain. If the passivated bean has any references to other beans, the handles to those beans call the bean's remote method (create or findByPrimaryKey). Since the caller's principal hasn't been associated with the current context yet, the remote method fails due to an authentication exception. Simply changing the order of the interceptors is not spec compliant because legitimate security exceptions will not dispose of the session bean. I can think of two solutions. 1. Split the security interceptor into two. The first would check the caller's credentials. If verifiable, associate the principal with the current context. Otherwise, do nothing before calling the next interceptor. The second security interceptor would check the method permissions. 2. Add support for a special principal like the anybody principal to the security interceptor. Any call with this principal will always succeed. Then the StatefulSessionPersistenceManager can temporarily associate this principal during activateSession. I think the first solution is cleaner, and only marginally violates the EJB spec. The spec is concerned with checking the callers roles against the declared method permissions. It really isn't concerned with verifying the caller's credentials. Any thoughts before I attempt another patch? --Victor Langelo Bugs item #552157, was opened at 2002-05-03 21:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=552157group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Victor Langelo (vlangelo) Assigned to: Nobody/Anonymous (nobody) Summary: Stateful session activation fails Initial Comment: JDK 1.3.1_03 Windows NT and RedHat Linux 7.0 JBoss version 2.4.5RC3+ (branch_2_4 checkout 5/3/02) and in JBoss 2.4.4 This is really the same as bug 441165. When a stateful session bean with referenced entity bean is reactivated, there is no security context associated with the thread. Hence an Authenication exception is thrown by an attempt to call the entity bean's findBy PrimaryKey method. As shown in the following log excerpt, AbstractInstanceCache.get is called before the security interceptor has associated the caller principal with the current context. [ClientEditBean,2002-05-03 22:29:45,672] ejbPassivate called for com.eclipseservices.adpro.customer.ClientEditBean@2b436d [DBConnectionProvider,2002-05-03 22:29:58,711] Getting data source from environment. [DBConnectionProvider,2002-05-03 22:29:58,721] getDBConnection: creating connection spec. [SecurityInterceptor,2002-05-03 22:30:29,435] Authentication exception, principal=null [ClientEdit,2002-05-03 22:30:29,465] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException; nested exception is: java.rmi.NoSuchObjectException: Could no t activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:182) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:194) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) at org.jboss.ejb.StatefulSessionContainer.invoke(Statefu lSessionContainer.java:347) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:412) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown
[JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
Bugs item #552157, was opened at 2002-05-03 21:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=552157group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Victor Langelo (vlangelo) Assigned to: Nobody/Anonymous (nobody) Summary: Stateful session activation fails Initial Comment: JDK 1.3.1_03 Windows NT and RedHat Linux 7.0 JBoss version 2.4.5RC3+ (branch_2_4 checkout 5/3/02) and in JBoss 2.4.4 This is really the same as bug 441165. When a stateful session bean with referenced entity bean is reactivated, there is no security context associated with the thread. Hence an Authenication exception is thrown by an attempt to call the entity bean's findByPrimaryKey method. As shown in the following log excerpt, AbstractInstanceCache.get is called before the security interceptor has associated the caller principal with the current context. [ClientEditBean,2002-05-03 22:29:45,672] ejbPassivate called for com.eclipseservices.adpro.customer.ClientEditBean@2b436d [DBConnectionProvider,2002-05-03 22:29:58,711] Getting data source from environment. [DBConnectionProvider,2002-05-03 22:29:58,721] getDBConnection: creating connection spec. [SecurityInterceptor,2002-05-03 22:30:29,435] Authentication exception, principal=null [ClientEdit,2002-05-03 22:30:29,465] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException; nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.lang.reflect.InvocationTargetException at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:182) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:194) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:347) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:412) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=552157group_id=22866 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
