tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "neal" <nealcab...@yahoo.com>
Subject RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Date Sat, 01 Mar 2003 21:59:27 GMT
Hmm.  I hear what you're saying but I would think that if Tomcat uses
different forms of URL formats that would be a fundamental
backwards-compatability issue.  Is this not a concern of the product?

:(



-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Saturday, March 01, 2003 1:53 PM
To: Tomcat Users List
Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)




On Sat, 1 Mar 2003, neal wrote:

> Date: Sat, 1 Mar 2003 13:29:08 -0800
> From: neal <nealcabage@yahoo.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
>
> actually the full URL that's coming back does not have the "file://" in
> front.  I guess that's why its complaining about not having a scheme.
>
> But again, why did it work before?  Why does it not work now?  And if the
> scheme is required, why is Class.getResource() not returning that as part
of
> the URL?
>

I agree that it's odd to have the leading "/" there, but it is not
necessarily a bug (I haven't checked the details).

Tomcat (more specifically, the class loader Tomcat provides for your
webapp) must be involved in the resources returned from inside the webapp
(i.e. /WEB-INF/classes or /WEB-INF/lib), because only Tomcat knows how and
where the actual resources are stored (inside our outside a JAR, perhaps
still inside an unpacked WAR file, ...).

The only promise you get from ClassLoader.getResource() is that, on that
URL instance, you can call openStream() or openConnection() to access the
underlying resource.  The actual format of the URL (when rendered as a
String) is totally up to the class loader.  There are no guarantees on
what it looks like (and, indeed, various versions of Tomcat have all used
different URL formats).

In particular, you are *not* promised that you can convert the URL to a
string form, and then back into a URL object that can retrieve the
resource data, like this:

  URL origURL = this.getClass().getResource("myresource.properties");
  InputStream origStream = origURL.openStream(); // Must work or its a bug

  String origString = origURL.toExternalForm();
  URL newURL = new URL(origString);
  InputStream newStream = newURL.openStream(); // Not guaranteed to work

Doing these transformations loses the URLStreamHandler that Tomcat embeds
in the URL that is returned by getResource().  When passing on the URL
that is returned to other processing code, you should always pass it on as
a URL (not as a String), or you must provide an appropriate resolver (such
as an EntityResolver instance for a SAXParser, or a URIResolver for a
Transformer).

Note that if the origURL.openStream() call fails, that's definitely a bug
... but if it works, then the class loader has fulfilled its promise, and
its up to you to provide the appropriate URL resolution services if you
convert to a String and back again.


Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message