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.
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.
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.
Waiting for #19905 on this one.
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.
Reassigning to new module owner Tomas Holy.
Seems handlers are already found in Lookup: core.startup/src/org/netbeans/core/startup/NbURLStreamHandlerFactory.java
Working on it.
Created attachment 90029 [details] Running patch
Please review this API change.
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).
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.
Y01 addressed in branch. For Y02, at least made factory class final.
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.
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.
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 restrictions.
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 openide.filesystems.)
Created attachment 90253 [details] Revised patch planned for tomorrow (minus apichanges)
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.
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.
Y02/Y04 addressed in branch by hiding proxy factory (available in lookup).
core-main #a9a5a7d321fe
Integrated into 'main-golden', will be available in build *200910310201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a9a5a7d321fe User: Jesse Glick <jglick@netbeans.org> Log: Issue #20838: declarative registration of URLStreamHandler instances by protocol.