8 Replies Latest reply: Nov 11, 2009 1:59 PM by 733806 RSS

    OC4J & XFire

    552795
      Howdy!

      I have a simple Web Service Client that I've generated from Xfire. From within my IDE (IDEA) the Client runs without any problems. However, if I try to run the Client from within an OC4J instance I get a NoSuchMethodError exception.

      This also happens with other Xfire clients we are working with. My guess is that there's some kind of classpath conflict, especially seeing as the client works fine in a standalone setting.

      Can anyone help?!

      The stacktrace follows:

      20.des.2006 17:55:11 oracle.j2ee.rmi.RMIMessages EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER
      WARNING: Exception returned by remote server: {0}
      javax.ejb.EJBException: java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;; nested exception is:
           java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;; nested exception is: oracle.oc4j.rmi.OracleRemoteException: java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;; nested exception is:
           java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;
      oracle.oc4j.rmi.OracleRemoteException: java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;
           at com.evermind.server.ejb.EJBUtils.getUserException(EJBUtils.java:346)
           at com.evermind.server.ejb.interceptor.system.AbstractTxInterceptor.convertAndHandleMethodException(AbstractTxInterceptor.java:69)
           at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:52)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
           at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
           at DisclosureNewsService_RemoteProxy_12ljjfe.submitNews(Unknown Source)
           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:585)
           at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
           at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
           at java.lang.Thread.run(Thread.java:595)

           Nested exception is:
      java.lang.NoSuchMethodError: javax.jws.WebService.portName()Ljava/lang/String;
           at org.codehaus.xfire.annotations.jsr181.Jsr181WebAnnotations.getWebServiceAnnotation(Jsr181WebAnnotations.java:50)
           at org.codehaus.xfire.annotations.AnnotationServiceFactory.create(AnnotationServiceFactory.java:170)
           at org.codehaus.xfire.service.binding.ObjectServiceFactory.create(ObjectServiceFactory.java:353)
           at com.omxgroup.cds.newsws.DisclosureNewsServiceClient.create0(DisclosureNewsServiceClient.java:59)
           at com.omxgroup.cds.newsws.DisclosureNewsServiceClient.<init>(DisclosureNewsServiceClient.java:26)
           at no.hugin.webservices.clients.omx.DisclosureNewsServiceHelperImpl.submitNews(DisclosureNewsServiceHelperImpl.java:59)
           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:585)
           at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:50)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
           at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
           at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
           at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
           at DisclosureNewsService_RemoteProxy_12ljjfe.submitNews(Unknown Source)
           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:585)
           at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
           at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
           at java.lang.Thread.run(Thread.java:595)


      Mark.
        • 1. Re: OC4J & XFire
          Avi Abrami
          Mark,
          A "NoSuchMethodError" usually indicates version incompatibilities.
          I'm only guessing, but I think you need to be using the latest OC4J -- 10.1.3.1.0 -- in order for this to work.
          Excuse me, but I could not ascertain from your post the version you are using.

          Good Luck,
          Avi.
          • 2. Re: OC4J & XFire
            18475
            Hello,

            You are both correct, it is a classloader issue, and my guess is you are using a OC4J 10.1.3.x release since javax.jws.WebService.portName is signature for the JSR 181 annotations that is not available in earliest release.

            OracleAS and XFire are not using the same exact release of 181, Oracle is using M1 and XFire update 2, so the signature of the @WebService.portname are different.

            If you are using the XFire client from a Web Application the easiest way to solve this issue is to use the classloader option "Search Local Classes First" available in the deployment plan when you deploy the application.
            But it looks like you are using it from an EJB, can you confirm? In this case you may hit a known issue that we are currently fixing regarding the class loader configuration.

            Regards
            Tugdual Grall
            • 3. Re: OC4J & XFire
              552795
              Good morning!

              Thanks for all the answers so far!

              Tugdual - you are correct, we are accessing the Web Service from an EJB.

              Client --> EJB --> XFire Web Service Client --> Remote Service

              Note that we have wrapped the EJB and Web Service Client in the same jar. I don't know if this makes any difference.

              As for checking the "Search Local Classes First" option we have tried that but have had no success. I'll try again when I get access to my laptop again.

              As for the version of OC4J, I can't check right now (no access to laptop) but I downloaded the latest version two days ago from oracle.



              Mark.
              • 4. Re: OC4J & XFire
                552795
                One more thing - if this is a known issue in regards to the classloader, can you suggest a workaround? Or do we need to wait for the fix?

                Thanks again,


                Mark.
                • 5. Re: OC4J & XFire
                  552795
                  Temporary fix made as follows:

                  Basically I've taken the two class libraries that mismatched, and spliced them together into a new class library that contains all the classes needed to run the XFire Web Service from OCFJ. I then replaced the original class library with this modified version.

                  Class Library Notes

                  The library is composed as follows:

                  Jws package - taken from the "xfire-jsr181-api-1.0-M1.jar" file distributed with Xfire 1.2.2.
                  Xml package - taken from the "jws-api.jar" file distributed with OC4J 10.1.3.1.

                  There is still some more work to be done with this new library. I would like to rename it so that it won't be mixed up with the existing "jws-api.jar" file. In addition further tests will be required to see if this solution causes problems on different platforms and so on.

                  Comments?

                  Mark.
                  • 6. Re: OC4J & XFire
                    552795
                    Good morning!

                    I have a better solution to this problem.

                    At startup OC4J loads a set of libraries that are not visible as shared libraries. These include the “jws-api.jar” library. This is controlled from the “[OC4J Root]\ j2ee\home\oc4j.jar\META-INF\boot.xml”.

                    This jar conflicts with the XFire "xfire-jsr181-api-1.0-M1.jar".

                    To resolve the XFire / Oracle issue, you can edit this boot.xml file. Add the full path to “xfire-jsr181-api-1.0-M1.jar” to this file. It should appear before the “jws-api.jar” library. An example of how this will look can be found at the bottom of this email.

                    This is a much better solution that the one I found yesterday as it makes no changes to the “jws-api.jar” library. In addition, both types of JSR 181 classes are available from the class path.

                    Once again, this solution will require testing to ensure that it doesn’t break other functionality, and it should be considered a temporary solution until Oracle makes the required changes to OC4J.


                    Mark
                    • 7. Re: OC4J & XFire
                      18475
                      Hello Mark,

                      The know issue that i was talking about is about this configuration explicitly.
                      But it is not supported to modify the boot.xml

                      Please send me your email address: tugdual[dot]grall[at]oracle[dot]com and we can discuss this issue privately.

                      Regards
                      Tugdual Grall
                      • 8. Re: OC4J & XFire
                        733806
                        Has AnyBody found the solution?

                        I got the same problem here.

                        Thanks in advance,
                        Thiago Valverde