XFire
  1. XFire
  2. XFIRE-812

Problem to connect to the webservice from the OC4J Container

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      2

      Description

      I want to access an external webservice. I've generated a webservice proxy by using XFire. Every thing works fine when I run my client as a standalone client. The problem occurs when I deployed my application to the OC4J application server. The deployment works fine, but when a module tried to access the proxy via a stateful session bean (EJB 3.0), it fails.

      I've tried many different ways to make it works without success. Please help me !!!

      The error message is attached to this message.

      Please send me an email if any one have fixed it...

      I'm standing helpless rite now...

      Waiting desperately for your respons,

      Best regards,

      Victor Dieu

      1. full.txt
        5 kB
        Mark Alan West
      2. The Error Message.txt
        0.6 kB
        Victor Dieu

        Activity

        Hide
        Mark Alan West added a comment -

        To expand on the above comment, deployed EJBs don't have a orion-web.xml file. They have a orion-application.xml file. And this doesn't not allow configuration of the class loader. I guess this is what Oracle is working on?

        Show
        Mark Alan West added a comment - To expand on the above comment, deployed EJBs don't have a orion-web.xml file. They have a orion-application.xml file. And this doesn't not allow configuration of the class loader. I guess this is what Oracle is working on?
        Hide
        Mark Alan West added a comment -

        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.

        Show
        Mark Alan West added a comment - 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.
        Hide
        Mark Alan West added a comment -

        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.

        Show
        Mark Alan West added a comment - 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.
        Hide
        Tomasz Sztelak added a comment -

        I'm closing it, since we have workaround till Oracle fix container.

        Show
        Tomasz Sztelak added a comment - I'm closing it, since we have workaround till Oracle fix container.
        Hide
        Shailesh Agarwal added a comment -

        Hi Tom,

        I'm using XFire181.jar as one of the dependents of my EAR and finding the same issue as defined in this thread.
        I need to deploy this ear in a server on which I don't have any control on the "[OC4J Root]\ j2ee\home\oc4j.jar\META-INF\boot.xml" file.

        Please let me know if besides editing the boot.xml and extracting the required classes from the 181 jar, is there any other work around?

        Regards,
        Shailesh.

        Show
        Shailesh Agarwal added a comment - Hi Tom, I'm using XFire181.jar as one of the dependents of my EAR and finding the same issue as defined in this thread. I need to deploy this ear in a server on which I don't have any control on the " [OC4J Root] \ j2ee\home\oc4j.jar\META-INF\boot.xml" file. Please let me know if besides editing the boot.xml and extracting the required classes from the 181 jar, is there any other work around? Regards, Shailesh.

          People

          • Assignee:
            Tomasz Sztelak
            Reporter:
            Victor Dieu
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: