You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Martin Cooper <ma...@tumbleweed.com> on 2001/01/03 07:20:28 UTC

Problem with Digester used "standalone"

I've been trying to use the Digester module on its own (i.e. no other Struts
code, no servlets, no JSP), and have been having problems. At first, I
thought it must be my application code, but then I tried copying the code
from the Struts example DatabaseServlet into my own Java application and
came across the same problem.

The problem happens when addSetProperties() is used. The call itself
succeeds, but later on, when Digester.parse() is called, I get the following
error and call stack:

java.lang.NullPointerException
        at
org.apache.struts.digester.SetPropertiesRule.begin(SetPropertiesRule.java,
Compiled Code)
        at org.apache.struts.digester.Digester.startElement(Digester.java,
Compiled Code)
        at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
        at com.sun.xml.parser.Parser.content(Parser.java:1499)
        at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
        at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
        at com.sun.xml.parser.Parser.parse(Parser.java:284)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:77)
        at org.apache.struts.digester.Digester.parse(Digester.java:708)
        at mfnc.TryDigester.TryDatabase(TryDigester.java:92)
        at mfnc.TryDigester.main(TryDigester.java:18)
org.xml.sax.SAXException

If I comment out the calls to addSetProperties(), everything works just fine
(except that I don't have the property values I wanted :-) ).

Anyone have any ideas about what I might be doing wrong? I know this isn't
how the Digester is expected to be used, but, well, it just seemed like a
handy class for parsing simple XML files...

Thanks!

--
Martin Cooper
Tumbleweed Communications




Re: Problem with Digester used "standalone"

Posted by ma...@tumbleweed.com.
At 12:26 PM 1/4/01 -0800, Craig R. McClanahan wrote:
>When you say "JSDK" classes, I hope you mean the "servlet.jar" file that
>contains the current version of the servlet API classes :-).

Yes, I meant the jar file containing the Servlets 2.2 implementation. Since 
Tomcat calls it servlet.jar and Resin calls it jsdk22.jar, I got lazy and 
just referred to it as the JSDK. I figured people would know what I meant. :-)

>The guilty party is undoubtedly BeanUtils.populate() -- one of the 
>variants here
>takes an HttpServletRequest as an argument, so it requires the servlet API
>classes.  I will look at the code dependencies of Digester, and can maybe use
>PropertyUtils directly instead -- but is having struts.jar + servlet.jar
>available on your classpath (plus an XML parser of course) *really* too 
>much to
>ask?

I guess not *really*. It just seems a bit weird to require the JSDK for a 
standalone Java application. Since what I'm doing is for my own use, it's 
not a big deal, but it would be an odd requirement to have to list if I was 
giving the app to other people.


--
Martin Cooper
Tumbleweed Communications



Re: Problem with Digester used "standalone"

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Martin Cooper wrote:

> Well, I finally got the Digester to work outside a servlet, but I'm not sure
> I would call the result "standalone". I never quite figured out where the
> earlier NullPointerException was coming from, but somewhere along the line
> it went away. Part of the solution seemed to be not using struts.jar, but
> using the Struts source code directly.
>
> What I did was to gradually clone enough of the Struts source tree to build
> my application. (That is, I kept copying files until it all compiled!) That
> seemed not to require too much until I had to include BeanUtils, at which
> point a whole slew of dependencies added themselves in. By the time I was
> done, I needed more than 30 Struts source files, and I had to have the JSDK
> and JDBC 2.0 classes in my classpath. Seems a bit excessive for an XML
> digester...
>

When you say "JSDK" classes, I hope you mean the "servlet.jar" file that
contains the current version of the servlet API classes :-).

>
> Unfortunately, that isn't the end of the story, though. Once I ran the
> resulting application, I got a NoClassDefFoundError. Once I tracked that one
> down, I discovered that I actually needed to have the JSDK in my classpath
> to *run* Digester code. This makes no sense to me, but unfortunately it
> seems to be the case.
>
> Now, I know the Digester is really intended for use with Struts web
> applications (parsing config files, etc), but it just seems like such an
> easy-to-use way of handling simple XML files that it would be nice if it was
> easy to use standalone. Is this something other people might use? Would it
> be worth spending some time (perhaps mine) to isolate the Digester from the
> rest of Struts?
>

The guilty party is undoubtedly BeanUtils.populate() -- one of the variants here
takes an HttpServletRequest as an argument, so it requires the servlet API
classes.  I will look at the code dependencies of Digester, and can maybe use
PropertyUtils directly instead -- but is having struts.jar + servlet.jar
available on your classpath (plus an XML parser of course) *really* too much to
ask?

