Timothy Bennett wrote:
New thread started from thread entitled [avalon-jetty] Status update
"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
I think we have to fix the SessionManager exposure first. The problem is that this component will probabaly get a reasonable level of attention and as such - we are just going to cause breakages in the near future.
If I can understand the problem a bit more clearly, then maybe I could make some changes in the next few days.
To help, here is one of your post from the same thread:
I did had a problem concerning the SessionManager that may have crept in as a result of the spi/impl separation. The value passed to the web-app is a jetty SessionManager but the value acquired from the service manager is a http.SessionManager (resulting in a class cast exception). I've changed the http.SessionManager to extend jetty.SessionManager in the SPI package as a temporary solution to get things going.
Hmmmmmm... Can you give me code example of where/when you were getting a cast exception? I wasn't having this problem, nor can I understand under what circumstances you were trying to do a class cast.
Sure.
The SessionManager interface is defined as follows:
package org.apache.avalon.merlin.http;
public interface SessionManager {}In JettyWebServer which implements Serviceable
/**
* stuff
* @avalon.dependency type="org.apache.avalon.merlin.http.SessionManager" version="1.1"
*/
public void service(ServiceManager manager)
Based on @avalon.dependency, Merlin will generate a xinfo descriptor and a SessionManager appliance will be assigned within the service manager applied to the JettyWebServer. However, down in the setSessionManager(HttpContext context) method, the following code is invoked:
String clazzName = org.apache.avalon.merlin.http.SessionManager.class.getName();
servletHandler.setSessionManager((SessionManager) m_serviceManager.lookup(clazzName));
The casting reference to SessionManager is not org.apache.avalon.merlin.http.SessionManager, instead its org.mortbay.jetty.servlet.SessionManager - bingo - ClassCastException because http.SessionManager does not extend servlet.SessionManager (at least it didn't but now it does but that screws up the API because we are exposing a jetty class).
However - we will need to sort this out in order for the SPI to be independent of the jetty implementation (which I think we can do by building a session instance dynamically based on meta-info pulled in from the servlet class) and maybe through this we can eliminate the need for servlet specific session classes which would bring things down to just the servlet class and @avalon tags.
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.
I'm still digging though Jetty docs with this in mind.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
