"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. > > D:\dev\avalon\merlin\target\docs\api\org\apache\avalon\composition\data\ComponentProfile.html
great!!! now i'll have to restructure my system again - but the intervals between restructurings become larger ;-)) thanks /eike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
