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 10:42:56 GMT
I'm also figuring you might have some wise defaults that people could add to
for constructing a filter/matchset.

Something like:

DefaultEntrys.add(...).add(....)

DefaultEntrys probably includes something like ServiceInfo, Name and such -
all stock options in the platform...

On 5 February 2011 10:28, Peter Firmstone <jini@zeus.net.au> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message