1. Transfer the war or ear file to the remote machine
2. Run a script on the remote machine

Actually it isn't doing anything JBoss specific, so you could use it for other application servers too (like Tomcat, at least when they are using hot deployment).
To perform step 1 you have to add the following plugin in your 'pom.xml':

And this plugin needs the 'distributionManagement' section to be filled like this:

The second step is a bit more complicated. I want to execute a script on the remote server using SSH. This can rather easily be done by using an Ant target, so to get this working in Maven we have to use the plugin to run an Ant target. It will ook like this:

Thta's it. These two plugins together do the job. For completeness I show the used properties that I have setup in my 'settings.xml':

And the script that is executed at the remote server 'deploy_web.sh':

If all this is in place you can deploy the ear/war file by using the command:
mvn clean deploy
Like I said before there is nothing JBoss specific to this and actually I am using the script to deploy my Mule applications to our Tomcat server.

• Modify the pom

Because we are not testing against JBoss anymore we don't need all the dependencies in the pom anymore, only the dependency for OpenEJB and the ones to use Hibernate. This makes the pom of the ejb module look like:

PLAIN TEXT
XML:
1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2.   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
3.     <modelVersion>4.0.0</modelVersion>
4.     <groupId>net.pascalalma.jboss</groupId>
5.     <artifactId>ch4</artifactId>
6.     <packaging>ejb</packaging>
7.     <version>1.0-SNAPSHOT</version>
8.     <name>ch4</name>
9.     <url>http://maven.apache.org</url>
10.     <dependencies>
11.         <dependency>
12.             <groupId>junit</groupId>
13.             <artifactId>junit</artifactId>
14.             <version>4.4</version>
15.             <scope>test</scope>
16.         </dependency>
17.  
18.         <!-- To test against OpenEJB -->
19.         <dependency>
20.             <groupId>org.apache.openejb</groupId>
21.             <artifactId>openejb-core</artifactId>
22.             <version>3.1</version>
23.             <scope>provided</scope>
24.         </dependency>
25.         <dependency>
26.             <groupId>org.hibernate</groupId>
27.             <artifactId>hibernate-entitymanager</artifactId>
28.             <version>3.4.0.GA</version>
29.             <scope>test</scope>
30.         </dependency>
31.         <dependency>
32.             <groupId>org.hibernate</groupId>
33.             <artifactId>hibernate</artifactId>
34.             <version>3.2.6.ga</version>
35.             <scope>test</scope>
36.         </dependency>
37.         <dependency>
38.             <groupId>commons-collections</groupId>
39.             <artifactId>commons-collections</artifactId>
40.             <version>3.2.1</version>
41.             <scope>test</scope>
42.             <!-- necessary in combination with Hibernate -->
43.         </dependency>
44.         <dependency>
45.             <groupId>org.slf4j</groupId>
46.             <artifactId>slf4j-log4j12</artifactId>
47.             <version>1.5.2</version>
48.             <scope>test</scope>
49.             <!-- necessary in combination with Hibernate-->
50.         </dependency>
51.     </dependencies>
52.     <build>
53.         <plugins>
54.             <plugin>
55.                 <artifactId>maven-compiler-plugin</artifactId>
56.                 <version>2.0.2</version>
57.                 <configuration>
58.                     <source>1.5</source>
59.                     <target>1.5</target>
60.                     <encoding>UTF-8</encoding>
61.                 </configuration>
62.             </plugin>
63.             <plugin>
64.                 <groupId>org.apache.maven.plugins</groupId>
65.                 <artifactId>maven-ejb-plugin</artifactId>
66.                 <configuration>
67.                     <generateClient>true</generateClient>
68.                     <ejbVersion>3.0</ejbVersion>
69.                 </configuration>
70.             </plugin>
71.         </plugins>
72.         <finalName>${artifactId}</finalName>
73.     </build>
74. </project>
• Add the ejb-jar.xml
  To have OpenEJB recognize our module as EJB3 module we have to add an (empty) ejb-jar.xml to our project. Here is the project layout:
  
• Rename the test class

Because I didn't want the test class to be picked up by the Maven I didn't put the phrase 'Test' in it. Now we want the test class now to be picked up, so we have to rename the class so the name contains the phrase 'Test'. I renamed the test class to 'ClientTest'.

• Tune the test class

Besides renaming the test class we also have to make some minor changes in it. We have to modify the intial context that is returned, to have it use the OpenEJB context. And OpenEJB uses another JNDI name construction by default so I changed the used name too in the class. Here is the new version:

PLAIN TEXT
JAVA:
1. package com.titan.clients;
2.  
3. import com.titan.travelagent.TravelAgentRemote;
4. import com.titan.domain.Cabin;
5.  
6. import java.util.Properties;
7. import javax.naming.Context;
8.  
9. import javax.naming.InitialContext;
10. import org.junit.Test;
11.  
12. public class ClientTest {
13.  
14.     private static Context jndiContext = null;
15.  
16.     @Test
17.     public void main() {
18.         try {
19.             jndiContext = getInitialContext();
20.  
21.             //  String jndiName = "TravelAgentBean/remote";
22.             String jndiName = "TravelAgentBeanRemote";
23.             Object ref = jndiContext.lookup(jndiName);
24.  
25.             TravelAgentRemote dao = (TravelAgentRemote) ref;
26.  
27.             Cabin cabin_1 = new Cabin();
28.             cabin_1.setId(1);
29.             cabin_1.setName("Master Suite");
30.             cabin_1.setDeckLevel(1);
31.             cabin_1.setShipId(1);
32.             cabin_1.setBedCount(3);
33.  
34.             dao.createCabin(cabin_1);
35.  
36.             Cabin cabin_2 = dao.findCabin(1);
37.             System.out.println(cabin_2.getName());
38.             System.out.println(cabin_2.getDeckLevel());
39.             System.out.println(cabin_2.getShipId());
40.             System.out.println(cabin_2.getBedCount());
41.  
42.         } catch (javax.naming.NamingException ne) {
43.             ne.printStackTrace();
44.         }
45.     }
46.  
47.     public static Context getInitialContext()
48.             throws javax.naming.NamingException {
49.         InitialContext context = null;
50.         Properties props = new Properties();
51.         props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
52.                 "org.apache.openejb.client.LocalInitialContextFactory");
53.         context = new InitialContext(props);
54.  
55.         return context;
56.     }
57. }
• Run it!

