Hello Aaron, Stephen and all!
On Thu, 2003-07-03 at 12:36, Stephen McConnell wrote:
SM>
SM> I have not tried to do this but this is what I'm thinking:
SM>
SM> 1. listener gets creation event
SM> 2. listener get classname of the servlet
SM> 3. listener reads in meta-info from descriptor
SM> corlocated with servlet class
SM> 4. listener gets meta-data from its own configuration
SM> or some external source
SM> 5. listener builds artifacts form lifecycle processing
SM> of the servlet and applies stages (e.g. servicing
SM> of the servlet)
SM> 5. listener intercepts destroy even and handles
SM> decommissioning of the artifacts conosumed by the
SM> servlet
SM>
SM> Has anyone tried anything like this?
JAF> My only question is about step number 2 -- how do we get the classname?
JAF> If I understand correctly the ServletContextListener only gives us an
JAF> instance of the the servlet context and even then, only gives it to us
JAF> on the creation of the web application.
JAF> Although this would be a better way to get the service manager into the
JAF> ServletContext (compared to the little extended Struts Servlet I wrote).
1)
So it looks to me too, but as I have suggested in another mail we
still have a way out: _if_ we derive our servlet not from HttpServlet
but from a specialized Avalon-provided servlet, the
init() and destroy()
methods of this specialized servlet will be able to fetch _some_
avalon provided object from one of
* servlet context
here it may be put by
* ServletContextListener
* specialized servlet (for servlet api < 2.3)
* JNDI
* static accessor method
and this object would implement the following interface
public interface ExternalComponentHousekeeper
{
void bringUp( Object component, String id );
void bringDown( Object component, String id );
}
performing all the avalon lifecycle stages on the newly
created servlet.
2)
this appoach however has a slight drawback: we won't
be able to restart our avalon container w/o restarting
the web application.
In case of alternative approaches, e.g.
* the whole avalon container is hosted inside a single
servlet and all the access to it goes through this servlet
* ServiceManager is bound to ServletContext
and the servlets do not implement lifecycle interfaces
themselves
we are free to restart the avalon container if, for
instance, configuration changes w/o restarting the whole
web app.
However this drawback may be considered minor.
3)
The proposed approach (providing avalon specialized
servlet) may be generalized to other areas:
we may provide
* specialized Struts actions
(_if_ they have an analog of dispose() method, do they?)
* stateless EJB-s
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
