Ulrich Mayring wrote: > > > > 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. >
It started out as discussion about web application frameworks, but I agree that HTTP support for Avalon is a most interesting proposition and the one that caught my eye. The possibility of WebEnabled components without the need for a bulky servlet engine would be brilliant IMHO. > 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. I think some of the abstractions could be properly reused but I don't necessarily believe the Servlet API has to be reused itself. For instance in an Avalon environment it does not make much sense to go out of our way to support ServletConfig class and Servlet.init() method because with Avalon we have a much more elegant solution to those aspects in Configurable and Initializable interfaces. As for request and response objects, these are only simple data wrappers that could easily live in the Avalon namespace. > > 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. > Exactly, Avalon web connectors, deliver the full range of Web based clients right to your component's doorstep :) > cheers, > > Ulrich > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
