redstream » JBoss http://www.redstream.nl Pragmatic Integrators Fri, 27 Jan 2012 19:31:59 +0000 en hourly 1 Deploying with Maven2 to a remote JBoss instance http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/ http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/#comments Sun, 06 Dec 2009 10:07:09 +0000 Pascal Alma http://www.pascalalma.net/?p=962 Continue reading →]]>

Some time ago I already explained how you could use Maven and the jboss-plugin to deploy your war or ear to your JBoss server. Now this works fine as long as your JBoss is a local installation running on the same machine as the one that is running Maven.
Of course there is a big chance that this is not the case in your development environment. In that case you can do the following in Maven to deploy your ear to the JBoss instance:

  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’:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>wagon-maven-plugin</artifactId>
      <version>1.0-beta-1</version>
      <executions>
        <execution>
          <id>upload-artifact</id>
          <phase>deploy</phase>
          <goals>
            <goal>upload</goal>
          </goals>
          <configuration>
            <serverId>${project.deploy.serverId}</serverId>
            <fromDir>target</fromDir>
            <includes>*.war</includes>
            <url>${project.deploy.url}</url>
            <toDir>${project.deploy.toDir}</toDir>
          </configuration>
        </execution>
      </executions>
   </plugin>
    ...
  </plugin>
</build>

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

1
2
3
4
5
6
7
8
9
10

<distributionManagement>
   <repository>
     <id>m2-internal-repo</id>
     <url>http://local.redstream.nl:8888/artifactory/libs-releases-local/</url>
   </repository>
   <snapshotRepository>
     <id>m2-internal-repo</id>
     <url>http://local.redstream.nl:8888/artifactory/libs-snapshots-local</url>
   </snapshotRepository>
</distributionManagement>

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-antrun-plugin</artifactId>
     <version>1.3</version>
     <dependencies>
       <dependency>
         <groupId>org.apache.ant</groupId>
         <artifactId>ant-jsch</artifactId>
         <version>1.7.1</version>
       </dependency>
       <dependency>
         <groupId>com.jcraft</groupId>
         <artifactId>jsch</artifactId>
         <version>0.1.41</version>
       </dependency>
       </dependencies>
         <executions>
           <execution>
             <id>deploy-artifact</id>
             <phase>deploy</phase>
             <goals>
               <goal>run</goal>
             </goals>
             <configuration>
               <tasks>
                  <sshexec host="${project.deploy.host}"
                                  username="${projecte.deploy.username}"
                                  password="${project.deploy.password}"
                                  trust="true"
                                 command="bin/deploy_web.sh"/>
               </tasks>
             </configuration>
           </execution>
         </executions>
      </plugin>

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’:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<profiles>
  <profile>
    <id>develop</id>
    <properties>
      <project.deploy.serverId>mule-server</mule.deploy.serverId>
      <project.deploy.url>scp://mule-server</mule.deploy.url>
      <project.deploy.toDir>/home/pascal</mule.deploy.toDir>
      <project.deploy.host>mule-server</mule.deploy.host>
      <project.deploy.username>pascal</mule.deploy.username>
      <project.deploy.password>pascal</mule.deploy.password>
    </properties>
  </profile>
  ...
</profiles>

And the script that is executed at the remote server ‘deploy_web.sh’:
[code]
#
# Deploy Mule applications
#
#
source /etc/profile

echo "Start deploying"

