river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-48) Lookup service type matching semantics are unclear or difficult to implement
Date Thu, 26 Jul 2007 13:12:40 GMT
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.


Mime
View raw message