1 2 Previous Next 15 Replies Latest reply on Jan 13, 2009 8:32 AM by Kevin Conner

    Getting the execution context of a BeanConfiguredAction

    Kent Damgaard Newbie

      I'm currently looking into logging from our ESBs.

      We are trying to reuse actions in different places in the flow of the ESB, for instance doing validations, but when an error occur we would like to have the action log the context in which the error occured.

      With the actions that are set up with a ConfigTree I can get the execution context from there at the start of the call to the process method, but since a BeanConfiguredAction does not have a ConfigTree I'm not sure how we can establish which context it has been instantiated in.

      Of course I could add a parameter named something like "context", but this could lead to problems if somebody does a copy/paste in jboss-esb.xml and forgets to change context to something new - in such a case we would have two actions logging the same context.

      So, are there another approach to this that I can use?

        • 1. Re: Getting the execution context of a BeanConfiguredAction
          Daniel Bevenius Master

          Hi,


          With the actions that are set up with a ConfigTree I can get the execution context from there at the start of the call to the process method, but since a BeanConfiguredAction does not have a ConfigTree I'm not sure how we can establish which context it has been instantiated in.

          The ConfigTree contains configuration time information and not execution time info. If you want to access this configuration time information from an action that implements BeanConfiguredAction, one way would be to override toString() in your actions and have it include this information.
          Is that this information that you are after?

          regards,

          /Daniel

          • 2. Re: Getting the execution context of a BeanConfiguredAction
            Kent Damgaard Newbie

             

            "beve" wrote:
            The ConfigTree contains configuration time information and not execution time info.


            From the experiments I've performed so far I'm able to get the name and category of the service at runtime, which is really what I need, to know which service the action is running inside.

            "beve" wrote:
            If you want to access this configuration time information from an action that implements BeanConfiguredAction, one way would be to override toString() in your actions and have it include this information.
            Is that this information that you are after?


            This would give me the memory address of the action, but if the same class is used in more than one service it would be difficult to correlate this to address to a service name. So if I understand your suggestion correctly this would not give me the information.

            • 3. Re: Getting the execution context of a BeanConfiguredAction
              Daniel Bevenius Master

               

              From the experiments I've performed so far I'm able to get the name and category of the service at runtime, which is really what I need, to know which service the action is running inside.

              Do you mean that you are accessing this information through the ConfigTree in this case?

              This would give me the memory address of the action, but if the same class is used in more than one service it would be difficult to correlate this to address to a service name.

              This is not what I mean. What I mean is that if you were interested in logging information that was specified in the actions configuration, say a URL, and your action implements BeanConfiguredAction, making sure that all your actions override toString() and include all fields that were set during initialization would let you access the same information. This only includes the fields that are set on the action. Attributes from from the service element like 'service-category' and 'service-name' would not be available.

              /Daniel

              • 4. Re: Getting the execution context of a BeanConfiguredAction
                Kent Damgaard Newbie

                 

                "beve" wrote:
                From the experiments I've performed so far I'm able to get the name and category of the service at runtime, which is really what I need, to know which service the action is running inside.

                Do you mean that you are accessing this information through the ConfigTree in this case?


                Yes, the method I use to get this info is like this:

                private String getLoggerName() {
                 StringBuffer loggerName = new StringBuffer("SchemaValidatorAction");
                
                 if (actionConfig != null) {
                 ConfigTree parent = actionConfig.getParent();
                 loggerName.append(":Action='" + actionConfig.getAttribute("action") + "'");
                 if (parent != null) { // Could happen if we are instantiated in a unit-test
                 loggerName.append(":ServiceName='" + parent.getAttribute("service-name") + "'");
                 loggerName.append(":ServiceCategory='" + parent.getAttribute("service-category") + "'");
                 }
                 }
                 return loggerName.toString();


                It seems to work ok, but only if called during process. If called in the constructor I have seen some strange behavior. I'm currently trying to set up a smaller sample project to see if I can isolate the cause of this.


                • 5. Re: Getting the execution context of a BeanConfiguredAction
                  Kent Damgaard Newbie

                  I should add that the actionConfig is set in the constructor like this

                  protected ConfigTree actionConfig;
                  
                   public SampleAction(ConfigTree config) {
                  
                   actionConfig = config;
                   }
                  


                  • 6. Re: Getting the execution context of a BeanConfiguredAction
                    Kent Damgaard Newbie

                    Did some further testing, my suspicions about a problem in the constructor proved to be a bug, so that part works.

                    Tried to see if it was possible to get a BeanConfiguredAction to instantiate with a ConfigTree, but it seems that it only works with a default constructor. It would be a nice addition if the BeanConfiguredAction was supplied with a ConfigTree if it supplied an additional constructor which took a ConfigTree as argument.

                    • 7. Re: Getting the execution context of a BeanConfiguredAction
                      Daniel Bevenius Master

                      Glad you found the solution to your first issue.

                      Tried to see if it was possible to get a BeanConfiguredAction to instantiate with a ConfigTree, but it seems that it only works with a default constructor. It would be a nice addition if the BeanConfiguredAction was supplied with a ConfigTree if it supplied an additional constructor which took a ConfigTree as argument.

                      Yes, I took a quick look and this will require a code change. If you like you can add a feature request here:
                      https://jira.jboss.org/jira/browse/JBESB

                      Thanks,

                      /Daniel

                      • 8. Re: Getting the execution context of a BeanConfiguredAction
                        Daniel Bevenius Master

                        I added a jira for this feature request: https://jira.jboss.org/jira/browse/JBESB-2267

                        This has been committed to the svn trunk. If you take a look at the custom_action quickstart and in particular this class:
                        http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/custom_action/src/org/jboss/soa/esb/samples/quickstart/customaction/CustomBeanConfigAction.java

                        As you can see if you specify any of the following fields(and setters) they will get injected:

                        serviceCategory
                        serviceName
                        serviceDescription
                        maxThreads
                        mep
                        

                        Please take a look and let us know if you are missing anything.

                        regards,

                        /Daniel



                        • 9. Re: Getting the execution context of a BeanConfiguredAction
                          Kent Damgaard Newbie

                           

                          "beve" wrote:
                          I added a jira for this feature request: https://jira.jboss.org/jira/browse/JBESB-2267

                          This has been committed to the svn trunk. If you take a look at the custom_action quickstart and in particular this class:
                          http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/custom_action/src/org/jboss/soa/esb/samples/quickstart/customaction/CustomBeanConfigAction.java

                          As you can see if you specify any of the following fields(and setters) they will get injected:
                          serviceCategory
                          serviceName
                          serviceDescription
                          maxThreads
                          mep
                          

                          Please take a look and let us know if you are missing anything.

                          regards,

                          /Daniel



                          Yay! :) This is really cool, thank you for the quick change.

                          I would like to suggest adding the name of the action as well. That would make it possible to log out the name of the action, which would make it easier to find the action in jboss-esb.xml, since in theory one could have the same action appear multiple times within one service.

                          • 10. Re: Getting the execution context of a BeanConfiguredAction
                            Daniel Bevenius Master

                             

                            I would like to suggest adding the name of the action as well.

                            Good idea. How about we map the name to 'actionName' to avoid conflicts with custom actions that have a name field?





                            • 11. Re: Getting the execution context of a BeanConfiguredAction
                              Kent Damgaard Newbie

                               

                              "beve" wrote:
                              I would like to suggest adding the name of the action as well.

                              Good idea. How about we map the name to 'actionName' to avoid conflicts with custom actions that have a name field?





                              Yes, that sounds likea good idea.

                              • 12. Re: Getting the execution context of a BeanConfiguredAction
                                Morten Hattesen Newbie

                                I don't feel comfortable with an API design of a BeanConfiguredAction, that injects certain configuration properties, if the bean happens to implement certain "magically named" setters, i.e.

                                setServiceCategory
                                setServiceName
                                setServiceDescription
                                setMaxThreads
                                setMep

                                I definately see the need for a BeanConfiguredAction to be able to get access to the configuration information, but I feel that using magic names is a poor API design practice.

                                Firstly, there is the risk of name clashes with actual action properties, which would lead to confusing (at best) behavior.

                                Secondly, the list of relevant configuration properties is not fixed, and must thus be maintained and expanded in the future.

                                I propose that an action that implements BeanConfiguredAction is instantiated with a ConfigTree constructor argument, if such a constructor is available.

                                This way you would achieve the best of both worlds: Access to the full ConfigTree and convenient action property injection.

                                It should also be possible to let a subclass of ActionPipelineProcessor/AbstractActionPipelineProcessor implement BeanConfiguredAction, and thus add the convenience of direct action property injection.


                                After reviewing the ESB action source code, I feel it would be a fairly trivial excercise to implement the behavior described above, had it not been for the fact that a BeanConfiguredAction instance has an entirely different lifecycle to that of an ActionPipelineProcessor instance, in that a new instance is created on every invocation of the process() method.

                                I will raise JIRA separate issues on the ActionPipelineProcessor/BeanConfiguredAction configuration issue as well as on the BeanConfiguredAction.

                                • 13. Re: Getting the execution context of a BeanConfiguredAction
                                  Daniel Bevenius Master

                                   

                                  I will raise JIRA separate issues on the ActionPipelineProcessor/BeanConfiguredAction configuration issue as well as on the BeanConfiguredAction.

                                  Sure, raise the jiras and we'll take a look.

                                  regards,

                                  /Daniel

                                  • 14. Re: Getting the execution context of a BeanConfiguredAction
                                    Kevin Conner Master

                                    The BeanConfiguredAction has the same instantiation behaviour as actions which do not implement any of the interfaces. This work was done by a community member and was done to satisfy his requirements.

                                    I agree that it would be better if it fitted into the normal behaviour but we should implement this as a different type of action. Any action keeping state must be linked into the pipeline lifecycle and the processException, processSuccess, initialise and destroy methods should all be supported.

                                    1 2 Previous Next