11 Replies Latest reply on Jul 17, 2007 6:00 AM by Mark Little

    JMSRouter refactoring

    Daniel Bevenius Master

      Hi,

      we are using the JMSRouter and would like to use the setting of the correlation id which is now being done, or will after MR3 is released. More info about the correlation id can be found here http://jira.jboss.com/jira/browse/JBESB-652

      Now, this is all good except that we want to be able to set the property unwrap to true, and still have the correlation id set.
      This is currenlty not possible as unwrap will will extract the content of the Message's body (in AbstractRouter) and then pass that Object to JMSRouter's process method, hence the information from the Message object being lost and there is no way to set the outgoing messages correlation id to the Message objects ID.

      The way I would like it do be is that setting unwrap to true means that I want the content of the Message objects body to be routed and the setting of JMSProperties should be performed.

      The short term solution for this might be to change the createObjectMessage to be protected so that I can subclass it to suite my needs. But I think setting unwrap to true would be more logical, but other routers might depend on the current behaviour.
      Any thought?

      Thanks,

      Daniel

        • 1. Re: JMSRouter refactoring
          Mark Little Master

          Can you point me at some relevant code in the tree?

          • 2. Re: JMSRouter refactoring
            Daniel Bevenius Master

            This is from AbstractRouter:

            public final Message process(Message message) throws ActionProcessingException {
             if(unwrap) {
             route(ActionUtils.getTaskObject(message));
             } else {
             route(message);
             }
            
             return null;
            }
            


            And JMSRouter route method is called with either the complete Message object when unwrap=false, and when unwrap=true with the contents of the Message objects body.

            Thanks,

            Daniel

            • 3. Re: JMSRouter refactoring
              Tom Fennelly Master

              Dan, it seems to me that the easiest thing to do would be to change the AbstractRouter.process method from being final and then just override all this behavior in the JMSRouter.

              • 4. Re: JMSRouter refactoring
                Mark Little Master

                Yes, I agree with Tom.

                • 5. Re: JMSRouter refactoring
                  Daniel Bevenius Master

                  Great. I'll do that.

                  Thanks,

                  Daniel

                  • 6. Re: JMSRouter refactoring
                    Daniel Bevenius Master

                    I'd like to add the ability for the JMSRouter to function as a splitter so that the action processing pipleline will continue processing.

                    <action name="route-to-response" class="org.jboss.soa.esb.actions.routing.JMSRouter">
                     <property name="jndiName" value="queue/XXXResponse"/>
                     <property name="unwrap" value="true"/>
                     <property name="continue-processing" value="true"/>
                    </action>
                    

                    Setting the property "continue-processing" to true would then make the process method, which has been overridden by JMSRouter, return the message object, which will cause the processing of the pipeline to continue.

                    I know that this is what a NotfiyJMS is for, but this would mean that I'd need to refactor the NotfiyQueue class so it can use the setting of correlation id that exists in JMSRouter. Plus I think there is a JIRA to refactor the NotifyJMS classes anyway.

                    /Daniel



                    • 7. Re: JMSRouter refactoring
                      Mark Little Master

                      I'm concerned you're starting to mix requirements. We have splitter and aggregator capabilities elsewhere too.

                      • 8. Re: JMSRouter refactoring
                        Tom Fennelly Master

                        This sounds like wiretap to me. I think the whole area of routing messages off the bus (to ESB Message Unaware endpoints) is something that needs attention. We Gateways for getting messages on and the Notifiers and Routers (and possibly more) for getting them off. Grrr!!!

                        • 9. Re: JMSRouter refactoring
                          Mark Little Master

                           

                          "tfennelly" wrote:
                          This sounds like wiretap to me.


                          And I'm fairly sure we have that too.

                          I think the whole area of routing messages off the bus (to ESB Message Unaware endpoints) is something that needs attention. We Gateways for getting messages on and the Notifiers and Routers (and possibly more) for getting them off. Grrr!!!


                          Agreed, but we've already agreed that it's good enough for the 4.2GA release. So let's not go opening that up again ;-)

                          • 10. Re: JMSRouter refactoring
                            Daniel Bevenius Master

                             

                            I'm concerned you're starting to mix requirements. We have splitter and aggregator capabilities elsewhere too.

                            Yes, so am I. This was more of a desperate solution to get things working for me.

                            Should I use the Notifiers for this?
                            In this case I have to add the correlation stuff and that would require some refactoring of NotifyQueue and NotifyTopics. Is this alright?

                            I'll also check out the wiretap as I havn't done so yet.

                            thanks,

                            Daniel

                            • 11. Re: JMSRouter refactoring
                              Mark Little Master

                               

                              "beve" wrote:
                              I'm concerned you're starting to mix requirements. We have splitter and aggregator capabilities elsewhere too.

                              Yes, so am I. This was more of a desperate solution to get things working for me.

                              Should I use the Notifiers for this?
                              In this case I have to add the correlation stuff and that would require some refactoring of NotifyQueue and NotifyTopics. Is this alright?

                              I'll also check out the wiretap as I havn't done so yet.


                              Definitely look at what's already there and then come up with a proposal for reusing (and possibly refactoring) what we have.