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 <[email protected]> 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 <[email protected]> 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. >>> >>> >>> >> >> >> > >
