Issue Details (XML | Word | Printable)

Key: XFIRE-812
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Tomasz Sztelak
Reporter: Victor Dieu
Votes: 1
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
XFire

Problem to connect to the webservice from the OC4J Container

Created: 20/Dec/06 11:14 AM   Updated: 16/Jan/09 04:48 AM   Resolved: 03/Jan/07 07:43 AM
Return to search
Component/s: None
Affects Version/s: 1.2.3
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Text File full.txt (5 kB)
2. Text File The Error Message.txt (0.6 kB)



 Description  « Hide

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



Mark Alan West added a comment - 20/Dec/06 11:52 AM

Here's the full lstacktrace....


Mark Alan West made changes - 20/Dec/06 11:52 AM
Field Original Value New Value
Attachment full.txt [ 24765 ]
Mark Alan West added a comment - 21/Dec/06 01:10 AM

Comments from Tugudal Grall, Oracle:

"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."

I'll update more later... hopefully someone else can save time if I document this properly.


Tomasz Sztelak made changes - 21/Dec/06 08:55 AM
Assignee Dan Diephouse [ dandiep ] Tomasz Sztelak [ tomeks ]
Tomasz Sztelak added a comment - 21/Dec/06 10:02 AM

I added page http://docs.codehaus.org/display/XFIRE/OC4J+10.1.3.x to http://xfire.codehaus.org/Application+Server+Support. Can somebody add any exact info how and where this option should be set ?


Mark Alan West added a comment - 21/Dec/06 10:29 AM

Heya!

When deploying Applications via the OC4J Web Interface, you'll come to a "Deploy: Deployment Settings" page. From here you can click on "Configure Class Loading".

If you are deploying a Web Application you can select the "Search Local Classes First" option. However, if you are deploying an EJB or other application, this option is not given.

Therefore this fix only works for WAR deployments.

I am working on finding a solution for EJB deployments.

Mark.


Mark Alan West added a comment - 21/Dec/06 10:32 AM

One more thing - you can also set this directly in the application configuration as follows:

If you are using tag library JAR files at the application level that are intended to supersede JAR files in the well-known tag library location (global level), then you must set the application loader to search local classes first. You can do this through the following setting in your application's orion-web.xml file:

<web-app-class-loader search-local-classes-first="true" />


Mark Alan West added a comment - 21/Dec/06 10:38 AM

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?


Mark Alan West added a comment - 21/Dec/06 01:03 PM

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.


Mark Alan West added a comment - 22/Dec/06 03:39 AM

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.


Tomasz Sztelak added a comment - 03/Jan/07 07:43 AM

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


Tomasz Sztelak made changes - 03/Jan/07 07:43 AM
Resolution Won't Fix [ 2 ]
Status Open [ 1 ] Closed [ 6 ]
Shailesh Agarwal added a comment - 16/Jan/09 04:48 AM

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.