How to use concurrently different version of the same classes

Question

Hi,

I have to provide an interface to a set of web services for which I have generated the code stubs and object binding. Many of the transactions share a common object model and thus a large part of the generated code overlaps. Normally this would not be a concern as I would just re-use the same code since the wsdl would link the same xsd files.

Unfortunately here the provider of these services has separated the xsd so that each services binds to a separate set (basically a copy) of the same files. In their specification they state that the implementation of the client side should isolate each web-services for easier maintenance. Basically they want to be able to modify the xsd for a single web service while leaving all others untouched.

The question is as follows :

How could I integrate these different set of generated classes in the same program so that each services exposes their functionality without interfering with their brethren ?

One solution I thought was to create a facade for each of them that would expose the desired functionality and object model so that the actual implementation remains hidden. Then though clever use of custom class loaders each facade would load a specific jar containing the generated code for this particular service.

Any thought ? ideas ? what was your experience facing a similar problem ?

thanks

Answer 1

Have you considered using OSGi based bundles (e.g. Eclipse Equinox runtime)? Using an OSGi based implementation each set of generated classes would be in a separate bundle (.jar file) that gets its own class loader and can selectively export parts of its API to the rest of the application. So it provides a ready implementation of the solution you proposed.

Answer 2

In general, the easiest way to handle this is to use a jaxb binding file (or the -p param to CXF's wsdl2java tool) to map the generated code into a package specific for the particular service. Thus, each service would have it's own objects to work with.

The complexity would come if you have to integrate the various services. Like take the return from one to call into another. Since the objects would be completely different, you would need to write code to copy data from one to the other. Possibly not fun. :-(

Answer 3

For Java two classes are different from eachother when they are loaded by separate classloaders. You can take advantage of this by loading the 2 versions of the classes yourself from 2 URLClassLoaders which get the URL of the respective jars as classpath. You might not need to build 2 facades if both sets of objects implement the same interfaces.

update

Yes, the jars should not be on the classpath of the main application. If you set a classloader of the main application as parent to your URLClassLoaders, the classes loaded still will have access to the rest of the classpath your application uses.

For statics if they are constants they will probably be inlined by the compiler. For static variables you will get 2, 1 for each jar loaded. If those variables are used outside of the context of the jars, you will probably have to access them via reflection off their class objects. Wether you need to select one over the other or combine them depends on the application, it would be my guess that if you can load and use 2 versions in 1 application that any static variables would only be used in the context of the respective jars.