Yep. On 5 February 2011 10:45, Peter Firmstone <j...@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 <j...@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 <j...@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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > >
