You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sahoo <Sa...@Sun.COM> on 2008/09/08 17:01:19 UTC
Locating URLStreamHandler without url handler service in Felix
Recently I observed some some interesting behaviors while trying to use
JRE defined property called "java.protocol.handler.pkgs" to locate
URLStreamHandler. Yes, I know I should be using OSGi URL handler
service, but that's a separate discussion. Here are my observations:
1. I don't see any Handler for *bundle* scheme. So, if I disable
urlhandler service (felix.service.urlhandlers=false in
config.properties), then any URL with *bundle* scheme can't be used.
Should there not be handlers for all Felix defined schemes?
2. framework/URLHandlers.java, which is responsible for processing
"java.protocol.handler.pkgs", prefixes default pkg names by user
supplied value. So, if I specify p.q as the value of that system
property, then the pkg list becomes: p.q|sun.net.www.protocol|..." This
was causing a LinkageError for me while trying to locate a handler for
jar scheme. When I set the property as sun.net.www.protocol|p.q, things
started working. I have to investigate a bit more on the LinkageError
with a smaller test case.
3. URLhandlers.java calls m_secureAction.forName(className) to see if a
handler is found in a package or not. This eventually calls
Class.forName() which uses caller's classloader to load className. Since
caller is always a Felix class, SecureAction to be precise, it is only
able to locate handlers that are visible to classloader that loaded
Felix. Should Felix be using Thread's context class loader to find the
class?
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Locating URLStreamHandler without url handler service in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sahoo wrote:
> Richard S. Hall wrote:
>>
>>
>> Sahoo wrote:
>>> Karl Pauls wrote:
>>>>> Recently I observed some some interesting behaviors while trying
>>>>> to use JRE
>>>>> defined property called "java.protocol.handler.pkgs" to locate
>>>>> URLStreamHandler. Yes, I know I should be using OSGi URL handler
>>>>> service,
>>>>> but that's a separate discussion. Here are my observations:
>>>>>
>>>>> 1. I don't see any Handler for *bundle* scheme. So, if I disable
>>>>> urlhandler
>>>>> service (felix.service.urlhandlers=false in config.properties),
>>>>> then any URL
>>>>> with *bundle* scheme can't be used. Should there not be handlers
>>>>> for all
>>>>> Felix defined schemes?
>>>>>
>>>>
>>>> I don't think that the bundle protocol handler would be generally
>>>> useful. It's only meaningful in the context of a framework and as such
>>>> implementation specific as well...
>>>>
>>> Does Felix not return URL with bundle scheme for any resource found
>>> in a bundle? If yes, how JVM use that URL when urlhandler service is
>>> switched off?
>>
>> Felix uses the URL constructor that accepts a stream handler and we
>> pass in our custom handler there. Of course, this means that you
>> cannot convert the URL to a string and then back to a URL, but there
>> isn't much we can do about that.
>>
> Could Felix not have a Handler like org.apache.felix.bundle.Handler so
> that one could add it to the pkg list that JVM searches for custom url
> handlers?
Not really, because the handler would have no way of knowing which
framework instance it was associated with.
-> richard
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Locating URLStreamHandler without url handler service in Felix
Posted by Sahoo <sa...@sun.com>.
Richard S. Hall wrote:
>
>
> Sahoo wrote:
>> Karl Pauls wrote:
>>>> Recently I observed some some interesting behaviors while trying to
>>>> use JRE
>>>> defined property called "java.protocol.handler.pkgs" to locate
>>>> URLStreamHandler. Yes, I know I should be using OSGi URL handler
>>>> service,
>>>> but that's a separate discussion. Here are my observations:
>>>>
>>>> 1. I don't see any Handler for *bundle* scheme. So, if I disable
>>>> urlhandler
>>>> service (felix.service.urlhandlers=false in config.properties),
>>>> then any URL
>>>> with *bundle* scheme can't be used. Should there not be handlers
>>>> for all
>>>> Felix defined schemes?
>>>>
>>>
>>> I don't think that the bundle protocol handler would be generally
>>> useful. It's only meaningful in the context of a framework and as such
>>> implementation specific as well...
>>>
>> Does Felix not return URL with bundle scheme for any resource found
>> in a bundle? If yes, how JVM use that URL when urlhandler service is
>> switched off?
>
> Felix uses the URL constructor that accepts a stream handler and we
> pass in our custom handler there. Of course, this means that you
> cannot convert the URL to a string and then back to a URL, but there
> isn't much we can do about that.
>
Could Felix not have a Handler like org.apache.felix.bundle.Handler so
that one could add it to the pkg list that JVM searches for custom url
handlers?
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Locating URLStreamHandler without url handler service in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sahoo wrote:
> Karl Pauls wrote:
>>> Recently I observed some some interesting behaviors while trying to
>>> use JRE
>>> defined property called "java.protocol.handler.pkgs" to locate
>>> URLStreamHandler. Yes, I know I should be using OSGi URL handler
>>> service,
>>> but that's a separate discussion. Here are my observations:
>>>
>>> 1. I don't see any Handler for *bundle* scheme. So, if I disable
>>> urlhandler
>>> service (felix.service.urlhandlers=false in config.properties), then
>>> any URL
>>> with *bundle* scheme can't be used. Should there not be handlers for
>>> all
>>> Felix defined schemes?
>>>
>>
>> I don't think that the bundle protocol handler would be generally
>> useful. It's only meaningful in the context of a framework and as such
>> implementation specific as well...
>>
> Does Felix not return URL with bundle scheme for any resource found in
> a bundle? If yes, how JVM use that URL when urlhandler service is
> switched off?
Felix uses the URL constructor that accepts a stream handler and we pass
in our custom handler there. Of course, this means that you cannot
convert the URL to a string and then back to a URL, but there isn't much
we can do about that.
-> richard
>>> 2. framework/URLHandlers.java, which is responsible for processing
>>> "java.protocol.handler.pkgs", prefixes default pkg names by user
>>> supplied
>>> value. So, if I specify p.q as the value of that system property,
>>> then the
>>> pkg list becomes: p.q|sun.net.www.protocol|..." This was causing a
>>> LinkageError for me while trying to locate a handler for jar scheme.
>>> When I
>>> set the property as sun.net.www.protocol|p.q, things started
>>> working. I have
>>> to investigate a bit more on the LinkageError with a smaller test case.
>>>
>>
>> Sounds strange. Please try to get this test case done so that we can
>> see whats going on.
>>
>>
> I will try.
>>> 3. URLhandlers.java calls m_secureAction.forName(className) to see
>>> if a
>>> handler is found in a package or not. This eventually calls
>>> Class.forName()
>>> which uses caller's classloader to load className. Since caller is
>>> always a
>>> Felix class, SecureAction to be precise, it is only able to locate
>>> handlers
>>> that are visible to classloader that loaded Felix. Should Felix be
>>> using
>>> Thread's context class loader to find the class?
>>>
>>
>> Well, the current approach wasn't intended to be an extension
>> mechanism. All it should do is to allow for other jvm implementations.
>> I think it is problematic to try to use it for other purposes. One
>> issue is that handlers are cached by the jvm iirc. It would be sort of
>> strange to use the context class loader in this case because one would
>> need to control all threads that trigger handler loading.
>>
> OK.
>> It almost sounds to me like you are trying to build your own
>> URLHandlers outside of the framework. Could you maybe let us know a
>> bit more about what it is you need? Maybe there is a different
>> solution to your problem...
>>
> No, I was just trying to use different url handlers without url
> handler service ad observed these behaviors. In practice, I am
> actually using url handler service.
>
> Thanks,
> Sahoo
>> regards,
>>
>> Karl
>>
>>
>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Locating URLStreamHandler without url handler service in Felix
Posted by Sahoo <Sa...@Sun.COM>.
Karl Pauls wrote:
>> Recently I observed some some interesting behaviors while trying to use JRE
>> defined property called "java.protocol.handler.pkgs" to locate
>> URLStreamHandler. Yes, I know I should be using OSGi URL handler service,
>> but that's a separate discussion. Here are my observations:
>>
>> 1. I don't see any Handler for *bundle* scheme. So, if I disable urlhandler
>> service (felix.service.urlhandlers=false in config.properties), then any URL
>> with *bundle* scheme can't be used. Should there not be handlers for all
>> Felix defined schemes?
>>
>
> I don't think that the bundle protocol handler would be generally
> useful. It's only meaningful in the context of a framework and as such
> implementation specific as well...
>
Does Felix not return URL with bundle scheme for any resource found in a
bundle? If yes, how JVM use that URL when urlhandler service is switched
off?
>
>> 2. framework/URLHandlers.java, which is responsible for processing
>> "java.protocol.handler.pkgs", prefixes default pkg names by user supplied
>> value. So, if I specify p.q as the value of that system property, then the
>> pkg list becomes: p.q|sun.net.www.protocol|..." This was causing a
>> LinkageError for me while trying to locate a handler for jar scheme. When I
>> set the property as sun.net.www.protocol|p.q, things started working. I have
>> to investigate a bit more on the LinkageError with a smaller test case.
>>
>
> Sounds strange. Please try to get this test case done so that we can
> see whats going on.
>
>
I will try.
>> 3. URLhandlers.java calls m_secureAction.forName(className) to see if a
>> handler is found in a package or not. This eventually calls Class.forName()
>> which uses caller's classloader to load className. Since caller is always a
>> Felix class, SecureAction to be precise, it is only able to locate handlers
>> that are visible to classloader that loaded Felix. Should Felix be using
>> Thread's context class loader to find the class?
>>
>
> Well, the current approach wasn't intended to be an extension
> mechanism. All it should do is to allow for other jvm implementations.
> I think it is problematic to try to use it for other purposes. One
> issue is that handlers are cached by the jvm iirc. It would be sort of
> strange to use the context class loader in this case because one would
> need to control all threads that trigger handler loading.
>
OK.
> It almost sounds to me like you are trying to build your own
> URLHandlers outside of the framework. Could you maybe let us know a
> bit more about what it is you need? Maybe there is a different
> solution to your problem...
>
No, I was just trying to use different url handlers without url handler
service ad observed these behaviors. In practice, I am actually using
url handler service.
Thanks,
Sahoo
> regards,
>
> Karl
>
>
>
>> Thanks,
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Locating URLStreamHandler without url handler service in Felix
Posted by Karl Pauls <ka...@gmail.com>.
> Recently I observed some some interesting behaviors while trying to use JRE
> defined property called "java.protocol.handler.pkgs" to locate
> URLStreamHandler. Yes, I know I should be using OSGi URL handler service,
> but that's a separate discussion. Here are my observations:
>
> 1. I don't see any Handler for *bundle* scheme. So, if I disable urlhandler
> service (felix.service.urlhandlers=false in config.properties), then any URL
> with *bundle* scheme can't be used. Should there not be handlers for all
> Felix defined schemes?
I don't think that the bundle protocol handler would be generally
useful. It's only meaningful in the context of a framework and as such
implementation specific as well...
> 2. framework/URLHandlers.java, which is responsible for processing
> "java.protocol.handler.pkgs", prefixes default pkg names by user supplied
> value. So, if I specify p.q as the value of that system property, then the
> pkg list becomes: p.q|sun.net.www.protocol|..." This was causing a
> LinkageError for me while trying to locate a handler for jar scheme. When I
> set the property as sun.net.www.protocol|p.q, things started working. I have
> to investigate a bit more on the LinkageError with a smaller test case.
Sounds strange. Please try to get this test case done so that we can
see whats going on.
> 3. URLhandlers.java calls m_secureAction.forName(className) to see if a
> handler is found in a package or not. This eventually calls Class.forName()
> which uses caller's classloader to load className. Since caller is always a
> Felix class, SecureAction to be precise, it is only able to locate handlers
> that are visible to classloader that loaded Felix. Should Felix be using
> Thread's context class loader to find the class?
Well, the current approach wasn't intended to be an extension
mechanism. All it should do is to allow for other jvm implementations.
I think it is problematic to try to use it for other purposes. One
issue is that handlers are cached by the jvm iirc. It would be sort of
strange to use the context class loader in this case because one would
need to control all threads that trigger handler loading.
It almost sounds to me like you are trying to build your own
URLHandlers outside of the framework. Could you maybe let us know a
bit more about what it is you need? Maybe there is a different
solution to your problem...
regards,
Karl
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org