Rickard Lundin recently asked this question: "I need to be able
[at] "runtime" to choose wsit config file. One way would be to have multiple "WEB-INF/..xml" and add exactly one of them to the jvm classpath."
There are at least two ways to approach that question. The approach we designed the WSIT configuration for is that you know all your services that you are talking to in advance. That is a reasonable assumption since you need to know the structure of the SOAP messages, etc. to talk to a web service anyway. If you already know the service you are going to talk to, you can do the WSIT configuration before deployment. So the first approach boils down to:
Configuring multiple WSIT web services or clients at once
Creating and configuring multiple web services has been designed into WSIT from the beginning. The WSIT tutorial has an extensive example how to configure one web service without the help of NetBeans. The important aspect of this example is that it uses a configuration file named
wsit-fromjava.server.AddNumbersImpl.xml. The configuration file is named after the web service implementation class. That makes it very easy to configure multiple web services. Simply add a configuration file for each service.
The web service client is only slightly more complex to configure. A client has no notion of an implementation class. Thus it always searches for the configuration file
wsit-client.xml on the class path. So what do you do when you have multiple clients and all pick up the same configuration file? The solution is to simply put the configuration for all clients into the same file. NetBeans actually does that for you already and it is easy to take the same approach manually. NetBeans generates a
wsit-client.xml that looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<import location="EchoService.xml" namespace="http://service.echo.ws.xml.sun.com/"/>
The actual configuration is contained in the file EchoService.xml. That makes it very easy to configure clients for additional web services. Simply add more import statements to the
Now while the above covers most use cases, we ran into a problem with Open ESB. Open ESB builds composite applications, which ultimately means in our case that it bundles web services inside an application inside a composite application. Consequently, looking up our configuration files from the class path did not work anymore because the files were inside a bundle on the class path. So we had to create a proprietary extension to:
Pass configuration file location into WSIT
Note that the following is an unsupported extension to WSIT and the interfaces may change any time without notice. Moreover, the same mechanisms are used to pass servlet data into JAX-WS and you are likely introducing unpleasant side-effects if using this when running a web service as a servlet.
On the client side, you need to create a client by using the
create(URL wsdlDocumentLocation, QName serviceName, WSService.InitParams properties) method on
WSService. The method returns a
Service object that you can use like any ordinary web service client. The
properties parameter takes a
Container that you need to implement and set as parameter. This
Container, when invoked with
getSPI(Class<ResourceLoader> ResourceLoader.class), has to return an implementation of the
ResourceLoader interface. Finally, the
ResourceLoader will be invoked by the
getResource("wsit-client.xml"). That is the point where your application can return a URL to the file it wants WSIT to read. Your file does not have to be named
The implementation on the web service side is pretty similar. Instead of
WSService you need to use one of the two
create methods on
WSEndpoint to create your service. All the create methods take a
Container as parameter. From there on the implementation is similar to the client. The
getResource call will of course be invoked with the name of the server-side configuration file WSIT is looking for.
Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT