"mteira" wrote : While I wait for your answer, here is the link to one of the problems I've found: | http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92188 | | That will probably have to do with the classloading. By default, .war's are loaded in a separate classloading environment that can see the libraries in the server's lib folder and the classes and libs defined in the .war's itself. .ears have a different classloading mechanism. By default, the .ear's are loaded in the global classpath. (Meaning that they share the same classloader repository as the global classloader). So classes in .ear files will be visible to the global classpath and classes in .war files are not (by default). I'm not yet sure, but i can only expect that this problem somehow must boil down to that. "mteira" wrote : I'm thinking that perhaps a workaround could be to comment out the 'web' descriptor in the application.xml ear file, and deploy into my jboss both the console war and the jbpm.ear. | | if that works for you, it could be a temporary workaround. "mteira" wrote : | Is there any code in the repository to test the JMS service messaging from the client side? | indeed. i was busy trying to create the .ear packaging when i got interrupted in this line of work. so here's the todo in the sequence that i had in mind: 1) create a decent .ear packaging with jbpm and the mdb and the slsb. the packaging should also contain the configuration that binds the jbpm messaging service to JMS. 2) create a test set up so that messaging can be tested. i got started on this by incorporating cactus. i have one cactus test somewhere that is able to print a log message inside of jboss. 3) create test cases that execute processes with async="true" and run these inside of the container and check if the JMS queues contain the proper jobs. "mteira" wrote : | Looking at the code it seems to me that what I need is to create those Command subclass object (for example, a NewProcessInstanceCommand) and just send it to the queue where the CommandListener MDB is attached. | yes. "mteira" wrote : | Anyway, as the Command subclasses don't have a constructor, and a lot of getter and setter methods, I'm not sure of what setter methods should be invoked to create a valid Command object, but I suppose that it depends on the subclass I'm using. | use the setters. the commands are a work in progress. note that the use cases for commands are still being discovered/examined. e.g. relation between web services and commands still needs to be worked out in detail. it could be that the commands will be subject to change. after the use cases for commands become clear and they have stabilized a bit, we can start creating convenience constructors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976921#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...