Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <Pine.LNX.4.58.0505251010380.15722@saturn.opentools.org>
References: <db42f0b78651dbfe91e270eff02b2ae2@hiramchirino.com>
 <f8de7ee0505250623788dc5b7@mail.gmail.com>
 <Pine.LNX.4.58.0505251010380.15722@saturn.opentools.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <78495790-A65E-4F9C-9D62-005A73A2E939@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Why are gbeans not serialized but the gbean attributes are?
Date: Fri, 27 May 2005 15:43:15 -0700
To: dev@geronimo.apache.org


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