When all this is in place you can build the module and the unit test is executed in OpenEJB before it is deployed to JBoss

Now this concludes this serie of posts about testing and deploying EJB3 modules with Maven against JBoss5. I hope it may help you in some way.

With this in place you can do the following to deploy the ear file:
mvn package jboss:harddeploy
The result in JBoss will be something like:

15:47:43,340 INFO [SessionSpecContainer] Stopping jboss.j2ee:ear=jboss-ear.ear,jar=ch4-1.0-SNAPSHOT.jar,name=TravelAgentBean,service=EJB3
15:47:43,365 INFO [EJBContainer] STOPPED EJB: com.titan.travelagent.TravelAgentBean ejbName: TravelAgentBean
15:47:43,414 INFO [PersistenceUnitDeployment] Stopping persistence unit persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan
15:47:43,414 INFO [SessionFactoryImpl] closing
15:47:43,414 INFO [SchemaExport] Running hbm2ddl schema export
15:47:43,415 INFO [SchemaExport] exporting generated schema to database
15:47:43,416 INFO [SchemaExport] schema export complete
15:47:43,416 INFO [SessionFactoryObjectFactory] Unbinding factory from JNDI name: persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan
15:47:43,416 INFO [NamingHelper] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}
15:47:43,416 INFO [SessionFactoryObjectFactory] Unbound factory from JNDI name: persistence.unit:unitName=jboss-ear.ear/ch4-1.0-SNAPSHOT.jar#titan

Now to test this EJB bean with a client running in Netbeans I had some more trouble. It appears you can not have a 'static void main(String[] args)' method to be executed if you have put your client class in a Maven project. In a Maven project the 'run file' command from Netbeans will always lead to a 'mvn test' command for the corresponding file. The way I work around this, is by making the test client, provided by the book, a jUnit test class, but without the phrase 'test' in the classname. By doing it this way, the client class is not picked up when building the project with Maven (which is good because it would be too early to test it because the class has to be deployed first on our JBoss instance). However, the test is executed when performing a 'run file' in Netbeans! Here is my code for the Client:

Please note that I had to modify the jndi name for looking up my EJB component. This is caused by the fact that JBoss adds the name of the ear file with which the EJB component is deployed.
Anyway, here is the produced output of the test class:

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.titan.clients.Client
Master Suite
1
1
3

Results :
------------------------------------------------------------------------
BUILD SUCCESSFUL
------------------------------------------------------------------------
Total time: 3 seconds
Finished at: Sun May 03 16:22:03 CEST 2009
Final Memory: 7M/13M
------------------------------------------------------------------------

By the way, the added ear-module can be reused for the EJB3 modules of the other chapters. Just modify the dependencies in the ear file and redeploy the constructed ear-file.

1. Minimal use of Maven

In this option I only use Maven to create the ejb-jar. The deployment and the execution of the client to test the EJB is done manually.

2. Medium use of Maven

I use Maven to create the ejb-jar file, a separate ear file and I deploy it with Maven at a running JBoss container. Running the client is still done 'manually'. Ear project can be reused to deploy ejb jars of other chapters.

3. Optimal use of Maven

I extend the setup by performing the unit test in Maven by making use of OpenEJB before it is deployed to JBoss. This way I am sure the bean is working correctly when it is deployed on JBoss.

In this post I describe the steps for option 1.

Steps to make this work:

• create a Maven project

This steps is obvious. Just create a standard Maven project with the command mvn archetype:generate like described in detail here.

• copy code to maven code dir
  Next step is to copy the (re)sources to the place where Maven2 expects it (also a good point to remove the default generated classes App.java and AppTest.java. You will get a setup like this:
  
• modify pom

Next step is to enrich the pom with all dependencies necessary to compile the code. And these are a lot of dependencies when using JBoss to compile against. The complete pom can be found
here. I have added this property to my settings.xml as it is used in the pom:

PLAIN TEXT
XML:
1. <jboss.home>/usr/local/jboss</jboss.home>
• modify the 'persistence.xml'

By using the new JBoss version it appears that the original persisitence.xml isn't working anymore. I had to add the following to it:

PLAIN TEXT
XML:
1. xmlns="http://java.sun.com/xml/ns/persistence"
2.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3.     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
4.     version="1.0"

If you don't add this I got the error:

DEPLOYMENTS IN ERROR:
Deployment "vfszip:/usr/local/jboss-5.0.1.GA/server/default/deploy/ch4.jar/" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=persistence

That's it. You can now build an ejb-jar file and copy it to the JBoss instance by hand. And you can run a client program to call your bean.
In the next post I will show you how you can use Maven to perform the deployment for you and how you can use a 'standalone' client to test your ejb deployment in Netbeans.

]]> http://blog.redstream.nl/2009/05/03/ejb3-with-jboss5-and-maven2/feed/ 11 http://blog.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/ http://blog.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/#comments Wed, 18 Jun 2008 12:45:12 +0000 Pascal Alma http://www.pascalalma.net/?p=137 In my former post (here) I described how to combine Spring WS with StAX parsing the SOAP messages. I ended with generating the WSDL as a test and said you could use Soap UI for testing the web service.
Well, I did. And I was running into the following error when I had deployed my web service at JBoss4.0.5.GA:
PLAIN TEXT
XML:
1. <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
2.    <env:Header/>
3.    <env:Body>
4.       <env:Fault>
5.          <faultcode>env:Server</faultcode>
6.          <faultstring>Operation only supported for javax.xml.soap.Node, this is a [#comment: Test comment]</faultstring>
7.       </env:Fault>
8.    </env:Body>
9. </env:Envelope>


I fixed the issue by adding the following dependencies to the project's pom.xml:

PLAIN TEXT
XML:
1. <dependency>
2.     <groupId>com.sun.xml.messaging.saaj</groupId>
3.     <artifactId>saaj-impl</artifactId>
4.     <version>1.3</version>
5. </dependency>
6. <dependency>
7.     <groupId>javax.activation</groupId>
8.     <artifactId>activation</artifactId>
9.     <version>1.1</version>
10.     <scope>provided</scope>
11. </dependency>

If I don't add this dependencies, apparently Spring WS is using the JBossWS libraries as default, and these libraries can't handle the StAX parsing/writing abilities of Spring WS.
So, after adding the necessary dependencies and redeploying the web service I got the expected response:

PLAIN TEXT
XML:
1. <soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
2.    <soap-ENV:Header/>
3.    <soap-ENV:Body>
4.       <hr:HolidayResponse xmlns:hr="http://www.pascalalma.net/hr/schemas">
5.          <!--Test comment-->
6.          <hr:Status>APPROVED</hr:Status>
7.       </hr:HolidayResponse>
8.    </soap-ENV:Body>
9. </soap-ENV:Envelope>

I don't know about other J(2)EE Servers but for this JBoss version you need these dependencies to get it working.

]]> http://blog.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/feed/ 0 http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/#comments Sun, 03 Feb 2008 09:48:40 +0000 Pascal Alma http://www.pascalalma.net/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ In this blog I'll show you how you can create a WebService of your EJB3 objects by using anotations. I will also show you how to build and deploy the package with Maven2. Let's start with the initial situation.
I have installed JBoss 4.2.1 and Maven2. In my settings.xml of Maven2 I have set a property pointing to my JBoss installation and I have defined a JBoss/Maven2 repository.