>
> --
> Martin Cooper
> Tumbleweed Communications
>

Craig McClanahan



Re: Problem with Digester used "standalone"

Posted by Michael Roberts <mi...@ivtweb.com>.
How about cloning the BeanUtilsclass but removing the code not used by Digester
that is bringing in the unecessary dependencies?  And then asking Struts to
release a separate digester.jar as part of the distribution?

I agree on the usefulness of Digester.  I have several webapps where Digester is
used more heavily within my application specific code than in Struts itself.

Martin Cooper wrote:

> Well, I finally got the Digester to work outside a servlet, but I'm not sure
> I would call the result "standalone". I never quite figured out where the
> earlier NullPointerException was coming from, but somewhere along the line
> it went away. Part of the solution seemed to be not using struts.jar, but
> using the Struts source code directly.
>
> What I did was to gradually clone enough of the Struts source tree to build
> my application. (That is, I kept copying files until it all compiled!) That
> seemed not to require too much until I had to include BeanUtils, at which
> point a whole slew of dependencies added themselves in. By the time I was
> done, I needed more than 30 Struts source files, and I had to have the JSDK
> and JDBC 2.0 classes in my classpath. Seems a bit excessive for an XML
> digester...
>
> Unfortunately, that isn't the end of the story, though. Once I ran the
> resulting application, I got a NoClassDefFoundError. Once I tracked that one
> down, I discovered that I actually needed to have the JSDK in my classpath
> to *run* Digester code. This makes no sense to me, but unfortunately it
> seems to be the case.
>
> Now, I know the Digester is really intended for use with Struts web
> applications (parsing config files, etc), but it just seems like such an
> easy-to-use way of handling simple XML files that it would be nice if it was
> easy to use standalone. Is this something other people might use? Would it
> be worth spending some time (perhaps mine) to isolate the Digester from the
> rest of Struts?
>
> --
> Martin Cooper
> Tumbleweed Communications
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, January 03, 2001 12:01 AM
> Subject: Re: Problem with Digester used "standalone"
>
> > Martin Cooper wrote:
> >
> > > I've been trying to use the Digester module on its own (i.e. no other
> Struts
> > > code, no servlets, no JSP), and have been having problems. At first, I
> > > thought it must be my application code, but then I tried copying the
> code
> > > from the Struts example DatabaseServlet into my own Java application and
> > > came across the same problem.
> > >
> > > The problem happens when addSetProperties() is used. The call itself
> > > succeeds, but later on, when Digester.parse() is called, I get the
> following
> > > error and call stack:
> > >
> >
> > As you can see from the way that Struts itself uses the digester (for
> example,
> > when parsing struts-config.xml), you can see that the set properties rule
> is
> > quite common.  Would it be possible to run this in an environment with the
> JIT
> > turned off, so we can see what line number in SetPropertiesRule is
> throwing the
> > exception?  Also, could you post the logic you're using to initialize the
> > digester -- at least for the patterns that match when you get the
> exception?
> > (It might also be useful to call digester.setDebug(999) so you can see
> trace
> > output on System.out).
> >
> > The most likely cause would be if there are no items on the object stack
> > (perhaps because you didn't call an object create rule on the same pattern
> > first), but the only way to know is to have a few more details.
> >
> > Craig
> >
> >

--
Michael Roberts  |  System Architect
miroberts@ivtweb.com  |  t: 212 233 7080 x7370  |  f: 212 233 7145

IVT  |  Interactive Video Technologies  |  100 Broadway, 18th floor |  NY, NY
10005



Re: Problem with Digester used "standalone"

Posted by Martin Cooper <ma...@tumbleweed.com>.
Well, I finally got the Digester to work outside a servlet, but I'm not sure
I would call the result "standalone". I never quite figured out where the
earlier NullPointerException was coming from, but somewhere along the line
it went away. Part of the solution seemed to be not using struts.jar, but
using the Struts source code directly.

What I did was to gradually clone enough of the Struts source tree to build
my application. (That is, I kept copying files until it all compiled!) That
seemed not to require too much until I had to include BeanUtils, at which
point a whole slew of dependencies added themselves in. By the time I was
done, I needed more than 30 Struts source files, and I had to have the JSDK
and JDBC 2.0 classes in my classpath. Seems a bit excessive for an XML
digester...

Unfortunately, that isn't the end of the story, though. Once I ran the
resulting application, I got a NoClassDefFoundError. Once I tracked that one
down, I discovered that I actually needed to have the JSDK in my classpath
to *run* Digester code. This makes no sense to me, but unfortunately it
seems to be the case.

