avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: Phoenix and the Web
Date Wed, 02 Oct 2002 15:24:12 GMT
Daniel Krieg wrote:
> 
> I agree.  However, within Phoenix, SARs can have dependencies on other SARs,
> can access these SARs from the ServiceManger which is supplied in the
> service method, and can utilize these other SARs to perform their work
> interface.  This is not counter to IoC.

Blocks can have dependencies on other blocks, when they are assembled in 
one SAR. That is ok and does not break IOC, because Phoenix doesn't 
control individual blocks, it controls SARs. However, when SARs start to 
control other SARs, I think IoC is broken.

> Wrong.  Phoenix will control the lifecyle of Catalina and all WARs within
> it.  I am simply offering a work interface that allows other SARs the
> capability to deploy/undeploy WARs specific to that SAR...at least that is
> the current interface ( posted a message to the Avalon-Phoenix Developers
> List earlier today discussing this).  WARs should be able to access the work
> interface for other SARs within Phoenix and utiltize their capabilities.

Hm, for me one of the cool features of Avalon/Phoenix is that SARs do 
*not* depend on other SARs and one malfunctioning SAR cannot cripple 
another one.

Somehow I don't like the idea of a SAR undeploying a component that 
belongs to another SAR.

> What I have done with Catalina Sevak is to have its lifecycle determined by
> Phoenix, managable through Phoenix's MX4J HTTPConnector, and provides the
> full functionality of Tomcat except its own server start/stop sequence.

I think that is reasonable. You are controlling a WARs lifecycle through 
Phoenix's lifecycle, this does not break IoC, it's just a mapping.

> More people use Servlets than use Phoenix and is therefore a recognized
> standard.

Absolutely.

 > I can create a WAR that depends on other J2EE standard
> components, such as TransactionManagers, etc. configure the application
> server (Phoenix) to map its resources instances (SARs) into the JNDI
> namespace that the WAR searches, to supply that WAR with appropriate
> component implementations.  Many application servers offer additional
> "proprietary" funcationality.  This is my goal with Phoenix.  Create the
> ability to map Phoenix resources into the JNDI ENC of deployed WARs.

I'm not saying these proprietary extensions are bad, I'm just saying 
they are not a standard in the same way that an alternate Servlet API is 
not a standard. It's also just a proprietary extension.

About Phoenix==>JNDI==>WAR - I see performance problems. I think this is 
workable only for infrequent communication, like configuring at startup. 
But providing a synchronous service over that link? Hmm....

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung


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


Mime
View raw message