"Stephen McConnell" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL PROTECTED]
> Eike Stepper wrote:
>
> > hi,
> >
> > what is the preferred way to commission components dynamically?
>
> The preferred way is to use a "facility" - which I'll explain.
> Currently I'm presuming that you have merlin embedded in an application
> and you have successfully deployed a block (or two or more) either by
> parameterizing the factor criteria or by interacting with the root
> containment model API.
>
> At this level (meaning at the level of code that is embedding Merlin)
> you will quickly run into limitations as to what you can and can't do as
> a result of not having component classes available in the space in which
> your code is executing. The classes are available within Merlin down in
> a container somewhere but your simply too far removed from action. The
> solution is create a regular component that will manage things from with
> (as opposed from above).
i'm not sure about what you mean here. what is the benefit in creating
another component with the same inconveniences (regarding the accessibility
from outside of the container)? is it not possible to set up the classpath of
the "embedder" similar to the one of the container?
> Management from within is archived by providing a component with a
> reference to the containment model it is resident within. Like Niclas
> described - this is achieved by declaring a context entry dependency on
> the component that Merlin will take care of for you:
>
> public class MyComponent
> {
> final ContainmentModel m_model;
>
> /**
> * Creation of a new facility.
> *
> * @avalon.entry key="urn:composition:containment.model"
> * type="org.apache.avalon.composition.model.ContainmentModel"
> */
> public MyComponent( Context context ) throws ContextException
> {
> m_model = (ContainmentModel) context.get(
> "urn:composition:containment.model" );
>
> // and now your playing from the inside with everything
> // you need in the classloader associated with this
> // container - you can create and remove subcontainer,
> // commission and decommission components, change
> // configurations, whatever ....
> }
> }
>
> >
> > up to now i just call the constructor of the component class and
> > some of the lifecycle methods. how is the association to a particular
> > container established?
>
> You should *never* need to do such lowly stuff - merlin will do these
> things for you based on request you make based on supplied service
> references or named components references. Remember that it's really
> important to eliminate assumption in you code about components (such as
> constructor signatures, lifecycles, etc.).
>
> > i've also tried to use the model to add a DefaultComponentModel
> > but got stuck when asked for the SystemContext with its awful ctor.
>
> Sounds like your going about the construction of the
> DefaultComponentModel in the wrong way (which is interesting because it
> means we have a few constructors to move from public to protected). A
> ComponentModel (a type of DeploymentModel) is normally resolved by
> locating an existing component model that was declared within a block
> under a <component> directive using one of the getModel() operations.
>
> However, if your really aiming for total dynamics and you intend
> constructing a totally new component. Then you create an instance of
> ComponentProfile and add this to the container (and the container will
> return the corresponding ComponentModel):
>
> ComponentProfile profile = createMyComponentProfile();
> ComponentModel componentModel =
> (ComponentModel) m_model.addModel( profile );
no, i'm not looking for the lowest way but for an example of the usual
(high-level) way. please imagine a simple tcp connection listener (ServerSocket).
on connection attempt of a client it has to incarnate a slave socket. in case
this slave socket is a component (i want to manage and monitor it), the master
component would have to commision a new component. i could not find any
example or description, how this is achieved (well, actually there was an example
in excalibur or cornerstone, but that illustrated the direct use of constructors and
active lifecycle calls, which you called odd above).
/eike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
