commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barney Barumba (JIRA)" <>
Subject [jira] [Created] (DIGESTER-181) Replace stack object with result from CallMethod rule
Date Wed, 31 Dec 2014 09:57:13 GMT
Barney Barumba created DIGESTER-181:

             Summary: Replace stack object with result from CallMethod rule
                 Key: DIGESTER-181
             Project: Commons Digester
          Issue Type: Improvement
    Affects Versions: 3.2
         Environment: Linux x_86_64, JDK 1.7.0_65
            Reporter: Barney Barumba

I'd like to suggest the following addition to the digester: a new flag on the CallMethodRule
to replace the top object on the digester stack with the results of the method call.

Additions to CallMethodRule:
++  protected boolean replaceStackObject;

    public void end( String namespace, String name ) throws Exception
        // standard invoke code...

        result = invoke...

++      if (replaceStackObject)
++      {
++          getDigester().pop();
++          getDigester().push( result );
++      }

        processMethodCallResult( result );

Usage would then be something like:
    public class WidgetBuilder
        // standard bean getters, setters, methods...

        public Widget build()
            return new Widget(...);

    public class WidgetRules extends AbstractRulesModule
        protected void configure()

My use case is implementing the builder pattern as above, but I could see this as a generally
useful construct for other things too. Also, it seems a fairly uninvasive change: if you ignore
the new flag you get the current behaviour.

I've currently implemented this as my own rule, which works for my case:
    public class CallMethodReplaceRule extends CallMethodRule
        public CallMethodReplaceRule(String methodName)

        protected void processMethodCallResult(Object result)
            getDigester().push( result );
but I think the additional parameter to the CallMethodRule seems a better general solution,
and would then allow the fluent rule creation style, which is much harder with custom rules.

If anyone thinks this would be useful then I'm happy to come up with a full patch, but as
I have a simple workaround for my specific case I haven't bothered with this yet.

This message was sent by Atlassian JIRA

View raw message