river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: MarshalledServiceItem
Date Sat, 05 Feb 2011 09:48:04 GMT
Dan Creswell wrote:
> "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....
>
>   
Hmm, null is a problem, we could still have fields missing subclass 
classes, which might prevent a subclass from unmarshalling.

Is there a way we can catch a class not found exception or similar and 
still get the state of the superclass, or would this violate 
polymorphism, method overrides etc?

I guess the likelihood of having null values is reduced, although not 
eliminated.

If we compact the final array of Entry's so null entry's are removed, 
the client only needs to find the Entry's it's interested in, likely 
ignoring the others anyway.

So the client needs to ensure the Entry's are resolvable from the classpath.

I have thought about the case where a proxy uses the lookup service and 
has Entry's in it's proxy classloader, but this could be subject to 
security issues, where two services with different Subject's end up 
sharing state.

We might also consider only including Entry's that don't have null field 
values, this puts the impetus on the implementer to consider the Entry 
field classes.

Cheers,

Peter.

Mime
View raw message