HOW did you integrate jboss into your application??? You should not have to add jbossmq-client.jar to the classpath since all those classes are allready in jbossmq.jar. Integrating jboss can be tricky since it uses so many classloader tricks. I'm willing to bet you having some kind of classloader misconfiguration.
I used the template for jboss main function and start it
in a separate thread from inside our application main function. The problem I think is that I was trying to
run publishers/subscribers from jpython windows (available in our application) and for some reasons it
won't recognize some setting from the main application
classpath. Next, I will try to run it as a normal test
class. I think the client libraries are the same as the
server ones, but stripped down. Am I right ?
I don't know if you have an extension for JMS to support
hierarchical topics, if not I will need to build such a
module and if successful, I may submit it as jbossmq extension (eventually as a jmx bean).
Ok I think I have a solution for you. You need to
- create an URLClassloader and initialize it with just the run.jar (or whatever jar you have that starts up jboss embeded) and the jars in the /lib directory. Set the parent classloader to null (thats the important part)
- Use the URLClassloader to load the class that you start jboss with. Use reflection to invoke the method that starts jboss.
If you start jboss like this you should be able to use the jbossmq-client.jar in your application's classpath since it will not be in JBoss's boot classpath.
But even if you do this I'm not 100% sure that I will work with the JVM IL, but it should work with the other ILs.
I tried, and it worked partially. For run.jar that has
the jboss.Main is OK, but the problem is that Main need
classes from \lib and it tries to load them with the
default class loader. There is a way to change temporarly
the default class loader ? Or to load entire jar files ?
I'm almost giving up!
It seems that class (jar) loading in the jboss server is so tricky that is no way to create a jms client in the same JVM with the running jboss server.
Even if you are able to use server side jars to
start clients (from lib/ext/ instead of client/), by adding jars from lib/ext/ to application classpath (that starts jboss), screwed up completelly jboss and prevents it to start the JMS.
May be can help.
I have to say I doubt this. I have several "JMS clients" running in the same VM as JBoss, implemented as MBeans. A complete JMS based event system for example.
Can I have an example please ? Probably my problem came from the fact that I tried to embedd jboss inside our own
application, instead of running it standalone. That prevents (at least that seems) for my JMS clients to
access the jboss classes from lib/ext.
> I tried, and it worked partially. For run.jar that
> the jboss.Main is OK, but the problem is that Main
> classes from \lib and it tries to load them with the
> default class loader. There is a way to change
Check 2 things:
- 1. that run.jar is not in your application's classpath (cause then jboss.Main will be loaded by the default classloader) and
- 2. Are you sure you loaded the jboss.Main using a NEW URLClassloader with out a parent???
If you do not give it a parent then there is no way that the Main can try to use the default classloader for anything.
> Check 2 things:
> - 1. that run.jar is not in your application's
> classpath (cause then jboss.Main will be loaded by
> the default classloader) and
> - 2. Are you sure you loaded the jboss.Main using a
> NEW URLClassloader with out a parent???
> If you do not give it a parent then there is no way
> that the Main can try to use the default classloader
> for anything.
I did both, but it seems that just not work in that way.
Here is the javadoc for URLClassLoader:
for URLClassLoader( URL urls):
Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader. The URLs will be searched in the order specified for classes and resources after first searching in the parent class loader. Any URL that ends with a '/' is assumed to refer to a directory. Otherwise, the URL is assumed to refer to a JAR file which will be downloaded and opened as needed.
for URLClassLoder( URL urls, ClassLoader parent):
Constructs a new URLClassLoader for the given URLs. The URLs will be searched in the order specified for classes and resources after first searching in the specified parent class loader. Any URL that ends with a '/' is assumed to refer to a directory. Otherwise, the URL is assumed to refer to a JAR file which will be downloaded and opened as needed.
So if you don't set the parent class loader or set it to null, it seems it will use the bootstrap class loder.
So you cannot separate the client classpath from the jboss
classpath. My question is why they clash ? The client classes cannot be just a subset of the server and if you use the server one, that could be fine for everyone ?
Now I shall run jboss in his own process, in order to use
the JMS client, so I cannot embedd jboss into our application. Any help will be welcomed.
Why don't you run your application as an mbean inside jboss?
I started our application as JMX MBean, and everything went fine.
Hiram, what's the problem with JVM IL ? If properly implemented could speed a lot the messages between components in the same JVM. I did some simple bench tests,
and I get around 10ms per message in the same JVM, 20-40ms per message for the client in a different JVM but the same machine, 150-200ms for the client in a different JVM on a different machine. We use mostly intra JVM messaging.
IF your app is running as an MBean, then the JVM IL should work for you. Don't include the jbossmq-client.jar in the yoiur MBean's classpath.
How does JBossMQ handle the I/O for JMS clients in the same JVM as the JMS server? Does it actually create a new socket? Or does it bypass that somehow?
It bypasses the sockets. The client JMS API does direct method calls into the server.
Note that message content is still serialized since the JMS spec requires pass by value sematics. the JVM IL just gives you an edge over the other ILs since the method call is not serialized.