Chris Burdess wrote:
Olivier Jolly wrote:
There is no way to determine whether a URL scheme is "valid" or not,
assuming that is even meaningful.
If we append the spec to the context in this case we should also do
so in the case of
url = new URL("http://www.foo.bar.com");
url = new URL(url, "http://www.foo.bar.com");
this should produce "http://www.foo.bar.com/http://www.foo.bar.com".
Also please note, I'm not saying this is a good idea, quite the reverse.
Actually, there is a way to determine whether a protocol is valid or
not, or more precisely, whether we have an handler for it or no.
That isn't the same thing, and I think it would be unwise to
differentiate based purely on whether there is a runtime handler set up
for it. Let's say I have a J2EE application with 30 different jar
files, one of which contains a handler for the "foo" schema. I have the
following code:
url = new URL(new URL("http://widgets.com"), "foo://
override.widgets.com/stuff");
Now, because my deployment environment is complicated, perhaps my
foo.jar doesn't get included or there is a nasty classloader issue
which prevents the handler from getting loaded. I would expect to get a
MalformedURLException but instead I silently get a bogus URL
"http://widgets.com/foo://override.widgets.com/stuff".
At this point I start hunting down the Classpath contributors who made
this design decision and popping away at them with an SLR.
We also have to take into consideration the behavior of Sun's
implementation. Given what you say above, the fine engineers at Sun
should be shaking in their boots.
Also RFC 2396 section 3 seems to explicitly allow for a ':' in the
specification to be appended to the context.
Given that it is explicitly allowed to have a ':' how would you handle this?
David Daney
David Daney.