2 Replies Latest reply on Mar 3, 2009 6:08 PM by Guillaume Jeudy

    Invoking seam component EJBs outside of seam application

    J R Newbie

      I am using Seam to build a REST service onto an existing EJB based application. I am using Seam to take advantage of its managed persistence contexts and transaction management. In the process I have begun annotating some of the prexisting EJBs as Seam components. However, I have found that now when I attempt access these EJBs outside of Seam (i.e, using @EJB, looking them up in JNDI in another application outside the EAR, etc.) I get the following warning in the server logs:



      2009-02-27 16:28:06,418 WARN  [com.arjuna.ats.arjuna.logging.arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@1b562ae




      Everything seemingly works properly, but the above warnings appear repeatedly. I do not get these warnings when I access the REST web service, only when the EJBs are invoked outside of Seam.


      How do I resolve these warnings? I know that the documentation warns that SLSB Seam components should not be instantiated from JNDI. I also realize that within the Seam application that makes perfect sense. However, can I not continue to access EJBs that I annotate as Seam components as regular old EJBs? Is it not possible to create a Seam component based on an SLSB EJB and use that bean both as an EJB and a seam component?


      My reason for using Seam, the problem I'm trying to work around is essentially this. I would like to take advantage of Seam managed persistence contexts in the REST service (to avoid LazyInitializationException when the web service marshals the response). So, accordingly, I have made by DAOs Seam components and inject a Seam managed entity manager into them. These DAOs are used by the new REST service and various other session beans in the application. Anytime one of these DAO EJBs is involved in a transaction initiated outside the REST service, I get warnings like the one above.


      My components.xml contains (managed persistence context and EJB transactions):


      <persistence:managed-persistence-context name="em" auto-create="true"
           persistence-unit-jndi-name="java:/EntityManagerFactories/Assessment2EMF"/>
      <transaction:ejb-transaction/>



      I have also properly installed the org.jboss.seam.ejb.SeamInterceptor. Everything should be configured properly.


      Any ideas? I appreciate the help.


        • 1. Re: Invoking seam component EJBs outside of seam application
          Guillaume Jeudy Master

          The way it works is if you inject using EJB3 (@EJB) annotation then only the EJB container processes the annotations on your class, any Seam specific annotation won't be processed.


          I assume that you inject your seam managed PC using @In annotation, then it will simply not be populated. If you use @PersistenceContext then it's the EJB container that will inject the entityManager (therefore you won't benefit from seam managed PC).


          I don't think you can achieve your goal. The seam context is only available from a web request. There is some very limited support from outside a web context for example, use a Seam context in an MDB (but then you don't have access to any scopes besides APPLICATION scope). I'm not 100% sure on the MDB part but I also went a similar route as you and concluded it was not feasible see: http://www.seamframework.org/Community/ReuseStatelessServicesBuiltWithSeam

          • 2. Re: Invoking seam component EJBs outside of seam application
            Guillaume Jeudy Master

            Sorry I didnt read all of your post to the end. By looking at Seam 2.0.1.GA source code installing Seam Interceptor should at least give you a temporary EVENT and APPLICATION context for the duration of the call if you are using the EJB outside a seam context. The seam managed persistence context is by default in CONVERSATION scope so I dont know how that would fare.


            In any case minimal code samples of your usecase would be welcome.