Andrei Ivanov wrote:
>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
>
Yep.
>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).
>
Yep.
>
>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?
>
Correct.
>-------------------------------------------------
>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...
>
Phoenix can establish block1 and block2 and provide these to top-block.
The top-block implementation is basically acting as a proxy and
directing requests to either block12 or block2 based on the
configuration supplied policy. As far as Phoenix is concerning,
top-block is a perfectly valid cvandidate for supply the service to Main.
I don't see an issue (but I'm working on other things at the same time
and my have just missing simothing important).
Cheers, Steve.
>
>Andrei
>
>----- Original Message -----
>From: "Stephen McConnell" <[EMAIL PROTECTED]>
>To: "Avalon-Phoenix Developers List" <[EMAIL PROTECTED]>
>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" <[EMAIL PROTECTED]>
>>>To: "Avalon-Phoenix Developers List"
>>>
>>>
><[EMAIL PROTECTED]>
>
>
>>>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" <[EMAIL PROTECTED]>
>>>>>To: "Avalon-Phoenix Developers List"
>>>>>
>>>>>
>>>>>
>>>>>
>>><[EMAIL PROTECTED]>
>>>
>>>
>>>
>>>
>>>>>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 -> [EMAIL PROTECTED]
>>>>>>
>>>>>>--
>>>>>>To unsubscribe, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>><mailto:[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]>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>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]>
>
>
>
>
>
>--
>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]>
