3 Replies Latest reply on Nov 21, 2003 5:37 PM by genman

    JbossMQ "thin" client

    greigm

      I'm trying to produce a stand-alone Jboss mq client to be delievered over a low-bandwidth connection, therefore I would like to know if there is a minimal or "thin" set of client jars to allow the client app to connect. Currently I have to include
      concurrent.jar
      jboss-client.jar
      jboos-common-client.jar
      jboss-j2ee.jar
      jnp-client.jar

      Which total some 660Kb, is there a "thin" version around?

      Currently using Jboss version 3.2.2

      Thanks,

      Greig..

        • 1. Re: JbossMQ "thin" client

          Why not using SOAP? And then having a SOAP service on your server that would invoke JMS?

          That way you can have a thin client (SOAP libraries are available for lots of devices and languages)

          Any info, let me know.

          Regards,

          Stephane

          • 2. Re: JbossMQ "thin" client
            colinmadere

            I've asked this question before in other places when building a prototype JMS Applet. As far as I could find and from what responses I got there is no official or public distribution of a minimal class collection for thin JMS clients. Your other option is to pick through the jars yourself and include only the classes you will use. However, you may run into a Log4J dependancy unless you edit the sources :)

            Let us know if you find anything, in a few months I'll almost certainly have to do this myself...

            • 3. Re: JbossMQ "thin" client
              genman


              I think you can generate a list of all the classes in use when you are running your JMS client. I think the Java plugin can help you do this. There are probably tools for doing this as well. Anyway, once you have that list you can probably go about generating your own .jar files. One solution that comes to mind is "jar xf *.jar" everything into one directory, taking this list, and generating your own.

              If you are only sending messages, I would use SOAP or a Servlet call.