avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Ivanov" <my...@surfeu.fi>
Subject Re: Doesn't work Re: Using Service / Component Selector in Phoenix
Date Tue, 11 Jun 2002 22:46:12 GMT
Hi Steve, thanks for answer. So far I am using solution when one have to
modify assembly to switch between implementations. As you pointed out, I am
using the following approach (let me quote whole picture to make things
clear):

assembly.xml

<block class="com.xxx.Main" name="main">
    <provide name="block1" role="com.xxx.Service"/>
</block>

<block class="com.xxx.DefaultService1" name="block1">
    ...
</block>

<block class="com.xxx.DefaultService2" name="block2">
    ...
</block>
-------------------------------------------------
Main.xinfo
<blockinfo>

  <services>
    <service name="... contract.for.Main..." version="1.0"/>
  </services>

  <dependencies>
    ...
    <dependency>
      <service name="com.xxx.Service" version="1.0"/>
    </dependency>
  </dependencies>
</blockinfo>

-------------------------------------------------
DefaultService1.xinfo

<blockinfo>

  <services>
    <service name="com.xxx.Service" version="1.0"/>
  </services>

  <dependencies>
    ...
  </dependencies>
</blockinfo>
-------------------------------------------------
DefaultService2.xinfo
<blockinfo>

  <services>
    <service name="com.xxx.Service" version="1.0"/>
  </services>

  <dependencies>
    ...
  </dependencies>
</blockinfo>
-------------------------------------------------
config.xml
<block1>...</block1>
<block2>...</block2>

As you pointed, in this case to switch from "block1" to "block2" to be used
by "main", one have to simply replace word "block1" with word  "block2" in
provide clause of "main". So far so good.

Two drawbacks:
1. if there are many blocks which require "com.xxx.Service" to function, one
have to replace block1 with block2 in every place in assembly. This is where
mistakes can happen
2. someone who is implementing new block then must have some idea about how
assembly.xml is constructed and this is bad (requires extra documentation
and so on).

Therefore, it will not be bad if only changes in config will be necessary to
add and select new block which provides com.xxx.Service. Then about second
approach proposed in your reply:

> If you want to do this a composition time, then you would need to
> declare "top-block" as dependent on two services (using different
> role names) and during your initialization, your implementation

Let me "redraw" above, so that you may point if I am mistaken or not:

top-block:
assembly.xml

<block class="com.xxx.Main" name="main">
    <provide name="top-block" role="com.xxx.TopBlock"/>
</block>

<block class="com.xxx.DefaultTopBlock" name="top-block">
    <provide name="block1" role="role1"/>
    <provide name="block2" role="role2"/>
</block>

rest of assembly is the same, is it?
-------------------------------------------------
Main.xinfo
...
    <dependency>
      <service name="com.xxx.TopBlock" version="1.0"/>
    </dependency>

I think I may stop here since, as I see it already, it will not work.
Because there is no way to fetch block1 or block2 inside Main, simply
because it's component / service manger will not contain block1 or block2...

Andrei

----- Original Message -----
From: "Stephen McConnell" <mcconnell@osm.net>
To: "Avalon-Phoenix Developers List" <avalon-phoenix-dev@jakarta.apache.org>
Sent: Wednesday, June 12, 2002 12:59 AM
Subject: Re: Doesn't work Re: Using Service / Component Selector in Phoenix