for archive in ~/deploy/*.war; do
echo "Copying to tomcat: web-archive \"$archive\""
cp $archive /$TOMCAT_HOME/webapps/
done

echo "Deploying finished"

echo "Clean up ~/deploy directory"
rm -rf ~/deploy/*.war
[/code]
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.

]]> http://www.redstream.nl/2009/12/06/deploying-with-maven2-to-a-remote-jboss-instance/feed/ 16 EJB3 with JBoss5 and Maven2 (part 3) http://www.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/ http://www.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/#comments Mon, 18 May 2009 18:38:05 +0000 Pascal Alma http://www.pascalalma.net/?p=814 Continue reading →]]>

As I promised here this is the last part about using Maven2 to build, test and deploy an EJB3 application to JBoss5. In part 2 I showed how you can build and deploy your EJB3 application in JBoss. In this step I want to show you how you can (unit)test your EJB3 module before you deploy it to JBoss. In part 2 we had to deploy the bean first, before we could test it, but that is not the most optimal way. It would be nicer if the code is tested before it is deployed to the JBoss server. To do this, I make use of OpenEJB. This is a lightweight container that is very easy to use with Maven. Another advantage of this approach is that the EJB component is tested/used in two different EJB containers and reduces the possiblity that container-specific code is used in the application.
Although I have described a similar situation before in this post I will show the steps to get to this setup but now based on the situation of the last post. These are the steps to perform:

  • 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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>net.pascalalma.jboss</groupId>
    <artifactId>ch4</artifactId>
    <packaging>ejb</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>ch4</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.4</version>
            <scope>test</scope>
        </dependency>
 
        <!-- To test against OpenEJB -->
        <dependency>
            <groupId>org.apache.openejb</groupId>
            <artifactId>openejb-core</artifactId>
            <version>3.1</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>3.4.0.GA</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>3.2.6.ga</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
            <version>3.2.1</version>
            <scope>test</scope>
            <!-- necessary in combination with Hibernate -->
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.5.2</version>
            <scope>test</scope>
            <!-- necessary in combination with Hibernate-->
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.0.2</version>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-ejb-plugin</artifactId>
                <configuration>
                    <generateClient>true</generateClient>
                    <ejbVersion>3.0</ejbVersion>
                </configuration>
            </plugin>
        </plugins>
        <finalName>${artifactId}</finalName>
    </build>
</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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

    package com.titan.clients;
 
import com.titan.travelagent.TravelAgentRemote;
import com.titan.domain.Cabin;
 
import java.util.Properties;
import javax.naming.Context;
 
import javax.naming.InitialContext;
import org.junit.Test;
 
public class ClientTest {
 
    private static Context jndiContext = null;
 
    @Test
    public void main() {
        try {
            jndiContext = getInitialContext();
 
            //  String jndiName = "TravelAgentBean/remote";
            String jndiName = "TravelAgentBeanRemote";
            Object ref = jndiContext.lookup(jndiName);
 
            TravelAgentRemote dao = (TravelAgentRemote) ref;
 
            Cabin cabin_1 = new Cabin();
            cabin_1.setId(1);
            cabin_1.setName("Master Suite");
            cabin_1.setDeckLevel(1);
            cabin_1.setShipId(1);
            cabin_1.setBedCount(3);
 
            dao.createCabin(cabin_1);
 
            Cabin cabin_2 = dao.findCabin(1);
            System.out.println(cabin_2.getName());
            System.out.println(cabin_2.getDeckLevel());
            System.out.println(cabin_2.getShipId());
            System.out.println(cabin_2.getBedCount());
 
        } catch (javax.naming.NamingException ne) {
            ne.printStackTrace();
        }
    }
 
    public static Context getInitialContext()
            throws javax.naming.NamingException {
        InitialContext context = null;
        Properties props = new Properties();
        props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
                "org.apache.openejb.client.LocalInitialContextFactory");
        context = new InitialContext(props);
 
        return context;
    }
}
  • 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.

]]> http://www.redstream.nl/2009/05/18/ejb3-with-jboss5-and-maven2-part-3/feed/ 0 EJB3 with JBoss5 and Maven2 (part 2) http://www.redstream.nl/2009/05/08/ejb3-with-jboss5-and-maven2-part-2/ http://www.redstream.nl/2009/05/08/ejb3-with-jboss5-and-maven2-part-2/#comments Fri, 08 May 2009 18:49:54 +0000 Pascal Alma http://www.pascalalma.net/?p=799 Continue reading →]]>

As I stated here I see three levels of using Maven2 to build and deploy your EJB3 application with JBoss5 as application server. The minimal use of Maven I have described here, in this post I will extend the role of Maven so you can use it for the deployment of the JEE application too. I will also show how to create a client class in Netbeans to test your deployment. To show this I will extend the example I used in the previous post.
To make use of Maven for the deployment I added a new module to my project: jboss-ear. With this module I will create an ear file for the ch4 module and use this plugin to deploy the ear to JBoss (I wasn’t able to deploy the ejb-jar directly with the plugin so hence the extra module). The module is very basic and only contains a pom file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>net.pascalalma.jboss</groupId>
    <artifactId>jboss-ear</artifactId>
    <packaging>ear</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>jboss-ear</name>
    <dependencies>
        <dependency>
            <groupId>net.pascalalma.jboss</groupId>
            <artifactId>ch4</artifactId>
            <type>ejb</type>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-ear-plugin</artifactId>
                <configuration>
                    <displayName>Ch4 Services</displayName>
                    <description>All EJBs for a chapter</description>
                    <version>1.4</version>
                    <modules>
                        <ejbModule>
                            <groupId>net.pascalalma.jboss</groupId>
                            <artifactId>ch4</artifactId>
                        </ejbModule>
                    </modules>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jboss-maven-plugin</artifactId>
                <configuration>
                    <jbossHome>${jboss.home}</jbossHome>
                    <serverName>default</serverName>
                    <port>8080</port>
                </configuration>
            </plugin>
        </plugins>
        <finalName>${artifactId}</finalName>
    </build>
</project>

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package com.titan.clients;
 
import com.titan.travelagent.TravelAgentRemote;
import com.titan.domain.Cabin;
 
import javax.naming.Context;
 
import javax.naming.InitialContext;
import org.junit.Test;
 
public class Client {
 
    private Context jndiContext = null;
 
    @Test
    public void mainTest() throws Exception {
        try {
            jndiContext = getInitialContext();
 
            String jndiName = "jboss-ear/TravelAgentBean/remote";
 
            Object ref = jndiContext.lookup(jndiName);
 
            TravelAgentRemote dao = (TravelAgentRemote) ref;
 
            Cabin cabin_1 = new Cabin();
            cabin_1.setId(1);
            cabin_1.setName("Master Suite");
            cabin_1.setDeckLevel(1);
            cabin_1.setShipId(1);
            cabin_1.setBedCount(3);
 
            dao.createCabin(cabin_1);
 
            Cabin cabin_2 = dao.findCabin(1);
            System.out.println(cabin_2.getName());
            System.out.println(cabin_2.getDeckLevel());
            System.out.println(cabin_2.getShipId());
            System.out.println(cabin_2.getBedCount());
 
        } catch (javax.naming.NamingException ne) {
            ne.printStackTrace();
        }
    }
 
    public static Context getInitialContext()
            throws javax.naming.NamingException {
       return new InitialContext();
    }
}

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.

]]> http://www.redstream.nl/2009/05/08/ejb3-with-jboss5-and-maven2-part-2/feed/ 0 EJB3 with JBoss5 and Maven2 http://www.redstream.nl/2009/05/03/ejb3-with-jboss5-and-maven2/ http://www.redstream.nl/2009/05/03/ejb3-with-jboss5-and-maven2/#comments Sun, 03 May 2009 07:02:05 +0000 Pascal Alma http://www.pascalalma.net/?p=762 Continue reading →]]>

Although I am pretty familair with EJB3 I decided to get prepared for my next certificate SCBCD by going through the book ‘Enterprise JavaBeans 3.0‘ by Burke and Monson-Haefel. A good thing about the book is that they added a ‘workbook’ in which exercises and coding examples are described. However, there is also a ‘disadvantage’ and that is that they use Ant to do the building, deploying and running of the code. And they use JBoss4.0 as an application server, which was the logical choice when the book came out, I guess, but is outdated nowadays. So I decided to rewrite the example a little as an exercise by making use of Maven2 for the building and deploying and do this on JBoss5.0.1 that has been released a few weeks ago.
While creating the Maven builds for the first chapter I discovered there are actually several ways to do this, depending on the extend you want to use Maven for this:

  1. Minimal use of Maven

    2. 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

    3. 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

    4. 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:

      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:

      1
2
3
4

      xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
    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://www.redstream.nl/2009/05/03/ejb3-with-jboss5-and-maven2/feed/ 22 Using StAX Parsing with JBoss4.0.5.GA http://www.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/ http://www.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 Continue reading →]]>

    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:

    1
2
3
4
5
6
7
8
9

    <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Header/>
   <env:Body>
      <env:Fault>
         <faultcode>env:Server</faultcode>
         <faultstring>Operation only supported for javax.xml.soap.Node, this is a [#comment: Test comment]</faultstring>
      </env:Fault>
   </env:Body>
</env:Envelope>


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

    1
2
3
4
5
6
7
8
9
10
11

    <dependency>
    <groupId>com.sun.xml.messaging.saaj</groupId>
    <artifactId>saaj-impl</artifactId>
    <version>1.3</version>
</dependency>
<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>activation</artifactId>
    <version>1.1</version>
    <scope>provided</scope>
</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:

    1
2
3
4
5
6
7
8
9

    <soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-ENV:Header/>
   <soap-ENV:Body>
      <hr:HolidayResponse xmlns:hr="http://www.redstream.nl/hr/schemas">
         <!--Test comment-->
         <hr:Status>APPROVED</hr:Status>
      </hr:HolidayResponse>
   </soap-ENV:Body>
</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://www.redstream.nl/2008/06/18/using-stax-parsing-with-jboss405ga/feed/ 0     Creating an EJB3 WebService with Maven2 running on JBoss 4.2.1 http://www.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ http://www.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/ Continue reading →]]>

    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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

    <settings>
  <localRepository>d:/maven2/repo/</localRepository>
  <profiles>
    <profile>
      <id>default-repositories</id>
      <repositories>
        <repository>
          <id>global</id>
          <name>External Mirror of Central Repository</name>
          <url>http://repo1.maven.org/maven2</url>
        </repository>
        <repository>
          <id>repo.maven</id>
          <url>http://repo1.maven.org/maven2-repoclean-java.net</url>
        </repository>
        <repository>
          <id>jboss.maven</id>
          <url>http://repository.jboss.com/maven2/</url>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>repo1org</id>
          <name>External Plugin Repository</name>
          <url>http://repo1.maven.org/maven2/</url>
        </pluginRepository>
      </pluginRepositories>
    </profile>
    <profile>
      <id>property-overrides</id>
      <properties>
        <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home>
      </properties>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>property-overrides</activeProfile>
    <activeProfile>default-repositories</activeProfile>
  </activeProfiles>
</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:

    1
2
3
4
5
6
7
8
9

    package net.pascalalma.services;
 
import javax.ejb.Remote;
 
@Remote
public interface EchoService {
 
	public String sayHello(String subject);
}

    and the implementation:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14

    package net.pascalalma.services.impl;
 
import javax.ejb.Stateless;
 
import net.pascalalma.services.EchoService;
 
@Stateless
public class EchoServiceBean implements EchoService {
 
	public String sayHello(String name)
	{
		return "Hi " + name + "!";
	}
}

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

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>net.pascalalma</groupId>
	<artifactId>my-ejb-project</artifactId>
	<version>1.0</version>
	<packaging>ejb</packaging>
 
	<build>
		<sourceDirectory>src/main/java</sourceDirectory>
		<finalName>my-ejb-project</finalName>
		<plugins>
			<plugin>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.5</source>
					<target>1.5</target>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-javadoc-plugin</artifactId>
				<configuration>
					<classpath>/src/main/java</classpath>
				</configuration>
			</plugin>
			<plugin>
				<artifactId>maven-ejb-plugin</artifactId>
				<configuration>
					<ejbVersion>3.0</ejbVersion>
					<archive>
						<manifest>
							<addClasspath>true</addClasspath>
						</manifest>
					</archive>
				</configuration>
			</plugin>
		</plugins>
	</build>
	<dependencies>
		<dependency>
			<groupId>org.apache.geronimo.specs</groupId>
			<artifactId>geronimo-jpa_3.0_spec</artifactId>
			<version>1.1</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.geronimo.specs</groupId>
			<artifactId>geronimo-ejb_3.0_spec</artifactId>
			<version>1.0</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.1</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
	<reporting>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-surefire-report-plugin</artifactId>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-jxr-plugin</artifactId>
			</plugin>
		</plugins>
	</reporting>
</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):

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>net.pascalalma</groupId>
	<artifactId>my-ear-project</artifactId>
	<packaging>ear</packaging>
	<version>1.0</version>
	<name>my-ear-project</name>
	<dependencies>
		<dependency>
			<groupId>net.pascalalma</groupId>
			<artifactId>my-ejb-project</artifactId>
			<version>1.0</version>
			<type>ejb</type>
		</dependency>
	</dependencies>
	<build>
		<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>jboss-maven-plugin</artifactId>
				<configuration>
					<jbossHome>${jboss.home}</jbossHome>
					<serverName>default</serverName>
					<port>8080</port>
				</configuration>
			</plugin>
			<plugin>
				<artifactId>maven-ear-plugin</artifactId>
				<configuration>
					<displayName>My EJB Component</displayName>
					<description>My EJB Component</description>
					<version>1.4</version>
					<modules>
						<ejbModule>
							<groupId>net.pascalalma</groupId>
							<artifactId>my-ejb-project</artifactId>
						</ejbModule>
					</modules>
				</configuration>
			</plugin>
		</plugins>
	</build>
</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:

    1
2
3
4
5
6
7
8
9
10
11

    package net.pascalalma.services;
 
import javax.ejb.Remote;
import javax.jws.WebService;
 
@Remote
@WebService()
public interface EchoService {
 
	public String sayHello(String subject);
}

    and the implementation class:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    package net.pascalalma.services.impl;
 
import javax.ejb.Stateless;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
 
import net.pascalalma.services.EchoService;
 
@Stateless
@WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService")
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT)
public class EchoServiceBean implements EchoService {
	@javax.jws.WebMethod()
	public String sayHello(String name)
	{
		return "Hi " + name + "!";
	}
}

    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:

    1
2
3
4
5
6

        <dependency>
      <groupId>xfire</groupId>
      <artifactId>xfire-jsr181-api</artifactId>
      <version>1.0-M1</version>
      <scope>provided</scope>
    </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:
    Soap request

    After sending the request we will get this respone:
    soap response

    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://www.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/feed/ 20     Classloader issue with JBoss 4.0.5GA http://www.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/ http://www.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/ Continue reading →]]>

    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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    <?xml version="1.0" encoding="UTF-8"?>
<!-- The JBoss service configuration file for the EAR deployer service.
$Id: ear-deployer.xml 60679 2007-02-19 21:35:39Z scott.stark@jboss.org $
-->
<server>
   <!-- EAR deployer, remove if you are not using ear deployments -->
   <mbean code="org.jboss.deployment.EARDeployer"
      name="jboss.j2ee:service=EARDeployer">
      <!-- A flag indicating if ear deployments should have their own scoped
      class loader to isolate their classes from other deployments.
      -->
      <attribute name="Isolated">false</attribute>
      <!-- A flag indicating if the ear components should have in VM call
      optimization disabled.
      -->
      <attribute name="CallByValue">false</attribute>
      <!-- A flag the enables the default behavior of the ee5 library-directory. If true,
      the lib contents of an ear are assumed to be the default value for library-directory
      in the absence of an explicit library-directory. If false, there must be an
      explicit library-directory.
      -->
      <attribute name="EnablelibDirectoryByDefault">true</attribute>
   </mbean>
</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:

    1
2
3
4
5
6
7
8

    <jboss-app>
  <loader-repository>
  net.pascalalma.appl:archive=my-app.ear
     <loader-repository-config>
     java2ParentDelegation=false
     </loader-repository-config>
  </loader-repository>
</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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

    <project>
  ...
  ...
  <build>
    <plugins>
       <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>jboss-maven-plugin</artifactId>
          <configuration>
                  <jbossHome>${jboss.home}</jbossHome>
                  <serverName>default</serverName>
                  <port>8080</port>
          </configuration>
       </plugin>
       <plugin>
          <artifactId>maven-ear-plugin</artifactId>
          <configuration>
             <displayName>My Application</displayName>
             <description>My apliation using HttpClient3.0.1</description>
             <version>2.3.1</version>
             <modules>
                <ejbModule>
                   <groupId>net.pascalalma</groupId>
                   <artifactId>
                      my-ejb-app
                   </artifactId>
                </ejbModule>
                <webModule>
                   <groupId>net.pascalalma</groupId>
                   <artifactId>
                      my-web-app
                   </artifactId>
                   <contextRoot>/my-app</contextRoot>
                </webModule>
             </modules>
             <jboss>
                <version>4</version>
                <loader-repository>
                  net.pascalalma.appl:archive=my-app.ear
                </loader-repository>
                <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
             </jboss>
             <archive>
                <manifest>
                   <addClasspath>true</addClasspath>
                </manifest>
             </archive>
          </configuration>
       </plugin>
    </plugins>
  </build>
</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://www.redstream.nl/2008/01/29/classloader-issue-with-jboss-405ga/feed/ 0     Back to Maven2 again http://www.redstream.nl/2007/10/16/back-to-maven2-again/ http://www.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/ Continue reading →]]>

    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/ . 
      1
2
3
4
5

      <settings>
  ...
  <localRepository>/path/to/local/repo/</localRepository>
  ...
</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.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

      <settings>
  .
  <proxies>
   <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.somewhere.com</host>
      <port>8080</port>
      <username>proxyuser</username>
      <password>somepassword</password>
      <nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
    </proxy>
  </proxies>
  .
  .
</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:

      1
2
3
4
5
6
7
8
9
10
11
12
13

      <settings>
  ...
  <mirrors>
   <mirror>
      <id>planetmirror</id>
      <name>Australian Mirror of http://repo1.maven.org/maven2/</name>
      <url>http://public.planetmirror.com/maven2/</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
        ...
  </mirrors>
  ...
</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:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14

    <build>...
		<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>jboss-maven-plugin</artifactId>
				<configuration>
					<jbossHome>${jboss.home}</jbossHome>
					<serverName>default</serverName>
					<port>8080</port>
				</configuration>
			</plugin>
		</plugins>
                ...
	</build>

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

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

      ...
  <profiles>
  ...
    <profile>
      <id>property-overrides</id>
        <properties>
          <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home>
        </properties>
    </profile>
  </profiles>
  <activeProfiles>
    ...
    <activeProfile>property-overrides</activeProfile>
  </activeProfiles>
  ...

    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://www.redstream.nl/2007/10/16/back-to-maven2-again/feed/ 5     Using a JBoss MBean in your web-application http://www.redstream.nl/2007/05/07/using-a-jboss-mbean-in-your-web-application/ http://www.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 Continue reading →]]>

    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!

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

     public int getMessageCountConsumer() {
      int messageCount = -1;
      try {
         MBeanServer server = org.jboss.mx.util.MBeanServerLocator.locateJBoss();
 
         // Get the MBeanInfo for the JNDIView MBean
         Hashtable props = new Hashtable();
         props.put("service", "Queue");
         props.put("name", "MyQueue");
         ObjectName name = new ObjectName("jboss.messaging.destination", props);
 
         messageCount = (Integer)(server.getAttribute(name, "MessageCount"));
 
      } catch (Exception e) {
         // Error is logged but process is not broken. Not that big problem.
         LOG.error("Error while getting messageCount:", e);
      }
      return messageCount;
   }
    ]]>     http://www.redstream.nl/2007/05/07/using-a-jboss-mbean-in-your-web-application/feed/ 1