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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
