Problem to connect to the webservice from the OC4J Container

Here's the full lstacktrace....

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.

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 ?

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.

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

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?

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.

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.

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

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.