The settings.xml file looks like this:
PLAIN TEXT
XML:
1. <settings>
2.   <localRepository>d:/maven2/repo/</localRepository>
3.   <profiles>
4.     <profile>
5.       <id>default-repositories</id>
6.       <repositories>
7.         <repository>
8.           <id>global</id>
9.           <name>External Mirror of Central Repository</name>
10.           <url>http://repo1.maven.org/maven2</url>
11.         </repository>
12.         <repository>
13.           <id>repo.maven</id>
14.           <url>http://repo1.maven.org/maven2-repoclean-java.net</url>
15.         </repository>
16.         <repository>
17.           <id>jboss.maven</id>
18.           <url>http://repository.jboss.com/maven2/</url>
19.         </repository>
20.       </repositories>
21.       <pluginRepositories>
22.         <pluginRepository>
23.           <id>repo1org</id>
24.           <name>External Plugin Repository</name>
25.           <url>http://repo1.maven.org/maven2/</url>
26.         </pluginRepository>
27.       </pluginRepositories>
28.     </profile>
29.     <profile>
30.       <id>property-overrides</id>
31.       <properties>
32.         <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home>
33.       </properties>
34.     </profile>
35.   </profiles>
36.   <activeProfiles>
37.     <activeProfile>property-overrides</activeProfile>
38.     <activeProfile>default-repositories</activeProfile>
39.   </activeProfiles>
40. </settings>

Lateron we'll see that Maven uses the JBoss plugin and the property for the deployment of our application.

I have created a project 'my-ejb-project' with a simple EJB session bean. The bean (and it's interface) looks like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4.  
5. @Remote
6. public interface EchoService {
7.  
8.     public String sayHello(String subject);
9. }

and the implementation:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4.  
5. import net.pascalalma.services.EchoService;
6.  
7. @Stateless
8. public class EchoServiceBean implements EchoService {
9.  
10.     public String sayHello(String name)
11.     {
12.         return "Hi " + name + "!";
13.     }
14. }

To build this project I have this in the project's pom.xml file:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <project xmlns="http://maven.apache.org/POM/4.0.0"
3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
5.     <modelVersion>4.0.0</modelVersion>
6.     <groupId>net.pascalalma</groupId>
7.     <artifactId>my-ejb-project</artifactId>
8.     <version>1.0</version>
9.     <packaging>ejb</packaging>
10.  
11.     <build>
12.         <sourceDirectory>src/main/java</sourceDirectory>
13.         <finalName>my-ejb-project</finalName>
14.         <plugins>
15.             <plugin>
16.                 <artifactId>maven-compiler-plugin</artifactId>
17.                 <configuration>
18.                     <source>1.5</source>
19.                     <target>1.5</target>
20.                 </configuration>
21.             </plugin>
22.             <plugin>
23.                 <groupId>org.apache.maven.plugins</groupId>
24.                 <artifactId>maven-javadoc-plugin</artifactId>
25.                 <configuration>
26.                     <classpath>/src/main/java</classpath>
27.                 </configuration>
28.             </plugin>
29.             <plugin>
30.                 <artifactId>maven-ejb-plugin</artifactId>
31.                 <configuration>
32.                     <ejbVersion>3.0</ejbVersion>
33.                     <archive>
34.                         <manifest>
35.                             <addClasspath>true</addClasspath>
36.                         </manifest>
37.                     </archive>
38.                 </configuration>
39.             </plugin>
40.         </plugins>
41.     </build>
42.     <dependencies>
43.         <dependency>
44.             <groupId>org.apache.geronimo.specs</groupId>
45.             <artifactId>geronimo-jpa_3.0_spec</artifactId>
46.             <version>1.1</version>
47.             <scope>provided</scope>
48.         </dependency>
49.         <dependency>
50.             <groupId>org.apache.geronimo.specs</groupId>
51.             <artifactId>geronimo-ejb_3.0_spec</artifactId>
52.             <version>1.0</version>
53.             <scope>provided</scope>
54.         </dependency>
55.         <dependency>
56.             <groupId>junit</groupId>
57.             <artifactId>junit</artifactId>
58.             <version>4.1</version>
59.             <scope>test</scope>
60.         </dependency>
61.     </dependencies>
62.     <reporting>
63.         <plugins>
64.             <plugin>
65.                 <groupId>org.apache.maven.plugins</groupId>
66.                 <artifactId>maven-surefire-report-plugin</artifactId>
67.             </plugin>
68.             <plugin>
69.                 <groupId>org.apache.maven.plugins</groupId>
70.                 <artifactId>maven-jxr-plugin</artifactId>
71.             </plugin>
72.         </plugins>
73.     </reporting>
74. </project>

Besides this ejb-project I have also created a ear-project that is used to create an ear file containing the EJB's jar file (and optionally other deliverables like war-file etc). The pom file of this project looks like (the project doesn't contain anything else):

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <project xmlns="http://maven.apache.org/POM/4.0.0"
3.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
5.     <modelVersion>4.0.0</modelVersion>
6.     <groupId>net.pascalalma</groupId>
7.     <artifactId>my-ear-project</artifactId>
8.     <packaging>ear</packaging>
9.     <version>1.0</version>
10.     <name>my-ear-project</name>
11.     <dependencies>
12.         <dependency>
13.             <groupId>net.pascalalma</groupId>
14.             <artifactId>my-ejb-project</artifactId>
15.             <version>1.0</version>
16.             <type>ejb</type>
17.         </dependency>
18.     </dependencies>
19.     <build>
20.         <plugins>
21.             <plugin>
22.                 <groupId>org.codehaus.mojo</groupId>
23.                 <artifactId>jboss-maven-plugin</artifactId>
24.                 <configuration>
25.                     <jbossHome>${jboss.home}</jbossHome>
26.                     <serverName>default</serverName>
27.                     <port>8080</port>
28.                 </configuration>
29.             </plugin>
30.             <plugin>
31.                 <artifactId>maven-ear-plugin</artifactId>
32.                 <configuration>
33.                     <displayName>My EJB Component</displayName>
34.                     <description>My EJB Component</description>
35.                     <version>1.4</version>
36.                     <modules>
37.                         <ejbModule>
38.                             <groupId>net.pascalalma</groupId>
39.                             <artifactId>my-ejb-project</artifactId>
40.                         </ejbModule>
41.                     </modules>
42.                 </configuration>
43.             </plugin>
44.         </plugins>
45.     </build>
46. </project>

