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 <[EMAIL PROTECTED]> 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 <[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 > > > > > > > > >
