RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Howdy, This whole thread might be related to other one, regarding your "upgrade" method of simply copying over. You may end up with mismatching internal tomcat jars. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: neal [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 01, 2003 9:16 PM >To: Tomcat Users List >Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > >Thanks for the info. > >I guess I'm just frustrated because my app broke when I upgraded Tomcat. >:-\ > >Neal > >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 01, 2003 4:36 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:59:27 -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) >> >> 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? >> > >No ... the "external form" of the URL returned by getResource() is a >private implementation detail, just as the fully qualified class name of >the class that implements HttpSession is a private implementation detail. >Just because you can see it doesn't mean you should rely on it. The same >goes for relying on any other container-specific (or sometimes even >version-specific) feature that is not defined in the specs (like the >invoker servlet, or the ability to reload a webapp without restarting your >server, or tons of other things ...). > >More important in this particular case is a fundamental principle of >understanding how java.net.URL works -- the mechanism that resolves a URL >can either be built in (the URLStreamHandler argument passed to one of the >constructors) or must be provided externally. You cannot assume that >URL --> String --> URL transformations can be done without losing >information. > >See the Java Tutorial's "Networking Trail" for more info on the URL >related APIs. > > http://java.sun.com/docs/books/tutorial/ > >> :( >> > >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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Thanks for the info. I guess I'm just frustrated because my app broke when I upgraded Tomcat. :-\ Neal -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 4:36 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:59:27 -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) > > 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? > No ... the "external form" of the URL returned by getResource() is a private implementation detail, just as the fully qualified class name of the class that implements HttpSession is a private implementation detail. Just because you can see it doesn't mean you should rely on it. The same goes for relying on any other container-specific (or sometimes even version-specific) feature that is not defined in the specs (like the invoker servlet, or the ability to reload a webapp without restarting your server, or tons of other things ...). More important in this particular case is a fundamental principle of understanding how java.net.URL works -- the mechanism that resolves a URL can either be built in (the URLStreamHandler argument passed to one of the constructors) or must be provided externally. You cannot assume that URL --> String --> URL transformations can be done without losing information. See the Java Tutorial's "Networking Trail" for more info on the URL related APIs. http://java.sun.com/docs/books/tutorial/ > :( > 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]
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:59:27 -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) > > 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? > No ... the "external form" of the URL returned by getResource() is a private implementation detail, just as the fully qualified class name of the class that implements HttpSession is a private implementation detail. Just because you can see it doesn't mean you should rely on it. The same goes for relying on any other container-specific (or sometimes even version-specific) feature that is not defined in the specs (like the invoker servlet, or the ability to reload a webapp without restarting your server, or tons of other things ...). More important in this particular case is a fundamental principle of understanding how java.net.URL works -- the mechanism that resolves a URL can either be built in (the URLStreamHandler argument passed to one of the constructors) or must be provided externally. You cannot assume that URL --> String --> URL transformations can be done without losing information. See the Java Tutorial's "Networking Trail" for more info on the URL related APIs. http://java.sun.com/docs/books/tutorial/ > :( > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
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]
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]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
First, how how exactly are you calling getResource()? Here are some
examples...
This will get the resource in the root of the current classloader ( ie...
WEB-INF/classes or the root of a .jar file)
myClass.getResource("/myprops.properties");
This will get the resource relative to the location of the calling class
myClass.getResource("myprops.properties");
I've never run into the scheme problem. You can try the above first and
see if that works. If not, please provide a full description about where
the file is that you are trying to get using getResource() and show exactly
how you are calling getResource().
Jake
At 01:29 PM 3/1/2003 -0800, you wrote:
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?
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 01, 2003 1:24 PM
To: Tomcat Users List
Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
That's normal. The full URL should look soemthing like this, though...
file:///D:/dev/tomcat/webapps/myapp/WEB-INF/classes/org/mypackage/somefile.p
roperties
or if it is inside an archive...
jar:file:///D:/dev/tomcat/webapps/myapp/WEB-INF/lib/somejar.jar!/org/mypacka
ge/somefile.properties
Jake
At 01:00 PM 3/1/2003 -0800, you wrote:
>Actually,
>
>It seems that the problem is that Class.getResource() is returning a URL
>with a leading "/" dispite the fact that I'm on a Windows box. For
>instance, its returning a url like:
>
>/D:/dev/tomcat/...
>
>where it *should* be returning:
>
>D:/dev/tomcat/..
>
>If I mockup a String of that nature it works fine which seems to confirm
>this.
>
>So, I could always compensate by removing the "/" but I ultimately deploy
to
>Linux and I presume this will mess up my paths in my production site if I
do
>so.
>
>Of course, I could always find a workaround ... but ... should I have to?
I
>mean, I'm guessing this is a bug somehow associated with the context of
this
>version of Tomcat.
>
>Any thoughts?
>
>Thanks.
>
>Neal
>
>-Original Message-----
>From: Reynir Hübner [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 01, 2003 12:41 PM
>To: Tomcat Users List
>Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
>
>
>Hi,
>
>This may have something to do with an upgraded version of jaxp or xerces,
>distributed with some dists of tomcat.
>According to the error you're getting your url is missing scheme, often
>'http' or 'https' in the beginning of the url (before '://')
>
> [scheme:]scheme-specific-part[#fragment]
>
>Which version of tomcat did you download (the full version or 1.4. LE) ?
>
>Hope it helps
>-reynir
>
>
>
> > -Original Message-
> > From: neal [mailto:[EMAIL PROTECTED]
> > Sent: 1. mars 2003 20:36
> > To: Tomcat Users List
> > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
> >
> >
> > Hmm ... it appears that for some F***'ed up reason, that the
> > URL created by using his.getClass().getResource() is no
> > longer acceptable for TRAX when using Tomcat 4.1.18, as
> > compared to Tomcat 4.0.4.
> >
> > The problem is that the URI begins with a "/". If I remove
> > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18.
> >
> > Why would Tomcat be involving itself in such issues? Only
> > thing I can think of is that maybe the conditions for this
> > Apache Exception were redefined in
> > 4.1.18:
> >
> > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI
> >
> > Neal
> >
> > -Original Message-
> > From: neal [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, March 01, 2003 11:02 AM
> > To: Tomcat Users List
> > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
> >
> >
> > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18
> > (Windows) and now it doesn't work! It appears that I have a
> > problem now with parsing my conf.xml file in my initServlet.
> >
> > I noticed that the new Tomcat has an "endorsed" directory
> > with a different copy of Xerces in it. Is this somehow related?
> >
> > Here's the error:
> > javax.xml.transform.TransformerException:
> > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI
> &g
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? -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 1:24 PM To: Tomcat Users List Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) That's normal. The full URL should look soemthing like this, though... file:///D:/dev/tomcat/webapps/myapp/WEB-INF/classes/org/mypackage/somefile.p roperties or if it is inside an archive... jar:file:///D:/dev/tomcat/webapps/myapp/WEB-INF/lib/somejar.jar!/org/mypacka ge/somefile.properties Jake At 01:00 PM 3/1/2003 -0800, you wrote: >Actually, > >It seems that the problem is that Class.getResource() is returning a URL >with a leading "/" dispite the fact that I'm on a Windows box. For >instance, its returning a url like: > >/D:/dev/tomcat/... > >where it *should* be returning: > >D:/dev/tomcat/.. > >If I mockup a String of that nature it works fine which seems to confirm >this. > >So, I could always compensate by removing the "/" but I ultimately deploy to >Linux and I presume this will mess up my paths in my production site if I do >so. > >Of course, I could always find a workaround ... but ... should I have to? I >mean, I'm guessing this is a bug somehow associated with the context of this >version of Tomcat. > >Any thoughts? > >Thanks. > >Neal > >-----Original Message----- >From: Reynir Hübner [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 01, 2003 12:41 PM >To: Tomcat Users List >Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > >Hi, > >This may have something to do with an upgraded version of jaxp or xerces, >distributed with some dists of tomcat. >According to the error you're getting your url is missing scheme, often >'http' or 'https' in the beginning of the url (before '://') > > [scheme:]scheme-specific-part[#fragment] > >Which version of tomcat did you download (the full version or 1.4. LE) ? > >Hope it helps >-reynir > > > > > -Original Message- > > From: neal [mailto:[EMAIL PROTECTED] > > Sent: 1. mars 2003 20:36 > > To: Tomcat Users List > > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > > > > Hmm ... it appears that for some F***'ed up reason, that the > > URL created by using his.getClass().getResource() is no > > longer acceptable for TRAX when using Tomcat 4.1.18, as > > compared to Tomcat 4.0.4. > > > > The problem is that the URI begins with a "/". If I remove > > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. > > > > Why would Tomcat be involving itself in such issues? Only > > thing I can think of is that maybe the conditions for this > > Apache Exception were redefined in > > 4.1.18: > > > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > > Neal > > > > -Original Message- > > From: neal [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 01, 2003 11:02 AM > > To: Tomcat Users List > > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > > > > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 > > (Windows) and now it doesn't work! It appears that I have a > > problem now with parsing my conf.xml file in my initServlet. > > > > I noticed that the new Tomcat has an "endorsed" directory > > with a different copy of Xerces in it. Is this somehow related? > > > > Here's the error: > > javax.xml.transform.TransformerException: > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > > > > Thanks. > > Neal > > > > > > - > > 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] > > > > > >- >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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
If that's normal then why did it work in Tomcat 4.0.4 and not in Tomcat 4.1.18? I can not say positively that it was not adding that leading slash in 4.0.4 but it was the first thing I noticed and when I took it out it fixed the problem. What else could it be? Neal -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 1:24 PM To: Tomcat Users List Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) That's normal. The full URL should look soemthing like this, though... file:///D:/dev/tomcat/webapps/myapp/WEB-INF/classes/org/mypackage/somefile.p roperties or if it is inside an archive... jar:file:///D:/dev/tomcat/webapps/myapp/WEB-INF/lib/somejar.jar!/org/mypacka ge/somefile.properties Jake At 01:00 PM 3/1/2003 -0800, you wrote: >Actually, > >It seems that the problem is that Class.getResource() is returning a URL >with a leading "/" dispite the fact that I'm on a Windows box. For >instance, its returning a url like: > >/D:/dev/tomcat/... > >where it *should* be returning: > >D:/dev/tomcat/.. > >If I mockup a String of that nature it works fine which seems to confirm >this. > >So, I could always compensate by removing the "/" but I ultimately deploy to >Linux and I presume this will mess up my paths in my production site if I do >so. > >Of course, I could always find a workaround ... but ... should I have to? I >mean, I'm guessing this is a bug somehow associated with the context of this >version of Tomcat. > >Any thoughts? > >Thanks. > >Neal > >-Original Message----- >From: Reynir Hübner [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 01, 2003 12:41 PM >To: Tomcat Users List >Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > >Hi, > >This may have something to do with an upgraded version of jaxp or xerces, >distributed with some dists of tomcat. >According to the error you're getting your url is missing scheme, often >'http' or 'https' in the beginning of the url (before '://') > > [scheme:]scheme-specific-part[#fragment] > >Which version of tomcat did you download (the full version or 1.4. LE) ? > >Hope it helps >-reynir > > > > > -Original Message- > > From: neal [mailto:[EMAIL PROTECTED] > > Sent: 1. mars 2003 20:36 > > To: Tomcat Users List > > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > > > > Hmm ... it appears that for some F***'ed up reason, that the > > URL created by using his.getClass().getResource() is no > > longer acceptable for TRAX when using Tomcat 4.1.18, as > > compared to Tomcat 4.0.4. > > > > The problem is that the URI begins with a "/". If I remove > > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. > > > > Why would Tomcat be involving itself in such issues? Only > > thing I can think of is that maybe the conditions for this > > Apache Exception were redefined in > > 4.1.18: > > > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > > Neal > > > > -Original Message- > > From: neal [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 01, 2003 11:02 AM > > To: Tomcat Users List > > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > > > > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 > > (Windows) and now it doesn't work! It appears that I have a > > problem now with parsing my conf.xml file in my initServlet. > > > > I noticed that the new Tomcat has an "endorsed" directory > > with a different copy of Xerces in it. Is this somehow related? > > > > Here's the error: > > javax.xml.transform.TransformerException: > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > > > > Thanks. > > Neal > > > > > > - > > 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] > > > > > >- >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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
That's normal. The full URL should look soemthing like this, though... file:///D:/dev/tomcat/webapps/myapp/WEB-INF/classes/org/mypackage/somefile.properties or if it is inside an archive... jar:file:///D:/dev/tomcat/webapps/myapp/WEB-INF/lib/somejar.jar!/org/mypackage/somefile.properties Jake At 01:00 PM 3/1/2003 -0800, you wrote: Actually, It seems that the problem is that Class.getResource() is returning a URL with a leading "/" dispite the fact that I'm on a Windows box. For instance, its returning a url like: /D:/dev/tomcat/... where it *should* be returning: D:/dev/tomcat/.. If I mockup a String of that nature it works fine which seems to confirm this. So, I could always compensate by removing the "/" but I ultimately deploy to Linux and I presume this will mess up my paths in my production site if I do so. Of course, I could always find a workaround ... but ... should I have to? I mean, I'm guessing this is a bug somehow associated with the context of this version of Tomcat. Any thoughts? Thanks. Neal -Original Message- From: Reynir Hübner [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 12:41 PM To: Tomcat Users List Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) Hi, This may have something to do with an upgraded version of jaxp or xerces, distributed with some dists of tomcat. According to the error you're getting your url is missing scheme, often 'http' or 'https' in the beginning of the url (before '://') [scheme:]scheme-specific-part[#fragment] Which version of tomcat did you download (the full version or 1.4. LE) ? Hope it helps -reynir > -Original Message- > From: neal [mailto:[EMAIL PROTECTED] > Sent: 1. mars 2003 20:36 > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > Hmm ... it appears that for some F***'ed up reason, that the > URL created by using his.getClass().getResource() is no > longer acceptable for TRAX when using Tomcat 4.1.18, as > compared to Tomcat 4.0.4. > > The problem is that the URI begins with a "/". If I remove > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. > > Why would Tomcat be involving itself in such issues? Only > thing I can think of is that maybe the conditions for this > Apache Exception were redefined in > 4.1.18: > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > Neal > > -Original Message----- > From: neal [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 01, 2003 11:02 AM > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 > (Windows) and now it doesn't work! It appears that I have a > problem now with parsing my conf.xml file in my initServlet. > > I noticed that the new Tomcat has an "endorsed" directory > with a different copy of Xerces in it. Is this somehow related? > > Here's the error: > javax.xml.transform.TransformerException: > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > Thanks. > Neal > > > - > 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] > > - 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]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Actually, It seems that the problem is that Class.getResource() is returning a URL with a leading "/" dispite the fact that I'm on a Windows box. For instance, its returning a url like: /D:/dev/tomcat/... where it *should* be returning: D:/dev/tomcat/.. If I mockup a String of that nature it works fine which seems to confirm this. So, I could always compensate by removing the "/" but I ultimately deploy to Linux and I presume this will mess up my paths in my production site if I do so. Of course, I could always find a workaround ... but ... should I have to? I mean, I'm guessing this is a bug somehow associated with the context of this version of Tomcat. Any thoughts? Thanks. Neal -Original Message- From: Reynir Hübner [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 12:41 PM To: Tomcat Users List Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) Hi, This may have something to do with an upgraded version of jaxp or xerces, distributed with some dists of tomcat. According to the error you're getting your url is missing scheme, often 'http' or 'https' in the beginning of the url (before '://') [scheme:]scheme-specific-part[#fragment] Which version of tomcat did you download (the full version or 1.4. LE) ? Hope it helps -reynir > -Original Message- > From: neal [mailto:[EMAIL PROTECTED] > Sent: 1. mars 2003 20:36 > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > Hmm ... it appears that for some F***'ed up reason, that the > URL created by using his.getClass().getResource() is no > longer acceptable for TRAX when using Tomcat 4.1.18, as > compared to Tomcat 4.0.4. > > The problem is that the URI begins with a "/". If I remove > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. > > Why would Tomcat be involving itself in such issues? Only > thing I can think of is that maybe the conditions for this > Apache Exception were redefined in > 4.1.18: > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > Neal > > -Original Message----- > From: neal [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 01, 2003 11:02 AM > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 > (Windows) and now it doesn't work! It appears that I have a > problem now with parsing my conf.xml file in my initServlet. > > I noticed that the new Tomcat has an "endorsed" directory > with a different copy of Xerces in it. Is this somehow related? > > Here's the error: > javax.xml.transform.TransformerException: > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > Thanks. > Neal > > > - > 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] > > - 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]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Hi, This may have something to do with an upgraded version of jaxp or xerces, distributed with some dists of tomcat. According to the error you're getting your url is missing scheme, often 'http' or 'https' in the beginning of the url (before '://') [scheme:]scheme-specific-part[#fragment] Which version of tomcat did you download (the full version or 1.4. LE) ? Hope it helps -reynir > -Original Message- > From: neal [mailto:[EMAIL PROTECTED] > Sent: 1. mars 2003 20:36 > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > Hmm ... it appears that for some F***'ed up reason, that the > URL created by using his.getClass().getResource() is no > longer acceptable for TRAX when using Tomcat 4.1.18, as > compared to Tomcat 4.0.4. > > The problem is that the URI begins with a "/". If I remove > that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. > > Why would Tomcat be involving itself in such issues? Only > thing I can think of is that maybe the conditions for this > Apache Exception were redefined in > 4.1.18: > > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > Neal > > -Original Message----- > From: neal [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 01, 2003 11:02 AM > To: Tomcat Users List > Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) > > > I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 > (Windows) and now it doesn't work! It appears that I have a > problem now with parsing my conf.xml file in my initServlet. > > I noticed that the new Tomcat has an "endorsed" directory > with a different copy of Xerces in it. Is this somehow related? > > Here's the error: > javax.xml.transform.TransformerException: > org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI > > > Thanks. > Neal > > > - > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Hmm ... I'm wondering how this is going to affect the x-platform-ness of my application now. I'm developing on a windows platform and deploying to linux, wherein my paths actually *should* start with a "/". UUugh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
Hmm ... it appears that for some F***'ed up reason, that the URL created by using his.getClass().getResource() is no longer acceptable for TRAX when using Tomcat 4.1.18, as compared to Tomcat 4.0.4. The problem is that the URI begins with a "/". If I remove that leading "/" suddenly the URLs are acceptable in Tomcat 4.1.18. Why would Tomcat be involving itself in such issues? Only thing I can think of is that maybe the conditions for this Apache Exception were redefined in 4.1.18: org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI Neal -Original Message- From: neal [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 11:02 AM To: Tomcat Users List Subject: RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4) I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 (Windows) and now it doesn't work! It appears that I have a problem now with parsing my conf.xml file in my initServlet. I noticed that the new Tomcat has an "endorsed" directory with a different copy of Xerces in it. Is this somehow related? Here's the error: javax.xml.transform.TransformerException: org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI Thanks. Neal - 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]
RE: XML problem with Tomcat 4.1.18 (but was ok in 4.0.4)
I ported my app from Tomcat 4.0.4 (Windows) to Tomcat 4.1.18 (Windows) and now it doesn't work! It appears that I have a problem now with parsing my conf.xml file in my initServlet. I noticed that the new Tomcat has an "endorsed" directory with a different copy of Xerces in it. Is this somehow related? Here's the error: javax.xml.transform.TransformerException: org.apache.xml.utils.URI$MalformedURIException: No scheme found in URI Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
