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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > >
