8 Replies Latest reply on Jul 1, 2010 12:08 PM by timfox

    new message types

    bill.burke

      Last I looked, message types are pretty static (ObjectMessage, etc...) and non-extendable.  I'd like the ability to plug in/register new object types at config and runtime.  I'm looking to add a HttpMessage and JaxrsMessage so that it is easier for REST consumers to go to and from Java code from text-based messages.

        • 1. Re: new message types
          clebert.suconic

          Honestly.. I don't know why JMS has so many message types.. you only need one which is BytesMessage.

           

          On our core-api, there is only Message, where you have a buffer exposed by HornetQBuffer.

           

          For large messages, you could also use streaming through our large message support:

           

          http://hornetq.sourceforge.net/docs/hornetq-2.1.0.Final/user-manual/en/html/large-messages.html

          • 2. Re: new message types
            bill.burke

            Let me give you and example of what I want to have as a feature of the HornetQ REST interface:

             

            1. python client posts JSON to HornetQ REST Topic.  REST Interface takes HTTP message and creates a new message type HttpMessage and stuffs in HTTP headers into properties designed to hold HTTP headers.  HTTP message body is stuffed in Message body.

             

            2. There is a ruby client that is pulling the topic as a consumer.  HornetQ takes the HttpMessage and converts it into an HTTP response as-is.

             

            3. There is also a Java client that wants to convert the JSON packet to a Java object using the RESTEasy->Jackson integration, so it does:

             

            onMessage(Message msg)

            {

               HttpMessage http = (HttpMessage)msg;

               MyObject obj = http.getBody(MyObject.class);

            }

             

            The HttpMessage is already initialized with apropriate marshallers, etc.  (in other words, it has pointers back to RESTEasy to obtain the unmarshaller required based on the MyObject.class passed in, and the content-type of the HTTP message).

             

            The idea of the HttpMessage is that

             

            1. Both JMS, HornetQ, and HTTP headers can be stuffed within a HornetQ message.  Consumers can easily iterate on JUST the HTTP headers

            2. RESTEasy factory objects don't have to be provided to Java consumers of HTTP messages

            • 3. Re: new message types
              clebert.suconic

              Your implementation will work with HornetQ only?

               

              You could have something like:

               

              new HTTPMessage(javax.jms.Message)

                 or

              new HTTPMessage(javax.jms.BytesMessage)

               

               

              That would work with any JMS Provider.

               

               

               

              If that doesn't work for you, I guess we could provide an extension on the JMS layer to provide extensions. (Maybe there's a way already. I will look tomorrow for a way to you or any user to extend the JMS facade for specific messages)

              • 4. Re: new message types
                bill.burke

                Yet another reason why I want my own message type:  I can't put certain HTTP headers that contain a "-" within a JMS message property as they are illegal identifiers, i.e. "Content-Type".  If a user wants to post an ObjectMessage via JMS that is consumed by REST clients, they will have to know the magic.

                 

                I'll try using a wrapper object as you suggested or static method wrappers and see how that works out.  I just thought it might save a little typing for the user.

                 

                 

                BTW, my impl will only work with hornetq because I'll be using the core API to avoid messaging copying (ServerSession), to protect against dups, and so I can tailor the impl to clustering semantics.  I don't think I could create a truly generic REST interface that worked in a clustering scenario well.

                • 5. Re: new message types
                  clebert.suconic
                  BTW, my impl will only work with hornetq because I'll be using the core API to avoid messaging copying

                   

                  The core api doesn't have the concept of message types.  There is only Message with properties and a body.

                   

                  I didn't understand how you would put all together.

                  • 6. Re: new message types
                    timfox

                    Clebert Suconic wrote:

                     

                    The core api doesn't have the concept of message types.  There is only Message with properties and a body.

                     

                     

                    Wrong.

                     

                    Core message has a type field, specifically designed to distinguish different types of messages.

                    • 7. Re: new message types
                      clebert.suconic
                      Core message has a type field, specifically designed to distinguish different types of messages.

                       

                       

                      That's merely informative and only has a real use on JMS. There's no specific hierarchy of MessageTypes like there is on JMS. That's just a field, and that's different to what Bill is asking.

                      • 8. Re: new message types
                        timfox

                        I didn't say there was a hierarchy, but core DOES have a notion of message type