Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 63820 invoked from network); 6 Feb 2011 19:52:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Feb 2011 19:52:12 -0000 Received: (qmail 10009 invoked by uid 500); 6 Feb 2011 19:52:12 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 9943 invoked by uid 500); 6 Feb 2011 19:52:11 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 9934 invoked by uid 99); 6 Feb 2011 19:52:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 19:52:11 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [61.9.168.146] (HELO nskntmtas04p.mx.bigpond.com) (61.9.168.146) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 19:52:02 +0000 Received: from nskntotgx03p.mx.bigpond.com ([61.9.223.241]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20110206195136.QJZD785.nskntmtas04p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Sun, 6 Feb 2011 19:51:36 +0000 Received: from [10.1.1.2] (really [61.9.223.241]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20110206195135.JIQS13584.nskntotgx03p.mx.bigpond.com@[10.1.1.2]> for ; Sun, 6 Feb 2011 19:51:35 +0000 Message-ID: <4D4EFA4B.6020805@zeus.net.au> Date: Mon, 07 Feb 2011 05:45:15 +1000 From: Peter Firmstone User-Agent: Thunderbird 2.0.0.14 (X11/20080531) MIME-Version: 1.0 To: river-dev@incubator.apache.org Subject: Re: MarshalledServiceItem References: <4D45C8A5.6010309@zeus.net.au> <4D49F3A5.9070104@zeus.net.au> <4D49F7B9.7060201@wonderly.org> <4D4A41CD.5060500@zeus.net.au> <4D4A70FF.2060904@zeus.net.au> <4D4A7C96.8060305@zeus.net.au> <4D4B20E7.3060900@zeus.net.au> <53CE3906-CFC2-4DBF-9322-55AA0C9C0A0E@topiatechnology.com> <4D4B45E3.9070000@zeus.net.au> <4D4BD4CC.2020902@zeus.net.au> <4D4D1CD4.90405@zeus.net.au> <4D4D2655.7030202@zeus.net.au> <4D4D2A52.1000804@zeus.net.au> <4D4E89DC.5010209@zeus.net.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4D4EFBC8.00C0,ss=1,fgs=0 X-Virus-Checked: Checked by ClamAV on apache.org I was thinking about post filtering on an Entry's contents after the lookup method returns. 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. 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. 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 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 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 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 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >