Re: Enhydra: Re: DTD validation of struts-config.xml

2001-02-12 Thread Craig R. McClanahan

DONNIE HALE wrote:

> To those interested:
>
> I followed the rabbit trail implied by Craig's response, and have discovered that in 
>fact there is an issue when Struts attempts to register its local DTD in the 
>initDigester method. However, I believe it may be due to a bug in the Struts code, 
>not Enhydra's class loader. The class loader implicitly used by the code in 
>ActionServlet.initDigester:
>
> URL url = this.getClass().getResource(registrations[i+1]);
>
> is "org.apache.tomcat.core.ServletClassLoader". I didn't pursue this angle terribly 
>far other than to intuit that it wasn't the class loader I expected.
>
> Making a short story long, I figured that the "getResource" method on the servlet 
>context was the appropriate method to use, I changed the relevant section in 
>initDigester to:
>
> // Register our local copy of the DTDs that we can find
> for (int i = 0; i < registrations.length; i += 2) {
> URL url;
> try {
> url = 
>getServletConfig().getServletContext().getResource(registrations[i+1]);
> }
> catch (java.net.MalformedURLException e) {
> url = null;
> }
> if (url != null)
> digester.register(registrations[i], url.toString());
> }
>
> This seems to fix the problem, though I can't say for sure what ill side effects it 
>could have. My guess is that one can't assume that the class loader of the servlet 
>class itself (at least, perhaps, while it's "init" method is still running) is the 
>same as that of the web application as a whole. Consequently, the standard servlet 
>getResource method is appropriate because the classpath of the class loader being 
>used behind the scenes of that method is the one to which the WEB-INF/lib stuff and 
>WEB-INF/classes directories have been added.
>

Unfortunately, this solution is not going to help unless you much -- at least in a 
servlet container that conforms to the spec requirements.

ServletContext.getResource() returns you a URL of a web application resource -- in 
other words, of a "file" or "directory" entry from the original WAR file.  For 
example, you can get a URL to read the web.xml file itself, if you want to, by calling:

URL url =
  getServletContext().getResource("/WEB-INF/web.xml");

However, the internal copy of the DTD we are talking about here is in the struts.jar 
file (along with all the LocalStrings.properties files containing messages generated 
by the Struts components themselves).  Struts expects to be able to access these 
resources via the class loader that the class was loaded from.

URL url =
   
this.getClass().getResource("/org/apache/struts/resources/struts-config_1_0.dtd");

Among other things, that means the call will succeeed whether you leave the Struts 
classes packaged in "struts.jar", or unpack them into WEB-INF/classes -- it is totally 
up to the class loader to figure out how to return a URL that can be used to read 
these resources.  And the class loader in question is the class loader provided by 
your servlet container.

Craig McClanahan






>
> Thanks,
>
> Donnie
>
> >>> [EMAIL PROTECTED] 02/12/01 03:01PM >>>
> Lee Hall wrote:
>
> > We've been using the Tomcat 3.2 that is integrated with NetBeans to do
> > our Struts development.  Our test deployment server (AIX 4.3 with the
> > IBM 1.2.2 JVM) is running a vanilla Tomcat3.2.1.  Neither of these
> > environments has any problem with the subject of this message. Our
> > pre-production server (AIX 4.3 with the IBM 1.2.2 JVM) is running
> > Enhydra 3.1 and fails initialization due to the validation done by
> > ActionServlet.  We've tried forcing Xerces 1.2 in Enhydra, but Enhydra
> > persists in it's attempt to validate using the network URL instead of
> > the local resource. I hacked ActionServlet.initDigester() to turn off
> > validation and that got us by - but I know it's the wrong way to deal
> > with this.  In spite of the Barracuda project, I would hope that the
> > Enhydra team would want to be completely Tomcat-compatible (which I
> > think includes Struts compatibility). Still, it was easier to "fix"
> > the ActionServlet than to fingure out why we are having this problem
> > with Enhydra.  I know, I know... I should have extended ActionServlet
> > to override instead of butchering my clean Struts - but the question
> > remains regarding why this seeming incompatibility exists. Could
> > somebody give me a clue?- Lee
>
> As you can see from the source code in ActionServlet, Struts attempts to
> register its local copy of the DTD in the initDigester() method.  It
> uses Class.getResource() to actually acquire a URL for reading the
> contents of the DTD, which is stored as a resource in the "struts.jar"
> file.  If the web application class loader in Enhydra has problems
> implementing this method correctly, you could encounter the symptom that
> you report (trying to go across t

Enhydra: Re: DTD validation of struts-config.xml

2001-02-12 Thread DONNIE HALE

To those interested:

I followed the rabbit trail implied by Craig's response, and have discovered that in 
fact there is an issue when Struts attempts to register its local DTD in the 
initDigester method. However, I believe it may be due to a bug in the Struts code, not 
Enhydra's class loader. The class loader implicitly used by the code in 
ActionServlet.initDigester:

URL url = this.getClass().getResource(registrations[i+1]);

is "org.apache.tomcat.core.ServletClassLoader". I didn't pursue this angle terribly 
far other than to intuit that it wasn't the class loader I expected.

Making a short story long, I figured that the "getResource" method on the servlet 
context was the appropriate method to use, I changed the relevant section in 
initDigester to:

// Register our local copy of the DTDs that we can find
for (int i = 0; i < registrations.length; i += 2) {
URL url;
try {
url = 
getServletConfig().getServletContext().getResource(registrations[i+1]);
}
catch (java.net.MalformedURLException e) {
url = null;
}
if (url != null)
digester.register(registrations[i], url.toString());
}

This seems to fix the problem, though I can't say for sure what ill side effects it 
could have. My guess is that one can't assume that the class loader of the servlet 
class itself (at least, perhaps, while it's "init" method is still running) is the 
same as that of the web application as a whole. Consequently, the standard servlet 
getResource method is appropriate because the classpath of the class loader being used 
behind the scenes of that method is the one to which the WEB-INF/lib stuff and 
WEB-INF/classes directories have been added.

Thanks,

Donnie


>>> [EMAIL PROTECTED] 02/12/01 03:01PM >>>
Lee Hall wrote:

> We've been using the Tomcat 3.2 that is integrated with NetBeans to do
> our Struts development.  Our test deployment server (AIX 4.3 with the
> IBM 1.2.2 JVM) is running a vanilla Tomcat3.2.1.  Neither of these
> environments has any problem with the subject of this message. Our
> pre-production server (AIX 4.3 with the IBM 1.2.2 JVM) is running
> Enhydra 3.1 and fails initialization due to the validation done by
> ActionServlet.  We've tried forcing Xerces 1.2 in Enhydra, but Enhydra
> persists in it's attempt to validate using the network URL instead of
> the local resource. I hacked ActionServlet.initDigester() to turn off
> validation and that got us by - but I know it's the wrong way to deal
> with this.  In spite of the Barracuda project, I would hope that the
> Enhydra team would want to be completely Tomcat-compatible (which I
> think includes Struts compatibility). Still, it was easier to "fix"
> the ActionServlet than to fingure out why we are having this problem
> with Enhydra.  I know, I know... I should have extended ActionServlet
> to override instead of butchering my clean Struts - but the question
> remains regarding why this seeming incompatibility exists. Could
> somebody give me a clue?- Lee

As you can see from the source code in ActionServlet, Struts attempts to
register its local copy of the DTD in the initDigester() method.  It
uses Class.getResource() to actually acquire a URL for reading the
contents of the DTD, which is stored as a resource in the "struts.jar"
file.  If the web application class loader in Enhydra has problems
implementing this method correctly, you could encounter the symptom that
you report (trying to go across the network to grab the DTD).

Craig McClanahan


-
To unsubscribe from this mailing list, send email to [EMAIL PROTECTED] 
with the text "unsubscribe enhydra" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at [EMAIL PROTECTED]