Why are gbeans not serialized but the gbean attributes are?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why are gbeans not serialized but the gbean attributes are?

Hiram Chirino
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

Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

Srinath Perera
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 <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

Hiram Chirino
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 <[hidden email]> 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

ammulder
In reply to this post by Srinath Perera
Srinath,
        There are several easy solutions to attributes you don't want to
Serialize -- such as transient, read/writeObject, or Externalizable.  So I
don't think the reason is simply that it would be hard to deal with the
magic attributes.

        Of course, I'm not sure what advantage there would be to requiring
that all GBeans be Serializable, either, since generally speaking they
won't work if transferred somewhere over the network without speal
reconstruction support on the other side...

        The more interesting question is Hiram's point on providing more
advanced support for attribute contruction.  This seems to be one of the
advantages Dain's Spring-based kernel provides.

Aaron

On Wed, 25 May 2005, 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 <[hidden email]> 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
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

David Jencks-2
In reply to this post by Hiram Chirino
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 <[hidden email]> 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
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

Srinath Perera
In reply to this post by ammulder
Thanks Aaron for the clarification ..I agree that magic attributes is
not *the* reason. But, if a GBean has a magic attribute and
serialized, it is not usable by just serializing
as the injection of the magic attributes again ect is needed. The
things may get bit complicated

I feel the GBean reconstruction from the disk, is a work to the
framework,  we can not just replace it with serialization. I prefer
the way it is there now.

But of course it is just my gut feeling :)
Thanks
Srinath

On 5/25/05, Aaron Mulder <[hidden email]> wrote:

> Srinath,
>         There are several easy solutions to attributes you don't want to
> Serialize -- such as transient, read/writeObject, or Externalizable.  So I
> don't think the reason is simply that it would be hard to deal with the
> magic attributes.
>
>         Of course, I'm not sure what advantage there would be to requiring
> that all GBeans be Serializable, either, since generally speaking they
> won't work if transferred somewhere over the network without speal
> reconstruction support on the other side...
>
>         The more interesting question is Hiram's point on providing more
> advanced support for attribute contruction.  This seems to be one of the
> advantages Dain's Spring-based kernel provides.
>
> Aaron
>
> On Wed, 25 May 2005, 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 <[hidden email]> 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
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

Dain Sundstrom
In reply to this post by Srinath Perera
In geronimo only the attributes explicitly marked as "persistent" in  
the GBeanInfo are serialized.  The magic attributes are not allowed  
to be marked as persistent.

-dain


On May 25, 2005, at 6: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 <[hidden email]> 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why are gbeans not serialized but the gbean attributes are?

Dain Sundstrom
In reply to this post by ammulder

On May 25, 2005, at 7:24 AM, Aaron Mulder wrote:

>     The more interesting question is Hiram's point on providing more
> advanced support for attribute contruction.  This seems to be one  
> of the
> advantages Dain's Spring-based kernel provides.

Right. One big advantage of the Spring based kernel is the attributes  
get the same quality of service as the top-level named service (a  
GBean in geronimo nomenclature).  In geronimo we save the "recipe"  
for a service, meaning we save the name of the class to construct,  
the attribute values to inject and the references to inject.  When  
the service is restarted, we follow the recipe to create a new  
instance of the service.  In the spring based kernel, not only do we  
have a recipe for the top-level named service, but the attributes can  
also be saved as a "recipe".  This means an attribute can be  
arbitrarily complex without having to support serialization.

-dain