river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Rollo <danro...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 20:59:13 GMT
OK, so it sounds like you are NOT proposing live objects in the space, 
right?

Are you suggesting the space should be able to find matching entries 
using non-public (protected, package, and private) field values? If so, 
I'm having trouble imagining how the template objects passing into 
space.read()/take() would look.
Maybe it would help clarify if you could post some example "API" changes 
for space.write(), read(), take(), etc.


Dan

Wade Chandler wrote:
> What I'm talking about is if the entries themselves are not live objects, then their
fields are not accessed as fields of Java objects, but just as data. So, whether the client
sends data to be held in an entry on the spaces server from a bean or class with fields really
doesn't make a difference as data moved from point a to point b is still just the data, and
all the spaces server is housing is state and has the ability to look that up. Thus, it doesn't
matter if the client side data comes from any type in any relaxed form or an Entry extension
as exists now as long as it can be used to correctly reconstitute the information in what
ever form on another client or the same client when reread. On the server, setter or getter
won't matter, nor will fields in a class on the client side as the server just works against
stored state regardless of the contained format whether that be some binary form, XML, or
otherwise.
> 
> Wade
> 
>  ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream
Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
> 
> 
> 
> ----- Original Message ----
>> From: Dan Rollo <danrollo@gmail.com>
>> To: river-dev@incubator.apache.org
>> Cc: hwadechandler-apache@yahoo.com
>> Sent: Wednesday, September 3, 2008 11:49:59 AM
>> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
>>
>> Hi Wade,
>>
>> (Warning: Non-expert response follows. ;)
>>
>> I think they key problem with setter/getter matching is it would REQUIRE 
>> the javaspace to make the entry "live" in order to execute the getter 
>> used during matching. (I think this is why Gregg focused on the "live 
>> objects in a space" topic.)
>>
>> Even with metadata, you must have a live object in order to execute a 
>> method (ie: getter) on that object.
>>
>> If you are proposing that additional metadata allow matching on 
>> non-public fields WITHOUT actually executing the getter, things get 
>> muddy fast. For example: if you change your Person example code to:
>>
>>> public class Person {
>>>  private String firstName;
>>>  private String lastName;
>>>  public String getFirstName(){
>>       if (true) { throw new RuntimeException("some validate failure); }
>>>    return firstName;
>>>  }
>>>  //..getter here
>>> //lastname setter
>>> //lastname getter
>>> }
>> Assuming a "metadata matcher" existed, I see only two options:
>> 1. If the space just matches on the serialized/marshalled "value" of the 
>> firstName field, the "validate" logic of the getter never runs. To me, 
>> this feels like black magic that would confuse users.
>> 2. If the space must call "entry".getFirstName(), you are back to 
>> requiring the space to deserilize (make "live") the entry object to do 
>> the matching. This lands you back at: http://griddle.dev.java.net
>>
>> Am I missing some concept that would allow a non-live/marshalled object 
>> to be matchable?
>>
>> Dan Rollo
>>
<snip>

Mime
View raw message