However - the service interface is the only visible aspect that is exposed. The implementation is isolated behind a proxy that is returned on invocation of ServiceManager.lookup( role ).


Stephen.


Timothy Bennett wrote:


"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]


Timothy Bennett wrote:



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).




The package as coded was meant to keep the Jetty-specific stuff in the impl and keep the Jetty stuff out of the spi side of things. Here is how it is supposed to work, and maybe I screwed up the doclets or something:

o.a.a.m.http.SessionManager is a place-holder empty interface in the api.
That looks fine.  In the impl side, the o.a.a.m.http.AvalonSessionManager
implements this avalon-http SessionManager interface, BUT extends the
org.mortbay.jetty.servlet.AbstractSessionManager class.  This
AvalonSessionManager is a merlin component and is a subclass of Jetty's
SessionManager.  But we don't use this component directory in any
application we assembly.  We construct our own "custom" extension of
AvalonSessionManager that is also a merlin component that overrides the
service() lifecycle method (just calling super(...)), so that our custom
SessionManager (see o.a.a.m.http.example.ExampleSessionManager) can have
doclet tags exposing the services that we are dependent on.  But since this
component is an extension of AvalonSessionManager, it is also a subclass of
Jetty's AbstractSessionManager.

Now the meta-info should tie the service dependency on
o.a.a.m.http.SessionManager in JettyWebServer to the component
implementation of that service that we define in our block.xml (and doclets)
to our customized extension of AvalonSessionManager (such as the
ExampleSessionManager).

The block.xml shows this intention:

   <!-- Session Manager sub-class -->
   <component name="session-mgr"
class="org.apache.avalon.merlin.http.example.ExampleSessionManager"
activation="startup"/>

   <!-- Web Server -->
   <component name="avalon-jetty"
class="org.apache.avalon.merlin.http.JettyWebServer" activation="startup">
       <configuration>
           <Listener port="8080"/>
           <Context name="example" path="/example/*">
               <Servlet name="Example" path="/servlets/*"
classname="org.apache.avalon.merlin.http.example.ExampleServlet"/>
           </Context>
       </configuration>
   </component>

Through the doclet's the JettyWebServer component should resolve its service
dependency to the avalon-http SessionManager to the ExampleSessionManager
implementation (which is also a Jetty Session Manager subclass because it
extends AvalonSessionManager).

The o.a.a.m.http.SessionManager interface SHOULD NOT extend Jetty Session
Manager.  That is what the AvalonSessionManager in the impl package is
supposed to do.




--------------------------------------------------------------------- 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]



Reply via email to