1 2 3 4 5 Previous Next 64 Replies Latest reply on Oct 2, 2009 2:43 PM by kconner Go to original post
      • 30. Re: XPath Routing
        tfennelly

        Oh and.... note I didn't create a new attribute declaring whether it's Drools, XPath etc rules. I reused the "cbrClass" attribute. It can be used to specify the fully qualified class name, or an alias e.g. "XPath", "Drools"/"JBrules" (default) etc etc.

        Also note that I purposely used the attribute name of "expression" on the rule element. I did this so we could use the same format for regex, or other solutions.

        • 31. Re: XPath Routing
          tfennelly

           

          "burrsutter" wrote:
          What does order-rules.properties look like?

          And will this support Wiretap use cases? A router skips other actions in the pipeline/chain. A wiretap allows them to execute, right?



          It's a .properties file:
          blue=/a:order/a:header[@cat='blue']
          red=/b:order/b:header[@cat='red']
          green=/c:order/c:header[@cat='green']


          It supports the same patterns as the current Drools impl. It uses the ContentBasedWiretap class.

          • 32. Re: XPath Routing
            burrsutter

            For the inline use case, can we do away with the destination-name concept, it seems harder to use and doesn't add significant value.

            <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
             <property name="cbrClass" value="XPath"/>
             <property name="ruleSet">
             <rule target-service="OrderCategory:BlueService" expression="/order/header[@cat='blue']" />
             <rule target-category="OrderCategory" target-service="RedService"" expression="/order/header[@cat='red']" />
             </property>
            </action>
            


            A couple of other points: I don't think "cbrClass" makes sense for the value of XPath but I don't have a better suggestion.

            I think property named "ruleSet" sounds a little strange for XPath users, since they have no knowledge of rules, just XPath expressions.

            One thing to keep in mind, XPath and/or Regex routers are the "default" router/wiretaper/filter, Rules-based routers will be considered the advanced options for only when the complexity rises to need that solution.

            Our Getting Started experience should start with XPath/Regex & XSLT with Rules-based CBR/Filter and Smooks-based Transformations being for more advanced use cases.

            • 33. Re: XPath Routing
              tfennelly

               

              "burrsutter" wrote:
              For the inline use case, can we do away with the destination-name concept, it seems harder to use and doesn't add significant value.
              <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
               <property name="cbrClass" value="XPath"/>
               <property name="ruleSet">
               <rule target-service="OrderCategory:BlueService" expression="/order/header[@cat='blue']" />
               <rule target-category="OrderCategory" target-service="RedService"" expression="/order/header[@cat='red']" />
               </property>
              </action>
              



              Ah yes... very good suggestion Burr... we should be able to do that. I guess we'll also need to also support what I already proposed if we want all this ContentBasedRouting stuff to be consistent?

              "burrsutter" wrote:
              A couple of other points: I don't think "cbrClass" makes sense for the value of XPath but I don't have a better suggestion.


              Right... well cbrClass already exists and my thinking was that if we introduced another property then we'd have to start raising errors if the user configured both, which seems ugly to me.

              "burrsutter" wrote:
              One thing to keep in mind, XPath and/or Regex routers are the "default" router/wiretaper/filter, Rules-based routers will be considered the advanced options for only when the complexity rises to need that solution.

              Our Getting Started experience should start with XPath/Regex & XSLT with Rules-based CBR/Filter and Smooks-based Transformations being for more advanced use cases.


              Right... I know I said it already (indirectly perhaps :) ), but I actually think there would be less confusion for the user if we made a clean break from the ContenBasedRouter action config. We could still use the same underlying code. I think there's nothing more confusing for things to look "nearly the same", but for them to not really be the same and to have subtle little differences that need to be explained in parallel.

              • 34. Re: XPath Routing
                edgarsilva

                Good point guys!

                Do you think could be valuable also add some "searching into collections", and use JXPath: http://commons.apache.org/jxpath/

                This is my 2 cents :D

                Cheers

                Edgar

                • 35. Re: XPath Routing
                  kconner

                   

                  "tfennelly" wrote:
                  Right... I know I said it already (indirectly perhaps :) ), but I actually think there would be less confusion for the user if we made a clean break from the ContenBasedRouter action config. We could still use the same underlying code. I think there's nothing more confusing for things to look "nearly the same", but for them to not really be the same and to have subtle little differences that need to be explained in parallel.

                  And it could also be argued that it is confusing to have multiple different actions doing the same job (content based routing). We could spend a long time arguing back and forwards about the merits of each when

                  - we don't have the time
                  - they are functionally equivalent.

                  We are not creating another mechanism when the original author has already added one. Okay, it is not as clean as I would have liked and may not have been how we would do it but it does exist and we will use it.

                  We also do *not* have to use the same attributes as the drools version if they do not make sense. As I already pointed out the extension mechanism passes the configuration through to the implementation.

                  Kev


                  • 36. Re: XPath Routing
                    kconner

                     

                    "tfennelly" wrote:
                    Oh and.... note I didn't create a new attribute declaring whether it's Drools, XPath etc rules. I reused the "cbrClass" attribute. It can be used to specify the fully qualified class name, or an alias e.g. "XPath", "Drools"/"JBrules" (default) etc etc.

                    Create a new attribute, it serves a different purpose. I thought this had already come up but may be mistaken.

                    Kev

                    • 37. Re: XPath Routing
                      kconner

                       

                      "tfennelly" wrote:
                      Right... well cbrClass already exists and my thinking was that if we introduced another property then we'd have to start raising errors if the user configured both, which seems ugly to me.


                      Which is what we should be doing. Ugly is forcing the same attribute to have multiple meanings.

                      Kev

                      • 38. Re: XPath Routing
                        kconner

                         

                        "tfennelly" wrote:
                        Kev, how do you want this to behave if the user specifies a value for the cbrClass, as well as a value for this new attribute?

                        Throw an exception if both are specified, they should be exclusive.

                        Kev

                        • 39. Re: XPath Routing
                          kconner

                           

                          "tfennelly" wrote:
                          Martin, would you be OK with putting this one on the back boiler for now? We can always add it later.

                          I agree with this, we should defer this until later so that we can have time to think about the consequences.

                          The current work is only concerned with duplicating the CBR functionality but using xpath/regexp in place of drools.

                          Kev

                          • 40. Re: XPath Routing
                            tfennelly

                            OK Kev... I'm happy to do things your way. Sorry for bringing up other points.

                            • 41. Re: XPath Routing
                              bfitzpat

                              I have a couple of concerns.

                              #1 - Sounds like it would change the "Add Content Based Router" wizard in the ESB Editor. If so, that may require some development time. What's the time frame here?

                              #2 - How would it affect existing users? Would we offer to update older ContentBasedRouter configs to the new format? Would we invalidate any existing configurations? If we're breaking older folks, we need to provide a path to upgrade them to the new stuff.

                              --Fitz

                              _______________________________
                              Brian Fitzpatrick (aka "Fitz")
                              Senior Software Engineer, SOA-P
                              JBoss by Red Hat

                              • 42. Re: XPath Routing
                                kconner

                                 

                                "bfitzpat" wrote:
                                I have a couple of concerns.

                                #1 - Sounds like it would change the "Add Content Based Router" wizard in the ESB Editor. If so, that may require some development time. What's the time frame here?

                                Yes, but I would expect that to be the case regardless. This is slated for the ESB 4.7 project release and then into the SOA 5 platform.

                                "bfitzpat" wrote:
                                #2 - How would it affect existing users? Would we offer to update older ContentBasedRouter configs to the new format? Would we invalidate any existing configurations? If we're breaking older folks, we need to provide a path to upgrade them to the new stuff.


                                There is no reason why this should break existing configurations and I would consider it a bug if it does. Those should run unmodified.

                                Kev

                                • 43. Re: XPath Routing
                                  kconner

                                   

                                  "Kevin.Conner@jboss.com" wrote:
                                  There is no reason why this should break existing configurations

                                  I should have qualified that as 'no technical reason'.

                                  Kev

                                  • 44. Re: XPath Routing
                                    tfennelly

                                    Kev... when you get a chance... outline the exact configuration you want to see for this please. Thanks.