"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Timothy Bennett wrote: > > > > >I would like to get rid of having to extend the AvalonSessionManager for > >each "application" that uses avalon-http. This is an artifact from Henson's > >block, and basically provides a mechanism for the Jetty Session Manager to > >"carry" a ServiceManager instance that knows about the dependent services > >you want the servlet(s) to have access to. If there's a better and cleaner > >way of getting the service dependencies into the servlet container's session > >manager, then I'm all for that. Let's noodle on it and discuss it. > > > > Some very initial thoughts - two possible approaches: > > 1. servlet is a component > 2. context is a component > > With "servlet is a component" scenario what we want is to be able to > customize the way the servlet is deployed. Instead of following the > classic Avalon deployment cycle we want the appliance the is managing > the servlet type to construct a SessionManager and configure everything > based on @avalon declarations in the servlet class definition. This > would be possible if we have a factory oriented applicance). The > appliance would instantiate a factory component and use the factory to > deploy the servlet. > > However, this is not totally clean because we don't want to expose the > servlet to other components. In effect we want the web-server context > to to take care of all of this - enter "context is a component". This > approach is much nicer because we can define a component that exposes a > context interface, consumes a web-server (into which context instances > are registered), and as part of its deployment it reads meta info/data > about servlets and deploys these into itself. In addition, it exposes > operation to add, enumerate and remove servlets via its service interface. > > E.g.: > > <container name="demo"> > > <!-- create the web server --> > <component name="server" > class="org.apache.avalon.merlin.http.JettyWebServer"> > <configuration> > <Listener port="8080"/> > </configuration> > </component> > > <!-- create a web context (depends on web-server) --> > <component name="context" > class="org.apache.avalon.merlin.http.JettyWebServer"> > <configuration> > <Servlet name="Example" path="/servlets/*" > > classname="org.apache.avalon.merlin.http.example.ExampleServlet"/> > </configuration> > </component> > > </container> > > But - the ultimate scenario is to seperate the servlet and the context - > i.e. we construct the servlet instance, its dependent on a context, on > initialization we add it to a servlet holder then let jetty do its > stuff. All we need to do is to figure out if we can replace the servlet > instance factory in jetty. In this scenario Merlin is responsible for > the diirect servlet instance depoyment and decommissioning - the perfect > scenario. >
Two thoughts: First, this seems to "break" standard j2ee servlet compliance, and basically creates "merlin-ized servlets". But, I guess I've already broken with j2ee servlet compliance by wanting to get Avalon component references through the ServiceManager from inside my servlet. I can't very well go off and deploy this servlet on some standalone version of Tomcat or Jetty. So, I guess that really a non-issue... Second, I do think that I'd like the option of deploying non-Avalon aware web apps inside my merlin-embedded servlet container. For instance, I might have a merlin container that has a couple of blocks -- say the hsqldb component and the avalon-http component. The database is just listening on a port -- no real service interface here -- the container is just managing the lifecycle of the database server. But I might want to deploy a generic web application that makes JDBC calls into the database and has some JSP and servlets that presents the user with some kind of WUI. This web app (WAR) could easily be deployed in a standalone Tomcat container and using JDBC to connect to some Oracle or MySQL server. But re-deployed in my avalon-http component, it could be configured instead to connect to my also merlin-embedded HSQL server using the same JDBC calls in the servlet code. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
