S'cool. On 6 February 2011 19:45, Peter Firmstone <j...@zeus.net.au> wrote:
> I was thinking about post filtering on an Entry's contents after the lookup > method returns. > > Well, there might be a use case there as well, not sure but than haven't thought about it.... > Sorry, what you meant was the builder generates a default array or Set of > Entry classes required to support the platform, additional Entry classes the > client needs can be added, then it builds the array to pass as a parameter > to the lookup service. > > Yep. > Do you think we need to pass all classes related to the Entry's (fields) or > just the Entry classes? I'm thinking it'd be simpler if it's just the Entry > classes. > > I'm thinking classes, anything more than that is more specific selection that a client wants to do and hasn't accounted for in the original lookup (which would seem to be a "broken" client?) > > Cheers, > > Peter. > > Dan Creswell wrote: > >> I was assuming a filter was inclusive by default. i.e. You specify just >> the >> things you're interested in a client seeing. >> >> There seems less value in removal given a client specifies its interests >> somewhat in relation to what is on its classpath.... >> >> On 6 February 2011 11:45, Peter Firmstone <j...@zeus.net.au> wrote: >> >> >> >>> A filter could also collect, rather than just remove. >>> >>> Do you think query/filter builders should be specific to a particular >>> Entry >>> type? >>> >>> >>> Cheers, >>> >>> Peter. >>> >>> Dan Creswell wrote: >>> >>> >>> >>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > >
