10 Replies Latest reply on Sep 22, 2006 9:58 AM by Tom Fennelly

    Action Processing Pipelines, updated Trailblazer etc...

    Tom Fennelly Master

      This code is all checked into the trunk and documented (to some extent :-) ) on the Wiki:
      http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

        • 1. Re: Action Processing Pipelines, updated Trailblazer etc...
          Kurt Stam Master

          Thanks Tom,

          Quick question, why are we using junit.framework.TestCase in production code? I'm looking at the JMSRouter.java

          --Kurt

          • 2. Re: Action Processing Pipelines, updated Trailblazer etc...
            Kurt Stam Master

            Also you have added BankQuoteRequest.java in the same package twice; once in the banks project and once in the loanbroker.banks. Seems like asking for trouble.. Can we at least make sure the packages are different? I don't think the loanbroker should have a *.loanbroker.bank package.

            --Kurt

            • 3. Re: Action Processing Pipelines, updated Trailblazer etc...
              Tom Fennelly Master

               

              "kurt.stam@jboss.com" wrote:
              Also you have added BankQuoteRequest.java in the same package twice; once in the banks project and once in the loanbroker.banks. Seems like asking for trouble.. Can we at least make sure the packages are different? I don't think the loanbroker should have a *.loanbroker.bank package.

              --Kurt


              Yeah, that class was sorta there twice already: one was called "BankQuoteRequest" and the other was called "BanksQuoteRequest". This seems like a mess to me also. It was causing grief when using XStream on both ends - the Bank code had a "BankQuoteRequest" class but not a "BanksQuoteRequest". Dunno how you were avoiding this issue before but either way I think they either need to chare a lib or else we can't use XStream on both ends of the wire.

              I'd also suggest that this is demo code, not "production" code :-)

              • 4. Re: Action Processing Pipelines, updated Trailblazer etc...
                Tom Fennelly Master

                 

                "kurt.stam@jboss.com" wrote:
                Thanks Tom,

                Quick question, why are we using junit.framework.TestCase in production code? I'm looking at the JMSRouter.java

                --Kurt


                Sorry Kurt, I replied in too much of a hurry last time and so got your 2 posts mixed up in my head - your ref to production code was wrt the JMSRouter class and you're 100% correct.

                For sure, there shouldn't be JUnit dependencies in production code and I've removed it in this case. JMSRouter was originally JUnit fixture code that I moved to production code - I forgot to remove that dependency. Thanks for spotting that and apologies for being so hasty in my last reply.

                • 5. Re: Action Processing Pipelines, updated Trailblazer etc...
                  Mark Little Master

                  Thanks Tom. Nice work. Now don't forget to add the documentation to the Programmers Guide ;-)

                  • 7. Re: Action Processing Pipelines, updated Trailblazer etc...
                    Kurt Stam Master

                    Yes the banks are using XStream, they are standalone bank applications. Why is the loanbroker now using XStream? We should be using our own marshalling implementation, why was this changed?

                    The BankQuoteRequest should not be the same class. These are independent systems and this will make the demo code confusing I think.

                    --Kurt

                    • 8. Re: Action Processing Pipelines, updated Trailblazer etc...
                      Tom Fennelly Master

                       

                      "kurt.stam@jboss.com" wrote:
                      Yes the banks are using XStream, they are standalone bank applications. Why is the loanbroker now using XStream? We should be using our own marshalling implementation, why was this changed?

                      I'm afraid I can't answer that one Kurt!! I just checked ProcessCreditResponse.java in the beta1 release and I can see now how this was able to work before. See in the sendJMSToBank method - it registers an alias such that org.jboss.soa.esb.samples.loanbroker.banks.BanksQuoteRequest gets mapped to org.jboss.soa.esb.samples.loanbroker.banks.BankQuoteRequest. Look really hard and you'll spot the difference. ObjectToXStream just uses the class name of the object passed in.

                      So, we can either remove XStream from one end or the other, or leave things as they are. There's no point going back to the beta1 way of doing things because that's no less confusing than it is now.

                      I'd go for removing XStream from the Bank code because ObjectToXStream is an OK demo of how to write reusable action processors. The demo isn't really about how to write banking systems using XStream.

                      "kurt.stam@jboss.com" wrote:

                      The BankQuoteRequest should not be the same class. These are independent systems and this will make the demo code confusing I think.


                      +1

                      Sounds like something to be added to JIRA :-)

                      • 9. Re: Action Processing Pipelines, updated Trailblazer etc...
                        Daniel Brum Novice

                        Guys, using XStream on both sides was just a convenience, nothing more. The TB is about showing how to use the Beta of the ESB features, nothing to do with writing banks and their systems, etc.

                        I would not bother with re-writing those aspects of the TB now.

                        • 10. Re: Action Processing Pipelines, updated Trailblazer etc...
                          Tom Fennelly Master

                           

                          "daniel.brum@jboss.com" wrote:
                          Guys, using XStream on both sides was just a convenience, nothing more. The TB is about showing how to use the Beta of the ESB features, nothing to do with writing banks and their systems, etc.

                          I would not bother with re-writing those aspects of the TB now.


                          lol,.. too funny Dan! That's exactly what I said... "...we're not demoing writing banking systems ...". I changed it after anyway - XStream still on both sides but the classes are in different packages so peoples Eclipse etc doesn't complain about dup classes etc

                          Once I get the Transformation stuff in there (very close), I'll engineer the Trailblazer such that the XML generated on the Loanbroker side will require a transformation before sending to the Bank. That should add nicely to the Trailblazer!