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