>
>
> Andrei Ivanov wrote:
>
> >Hm, after closer look I see that this solution doesn't work.
> >It just shows how to use other role names (that class name) but it
doesn't
> >tell how to select implementations :-(
> >
>
> If I understand you correctly, you want to be able to select which block
> implementation is going to provide a service to a dependent block.  The
> routing of the provider to the dependent is declared in the assembly.xml
> file.
>
>   <block class="myDependentBlockClassName" name="top-block" >
>     <provide name="block-b" role="the-role-for-service-A"/>
>   </block>
>
> This is telling Phoenix to use a block you have named as "blockB"
> as the component provider of service A.  To switch between "block-a"
> and "block-c" is basically a matter of updating the mapping in your
> assembly.xml.
>
> If you want to do this a composition time, then you would need to
> declare "top-block" as dependent on two services (using different
> role names) and during your initialization, your implementation
> selects which service it is going to use based on the information
> contained in the configuration.
>
> Hope the helps.
>
> Cheers, Steve.
>
>
> >
> >Andrei
> >
> >----- Original Message -----
> >From: "Stephen McConnell" <mcconnell@osm.net>
> >To: "Avalon-Phoenix Developers List"
<avalon-phoenix-dev@jakarta.apache.org>
> >Sent: Tuesday, June 11, 2002 4:03 PM
> >Subject: Re: Using Service / Component Selector in Phoenix
> >
> >
> >
> >
> >>The document
>
>>http://jakarta.apache.org/avalon/phoenix/guide-example-configuration.html
> >>contains a description of how to handle this inside Phoinix.
> >>
> >>Cheers, Steve.
> >>
> >>
> >>Andrei Ivanov wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>I came across with simple problem (I think it is simple for experienced
> >>>Avalon developers) with my Phoenix-based application.
> >>>
> >>>The problem is as follows:
> >>>I have phoenix service which contract is defined in interface
> >>>
> >>>A. ServiceInterface
> >>>
> >>>I have two different block which offer service A (in other words
> >>>
> >>>
> >different
> >
> >
> >>>implementation for the same service):
> >>>
> >>>Blocks
> >>>B. offers A
> >>>C. offers A
> >>>
> >>>B and C should be configured and initialized differently as well as
they
> >>>will depend on different services.
> >>>
> >>>I would like to be able to specify which block will be used (B or C) to
> >>>provide service A changing only configuration (config.xml) file.
> >>>Can anyone give me example how to achieve that and what is the standard
> >>>practice for Phoenix-based application for this?
> >>>
> >>>Regards,
> >>>Andrei
> >>>
> >>>
> >>>
> >>>----- Original Message -----
> >>>From: "Peter Royal" <proyal@apache.org>
> >>>To: "Avalon-Phoenix Developers List"
> >>>
> >>>
> ><avalon-phoenix-dev@jakarta.apache.org>
> >
> >
> >>>Sent: Monday, June 10, 2002 5:44 PM
> >>>Subject: Re: Constraints on dependencies
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>On Thursday 06 June 2002 07:43 pm, Peter Donald wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>1. Are constraints container specific or not?
> >>>>>2. Is there a subset of constraints that are container agnostic?
> >>>>>3. How do we represent constraints in the system? An opaque string?
A
> >>>>>Configuration tree? An XPath expression?
> >>>>>4. Do the providers or the Kernel validate the constraints?
> >>>>>5. Do the providers get informed that they must conform to certain
> >>>>>constraints?
> >>>>>6. Does validation occur at initialization time or assembly time?
> >>>>>
> >>>>>My answers would be;
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>1. Sometimes. I haven't seen any container-specific examples yet
though
> >>>>
> >>>>
> >;)
> >
> >
> >>>>2. Yes. Mainly anything that involves lookup( ROLE ), ie. component
> >>>>
> >>>>
> >>>>
> >>>>
> >>>assembly
> >>>
> >>>
> >>>
> >>>
> >>>>3. XPath or other evaluated expression :)
> >>>>4. Kernel
> >>>>5. No, but there may be cases where they need to be queried by the
> >>>>
> >>>>
> >kernel
> >
> >
> >>>>
> >>>>
> >>>for
> >>>
> >>>
> >>>
> >>>
> >>>>constraint resolution (like the ORB example. the kernel will most
likely
> >>>>
> >>>>
> >>>>
> >>>>
> >>>be
> >>>
> >>>
> >>>
> >>>
> >>>>unaware that its ORB component hosts others)
> >>>>6. Both. As much as possible should be done at assembly, but I'm sure
> >>>>
> >>>>
> >some
> >
> >
> >>>>must be defered to init time.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>The problem is basically that in some cases it is going to be
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>practically
> >>>
> >>>
> >>>
> >>>
> >>>>>impossible for kernel to validate the constraint unless the provider
> >>>>>conforms to very specific contracts or is self validating.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>I agree. I'd opt more for the "specific contracts" option, which could
> >>>>
> >>>>
> >be
> >
> >
> >>>>
> >>>>
> >>>as
> >>>
> >>>
> >>>
> >>>
> >>>>easy as exposing MetaInfo classes.
> >>>>-pete
> >>>>
> >>>>--
> >>>>peter royal -> proyal@apache.org
> >>>>
> >>>>--
> >>>>To unsubscribe, e-mail:
> >>>>
> >>>>
> >>>>
> >>>>
> >>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> >>>
> >>>
> >>>
> >>>
> >>>>For additional commands, e-mail:
> >>>>
> >>>>
> >>>>
> >>>>
> >>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
> >>>
> >>>
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail:
> >>>
> >>>
> ><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> >
> >
> >>>For additional commands, e-mail:
> >>>
> >>>
> ><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
> >
> >
> >>>
> >>>
> >>>
> >>--
> >>
> >>Stephen J. McConnell
> >>
> >>OSM SARL
> >>digital products for a global economy
> >>mailto:mcconnell@osm.net
> >>http://www.osm.net
> >>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >>
> >>
> ><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> >
> >
> >>For additional commands, e-mail:
> >>
> >>
> ><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
> >
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
<mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
<mailto:avalon-phoenix-dev-help@jakarta.apache.org>
> >
> >
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message