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