Niclas Hedman wrote:

> Perhaps you have not noticed that there are a set of tutorial samples as
well.
> Not sure where they go distribution-wise, but I know you work with the
CVS,
> so look in;
>   avalon/merlin/platform/tutorials
>
> I think this will also give some "tidbits". :o)
>

I'll have a look at them and I'll see if add them to the documentation.

> This is a "controversial issue". Inversion of Control means that we intend
to
> remove the ability for components to "go out and find" on their own.
> However, no container prevent stuff like this from happening (yet), but I
> doubt you will see something that generic.

I see. But this way don't you force all components to know about each other?
Suppose you're running 5000 services, and that tomorrow you write a service
that is useful for all of them. Probably there is another way, but with what
you're saying, should all the 5000 services add the new entry to their
declarative execution environment? This is one of the issues that Naming
Services want to address and one of the reason why they are so popular.
>
>
> Not sure what you mean.
>    merlinx.sh -execute someComp.jar
> will pick up the /BLOCK-INF/block.xml and create a deployment scenario
from
> that file.
>
>    merlinx.sh someBlock.xml
>
> where the block XML file given will describe the deployment scenario. In
which
> case you can have loads of "assembled" applications with the blocks you
have
> at your disposal.
>

I've tried both but I obtain the following:

D:\Projects\myMerlin>merlinx -execute target\merlinj-1.0.jar
---- runtime exception
report --------------------------------------------------
Exception: org.apache.avalon.merlin.KernelRuntimeException
Message: Unable to transform the token: [and] due to an unexpected error.
---- 
cause ---------------------------------------------------------------------
Exception: org.apache.avalon.merlin.KernelRuntimeException
Message: Unable to resolve the block path [and].
---- stack
trace ---------------------------------------------------------------
org.apache.avalon.merlin.KernelRuntimeException: Unable to resolve the block
path [and].
org.apache.avalon.merlin.impl.DefaultCriteria.resolveURL(DefaultCriteria.jav
a:731)
org.apache.avalon.merlin.impl.DefaultCriteria.getDeploymentURLs(DefaultCrite
ria.java:446)
org.apache.avalon.merlin.impl.DefaultFactory.create(DefaultFactory.java:474)
org.apache.avalon.merlin.cli.Main.<init>(Main.java:322)
org.apache.avalon.merlin.cli.Main.main(Main.java:274)
----------------------------------------------------------------------------
----

How could I solve?

> More than we want to believe.
> To make it RMI only is no big deal, and I think there are some work
already
> done in that area (pre-my time).
> But _I_ want to see Merlin be capable of being a Jini containment
platform, so
> that services that are deployed in Merlin would join the federation of
Jini
> services.
> This is a lot trickier to use, as we must first make the "static binding"
of
> Merlin today into a "dynamic binding", and allow services to "come and
go",
> i.e. other services should not only have "lookup" but also be registered
as
> some form of "availability listeners" to the services they require.

This sounds good, but isn't that against the Inversion of Control pattern?

>
> Niclas
>

Marco
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to