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 <[EMAIL PROTECTED]>
To: [email protected]
Cc: [EMAIL PROTECTED]
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>
