Leo Sutic wrote:
>1) How is end-of-life processing handled?
> If the service instance implements Disposable, when and how do I
> dispose of the service instance?
>
>
Two options (depending on value of the DISPOSAL_POLICY_KEY supplied in
the context). The behaviour depends on (a) the value of the policy, and
(b) the the target components support for Startable and/or Executable.
See javadoc in ServiceLoader describing context values. To summarise -
if the component is Startable, and disposal is faslse - merlin runs the
component until a shutdown hook occurs following which it properly
disposes of the component (this is something that will change in Merlin
II - i.e. a formal startup and shutdown process following the
containerkit model).
>2) Suppose I have a component A that has a dependency on component B.
> When I call pipeline("A"), this will set up and instance of B and
> set up a ServiceManager for A so that A can get a reference to B.
> Correct?
>
Correct - one additional point - if A implements Serviceable then it
gets a ServiceManager otherwise if it implements Composable it get a
ComponentManager.
>
> Now, suppose I call pipeline("B") first, and get a service instance
> of B. Can I force Merlin to use that instance to satisfy A's
> dependency?
>
>
Nope. This is touching on current Merlin limitations (i.e. no provision
for mechanisms to override the assembly logic). That's something for
Merlin II.
>3) In the case above, when B is instatiated as a result of A requiring
>it,
> will B be disposed along with A when A is disposed?
>
Yes.
>4) Where does Merlin keep references to B in the case (3)?
>
>
The ServiceRegistry class class bascally tracks what services are being
used and handles disposal on termination. This is another area the
Merlin II will improve on - containerkit includes the DependecyMap which
should provide the logical ordering of startup and shutdown of dependent
components - I'm currently trying to sort that particular point out at
the moment (see the assembly package README for notes on executing the
current Merlin II demo of current progress).
>MicroContainer does not return a service instance, but a proxy
>implementing
>all of the service instance's interfaces. When the proxy is GC'd or when
>it is
>passed to the MicroContainer.release() method, it handles disposal of
>the
>contained instance as well as all dependencies that are no longer used
>anywhere else.
>I would like to see something similar in Merlin.
>
>
If you dig into the manager classes (AbstrractManager,
DefaultComponentManager, DefaultServiceManger) you will see a code
commented out dealing with pooled components - its was commented out
during the Excalibur reshuffle and reflected uncertainty about where
mpool was going. Personally I would like to see this side of things
enhanced to provide complete support for different lifestyles. This is
also an area where revision to the compoennt/service manager management
needs to be re-cut using the ResourceProvider absttraction in
containerkit. I havn't started thinking about any of that yet in the
Merlin II work. One thing I'm being careful about is kernel/container
interaction - and this is not so clear inside containerkit. But that not
immediately an issue because I'm still dealing at the type/meta level
and havn't got into any compponent instantiation or lifecycle processing
yet in Merlin II.
>It also allows you to specify suppliers (the answer to question 2 is
>"yes" for MicroContainer):
>
> public static Composer getInstance( Supplier supplier )
> {
> return (Composer) new MicroContainer( ComposerImpl.class )
> .component( Supplier.ROLE, supplier ) // Specify supplier
>of service.
> // (The supplier must
>be another proxy.)
> .sharedInstance( true ) // Handling policy
> .create(); // Create the proxy
>instance with a
> // contained
>component instance.
> }
>
>I would love to see something similar in Merlin.
>
Me too! Should this be focussed on Merlin current or Merlin II (where
Merlin II canbe considered more as a general container services
framework)? My suggestion would be to trial some things using the
containerkit ResourceProvider model and sort out what mata info needs to
be declared to support the above - for example, the sharedInstance is
presumable a policy of the implementation class. I.e. where information
is specific to a component - ensure the possibility for the declaration
of this at the .xinfo level. Concerning proxies - this is also something
I would like to see.
Cheers, Steve.
>
>/LS
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>Sent: den 1 juli 2002 21:13
>>To: Avalon Developers List
>>Subject: Re: [Attn: Stephen] ***I Get It Now***
>>
>>
>>
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>Stephen,
>>>
>>>I looked over Merlin, and I think I'll ditch MicroContainer for it.
>>>
>>>In particular, it would appear as if I can keep just the
>>>
>>>
>>MicroContainer
>>
>>
>>>class (maybe move it over to Merlin).
>>>
>>>Let me explain:
>>>
>>>+ Merlin uses the ServiceLoader class to start up a component.
>>>
>>>+ Basically, you say "ServiceLoader, the components are in these JAR
>>>files,
>>> I want to use this component, load it." So I could use
>>>
>>>
>>ServiceLoader
>>
>>
>>>to
>>> get a DataSourceComponent and it would automatically
>>>
>>>
>>check all listed
>>
>>
>>> JAR files for the depndencies of the DataSourceComponent.
>>>
>>>But then, once Merlin has loaded the component, how do I get a
>>>reference to it? That is, after calling initialize() on the
>>>serviceLoader, what do I do then?
>>>
>>>
>>>
>>ServiceLoader is a compoent that implements the interface
>>PipelineService. The PipelineService interface contains the
>>operation
>>"pipeline" which is the directive to Merlin to load and process the
>>lifecycle of a target component given a classname. The pipeline
>>operation returns the component to the invoking client. Take
>>a look at
>>the
>>http://home.osm.net/doc/merlin/org/apache/excalibur/merlin/pac
>>kage-summary.html
>>and the javadoc for ServiceLoader for addition details.
>>
>>
>>
>>>In particular, suppose I have this:
>>>
>>>public void MyApp {
>>>
>>> public static void main(String[] args) throws Exception {
>>> // Do stuff
>>>
>>> ...
>>>
>>> // I want to use a DataSourceComponent right here.
>>> // The component I want to use is fully meta-enabled, and so is
>>> // all its dependencies. How?
>>>
>>> ...
>>>
>>> // Some other stuff
>>> }
>>>
>>>}
>>>
>>>Question:
>>>
>>>+ Does Merlin *require* the use of external XML files for
>>>configuration? Or can
>>> a configuration be built programmatically and given to Merlin?
>>>
>>>
>>>
>>>
>>Its desiged to be built programatically. No configuration is
>>"required". The functional parameters are passed under a
>>ServiceLoaderContext.Details of ServiceLoader in terms of the
>>contextualize and configure requirements are detiled in the
>>ServiceLoader javadoc. The optional configuration lets the client
>>override the default configuration of a component - but this
>>an area I
>>want to review as part of Merlin II (refer the excalibur assembly
>>package and the readme file for more details). What Merlin
>>does require
>>is that component structure is declared in an xinfo file - at
>>the moment
>>its a bick strict - and I think this could be generalized so that a
>>minimal component xinfo could be logically derived if not explicitly
>>declared - but that's more a Merlin II subject. Main changes between
>>current Merlin and Merlin II are (a) II builds extensively on
>>containerkit, (b) II introduces more structured approach to merlin
>>assembly defintions (an example is included in the Excalibur
>>asssembly
>>package), and (c) the overall design focussed on the ability
>>to create a
>>hierachy of merlin containers in service can be explicitly exported.
>>
>>Cheers, Steve.
>>
>>
>>
>>
>>>/LS
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
>>>
>><mailto:avalon-dev-> [EMAIL PROTECTED]>
>>
>>
>>>For
>>>
>>>
>>additional commands,
>>e-mail:
>>
>>
>>><mailto:[EMAIL PROTECTED]>
>>>
>>>
>>>
>>>
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:[EMAIL PROTECTED]
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:avalon-dev-> [EMAIL PROTECTED]>
>>For
>>additional commands,
>>e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