With all this in place we are able to build the EJB3 project with the command:
c:\workspace\my-ejb-project\mvn clean install
and to package and deploy the EAR project with:
c:\workspace\my-ear-project\mvn clean package jboss:harddeploy

To make our EJB3 bean available as a webservice, we have to add some annotations to the source, so the code of the interface and the bean will become something like this:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services;
2.  
3. import javax.ejb.Remote;
4. import javax.jws.WebService;
5.  
6. @Remote
7. @WebService()
8. public interface EchoService {
9.  
10.     public String sayHello(String subject);
11. }

and the implementation class:

PLAIN TEXT
JAVA:
1. package net.pascalalma.services.impl;
2.  
3. import javax.ejb.Stateless;
4. import javax.jws.WebService;
5. import javax.jws.soap.SOAPBinding;
6.  
7. import net.pascalalma.services.EchoService;
8.  
9. @Stateless
10. @WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService")
11. @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT)
12. public class EchoServiceBean implements EchoService {
13.     @javax.jws.WebMethod()
14.     public String sayHello(String name)
15.     {
16.         return "Hi " + name + "!";
17.     }
18. }

That's it! The only thing left is that we have to add a new dependency to the pom (for the javax.jws.*). The dependency looks like:

PLAIN TEXT
XML:
1. <dependency>
2.       <groupId>xfire</groupId>
3.       <artifactId>xfire-jsr181-api</artifactId>
4.       <version>1.0-M1</version>
5.       <scope>provided</scope>
6.     </dependency>

As you can see the dependency has the scope 'provided' because the library is already available in JBoss, so we don't want to package it in our jar file.

Now rebuild and redeploy the packages and it is done!

To test the webservice I use my favorite tool 'Soap UI'. We can generate the necessary WSDL at runtime by going to the url: 'http://127.0.0.1:8080/EchoServiceBeanService/EchoServiceBean?wsdl'. The result in SOAP UI looks like this:


After sending the request we will get this respone:


I hope this post makes clear that is easy to make your EJB3 session beans available as a webservice, by simply adding some annotations to your code.

]]> http://blog.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/feed/ 17 http://blog.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/ http://blog.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/#comments Tue, 29 Jan 2008 19:07:13 +0000 Pascal Alma http://www.pascalalma.net/2008/01/29/classloader-issue-with-jboss-405ga/ Today I was asked to help solving an issue with an application that was deployed on JBoss 4.0.5.GA. It had been running for some months without a problem, until a new application had to be deployed. This new application demanded that the isolation level in the 'ear-deployer.xml' config file had to be set to its default value 'false'. However, the setting was set to 'true' for some reason.

Here is the content of the file:
PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <!-- The JBoss service configuration file for the EAR deployer service.
3. $Id: ear-deployer.xml 60679 2007-02-19 21:35:39Z scott.stark@jboss.org $
4. -->
5. <server>
6.    <!-- EAR deployer, remove if you are not using ear deployments -->
7.    <mbean code="org.jboss.deployment.EARDeployer"
8.       name="jboss.j2ee:service=EARDeployer">
9.       <!-- A flag indicating if ear deployments should have their own scoped
10.       class loader to isolate their classes from other deployments.
11.       -->
12.       <attribute name="Isolated">false</attribute>
13.       <!-- A flag indicating if the ear components should have in VM call
14.       optimization disabled.
15.       -->
16.       <attribute name="CallByValue">false</attribute>
17.       <!-- A flag the enables the default behavior of the ee5 library-directory. If true,
18.       the lib contents of an ear are assumed to be the default value for library-directory
19.       in the absence of an explicit library-directory. If false, there must be an
20.       explicit library-directory.
21.       -->
22.       <attribute name="EnablelibDirectoryByDefault">true</attribute>
23.    </mbean>
24. </server>

By setting the parameter back to 'false' and test the applications that were deployed on the JBoss instance, it was quickly found which application went wrong. One of the applications was giving the following exception:

Caused by: java.lang.NoSuchMethodError: org.apache.commons.httpclient.methods.PostMethod.getParams()Lorg/apache/commons/httpclient/params/HttpMethodParams;
at net.pascalalma.components.sms.SmsServiceBean.postSmsRequest(SmsServiceBean.java:220)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.java:127)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)

