You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2005/10/02 15:32:20 UTC
URL Handlers Service
Hello,
I am in the process of re-implementing the URL Handlers service for
Felix. The URL Handlers service is essentially a singleton, since it
must make calls to URL.setURLStreamHandlerFactory() and
URLConnection.setContentHandlerFactory(), which are singleton methods.
However, I would like to consider approaches for making it work when
multiple instances of the framework are in memory at the same time. As
far as I can see, there are at least three approaches:
1. First framework instance wins, every other framework instance is
out of luck. (However, they will be able to use the stream and
content handlers of the first framework instance implicitly.)
2. All stream and content handlers for all framework instances are
aggregated; thus, individual frameworks use a merged set of handlers.
3. Framework isolation is maintained, i.e., bundles in a given
framework instance only see handlers registered by bundles in the
same framework instance.
For me, #3 seems like the way to go, but I am not sure how easily this
can be achieved. My thought was to create a static implementation of the
URL Handler service with which each framework instance would register
upon creation.
When asked for a handler, I imagine that the URL Handlers service would
always return a handler proxy (except for built-in handlers), even if no
handlers existed, in which case the proxy would just throw some
reasonable exception when it was invoked. The reason to always return a
proxy is somewhat complicated, but is related to the fact that the JVM
libraries cache the answer in some cases and also because some framework
instances may have handlers registered and other may not, thus the
distinction between having and not having a handler is a little murky.
When a handler proxy is invoked it could use
SecurityManager.getClassContext() to get the call stack of classes and
walk up the call stack to get the first class that is loaded from a
bundle class loader. From the bundle class loader it could then find out
to which framework instance the bundle belonged and use this information
to find out if the framework instance has a registered handler service
that matches the request. If not, it would throw an appropriate
exception, if so the call would be delegated to the handler service.
Of course, there are probably a lot of little details I have not thought
about, but this is a general outline of how I am thinking of approaching
the problem. Also, I am figuring that we can optimize the single
framework instance case so that it doesn't have to do a lot of extra
work if only one framework instance exists.
Comments are welcome.
-> richard
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Ralph Goers wrote:
> OK. That makes it tougher. So if two bundles want to register the
> same protocol I guess one of them loses?
Well, in the standard Java sense it is worse than that, since only one
entity can set the stream handler factory. OSGi URL Handlers improves on
this by allowing bundles to share the single stream handler factory.
Regarding your specific question, yes, only one bundle at a time can
provide a handler for a given protocol and the framework selects which
one to use; however, other bundles are free to offer their handlers for
the same protocol and the framework might use theirs if the current one
goes away (i.e., the bundle providing it is stopped).
> I don't understand why this is a problem. I was under the impression
> that OSGi would always be returning a proxy stream handler that is
> basically the same for every protocol. So it is the proxy that needs
> the list of handlers, not the JVM. Am I misunderstanding section 11.3.1?
You are correct, but I think that Niclas was describing standard Java
behavior, not the OSGi URL Handlers spec behavior. OSGi URL Handlers
takes the standard Java behavior one step further by sharing URL
handling among bundles, we are talking about taking it even one step
further by sharing URL handling among framework instances.
-> richard
Re: URL Handlers Service
Posted by Ralph Goers <Ra...@dslextreme.com>.
Niclas Hedhman wrote:
>On Monday 03 October 2005 08:23, Ralph Goers wrote:
>
>
>>1. Every bundle should have its own URL handlers.
>>
>>
>
>Incorrect. A bundle can install URL handlers, which is made available to all
>other bundles. And those can use it without the service interfaces, i.e.
>
>URL abc = new URL( "my://special/url" );
>InputStream in = abc.opneStream();
>
>
OK. That makes it tougher. So if two bundles want to register the same
protocol I guess one of them loses?
>
>
>>So why not just maintain the list of stream handlers and content for the
>>bundle in the Bundle implementation object? Then your proxy could just
>>look at that to determine if the protocol is supported.
>>
>>
>
>Because the above is dictated by the
>static public void URL.setURLStreamHandlerFactory(URLStreamHandlerFactory fac)
>method.
>
>The JVM only allows it to be set once, not reset, JVM wide, and the JVM will
>cache the URLStreamHandlers that the factory produces forever. IMHO, very
>nasty, and I am surprised that Sun hasn't done something about it over all
>these years.
>
>
I don't understand why this is a problem. I was under the impression
that OSGi would always be returning a proxy stream handler that is
basically the same for every protocol. So it is the proxy that needs
the list of handlers, not the JVM. Am I misunderstanding section 11.3.1?
Ralph
Re: URL Handlers Service
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 October 2005 08:23, Ralph Goers wrote:
> 1. Every bundle should have its own URL handlers.
Incorrect. A bundle can install URL handlers, which is made available to all
other bundles. And those can use it without the service interfaces, i.e.
URL abc = new URL( "my://special/url" );
InputStream in = abc.opneStream();
> So why not just maintain the list of stream handlers and content for the
> bundle in the Bundle implementation object? Then your proxy could just
> look at that to determine if the protocol is supported.
Because the above is dictated by the
static public void URL.setURLStreamHandlerFactory(URLStreamHandlerFactory fac)
method.
The JVM only allows it to be set once, not reset, JVM wide, and the JVM will
cache the URLStreamHandlers that the factory produces forever. IMHO, very
nasty, and I am surprised that Sun hasn't done something about it over all
these years.
> so what I am suggesting might not make any sense.
No, but that is Ok. :o)
Cheers
Niclas
Re: URL Handlers Service
Posted by Ralph Goers <Ra...@dslextreme.com>.
Richard S. Hall wrote:
>
> For me, #3 seems like the way to go, but I am not sure how easily this
> can be achieved. My thought was to create a static implementation of
> the URL Handler service with which each framework instance would
> register upon creation.
>
> When asked for a handler, I imagine that the URL Handlers service
> would always return a handler proxy (except for built-in handlers),
> even if no handlers existed, in which case the proxy would just throw
> some reasonable exception when it was invoked. The reason to always
> return a proxy is somewhat complicated, but is related to the fact
> that the JVM libraries cache the answer in some cases and also because
> some framework instances may have handlers registered and other may
> not, thus the distinction between having and not having a handler is a
> little murky.
>
> When a handler proxy is invoked it could use
> SecurityManager.getClassContext() to get the call stack of classes and
> walk up the call stack to get the first class that is loaded from a
> bundle class loader. From the bundle class loader it could then find
> out to which framework instance the bundle belonged and use this
> information to find out if the framework instance has a registered
> handler service that matches the request. If not, it would throw an
> appropriate exception, if so the call would be delegated to the
> handler service.
>
> Of course, there are probably a lot of little details I have not
> thought about, but this is a general outline of how I am thinking of
> approaching the problem. Also, I am figuring that we can optimize the
> single framework instance case so that it doesn't have to do a lot of
> extra work if only one framework instance exists.
>
> Comments are welcome.
>
> -> richard
Now I will admit that I am not too familiar with the OSGi spec - I just
now downloaded it and glanced at it, and I have not looked at the
current code, so what I am suggesting might not make any sense. It
seems to me that option 3 is what you should strive for but it seems the
problem is simply in the implementation. If my quick glance is correct
then:
1. Every bundle should have its own URL handlers.
2. I would assume that if there are multiple instances of the framework
that bundle instances within each framework are separate from the same
bundles within other framework instances.
So why not just maintain the list of stream handlers and content for the
bundle in the Bundle implementation object? Then your proxy could just
look at that to determine if the protocol is supported.
Ralph
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
>You realize that this is a very expensive procedure? Not sure exactly when you
>mean the above should take place, but it sounds like "very often"...
>
>IMHO, the only reasonable approach is to share the handlers within the JVM
>(i.e. solution 2). Better yet if the sharing mechanism could be used (or
>cooperating with) the world "outside" OSGi.
>
That was my main concern, but I don't have any hard numbers to back it up.
I don't know that this would happen "very often", it would happen when
someone tried to open a URL that wasn't handled by a built-in handler,
correct? I am not sure how often that would be.
I am not against #2, however, the most logical to me seems to be #3
since otherwise you are bleeding services among framework instances. Are
there other ways of doing #3?
-> richard
Re: URL Handlers Service
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 02 October 2005 21:32, Richard S. Hall wrote:
> When a handler proxy is invoked it could use
> SecurityManager.getClassContext() to get the call stack of classes and
> walk up the call stack to get the first class that is loaded from a
> bundle class loader.
You realize that this is a very expensive procedure? Not sure exactly when you
mean the above should take place, but it sounds like "very often"...
IMHO, the only reasonable approach is to share the handlers within the JVM
(i.e. solution 2). Better yet if the sharing mechanism could be used (or
cooperating with) the world "outside" OSGi.
Cheers
Niclas
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
>Besides the fact that you will likely to get VerifyError or something similar,
>and potentially have to deal with issues in collaboration between the
>java.net and the com.sun.net classes, don't you still need the container's
>classloader to be involved?
>
>All in all, I think Classloader tricks will hit back pretty badly. They
>normally do.
>
>What happened to the application isolation spec slated for JDK1.5??
>
>
>Also, people who are more familiar with webapp containers... Are
>URLStreamHandlers really used in Tomcat, Weblogic, Websphere et al??
>
>Or is this a hypothetical discussion?
>
Even then, I think this approach would only help if everyone wanted to
use each others' stream handlers. For Felix, we wanted them isolated by
framework instance, which is possible since we know something about the
class loader and bundle details. If this were made to be completely
generic so that anyone could participate, then it would be even more
difficult to multiplex for isolation purposes.
-> richard
Re: URL Handlers Service
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 October 2005 20:26, Upayavira wrote:
> No, actually it is intended to fix the problem caused by a
> URLStreamHandler already set by a containing application (e.g. servlet
> container). Once you've got your own URLStreamHandler and have worked
> around the VM's one, then you can just get on and solve the problems
> that you were working on, and we (Cocoon and others) can happily embed
> Felix within servlet containers, comfortable in the knowledge that we
> can enjoy all of the benefits of your work on URLStreamHandlers without
> any conflict with our container or any other apps running within it.
Besides the fact that you will likely to get VerifyError or something similar,
and potentially have to deal with issues in collaboration between the
java.net and the com.sun.net classes, don't you still need the container's
classloader to be involved?
All in all, I think Classloader tricks will hit back pretty badly. They
normally do.
What happened to the application isolation spec slated for JDK1.5??
Also, people who are more familiar with webapp containers... Are
URLStreamHandlers really used in Tomcat, Weblogic, Websphere et al??
Or is this a hypothetical discussion?
Cheers
Niclas
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Yes, Niclas raises a very good point, too. I would not be high on
> modifying the byte code of URL...seems overly risky.
Okay. I'll mull some more. :-)
Regards, Upayavira
> Niclas Hedhman wrote:
>
>> On Monday 03 October 2005 22:51, Upayavira wrote:
>>
>>
>>> Okay. What I have in mind is that, outside of OSGi, they can do what
>>> they like - talk to the System classloader, etc. Inside of OSGi, we do
>>> what _we_ like, i.e. override the standard URL class as necessary. That
>>> way, a Felix app can run alongside another app in a container when both
>>> set StreamHandlers. But the non-OSGi app wouldn't need to know anything
>>> about OSGi's stream handlers, in fact, much better that it doesn't.
>>>
>>
>>
>> I have previously tried to replace simpler classes in the rt.jar, and
>> always got Errors from the JVM complaining that something malicious is
>> going on. Perhaps I was unlucky, but I suspect some minimum checks are
>> in place...
>>
>> Well, even if that is not the case or that we can circumvent that
>> somehow, how about this next scenario;
>>
>> // Fetch the felix classloader "somehow" like;
>> FelixClassLoader fcl = getClass().getClassLoader();
>>
>> // The FelixClassLoader will intercept the findClass()
>> // method, and load the URL.class from upayavira.jar :o)
>> URL mine = new URL( "mine://abc" );
>> // URL array, which is in the FelixClassloader namespace
>> // for the reasons of above.
>> URL[] urls = new URL[] { mine };
>>
>> // Creating a URLClassLoader, which will be loaded by the
>> // bootstrap classloader, and load the URL.class from // rt.jar.
>> // Then an assignment of // rt:URL[] = upayavira:URL[]
>> // will fail due to incompatible namespace, and a NoClassDefError
>> // will be thrown.
>> URLClassLoader ucl = new URLClassLoader( urls, parent );
>>
>> I.e. Any JDK class that takes or returns a URL, will not work with the
>> URL.class that is loaded 'specially'.
>>
>> But we could of course limit ourselves to JDK 1.1.x and I think we
>> have a better chance. ;o)
>>
>>
>> Cheers
>> Niclas
>>
>>
>>
>>
>>
>
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, Niclas raises a very good point, too. I would not be high on
modifying the byte code of URL...seems overly risky.
-> richard
Niclas Hedhman wrote:
>On Monday 03 October 2005 22:51, Upayavira wrote:
>
>
>>Okay. What I have in mind is that, outside of OSGi, they can do what
>>they like - talk to the System classloader, etc. Inside of OSGi, we do
>>what _we_ like, i.e. override the standard URL class as necessary. That
>>way, a Felix app can run alongside another app in a container when both
>>set StreamHandlers. But the non-OSGi app wouldn't need to know anything
>>about OSGi's stream handlers, in fact, much better that it doesn't.
>>
>>
>
>I have previously tried to replace simpler classes in the rt.jar, and always
>got Errors from the JVM complaining that something malicious is going on.
>Perhaps I was unlucky, but I suspect some minimum checks are in place...
>
>Well, even if that is not the case or that we can circumvent that somehow, how
>about this next scenario;
>
> // Fetch the felix classloader "somehow" like;
> FelixClassLoader fcl = getClass().getClassLoader();
>
> // The FelixClassLoader will intercept the findClass()
> // method, and load the URL.class from upayavira.jar :o)
> URL mine = new URL( "mine://abc" );
>
> // URL array, which is in the FelixClassloader namespace
> // for the reasons of above.
> URL[] urls = new URL[] { mine };
>
> // Creating a URLClassLoader, which will be loaded by the
> // bootstrap classloader, and load the URL.class from
> // rt.jar.
> // Then an assignment of
> // rt:URL[] = upayavira:URL[]
> // will fail due to incompatible namespace, and a NoClassDefError
> // will be thrown.
> URLClassLoader ucl = new URLClassLoader( urls, parent );
>
>I.e. Any JDK class that takes or returns a URL, will not work with the
>URL.class that is loaded 'specially'.
>
>But we could of course limit ourselves to JDK 1.1.x and I think we have a
>better chance. ;o)
>
>
>Cheers
>Niclas
>
>
>
>
>
Re: URL Handlers Service
Posted by Niclas Hedhman <ni...@apache.org>.
On Monday 03 October 2005 22:51, Upayavira wrote:
> Okay. What I have in mind is that, outside of OSGi, they can do what
> they like - talk to the System classloader, etc. Inside of OSGi, we do
> what _we_ like, i.e. override the standard URL class as necessary. That
> way, a Felix app can run alongside another app in a container when both
> set StreamHandlers. But the non-OSGi app wouldn't need to know anything
> about OSGi's stream handlers, in fact, much better that it doesn't.
I have previously tried to replace simpler classes in the rt.jar, and always
got Errors from the JVM complaining that something malicious is going on.
Perhaps I was unlucky, but I suspect some minimum checks are in place...
Well, even if that is not the case or that we can circumvent that somehow, how
about this next scenario;
// Fetch the felix classloader "somehow" like;
FelixClassLoader fcl = getClass().getClassLoader();
// The FelixClassLoader will intercept the findClass()
// method, and load the URL.class from upayavira.jar :o)
URL mine = new URL( "mine://abc" );
// URL array, which is in the FelixClassloader namespace
// for the reasons of above.
URL[] urls = new URL[] { mine };
// Creating a URLClassLoader, which will be loaded by the
// bootstrap classloader, and load the URL.class from
// rt.jar.
// Then an assignment of
// rt:URL[] = upayavira:URL[]
// will fail due to incompatible namespace, and a NoClassDefError
// will be thrown.
URLClassLoader ucl = new URLClassLoader( urls, parent );
I.e. Any JDK class that takes or returns a URL, will not work with the
URL.class that is loaded 'specially'.
But we could of course limit ourselves to JDK 1.1.x and I think we have a
better chance. ;o)
Cheers
Niclas
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Upayavira wrote:
>
>> But if that MyHost code is running within a bundle, surely it would
>> use Felix's classloader?
>
>
>
> Yes, I stated that.
>
>> What scenarios are there under which an app running in an OSGi
>> container would _not_ use the Felix classloader? That is, without the
>> Felix Classlaoder being somewhere in the classloader chain?
>
>
>
> We are talking at cross purposes, I think. I all code to be loaded is
> inside of a bundle, then we will potentially get to intercept the class
> load call for URL.class, unless they do something like create their own
> class loader (which uses the system class loader as its parent by
> default) or just simply directly uses the system class loader.
>
> However, I thought you were also referring to the generic case, where
> you have a host application that creates an instance of Felix...in that
> case there is nothing you can do.
>
> No matter, there is still no way to guarantee that everyone uses your
> class loader even inside a bundle, because the system class loader is
> always accessible.
Okay. What I have in mind is that, outside of OSGi, they can do what
they like - talk to the System classloader, etc. Inside of OSGi, we do
what _we_ like, i.e. override the standard URL class as necessary. That
way, a Felix app can run alongside another app in a container when both
set StreamHandlers. But the non-OSGi app wouldn't need to know anything
about OSGi's stream handlers, in fact, much better that it doesn't.
Make sense now? :-)
Regards, Upayavira
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Upayavira wrote:
> But if that MyHost code is running within a bundle, surely it would
> use Felix's classloader?
Yes, I stated that.
> What scenarios are there under which an app running in an OSGi
> container would _not_ use the Felix classloader? That is, without the
> Felix Classlaoder being somewhere in the classloader chain?
We are talking at cross purposes, I think. I all code to be loaded is
inside of a bundle, then we will potentially get to intercept the class
load call for URL.class, unless they do something like create their own
class loader (which uses the system class loader as its parent by
default) or just simply directly uses the system class loader.
However, I thought you were also referring to the generic case, where
you have a host application that creates an instance of Felix...in that
case there is nothing you can do.
No matter, there is still no way to guarantee that everyone uses your
class loader even inside a bundle, because the system class loader is
always accessible.
-> richard
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Upayavira wrote:
>
>> I was working under the impression (potentially mistaken) that you ask
>> a classloader for a class, and that classloader defers to its parent,
>> and if its parent doesn't find the class it looks for it in its own
>> classpath. (This understanding comes from some limited work with the
>> AntClassLoader).
>
>
>
> Your understanding is correct.
>
>> In this case, you could intercept the request before you defer to the
>> System/Parent classloader. Are you saying that that _couldn't_ work?
>
>
>
> No, it would really work, because you cannot force everyone to use your
> class loader to load their classes. Certainly Felix can force bundles to
> use its class loader, but that is about it.
>
> For example, assume I write MyHost:
>
> public class MyHost {
> Felix felix = null;
> public MyHost() {
> URL.setURLStreamHandlerFactory(...);
> felix = new Felix();
> }
> }
>
> In such a situation, Felix has no control over the class loader loading
> MyHost.class, so URL.class would be loaded by some other class loader
> (most likely the standard app class loader).
But if that MyHost code is running within a bundle, surely it would use
Felix's classloader?
What scenarios are there under which an app running in an OSGi container
would _not_ use the Felix classloader? That is, without the Felix
Classlaoder being somewhere in the classloader chain?
Regards, Upayavira
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sorry, that should say, "No, it would NOT really work..."
-> richard
Richard S. Hall wrote:
> No, it would really work, because you cannot force everyone to use
> your class loader to load their classes. Certainly Felix can force
> bundles to use its class loader, but that is about it.
>
> For example, assume I write MyHost:
>
> public class MyHost {
> Felix felix = null;
> public MyHost() {
> URL.setURLStreamHandlerFactory(...);
> felix = new Felix();
> }
> }
>
> In such a situation, Felix has no control over the class loader
> loading MyHost.class, so URL.class would be loaded by some other class
> loader (most likely the standard app class loader).
>
> -> richard
>
>
>
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Upayavira wrote:
> I was working under the impression (potentially mistaken) that you ask
> a classloader for a class, and that classloader defers to its parent,
> and if its parent doesn't find the class it looks for it in its own
> classpath. (This understanding comes from some limited work with the
> AntClassLoader).
Your understanding is correct.
> In this case, you could intercept the request before you defer to the
> System/Parent classloader. Are you saying that that _couldn't_ work?
No, it would really work, because you cannot force everyone to use your
class loader to load their classes. Certainly Felix can force bundles to
use its class loader, but that is about it.
For example, assume I write MyHost:
public class MyHost {
Felix felix = null;
public MyHost() {
URL.setURLStreamHandlerFactory(...);
felix = new Felix();
}
}
In such a situation, Felix has no control over the class loader loading
MyHost.class, so URL.class would be loaded by some other class loader
(most likely the standard app class loader).
-> richard
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Upayavira wrote:
>
>> No, actually it is intended to fix the problem caused by a
>> URLStreamHandler already set by a containing application (e.g. servlet
>> container). Once you've got your own URLStreamHandler and have worked
>> around the VM's one, then you can just get on and solve the problems
>> that you were working on, and we (Cocoon and others) can happily embed
>> Felix within servlet containers, comfortable in the knowledge that we
>> can enjoy all of the benefits of your work on URLStreamHandlers
>> without any conflict with our container or any other apps running
>> within it.
>>
>> So, I think I'm aiming to solve a slightly different issue. Does it
>> make more sense in the light of that?
>
>
>
> Yes, it makes sense and that is an important problem too, but that gets
> us into other difficulties because we (from a Felix perspective) cannot
> assume that we control the class loader that loads the hosting
> application. This sounds like it would have to be integrated into a
> generic launcher utility of some sort.
Interesting.
I was working under the impression (potentially mistaken) that you ask a
classloader for a class, and that classloader defers to its parent, and
if its parent doesn't find the class it looks for it in its own
classpath. (This understanding comes from some limited work with the
AntClassLoader). In this case, you could intercept the request before
you defer to the System/Parent classloader. Are you saying that that
_couldn't_ work?
Regards, Upayavira
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Upayavira wrote:
> No, actually it is intended to fix the problem caused by a
> URLStreamHandler already set by a containing application (e.g. servlet
> container). Once you've got your own URLStreamHandler and have worked
> around the VM's one, then you can just get on and solve the problems
> that you were working on, and we (Cocoon and others) can happily embed
> Felix within servlet containers, comfortable in the knowledge that we
> can enjoy all of the benefits of your work on URLStreamHandlers
> without any conflict with our container or any other apps running
> within it.
>
> So, I think I'm aiming to solve a slightly different issue. Does it
> make more sense in the light of that?
Yes, it makes sense and that is an important problem too, but that gets
us into other difficulties because we (from a Felix perspective) cannot
assume that we control the class loader that loads the hosting
application. This sounds like it would have to be integrated into a
generic launcher utility of some sort.
-> richard
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Upayavira wrote:
>
>> I don't know if this is a completely stupid idea, but...
>>
>> If we've got our own classloader, then requests for classes will be
>> passed to that for resolution. Hence, if a request for java.net.URL is
>> made, such that the URL.setURLStreamHandlerFactory() method can be
>> called, could we not, instead of returning a java.net.URL class,
>> return a proxy class that has an alternative implementation of
>> setURLStreamHandlerFactory()? That way we just route around the JVM
>> problem within our own classloader.
>>
>> Reasonable? Stupid?
>
>
>
> Well, I have certainly had worse ideas, but I am not sure if we should
> us this approach. And ultimately, I don't think it solves the issue. We
> are in a situation where we have a single stream of requests for
> protocol handlers that must be multiplexed out to the appropriated
> framework instance to be serviced. The above approach doesn't really
> help with the multiplexing aspect.
No, actually it is intended to fix the problem caused by a
URLStreamHandler already set by a containing application (e.g. servlet
container). Once you've got your own URLStreamHandler and have worked
around the VM's one, then you can just get on and solve the problems
that you were working on, and we (Cocoon and others) can happily embed
Felix within servlet containers, comfortable in the knowledge that we
can enjoy all of the benefits of your work on URLStreamHandlers without
any conflict with our container or any other apps running within it.
So, I think I'm aiming to solve a slightly different issue. Does it make
more sense in the light of that?
Regards, Upayavira
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Upayavira wrote:
> I don't know if this is a completely stupid idea, but...
>
> If we've got our own classloader, then requests for classes will be
> passed to that for resolution. Hence, if a request for java.net.URL is
> made, such that the URL.setURLStreamHandlerFactory() method can be
> called, could we not, instead of returning a java.net.URL class,
> return a proxy class that has an alternative implementation of
> setURLStreamHandlerFactory()? That way we just route around the JVM
> problem within our own classloader.
>
> Reasonable? Stupid?
Well, I have certainly had worse ideas, but I am not sure if we should
us this approach. And ultimately, I don't think it solves the issue. We
are in a situation where we have a single stream of requests for
protocol handlers that must be multiplexed out to the appropriated
framework instance to be serviced. The above approach doesn't really
help with the multiplexing aspect.
-> richard
Re: URL Handlers Service
Posted by Jeremy Volkman <jv...@gmail.com>.
I also thought about that. I believe you would have to override the
system classloader by specifying the java.system.class.loader property
at jvm startup, but I am not sure. A method like this may be able to
solve the problem for all instances trying to set these singletons,
not just OSGi-implemented ones (e.g., a parent servlet container).
Jeremy
On 10/3/05, Upayavira <uv...@odoko.co.uk> wrote:
> Richard S. Hall wrote:
> > Niclas Hedhman wrote:
> >
> >> At the end of the day, the contract to be fulfilled lies in the
> >> URLStreamHandler and its factory. You are expected to subclass the
> >> URLStreamHandler and override a bunch of methods, like
> >> openConnection(), parseURL() and toExternalForm(). The real problem
> >> has nothing much to do with OSGi. It just try to provide a mechanism
> >> to overcome the JVM/JDK limitations in a colaboration friendly manner.
> >>
> >
> > Exactly. URL handling was implemented under the assumption that it would
> > be controlled and used by a single application. The OSGi framework
> > provides a collaborative environment for independent third parties. This
> > in and of itself would still be okay with the URL Handlers service spec,
> > but now we want to throw into the mix having multiple OSGi framework
> > instances, which conceptually each have their own URL Handlers service.
>
> I don't know if this is a completely stupid idea, but...
>
> If we've got our own classloader, then requests for classes will be
> passed to that for resolution. Hence, if a request for java.net.URL is
> made, such that the URL.setURLStreamHandlerFactory() method can be
> called, could we not, instead of returning a java.net.URL class, return
> a proxy class that has an alternative implementation of
> setURLStreamHandlerFactory()? That way we just route around the JVM
> problem within our own classloader.
>
> Reasonable? Stupid?
>
> Upayavira
>
Re: URL Handlers Service
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Niclas Hedhman wrote:
>
>> At the end of the day, the contract to be fulfilled lies in the
>> URLStreamHandler and its factory. You are expected to subclass the
>> URLStreamHandler and override a bunch of methods, like
>> openConnection(), parseURL() and toExternalForm(). The real problem
>> has nothing much to do with OSGi. It just try to provide a mechanism
>> to overcome the JVM/JDK limitations in a colaboration friendly manner.
>>
>
> Exactly. URL handling was implemented under the assumption that it would
> be controlled and used by a single application. The OSGi framework
> provides a collaborative environment for independent third parties. This
> in and of itself would still be okay with the URL Handlers service spec,
> but now we want to throw into the mix having multiple OSGi framework
> instances, which conceptually each have their own URL Handlers service.
I don't know if this is a completely stupid idea, but...
If we've got our own classloader, then requests for classes will be
passed to that for resolution. Hence, if a request for java.net.URL is
made, such that the URL.setURLStreamHandlerFactory() method can be
called, could we not, instead of returning a java.net.URL class, return
a proxy class that has an alternative implementation of
setURLStreamHandlerFactory()? That way we just route around the JVM
problem within our own classloader.
Reasonable? Stupid?
Upayavira
Re: URL Handlers Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
>At the end of the day, the contract to be fulfilled lies in the
>URLStreamHandler and its factory. You are expected to subclass the
>URLStreamHandler and override a bunch of methods, like openConnection(),
>parseURL() and toExternalForm(). The real problem has nothing much to do with
>OSGi. It just try to provide a mechanism to overcome the JVM/JDK limitations
>in a colaboration friendly manner.
>
Exactly. URL handling was implemented under the assumption that it would
be controlled and used by a single application. The OSGi framework
provides a collaborative environment for independent third parties. This
in and of itself would still be okay with the URL Handlers service spec,
but now we want to throw into the mix having multiple OSGi framework
instances, which conceptually each have their own URL Handlers service.
-> richard
URL Handlers Service + IO Connector
Posted by Didier Donsez <di...@imag.fr>.
Hi all,
Don't forget there is another part of the R3 and R4 specs that "handle" URL
IO Connector Service (chapter 13 in the R3, chapter 104 in the R4 draft)
3 slides : some part in french (sorry) but the translation is below
http://www-adele.imag.fr/~donsez/cours/osgi.pdf#page=103
/"
Factory of IOConnection
Service d'enregistrement et de recherche de fabriques de connexion
d'entrée-sortie
* based on the principles of the javax.microedition.io J2ME API (JSR???)
* tracks and registers ConnectionFactory services
* * the io.scheme property specifies the schemes
* delegate the Connection forging to the Connection service concerned
"/
A simple implementation is given here
http://www-adele.imag.fr/~donsez/dev/osgi/io/readme.html
with a simple demo for Oscar1.x
http://www-adele.imag.fr/~donsez/dev/osgi/script/io.txt
Didier
Noel J. Bergman a écrit :
>Niclas Hedhman wrote:
>
>
>>Noel J. Bergman wrote:
>>
>>
>>>>I would like to consider approaches for making it work when
>>>>multiple instances of the framework are in memory
>>>>
>>>>
>>>A classloader at the level of a container can be used to provide
>>>
>>>
>isolation
>
>
>>>within the container. Does this fit your need?
>>>
>>>
>
>
>
>>Not sure. First thought is; No
>>
>>
>
>Right. I had the same thought after I read your e-mail to Ralph, and made
>the connnection back to the message subject (URL handlers, which rely upon a
>static method in a system class).
>
>I'll see Mark in a few weeks and pose the issue to him if I remember.
>
> --- Noel
>
>
>
--
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------
RE: URL Handlers Service
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Noel J. Bergman wrote:
> > > I would like to consider approaches for making it work when
> > > multiple instances of the framework are in memory
> > A classloader at the level of a container can be used to provide
isolation
> > within the container. Does this fit your need?
> Not sure. First thought is; No
Right. I had the same thought after I read your e-mail to Ralph, and made
the connnection back to the message subject (URL handlers, which rely upon a
static method in a system class).
I'll see Mark in a few weeks and pose the issue to him if I remember.
--- Noel
Re: URL Handlers Service
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 October 2005 11:24, Noel J. Bergman wrote:
> > I would like to consider approaches for making it work when
> > multiple instances of the framework are in memory
>
> A classloader at the level of a container can be used to provide isolation
> within the container. Does this fit your need?
Not sure. First thought is; No, since the management needs to sit in the
System Classloader (or equivalent high level) and it needs to look at the
caller, which is the one that can be isolated by classloaders.
At the end of the day, the contract to be fulfilled lies in the
URLStreamHandler and its factory. You are expected to subclass the
URLStreamHandler and override a bunch of methods, like openConnection(),
parseURL() and toExternalForm(). The real problem has nothing much to do with
OSGi. It just try to provide a mechanism to overcome the JVM/JDK limitations
in a colaboration friendly manner.
Cheers
Niclas
RE: URL Handlers Service
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I would like to consider approaches for making it work when
> multiple instances of the framework are in memory
A classloader at the level of a container can be used to provide isolation
within the container. Does this fit your need?
--- Noel