URL Handlers service

["Richard S. Hall" <he...@ungoverned.org>]

[Warning! This will probably be long.]

Ok, I am on the verge of committing my URL Handlers service 
modifications to Felix. Currently, URL Handlers is broken for Felix and 
this should fix that; it should also add explicit support for using URL 
Handlers with multiple framework instances.

The approach I took to support multiple framework instances was what I 
outlined before. I created an essentially static URL Handlers service 
implementation. All framework instances wishing to use the URL Handlers 
service register with the static service upon creation. The static 
implementation acts as a multiplexer, routing incoming stream/content 
handler requests to handler services inside the appropriate framework 
instance. This means that bundles inside one framework instance will 
only see handler services from other bundles inside their respective 
framework instance. I have done minor testing and this appears to work, 
but more testing will definitely be necessary.

The approach I use to route incoming handler requests is to use the 
security class context, which gives me the call stack of classes. I then 
search backwards to find the first class loaded from a bundle and then 
route to the framework that owns that bundle. As an optimization, if 
there is only one framework instance, then I just assume that every 
request should be routed to it.

I also have a property that allows you to disable the URL Handlers 
service, which means that the URL.setURLStreamHandlerFactory() and 
URLConnection.setContentHandlerFactory() will not get called if the 
service is disabled. However, since this configuration property can be 
set on a per-instance basis, if one instance enables it, then these 
methods will get called. In that case, instances that disable it will 
simply not offer the service to their contained bundles, while instances 
that enable it will.

There are a few other things that still need to be finished before it is 
completely usable, which are:

    * Integrate with "bundle:" resource handling.
    * Deal with built-in handlers.
    * Implement appropriate security measures.

Even without these, it is still usable. Once these issues are addressed, 
then full spec compliance for URL Handlers will basically be done. My 
main motivation for now is to deal with built-in handlers properly, 
since I am currently just doing a hard-coded check for "file:", which is 
definitely a hack. The spec says a bit about dealing with built-in 
handlers, so I have to re-read it and see if it enlightens me on this topic.

I will try to get what I have committed next week, if I feel confident 
it won't break a bunch of stuff. :-)

-> richard

Re: URL Handlers service

["Richard S. Hall" <he...@ungoverned.org>]

Upayavira wrote:

>It is great to see you working hard on this. I get the impression that
>this was quite a knotty one.
>  
>

Actually, the implementation turned out to be pretty 
straightforward...the difficulty was more just deciding on the approach. 
This work has taken me a while because I have been working on 
presentations and papers and have been traveling a lot (currently in 
Taiwan), so I have been basically stealing time to work on the URL 
Handlers implementation. :-)

>I'd like, however, to ask if it is at all possible for you to do this
>kind of development work in a more bite-sized way. If your code comes in
>in small increments, you'll find that the community will likely
>understand it better, and thus be better equipped to help
>maintain/enhance it. Otherwise, it could just end up with us all
>deferring to you for maintenance of this code, which wouldn't be ideal.
>
>If you're concerned about breaking something, you can always commit the
>code you've done so far to some sandbox in SVN, then use svn move to
>move it to the correct resting place once it works.
>
>Consider this approach as a training exercise for the rest of us!
>
>Does this sound reasonable/plausible?
>

Sounds reasonable to me. However, in this particular situation I really 
cannot do this because I actually started this work on my Oscar 1.0.5 
code base, so it is not something I can commit until I forward port it 
to Felix. I started working on a 1.0.6 version of Oscar a while back 
because I realized I broke the old URL Handlers service when I 
implemented getResources() in Oscar 1.0.5. Oops! :-)

Luckily, these changes are fairly self-contained, so it should be easy 
to forward port and hopefully easy to understand.

-> richard

Re: URL Handlers service

[Upayavira <uv...@odoko.co.uk>]

