Lookup service type matching semantics are unclear or difficult to implement
----------------------------------------------------------------------------
Key: RIVER-48
URL: https://issues.apache.org/jira/browse/RIVER-48
Project: River
Issue Type: Bug
Components: net_jini_core
Affects Versions: jtsk_1.2
Reporter: Mark Brouwer
Priority: Minor
Bugtraq ID [4625466|http://bugs.sun.com/bugdatabase/view_bug.do?bug_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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
