This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 20838 - Find protocol handlers declaratively
Summary: Find protocol handlers declaratively
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
Depends on: 17934 19905 175853 176798
  Show dependency tree
Reported: 2002-02-25 17:15 UTC by Jesse Glick
Modified: 2009-11-18 10:00 UTC (History)
3 users (show)

See Also:
Exception Reporter:

Running patch (28.56 KB, patch)
2009-10-23 22:50 UTC, Jesse Glick
Details | Diff
Revised patch planned for tomorrow (minus apichanges) (53.84 KB, patch)
2009-10-30 00:56 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-02-25 17:15:15 UTC
It would make sense for URL protocol handlers (as handled by
NbfsStreamHandlerFactory) to be found using JNDI. E.g. a request for a
handler for URL "foo:/bar/baz" should look in JNDI under
"URLStreamHandlers/foo" for an instance of URLStreamHandler. register()
and deregister() would then be deprecated. javahelp module would
register URLStreamHandlers/nbdocs.instance in its layer.
Comment 1 Jesse Glick 2002-02-26 11:40:11 UTC
Yarda suggests (dev@openide) looking up the handler each time. TBD
whether this would work in practice (deadlocks, performance). A fix of
#19905 would be more comfortable.
Comment 2 Jesse Glick 2002-05-16 19:23:41 UTC
Waiting for #19905 on this one.
Comment 3 Jesse Glick 2002-10-28 17:05:16 UTC
In separation_19443_b branch, I am permitting
URLStreamHandlerFactory's to be registered to the system in Lookup.
Later, if this issue is still considered important, lookup
registration could be deprecated and JNDI added as a preferred option.
Comment 4 Antonin Nebuzelsky 2008-02-19 13:59:56 UTC
Reassigning to new module owner Tomas Holy.
Comment 5 Jesse Glick 2008-02-19 18:38:31 UTC
Seems handlers are already found in Lookup:

Comment 6 Jesse Glick 2009-10-23 22:49:15 UTC
Working on it.
Comment 7 Jesse Glick 2009-10-23 22:50:29 UTC
Created attachment 90029 [details]
Running patch
Comment 8 Jesse Glick 2009-10-23 22:51:48 UTC
Please review this API change.
Comment 9 Jaroslav Tulach 2009-10-25 14:07:43 UTC
Very useful, thanks for playing with it.

Y01 TCR: Provide own processor, independent of ServiceProvider one. Mixing them clashes with issue 170056
Y02 Are you sure ProxyURLStreamHandlerFactory (as inner class of interface) is not public by default? It should not be 
visible in the API (at most some factory method).

Comment 10 Jesse Glick 2009-10-26 15:33:24 UTC
Y01 - cannot be fully independent since it uses infrastructure from ServiceProviderProcessor. Can try to factor out a
helper class (akin to LayerGeneratingProcessor but for ServiceLoader format). If Lookup were split off, this helper
class would need to become public.

Y02 - it is public, intentionally - used from o.n.bootstrap, and available for use from unit tests as its Javadoc
indicated. (I forgot to make it final, which I will fix.) A factory method is not possible without introducing some
artificial holder class which seemed uglier, since Java arbitrarily forbids static methods in interfaces. I initially
tried a constant, but this triggers an open bug in javac with no apparent workaround.
Comment 11 Jesse Glick 2009-10-26 16:47:10 UTC
Y01 addressed in branch. For Y02, at least made factory class final.
Comment 12 Jaroslav Tulach 2009-10-28 18:46:53 UTC
Y03 I am surprised that the registration does not use LayerGeneratingProcessor and does not generate the info into 
layers. That would move the annotation to openide.filesystems, but openide.filesystems is where URLMapper & other URL 
manipulation methods are found anyway. There would be suitable place to put the proxy URLSHF factory method to: 
FileUtil. I do not see why this annotation shall be that important to deserve place in openide.util now.
Comment 13 Jesse Glick 2009-10-28 19:14:17 UTC
Y03 - I did not want to register handlers using layers, as that could set up a bad dependency cycle when looking up
basic protocols such as nbfs or nbres. Registering in META-INF/namedservices carries less risk (it is still necessary to
manually break a cycle in RecognizeInstanceFiles). The URLSHF also cannot be in openide.filesystems since it is used
from o.n.bootstrap.
Comment 14 Jaroslav Tulach 2009-10-28 19:22:21 UTC
Re. Y03 - OK.

Y04 Move the ProxyUSHF to non-public package of openide.util (next to NamedServicesProvider!?). o.n.bootstrap would be 
OK with that (at least in current setup) and tests would be OK as well, as they ignore the public package 
Comment 15 Jesse Glick 2009-10-28 20:37:13 UTC
Y04 is impossible without adding an implementation dependency (or, worse, reflection). I think we should be removing
impl deps, not introducing new ones. Anyway I don't really see what is harmful about ProxyUSHF...? (I initially
considered putting it in o.n.bootstrap, but it is much cleaner when the annotation, registering processor, runtime
client, and test can all live in the same module. openide.modules could house everything if not for the usage from
Comment 16 Jesse Glick 2009-10-30 00:56:27 UTC
Created attachment 90253 [details]
Revised patch planned for tomorrow (minus apichanges)
Comment 17 Jaroslav Tulach 2009-10-30 14:16:22 UTC
Re. Y04: There is no need for reflection between o.n.bootstrap and openide.util - they both are loaded by the same 
classloader. I just find the name and location of the default implementation confusing and unnecessary. If it was more 
hidden, users of the API could only benefit. But this is just an opinion and not a blocker.
Comment 18 Jesse Glick 2009-10-30 15:31:12 UTC
Y04 - Perhaps reflection is unnecessary at runtime under the current class loading scheme, but it is necessary during
the build, when public package restrictions are enforced by the harness. Would rather not complicate the build by
working around this.

Can rename the factory to URLStreamHandlerRegistration.ProxyFactory if that looks nicer.

Another option may be to put the proxy factory into default lookup. If I remember correctly this was my first thought
that I decided against, but I can double check whether it works.
Comment 19 Jesse Glick 2009-10-30 17:51:44 UTC
Y02/Y04 addressed in branch by hiding proxy factory (available in lookup).
Comment 20 Jesse Glick 2009-10-30 18:47:32 UTC
core-main #a9a5a7d321fe
Comment 21 Quality Engineering 2009-11-01 10:54:29 UTC
Integrated into 'main-golden', will be available in build *200910310201* on (upload may still be in progress)
User: Jesse Glick <>
Log: Issue #20838: declarative registration of URLStreamHandler instances by protocol.