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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
