Laszlo Hornyak wrote:

Joerg Buchberger �rta:

Laszlo Hornyak schrieb am 18.11.2002:

Joerg Buchberger mrta:

Hi.
I've got a couple of questions on Avalon and Phoenix:
1. How stable is Phoenix?
Stable enough :)

great :)


4. Does Phoenix offer its Blocks any means to communicate
centrally?

Your block gets a reference of the other block. see
ComponentManager.

Skipping thru the mailing list archive I read that
ComponentManager is deprecated (correct me if I'm wrong).

:) I mean ServiceManager.
I don`t know what is the difference, please someone from the developer group point me to the explanation. I still build my components on the component package...

The ComponentManager interface cntains the following operation:

Component lookup( String key ) throws ComponentException

This implies that any component exposed by the ComponentManager interface *must* implement the Component interface. This sucks big time because it means that if your working with "non-Avalon" components, you have to sork around this by proxying or wrapping object to look like components. The ServiceManager cleans up this problem by declaring the lookup operation as follows:

Object lookup( String key ) throws ServiceException;



Are there any other alternatives with regard to
"inter-block" communication?

What interblock communication do you need?
An assynchronious, or something CORBA-like thing?
For assynchronous communication, I think you can use worker threads and work queues, so it is not realy needed in a framework, isn`t it?
For a networked communication: it is not the framework`s job to do that.

At the level of a Phoneix application there is a thing called a BlockListener which you can use to ensure that one component in an application get notified of other componets that are deployed (but its container specific).

The alternative is to define a service which acts as a rspository/directory of service references. Include this component as a service depedency, then when you are up and running, use that service to get the references you need. Sometime in the case of recusive depedencies you need solutions like this to work around the problem.


Cheers, Steve.


Laszlo Hornyak


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

Reply via email to