"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Remy Maucherat wrote:
>>> You can get the attributes now by setting debug logging on
>>> o.a.t.u.IntrospectionUtils. It wouldn't be hard to do in general (e.g.
>>> make IntrospectionUtils.setAttribute return boolean instead of void, and
>>> warn in Digester.startElement if no rules are configured, but make the
>>> later configurable so that the TC shutdown digester doesn't produce a
>>> ton of warnings). However, it means that our fork of Digester
>>> increasingly moves away from c-d.
>>
>> This would be a great strategy (and there's no reason not to include it
>> in the current 6.0.x branch if it's simple). I'll play with it and see
>> what it does.
>
> After experimenting, this works great, but (there's a but) there's a
> glitch with the fake "className" attribute (or whatever replacement is
> used to pass to the object creation rule).
>
> I don't know how to avoid it in a simple way without a hack. Bill, any
> ideas ?
>
We're pretty consistant in our attribute names in server.xml, so while it
isn't the cleanest solution, it should work for us. How about adding to
Digester (depending on taste) either
setFakeAttributes(String [] names)
or
setFakeAttributes(List<String> names)
The second lets us hide the lookup in List.contains, the first makes the
caller simplier for a small list of exclusions. Then
Digester.addSetProperties can pass it on to the setPropertiesRule.
If this was for c-d, then we'd probably need:
setFakeAttributes(Map<Class, List<String>> names)
but that seems like overkill for our fork of Digester.
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