After some further investigation I found out that the problem was caused by the commons-httpclient.jar. The application needs to use tthe version 3.0.1 while the JBoss is supplied with version 2.0 (it's in the JBOSS_HOME/lib/ directory). So instead of setting the isolation level at JBoss instance level I tried to set this 'property' at application level by supplying a 'jboss-app.xml' with the .ear file of the application. The content of the 'jboss-app.xml' is:

PLAIN TEXT
XML:
1. <jboss-app>
2.   <loader-repository>
3.   net.pascalalma.appl:archive=my-app.ear
4.      <loader-repository-config>
5.      java2ParentDelegation=false
6.      </loader-repository-config>
7.   </loader-repository>
8. </jboss-app>

After testing this configuration the application worked fine, but I ran into another issue....
We are building and packaging our application with Maven2. To generate the ear-file, we use this maven-ear plugin. I found out that the plugin offers the possibility to generate the necessary 'jboss-app.xml' file by configuring the plugin in the corresponding pom file like this:

PLAIN TEXT
XML:
1. <project>
2.   ...
3.   ...
4.   <build>
5.     <plugins>
6.        <plugin>
7.           <groupId>org.codehaus.mojo</groupId>
8.           <artifactId>jboss-maven-plugin</artifactId>
9.           <configuration>
10.                   <jbossHome>${jboss.home}</jbossHome>
11.                   <serverName>default</serverName>
12.                   <port>8080</port>
13.           </configuration>
14.        </plugin>
15.        <plugin>
16.           <artifactId>maven-ear-plugin</artifactId>
17.           <configuration>
18.              <displayName>My Application</displayName>
19.              <description>My apliation using HttpClient3.0.1</description>
20.              <version>2.3.1</version>
21.              <modules>
22.                 <ejbModule>
23.                    <groupId>net.pascalalma</groupId>
24.                    <artifactId>
25.                       my-ejb-app
26.                    </artifactId>
27.                 </ejbModule>
28.                 <webModule>
29.                    <groupId>net.pascalalma</groupId>
30.                    <artifactId>
31.                       my-web-app
32.                    </artifactId>
33.                    <contextRoot>/my-app</contextRoot>
34.                 </webModule>
35.              </modules>
36.              <jboss>
37.                 <version>4</version>
38.                 <loader-repository>
39.                   net.pascalalma.appl:archive=my-app.ear
40.                 </loader-repository>
41.                 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
42.              </jboss>
43.              <archive>
44.                 <manifest>
45.                    <addClasspath>true</addClasspath>
46.                 </manifest>
47.              </archive>
48.           </configuration>
49.        </plugin>
50.     </plugins>
51.   </build>
52. </project>

Unfortunately, the plugin ignores the tag 'loader-repository-config' in the pom file. So this setting is not added to the 'jboss-app.xml' while this is the most important setting in our case! So for now I add the correct file by hand, but if someone knows a nice way to do this, I am very eager to hear it.

]]> http://blog.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/feed/ 0 http://blog.redstream.nl/2007/10/16/back-to-maven2-again/ http://blog.redstream.nl/2007/10/16/back-to-maven2-again/#comments Tue, 16 Oct 2007 16:49:54 +0000 Pascal Alma http://www.pascalalma.net/2007/10/16/back-to-maven2-again/ I have just begun at a new project with some new technologies. I am currently developing applications using EJB3, JSF1.2 and Facelets. We deploy the application on a JBoss 4.2.1 server. For the building, testing and packaging we are using Maven2. I have used it before at other projects and I must say: it is a relieve to use it again after having use Ant for the last 6 months. Although there are some disadvantages when using Maven for which I haven't found a solution yet, overall I find it a great step forward.
For those that haven't used Maven2 before and are ending up in this blog here is a quick list of the necessary steps to get it running on your Windows machine behind a firewall.
INSTALL:
1. Unzip maven-2.0.7-bin.zip to the directory you wish to install Maven 2.0.7. These instructions assume you chose C:\maven-2.0.7
2. Add the bin directory to your path, by opening up the system properties (WinKey + Pause), selecting the "Advanced" tab, and the "Environment Variables" button, then editing the PATH variable in the user variables. eg. "C:\maven-2.0.7\bin";%PATH%
3. In the same dialog, make sure that JAVA_HOME is set to the location of your JDK, eg. C:\jdk1.5.0_02
4. Run mvn --version to verify that it is correctly installed.

CONFIGURATION:

You can specify your user configuration in ${user.home}/.m2/settings.xml . A full reference to the configuration file is available. This section will show how to make some common configurations. Note that the file is not required - defaults will be used if it is not found.

Configuring your Local Repository

1. The location of your local repository can be changed in your user configuration. The default value is ${user.home}/.m2/repository/ .
   PLAIN TEXT
   XML:

   1. <settings>
   2.   ...
   3.   <localRepository>/path/to/local/repo/</localRepository>
   4.   ...
   5. </settings>

   Note: The local repository must be an absolute path.

2. Configuring a Proxy

   You can configure a proxy to use for some or all of your HTTP requests in Maven 2.0. The username and password are only required if your proxy requires basic authentication (note that later releases may support storing your passwords in a secured keystore - in the mean time, please ensure your settings.xml file (usually $user.home /.m2/settings.xml) is secured with permissions appropriate for your operating system).

   The nonProxyHosts setting accepts wild cards, and each host not to proxy is separated by the | character. This matches the JDK configuration equivalent.

   PLAIN TEXT
   XML:

   1. <settings>
   2.   .
   3.   <proxies>
   4.    <proxy>
   5.       <active>true</active>
   6.       <protocol>http</protocol>
   7.       <host>proxy.somewhere.com</host>
   8.       <port>8080</port>
   9.       <username>proxyuser</username>
   10.       <password>somepassword</password>
   11.       <nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
   12.     </proxy>
   13.   </proxies>
   14.   .
   15.   .
   16. </settings>

   Please note that urrently NTLM proxies are not supported as they have not been tested. You may be able to use the relevant system properties on JDK 1.4+ to make this work.