Now, I know the Digester is really intended for use with Struts web
applications (parsing config files, etc), but it just seems like such an
easy-to-use way of handling simple XML files that it would be nice if it was
easy to use standalone. Is this something other people might use? Would it
be worth spending some time (perhaps mine) to isolate the Digester from the
rest of Struts?

--
Martin Cooper
Tumbleweed Communications


----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, January 03, 2001 12:01 AM
Subject: Re: Problem with Digester used "standalone"


> Martin Cooper wrote:
>
> > I've been trying to use the Digester module on its own (i.e. no other
Struts
> > code, no servlets, no JSP), and have been having problems. At first, I
> > thought it must be my application code, but then I tried copying the
code
> > from the Struts example DatabaseServlet into my own Java application and
> > came across the same problem.
> >
> > The problem happens when addSetProperties() is used. The call itself
> > succeeds, but later on, when Digester.parse() is called, I get the
following
> > error and call stack:
> >
>
> As you can see from the way that Struts itself uses the digester (for
example,
> when parsing struts-config.xml), you can see that the set properties rule
is
> quite common.  Would it be possible to run this in an environment with the
JIT
> turned off, so we can see what line number in SetPropertiesRule is
throwing the
> exception?  Also, could you post the logic you're using to initialize the
> digester -- at least for the patterns that match when you get the
exception?
> (It might also be useful to call digester.setDebug(999) so you can see
trace
> output on System.out).
>
> The most likely cause would be if there are no items on the object stack
> (perhaps because you didn't call an object create rule on the same pattern
> first), but the only way to know is to have a few more details.
>
> Craig
>
>



Re: Problem with Digester used "standalone"

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Martin Cooper wrote:

> I've been trying to use the Digester module on its own (i.e. no other Struts
> code, no servlets, no JSP), and have been having problems. At first, I
> thought it must be my application code, but then I tried copying the code
> from the Struts example DatabaseServlet into my own Java application and
> came across the same problem.
>
> The problem happens when addSetProperties() is used. The call itself
> succeeds, but later on, when Digester.parse() is called, I get the following
> error and call stack:
>

As you can see from the way that Struts itself uses the digester (for example,
when parsing struts-config.xml), you can see that the set properties rule is
quite common.  Would it be possible to run this in an environment with the JIT
turned off, so we can see what line number in SetPropertiesRule is throwing the
exception?  Also, could you post the logic you're using to initialize the
digester -- at least for the patterns that match when you get the exception?
(It might also be useful to call digester.setDebug(999) so you can see trace
output on System.out).

The most likely cause would be if there are no items on the object stack
(perhaps because you didn't call an object create rule on the same pattern
first), but the only way to know is to have a few more details.

Craig



Re: Problem with Digester used "standalone"

Posted by Elod Horvath <el...@itfais.com>.
Martin Cooper wrote:
> 
> I've been trying to use the Digester module on its own (i.e. no other Struts
> code, no servlets, no JSP), and have been having problems. At first, I
> thought it must be my application code, but then I tried copying the code
> from the Struts example DatabaseServlet into my own Java application and
> came across the same problem.
> 
> The problem happens when addSetProperties() is used. The call itself
> succeeds, but later on, when Digester.parse() is called, I get the following
> error and call stack:
> 
> java.lang.NullPointerException
>         at
> org.apache.struts.digester.SetPropertiesRule.begin(SetPropertiesRule.java,
> Compiled Code)
>         at org.apache.struts.digester.Digester.startElement(Digester.java,
> Compiled Code)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
>         at com.sun.xml.parser.Parser.content(Parser.java:1499)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
>         at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
>         at com.sun.xml.parser.Parser.parse(Parser.java:284)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:77)
>         at org.apache.struts.digester.Digester.parse(Digester.java:708)
>         at mfnc.TryDigester.TryDatabase(TryDigester.java:92)
>         at mfnc.TryDigester.main(TryDigester.java:18)
> org.xml.sax.SAXException
> 
> If I comment out the calls to addSetProperties(), everything works just fine
> (except that I don't have the property values I wanted :-) ).
> 
> Anyone have any ideas about what I might be doing wrong? I know this isn't
> how the Digester is expected to be used, but, well, it just seemed like a
> handy class for parsing simple XML files...
> 

i had a similar problem a while back relating to dealing with method
calls that had primitive data type parameters (in my case, boolean).  
i don't remember the specifics as this was over a month ago.  i'll see
if i can dredge up the problem again at work today.

e
-- 
_______________________________________________________________________
Elod Horvath ('e')       /      ITFAIS Records (http://www.itfais.com/)