Java Reference
In-Depth Information
CLEAN SERVICE CLIENTS
If you're creating a client, the Metro JARs need to be included on its classpath or unjared into your
client JAR. In Maven 2, you can do this using the compile or default scope for the dependency.
But if you're creating a service application, it's a little different. You need to specify a dependency
scope of provided if you are deploying to Glassfish because Glassfish already includes these JARs
and the classloader will choke on the shell game because it won't be able to find other dependencies.
In other containers, use their vendor-specific extensions.
Now when you deploy your projects, they'll know to interpret the annotations and create a
service for you.
Overall, the idea is this: you create a parent so that you have a place to build that creates the
entire world for you with a single click. It builds the service first, then deploys it, and then
builds the client, using the freshly deployed WSDL.
With your JUnit tests, make sure that you test in both the service and client projects. Hope-
fully, this will seem obvious. But the confusion here can stem from our tendency to think that
the web service project must be tested as a web service because that is what's being built.
But that would require testing after deployment, which goes against the grain of how Maven
works. It's easy enough to get the results you want by following Maven conventions.
Basically, because the deploy phase happens after the test phase, your service project build
should test the code directly, as regular Java code, not the code deployed as a web service
with a WSDL. To do so, you can make use of mock objects. The Jakarta Commons project is
helpful here. It allows you to mock JNDI calls and make connections to a database defined as
a DataSource in your container. That will make sure that the Java code is thoroughly tested
(you can use Cobertura from http://cobertura.sourceforge.net/ to see just how much). The cli-
ent project will then execute its tests against the live, freshly deployed service.
Creating the service project
The service project is just a regular EAR or WAR project, depending on whether you're using
an EJB or a servlet for your service implementation. The only thing to note is that you want
to make the service artifact deploy automatically at build time, so that when the client builds
too, it can read the new WSDL and get the new implementation of the service. You do that as
you would with any regular WAR or EAR. If you're using Glassfish, here's a good plug-in to
use:
<plugin>
<groupId>org.n0pe.mojo</groupId>
<artifactId>asadmin-maven-plugin</artifactId>
<version>0.1</version>
Search WWH ::




Custom Search