Ulrich's MyServlet seems very similar to the idea of allowing Struts Actions to implement Avalon lifecycles:
class MyAction extends Action
implements Serviceable, Initializable, ...
Not quite, I want to host in an Avalon container, the above would be hosted on a Servlet Server (which in turn could be hosted in an Avalon container, but then things would become too complicated IMHO).
Okay, let's see if I can summarize the discussion into a set of use cases:
1. Access to Avalon Container from within webapp component:
In this case, the webapp component itself is not an avalon service but
is just a normal Servlet or similar component hosted by a servlet container. Possible solutions:
a) Contextual Access: the Avalon container is loaded into the servlet or
application context
b) Remote Access: the Avalon container is accessed via JNDI or similar protocol.
Maybe it would be nice to have the latter option, but I don't think it's good design. We could always use (Alt)RMI, if we just wanted a physical connection and didn't care about elegance of design and performance.
I want to point out that only the first use case allows much portability between servlet containers and application servers. The second case is the beginnings of an Avalon web framework. The real trick would be to allow access to Avalon services and support for Avalon lifecycles while not tying the application to any particular server or container.
I feel I should also mention that there are a couple web frameworks already based on Avalon: - Cocoon (http://coccon.apache.org) - Keel (http://keelframework.org/) - Turbine (http://jakarta.apache.org/turbine) [will be based on Avalon?]
These are not web frameworks, they are web application frameworks. I think the term web framework is a bit misleading, because all we're really talking about here is HTTP support for Avalon.
Since there already is a Java wrapper around HTTP (ServletRequest and ServletResponse classes from the Servlet API), I would think these could be used instead of inventing a new abstraction. Would make it easy for servlet developers, too.
Web application frameworks, such as the ones you mentioned above, would be possible candidates to use Avalon's HTTP support (if they have any interest at all in Avalon, that is).
A web application framework like Cocoon could be distributed as a WAR for deployment in Tomcat (as they do now) and additionally as a SAR (or whatever) for deployment in an Avalon container. In both cases Cocoon relies on getting the HTTP request passed in from an external source and that someone will handle the HTTP response that Cocoon creates. In the first case it would be Tomcat's responsibility to create and handle these objects according to the Servlet API and in the second case it would be the Avalon container's responsiblity.
I don't know how much of the Servlet API would have to be supported to make it worthwile for, say, Cocoon. Of course no one wants to write another Tomcat for Avalon. But maybe much of the needed code is already there within Apache (Coyote?) and just needs to be repackaged/rewrapped.
cheers,
Ulrich
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
