[cross-posting from Avalon Dev to Avalon User] Adam Rossi wrote:
You can do what you describe though a lifecycle extension. There are examples of the application of compoent lifecycle extensions in both Fortress and Merlin and documetation for both under the following URL:Stephen, I found your summary descriptions helpful. On thing I am struggling with is how to set a parameter in a component that is needed during Initialiable. For example, if my Company component needs a companyID set before it can initialize, how does the container set the ID before initialize is called? It seems that a name/value pair should be set in the context so that Contextualizable can supply the companyId before it is initialized. I have tried to find an example of this but could not find one. Is this beyond the lifecycle of the container and something that should be done via a set method after I have my object?
http://jakarta.apache.org/avalon/excalibur/container/extension.html
If have have a situation where code has runtime information that is needed by a component to function, then your basically describing something in container-land. As such, you need to think of in terms of your code acting as a container, and deploying components as required, and supplied with appropriate runtime information. The component lifecycle extension architecture does exactly this - it enables the seperation of a container side handler from the component-side lifecycle interface.
That was the quick answer - here is the longer answer that also addresses the point about container verus component seperation.
Unlike the framework interfaces, an Avalon Container API does not exist. However, there are iniatives such as the Fortress and Merlin work which specifically address embedded components, and varying levels of functional container-side services. There is also more application level content within the Phoenix project. If you look into all of this content you can basically break down the container-side concerns to the following:
1. logging management
- logging system bootstrapping
- logging channel creation
- management of logging targets
2. context management
- context criteria management
- context export from a container to a component
- declarative context generation
3. configuration management
- classic configuration loading
- default configuration handling
- cascading configurations
- verifiable configurations
4. component assembly
- building associations based on services and depedencies
- validation of assemblies
- assembly packaging
5. lifecycle processing
- management of the classic Avalon lifecycle
- extension management
6. lifestyle handling
- management of object pools
- per thread policies
- named providers
- transient components
7. deployment
- classloader management
- containment strategy
- service propergation
8. activation
- deferred activation
- service interface proxying
- principal identity
- policy management
In your example, you have a company identifier, presumably aquired through some runtime parameter, and you need to launch a component and supply it with that parameter, probably as a keyed value with the context object.
The simplest approach is just create you new component, create a context object, add the CompanyID to the context object, then contextualize the component. The problem with this approach is that your creating a tight binding between your container code and the component your deploying. For example, if you add support for logging on your component, you need to go back to you container-side code and make sure the component is given a logger. I.e. your container-side code becomes tightly bound to a component implemetation.
The alternative is to use a container-side framework that provides the type of services I've listed above. As I mentioned above, there isn't an Avalon Container API which means you either leverage something like Fortress or Merlin, or your role-you-own container management solution using things like excalibur/configuration, excalibur/extension, excalibur/container, excalibur/meta and so forth.
If you need any help with exploring the lifecycle extension approach, don't hesitate to post an email avalon-users. As to further sicussions on a Avalon Container API - that something more appropriate under avalon-dev.
Hope that helps.
Cheers, Steve.
Thanks,
Adam
On Fri, 2002-11-15 at 11:51, Stephen McConnell wrote:
<snip>
Contextualizable
supply of the runtime context - again, the
context information that the component needs
(key + type) can be declared in meta info so
a container can make sure the component gets
all of the context information it needs
Configurable
supply of the component configuration by the
to the component.
Initialiable
request from the container to the component
to initialize itself, typically the
component implemetation will validate internal
state at this point
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
