Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      It would be a very nice feature to apply selectors on the message body.
      Possibly using regexp, or XPath in case of TextMessages.
      The same for key/value pairs of MapMessage.

        Activity

        Hide
        rdohna added a comment -

        There may be use-cases, but I doubt that this is a good path to follow. It would add a lot of complexity to the spec, and the performance will probably be terrible, as providers can create something similar to an index on all properties, but not on the payload. And the message would have to be unpacked by every filter around, while it's not so easy to see if there could be messages that slip through all of your selectors... or be matched by more than one!

        Take it from a different perspective: You suggest regex and/or XPath. What if the content is JSON, or POJOs, or Byte-Arrays, or streamed messages, or ... You'd open up a can of worms where every use-case would require a change to the spec. So you'd have to find a generic form - some kind of filter SAM type seems a good option here. I put such filters exclusively into a content based router, i.e. it does not invoke the business code directly, but forwards the messages to several more specific destinations. This keeps the routing logic in one place where it's easier to make sure that there is no gap or overlap in your logic; and every message would have to be unpacked exactly two times, not up to n times with n selectors.

        Show
        rdohna added a comment - There may be use-cases, but I doubt that this is a good path to follow. It would add a lot of complexity to the spec, and the performance will probably be terrible, as providers can create something similar to an index on all properties, but not on the payload. And the message would have to be unpacked by every filter around, while it's not so easy to see if there could be messages that slip through all of your selectors... or be matched by more than one! Take it from a different perspective: You suggest regex and/or XPath. What if the content is JSON, or POJOs, or Byte-Arrays, or streamed messages, or ... You'd open up a can of worms where every use-case would require a change to the spec. So you'd have to find a generic form - some kind of filter SAM type seems a good option here. I put such filters exclusively into a content based router, i.e. it does not invoke the business code directly, but forwards the messages to several more specific destinations. This keeps the routing logic in one place where it's easier to make sure that there is no gap or overlap in your logic; and every message would have to be unpacked exactly two times, not up to n times with n selectors.
        Hide
        Nigel Deakin added a comment -

        As the previous comment said, we need to be wary of introducing features which are impossible for the JMS provider to implement efficiently. Message properties were invented to allow the provider to handle selectors on a limited amount of information without the need to unmarshall/uncompress/index the entire message payload.

        I'll raise it with the expert group after the early draft to see what views there are, especially from the representatives of JMS vendors. If you have any particular priorities please state them (and give as much justification as you can).

        Nigel

        Show
        Nigel Deakin added a comment - As the previous comment said, we need to be wary of introducing features which are impossible for the JMS provider to implement efficiently. Message properties were invented to allow the provider to handle selectors on a limited amount of information without the need to unmarshall/uncompress/index the entire message payload. I'll raise it with the expert group after the early draft to see what views there are, especially from the representatives of JMS vendors. If you have any particular priorities please state them (and give as much justification as you can). Nigel
        Hide
        Nigel Deakin added a comment -

        Following a discussion with the JSR 343 expert group, I am rejecting this proposal as it would be contrary to the way in which JMS is designed. Currently message selectors can be used to filter messages on the basis of application-defined message properties. JMS supports message properties expressly to avoid the need for the message selector mechanism to examine the message body, which might be inefficient.

        Closing this issue with a resolution of "Won't fix"

        Show
        Nigel Deakin added a comment - Following a discussion with the JSR 343 expert group, I am rejecting this proposal as it would be contrary to the way in which JMS is designed. Currently message selectors can be used to filter messages on the basis of application-defined message properties. JMS supports message properties expressly to avoid the need for the message selector mechanism to examine the message body, which might be inefficient. Closing this issue with a resolution of "Won't fix"
        Hide
        axel_podehl added a comment -

        I agree with closing this issue.

        The implementation of regexp or XPath filtering should be implemented by JMS providers, but can't be defined by the JMS standard. There are too many ways to define these filters and each regex or Xpath package used would have slight differences in syntax.

        Also, there's nothing preventing JMS providers to extend the notion of a JMS selector.
        In addition to supporting the standard JMS selector, a JMS provider can extend the notion of this selector.

        For example to apply the JMS selectors also on the properties of a MapMessages, there's an open source package: http://jamsel.sourceforge.net/

        In another product, you can use these types of JMS selector strings:

        ::regex::.trader=peter.
        ::xpath::/trade[trader='peter']
        ::request::fromTime=2002-12-31T14:15:16.123456

        Show
        axel_podehl added a comment - I agree with closing this issue. The implementation of regexp or XPath filtering should be implemented by JMS providers, but can't be defined by the JMS standard. There are too many ways to define these filters and each regex or Xpath package used would have slight differences in syntax. Also, there's nothing preventing JMS providers to extend the notion of a JMS selector. In addition to supporting the standard JMS selector, a JMS provider can extend the notion of this selector. For example to apply the JMS selectors also on the properties of a MapMessages, there's an open source package: http://jamsel.sourceforge.net/ In another product, you can use these types of JMS selector strings: ::regex::. trader=peter. ::xpath::/trade [trader='peter'] ::request::fromTime=2002-12-31T14:15:16.123456

          People

          • Assignee:
            Unassigned
            Reporter:
            koen.serneels
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: