commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18673] New: - call-method-rule called AFTER set-next-rule executes
Date Thu, 03 Apr 2003 22:06:39 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18673>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18673

call-method-rule called AFTER set-next-rule executes

           Summary: call-method-rule called AFTER set-next-rule executes
           Product: Commons
           Version: 1.4 Final
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Digester
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: byron.guernsey@appl.ge.com


with Digester-xmlrules 1.4.1:

This seems counter-practical to me:  In XML such as:

<object-create-rule class="Library" />
<pattern value="Catalog">
  <call-method-rule methodname="setCatalogSold" paramcount="1" 
paramtypes="java.lang.Boolean" />
  <call-param-rule paramnumber="0" attrname="sold" />
</pattern>

<set-next-rule methodname="addCatalog">

parsing XML such as:

<Catalog sold="true">
  <other stuff>
</Catalog>

The Library.addCatalog() method is called BEFORE the call to 
Catalog.setCatalogSold(Boolean)

So if Library.addCatalog() does a check to see if the catalog has been sold, it 
would not get the attribute set to true.  Later the call would be made and that 
would change the attribute to true after its already been passed off to another 
object. 

The <set-properties-rule> makes the calls to the setter methods before the call 
by set-next-rule, however, it cannot typecast the parameters and simply calls 
bean-compliant methods.

My only choice is to create bean compliant interfaces or bean objects to pass 
into my root object. This is not impossible, but I don't fully understand why 
the call-method-rule is working like it is and whether its truly the intended 
behavior. (and if so, what possible use could the behavior have?)

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message