3. Using Mirrors for Repositories
   Repositories can be declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files.

   Some reasons to use a mirror are:

   * There is a synchronized mirror on the internet that is geographically closer and faster
   * You want to replace a particular repository with your own internal repository which you have greater control over
   * You want to run maven-proxy to provide a local cache to a mirror and need to use its URL instead

   To configure a mirror of a given repository, you provide it in your settings file, giving the new repository its own id and url , and specify the mirrorOf setting that is the ID of the repository you are using a mirror of. For example, the id of the main Maven repository included by default is central , so to use an Australian mirror, you would configure the following:

   PLAIN TEXT
   XML:

   1. <settings>
   2.   ...
   3.   <mirrors>
   4.    <mirror>
   5.       <id>planetmirror</id>
   6.       <name>Australian Mirror of http://repo1.maven.org/maven2/</name>
   7.       <url>http://public.planetmirror.com/maven2/</url>
   8.       <mirrorOf>central</mirrorOf>
   9.     </mirror>
   10.         ...
   11.   </mirrors>
   12.   ...
   13. </settings>

Most of this info is just copied from the Maven website. This is just a summary with the most essential info. If you really want to use Maven2 for the first time I suggest you have a look there for more info.

Another thing which is good to know: sometimes you will need libraries that aren't in any global repository (some Sun jars, at least until recently or some jars you made yourself). To have Maven work with these libraries you will have to install them in your local repository. You can do so with the following command:

mvn install:install-file -DgroupId=net.pascalalma.faces -DartifactId=my-validators
-Dversion=1.0 -Dpackaging=jar -Dfile=C:/tmp/my-validators-1.0.jar

One final thing I found very handy is the use of the JBoss plugin to deploy your application to JBoss. You can use the plugin by putting the following in your pom:

PLAIN TEXT
XML:
1. <build>...
2.         <plugins>
3.             <plugin>
4.                 <groupId>org.codehaus.mojo</groupId>
5.                 <artifactId>jboss-maven-plugin</artifactId>
6.                 <configuration>
7.                     <jbossHome>${jboss.home}</jbossHome>
8.                     <serverName>default</serverName>
9.                     <port>8080</port>
10.                 </configuration>
11.             </plugin>
12.         </plugins>
13.                 ...
14.     </build>

In my settings.xml I have defined the jboss.home property like this:

PLAIN TEXT
XML:
1. ...
2.   <profiles>
3.   ...
4.     <profile>
5.       <id>property-overrides</id>
6.         <properties>
7.           <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home>
8.         </properties>
9.     </profile>
10.   </profiles>
11.   <activeProfiles>
12.     ...
13.     <activeProfile>property-overrides</activeProfile>
14.   </activeProfiles>
15.   ...

If al this is in place you can deploy your application to the default JBoss server with the command:
mvn clean package jboss:harddeploy

]]> http://blog.redstream.nl/2007/10/16/back-to-maven2-again/feed/ 4 http://blog.redstream.nl/2007/05/07/using-a-jboss-mbean-in-your-web-application/ http://blog.redstream.nl/2007/05/07/using-a-jboss-mbean-in-your-web-application/#comments Mon, 07 May 2007 06:23:22 +0000 Pascal Alma http://www.pascalalma.net/?p=32 For our application which is making use of queues to achieve aynchronious processing we also have build a web-application as kind of dashboard for the system. With this web-application the system administrator can stop, start and schedule batch processes. One thing that was really handy to show on the webpage were the number of messages that are in the queue. We have defined a JMS queue in JBoss with JBoss messaging (see this post). Now to get the number of messages in the queue there were two possibilities:
1. create a queueBrowser and browse to all messages and count them.
2. access the queue MBean and get the attribute messageCount.

It should be no surprise that I decided to go for the second solution. Here is the (rather simple) code I used to obtain a the MBean and get the property. Remind that this code will only work if it is deployed at the same JBoss instance as were the queue's MBean is configured!

PLAIN TEXT
JAVA:
1. public int getMessageCountConsumer() {
2.       int messageCount = -1;
3.       try {
4.          MBeanServer server = org.jboss.mx.util.MBeanServerLocator.locateJBoss();
5.  
6.          // Get the MBeanInfo for the JNDIView MBean
7.          Hashtable props = new Hashtable();
8.          props.put("service", "Queue");
9.          props.put("name", "MyQueue");
10.          ObjectName name = new ObjectName("jboss.messaging.destination", props);
11.  
12.          messageCount = (Integer)(server.getAttribute(name, "MessageCount"));
13.  
14.       } catch (Exception e) {
15.          // Error is logged but process is not broken. Not that big problem.
16.          LOG.error("Error while getting messageCount:", e);
17.       }
18.       return messageCount;
19.    }
]]> http://blog.redstream.nl/2007/05/07/using-a-jboss-mbean-in-your-web-application/feed/ 1 http://blog.redstream.nl/2007/04/10/jboss-messaging-installation-and-configuration/ http://blog.redstream.nl/2007/04/10/jboss-messaging-installation-and-configuration/#comments Tue, 10 Apr 2007 17:41:28 +0000 Pascal Alma http://www.pascalalma.net/?p=25 Last week I installed JBoss Messaging 1.2.0.GA on our JBoss 4.0.5.GA instance. In this blog I will state the steps we performed to install the extension and configure it for our application. I am not sure this will be THE way to do it, but this is how it worked for us. Please note that JBoss Messaging will be standard in JBoss 5, but since we are working with JBoss 4.0.5 we have to install it ourselves.
1. Well, as usual, the first step is to download the extension at this link. After obtaining the zip we extract it in some temporary directory.
2. Second step is necessary if you don't have Ant 1.7 running at your machine already. This version of Ant is necessary for the installation. So if it is not at your machine you can download it here. Follow the instructions supplied with it to install it.
3. Third step is also necessary if there hasn't been set a environment variable called 'JBOSS_HOME' pointing to your JBoss root directory. This environment variable is used by the Ant script to determine where to install the JBoss extension.

When this is all set you can browse to the directory '/jboss-messaging-1.2.0.GA/util' of the extracted jboss-messaging zip file and run Ant with the following command:
ant -f release-admin.xml


With this command the extension is installed and you will see in your JBoss instance a new server directory called 'messaging'. The next steps are the steps we performed to configure some queues and make them persisting themselves in a PostgreSQL 8 database.

To have JBoss persit its messages from the queue to Postgres it needs access to the Postgres JDBC driver. Therefor you need to copy the file 'postgresql-8.1-404.jdbc3.jar' (or your version) to the directory '$JBOSS_HOME$/server/messaging/lib'.

