On Tuesday 23 November 2004 09:49, ixxus nexxus wrote:
> Do you know of a good resource to working with blocks?
If you have read the basic papers on Soc and Ioc, then I have not much else to
offer...
> Could you help me
> how to modify the block to do what you described?
I'll try...
> In looking at the one of the block.xml that I've got, I see something like
> this:
> <container name="c">
Defines a loadable block, named "c"
> <services>
> <service type="a.b.c.Service">
> <source>service</source>
> </service>
> </services>
Defines that this block should expose the component named "service" as a
Service of type "a.b.c.Service". It requires that "service" (in this case
ServiceImpl) implements the Java interface "a.b.c.Service" and that it
defines the service in its type descriptor (.xinfo).
> <component name="service" class="a.b.c.ServiceImpl" activa
> tion="lazy"/>
Instructs Merlin that this container contains a component (i.e. a service
implementation) named "service", that the class to use is a.b.c.ServiceImpl
and that it should not activate it until it is being requested by someone
else.
> <component name="c2" class="a.b.c.c2Impl" activa
> tion="lazy"/>
same thing.
> </container>
end of container/block.
> I turns out that the only component that I need to modify is "c2", not the
> one that is named in the service definition. Will what you describe still
> work even if the component is not directly the service?
c2 is still a service implementation of some kind. If you locate the
a/b/c/c2Impl.xinfo file, you can see the service information of the "c2"
component in there.
since "c2" is activation="lazy" and isn't exposed as a service of the
container, I assume that "service" looks it up at some point.
Let's say that is the case. Then what you can do is;
Create a new class, which implements the same service as "c2", have that class
lookup "c2" for the delegation and change the block above, so that;
<component name="service" class="a.b.c.ServiceImpl" activation="lazy">
<dependencies>
<dependency key="c2" source="c3"/>
</dependencies>
</component>
(you will need to check the .xinfo file for the "key" of the ServiceImpl for
the "c2" dependency)
and introduce a
<component name="c3" class="a.b.c.C3Impl" activation="lazy" />
(you should not need to manually wire the "c3" to "c2". I think that Merlin
will locate that automatically. If not, then do the same thing as for the
"service" component.
> Also, the application I've got seems to have a number of block.xml files
> but none of them seem to be in the main directory? How do I figgure out how
> they are tied together and which is the "main" one?
Ok, there is no "main" in Merlin. Either the application is started by the
stand-alone Merlin, or it is embedded inside another application. I assume we
are talking the stand-alone case, where you start by a command-line "merlin"
of some kind.
On that command-line you provide the "block" reference, which is a XML file
similar to the one above. In it, you will find one or more components, and
possibly <includes> of other blocks references.
All of what is linked together forms the Model, i.e. an internal
representation in Merlin that defines the total application, without loading
any of the classes or instantiating them.
Merlin will then go through the list of components, and whatever components
that has the activation="startup", will be "commissioned".
"commissioned" means slightly different things for different "lifestyles"
(which can be found in the .xinfo file).
For singletons, it means that for each <component> element a Java instance
will be created, and its lifecycle methods will be called.
So, you need to locate the starting block and all blocks that are indirectly
linked into it via <includes>, check which components are
activation="startup" and has a lifestyle="singleton", and you have found the
initial set of components that Merlin starts in the beginning.
Now, please remember that these components may lookup and call other
components of different lifestyles and activation policies, and they will be
created and initialized accordingly along the way.
I hope this gives you enough background to get going.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
