Skip to main content

Mapping JAXB to existing classes on client side

5 replies [Last post]
Joined: 2007-04-06

I have a WebService SEI based on existing java code using JAX-WS.
I generate the WSDL for the client part, and get the artifacts for the service and
associated data model.
When I generate client based code with wsimport (given the WSDL generated from server side), I cannot find out how to use existing classes available on my client : my client is based on RCP from eclipse and uses the EMF model, thus on client side I get this kind of code.

My very basic datamodel defines a Person.
A Person is defined by its interface :
public interface Person extends EObject {
String getName();
void setName(String newName)

An implementation of this person using EMF is :
public class PersonImpl extends EObjectImpl implements Person {
public void setName(String newName) {
String oldName = name;
name = newName;
if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.SET, PersonmodelPackage.PERSON__NAME, oldName, name)); }

The setter implements the observer design pattern widely used in RCP.

A factory is defined to create instances of Person :
public interface PersonmodelFactory extends EFactory {
Person createPerson();

And as you guess I have an implementation of this factory.

I tried to use custom JAXB bindings on client side with no success, I had a look at sample type_substitution provided with jax-ws RI but did not found a solution either.

So my question is, is there a way to generate client side artifacts excluding web method parameters ?
I would like to use my own PersonImpl and prevent wsimport to generate the file (other files wrapping input/output parameters of Web Service method being still generated). If this is possible, will I have to annotate manually my class PersonImpl to help JAXB for marshalling process ?

Thanks in advance,

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-09

The first question is whether EMF objects are JAXB bindable. I kind of doubt if they are.

Joined: 2007-04-06

I would like to know whether it is possible to generate with wsimport client classes with the following custom file :

If my understanding of JAXB is accurate, wsimport should generate interfaces and implementations classes, providing a factory to create the objects.
My idea is to make my EMF object implement the Person interface, add the needed annotations and provide my own implementation for the factory.
Of course the PersonEMFImpl will inherit fields from org.eclipse.emf.ecore.impl.EObjectImpl.
Please tell me if this scenario is correct or if the JAXB layer will not support this : I cannot add annotation to the class org.eclipse.emf.ecore.impl.EObjectImpl.


Joined: 2003-06-09
Joined: 2007-04-06

I keep on trying to apply the exposed scenario namely trying to generate client side interfaces and provide my own implementation classes.
The generated Web Service interface references the implementation factory:
public interface PersonneWebService {[/i]
I then implement my own ObjectFactory that creates and manually annotate EMF classes
@XmlType(name = "personne", propOrder =[/i]
It still get into trouble for very specific mapping like EList entity built by a specific factory but I hope I will find a solution.

I tried using JAXB plugin mechanism but found that plugin does not help for customization. Only a subset of generated classes is manipulated:
GetPerson, GetPersonResponse and Personne. No chance to manipulate PersonneWebService and set annotation to my own ObjectFactory.

Joined: 2003-08-27


I would be very interested in knowing how to do this as well!

Although in my case the problem is that I have two different web services that happen to use the same value objects and now those value objects get generated two times, once for each web service.

I used @XmlType to set a namespace for all of those shared value objects hoping the client code generator would be smart enough to generate only one version of each, but alas, no.