river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: MarshalledServiceItem
Date Fri, 04 Feb 2011 00:18:43 GMT
It is a container object, it extends ServiceItem, it's essentially has 
identical state (or a subset of it), but unlike a ServiceItem, no 
attempt has been made to use or download remote codebases, only the 
classpath is used to resolve and unmarshall any objects contained in the 
ServiceItem.  Object references are set to null if their classes cannot 
be resolved locally, including the proxy, any Entry's or Entry fields.

A single method is provided to resolve the ServiceItem using remote 
codebases in addition to the classpath, this method returns a new 
ServiceItem.

The intent of the class is to provide access to Entry's for complex 
queries, (<>|&) performed locally, without downloading any codebases.  
Once the client has found a suitable service it can be retrieved after a 
codebase download and unmarshalling.

The implementer may also decide to avoid downloading the marshalled 
state of the service proxy, in addition to its codebase.

Other ideas:

PseudoServiceItem

PartialServiceItem

ServiceItemLocalSubset

Cheers,

Peter.

MICHAEL MCGRADY wrote:
> Could you state in a sentence what the class does?  Then we can all suggest possible
names?
>
> MG
>
>
> On Feb 3, 2011, at 1:40 PM, Peter Firmstone wrote:
>
>   
>> Or one of these?
>>
>> ClasspathFencedServiceItem
>>
>> ClaspathBoundServiceItem
>>
>> ClasspathConstrainedServiceItem
>>
>> Dan Creswell wrote:
>>     
>>> Thing is the ServiceItem is not the thing being resolved....
>>>
>>> On 3 February 2011 09:59, Peter Firmstone <jini@zeus.net.au> wrote:
>>>
>>>  
>>>       
>>>> How about LocallyResolvedServiceItem?
>>>>
>>>>
>>>> Dan Creswell wrote:
>>>>
>>>>    
>>>>         
>>>>> Sure, the method does indeed unmarshall but within specific constraints
>>>>> and
>>>>> those constraints are defined by the enclosing class (an instance of
>>>>> ServiceItem in this case).
>>>>>
>>>>> So I'm thinking we're really talking about is a ServiceItem that pulls
>>>>> from
>>>>> classpath so maybe LocallyResolvingServiceItem (not entirely keen on
that
>>>>> but explains what's happening).
>>>>>
>>>>> On some level there's a bit of me that screams we have a broken design
if
>>>>> we
>>>>> can't get decent names.....
>>>>>
>>>>> On 3 February 2011 09:10, Peter Firmstone <jini@zeus.net.au> wrote:
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>>>> Dan Creswell wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>        
>>>>>>             
>>>>>>> "In summary MarshalledServiceItem is a class that only resolves
local
>>>>>>> code.
>>>>>>> Interestingly MarshalledServiceItem, might not be an appropriate
name,
>>>>>>> perhaps LocalServiceItem to indicate that only local code is
utilised,
>>>>>>> on
>>>>>>> this reasoning, I can't see any objection to reflective proxy's
being
>>>>>>> non
>>>>>>> null either."
>>>>>>>
>>>>>>> Indeed, the name MarshalledServiceItem is completely "out-of-whack"
with
>>>>>>> what's going on.....
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>          
>>>>>>>               
>>>>>> The method unmarshall, sort of makes sense, can you think of a better
>>>>>> name?
>>>>>>
>>>>>>
>>>>>>
>>>>>>        
>>>>>>             
>>>>>      
>>>>>           
>>>>    
>>>>         
>>>  
>>>       
>
> Michael McGrady
> Chief Architect
> Topia Technology, Inc.
> Cel 1.253.720.3365
> Work 1.253.572.9712 extension 2037
> mmcgrady@topiatechnology.com
>
>
>
>
>   


Mime
View raw message