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 10:28:37 GMT
Ok, good reasoning, we can keep the Entry's explicit, in the call.

So we make the Entry's the client's interested in, the only Entry's 
that'll be unmarshalled, those and the ServiceID.

Cheers,

Peter.

Dan Creswell wrote:
> ...
>
> On 5 February 2011 09:48, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> 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.
>>
>>
>>     
> Yeah, which is why I'm tempted to have the client be explicit about which
> Entry's (and that would include subclasses of those Entry's it can
> tolerate). In this way the client can provide high-level explicit guidance
> as to what's right. No need for code to try and be clever and guess the
> client intent which is always ugly.
>
> Many times I suspect the Entry set used for matching will be the same as the
> filter set, probably can provide a nice method signature to help that.
>
> 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?
>>
>>
>>     
> Probably but again this is building clever code to try and compensate. It's
> the same as writing all the null handling if you will albeit hidden inside
> the River libraries.
>
>
>   
>> I guess the likelihood of having null values is reduced, although not
>> eliminated.
>>
>>
>>     
> Quite.
>
>
>   
>> 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.
>>
>>     
>
> Sure but then the client has to explicitly construct filter code, albeit
> clean of null checks to go through the list of Entry's to find what it's
> interested in. Unless we return a HashMap(EntryClass.getName,
> EntryClass.instance) to make that easier. Even so, you're still returning a
> bunch of Entry's only some of which may be interesting to the client....
>
>
>   
>> So the client needs to ensure the Entry's are resolvable from the
>> classpath.
>>
>>
>>     
> Absolutely - and the fact that it must means it can thus construct a proper
> filter list of Entrys of interest.
>
>
>   
>> 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.
>>
>>     
>
> Again, I think we're venturing into attempting to imply intent by examining
> null fields. If the implementer makes a mistake in their analysis they end
> up with unexpected results come lookup. Personally I don't like this sort of
> thing, I like explicit methods to guide an implementer and eliminate
> opportunities for these kinds of confusion.
>
> That last bit is really why I'm down on trying to solve all these problems
> (including the bandwidth ones) with clever management of class-downloading,
> reflection and such. It's implicit, makes assumptions about usage that are
> difficult for users to account for. It also leads to complicated, brittle
> code with many an opportunity for dark-corners/unhandled edge cases that
> cause confusion and are difficult to identify and fix for River implementers
> and users.
>
>
>   
>> Cheers,
>>
>> Peter.
>>
>>     
>
>   


Mime
View raw message