river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: MarshalledServiceItem
Date Sat, 05 Feb 2011 09:24:39 GMT
"ServiceClasspathSubItem is intended for client side filtering of lookup
* service results prior to clients using a service, the lookup service
* that implements this class, implements #getServiceItem(), so clients
* can obtain a complete ServiceItem when required after filtering."

I'm still wondering if it wouldn't be better for a client to send a list of
Entry's it's interested in seeing, separate from the set for matching to the
Registrar. The Registrar can then return ServiceItems for the matches and
pre-filter the Entry's per item. Especially given:

"Some fields in ServiceClasspathSubItem may be null, fields in Entry's may
* be null or even the service reference may be null, these fields would be
* non-null in a ServiceItem that resolves classes from dynamicly downloaded
* code or a remote codebase."

I think, if we do the filtering as I suggest, much of the comment re: nulls
above still applies in implementation but ultimately, the client will pick
Entry's for which it has the classpath such that it always deals in complete
Entry's and can have a level of predictability in respect of what is or is
not null. This might save clients having to do endless null checks etc that
can be a rich source of bugs and ugly code.

We might need the filter list to include specific subclasses as well....

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message