Showing posts with label Metro. Show all posts
Showing posts with label Metro. Show all posts

Tuesday, November 16, 2010

Metro : Jax WS incompatibilities with Netbeans

Using Netbeans 6.9 and Tomcat 6 with JAX WS via Metro and Java JDK 6 on Windows.

The Tomcat installation is the one that is loaded as part of Netbeans.

When you try and invoke the web service, you get a string of errors e.g.

java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String


The basic problem seems to be that the versions of JAX WS bundled with Netbeans / Java / Tomcat are incompatible.

(Metro provides JAX-WS 2.2 while Java SE includes JAX-WS 2.1. If you want to run Metro applications outside Tomcat, you will need to use the endorsed standards override mechanism. For more details see:

http://java.sun.com/javase/6/docs/technotes/guides/standards/index.html)

There are literally hundreds of articles etc. all over the web about how to fix this problem with tips about installing file x into the endorsed directory, the common/endorsed directory, updating Tomcat, updating Java etc. etc.

I tried a heap of them and none of the ones I tried fixed the problem. This is Google search at it's worst - tons of articles, all different, none of which appeared to work and utter frustration.

To complicate the issue, it you don't back out the failed change, you run the risk that the next change won't work because you didn't start from a known point.

To complicate things further, some of these changes partly work which means that next time you simply get a different error message and you have to start the process all over again.

Eventually, I went back to the source i.e. Metro and JAX WS.

I came across this article:

Creating a WSDL-first web service with Apache CXF or GlassFish Metro

which pointed me to:

Using JAX-WS 2.x / Metro 1.x/2.0 with Java SE 6

So, download Metro 2 - refer Metro 2.0

Ensure Netbeans and Tomcat are shut down.

Sort the zip file by path.

You do not need to extract all the files. You only need:

metro-on-tomcat.xml and all the jar files under /metro/lib and /metro/osgi.

Extract these to a directory.

Ensure you have ant installed.

Open a command prompt and navigate to the directory that you have just extracted the files to.

Type:

...\metro>set CATALINA_HOME=x:\Program Files\Apache Software Foundation\Apache Tomcat 6.0.26

i.e. the path where Tomcat 6 is installed

where ... is the directory that the files were extracted to.

Then run:

ant -f metro-on-tomcat.xml install


which produces:


Buildfile: metro-on-tomcat.xml

catalinahome-test:

init:

uninstall:

update-catalina-props:

test-api:

check-api:

install-api-tomcat5:

install-api-tomcat6:
[mkdir] Created dir: x:\Program Files\Apache Software Foundation\Apache Tomc
at 6.0.26\endorsed
[copy] Copying 2 files to x:\Program Files\Apache Software Foundation\Apach
e Tomcat 6.0.26\endorsed

install-api-tomcat:

install:
[echo] Installing Metro 2.0 FCS for x:\Program Files\Apache Software Founda
tion\Apache Tomcat 6.0.26 ...
[mkdir] Created dir: x:\Program Files\Apache Software Foundation\Apache Tomc
at 6.0.26\shared\lib
[copy] Copying 4 files to x:\Program Files\Apache Software Foundation\Apach
e Tomcat 6.0.26\shared\lib
[echo] ... installation complete.

BUILD SUCCESSFUL


The two files copied to the \endorsed directory are :

jsr173_api.jar and webservices-api.jar


The four files copied to the \shared\lib directory are:

webservices-extra.jar, webservices-extra-api.jar, webservices-rt.jar and webservices-tools.jar


In addition, the script updates catalina.properties in the \conf directory. It changes:

shared.loader=


to

shared.loader=${catalina.home}/shared/lib/*.jar


And that, believe it or not, is that!

Problem solved!

If you want to back the change out, run:

ant -f metro-on-tomcat.xml uninstall


For completeness, if you want to enable JAX-WS 2.2 for all applications running under Java SE 6, you may run the command:

ant install-api


That command will copy the file webservices-api.jar to ${java.home}/lib/endorsed.

(The command needs to be run by a user that has the permissions to copy files into ${java.home}/lib/endorsed.)

Note that I didn't need to do this.

Enjoy!

Thursday, January 28, 2010

Metro : Printing / dumping out the contents of a SOAP packet

I've used Metro a lot and I've always battled to have decent logging.

In the web service, I normally log all the inputs and the outputs and all the exceptions. Wouldn't it be easier if you could just log all the requests and responses which would guarantee that you had all the information all of the time?

I just couldn't figure out how.

Until I came across "MessageDumpingFeature". You find this in the Glassfish \lib directory in the webservices-rt.jar file.

If you've generated web services using Metro, you find the code below very familiar. All you really need to do is replace:

service.getWebServiceName();

with

service.getWebServiceName(messageDumper);

The code looks like:

 

import com.sun.xml.ws.assembler.MessageDumpingFeature;

... snip ...

messageDumper = new MessageDumpingFeature();

ServiceName service = new ServiceName();
WebServiceName port = service.getWebServiceName(messageDumper);
// TODO initialize WS operation arguments here
java.lang.String xxx = "yyy";
java.lang.String yyy = "zzz"
// TODO process result here
ResultName result = port.doWebService(xxx, yyy);

String request = messageDumper.nextMessage();
String response = messageDumper.nextMessage();

System.out.println (request);
System.out.println (response);

... snip ...

} catch (Exception ex) {
String request = messageDumper.nextMessage();
String response = messageDumper.nextMessage();

System.out.println (request);
System.out.println (response);
}


It prints out both normal responses and SOAP Faults.

A request would be dumped like:

 
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:doWebService xmlns:ns2="http://namespace/">
<xxx>yyy</xxx>
<yyy>zzz</yyy>
</ns2:doWebService>
</S:Body>
</S:Envelope>


A valid response would be dumped like:

 
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:doWebService xmlns:ns2="http://namespace/">
<return>
<aaa>bbb</aaa>
<bbb>ccc</bbb>
</return>
</ns2:doWebService>
</S:Body>
</S:Envelope>


A SOAP fault would be dumped like:

 
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
<faultcode>S:Server</faultcode>
<faultstring>SomeErrorString</faultstring>
<detail>
<ns2:SomeException xmlns:ns2="http://namespace/">
<message>SomeErrorMessage</message>
</ns2:SomeException>
</detail>
</S:Fault>
</S:Body>
</S:Envelope>


Of course, instead of dumping out the request / response, it could be written to a file instead.

Enjoy!

Tuesday, January 05, 2010

Metro : Sniffing the traffic with JAX-WS, Netbeans and Metro

I often use Fiddler to view / log browser traffic.

From the web site: "Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language."

However, it doesn't work when you want to look at Java web service (SOAP) traffic generated by the JAX-WS support in Netbeans (i.e. Metro).

I have a number of command line tools that I use to generate various types of traffic with a command line like:


java -jar SomeProgram.jar


To get Fiddler to work, you need to change the command line to:


java -DproxySet=true -DproxyHost=127.0.0.1 -DproxyPort=8888 -jar SomeProgram.jar


Fiddler uses port 8888 as default.

Enjoy!

Tuesday, October 20, 2009

Metro : JAX WS catalogue

One of the problems with using Netbeans to generate web services using Glassfish / Metro is that when you want to create a new Web service client, you are asked to select the web service which is normally on your local machine.

This means that the web service has an address like http://localhost:8080 and it then becomes a problem when you deploy to other environments.

One way around this is to use a catalog to resolve the addresses at run time. The file is called jax-ws-catalog.xml and it's placed in the META-INF directory.

It looks like e.g.

 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
<rewriteSystem
systemIdStartString="http://localhost:8080/"
rewritePrefix="http://some url:some port/"/>
<rewriteURI
uriStartString="http://localhost:8080/"
rewritePrefix="http://some url:some port/" />
</catalog>


This searches for any URL that starts with "http://localhost:8080/" and replaces this with "http://some url:some port/" e.g.

http://localhost:8080/webserver/WebService

becomes

http://some url:some port/webserver/WebService

The ant build files in Netbeans use the -catalog option to point to a file called catalog.xml in the project root directory. You can apply the same principles to this file to resolve addresses at compile time.

Some useful links:

Using a JAX-WS Catalog

How to write an XML catalog file

Global URI re-writing with jax-ws-catalog

Enjoy!