dev issue with xerces 2003-02-24 - By sandygao@(protected)
> Document d = builder.parse(file);
The parse() method expects a URI. Apparently, "SYS:\tomcat\cocoon" is not a
URI, which is why Xerces fails to parse the document. The correct fix, IMO,
wouldn't be to change Xerces to special-case Novell file names, but to make
the code that calls Xerces to generate a valid URI and pass that to Xerces.
This way: Xerces works as it should; and the code calling Xerces is
portable (not depending on Xerces' special behavior).
Having said that, the different behavior between the 2 versions might still
be a problem. Which versions of Xerces are ship in them?
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@(protected)
xerces-juser@(protected)
rlabz.com To: xerces-j-user@(protected)
.apache.org
cc:
02/24/2003 03:18 Subject: dev issue with xerces
PM
Please respond to
xerces-j-user
Hi;
I've been working around this issue for a while. Some
programmers from Jetspeed and Cocoon suggested the actual
problem lies with xerces and should be committed there.
There are a couple of fixes in the Bug DB for Jetspeed and
Cocoon (Vadim Gritsenko) has done. The problem has to do
with the handling of Volume Names (Drive Letters) Novell
Drives are accessed and referred typically with "sys:" and
"vol1:" etc, whatever the name of the volume is. An example
of "working" to "broken" would be the difference in tomcat
4.1.19 to 4.1.20. If the xercesImpl.jar and
xmlParserAPIs.jar were replaced in 4.1.20 with the ones from
4.1.19, the "marshalling" errors would go away, and
applications such as Jetspeed and Cocoon will work properly.
I would be happy to work with any developer who is willing
to make a permanant commit on this issue so I don't have to
keep going back to the indivual groups.
Providing Previous Bug DB information:
http://nagoya.apache.org/bugzilla/showvotes.cgi?bug_id=3372
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14917
t's me again. I haven't tried out recently because we
switched over on a Linux
machine. I'll look for the log if i'm on the Novell Server
again. But the
investigation we made points to this piece of
CocoonServlet.java:
if(path.indexOf(':')>1)
url = new URL(path);
else
url = (new File(path)).toURL();
In the RC1 it's row no. 642.
If Novell comes with it's path: "SYS:\tomcat\cocoon" it will
certainly go the
URL-way!
So far...
Vadim;
Hello... can you tell me how you fixed this problem on
Cocoon so I can tell the
jetspeed folks.
Yes, sure... Code snippet below does the trick:
try {
if (path.indexOf(':') > 1) {
this.servletContextURL = new URL(path);
} else {
this.servletContextURL = new File(path).toURL();
}
} catch (java.net.MalformedURLException me) {
// VG: Novell has absolute file names starting with the
// volume name which is easily more then one letter.
// Examples: sys:/apache/cocoon or sys:\apache\cocoon
try {
this.servletContextURL = new File(path).toURL();
} catch (java.net.MalformedURLException ignored) {
throw new ServletException("Unable to determine servlet context
URL.", me);
}
}
"if" is for Windows, "else" for URLs, and inside "catch"
special case for Novell.
Vadim
------- Additional Comments From Rapha?l Luta 2002-12-10
10:57 -------
The fault seems to be an error when calling Xerces:
Document d = builder.parse(file);
with file = File().getCanonicalPath().
So it seems that Xerces is failing on Netware when trying to
read
an existing canonical file path.
I guess this should really be fixed at xerces level, don't
you think ?
I will try as a workaround using an URL object instead of a
canonical
path since it seems to work for Cocoon.
Thanks for the patch.
greets
todd
http://www.wiserlabz.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@(protected)
For additional commands, e-mail: xerces-j-user-help@(protected)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@(protected)
For additional commands, e-mail: xerces-j-user-help@(protected)
|
|
