paulrutter commented on PR #552: URL: https://github.com/apache/felix-dev/pull/552#issuecomment-5500454148
Correction to my previous comment: I said I suspected Equinox simply does not hit this case. Having read `BundleResourceHandler` properly, that was the wrong way round — Equinox does not have the problem because it does not attempt the resolution at all, and Felix currently guarantees something stronger. `openConnection` there does: ```java String host = url.getHost(); // "<bundleId>.<container.hashCode()>" bundleID = parseBundleIDFromURLHost(host); // parses ONLY the bundle id Module module = getModule(bundleID); // -> container.getModule(id), the BOUND container ``` The framework identity is encoded in the host by `createURLHostForBundleID(container, bundleId)`, but `openConnection` parses only the bundle id and resolves it against whichever container the handler instance was constructed with. The container part of the host is used for `equals`/`hashCode`/`hostsEqual`/`sameFile` comparisons, never to locate the owning container. So for the case Felix's `urlHandlersWithClassLoaderIsolation` covers — a `bundle:` URL re-parsed by a caller that is not in any bundle, with two frameworks live — Equinox would either return the resource with that bundle id **from the wrong container**, or fail with `URL_NO_BUNDLE_FOUND`. It depends entirely on plurl's `shouldHandle` having routed to the right factory, with no fallback when attribution is impossible. Felix's `URLHandlers.getFrameworkFromContext(uuid)` instead resolves the owning framework from the UUID in the URL, and previously did so across class loaders via the `registerFrameworkListsForContextSearch` bridge. That is a stronger guarantee, and it is why Felix has a test for it and there is no equivalent upstream. That changes what I am actually asking. Not "how does Equinox do this" — it doesn't — but: **Would plurl consider an API for routing a `URL` to its owning factory, rather than only routing a calling `Class`?** Something like a `PlurlStreamHandlerFactory` callback along the lines of `boolean shouldHandle(URL)`, consulted when call stack attribution yields nothing, would let each framework claim its own URLs by inspecting the host. Both frameworks would then behave correctly for URLs re-parsed outside a bundle, and Equinox could tighten its behaviour too if it wanted to. Without that, the options on the Felix side are: 1. Match Equinox: bind the handler to one framework and accept that cross-framework re-parsing resolves against the wrong one. Converges with upstream, but is a regression for Felix and means weakening or removing that test. 2. Keep the current guarantee with a Felix-side cross-copy UUID registry. That reintroduces reflection into exactly the mechanism plurl is meant to replace, since each class loader has its own copy of both `URLHandlers` and the plurl classes, and there is no shared rendezvous to publish to. I would rather not do 1 silently, since it drops behaviour Felix has today. Happy to raise (1) as a plurl issue with a concrete API proposal if you think it is reasonable. For the record the branch is otherwise in good shape: on Linux the framework suite is 121 tests with this as the only error, and `apache-rat` is satisfied now the headers are Apache-2.0. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
