Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
jtsk_1.2
-
None
-
None
-
4625466
Description
Bugtraq ID 4625466
The lookup service type matching semantics are either unclear or difficult to implement correctly.
On the one hand, the lookup service tends to ignore codebases when doing matching on the server side, but this conflicts with the concrete and specific type matching that the client will ultimately perform. Consider the case where a client does a lookup by type T, where T} is a class downloaded into the client, with codebase {{CB1, such that it is in a child of the context classloader. The lookup service may return multiple items that are logically of type T, but each may have distinct codebases, different than CB1. The classes for these items will end up in new child classloaders (siblings of the classloader that the client's original T is in), such that the actual types of the items, as viewed by the client, are not assignable to the T it used in the query. The same problems arise with attribute classes. Semantically this just seems wrong, and it is rather difficult to paper over it. If the singleton-form lookup returned null instead, that would be bad; there might well be some other item registered that would match the query. If the multiple-form lookup deleted items that didn't match, it would still be returning fewer items than might be possible, and it wouldn't really know how to compute an accurate totalMatches.
The spec does not discuss these issues, so it isn't clear if clients should be aware of these anomalies or if some other set of assumptions is required to allow a correct implementation of the specification.The lookup service type matching semantics are either unclear or difficult to implement correctly.
Attachments
Issue Links
- is related to
-
RIVER-328 OSGi Bundles for Versioning Control and Codebase Evolution
-
- Resolved
-