I like your idea of having gbean-like complex attributes. I don't have
time right now to think about it and I don't know offhand how we could
make it work.
thanks
david jencks
On May 25, 2005, at 6:50 AM, Hiram Chirino wrote:
That still does not make sense since you are talking about attributes.
So now we are saying attributes have to be serializable except the
magic ones which are not serializable. Kinda does not make too sense.
It also does not really explain why complex gbeans get the nifty
runtime construction support but complex attributes do not.
Regards,
Hiram
On May 25, 2005, at 9:23 AM, Srinath Perera wrote:
Hi Hiram;
I will try to give a possible reason ..
Not all the attributes in the GBeans are serializable, e.g.
ClassLoader, kernel attributes
in a GBean are not serializable, and have a special meaning in the
enviorment it runs.
those so called magic attributes get the values from the enviorment ..
so serializing them do not make sense. I belive this is a reason
making attributes Serializable (only the persitant ones), but not the
GBeans,
Thanks
Srinath
On 5/21/05, Hiram Chirino <[EMAIL PROTECTED]> wrote:
I've been trying to analyze the reason why gbean attributes HAVE to
be
serializable.
The facts are that:
1. A gbean itself does not need to be serializable.
2. Only the gbean attributes are serialized.
3. The de-serialized attributes are injected at runtime to
construct
the gbean.
My question is why does a gbean get different treatment than
attribute?
I've got a feeling it's this way because gbeans are complex objects
while most gbean attributes are simple types. But we are starting to
see gbean objects that have complex attribute types.
Why not also give gbean attributes the kind of runtime construction
support that is given to gbeans? If this was done, then you don't
force complex attributes to implement the Serializable interfaces.
This could go a long way in helping solve some of the serialization
issues that are being discussed in other threads.
Regards,
Hiram Chirino
