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
differentThe 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
<[email protected]>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"
;)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. Sometimes. I haven't seen any container-specific examples yet though1. 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;
kernel2. 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
some
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
bemust be defered to init time.
The problem is basically that in some cases it is going to be
practically
I agree. I'd opt more for the "specific contracts" option, which couldimpossible for kernel to validate the constraint unless the provider conforms to very specific contracts or is self validating.
<mailto:[EMAIL PROTECTED]>
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:
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]>