Richard S. Hall wrote:
> [Warning! This will probably be long.]
> 
> Ok, I am on the verge of committing my URL Handlers service
> modifications to Felix. Currently, URL Handlers is broken for Felix and
> this should fix that; it should also add explicit support for using URL
> Handlers with multiple framework instances.
> 
> The approach I took to support multiple framework instances was what I
> outlined before. I created an essentially static URL Handlers service
> implementation. All framework instances wishing to use the URL Handlers
> service register with the static service upon creation. The static
> implementation acts as a multiplexer, routing incoming stream/content
> handler requests to handler services inside the appropriate framework
> instance. This means that bundles inside one framework instance will
> only see handler services from other bundles inside their respective
> framework instance. I have done minor testing and this appears to work,
> but more testing will definitely be necessary.
> 
> The approach I use to route incoming handler requests is to use the
> security class context, which gives me the call stack of classes. I then
> search backwards to find the first class loaded from a bundle and then
> route to the framework that owns that bundle. As an optimization, if
> there is only one framework instance, then I just assume that every
> request should be routed to it.
> 
> I also have a property that allows you to disable the URL Handlers
> service, which means that the URL.setURLStreamHandlerFactory() and
> URLConnection.setContentHandlerFactory() will not get called if the
> service is disabled. However, since this configuration property can be
> set on a per-instance basis, if one instance enables it, then these
> methods will get called. In that case, instances that disable it will
> simply not offer the service to their contained bundles, while instances
> that enable it will.
> 
> There are a few other things that still need to be finished before it is
> completely usable, which are:
> 
>    * Integrate with "bundle:" resource handling.
>    * Deal with built-in handlers.
>    * Implement appropriate security measures.
> 
> Even without these, it is still usable. Once these issues are addressed,
> then full spec compliance for URL Handlers will basically be done. My
> main motivation for now is to deal with built-in handlers properly,
> since I am currently just doing a hard-coded check for "file:", which is
> definitely a hack. The spec says a bit about dealing with built-in
> handlers, so I have to re-read it and see if it enlightens me on this
> topic.
> 
> I will try to get what I have committed next week, if I feel confident
> it won't break a bunch of stuff. :-)

It is great to see you working hard on this. I get the impression that
this was quite a knotty one.

I'd like, however, to ask if it is at all possible for you to do this
kind of development work in a more bite-sized way. If your code comes in
in small increments, you'll find that the community will likely
understand it better, and thus be better equipped to help
maintain/enhance it. Otherwise, it could just end up with us all
deferring to you for maintenance of this code, which wouldn't be ideal.

If you're concerned about breaking something, you can always commit the
code you've done so far to some sandbox in SVN, then use svn move to
move it to the correct resting place once it works.

Consider this approach as a training exercise for the rest of us!

Does this sound reasonable/plausible?

I hope I'm not too off-base suggesting this.

Regards, Upayavira

Re: URL Handlers service

["Richard S. Hall" <he...@ungoverned.org>]

Hello Jeremy,

Jeremy Volkman wrote:

>I assume you're referring to SecurityManager.getClassContext()?
>

Yes.

>The only problem I foresee is if a SecurityManager is installed that
>disallows creation of new SecurityManagers (there is a check for this
>in the SecurityManager constructor).  If you do indeed use
>SecurityManager.getClassContext(), I assume you had to extend the
>SecurityManager class as well since the method is protected.
>

Yes, I created a subclass. The framework pretty much operates under the 
assumption that its protection domain is "all permission", otherwise 
there would be plently of things that would cause security exceptions.

Once we get security implemented properly in Felix (with [conditional] 
permission admin), then the framework will pretty much assume it 
controls security. This is another area where we may want to investigate 
how we interact with multiple framework instances as well as host 
applications.

-> richard

Re: URL Handlers service

[Jeremy Volkman <jv...@gmail.com>]

Hi Richard,

On 11/4/05, Richard S. Hall <he...@ungoverned.org> wrote:

[snip]

>
> The approach I use to route incoming handler requests is to use the
> security class context, which gives me the call stack of classes. I then
> search backwards to find the first class loaded from a bundle and then
> route to the framework that owns that bundle. As an optimization, if
> there is only one framework instance, then I just assume that every
> request should be routed to it.
>

I assume you're referring to SecurityManager.getClassContext()? I am
also using this method to support my Apache Jakarta Commons Logging
implementation which provides the ability to log events per bundle. 
JCL is provides the LogFactory class with static methods
getLog(String) and getLog(Class).  This made it rather tricky at first
to find out which bundle issued the call to getLog().

The only problem I foresee is if a SecurityManager is installed that
disallows creation of new SecurityManagers (there is a check for this
in the SecurityManager constructor).  If you do indeed use
SecurityManager.getClassContext(), I assume you had to extend the
SecurityManager class as well since the method is protected.


Jeremy