> -----Original Message-----
> From: Felipe Castro - M4U [mailto:[EMAIL PROTECTED]
> Sent: 12 November 2004 14:53
> To: Avalon framework users
> Subject: Re: Service configuration
>
> ----- Original Message -----
> From: "Stephen McConnell" <[EMAIL PROTECTED]>
> To: "'Avalon framework users'" <[EMAIL PROTECTED]>
> Sent: Friday, November 12, 2004 11:12 AM
> Subject: RE: Service configuration
>
>
> >
> >
> > > -----Original Message-----
> > > From: Felipe Castro - M4U [mailto:[EMAIL PROTECTED]
> > > Sent: 12 November 2004 13:57
> > > To: [EMAIL PROTECTED]
> > > Subject: Service configuration
> > >
> > > Hello,
> > >
> > > I'm just begining with avalon-merlin and I'm really stuck with a
> > service
> > > configuration problem. I know merlin is being discontinued but I'm
> > just
> > > trying to learn the basics for now.
> > >
> > > I have a container myContainer that exports a service myService
and a
> > > consumer container (myConsumerContainer) that declares some
components
> > > wich depend on myService. Is it possible to modify the
configuration
> > _of
> > > myService_ from the myConsumerContainer block.xml for each
dependent
> > > component?
> >
> > When you declare a component in a block using
> > <component name=".." class=".."/> you basically saying 'here is a
> > deployment scenario so the following example is basically creating a
a
> > couple of components with a particular configurations.
> >
> > <component name="red" class="Widget">
> > <configuration>
> > <color>red</color>
> > </configuration>
> > </component>
> >
> > <component name="blue" class="Widget">
> > <configuration>
> > <color>blue</color>
> > </configuration>
> > </component>
>
> On which block are you saying to do that? The block that exports the
> service
> or the block consuming the service?
In the scenario I described you declare the dependency override on
component that is consuming the service. So for example - if we had a
Gizmo component that wants to consume a widget - we could do the
following:
<component name="gizmo" class="Gizmo">
<dependencies>
<dependency key="widget" source="red"/>
</dependencies>
</component>
As to the 'which block' - well - you need to have the apis in a common
container but apart from that you just include the address of the
component you want to assign to the dependency (the address can be
relative or absolute path where the path is in the form:
[container-name]/[container-name...]/[component-name]
> Placing these declarations on the exporting block would tie me to use
only
> the same set of configurations for every consumer block. I guess I
forgot
> to
> mention that my intention is to make a service package that is used by
> consumer blocks. This would work as a component library, so, ideally,
the
> user blocks would not have access to the library block.xml's.
Several ways to do this - if manual configuration overriding is not
sufficiently flexible then doing the same thing programmatically is also
an option.
> On the other hand, placing these declarations on the consumer block
would
> break interface/impl separation. (I don't know even if that's really
an
> option... just antecipating to save messages)
Placing them on the consumer ties the consumer and provider together
which means you end up with a family of components and that is a
potentially limiting factor.
> Does that leaves me only with the facility option you mentioned below?
The facilities option simply means you can do whatever you want - for
example you could dynamically construct and deploy components on demand,
dynamically modify configuration info and service bindings, whatever.
However - some thinking about the problem could potential establish a
simple solution - for example - setting up a factory service that your
consumers are dependent on - and exposing through that an operation to
get the service based on a set of supplied parameters. The actual
factory implementation could itself be a block or a facility.
Best thing to do is to raise the subject on the support-dpml list.
Hope that helps.
Cheers, Steve.
> Thanks a lot.
>
> >
> > Note that in both cases we are using the same component
implementation
> > class. The next issue to deal with is to assign the right component
to
> > the consuming services - lets assume you have a component named
"fred"
> > that wants a 'red' widget and a component named "bill" that wants a
> > 'blue' widget. This is basically handled by including a
<dependency>
> > directive inside the 'fred' and 'bill' components within which you
> > reference the widget you want bound to the provider. There is a
> > tutorial on this (and supporting code) on the DPML site (something
> > similar should exist on the Avalon site as well).
> >
> >
http://www.dpml.net/central/guide/development/dependencies/manual.html
> >
> >
> > > As far as I now, I could write a "target" directive under the
> > "include" of
> > > myContainer and override the default configuration of myService.
> > That's ok
> > > but it raises a problem if more than one component depends on
> > myService,
> > > each of them needing myService to be configured in a specific way.
> > >
> > > Maybe I shouldn't use the service approach if a different
> > configuration is
> > > needed for each consumer component?
> > >
> > > Thanks for any info
> >
> > Another approach is to do this dynamically using a facility - but if
> > your thinking in that direction then you should get yourself signed
up
> > using:
> >
> > http://www.dpml.net/central/about/resources/lists.html
> >
> > Then do a checkout and build and Magic, Transit and Metro:
> >
> > http://www.dpml.net/central/guide/setup/index.html
> >
> > Cheers, Steve.
> >
> >
> >
> >
---------------------------------------------------------------------
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
