> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> Leo Sutic wrote:
>
> >
> >
> >>From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> >>
> >>a solid defition of the four "standard" lifestyles.
> >>
> >>
> >
> >I think we already have that. Pooled means one-per-lookup, from a
> >common pool, singleton means singleton per container,
> transient means
> >one new instance per lookup.
> >
> >Why not just let the definitions stand as they are? I think they are
> >clear enough. The words "pooled" and "singleton" are well defined.
> >"Transient" is made up here, but if we say "one new instance
> for each
> >lookup()" then I think most people will understand.
> >
>
> Some questions for you - here is a defintion of a container with two
> components. Lets assume that the component lifestyle is singleton.
>
> <container name="demo">
> <component type="PersonProvider" name="accounts">
> <configuration>
> <name>Sally</name>
> </configuration>
> </component>
> <component type="PersonProvider" name="logistics">
> <configuration>
> <name>Carol</name>
> </configuration>
> </component>
> </container>
>
> I've just broken you defintion of a singeton. My notion of a
> "singleton" lifestyle is that an instance of an identifiable
> component deployment scenario may be shared across all requests -
> and that multiple deployment scenarios may coexist for that type.
> In the above example - we would see two component managers each
> differentiated in terms of the deployment scenario (different
> confuration or parameters, etc.).
I don't think it is broken - the above will result in exactly
two component instances, yes? One for accounts, and one for logistics.
So one <component/> == one instance.
For transients:
one <component/> == any number of component instances being created
For pooled:
one <component/> == any number of component instances being created,
but we're smart about it.
For thread:
one <component/> == any number of instances being created, but
only one per unique thread that requests it.
That we may have multiple instances of the Java class doesn't make it
less of a singleton when viewed as a component and/or deployment
scenario
in a container. I.e. ONE deployment scenario per container == singleton.
Of course, otherwise we end up in absurdities - singleton-per-universe:
can you guarantee that some gray alien hasn't created an instance of
your class?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
