We have ORP/classpath running with some business applications like Jigsaw and
Tomcat, and we found limitations of classpath's URL/URLStreamHandler to handle
all kinds of url formats, especially file, jar protocols.
We have worked out some ad hoc solutions like
http://www.mail-archive.com/[email protected]/msg03664.html and
http://www.mail-archive.com/[email protected]/msg03727.html).
The original author of URLStreamHandler, Aaron, points out that it's not wise to do
all
the protocol specific parsing in parseURL. We agree with him, and we suggest some
changes like the following:
1. In URL.java:
public
URL(URL context, String url, URLStreamHandler ph) throws MalformedURLException
{ ... ...
if ( context == null ){
this.ph.parseURL(this, url, start, end);
} else {
some ad hoc combination of context and url.
}
}
We suggest that whatever context will be, call ph.parseURL(), then it's clear and non-
redundant, and can delegate some protocol-specific parsing jobs to protocol handlers.
2. In URLStreamHandler.java
protected void
parseURL(URL url, String url_string, int start, int end){
}
Will be changed to do normal tasks required by java library documentation, i.e,
parsing
suppose the protocol is http, and do tasks like canonicaling "through the removal of
directory changes made by occurences of ".." and ".". For a more detailed description
of
URL parsing"(Classpath's current implementation even hasn't addressed this problem).
Also,
protected String toExternalForm(URL u){
}
will suppose a output for normal protocol.
3. Let non-http protocol handlers do parseURL themselves.
That's to say, let gnu/java/net/protocol/*/Handler.java override toExternalForm. These
protocols includes file, jar etc.
4. If the protocol is somewhat specific in output format, like jar, override
toExternalForm.
That's to say, let gnu/java/net/protocol/jar/Handler.java override toExternalForm.
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
