[jira] Created: (SANDBOX-240) Caching of URLStreamHandler by the URL class

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (SANDBOX-240) Caching of URLStreamHandler by the URL class

JIRA jira@apache.org
Caching of URLStreamHandler by the URL class
--------------------------------------------

                 Key: SANDBOX-240
                 URL: https://issues.apache.org/jira/browse/SANDBOX-240
             Project: Commons Sandbox
          Issue Type: Bug
          Components: JNet
            Reporter: Niall Pemberton
            Priority: Minor


I've been having a look at JNet to try and get an understanding of what it does - from looking at the source code and Carsten's initial post:

  http://markmail.org/message/tm3wzgxk3fq3o7s3

Seems that the idea is to be able to provide different URLStreamHandler implementations for different applications running in the same JVM. So for example, if I had two webapps the required different handlers for the "file" protocol - then I should be able to do that using JNet?

In some thread somewhere, someone mentioned that felix was already doing something similar - so I took a look at their URLStreamHandlerFactory implementation:

  http://svn.apache.org/repos/asf/felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlers.java

...which serves up "proxy" URLStreamHandler implementations for all protocols because, as it says in the comments, the URL class caches URLStreamHandler implementations for each protocol - and looking at the Harmony implementation of URL, this is the case:

  http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URL.java

So this seems like it would defeat the main point of JNet - since once URL has cached the URLStreamHandler for a protocol, then it won't even go to the registered URLStreamHandlerFactory after that and DynamicURLStreamHandlerFactory won't be asked to serve up whatever factory is set in its "current execution context".

Is this right or have I got the wrong end of the stick?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.