Daniel Frey wrote:
Stephen McConnell wrote:
Just a note concerning activation - the default behaviour is then any component declared using <component> will have activation on startup enabeld by default - unless the component type is transient.
Sounds like the default changes for all components in the system... This is certainly true for WhateverImpl when using the activation attribute. What about other components not using the activation attribute? Does the default change for any component declaration within the same block.xml (<container>), or even for any component running in the system? I would expect that each component has its default which may be overridden by the activation attribute for the component meant by the name attribute, so in:
<container> <component name="fred" class="WhateverImpl" activation="startup"/> <component name="alf" class="WhatelseImpl"/> </container>
That fred is activated on startup and alf is default.
That's what happens.
Just correct me if I'm wrong: - What about other components not using the activation attribute? They use the unchanged default: transient.
There is some confusion here. First off - totally independently of startup policies, we have the notion of a component lifestyle. A lifestyle policy is related to the component type - for example a singleton lifestyle states that a component instance of this type can be shared by many different client (i.e. its thread-safe). A "thread" lifestyle can be shared between multiple components within the same thread, a "transient" component is not shared and a new instance is created for every request.
Because transient components are not shared - it does not make sense to activate them on startup. Hence - the default activation-on-startup policy for a component with a transient lifestyle policy is false.
- Does the default change for any component declaration within the same block.xml (<container>), or even for any component running in the system? Nop, neither.
Declaring activation="startup" only effects the component against which it is declared on. However, keep in mind that if your component has dependencies on other components, then the other components will be automatically activated irrespective of the startup policy.
So for example, if WhateverImpl class contains a component tag looks like:
@avalon.component name="xyz"
then the component will default to a "transient" lifestyle in which case
activation on startup will be false - however, this can be overriden by declaring the activation="startup" policy in the component directive.
So transient is default, which may be overridden in the component
configuration within block.xml
No. The lifestyle of a component is declared by the component implementation. I.e. to use a different lifestyle you need to declare this as part of the @avalon.component tag using the lifestyle attribute.
Ok. So transient is default activation.
No. The "transient" lifestyle is the default lifestyle policy.
It may be overridden by in the
@avalon.component tag by using one of the values singleton, thread or
pooled.
The lifestyle policy may be declared using @avalon.component lifestyle=[LIFESTYLE-POLICY]".
And this may be overridden by the components activation attribute in the block.xml file.
A lifestyle policy cannot be modified. It is immutable and part of the component implementation. The activation on startup policy can be overridden on a per-component basis using the activation attribute.
Btw, I've found now three terms which in my limited beginners understanding
are equivalent: container <-> block <-> partition.
Related ...
container - a system providing support for component isolation
that enables service delivery through composition of
a set of contained sub-systemsblock - a standalone container description
partition - the namespace associated with a container or
component with a hierarchical modelIf there is not difference, except from where it is being used, it would be nice to unite them. What about the very clear container.xml has a container tag and the standard context entry for it is urn:avalon:container?
Context entries scoped under urn:avalon are restricted to the "normally" available set of context entries (i.e. standard avalon).
I suppose the lifestyle attribute of the avalon.component javadoc tag has nothing to do with the activation?
Given either of the following equivalent declarations:
@avalon.component name="widget" @avalon.component name="widget" lifestyle="transient"
The the lifestyle will be set to TRANSIENT and the default activation on startup policy will be false. For any other lifestyle, if the component is actually declared in a block, the default activation on startup is enabled.
So it has to do with each other: transient activation <- transient lifestyle, startup activation <- singleton, thread or pooled lifestyle. That's not mentioned in the javadoc tag reference in the Meta documentation. Maybe you don't want to have too much cross referencing, which always involves many documentation upgrades in case of changes... But if not I could try to insert a subchapter "Note" mentioning this.
No.
Transient component are a special case. Unfortunately when associating a lifestyle if no lifestyle is declared - the only safe lifestyle assumption is transient.
Ok - when we commission a container model the container looks at all of the component and subcontainers models within it. If the child being commissioned is a component model - then the container has to make a decision if a instance should be created or not. Generally speaking it makes sense to pre-load components that have been declared inside a container, however, if the component type's lifestyle is transient it does not make sense (unless the policy of explicitly overridden) because activation at this point is not a result of a request for any other component - which means that the component will never be referenced by anything else (because any subsequent request will always return a new instance).
Cheers, Steve.
Sorry about the problems - but the feedback is definely appreciated.
Don't sorry. That's normal, but confusing at the beginning. I think I'll calculate two weeks of getting into Merlin before refactoring my application.
Thanks, Daniel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