To tell JBoss how to access the Postgres database (define a datasource) we put a file called 'postgres-ds.xml' in the directory '$JBOSS_HOME$/server/bag/deploy/'. The file has the following content:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <datasources>
3.     <local-tx-datasource>
4.         <jndi-name>JmsDS</jndi-name>
5.     <connection-url>jdbc:postgresql://localhost/jms</connection-url>
6.     <driver-class>org.postgresql.Driver</driver-class>
7.     <user-name>jms</user-name>
8.     <password>jms</password>
9.     <new-connection-sql>select 1</new-connection-sql>
10.     <check-valid-connection-sql>select 1</check-valid-connection-sql>
11.     <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
12.     <metadata>
13.     <type-mapping>PostgreSQL 8.1</type-mapping>
14.     </metadata>
15.   </local-tx-datasource>
16. </datasources>

As you can see in the file it tries to connect to a database called 'JMS' at the localhost. It uses username 'JMS' and password 'JMS'. You must make sure this database exists and the user JMS has the rights to create database objects in the database.

Now JBoss is ready and we have to define the queues in JBoss Messaging. Since we use the default ConnectionFactory we do not have to add one and we just add a MBean to the file 'destinations-service.xml' in the directory '$JBOSS_HOME/server/messaging/deploy/jboss-messaging.sar/':

PLAIN TEXT
XML:
1. <mbean code="org.jboss.jms.server.destination.QueueService"
2.       name="jboss.messaging.destination:service=Queue,name=BagQueue"
3.       xmbean-dd="xmdesc/Queue-xmbean.xml">
4.       <depends optional-attribute-name="ServerPeer"> jboss.messaging:service=ServerPeer</depends>
5.       <depends>jboss.messaging:service=PostOffice</depends>
6.    </mbean>

