Ulrich , I am currently working on Catalina Sevak. The current project that I am working on consists of a series of services to be deployed into Phoenix. I must be able to allow webapps to access these other services...a requirement not yet implemented by Sevak. Addtionally I may need to allow these services to update/add/remove webapps that are currently deployed. The approach that I have taken so far is to create Avalon-based classes to implement the required interfaces and have these classes dynamically delegate to Tomcat-based classes using reflection. Thus far I have implemented a bootstrap mechanism that replicates the Tomcat startup script and a custom Catalina Server implementation the eliminates the standard socket-based shutdown used by Tomcat. My goal is to eventually have a custom Context class that delegates to Tomcat's StandardContext, adding functionality as needed. One such instance is in creating the ServletContext. By implementing this custom Context, I hope to be able to set things like the ServiceManager into the ServletContext as an attribute...what do you think?
> 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. I think that Web application components would like to be able to access and utilize the services of other components within Phoenix as if the Web application was itself a phoenix component. I imagine that other components might require the ability to deploy web applications, create custom Service blocks within the web server, start/stop these service blocks, etc. For example, say that I have created a phoenix service that controls an external hardware resource and want to be able to manipulate that service via a web application. I would need to create a block that depends on Sevak and has the ability to specify a webapp Context that contains references back to itself, and to specify which Host within Sevak this webapp should be deployed to. > > 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? Phoenix is an application server kernel...utilizing Phoenix as a component embedded within a Web Container does not make much sense. > > 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. If they won't componentize their design, we must create abstract wrappers to adapt the two. > > 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). You lost me here...what is the advantage? > > 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. If you are looking for a way to provide web access via Sockets, I believe such components exist within Excalibur that can be used within Phoenix. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
