avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <leosim...@apache.org>
Subject RE: Lifecycleable interface
Date Fri, 12 Apr 2002 09:44:01 GMT
> Phoenix has a drawback as a server/container of other application
> containers(i.e. serlvet, EJB, Jesktop etc..). It doesn't provide a simple,
> united way to allow applications(i.e., a servlet deployed in a serlvet
> engine contained in phoenix) to communicate with the phoenix kernel, other
> sars,  and other blocks assemble within the same sar.

This follows directly from the implementation of the Inversion of Control
pattern. You should not see it as a drawback!

> I hope in the future, I can answer the question 'Why deploy a
> servlet in Jo!
> running inside Phoenix, but not a standalone Jo! environment' as 'The
> servlet can utilize services provided by other phoenix
> blocks'(The Beauty of
> Phoenix).

I think that 'The servlet can utilize services provided by other phoenix
blocks' should not be a feature of phoenix. Rather, it should be a feature
of an application/block running in Phoenix, for example, a JNDI registry.

The reason: we want to guarantee applications running within phoenix a
black box. While it should be possible for others to gain access to the
black box (ie use the services it exposes), this is not something the
kernel should do, but rather something the application in that black box
should do itself.

In concrete terms, we have Phoenix running a JMX Server in one block
(and the kernel registers itself with the JMX Server), another block
running EOB (which registers itself with the JMX Server) and yet
another block running Jo! (which registers itself with the JMX Server).
Jo! can now access EOB through JMX, but not through the kernel.

Further discussion should go to the phoenix list, of course.


- Leo

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