> 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. regards, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
