> -----Original Message-----
> From: Ulrich Mayring [mailto:[EMAIL PROTECTED]
> Unico Hommes wrote:
> >
> > class MyServlet extends HttpServlet implements Serviceable
>
> I like this approach:
>
> class MyServlet extends AbstractLogEnabled
> implements Serviceable, Configurable, ... , WebEnabled
>
Ulrich's MyServlet seems very similar to the idea of allowing Struts Actions
to implement Avalon lifecycles:
class MyAction extends Action
implements Serviceable, Initializable, ...
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.
2. Avalon Web Enabled Components:
In this case, the component _is_ an Avalon service, hosted in an Avalon
Container. The container provides access to web services such as the
HTTP reply and requests (via HTTPClient or Servlet reply/requests).
This could be handled in a number of ways:
a) A Servlet (or webapp component like a Struts Action) which implements
Avalon lifecycle methods
b) An Avalon service which implements a "WebEnabled" lifecycle extension
In either case you would need the Avalon container to be either embedded in
the webapp framework or have the container (or the block) provide support
for WebEnabled and Servlet lifecycle extensions. This brings us to the
third use case:
3. Avalon Servlet Container:
Either a block or a set of container extensions which would provide
support of the Servlet API. Essentially a light weight servlet
container.
Could also supply support for Avalon "WebEnabled" components listed
above.
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?]
And from what I understand WebWork2 uses XWork which has similarities with
Avalon (http://www.opensymphony.com:8668/space/WebWork2)
Okay, did I miss anything? Questions? Comments?
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
