Digester wildcard question

Digester wildcard question

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:

... 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!

...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...

...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?

> 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: [hidden email]> For additional commands, e-mail: [hidden email]>
>

Re: Digester wildcard question

> 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!
>

The standard rule-matching engine (RulesBase) doesn't support this. It
allows leading wildcards (eg "*/item1"), but doesn't support a wildcard
on its own.

The ExtendedBaseRules class allows trailing wildcards, so "myDoc/*" will
match any direct child element of myDoc which is what you want I
believe. It also allows completely-wild expressions "*" and "!*". It
doesn't have any expression to specify "any descendant of myDoc". See
the javadoc for class ExtendedBaseRules for more info.

The RegExRules class is even more powerful (but slower).

There is a sneaky way of effectively supporting trailing-wildcard with
the standard RulesBase matching engine if you are writing your own rule;
the SetNestedElementRule class has an example of this. But
ExtendedBaseRules is probably what you are looking for.

Re: Digester wildcard question

Thank you *very* much Simon, that was exactly what I needed! I wound up
using "config/?" as the pattern, and that did the trick perfectly,
everything else worked as-is.

You know, Digester has always struck me as one of those things that is a
bit overwhelming for a while, but it really is one of the more
powerful and useful Commons projects out there.

Thank again!

Frank

Simon Kitching wrote:

> On Mon, 2005-06-20 at 14:01 -0400, Frank W. Zammetti wrote:
>
>>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!
>>
>
>
> The standard rule-matching engine (RulesBase) doesn't support this. It
> allows leading wildcards (eg "*/item1"), but doesn't support a wildcard
> on its own.
>
> The ExtendedBaseRules class allows trailing wildcards, so "myDoc/*" will
> match any direct child element of myDoc which is what you want I
> believe. It also allows completely-wild expressions "*" and "!*". It
> doesn't have any expression to specify "any descendant of myDoc". See
> the javadoc for class ExtendedBaseRules for more info.
>
> The RegExRules class is even more powerful (but slower).
>
> There is a sneaky way of effectively supporting trailing-wildcard with
> the standard RulesBase matching engine if you are writing your own rule;
> the SetNestedElementRule class has an example of this. But
> ExtendedBaseRules is probably what you are looking for.
>
> Regards,
>
> Simon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>
>
>
>
>

The idea, ultimately, is that I would be getting the value of
configClass from a context init param. So I want Digester to create an
instance of the named class, and then for each element encountered in
the XML file, call the appropriate setter.

Now, it sure looks to me like that bean has an item1 property :) I
tried making it public, just on a whim, but that made no difference (and
I'm kind of glad it didn't because that would have confused the hell out
of me!)

> Thank you *very* much Simon, that was exactly what I needed! I wound up
> using "config/?" as the pattern, and that did the trick perfectly,
> everything else worked as-is.
>
> You know, Digester has always struck me as one of those things that is a
> bit overwhelming for a while, but it really is one of the more powerful
> and useful Commons projects out there.
>
> Thank again!
>
> Frank
>
> Simon Kitching wrote:
>
>> On Mon, 2005-06-20 at 14:01 -0400, Frank W. Zammetti wrote:
>>
>>> 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!
>>>
>>
>>
>> The standard rule-matching engine (RulesBase) doesn't support this. It
>> allows leading wildcards (eg "*/item1"), but doesn't support a wildcard
>> on its own.
>>
>> The ExtendedBaseRules class allows trailing wildcards, so "myDoc/*" will
>> match any direct child element of myDoc which is what you want I
>> believe. It also allows completely-wild expressions "*" and "!*". It
>> doesn't have any expression to specify "any descendant of myDoc". See
>> the javadoc for class ExtendedBaseRules for more info.
>>
>> The RegExRules class is even more powerful (but slower).
>>
>> There is a sneaky way of effectively supporting trailing-wildcard with
>> the standard RulesBase matching engine if you are writing your own rule;
>> the SetNestedElementRule class has an example of this. But
>> ExtendedBaseRules is probably what you are looking for.
>>
>> Regards,
>>
>> Simon
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]>> For additional commands, e-mail: [hidden email]>>
>>
>>
>>
>>
>

Re: Digester wildcard question

Good call, making the methods non-static solved the problem.

I'm not sure how I feel about leaving it like that though, so I will go
off and check out the other suggestions you offered... I actually just
spent a few minutes playing with the CallMethodRule... I came up with
what I thought was a clever and elegant solution, but it doesn't seem to
work... I created the following class:

I thought it might be the same kind of static vs. non-static thing, but
I've tried the methods both static and non-static, made no difference.

I'm about ready to "give up" and just leave the methods non-static...
because the bean being populated stores static condfiguration
information though, it would be nicer to not have to instantiate it to
get at the config info. But. it's not the end of the world or anything.
But if you have any ideas about why the above didn't work, maybe there
is still a chance of not having to do that.

I will look at SetNestedPropertiesRule in a bit too, haven't got around
to that yet.

Frank

Simon Kitching wrote:

> Hi Frank,
>
> On Mon, 2005-06-20 at 22:13 -0400, Frank W. Zammetti wrote:
>
>>...and here is that class I'm trying to populate...
>>
>>public class SampleAppConfigBean {
>> private static String item1;
>> private static String item2;
>> private static String item3;
>> public static void setItem1(String val) {
>> item1 = val;
>> }
>
>
>>Now, it sure looks to me like that bean has an item1 property :)
>
>
> I'm guessing that the fact that the method is static is where the
> problem lies, because everything else looks good. The
> BeanPropertySetterRule really does expect the target properties to be
> valid javabean properties, which is different from there just being a
> setter method. Unfortunately Sun haven't clearly documented exactly what
> the rules are for javabean properties (at least anywhere I can find).
>
> You could try writing a trivial test class which calls
> java.beans.Introspector.getBeanInfo(SampleAppConfigBean) and see what
> java tells you the available bean properties are.
>
> I bet that setItem1 etc are not reported - and that if you make the
> methods non-static that they will be.
>
> If this is the case, and you really need these methods to be static then
> you could resort to using CallMethodRule instead of
> BeanPropertySetterRule, as CallMethodRule doesn't require its targets to
> comply with the javabean rules.
>
> Have you had a look at the SetNestedPropertiesRule? As its javadoc
> describes, it should handle the problem you have but with the standard
> RulesBase class (though it does require the target is a property like
> BeanPropertySetterRule does). Either approach is ok though...
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>
>
>
>
>

Re: Digester wildcard question

On Mon, 2005-06-20 at 23:59 -0400, Frank W. Zammetti wrote:

> Good call, making the methods non-static solved the problem.
>
> I'm not sure how I feel about leaving it like that though, so I will go
> off and check out the other suggestions you offered... I actually just
> spent a few minutes playing with the CallMethodRule... I came up with
> what I thought was a clever and elegant solution, but it doesn't seem to
> work... I created the following class:
>
> public class MyRule extends CallMethodRule {
> public MyRule() {
> super("");
> }
> public void body(String bodyText) throws Exception {
> String cem = digester.getCurrentElementName();
> methodName = "set" + cem.substring(0, 1).toUpperCase() +
> cem.substring(1);
> super.body(bodyText);
> }
> }
>
> And I did:
>
> digester.addRule("config/?", new MyRule());
>
> ...in the calling code. I got an exception that doesn't seem to make
> sense...
>
> SEVERE: End event threw exception
> java.lang.NoSuchMethodException: No such accessible method: setItem1()
> on object
> : jwp.sampleapp.SampleAppConfigBean
>
> I thought it might be the same kind of static vs. non-static thing, but
> I've tried the methods both static and non-static, made no difference.

I'm puzzled too. It's not terribly elegant but I don't see why it won't
work in your case.

>
> I'm about ready to "give up" and just leave the methods non-static...
> because the bean being populated stores static condfiguration
> information though, it would be nicer to not have to instantiate it to
> get at the config info. But. it's not the end of the world or anything.
> But if you have any ideas about why the above didn't work, maybe there
> is still a chance of not having to do that.
>

Rather than distort your design, I would suggest either:

(a)
Create your own Rule class based on the source for
BeanPropertySetterRule, but replacing all of the method lookup stuff
with a simple:
Method m = Config.class.getMethod(xmlElementName);
m.invoke(null, bodyText);
All your config methods seem to take strings so you don't need to worry
about type-conversion.

Digester is designed to allow custom rules to be written.

(b)
Turn your config object into a singleton. Instead of using
ObjectCreateRule, use FactoryCreateRule with a custom ObjectFactory
which simply returns the singleton object. It's still a change to your
design but not so radical.

> I will look at SetNestedPropertiesRule in a bit too, haven't got around
> to that yet.

It's probably only of theoretical interest in your case if you really
want static methods, as it does depend on BeanUtils.setProperty which
requires true bean properties and hence no static methods.

Re: Digester wildcard question

> Rather than distort your design, I would suggest either:
>
> (a)
> Create your own Rule class based on the source for
> BeanPropertySetterRule, but replacing all of the method lookup stuff
> with a simple:
> Method m = Config.class.getMethod(xmlElementName);
> m.invoke(null, bodyText);
> All your config methods seem to take strings so you don't need to worry
> about type-conversion.

I thought of that too... ironically, talking about elegance, I thought
that was less elegant than extending an existing class that already did
99% of what I wanted :)

> (b)
> Turn your config object into a singleton. Instead of using
> ObjectCreateRule, use FactoryCreateRule with a custom ObjectFactory
> which simply returns the singleton object. It's still a change to your
> design but not so radical.

I think that will actually put a bit more restrictions on the bean than
I'd like, although I certainly see your point.

I think because of what I'm really trying to do, I'm simply going to
document the fact that the setters of the bean must be non-static. The
getters can still be static, which is really the more important
consideration, and that's what I'll do for the sample bean I am doing.
In the end it will be a developers' choice, not mine, but as long as
they know this "limitation", minor as it is, I think that is OK. It
could even be argued it isn't really a limitation anyway, just a point
to document, and I think that's where I'm coming down on it in the end.

Thanks for all your help Simon, it has been absolutely invaluable! I've
learned more about Digester in the last few hours than in all the time
I've used it before :)