Would be interesting to hear what your intention is to do this.
Classes are loaded in the order they are needed by the classloader resolving the dependencies. Well, nothing new for now ;-)
If you want to do something like preloading classes for classloader caching issue, try to deploy a service with your application which only calls getRescource on the classloader in your prefered order.
I actually do not know what the problem it. My MDB is not deployed correctly. When I recopy .jat file into deploy directory, after Jboss starts, it is deployed correctly.
How do I know it is not deployed correctly?
I do not see any error messages about incorrect deployment. It just does not accept messages (onMessage() is not called). And QueueDepth in the queue mbean shows non-zero value.
When I recopy .jar file, jboss redeploys the mdb, and the MDB reads the messages.
The same happens if I stop and start the MBD via jmx console.
I though some classes were not deployed in the right order. Any idea why?
Read the server.log to see if the bean is deployed correctly (no errors or warnings). Does the bean depend on any other services which are not present or have not been started.
I remember when copying large deployment units over a slow network JBoss started deploying after the file was created but it wasn't complete. But I didn't track this further down and you should see this in the server.log, too.
Can you reproduce this behaviour with a small testcase? If nothing of this works, try to post a bugreport on http://sourceforge.net .
Try changing your deploymentsorter in jboss-service.xml to scanner.PrefixDeploymentSorter and deploying your mdb with a number(ie. 1mdb.jar).
See if that works. If it does, great!
I had a similar problem, I ended up deploy 1persistance.jar, 2session.jar, 3mdb.jar etc to make it work. Same problem existed for .ears.
ioparra thank you very much.. I tried almost everything, but this seems really to work.. However, I think it is not a nice solution.. If anybody knows another way, please let "us" know,
If this works, then you are having issues with deployment order and class loading dependencies. By numbering, you're telling jboss to deploy in this specific order. Otherwise, jboss will just grab all your .jar files and deploy them in any random order.
I have found that deploying for the development environment in this fashion is acceptable, for production it is not. For production, we deploy using an ear. Then we specify entries in our jboss.xml for each ejb that has dependencies.
You could put clauses in your mdb.jar/META-INF/jboss.xml to depend on any other JMX-Name. That will hold off the deployment of your ejb. If you still have stack traces, then your mdb.jar may still be dependent on another jar making into the classloader.
You can include this jar in your META-INF/MANIFEST.MF(Class-Path: ) entry. Becareful though, you may end up with duplicate certificates because this jar is deployed twice. If that's the case, its already a known bug... :). For this reason, I recommend an ear.
Another option is to make everything 1 large jar. Sorta brutal if you have a large code base and many developers. I thought about this for a while, then opted out...
PS. If it STILL doesn't work, let me know. Also, if you are using xdoclet to create your descriptors, it doesn't support jboss.depends entries. I've already offered a patch for XDoclet to include this as a feature .
Before anyone asks: No, the order of entries in application.xml for ears does not define the order of deployment for the jars. Application.xml is parsed into a HashSet then iterated, the ordering is lost there.