"Stephen McConnell" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL PROTECTED]
> Eike Stepper wrote:
>
> > "Stephen McConnell" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL 
> > PROTECTED]
> >
> >>Eike Stepper wrote:
> >>
> >>>"Stephen McConnell" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL 
> >>>PROTECTED]
> >>>
> >>>
> >>>>Eike Stepper wrote:
> >>>>
> >>>>
> >>>>
> >>>>>hi,
> >>>>>
> >>>>>i'd like to bring that topic back to your attention:
> >>>>>
> >>>>>am i really forced to carry a resolved proxy of a
> >>>>>transient component as long as i want the component
> >>>>>be prevented from disposal?
> >>>>
> >>>>Lets get back to an underlying question.  The transient lifestyle is
> >>>>intended for create-use-forget style components - however - everything
> >>>>seems to indicate that your using transients in order to achieve some
> >>>>specific objective.  Can you fill me in?
> >>>
> >>>
> >>>hmm, your counter question makes me suspicious again ;-)
> >>
> >>:-)
> >>
> >>
> >>>is there another big concept that i 'm missing? i thought it's quite
> >>>natural to have singleton classes like let' say a SessionManager.
> >>>but it's even more natural to have many non-singleton classes
> >>>(you call them transient) like a Session. it's most vital for most
> >>>abstractions to simultaneously have multiple instances with
> >>>different states. if i want such an abstraction to be implemented
> >>>as a component, i have to declare it transient, do i not?
> >>
> >>Short answer - no.
> >>
> >>What you seem to be describing is singleton lifestyle.  Keep in mind
> >>that the notion of "single" refers to a single identifiable deployment
> >>scenario.  Consider the following two component declarations (and assume
> >>that the underlying component type is a singleton):
> >>
> >>    <component name="widget" class="IdentifiableDemo"/>
> >>    <component name="gizmo" class="IdentifiableDemo"/>
> >>
> >>The above declarations will result in the establishment of two instances
> >>- widget and gizmo, each with their own state.  As far as Merlin is
> >>concerned both component declarations represent unique deployment
> >>scenario (doing a widget.equals( gizmo ) will return false).
> >>Programatically you can construct the deployment models for widget and
> >>gizmo by creating the profile on-the-fly, add it to the container,
> >>commission the returned model and instantiate it using resolve.
> >>
> >>Does that make sense?
> >
> >
> > yes ;-)) it would also solve the problem that my components all share
> > the same name, what makes log-analysis annoying...
> >
> > how exactly is "creating the profile on-the-fly" done?
>
> Just create an instance of ComponentProfile and add this to your
> container. Without looking at the docs it should be something like:
>
>     String name = "widget-" + ( n++ );
>     String classname = "IdentifiableDemo";
>     ComponentProfile profile = new ComponentProfile( name, classname );
>     ComponentModel model =
>       (ComponentModel) m_containerModel.addModel( profile );
>     model.commission();
>     IdentifiableDemo widget = model.resolve();
>
> Also - take a look at the javadoc for ComponentProfile to get an idea of
> the sorts of things you can do with the class.

since this is a blocker for me i've tried once more to set up
the most simple scenario: a facility that produces a component
via an implicit ComponentProfile. it works well as long as i do not
declare the created component to expect a context entry of type
java.nio.channels.SocketChannel.

in fact a context entry of type java.lang.Integer also causes the NPE.
obviously addModel(profile) fails if the component requests non-standard
context entries...

i have some sources of avalon+merlin but they don't exactly match
the binary releases that were downloaded (framework-4.2.0). the
place where the sources should be downloaded only contains the tutorial
sources. i don't know how to make svn switch to a certain release (even
if i knew the proper tag).

/eike





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to