avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Phoenix and the Web
Date Mon, 30 Sep 2002 23:18:29 GMT
Ulrich,

Jo! not has been ported to the sevak project. If you have phoenix/ and 
apps/ in adjascent directories you can deploy a test SAR for Jo! with...
  ant -buildfile jo.xml install

Similarly Catalin's test SAR can be installed with ...
  ant -buildfile jetty.xml install

When we get Jetty working, it will be deployable with ...
  ant -buildfile jetty.xml install

You will have to have built phoenix via the dist-lite target first.

Regards,

- Paul



> Hello folks,
>
> given my recent (unsuccessful) endeavour of getting Jo! to run under 
> Phoenix, I began to wonder what a connection between Phoenix and the 
> Web could/should look like. I think it is imperative for a server 
> application framework and an applicaton server to be able to serve the 
> Web.
>
> Here are some options I can think of:
>
> 1) There is a class called PhoenixServlet, but it is labelled as 
> experimental. It does not seem to do very much either. What is its 
> purpose?
>
> 2) Jo! and Sevak can run servlets, but they have no native way to 
> communicate with other apps (except via AltRMI or similar methods). I 
> don't think it is possible to persuade the developers of Jo! or 
> Catalina to componentize their designs to accommodate Avalon/Phoenix. 
> But everything else is just a hack.
>
> 3) How about an ajpv12 or ajpv13 component? Maybe the code can be 
> nicked from Catalina and repackaged as a component. Then every Phoenix 
> app could just use that component and be fully connected to everyone 
> who supports mod_jk or mod_jserv (mainly the Apache httpd, but also 
> some other webservers).
>
> 4) MX4J already has a HTTPConnector, but it is fairly limited to JMX. 
> But we just need a way to pass control to an arbitrary app and give 
> back a response, maybe it can be done with MX4J?
>
> 5) Development of a HTTP component. It does not need to be a 
> full-blown webserver, we just need to speak HTTP. For access control, 
> URL rewriting, error handling and all those other fancy features we 
> could rely on an external webserver and assume that he makes sure to 
> forward only "safe and appropriate" HTTP requests to us for backend 
> processing. Connections have to be limited to that webserver, though. 
> Most webservers have a way to forward HTTP requests to another webserver.
>
> Any other ideas/comments? I like option 3) best.
>
> cheers,
>
> Ulrich
>




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