paul anderson created DIGESTER-179:
--------------------------------------
Summary: Digester 3 can require onerous configuration
Key: DIGESTER-179
URL: https://issues.apache.org/jira/browse/DIGESTER-179
Project: Commons Digester
Issue Type: Improvement
Affects Versions: 3.0
Environment: any
Reporter: paul anderson
here's the use-case for which Digester used to be perfectly suited, but which i
can no longer do unless I use Digester 2. First some background.
numerous schemas I have used from several vertical markets (healthcare,
finance, stocks, futures, options, ForEx) are very rich and generalized, able
to cover a very wide range of operations/data from that particular market.. For
example take a look at FixML.
it is often the case that one needs to write extractors that focus on a subset
of the data (in other words, on just a small set of the overall schema, even
though the incoming XML represents a much more rich set of data.
I used to be able to write very simple digester XML rules with
set-properties-rule, object-create-rule etc., without needing to spend long
excluding certain attributes (as I would have to do now if I used Digester 3).
All I had to do was have java beans that had the setters/properties that I
*wanted*, put in a few strategically placed set-properties-rules and my XML
would digest very easily. The advantage of this is that as XML schemas were
extended, the code would keep working for quite some time, since new attributes
didn't break the Digester.
Digester 3.1 breaks if there are attributes which are not represented by
properties in the beans. You have to explicitly call out every single attribute
in the XML that you want to ignore. If you don't ignore an attribute and there
is no matching property, then there are runtime errors. This means that the
addition of just one new attribute in a part of the XML that is already being
digested breaks the entire application.
The details are all written here:
http://mail-archives.apache.org/mod_mbox/commons-user/201402.mbox/%[email protected]%3e
--
This message was sent by Atlassian JIRA
(v6.2#6252)
