Hello Aaron and All!
FA> a) A Servlet (or webapp component like a Struts Action) which implements
FA> Avalon lifecycle methods
Just got an idea of how this (servlet or struts action implementing
lifecycle methods) can be implemented:
in Fortress speak:
1) we create a specialized DefaultContainer
derivative. It itself implements the following interface:
public interface ExternalComponentHousekeeper
{
void bringUp( Object component, String id );
void bringDown( Object component, String id );
}
2) we derive our Servlets not from
HttpServlet but from
public class ExternalAvalonComponentServlet extends HttpServlet
{
public void init()
{
// obtain somehow our housekeeper
// this can be done
//
// for < Servlet 2.3
// by getServlet( String name ) - we'll configure a
// special servlet to host Avalon container
//
// or a servletContextListener could hook it into
// Servlet Context (for Servlet > 2.3)
//
// or it could be obtained from JNDI
//
ExternalComponentHousekeeper ech = ...
ech.bringUp( this, getServletName() );
}
public void destroy()
{
ech.bringDown( this, getServletName() );
}
}
Same for Struts actions.
ech would bring them though all lifecycle stages.
So the components are created outside avalon contianer
but serviced within it.
The servlet name can be used to even fetch a configuration
for such external component from the regular .xconf file.
I'm in doubt here, how to delimiter the configuration for
such inside .xconf, but this is solvable.
3. Even for a container that has assembly we can have a "fake"
component this may be okay since the name of the servlet
serves as a pseudo-component-id, allowing a "personal"
assembly section to be written for it
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