There is one more file that must be added to the directory '$JBOSS_HOME/server/bag/deploy/jboss-messaging.sar/': 'postgresql-persistence-service.xml'. The contents of this file:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="utf-8"?>
2.  
3. <!--
4.      Postgresql non-clustered persistence deployment descriptor.
6.      Tested with PostgresSQL 8.1.5
8.      $Id: postgresql-persistence-service.xml 2449 2007-02-26 19:25:34Z timfox $
9. -->
10.  
11. <server>
12.  
13.    <mbean code="org.jboss.messaging.core.plugin.JDBCPersistenceManagerService"
14.          name="jboss.messaging:service=PgPersistenceManager"
15.          xmbean-dd="xmdesc/JDBCPersistenceManager-xmbean.xml">
16.          <depends>jboss.jca:service=DataSourceBinding,name=JmsDS</depends>
17.          <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
18.          <attribute name="DataSource">java:/JmsDS</attribute>
19.          <attribute name="CreateTablesOnStartup">true</attribute>
20.          <attribute name="UsingBatchUpdates">true</attribute>
21.        <attribute name="SqlProperties"><![CDATA[
22.    CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INTEGER, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID))
23.    CREATE_IDX_MESSAGE_REF_TX=CREATE INDEX JBM_MSG_REF_TX ON JBM_MSG_REF (TRANSACTION_ID)
24.    CREATE_IDX_MESSAGE_REF_ORD=CREATE INDEX JBM_MSG_REF_ORD ON JBM_MSG_REF (ORD)
25.    CREATE_IDX_MESSAGE_REF_PAGE_ORD=CREATE INDEX JBM_MSG_REF_PAGE_ORD ON JBM_MSG_REF (PAGE_ORD)
26.    CREATE_IDX_MESSAGE_REF_MESSAGE_ID=CREATE INDEX JBM_MSG_REF_MESSAGE_ID ON JBM_MSG_REF (MESSAGE_ID)
27.    CREATE_IDX_MESSAGE_REF_SCHED_DELIVERY=CREATE INDEX JBM_MSG_REF_SCHED_DELIVERY ON JBM_MSG_REF (SCHED_DELIVERY)
28.    CREATE_MESSAGE=CREATE TABLE JBM_MSG (MESSAGE_ID BIGINT, RELIABLE CHAR(1), EXPIRATION BIGINT, TIMESTAMP BIGINT, PRIORITY SMALLINT, HEADERS BYTEA, PAYLOAD BYTEA, CHANNEL_COUNT INTEGER, TYPE SMALLINT, PRIMARY KEY (MESSAGE_ID))
29.    CREATE_TRANSACTION=CREATE TABLE JBM_TX (TRANSACTION_ID BIGINT, BRANCH_QUAL BYTEA, FORMAT_ID INTEGER, GLOBAL_TXID BYTEA, PRIMARY KEY (TRANSACTION_ID))
30.    CREATE_COUNTER=CREATE TABLE JBM_COUNTER (NAME VARCHAR(255), NEXT_ID BIGINT, PRIMARY KEY(NAME))
31.    INSERT_MESSAGE_REF=INSERT INTO JBM_MSG_REF (CHANNEL_ID, MESSAGE_ID, TRANSACTION_ID, STATE, ORD, PAGE_ORD, DELIVERY_COUNT, SCHED_DELIVERY) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
32.    DELETE_MESSAGE_REF=DELETE FROM JBM_MSG_REF WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
33.    UPDATE_MESSAGE_REF=UPDATE JBM_MSG_REF SET TRANSACTION_ID=?, STATE='-' WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
34.    UPDATE_PAGE_ORDER=UPDATE JBM_MSG_REF SET PAGE_ORD = ? WHERE MESSAGE_ID=? AND CHANNEL_ID=?
35.    COMMIT_MESSAGE_REF1=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='+'
36.    COMMIT_MESSAGE_REF2=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='-'
37.    ROLLBACK_MESSAGE_REF1=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='+'
38.    ROLLBACK_MESSAGE_REF2=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='-'
39.    LOAD_PAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, PAGE_ORD, SCHED_DELIVERY FROM JBM_MSG_REF WHERE CHANNEL_ID = ? AND PAGE_ORD BETWEEN ? AND ? ORDER BY PAGE_ORD
40.    LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD
41.    LOAD_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? ORDER BY ORD
42.    UPDATE_REFS_NOT_PAGED=UPDATE JBM_MSG_REF SET PAGE_ORD = NULL WHERE PAGE_ORD BETWEEN ? AND ? AND CHANNEL_ID=?
43.    SELECT_MIN_MAX_PAGE_ORD=SELECT MIN(PAGE_ORD), MAX(PAGE_ORD) FROM JBM_MSG_REF WHERE CHANNEL_ID = ?
44.    SELECT_EXISTS_REF=SELECT MESSAGE_ID FROM JBM_MSG_REF WHERE CHANNEL_ID = ? AND MESSAGE_ID = ?
45.    SELECT_EXISTS_REF_MESSAGE_ID=SELECT MESSAGE_ID FROM JBM_MSG_REF WHERE MESSAGE_ID = ?
46.    UPDATE_DELIVERY_COUNT=UPDATE JBM_MSG_REF SET DELIVERY_COUNT = ? WHERE CHANNEL_ID = ? AND MESSAGE_ID = ?
47.    UPDATE_CHANNEL_ID=UPDATE JBM_MSG_REF SET CHANNEL_ID = ? WHERE CHANNEL_ID = ?
48.    LOAD_MESSAGES=SELECT MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, HEADERS, PAYLOAD, TYPE FROM JBM_MSG
49.    INSERT_MESSAGE=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, HEADERS, PAYLOAD, CHANNEL_COUNT, TYPE) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
50.    INC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT + 1 WHERE MESSAGE_ID=?
51.    DEC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT - 1 WHERE MESSAGE_ID=?
52.    DELETE_MESSAGE=DELETE FROM JBM_MSG WHERE MESSAGE_ID=? AND CHANNEL_COUNT=0
53.    MESSAGE_ID_COLUMN=MESSAGE_ID
54.    MESSAGE_EXISTS=SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ? FOR UPDATE
55.    INSERT_TRANSACTION=INSERT INTO JBM_TX (TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID) VALUES(?, ?, ?, ?)
56.    DELETE_TRANSACTION=DELETE FROM JBM_TX WHERE TRANSACTION_ID = ?
57.    SELECT_PREPARED_TRANSACTIONS=SELECT TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID FROM JBM_TX
58.    SELECT_MESSAGE_ID_FOR_REF=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '+' ORDER BY ORD
59.    SELECT_MESSAGE_ID_FOR_ACK=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '-' ORDER BY ORD
60.    UPDATE_COUNTER=UPDATE JBM_COUNTER SET NEXT_ID = ? WHERE NAME=?
61.    SELECT_COUNTER=SELECT NEXT_ID FROM JBM_COUNTER WHERE NAME=? FOR UPDATE
62.    INSERT_COUNTER=INSERT INTO JBM_COUNTER (NAME, NEXT_ID) VALUES (?, ?)
63.    SELECT_ALL_CHANNELS=SELECT DISTINCT(CHANNEL_ID) FROM JBM_MSG_REF
64.        ]]></attribute>
65.  
66.          <attribute name="MaxParams">500</attribute>
67.    </mbean>
68.  
69.    <mbean code="org.jboss.messaging.core.plugin.DefaultPostOfficeService"
70.       name="jboss.messaging:service=PostOffice"
71.       xmbean-dd="xmdesc/DefaultPostOffice-xmbean.xml">
72.       <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
73.       <depends>jboss.jca:service=DataSourceBinding,name=JmsDS</depends>
74.       <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
75.       <attribute name="PostOfficeName">JMS</attribute>
76.       <attribute name="DataSource">java:/JmsDS</attribute>
77.       <attribute name="CreateTablesOnStartup">true</attribute>
78.       <attribute name="SqlProperties"><![CDATA[
79. CREATE_POSTOFFICE_TABLE=CREATE TABLE JBM_POSTOFFICE (POSTOFFICE_NAME VARCHAR(255), NODE_ID INTEGER, QUEUE_NAME VARCHAR(1023), COND VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1))
80. INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED) VALUES (?, ?, ?, ?, ?, ?, ?)
81. DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND QUEUE_NAME=?
82. LOAD_BINDINGS=SELECT NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME  = ?
83.       ]]></attribute>
84.    </mbean>
85.  
86.    <mbean code="org.jboss.jms.server.plugin.JDBCJMSUserManagerService"
87.       name="jboss.messaging:service=JMSUserManager"
88.       xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
89.       <depends>jboss.jca:service=DataSourceBinding,name=JmsDS</depends>
90.       <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
91.       <attribute name="DataSource">java:/JmsDS</attribute>
92.       <attribute name="CreateTablesOnStartup">true</attribute>
93.       <attribute name="SqlProperties"><![CDATA[
94. CREATE_USER_TABLE=CREATE TABLE JBM_USER (USER_ID VARCHAR(32) NOT NULL, PASSWD VARCHAR(32) NOT NULL, CLIENTID VARCHAR(128), PRIMARY KEY(USER_ID))
95. CREATE_ROLE_TABLE=CREATE TABLE JBM_ROLE (ROLE_ID VARCHAR(32) NOT NULL, USER_ID VARCHAR(32) NOT NULL, PRIMARY KEY(USER_ID, ROLE_ID))
96. SELECT_PRECONF_CLIENTID=SELECT CLIENTID FROM JBM_USER WHERE USER_ID=?
97. POPULATE.TABLES.1=INSERT INTO JBM_USER (USER_ID,PASSWD,CLIENTID) VALUES ('dilbert','dogbert','dilbert-id')
98.       ]]></attribute>
99.    </mbean>
100.  
101. </server>

By default the file 'hsqldb-persistence-service.xml' is added to the directory to perform the persistence with HSQLDB. This file must now be removed to avoid clashes in JBoss configuration. So remove the file.

One more thing to do is to tell the JBoss Messaging to use our new persistence manager: PgPersistenceManager. To do this edit the file 'messaging-service.xml' in the directory '$JBOSS_HOME/server/bag/deploy/jboss-messaging.sar/' and replace the next line:

PLAIN TEXT
XML:
1. <depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PersistenceManager</depends>

with:

PLAIN TEXT
XML:
1. <depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PgPersistenceManager</depends>

That was the final step. You should now be able to access the JMS Queues with Spring for example as I have blogged here.

]]> http://blog.redstream.nl/2007/04/10/jboss-messaging-installation-and-configuration/feed/ 2