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 20:31:37 GMT
Yep.

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

> Sounds interesting, looks like a builder?
>
>
> Dan Creswell wrote:
>
>> 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