11 Replies Latest reply on May 6, 2008 3:24 AM by loucs

    Wrong tx on thread, illegalStateException when accessing an

    loucs

      i posted this problem in the jboss portal and the jndi forums but i figured its place was here.

      first of all, i'm using JBoss 4.2.2.GA, portal 2.6.4.GA, Seam 2.0.0.GA and EJB3

      my project is deployed in an ear which contains portlet controllers for portal portlets, and a lot of EJB Entity. it contains also a session bean which i'd like to access via jndi.

      here's the code related to it :

      the bean code :
      
      @Stateless
      @TransactionManagement(TransactionManagementType.BEAN)
      
      
      public class IdentityUserModule implements IdentityUserModuleRemote {
      
       //@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
       public SiteAccountImpl findUserByUserName(String userName) {
       /*if (userName.indexOf('@') != -1) {
       String[] tab = userName.split("@");
       SiteAccountManagerImpl manager = new SiteAccountManagerImpl();
       return manager.getSiteAccountFromHostAndLogin(tab[0], tab[1]);
       }*/
       return null;
       }
      
       @Remove
       public void destroy() {}
      }
      
      
      
      the remote interface :
      
      @Remote
      public interface IdentityUserModuleRemote {
       public SiteAccountImpl findUserByUserName(String userName);
      }
      



      the class where i do the jndi lookup is in a separated jar that i export in server\default\deploy\jboss-portal.sar\lib

      here is its code :

      
      public class AgeoUserModuleImpl extends HibernateUserModuleImpl {
       public User findUserByUserName(String userName) throws IdentityException {
       System.out.println("on rentre dans user module!!!!!!!!!!!!!!");
       IdentityUserModuleRemote userModule;
       Object tmp;
      
       try {
      
       tmp = new InitialContext().lookup("smalltox-ear/IdentityUserModule/remote");
      
      
       System.out.println(tmp.getClass() + " bla");
      
       userModule = (IdentityUserModuleRemote) tmp;
      
       } catch (RuntimeException re) {
       System.out.println("pas de jndi et runtime : " + re.getMessage());
       //re.printStackTrace();
       return super.findUserByUserName(userName);
       }
       catch (Exception e) {
       System.out.println("pas de jndi et : " + e.getMessage());
       //e.printStackTrace();
       return super.findUserByUserName(userName);
       }
       if (userModule == null) {
       System.out.println("pas de JNDI 2");
       return super.findUserByUserName(userName);
       }
       else
       System.out.println("acces au JNDI!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
      
       /*SiteAccountImpl account = userModule.findUserByUserName(userName);
       if (account == null)
       return null;
      
       HibernateUserImpl user = new HibernateUserImpl(userName);
       user.setEnabled(account.getActivated());
       user.setPassword(account.getPassword());
       new Set<Role>();
       user.setRoles()*/
       return super.findUserByUserName(userName);
       }
      }
      
      



      - the line : System.out.println(tmp.getClass() + " bla"); print something like "class proxy$855 bla"

      so the jndi lookup works fine.

      but at the line where i cast object tmp into IdentityUserModuleRemote,

      i got the wrong tx exception.

      here's the stack trace :

      java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < ac, BasicAction: -3f57fe93:e6f9:481864a2:27f status: ActionStatus.ABORT_ONLY >, actual TransactionImple < ac, BasicAction: -3f57fe93:e6f9:481864a2:289 status: ActionStatus.RUNNING >
       at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:162)
       at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
       at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
       at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
       at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
       at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
       at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
       at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
       at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
       at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
       at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
       at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:250)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
       at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
       at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
       at java.lang.Thread.run(Thread.java:619)
      14:34:39,648 ERROR [[PortalServletWithPathMapping]] "Servlet.service()" pour la servlet PortalServletWithPathMapping a généré une exception
      java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < ac, BasicAction: -3f57fe93:e6f9:481864a2:27f status: ActionStatus.ABORT_ONLY >, actual TransactionImple < ac, BasicAction: -3f57fe93:e6f9:481864a2:289 status: ActionStatus.RUNNING >
       at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:162)
       at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
       at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
       at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
       at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
       at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
       at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
       at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:69)
       at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:130)
       at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
       at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
       at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:250)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
       at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
       at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
       at java.lang.Thread.run(Thread.java:619)
      14:34:40,545 ERROR [CachedConnectionValve] Application error: PortalServletWithPathMapping did not complete its transaction
      


      if you need other infos on the project, i'll give it out with pleasure.

      any clues would help as i'm a total noob to transaction management (only know some of the bases concept).

      Regards,

      --
      Lucas
      Montes


        • 1. Re: Wrong tx on thread, illegalStateException when accessing
          loucs

          i've done the same thing accessing my ejb with jmx and the same exception happened. i'm must make a mistake deploying my ear in portal...

          here's the code i used instead og the jndi lookup (i've made a local interface for my ejb with the @Local annotation) :

          
          MBeanServer mbeanServer = MBeanServerLocator.locateJBoss();
          userModule = (IdentityUserModuleLocalInterface) MBeanProxy.get(IdentityUserModuleLocalInterface.class, new ObjectName(""), mbeanServer);
          
          


          Regards,

          --
          Lucas
          Montes

          • 2. Re: Wrong tx on thread, illegalStateException when accessing
            vickyk

            Check if the TX is not timed out
            http://wiki.jboss.org/wiki/TxMultipleThreads

            • 3. Re: Wrong tx on thread, illegalStateException when accessing
              vickyk

              Do your code always gives the same exeption ie info about ABORTED TX Or you get it randomly ?

              • 4. Re: Wrong tx on thread, illegalStateException when accessing
                loucs

                the BasicAction hashcode changes but the expected transaction is always in ABORTED status.
                i've done a lot of tests, printing the current Transaction status (always active).

                i've tested with a TransactionPropagationContextImporter :

                TransactionPropagationContextImporter importer = (TransactionPropagationContextImporter) new InitialContext().lookup("java:TransactionPropagationContextImporter");
                
                
                
                 Object tmp = new InitialContext().lookup("smalltox-ear/IdentityUserModule/local");
                
                
                 Transaction tx = importer.importTransactionPropagationContext(tmp);
                
                 printTransactionStatus(tx.getStatus());
                
                


                but it gives me an error :
                ERROR [PropagationContextManager] jboss-atx: unknown Tx PropagationContext

                I've tested both with the EJB local and remote interfaces. i've tested in CMT and BMT environment too. each cases giving me the same exception, even the MBean way of accessing my ejb.

                thanks for your interest at my issue,

                --
                Lucas
                Montes

                • 5. Re: Wrong tx on thread, illegalStateException when accessing
                  loucs

                  it seem i got wrong using the TransactionPropagationContextImporter, i'll find t he right usage for this class.

                  Regards,

                  --
                  Lucas
                  Montes

                  • 6. Re: Wrong tx on thread, illegalStateException when accessing
                    loucs

                    i finally got rid of the Wrong tx on thread, but another strange issue is happening :

                    I first get the TransactionManager via jndi (java:TransactionManager).

                    then i suspend the current transaction :
                    t = tm.suspend();

                    then i do the lookup of my EJB remote or local interface, and i put it into an JBossProxy interface.

                    then i print infos with the getClass() method :

                    
                    tmp = (JBossProxy) new InitialContext().lookup("smalltox-ear/IdentityUserModule/remote");
                     System.out.println("obj : " + tmp.getClass().getName() + " " + tmp.getClass().getSimpleName() + " " + tmp.getClass().getSuperclass() + " " + tmp.getClass().getPackage() );
                    
                    
                     for (int i = 0; i < tmp.getClass().getMethods().length; i++) {
                     System.out.println("method : " + tmp.getClass().getMethods().getName());
                     }
                    
                    
                     for (int i = 0; i < tmp.getClass().getInterfaces().length; i++)
                     System.out.println("Interface : " + tmp.getClass().getInterfaces().getName());
                    
                    



                    and here's the output :

                    obj : $Proxy855 $Proxy855 class java.lang.reflect.Proxy null
                    
                    10:20:29,339 INFO [STDOUT] method : hashCode
                    10:20:29,339 INFO [STDOUT] method : equals
                    10:20:29,339 INFO [STDOUT] method : toString
                    10:20:29,339 INFO [STDOUT] method : findUserByUserName
                    10:20:29,340 INFO [STDOUT] method : getAsynchronousProxy
                    10:20:29,340 INFO [STDOUT] method : isProxyClass
                    10:20:29,340 INFO [STDOUT] method : getProxyClass
                    10:20:29,340 INFO [STDOUT] method : newProxyInstance
                    10:20:29,340 INFO [STDOUT] method : getInvocationHandler
                    10:20:29,340 INFO [STDOUT] method : wait
                    10:20:29,340 INFO [STDOUT] method : wait
                    10:20:29,340 INFO [STDOUT] method : wait
                    10:20:29,340 INFO [STDOUT] method : getClass
                    10:20:29,340 INFO [STDOUT] method : notify
                    10:20:29,340 INFO [STDOUT] method : notifyAll
                    
                    10:20:29,340 INFO [STDOUT] Interface : com.smalltox.foundation.identity.IdentityUserModuleRemote
                    10:20:29,341 INFO [STDOUT] Interface : org.jboss.ejb3.JBossProxy
                    


                    then i try to cast the JBossProxy object into my local or remote interface and i got a class cast exception :

                    $Proxy855 cannot be cast to com.smalltox.foundation.identity.IdentityUserModuleRemote

                    this is really strange, and the samething happen whether i resume the transaction before the cast of after..

                    the encouraging part is that portal continues to work well after i resume the transaction.

                    I think i might have to move this post in the EJB section of this forum :)

                    any clues would help a lot.

                    Regards,

                    --
                    Lucas
                    Montes

                    • 7. Re: Wrong tx on thread, illegalStateException when accessing
                      loucs

                      i'd like to add that in my jmx console, i've got this output in the JNDIView :

                      when remote + ejb stateful
                      Global JNDI Namespace
                      
                      +- smalltox-ear (class: org.jnp.interfaces.NamingContext)
                       +- IdentityUserModule (class: org.jnp.interfaces.NamingContext)
                       | | +- remote (class: java.lang.Object)
                       | | +- remoteStatefulProxyFactory (proxy: $Proxy857 implements interface org.jboss.ejb3.ProxyFactory)
                      
                      when remote and ejb statless
                      
                      +- smalltox-ear (class: org.jnp.interfaces.NamingContext)
                       +- IdentityUserModule (class: org.jnp.interfaces.NamingContext)
                       | | +- remote (proxy: $Proxy854 implements interface com.smalltox.foundation.identity.IdentityUserModuleRemote,interface org.jboss.ejb3.JBossProxy)
                      
                      
                      when i make my EJB local and stateless:
                      
                      +- smalltox-ear (class: org.jnp.interfaces.NamingContext)
                       +- IdentityUserModule (class: org.jnp.interfaces.NamingContext)
                       | | +- local (proxy: $proxy855 implements interface com.smalltox.foundation.identity.IdentityUserModuleLocalInterface, interface org.jboss.ejb3.JBossProxy)
                      
                      


                      i think it migth be caused by the fact my local or remote interfaces are in a jar in the libdir of portal, and in my ear. but i can't see any other way of calling my ejb from the portal app.

                      Regards,

                      --
                      Lucas
                      Montes

                      • 8. Re: Wrong tx on thread, illegalStateException when accessing
                        loucs

                        ok so i've read some of the seam reference guide and it isn't specified that a unifiedclassloader must be defined for it to work. it seems te loader-repository was defined because of a problem of classloading the FacesContext. i will continue throught this to find more from where does the conflict come from, but i'm still posting the exception, in case someone can give me a hint :) (strange i can't post in the seam forum...)

                        
                        Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "com.sun.facelets.util.Resource.getResourceUrl(Ljavax/faces/context/FacesContext;Ljava/lang/String;)Ljava/net/URL;" the class loader (instance of org/jboss/portal/faces/loader/FacesClassLoader) of the current class, com/sun/facelets/impl/DefaultResourceResolver, and the class loader (instance of org/jboss/mx/loading/UnifiedClassLoader3) for resolved class, com/sun/facelets/util/Resource, have different Class objects for the type javax/faces/context/FacesContext used in the signature
                         at com.sun.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:19)
                         at com.sun.facelets.impl.DefaultFaceletFactory.<init>(DefaultFaceletFactory.java:70)
                         at com.sun.facelets.FaceletViewHandler.createFaceletFactory(FaceletViewHandler.java:286)
                         at com.sun.facelets.FaceletViewHandler.initialize(FaceletViewHandler.java:197)
                         at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:494)
                         at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
                         at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
                         at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:397)
                         at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:377)
                         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:474)
                         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:323)
                         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
                         at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
                         at org.jboss.portal.faces.loader.FacesPortlet.render(FacesPortlet.java:100)
                         at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
                         at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
                         at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
                         at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
                         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
                         at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
                         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
                         at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
                         at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
                         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
                         at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:104)
                         at org.jboss.portal.web.command.CommandDispatcher$CallbackCommand.execute(CommandDispatcher.java:74)
                         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                         at java.lang.reflect.Method.invoke(Method.java:597)
                         at org.jboss.portal.web.command.CommandServlet.doGet(CommandServlet.java:131)
                         at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
                         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
                         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
                         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
                         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
                         at org.jboss.portal.web.command.CommandServlet.include(CommandServlet.java:80)
                         ... 178 more
                        
                        


                        The first thing coming to my mind is that portal and seam (or my project), use different implementations of the JSF spec but i can't really say since i haven't participated in the architectural design of the project. as i write ths post it comes to my mind that portal seem to use Myfaces and my project uses richfaces (and also import another one like icefaces i think), so it must be the cause of the problem that lead the project architect to define a lloader-repository in the ear.

                        thanks for your help,

                        --
                        Lucas
                        Montes

                        • 9. Re: Wrong tx on thread, illegalStateException when accessing
                          vickyk

                          It is becoming messy here , you started with TX and then seam/EJB and finally it seems some CL issue .
                          I would suggest you to go to the seam/EJB forums and get it thrashed there first .

                          Also you should not be interacting with the TransactionManager directly in the application code it should be the UserTransaction which should be used .

                          • 10. Re: Wrong tx on thread, illegalStateException when accessing
                            loucs

                            that's the point :) i posted in portal forum because it's the use of a different implementation of jsf in my project from the portal project's one that forced my project architect to isolate my ear classloading with a loader-repository.

                            and i posted in EJB/JBoss and JNDI lookups because one of the solution would be to forced the calledbyvalue lookup on my EJB, but i still can't figure out how to do this with EJB3 :P

                            Regards,

                            --
                            Lucas
                            Montes

                            • 11. Re: Wrong tx on thread, illegalStateException when accessing
                              loucs

                              problem solved :) i've done a lookup forcing the marshalling for method invocation (called-by-value) by putting the full scheme in the lookup :

                              new InitialContext("jnp://localhost:1099/EJBJndiName");
                              


                              (my project manager wanted to keep the scoping of classloading for my ear so that was the less ugly way to do it :)