As you can see, the example is very simple. It contains two in-memory queues. You can send some text in the vm://in queue and it gets echoed out into the vm://out queue.
Fixing the testcase
Before you can run the example, there’s an error in the generated test case, that needs to be solved first (or you can skip the test when running maven of course).
The configuration for the test case, called artifactId-functional-test-config.xml is similar to the main configuration:
As an extra bonus it appends ” Received” to the input string before it is sent to the vm://out queue.
The unit test contains the following code:
public void testHelloMule() throws Exception
MuleClient client = new MuleClient(muleContext);
MuleMessage result = client.send("vm://in", "some data", null);
assertFalse(result.getPayload() instanceof NullPayload);
assertEquals("some data Received", result.getPayloadAsString());
If you run the test goal, this test case will fail on line 7. The problem is that the input string is sent to the vm://out queue, hence the synchronous result is an empty mule message. To fix this, you can either change the configuration, so that the input is not passed to the vm://out queue, like this:
In this blog i’ll develop a simple webservice using JAX-WS. I’ll first start with the contract (wsdl and xsd’s). The contract will be used for generating the necessary JAXB artifacts. Getting the webservice up and running will be a piece of cake after that all thanks to Maven and JAX-WS.
First things first, let’s create a new Maven project. I’m using Netbeans as IDE for this.
New Maven Web Application
First Create a new Maven Web Application
and call it hello_person for example
The webservice will accept a Person graph with a first and last name and will return a concatenated “Hello first name last name!”. Not very original but good enough for the example.
First we’ll define the xsd called helloPersonService.xsd for the request and response. The request will contain a Person object with a first and last name, the response will contain a Greetings string. We’ll store it in src/main/resources/xsd.
Next up is adding the necessary component to the pom file. We need the jax-ws runtime libraries, the jetty plugin as we use jetty as the servlet container, and the jaxws-maven-plugin for generating the java code from the contract. I’ve highlighted these dependencies in the pom file below.
First, let’s do a Clean and Build in NetBeans. This will generate the JAXB/JAX-WS artifacts from the contract.
Notice that the jaxws-maven-plugin has generated an interface called nl.example.hello_person.service.generated.HelloPersonServicePortType for the PortType in the wsdl. This is the interface we have to implement. The code for the implementation is pretty straightforward. I’ve added it below for convenience. Notice that the implementation class is called nl.example.hello_person.service.HelloPersonServiceImpl. We’ll need this in one of the next steps. Also notice the necessary @WebService annotation. The endpointInterface atribute points of course to the generated interface.
Notice that the implementation attribute is pointing to our implementation class.
Running the service
Add jetty:run as custom action (via Run > Set Project Configuration > Customize > Actions) and run it.
Now open a browser and check the following url http://localhost:8083/hello_person/helloPersonService. If you see the following screen, the webservice is up and running!
Testing the service
For testing I’m using the soapUI plugin for Netbeans.
After you’ve installed the plugin, you can create a new Web Service Testing Project (New Project > SOA > Web Service Testing Project)
Point the initial WSDL property to the url you’ve seen on the Web Services page: http://localhost:8083/hello_person/helloPersonService?wsdl.
The testsuite now contains a greetPerson Test Step. You can now test if the service works. If all goes well, you should see something similar to the picture below.
I recently ran into a problem when using maven resource filtering from within Eclipse. The problem was that properties in xml files (in this case a spring configuration file) weren’t expanded. Eventually i figured out what was causing the problem. That’s what this small blog is about.
As noted i wanted maven to expand some properties – datasource properties in this case – in a spring configuration file. The idea was to externalize the datasource connection information in various environment files, so that during deployment the right datasource connection information would be put in the spring configuration file according to the deployment environment, eg. local, test, staging.
For this i altered the spring conguration file, called spring-config.xml in my case, and changed the configuration for the dataSource spring bean into the one resembling the xml stanza below:
Now i used eclipse with the m2eclipse plugin and defined the following configuration for packaging the project (a web application) to a war file suitable for my local environment:
Notice the embedded Maven Runtime which is selected by default.
After running the configuration the properties for the datasource bean were not expanded and the original spring configuration file for the local deployment got packaged. I also noticed that maven properties in property text files as opposed to xml files, did get expanded. So the problem only occurred in xml files.
I noticed that running the package maven goal from a terminal window did expand the properties. So eventually i realized that the embedded maven version selected by default was the cause of distress. After i switched the maven runtime for the run configuration to the maven version currently installed on my ubuntu distribution, the problem was solved. See the picture below for this configuration.
The maven version on my ubuntu distribution, by the way, was installed via the following command:
sudo apt-get install maven2
Note that in future versions the bug in the maven embedded runtime may be fixed.
Recently I changed a seam-gen generated project into a maven project. It took me a while to get it all up and running. In this blog I’ll try to summarize all the steps needed to convert a seam-gen app (the open18 app I created in the previous blogs) into a full blown Maven project called open18_mvn2. I took the liberty to stretch the Maven pom to support deployment to glassfish as well as jboss.
Above is the list with prerequisites. Most of them are taken care of when you’ve followed all the steps in the previous blog series “Seam-gen on glassfish”.
You’ve created the seam-gen project open18;
You’ll have a mysql database up and running in which resides the open18 catalog with application data.
You’ll have a glassfish installation available in ~/opt/glassfishv2;
The necessary hibernate and slf4j/log4j libraries and the mysql-connector-java-5.1.12-bin.jar file are all available in the <glassfish_home>/domains/domain1/lib/ext directory. This can be done via the ant task gf-prepare of the seam-gen app;
A connection pool (open18Pool) together with a datasource (open18Datasource) for connecting to the mysql open18 catalog is available in the glassfish server. This datasource can be installed on the server via the ant task gf-deploy-datasource of the seam-gen app;
For this blog I added a jboss server installation and put it in ~/opt/jboss-5.1.0.GA;
See the next section for installation details;
The mysql driver mysql-connector-java-5.1.12-bin.jar is available in the <jboss_home>/server/default/lib directory;
A datasource file open18-ds.xml is available in the jboss server directory <jboss_home>/server/default/deploy for connecting to the mysql open18 catalog. This datasource can be installed on the server via the ant task datasource of the seam-gen app.
Next we’ll setup the maven project structure, wherein we will copy the necessary files from the seam-gen app.
hot: Folder for the hot deployable sources (i.e. the action classes). In the seam-gen app this is the src/hot folder;
java: Folder for the ordinary java sources (eg. the model classes). In the seam-gen app this is the src/main folder;
resources: All the resource files. In the seam-gen app this is the resources folder without the WEB-INF folder. Of all the multiple environment files, I only added the -dev files and renamed them by dropping the –dev extension. For example, i’ve renamed the components-dev.properties to components.properties.;
webap: The web-app folder containing all the view files. In the seam-gen app this is the view folder combined with the resources/WEB-INF folder;
bootstrap: The bootstrap files needed for testing with jboss-embedded. In the seam-gen app this is the bootstrap folder;
java: Folder for the test classes. In the seam-gen app this is the src/test folder;
resources: Resource files for testing. In the seam-gen app these are the resources/META-INF/persistence-test.xml, resources/components-test.properties and resources/import-test.sql files. I’ve renamed them by dropping off the -test extension.
This is the pom file with which it’ll be possible to eg. test and explode the application to glassfish and jboss. I’ve highlighted the lines which I will comment upon in this section.
the webapp directory: this includes for one the facelets and page desciptors;
the test resources directory: this will contain files like persistence.xml and components.properties;
the test bootstrap directory: this will contain the bootstrap files needed for testing with jboss embedded server.
line 330-340: maven-surefire-plugin
Make sure to add this plugin configuration, or else the tests will surely fail.
line 351-384: maven-antrun-plugin
This is a little workaround. JBoss embedded unfortunately doesn’t see the persistence.xml file in the target/test-classes/META-INF directory. It has to be in the target/classes/META-INF directory. To work around this issue, we’ll make a backup of the persistence.xml in the classes tree and replace it with the test-classes version. After the testing phase we’ll put the backed up persistence.xml file back in place.
line 390: jboss.local profile
Profile for hot deployment and undeployment to jboss.
line 425: directory.deploy.jboss
Make sure to point this to the domain folder of your jboss installation.
line 430: glassfish.local profile
Profile for hot deployment and undeployment to glassfish.
line 484: glassfish.home
Make sure to point this to your glassfish installation.
At this point your project in Netbeans should look like the picture below
5. Test class example
To check if testing (and especially persistence against the Hypersonic database) works correctly I’ve added the test class org.open18.test.CreateNewFacilityActionTest, which adds a new facility. Note that you have to be logged in first to be able to make any permanent changes:
Because the generated JPA classes all contain a catalog named “OPEN18” you need to make sure that when Hibernate is going to create the tables in the Hypersonic database you’re connected to a schema by the same name. If you don’t do this, you’ll get a bunch of “invalid schema name OPEN18” messages when running the maven test goal. Add the following line below the displayed comment
<!-- sql to call when connection is created -->
<new-connection-sql>CREATE SCHEMA OPEN18 AUTHORIZATION DBA</new-connection-sql>
7. Running the goals
Now you can test your Maven seam-gen app.
Test (Netbeans context menu) will run the maven test goal;
Run (Netbeans context menu) and selecting a server will deploy the application;
Clean (Netbeans context menu) will run the maven clean goal. When you’ve set one of the profiles (via the Set Configuration context menu) it will also undeploy the application from the server;
Profile jboss.local (via Custom goals context menu) will hot deploy the application to jboss;
Goal prepare-package with profile glassfish.local (via Custom goals context menu) will hot deploy the application to glassfish.