Error connecting Peoplesoft webservice from a JSF application over Integrated weblogic server

[ashvini tharval]

I have a developed a simple JSF application using Jdeveloper 11g.
To this application i have added a webservice proxy which generates the proxy client which communicates with the peoplesoft webservice.
when i run the standalone proxy class, it is able to connect to the webservice and get the required data.
But as i deploy the whole JSF application (where the managed bean calls a method in the client) in Integrated weblogic server, i get an XMLStreamReaderException.
To debug this issue i deployed the war file in apache-tomcat6.0.26 with all the reqquired libraries(jsf jars) in the Lib folder, it actually worked , my jsf application was able to get the data from the webservice.
I was thinking, it could be a packaging problem of JDev, the way it creates the war file may be faulty, but i tried building the war file externally
and still it did not work.
I am not finding any links that can help me.
Any help is appreciated.

The error i get in the weblogic is
com.sun.xml.ws.streaming.XMLStreamReaderException: unexpected XML tag. expected: {http://peoplesoft.com/KCM_WEB_CASE_CI}Get__CompIntfc__KCM_WEB_CASE_CIResponse but found: {http://schemas.xmlsoap.org/ws/2002/xx/secext}Get__CompIntfc__KCM_WEB_CASE_CIResponse
avax.faces.el.EvaluationException: com.sun.xml.ws.streaming.XMLStreamReaderException: unexpected XML tag. expected: {http://peoplesoft.com/KCM_WEB_CASE_CI}Get__CompIntfc__KCM_WEB_CASE_CIResponse but found: {http://schemas.xmlsoap.org/ws/2002/xx/secext}Get__CompIntfc__KCM_WEB_CASE_CIResponse
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:475)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:756)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227

thanks in advance
Ashvini

[Ivan Krizsan]

Hi!
Try running the JBoss Tattletale tool ( http://www.jboss.org/tattletale ) on both projects to see what dependencies you have and if you are using different version of the same JAR in the different projects. In addition, you should also make sure you have no conflicts.
Best wishes!

[ashvini tharval]

I was able to resolve this issue, i recreated the web service proxy, this time for the mapping options did not create any root package for generated type, so all the datatypes were created under the same package.
After this when i ran my jsf application , it worked.

[p adams]

ashvini tharval wrote:I was able to resolve this issue, i recreated the web service proxy, this time for the mapping options did not create any root package for generated type, so all the datatypes were created under the same package.
After this when i ran my jsf application , it worked.

Is there any chance you can expand on your solution? I'm experiencing nearly the exact same symptoms in a slightly different environment. I have a feeling that the ClassLoader architecture of the application that I'm embedding a web service client is causing the issue but I'm at a dead end. It sounds as if you were able to work around the problem.

Thanks.

[ashvini tharval]

Hey,
Are you using jdeveloper to generate webservice proxies??If yes which version?
Basically i just tried different ways to generate the proxies, by selecting/unselecting certain options.
And it worked for me when i generated all the datatypes under the default package.
What kind of error are you getting??
If you can specify more details, i can explain it better.

Thanks
ash

[p adams]

No I'm not using JDeveloper I just have the same symptoms. My application is actually generated outside of an IDE using wsimport from wsdl and then re-packaged to be installed as an Eclipse plugin. Unfortunately I don't want the generated classes to be in the default package. I'm afraid the XMLStreamReaderException might be just the tip of the iceberg. I'm using JAX-WS 2.2 installed into a JDK 1.6 (webservices-api.jar in jre/lib/endorsed) and the plugin re-packages the other required classes. I'm using a jax-ws-catalog.xml for locally packaged WSDL which seems to work fine while the XML based jax-ws handler chain does not work properly (when re-packaged, works fine outside of the plugin) which implies to me that there are odd ClassLoader related issues (jax-ws-catalog is resolved from /META-INF while the handler chain is package specific which kind of re-inforces the assumption.

The other very odd thing here is that the exception message is within the "readResponse" method implying that a request has been sent to the service and a response is being read when I can verify that no request was ever sent (wireshark captures verify and altering of the URL to non-existent service never result in a connection exception).

[ashvini tharval]

Well i am not familiar with generating proxies without using jdeveloper.
But the error i was getting was due to namespace issues
Get__CompIntfc__KCM_WEB_CASE_CIResponse {http://peoplesoft.com/KCM_WEB_CASE_CI} Get__CompIntfc__KCM_WEB_CASE_CIResponse {http://schemas.xmlsoap.org/ws/2002/xx/secext}
As you see the response expects a different namespace.
To resolve this, i actually added SOAPLogHandler which will capture the request and alter the request before sending it to the webservice.
http://blog.jdevelop.eu/2008/03/08/how-to-modify-jax-ws-soap-messages/

You can download SOAPUI tool to verify how to pass the request/response.

Thanks

[p adams]

Thanks.

I have dumped the message in both directions from a handler and the really strange thing is that when the message is outbound I see the request (normal) BUT when the message is inbound I also see the request (very much not normal).

As I mentioned previously I can verify that the request object is never actually sent over the wire (I often run a man in the middle to watch the network traffic to see the SOAP on the wire). WIthin my SOAPHandler implementation the same SOAPMessage object is passed regardless of:

((Boolean)messageContext.get ( MessageContext.MESSAGE_OUTBOUND_PROPERTY )).booleanValue ()

true|false, dumping the message contents shows the request.

JAX-WS never puts anything on the wire...

[p adams]

I finally sorted out my problem which had to do with the environment I was in and attempting to use ThreadLocals from within an implementation of

javax.xml.ws.handler.soap.SOAPHandler<javax.xml.ws.handler.soap.SOAPMessageContext>

My implementation was returning false from the handleMessage method because its requirements hadn't been met.

The javadoc for SOAPHandler.handleMessage reads:
Returns:
An indication of whether handler processing should continue for the current message

* Return true to continue processing.
* Return false to block processing.

BUT what JAX-WS RI was actually doing was simply skipping the remainder of the handler chain and moving on.

This happens in:
com.sun.xml.ws.handler.HandlerProcessor.callHandleMessage (private method)
which contains the following code:
int i = start;
try {
if (start > end) {
while (i >= end) {
if (!handlers.get(i).handleMessage(context)) {
setIndex(i);
return false;
}
i--;
}
} else {
while (i <= end) {
if (!handlers.get(i).handleMessage(context)) {
setIndex(i);
return false;
}
i++;
}
}
} catch (RuntimeException e) {
setIndex(i);
throw e;
}
return true;

So when a handler returns "false" it doesn't "block processing" as the javadoc reads BUT rather it simply ignores the remainder of the handler chain and moves on. In my case the end result of this was that NO REQUEST was sent and processResponse was called with the "packet" still set to the request which results in an exception like:

com.sun.xml.ws.streaming.XMLStreamReaderException: unexpected XML tag. expected: {<NameSpace>}<Method>Response but found: {<NameSpace>}<Method>
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.verifyTag(XMLStreamReaderUtil.java:214)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.verifyTag(XMLStreamReaderUtil.java:222)
at com.sun.xml.ws.client.sei.ResponseBuilder$DocLit.readResponse(ResponseBuilder.java:591)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:121)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)

Given the code above unfortunately now this exception makes some sense though I would have to argue that this is a bug in the JAX-WS RI.