2

We have some existing Java code running on a Tomcat server that we want to allow code on another machine to execute, so we are looking into web services. I am new to web services and I think I'm probably doing something wrong here.

I have followed a few online tutorials on how to deploy a JAX-WS web service in Tomcat. I have created a web service class and annotated it with @WebService, written a web.xml and sun-jaxws.xml file, packaged those files (plus the JAX-WS jar files) into a .war file, and deployed it into Tomcat. That appears to be working, as I can load the WSDL file in a browser pointed at Tomcat.

It's the web service client I'm having trouble with. First of all, there are existing classes on the server side that get mapped into a database. We want to allow the client to use those same existing classes and create instances of out of them, invoke the web service, and then have the objects get stored into the database. However, when I ran the wsimport command against the server's WSDL file, it generated a bunch of Java classes, a lot of which are similar to our existing classes. I guess we have to use those instead of our existing classes? So much for code reuse, unless I'm confused, which is very possible.

So now I've written the client using those classes that wsimport generated. But I'm getting compile errors. Some of the fields in our existing Java classes are of type java.net.InetAddress. But for some reason, wsimport generated its own InetAddress class, and this is what it looks like:

package ems.server.webservices;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlType;
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "inetAddress")
public class InetAddress {
}

Yeah it's just a class with nothing in it! So a lot of the compile errors I'm getting say:

WSClient.java:37: setAddress(ems.server.webservices.InetAddress) in ems.server.webservices.NetworkAddress cannot be applied to (java.net.InetAddress)
    networkAddress.setAddress(InetAddress.getByName("1.1.1.1"));

I'm trying to create a java.net.InetAddress, but it wants me to use the empty class that was generated by wsimport. I must be doing something wrong here. Please enlighten me.

skaffman
  • 398,947
  • 96
  • 818
  • 769
pacoverflow
  • 3,726
  • 11
  • 41
  • 71
  • Have a look at customizing JAXB bindings. I'm not sure if it will be helpful but it sounds like you might need to use some customizations when generating the classes. http://docs.oracle.com/javaee/5/tutorial/doc/bnbbf.html – ChadNC May 04 '12 at 16:23

1 Answers1

2

We have some existing Java code running on a Tomcat server that we want to allow code on another machine to execute, so we are looking into web services

Web services for this? Why?

First of all, there are existing classes on the server side that get mapped into a database. We want to allow the client to use those same existing classes....So much for code reuse

Really bad idea. The purpose of Web Services is not code-reusability but interoperability. Trying to reuse business classes that actually carry the semantics of the programing language you are using, is not only a bad practice but can lead you to many issues unless for most trivial web services where you also control the client.

when I ran the wsimport command against the server's WSDL file, it generated a bunch of Java classes

When you run the wsimport all the necessary artifacts required for the web service client to communicate to the web server are created. This includes all the stub classes that help in transforming your classes during the SOAP marshalling/demarshalling

But I'm getting compile errors. Some of the fields in our existing Java classes are of type java.net.InetAddress

java.net.InetAddress is a Java specific class. You should not be exposing that in the first place. That is why the code generator creates the empty java.net.InetAddress.

To be honest I can not give you a direct answer for making this work. The only I hint could give you is that if you annotate the InetAddress fields with @XmlTransient they will not be exposed in WSDL and you will not have that problem. Of course, you don't say if this field is needed for you so, perhaps my suggestion is useless to you.

But my recomendation is to switch your approach. You are on the wrong path IMHO. The only recomendation is to change your approach.

Cratylus
  • 52,998
  • 69
  • 209
  • 339