|
Replies:
16
-
Last Post:
Nov 9, 2009 5:40 PM
by: dsosnoski
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Broken Fault handling in Metro
Posted:
Oct 29, 2009 3:00 AM
|
|
|
I have a Fault containing a data object. If I deploy my service to Tomcat using Metro 1.5, the returned SOAP message looks like this:
<S:Body>
<S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
<faultcode>S:Server</faultcode>
<faultstring>Book already present with matching ISBN</faultstring>
<detail>
<addDuplicate:addDuplicate xmlns:addDuplicate="http://ws.sosnoski.com/library/wsdl" xmlns="http://ws.sosnoski.com/library/wsdl" xmlns:ns2="http://ws.sosnoski.com/library/types">
<book xmlns:ns8="http://ws.sosnoski.com/library/wsdl" xmlns="" isbn="0445203498" type="scifi">
<ns2:author>Cook, Glen</ns2:author>
<ns2:title>The Dragon Never Sleeps</ns2:title>
</book>
</addDuplicate:addDuplicate>
<ns2:exception xmlns:ns2="http://jax-ws.dev.java.net/" class="com.sosnoski.ws.library.metro.AddDuplicateFault" note="To disable this feature, set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system property to false">
<message>Book already present with matching ISBN</message>
<ns2:stackTrace>
<ns2:frame class="com.sosnoski.ws.library.metro.MetroLibraryImpl" file="MetroLibraryImpl.java" line="48" method="addBook"/>
<ns2:frame class="sun.reflect.NativeMethodAccessorImpl" file="NativeMethodAccessorImpl.java" line="native" method="invoke0"/>
<ns2:frame class="sun.reflect.NativeMethodAccessorImpl" file="NativeMethodAccessorImpl.java" line="39" method="invoke"/>
<ns2:frame class="sun.reflect.DelegatingMethodAccessorImpl" file="DelegatingMethodAccessorImpl.java" line="25" method="invoke"/>
<ns2:frame class="java.lang.reflect.Method" file="Method.java" line="585" method="invoke"/>
...
The Fault object returned on the client is missing any data in this case - the expected addDuplicate component of the Fault detail appears to be discarded. Is this by design?
I've verified that setting -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false on the server prevents the stack trace from being sent, and in that case the Fault data is correctly returned to the client.
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 4, 2009 1:40 PM
in response to: dsosnoski
|
|
|
This is odd behavior. Does the fromwsdl sample (that has wsdl faults) in Metro 1.5 work fine in your environment?
Also, We made some changes to embedding the stack trace in JAX-WS 2.2/Metro 2.0 due to interop issues. See https://jax-ws.dev.java.net/issues/show_bug.cgi?id=761 for more details.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 1:32 AM
in response to: ramapulavarthi
|
|
|
I've verified the behavior of the code on my system, using J2SE 1.5 which avoids any potential classpath conflicts with the 1.6 bundled versions of JAXB and JAX-WS. The Fault exception (AddDuplicateFault) is thrown with an AddDuplicate object as the faultInfo value, but this AddDuplicate object does not contain the expected book information from the Fault/detail. If I set the property on the server so that the stack trace is not included in the detail, the book information is returned as expected.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 1:49 AM
in response to: dsosnoski
|
|
|
OK, let's see if I can reproduce your environment:
- What version of Tomcat are you running exactly?
- What libraries do you have in <CATALINA_HOME>/common/endorsed, shared/lib and endorsed?
- What JDK are you using to run Tomcat?
- What JDK are you using to build service and client and run the client?
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 10:50 AM
in response to: dsosnoski
|
|
|
I can't reproduce the issue. I suspect that saaj or jax-ws implementation is picked up from somewhere other than Metro. Please run with ant -verbose and check the classpath. Is it possible to test the fromwsdl sample in Metro that has the wsdl faults?
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 1:43 AM
in response to: dsosnoski
|
|
|
I tried various JDK and Tomcat versions with Metro 1.5 and your sample application and cannot reproduce the issue. I am consistently getting this:
run:
[java] Connecting to http://localhost:8080/metro-library/
[java] Retrieved 'Infinity Beach'
[java] Retrieved 3 types:
[java] 'java' with 3 books
[java] 'scifi' with 4 books
[java] 'xml' with 2 books
[java] Failed adding 'The Dragon Never Sleeps' with ISBN '0445203498' - matches existing title 'The Dragon Never Sleeps'
[java] Retrieved 4 books of type 'scifi':
[java] 'Infinity Beach'
[java] 'Aristoi'
[java] 'Roadmarks'
[java] 'The Dragon Never Sleeps'
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 1:59 PM
in response to: ritzmann
|
|
|
I've tried it on another system with the same results. Both systems are running Mandriva Linux 2009.1. Here's the ant -verbose output from the second system:
Apache Ant version 1.6.5 compiled on June 2 2005
Buildfile: build.xml
Detected Java version: 1.5 in: /usr/java/jdk1.5.0_16/jre
Detected OS: Linux
parsing buildfile /home/dennis/devworks/jws09/configuredcode/build.xml with URI = file:///home/dennis/devworks/jws09/configuredcode/build.xml
Project base dir set to: /home/dennis/devworks/jws09/configuredcode
[property] Loading /home/dennis/devworks/jws09/configuredcode/build.properties
Build sequence for target(s) `run' is [run]
Complete build sequence is [run, compile-server, clean, generate, compile-client, build-client, package, build-server, prepare, ]
run:
[java] Executing '/usr/java/jdk1.5.0_16/jre/bin/java' with arguments:
[java] '-classpath'
[java] '/home/dennis/devworks/jws09/configuredcode/gen/bin:/home/dennis/devworks/jws09/configuredcode/client/bin:/home/dennis/tools/metro-1.5/lib/webservices-api.jar:/home/dennis/tools/metro-1.5/lib/webservices-extra-api.jar:/home/dennis/tools/metro-1.5/lib/webservices-extra.jar:/home/dennis/tools/metro-1.5/lib/webservices-rt.jar:/home/dennis/tools/metro-1.5/lib/webservices-tools.jar'
[java] 'com.sosnoski.ws.library.metro.WebServiceClient'
[java] 'localhost'
[java] '8080'
[java] '/metro-library/'
[java]
[java] The ' characters around the executable and arguments are
[java] not part of the command.
[java] Connecting to http://localhost:8080/metro-library/
[java] Retrieved 'Infinity Beach'
[java] Retrieved 3 types:
[java] 'java' with 3 books
[java] 'scifi' with 4 books
[java] 'xml' with 2 books
[java] Exception in thread "main" java.lang.NullPointerException
[java] at com.sosnoski.ws.library.metro.WebServiceClient.main(WebServiceClient.java:85)
BUILD FAILED
My JRE lib directory does not have an endorsed directory present, so nothing's coming from there.
On the server side, I'm using Tomcat 6.0.20, started via bin/startup.sh, with only the lib directory present (no common, shared, or endorsed directories).
If you monitor what's actually sent over the line, do you see the stack trace information? That seems to be the cause of the client problem in my tests, since when I disable sending the stack trace the client works without a problem.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 2:02 PM
in response to: dsosnoski
|
|
|
Oh, and this second system is a 64 bit Linux and JVM, vs 32 bit Linux and JVM on the original.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 2:07 PM
in response to: dsosnoski
|
|
|
And yet another thing - I'm using a Sun JVM downloaded directly from Sun, not the one that comes with the Mandriva installation:
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_16-b02, mixed mode)
The download file name (I keep them around for multiple installs without re-downloading) is jdk-1_5_0_16-linux-amd64.bin
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 5, 2009 3:06 PM
in response to: ritzmann
|
|
|
I've now gotten this working correctly, but I have no idea how. I tried first removing all other web applications from the Tomcat installation (there had been an Axis2 installation, as well as a couple of other Metro applications), but still saw the problem. I then reinstalled Metro and rebuilt, and the test started working - but when I compared the jars in the old and new Metro installation they were all identical, and when I switched back to the original installation of Metro 1.5 and rebuilt again it still worked.
The key difference in the XML sent over the wire is that the broken version had no namespace for the <book> element within the Fault/detail data, which did not match the schema - so that explains why the client returned a null for the book information. Anyone have any idea what could possibly have caused this namespace issue on the server, only in the case where a stack trace was being sent?
Since this appears to have been a fluke issue (definitely a server problem, but since the Tomcat installation on the second system, including web applications, was a copy of that on the first it wasn't an independent recreation of the problem), I'll remove discussion of it from the developerWorks article.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 6, 2009 7:52 AM
in response to: dsosnoski
|
|
|
My guess would be that Tomcat had picked up an outdated JAXP implementation from the Axis installation and removing Axis resolved that issue.
One thing I noticed is that you are including the Metro libraries in the web application. Generally, I would advise to install Metro in Tomcat and not include the libraries in the web application itself. The reason is that this is the only way to make sure the Metro implementation is picked up by Tomcat under JDK 6 and not the JDK internal code.
If I recall right, unfortunately the Metro 1.5 installation scripts don't support Tomcat 6. Tomcat 6 uses a different (undocumented) endorsed directory by default and the Metro 1.5 installation will miss that. Metro 2.0 does not have that issue. Metro 2.0 has not been released thus far but is very stable and well tested.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 7, 2009 2:43 AM
in response to: ritzmann
|
|
|
> My guess would be that Tomcat had picked up an
> outdated JAXP implementation from the Axis
> installation and removing Axis resolved that issue.
That sounds plausible, but surprising - Tomcat should be isolating different web applications from each other.
> One thing I noticed is that you are including the
> Metro libraries in the web application. Generally, I
> would advise to install Metro in Tomcat and not
> include the libraries in the web application itself.
> The reason is that this is the only way to make sure
> the Metro implementation is picked up by Tomcat under
> JDK 6 and not the JDK internal code.
That's one of the issues with bundling tools like JAXB and JAX-WS into the JRE, and one of the major drawbacks with using these tools rather than open source equivalents - at least if you're using J2SE 1.6 rather than 1.5.
Production environments may involve many different applications running on the same web server. It can be very difficult to change all these applications over to use a new version of a particular software component at one time. Having the jars in the web application rather than in the web server itself makes it possible to independently upgrade the applications, so generally I recommend this approach. It's certainly difficult if not impossible to use this kind of independent approach with JAXB/JAX-WS and J2SE 1.6+, though.
> If I recall right, unfortunately the Metro 1.5
> installation scripts don't support Tomcat 6. Tomcat 6
> uses a different (undocumented) endorsed directory by
> default and the Metro 1.5 installation will miss
> that. Metro 2.0 does not have that issue. Metro 2.0
> has not been released thus far but is very stable and
> well tested.
I'll definitely take a look at the improvements in Metro 2.0 when that's released. I do tend to stay with released versions of projects, though, since many organizations have a policy of only working with official releases.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 7, 2009 4:37 AM
in response to: dsosnoski
|
|
|
> That's one of the issues with bundling tools like
> JAXB and JAX-WS into the JRE, and one of the major
> drawbacks with using these tools rather than open
> source equivalents - at least if you're using J2SE
> 1.6 rather than 1.5.
>
> Production environments may involve many different
> applications running on the same web server. It can
> be very difficult to change all these applications
> over to use a new version of a particular software
> component at one time. Having the jars in the web
> application rather than in the web server itself
> makes it possible to independently upgrade the
> applications, so generally I recommend this approach.
> It's certainly difficult if not impossible to use
> this kind of independent approach with JAXB/JAX-WS
> and J2SE 1.6+, though.
FWIW...
This was precisely the issue we had last year deploying some of our first JAX-WS services on Websphere 6.1 (without its FeaturePack add-on). It was however, JDK 5. We used the JAX-WS RI 2.1.5 (not the full Metro distribution), had the build process copy the JARs from that distribution into WEB-INF/lib of the WAR file we were building. We then adjusted the WAS 6.1 classloader policy to use PARENT_LAST and classloader per WAR and we were able to successfully deploy a number of JAX-WS endpoints this way.
Another team using WAS 6.1, this time with the FeaturePack add-on that included Axis2 was not so lucky. No matter what they tried, class collisions and other issues kept occurring, preventing the endpoint from ever working.
Fortunately, it appears that with WAS 7 (JDK 6), fixes were made so that using the classloader policy adjustment, JAX-WS endpoints deployed w/ the Sun JAX-WS RI JARs in the WEB-INF/lib of the WAR itself will work along side those deployed as JAX-WS endpoint services developed using the OOTB WAS 7/JDK6 tooling that uses the built-in Axis2 runtime. The other thing that we insured was that the application build process used the wsimport and wsgen tools that were in JAX-WS RI distribution and not the IBM JDK 6 bundled in WAS 7.
Message was edited by: mcs130
Message was edited by: mcs130
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 7, 2009 5:09 PM
in response to: mcs130
|
|
|
Yes, bundling at the application server level can be just as bad as at the JRE level. Either way, you're stuck with using a particular version of the software for all your applications - and that version isn't even under your direct control. I generally prefer to just use a minimal servlet engine and then add in whatever components are necessary at the individual application level.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 9, 2009 1:55 AM
in response to: dsosnoski
|
|
|
Yes, as you know, there is not much we can do with a technology like the JAX-WS reference implementation once it is included in the JRE. Some application servers provide very fine-grained classloading options that may allow to override these classes per web application. The Servlet specification does not actually allow to override system classes per web application but that may be preferable over setting endorsed libraries for the entire server.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 9, 2009 10:54 AM
in response to: dsosnoski
|
|
|
>> My guess would be that Tomcat had picked up an
>> outdated JAXP implementation from the Axis
>> installation and removing Axis resolved that issue.
>That sounds plausible, but surprising - Tomcat should be isolating different web applications from each other.
From your earlier posts, I understand as you installed Axis on Tomcat. Though you bundle Metro libraries in Metro application, It would still up the libraries from Axis in Tomcat and not from WebApp unless you set <Loader delegate=false> in the Tomcat configuration. Did you set this?
To me it sounds like its picking up from Axis and a bug in it with handling fault messages, Can you paste the SOAP Fault message generated in that environment.
|
|
|
|
|
|
|
|
|
Re: Broken Fault handling in Metro
Posted:
Nov 9, 2009 5:40 PM
in response to: ramapulavarthi
|
|
|
When I referred to an Axis2 installation, I just meant that an axis2.war file was present as a web application, with the Axis2 jars in the .war file - not that the Axis2 jars had been added to the Tomcat classpath.
The original posting in this thread had the SOAP Fault message I was seeing generated. I later realized that the problem with the Fault was that the <book> element was somehow being written without a namespace, and hence was not recognized by the client. Setting -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false on the server eliminated the problem, which was why I thought it was caused by the stack trace information being included in the Fault/detail. And I could see from the stack trace details in the Fault that the Metro classes were being used for the actual processing, at least for those classes with stack frames.
|
|
|
|
|
java.net RSS
