Suggested experiment: Put a copy of the tiles DTD on your
drive. Edit the XML file you were digesting to change the
system id (the http url), and replace it with the path to
the file on your system. If the problem goes away then it
means you got a less-than-useful message disguising the real
It sounds like one of two things:
1) in the jar'd configuration something is missing from the classpath
2) in the jar'd configuration you aren't using the same type of
classloaders as you are in the non-jar'd configuration
(e.g. not just jar vs non-jar, but jar-in-webapp vs
Are you really sure that both logs
are from an attempt to process the
same file? They don't look like they
correspond at all. Sounds silly, but
is one of these the wrong log? Was
wondering if maybe one was actually
an old log, not one created as a result
of whatever you were trying to test.
I'm pretty sure that the XML parsing activity
is not thread-safe. Nothing to do with the
Digester code, I just remember reading cautions
with parsers like Xerces that they aren't
threadsafe.
Practically I don't think it would make sense
for a digester to be threadsafe. A digester is
an
The class below should get you output like:
adamOrEve name=bob
adamOrEve #children=2
adamOrEve first child name=joe
adamOrEve second child name=sue
import org.apache.commons.digester.*;
import java.io.*;
import java.util.*;
public class ParentExample {
public static
I haven't seen a book out there with really
significant Digester coverage, typically just some
brief mentions and urgings that you use it. I've been
pulling together some notes for a book over the last
several months, but lately contractor life has been
intruding. Not sure how much demand there
You were close. You lost track of the fact that
there is a parameter stack and a digester stack, and
you need to make sure that put is called on the
correct object.
import org.apache.commons.digester.*;
import java.io.*;
import java.util.*;
public class PersonExample2 {
public static
I've run into this one before. It is relatively easy
as long as you are willing to make a simplifying
assumption: a reference can only happen AFTER the real
thing, not before it. That way you will always
have the real thing recorded for lookup when you
hit the reference. Things are tougher if
Last I looked (a couple of years ago), Oracle drivers
maintained an open stream connection of some sort for
clobs, maybe the commit causes the driver to close
such streams? You could test that by writing code
directly against the Oracle driver, e.g. first getting
a reference to a CLOB, doing a
Not 100% certain about this, but just did a quick pass
through the Digester source. There is a
ignorableWhitespace callback in the Digester class
that currently doesn't do anything. Maybe it needs to
be checking the configuration of the parser to decide
if it should be tacking on the whitespace
I believe the issue may be that the property isn't
recognized if the getter and setter have a different
type. You are ok if there is no getter, but not if
the getter is of a different type. You showed
your setFoo, but not the getFoo. Does getFoo
return a String, or a Foo? I suspect the latter.
Yup, figured that is what it was. Beanutils basically
just extends what you get from the javabeans api, and
it depends not just on naming conventions, but also on
types.
The easy solution is to split the functionality
into two pieces:
private String fooText;
public String getFooText() {
Almost forgot, there is a way to both avoid changing
the XML and avoid changing the code. Use a
SetPropertiesRule and specify the mapping of the
attribute name to a property name.
Digester d=new Digester();
// set rules as usual, and also
Rule spr=new SetPropertiesRule(foo,fooText);
Just to add my two cents to the other responses,
Digester only uses two logging categories,
...Digester and ...Digester.sax. That
means that you can't use the usual Log4J config
hacks of tweaking category priorities to reduce
noise. You'll want to make effective use of
all the Log4J options,
14 matches
Mail list logo
