Re: [avalon-http] SessionManager

[Stephen McConnell]

Timothy Bennett wrote:

"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...
Its just a matter of effort.  A servlet is similar to a component in 
that it is assigned a logger, it receives a context object that may be 
populated with stuff declared in a web.xml file, and it can grag stuff 
in via JNDI.  Within Merlin we can customize the lifecycle so that the 
servlet is 100% spec compliant - plus - we can provide Avalon extras.  
Making deployment 100% compliant means more effor in mapping servlet 
spec constructs in to composition meta-model - but is doable.  I would 
imagine an initial cut would be based on classic Avalon directives - and 
then a progressive process of enabling compliance.



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.  

Non-avalon aware apps is easy - we just delegate to jetty - its also a 
requirement because there a lot of services that are simply bundled in a 
webapp as a deployment solution.

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.
Yep - here we are touching on the service and context access approaches 
the extend whet jetty is providing:

* via servlet context (derived from @avalon directive)
* via JNDI if configured
* via Avalon context if requested
The important thing is providing the serrvlet service resolution in a 
totally clean approach consitent wit the spec. Beyond that is sugar.

Cheers, Steve.





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]