RE: [Digester] Correct Behavior of Digester.resolveEntity( )?

[Dave Martin <dm...@altoweb.com>]

I've a similar issue where I might want to use a different EntityResolver
implementation than the one implemented in the Digester class. I'll probably
subclass the Digester, but I consider your suggestion of allowing
'pluggable' digesters to be preferable. 

In fact, it would be nice to reduce the need to subclass Digester as much as
possible. For example, we're using the Digester for our internally developed
software, and also incorporating software from the Mapper framework, which
subclasses the Digester it to provide additional stack access methods needed
by a custom Rule class. If we also have to extend the Digester, things start
to get a little messy. If we later wanted to incorporate another external
piece of software that also had a Digester subclass, things would become
quite messy indeed!

Ultimately, it would be nice to minimize the need to subclass Digester at
all, perhaps by exposing some of Digester's protected functionality (such as
full access to the object stack) to the Rule base class.

Just my 2 cents...

-Dave


 regarding subclassing Digester vs pluggable EntityResolver:


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Saturday, October 20, 2001 6:11 PM
> To: Jakarta Commons Developers
> Subject: Re: [Digester] Correct Behavior of Digester.resolveEntity( )?
> 
> 
> Digester's "resolveEntity()" method is an implementation of the SAX
> interface org.xml.sax.EntityHandler.  It's mission in life is 
> to look at
> the public ID you specify and return a corresponding 
> InputSource, if it
> can determine one.  This can be based on a preregistered URL 
> (if you have
> called the register() method) or based on trying to resolve 
> the system ID
> specified in the second argument.
> 
> The default implementation returns an InputSource *only* if a 
> URL has been
> preregistered.  Otherwise, it returns null, which is an 
> indication to the
> parser that it should attempt to open a regular URI connection to the
> specified system identifier.  What happens then is up to the 
> XML parser
> you are using -- consult the appropriate docs for more information.
> 
> It would be possible to change this default behavior in one 
> of two ways:
> 
> * Subclass Digester and provide your own implementation of the
>   resolveEntity() method.  You can do this yourself, without modifying
>   the existing source code.
> 
> * Modify Digester to allow the application to plug in an 
> EntityResolver
>   implementation, and use it if specified, defaulting to the current
>   implementation if not specified.  I'll put this on the TODO 
> list, and
>   look at also providing some example implementations.
> 
> For instance, it would be possible to create an EntityResolver that
> assumed the system id was a resource path inside a web 
> application, and
> used ServletContext.getResourceAsStream() to create an input 
> source for
> it.  Of course, this implementation would have to be given a 
> reference to
> the ServletContext associated with your webapp to make this 
> possible.  (If
> you use the subclass approach, you'll probably also need to add a
> setServletContext() method to make this available.
> 
> Craig
> 
> 
> On Fri, 19 Oct 2001, Vaughan Jackson wrote:
> 
> > Date: Fri, 19 Oct 2001 17:13:09 -0700
> > From: Vaughan Jackson <va...@tumbleweed.com>
> > Reply-To: Jakarta Commons Developers 
> <co...@jakarta.apache.org>
> > To: "'commons-dev@jakarta.apache.org'" 
> <co...@jakarta.apache.org>
> > Subject: [Digester] Correct Behavior of Digester.resolveEntity( )?
> >
> > Hi,
> >
> > I have a three questions about the behavior of this method. 
> My questions
> > are based on what I think I have observed in trying to 
> understand why I am
> > not
> > able to use external entity references to include XML 
> fragments within
> > struts-config.xml and validation.xml.
> >
> > Using Struts 1.0, what I think I see is XmlParser 
> requesting Digester to
> > resolve
> > an entity such as this.
> >
> > <!DOCTYPE form-validation [
> >     <!ENTITY requiredNoSuffix SYSTEM "requiredNoSuffix.xml">
> > ]>
> >
> > .
> > .
> > &requiredNoSuffix;
> >
> > According to the examples I have seen, this should work. 
> However, XmlParser
> > then calls
> > Digester.resolveEntity( publicId, systemId ) with a null 
> publicId. This
> > fails to resolve for at least
> > two reasons:
> >
> > 1. The public Id, which is the key Digester uses to lookup 
> DTDs is null;
> > 2. No such DTD has been registered anyway.
> >
> > I altered the above entity to this:
> >
> > <!DOCTYPE form-validation [
> >     <!ENTITY requiredNoSuffix PUBLIC "requiredNoSuffix"
> > "requiredNoSuffix.xml">
> > ]>
> >
> > This means that Digester.resolveEntity( publicId, systemId 
> )  is now called
> > with these values:
> >
> > resolveEntity( "requiredNoSuffix", "requiredNoSuffix.xml" )
> >
> > - this might be seen as an improvement, but it still does 
> not work, because
> > there is no corresponding
> > registered DTD.
> >
> > I then see my web server's XmlParser trying to resolve the 
> path to the
> > included XML fragment file
> > - it seems to fail to do this.
> >
> > OK. So my questions are the following.
> >
> > 1. Shouldn't either Digester, or the web server's XmlParser 
> be able to
> > resolve such an include
> >    file path (a relative one within a WAR file)?
> > 2. If one should, which should it be?
> > 3. If Digester should be able resolve to such files without 
> a pre-registered
> > DTD, is any fix
> >     planned for this in the near future?
> >
> > Thanks,
> > Vaughan.
> >
> >
> >
> > ___________________________________________________
> > Vaughan Jackson
> > Development
> > Tumbleweed Communications
> > vaughan.jackson@tumbleweed.com / +1 (650) 216 2532
> > ___________________________________________________
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: earth to digester

[robert burrell donkin <ro...@mac.com>]

On Wednesday, October 31, 2001, at 09:56 PM, Craig R. McClanahan wrote:

> I'm still here (though buried with work ...)

i've been talking OL to jason van zyl today about the possibility of 
writing a certain kind of rule. turned out that it had a few wrinkles. i 
don't think it's worth bothering you with the details right now.

- robert

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: earth to digester

["Craig R. McClanahan" <cr...@apache.org>]

I'm still here (though buried with work ...)

Craig


On Wed, 31 Oct 2001, robert burrell donkin wrote:

> Date: Wed, 31 Oct 2001 21:58:34 +0000
> From: robert burrell donkin <ro...@mac.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: earth to digester
>
> are scott or craig out there?
>
> (i know that the lists have been a bit cranky recently so i thought that
> it'd be good idea to ask before boring everybody else...)
>
> - robert
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: earth to digester

[robert burrell donkin <ro...@mac.com>]

are scott or craig out there?

(i know that the lists have been a bit cranky recently so i thought that 
it'd be good idea to ask before boring everybody else...)

- robert

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>