[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [equinox-dev] OSGi for Server-side...
- From: "Kaegi, Simon" <Simon.Kaegi@xxxxxxxxxx>
- Date: Wed, 26 Oct 2005 11:55:22 -0400
- Delivered-to: firstname.lastname@example.org
- Importance: normal
- Priority: normal
- Thread-index: AcXZ1W6B/aLwByddRVS3amQwzAD63gAZtUiA
- Thread-topic: [equinox-dev] OSGi for Server-side...
>> a URLFactory (see patch) e.g. At load time URL myURL = new URL("xxx")
>> is rewritten as URL myURL = URLFactory.createURL("xxx").
> And that the appropriate java.net.Handler is passed in the
> URL constructor???
The URLFactory has a 1 for 1 matchup of the URL Constructors. If the
handler isn't passed in, the URLFactory will parse the protocol from the
spec and figure out the appropriate handler using Eclipse's
>> In this way the URL remains portable between the ClassLoaders
>> (although the construction isn't)
> How about the tougher cases, such as URI.toURL() ??
Yep. The construction isn't portable between ClassLoaders.
For rt.jar I did some analysis a while back and URI.toURL() was the only
example I found that was really problematic.
Most other cases were really looking for file:// URLs and in the odd
case protocols directly supported in the VM.
In theory we could do more byte-code weaving for bundles that use
URI.toURL() but perhaps this is fighting a losing battle as any class
not loaded by the EclipseClassLoader that constructs URLs potentially
has this problem.
Still a neat idea ...
I'm not quite ready to throw in the towel and am open to spending some
time on this.
More analysis would be appreciated - especially on the verifier side.
> Personally I don't think intrusion on the established manner
> is the way to go.
> A collaborative API, with strong OSS support from major
> players, is much more likely to be successful and
> well-received than hacking the JVM and/or bytecode loading ;o)
Could be that we can't do it transparently in which case this is the way
This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.