Thank you very much Stephen for taking the time to explain these points. So for me the pictures gets much clearer now. It behaves like I would expect - after understanding what happens behind the scenes.
Thanks again, Daniel -----Ursprüngliche Nachricht----- Von: Stephen McConnell [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 13. März 2004 17:38 An: Avalon framework users Betreff: Re: Lifecycle disapeared Daniel Frey wrote: >>>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-systems block - a standalone container description partition - the namespace associated with a container or component with a hierarchical model > If 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]
smime.p7s
Description: S/MIME cryptographic signature
