avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Krieg" <dkr...@kc.rr.com>
Subject Re: Phoenix and the Web
Date Wed, 02 Oct 2002 13:46:52 GMT
Ulrich,

First of all I would like to thankyou for your input.  I am currently
working on a specific project and can easily "HACK" together a solution that
might not necessarily be the best design for standard use.  If I am able to
create something that will benefit many others in the process, I would much
rather adjust my strategies.

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

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

> > 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 totally agree.

> 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.
I think that the principle difference between the two is the type of
component that each can manage.  Within Phoenix, we can create components
that offer totally unique work interfaces, which clients i.e. other SARs,
can lookup using ServiceManager and invoke.  Within Catalina, the work
interface can never truly be more than that of a Servlet, which does not
allow clients, other Servlets, to access directly by interface.

>
> > 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.
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
accomplished this by writing a class that is Avalon based which delegates to
objects that wrap Catalina objects.  As the Avalon-based object move through
its lifecycle, it delegates the lifecycle to Catalina through the wrappers.



> > 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 :)
More people use Servlets than use Phoenix and is therefore a recognized
standard.  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.






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