OSGi applications use bridging to CXF-related issues that are encountered when a war package is deployed on WebSphere

It turns out that our programs are based on the Equinox architecture, but later, because of the need to implement the deployment of the war package in the middleware, the implementation of the eclipse-provided bridging approach is used.

There's time behind the bridged part. I write an article specifically, please refer to the Eclipse official documentation for an ambiguous temporary. The main point here is that the bridge has been successfully bridged. However, you are experiencing problems when using CXF.

Originally in other middleware run a good program, one put into the websphere_v8, on all kinds of error. are related to Axis2, but our project does not use AXIS2. Instead, use CXF.

The error is similar to the following example (I have 3 environments.) Each newspaper's fault is different, but it is very obvious that should not appear in the Axis2):

Java.lang.ClassCastException:org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler incompatible with Org.apache.cxf.frontend.ClientProxyat org.apache.cxf.frontend.ClientProxy.getClient (clientproxy.java:93)

Later, the data found that WebSphere has its own JAXWS engine. You can see that there are three jar packages under $was_home/endorsed_apis:

javax.j2ee.annotation.jarjaxb-api.jarjaxws-api.jar//version:2.2

Then there are org.apache.axis2.jar under the $was_home/plugins.

For example, you realized that MyService inherited the Javax.xml.Service.

So in the service construction method we can see:

Protected Service (Java.net.URL wsdldocumentlocation, QName serviceName) {        delegate = Provider.provider (). Createservicedelegate (wsdldocumentlocation,                serviceName,                this.getclass ());    }

It is this provider.provider () that gets the provider implementation that is always the implementation of axis, not the implementation of our CXF.

I. GENERAL Solutions

The official documents for CXF and IBM were queried. The resulting solution is as follows:

References

Lang=en ">http://www-01.ibm.com/support/knowledgecenter/SS7JFU_7.0.0/com.ibm.websphere.express.doc/ info/exp/ae/twbs_thirdparty.html?lang=en

And

http://cxf.apache.org/docs/application-server-specific-configuration-guide.html# Applicationserverspecificconfigurationguide-forwebsphere6.1.0.29+,v7andv8

1. Turn off the JAXWS engine that comes with WebSphere. There are two levels of settings:

Server level:

In the console interface, go to Application Server > Server1 > Process definition > Java virtual machine . Then increase the number of common JVM parameters

-dcom.ibm.websphere.webservices.disableibmjaxwsengine=true

Or go to custom properties again. Add a custom attribute Name=com.ibm.websphere.webservices.disableibmjaxwsengine, Value=true.

For an app:

In the meta-inf/manifest of your war pack. MF Adds Disableibmjaxwsengine:true, like this

2. Set your app's ClassLoader policy to Parent_last

Enterprise Applications > $YOUR _app > class loading and updating tests

Set the class loader order to Parent_last

Enterprise Applications > $YOUR _app > Module management > $YOUR _module, set the class loader order to Parent_last

The last class loading strategy for another place (to verify if this is required.) Some articles do not say this place):

Application Server > Server1. Set the class loading mode to Parent_last

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvytq3nzk5nw==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast ">

These are the solutions that IBM and CXF officially provide.

And then found some other options on the Web:

1. Remove Org.apache.axis2.jarH or remove ' meta-inf/services/javax.xml.ws.spi.provider ' from Org.apache.axis2.jar

This is more violent and will have an effect on the whole of was.

2. Switch to

Instead of the original

MyWebService SS = New   

2nd Article I tried, reported MyWebService is not a interface mistake. No details to follow what the reason.

All the ways that can be found on the internet have been tried without fruit and have to be analyzed by themselves.

Second, the way of bridging the special place

JAX-WS uses the service Provider Interface (SPI) mechanism to define the API for the upper layer. The implementation is then loaded by the provider class into different implementations.

First look at the JAX-ws loading sequence:

JAX-ws loading order Javax.xml.ws.spi.Provider Provider ()

• If A resource with the name of META - Inf/services/javax.xml.ws.spi.provider

    = Com.sun.xml.ws.spi.ProviderImpl

• $java. Home/lib/jaxws.properties,it contains an entry whose key is Javax.xml.ws.spi.Provider
• If A System property with the name Javax.xml.ws.spi.Provider
• Default is loaded (Com.sun.xml.internal.ws.spi.ProviderImpl)

Javax.xml.bind.Contextfinder.find

• jaxb.properties (key= javax.xml.bind.jaxbcontext
• system Property With name Javax.xml.bind.JAXBContext
• meta - inf/services/ Javax.xml.bind.JAXBContext  
• Default is loaded (com.sun.xml.internal.bind.v2.ContextFactory)

|_meta-inf    |_services        |_ javax.xml.bind.JAXBContext (com.sun.xml.bind.v2.ContextFactory)

Jaxws-api must be WebSphere, and after we've closed the ibmjaxwsengine and changed ClassLoader strategy in accordance with the official documentation, he's always loaded into the axis2 that comes with WebSphere. , so the Provider.provider () is in the search for provider implementations. There is no CXF package found in our application, which is related to the way OSGi bridging, and students using such a way should know what the folder structure is.

So, the solution is to put a cxf.jar in the war/web-inf/lib. And then no more axis2 came to haunt us.

Here is a problem, the Lib package has a Cxf,eclipse plugin folder also has a cxf.

Will there be a class conflict when using it?

Assuming that the cxf of Eclipse's plugin folder is removed directly, the various bundles depend on the error when booting. So the outside of a cxf, inside a CXF will not have a conflict?

The answer is no.

Because I deleted the contents of the CXF package under Lib. There are only a few files left in meta-inf/services/. can also be executed normally.  So it can be seen that the classes loaded into the execution should also be classes in CXF in Eclipse's plugins. The class that is loaded into CXF is loaded into the plugins in eclipse, and the classes in the equinox are loaded from the classloader of the bundle. Assuming it is loaded with the module or the classloader above, there is only cxf empty package in Lib, and no detailed class. This class is definitely not loaded. So, since it can be loaded in such a situation, it means that it was loaded from the classloader of the bundle.

Just for the sake of insurance. The solution to this step is:

Copy the Meta-inf/services folder in the CXF into a jar package and place it under the war/web-inf/lib folder.

OSGi applications use bridging to CXF-related issues that are encountered when a war package is deployed on WebSphere