1 2 3 Previous Next 34 Replies Latest reply on Oct 15, 2013 10:29 AM by steeltomato Go to original post
      • 30. Re: JNDI Lookup of EJBs
        mdzhokanov

        I am not perfectly aware of the classloading system of JBoss 7.

         

        1) Is it possible two separate applications (EAR and WAR) to share same classloader?

        2) Is it possible for two separate applications (EAR and WAR) the WAR classloader to be child of the EAR classloader so it could see the loaded from the parent classloader JARs? (or in AS 7 the hierarchical classloading model is fully replaced with the module-dependencies classloading model?)

         

        3) If I put the Client JAR as a global module in the AS 7 'modules' folder, probably the problem will go away. However, in this case I will have to replace the JAR file in the 'modules' folder every time I recompile the Client project, which is really inconvenient option.

         


        Currently, our system structure is like the following picture and we use @Remote communication between the two apps (deployed on JBoss 6.0, because AS 7 has not implemented RMI capabilities yet), but the serializaiton of the objects is an overhead which is not desirable, specially having in mind that both applications run on the same AS and in the same JVM currently (not sure what will happen in the near future, the Front.WAR might go to another AS - that's why we keep them separated).

        Regel_apps_strcture.png

        Thanks for the quick responses!

        • 31. Re: JNDI Lookup of EJBs
          borisha

          Same problem here:

           

          Caused by: javax.ejb.EJBException: java.lang.ClassCastException: com.test.Service1Remote$$$view7 cannot be cast to com.test.Service1

                  at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:193)

                  at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261)

                  at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:402)

                  at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:57)

                  at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:43)

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

                  at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

                  at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

                  at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

                  at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)

                  ... 9 more

           

           

          Service1Remote interface is a remote interface for EJB and it extends Service1 interface.

          • 32. Re: JNDI Lookup of EJBs
            mdzhokanov

            Borisa, you should give more information about your case. What is the structure of your application? How do access the interface (via manual JNDI lookup, via injection)? Are you talking about single application, or you have inter-application communication as in my case? Are these interfaces Local or Remote?

             

            I don't know how relevant to your problem is the following information. However, assuming that you use Remote interfaces I have to let you know that you cannot expose Remote EJB interfaces in JBoss AS 7 - RMI is not supported yet. This will be implemented this November with version 7.1 (look here http://community.jboss.org/thread/168873). Meanwhile you can download and recompile the patched by Wolf version:

            I got a very preliminary patch here https://github.com/wolfc/jboss-as/tree/AS7-1658

             

            It mem leaks, so it is not useful yet. Also creation of MarshallingInvocationHandler is slow.

             

            But you can try it out to see if you run into other issues.

            ------------

            Coming back to my case, just to inform you how I managed to solve my problem. I have added the third line into the META-INF/MANIFEST.MF file of the WAR application:

             

            Manifest-Version: 1.0

            Class-Path:

            Dependencies: deployment.RegelBackendEAR.ear.RegelBackendClient.jar

            In my WAR ClassPath I have added module dependency to the Client (interfaces) JAR, which is situated in the other EAR application.

             

            If your application has dependency on external application you need to add this dependency in your jboss-deployment-structure.xml file or in your MANIFEST.MF.

            Just have in mind the format of the dependency descriptor:

             

            "For top-level deployments it's deployment.<deployment-filename>. For example, a ear deployment named myapp.ear will have  deployment.myapp.ear as its module identifier.

            For subdeployments, it's deployment.<top-level-deployment-filename>.<relativepath-to-subdeployment>. For example, if myejb.jar is packaged at the root of myapp.ear then the module identifier of myejb.jar will be deployment.myapp.ear.myejb.jar."

             

            The jboss-deployment-structure.xml looks like this:

             

            <?xml version="1.0" encoding="UTF-8"?>

            <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">

              <deployment>

                      <dependencies>

                        <module name="deployment.RegelBackendEAR.ear.RegelBackendClient.jar"/>

                    </dependencies>

              </deployment>

            </jboss-deployment-structure>

             

            Regards,

            Miroslav

            • 33. Re: JNDI Lookup of EJBs
              borisha

              Thanks Miroslav,

               

              as most people I am also surprised that remote EJBs are not supported in 7.0.1

               

              Yes, I use two applications (two ear files) and trying to inject remote EJB from ear1 to ear2, and this does not work. I did not use @EJB injection but tried to do manual lookup. What confused me is that there was CCE, and I thought it is related to bug explained in this thread.

               

              I guess we will all have to wait for 7.1.0 to do anything useful.

               

              regards

              Borisa

              • 34. Re: JNDI Lookup of EJBs
                steeltomato

                Unfortunately this issue still existed in 7.1.1. I have not tested more recent releases or the WildFly EE7 implementation. Worse, the jboss-inter-app example doesn't have a proper implementation and results in the same view error.

                 

                I just want to clarify the workaround for getting this functional in case others bump against it.

                 

                In my case, I have three modules:

                A (war)

                B (war)

                Common (jar, included in both A and B)

                 

                To get the remoting to work from A to B, my EJBs in B must implement two interfaces. One interface is annotated with @Local, is only in the war of B and is only used in B. The other is annotated with @Remote, is only in Common and is only used outside of B.

                 

                For example, if the EJB is FooImpl and the interfaces are FooL and FooR, your resource class in A would have a producer such as:

                 

                @Produces

                @EJB(lookup = "java:global/B/FooImpl!org.bar.FooR")

                private FooR foo;

                1 2 3 Previous Next