"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.
now i can relax, because i've found a work-around:
in the xinfo i declare all context entries other than String, Integer, etc.
to be Object. this way i can provide a packaged profile which causes
meaningless Object()s to be created. then i overwrite them by:
componentModel.getContextModel().setEntry("socketChannel", SocketChannel.open());
although my work-around is working well for me, it would be
nice, if you clarified the issue...
/eike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
