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]>
