commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: Digester wildcard question
Date Mon, 20 Jun 2005 20:09:21 GMT
Ok, I played a bit and I think I'm fairly close...

I have the following code...

// ** sc is a valid ServletContext reference
String configFile = "/WEB-INF/config.xml";
Digester digester = new Digester();
digester.setValidating(false);
AppConfig ac = new AppConfig();
ac.setDigester(digester);
digester.push(ac);
digester.addCallMethod("config/*", "set", 0);
InputStream isConfigFile = sc.getResourceAsStream(configFile);
ac = (AppConfig)digester.parse(isConfigFile);

...AppConfig (condensed) looks like this...

public class AppConfig {
  private static HashMap configMap = new HashMap();
  private Digester digester;
  public void setDigester(Digester inDigester) {
    digester = inDigester;
  }
  public void set(String val) {
    configMap.put(digester.getCurrentElementName(), val);
  }
}

...AppConfig also contains an overriden toString() so I can display it
easily for debugging.  Just for completeness, here's the XML I'm trying to
parse...

<config>
 <item1>Value1</item1>
 <item2>Value2</item2>
 <item3>Value3</item3>
</config>

...So, the idea is simply that for each element encountered, I want an
entry in the configMap added, keyed by the element name (so,
item1="Value1", and so on), the idea being that I can support XML where I
don't know what elements will be there before-hand, aside from the root
guaranteed to be <config> and the structure to be "flat", i.e., no
elements nested in any element other than the root.

When I execute this, the configMap is empty at the end, so the values are
not getting set.  However, if I change...

digester.addCallMethod("config/*", "set", 0);

...to...

digester.addCallMethod("config/item1", "set", 0);
digester.addCallMethod("config/item2", "set", 0);
digester.addCallMethod("config/item3", "set", 0);

...then at the end, the configMap in fact does have three items in it,
each with the correct value.  So, in short, the wildcard specification is
not doing what I was hoping it would, everything else *appears* to be
working like I want.

So, the question is now simple: can wildcards be used in this fashion, or
is my expectation not correct?  If not, is there a way to configure the
rules to do what I'm trying to do?  If not, does this seem like a
reasonable enhancement to submit?

Thanks once again!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, June 20, 2005 2:01 pm, Frank W. Zammetti said:
> Hi... I went through the Digester docs, but couldn't find the answer to my
> specific question (although the answer seemed to be hinted at)... is it
> possible to have a matching pattern of simply "*" so that every element in
> the document being parsed fires the corresponding rule?
>
> What I'm trying to do is have a simple XML format with a list of elements:
>
> <myDoc>
>  <item1>11</item1>
>  <item2>22</item2>
>  <item3>33</item3>
> </myDoc>
>
> ... and I want to have a rule fire to take each of those and insert them
> in to a map (just a call to a generic setter), but without knowing
> before-hand that item1, item2 and item3 will be present (i.e., maybe it's
> item4, item5 and item6 instead).  So I figured just match "*" would do it,
> but am looking for verification.  TIA!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>


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


Mime
View raw message