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 12:11:06 GMT
Daniel Krieg wrote:
> 
> 
>>Hmm... not sure about that one. Do we really want to write a management
> console
>>for Catalina? Also, it breaks IoC, doesn't it?
> 
> Catalina already has a management console, we would simply be allowing
> clients to invoke without being tightly bound to Catalina.  Breaks
> IoC...really?...how?

First of all, sorry for the ugly formatting, I hope I fixed it now.

Ok, the motto of IoC in the Avalon world is: don't ask how your 
component can call Avalon, have Avalon call your component. So I think 
the WARs shouldn't be able to do anything to Avalon/Phoenix, instead 
they should rely on the fact that some of their methods will be called 
by Avalon/Phoenix. Therefore, those AWARs (Avalonized WARs) should have 
methods that are invoked by Avalon's lifecycle mechanism. Depending on 
how you want to do it they would be called deploy/undeploy or start/stop 
or pause/resume.

If I understood you correctly you don't want Avalon's lifecycle 
mechanism in control of the WARs, rather you want to give the Avalon 
user the power to control Catalina's lifecycle mechanism arbitrarily.

Furthermore you seem to want control in the other direction, too. Please 
correct me if I'm wrong, but your example said that a SAR controls a 
hardware resource and a WAR should control the SAR.

>>You could do that with JMX much, much easier.
> 
> You could do everything with JMX...no need for Avalon framework then...just
> look at JBoss!  I would much rather program to compile-time checked
> interfaces that pass around ObjectNames any day.

What I meant: if you need a management console for a SAR, it would be 
much easier to do it with JMX. I did not mean that WAR<==>SAR 
communication would be easier with JMX.

> I disagree.  Catalina is a Container that manages the lifecycle of Servlet
> instances.  Phoenix is a Container that can manages the lifecycle of
> Avalon-based instances--who have a much richer set of lifecycle methods than
> Servlets.

Both frameworks have their advantages - Avalon has a cool lifecycle, 
Catalina has a cool web container. But Avalon also has *some* web 
container (e.g. MX4J HTTPConnector) and Catalina also has *some* 
lifecycle. So I do not see any principal difference between the two.

> Why do we need to change anything semantically?  What is inheriantly wrong
> with the current state of Web Containers???  Far more reliable than GOTO
> statements!

What I meant: if we write wrappers around Catalina's lifecycle methods, 
we don't get Avalon's lifecycle mechanism. It would be cleaner (but 
maybe technically impossible?) to get rid of Catalina's lifecycle 
altogether in favor of Avalon's and just use Catalina's web container 
functionality.

> You want to rewrite the Servlet's API to Avalonize it?  Could easily be
> done...but would always be a non-standard technology.

Not less of a standard than Avalon itself. There is no way you can take 
a SAR and run it outside of Avalon/Phoenix. In your design it's not 
possible either and also your WARs won't run without Phoenix :)

>>Really? I couldn't find anything in the docs. Maybe in CVS?
> 
> I checked...it is in the Cornerstone project...ConnectionManager and
> SocketManager components.

Ah ok, I know about that one. I misunderstood you and thought you were 
talking about special-purpose Web components. Of course I can always 
open a socket on port 80 and speak HTTP.

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