avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Ivanov" <my...@surfeu.fi>
Subject Using Service / Component Selector in Phoenix
Date Tue, 11 Jun 2002 12:10:30 GMT
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):

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?


----- 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
> 3. XPath or other evaluated expression :)
> 4. Kernel
> 5. No, but there may be cases where they need to be queried by the kernel
> constraint resolution (like the ORB example. the kernel will most likely
> 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
> > 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
> easy as exposing MetaInfo classes.
> -pete
> --
> peter royal -> proyal@apache.org
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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>

View raw message