geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Possible workspace for jetty 6 work and other jee5 stuff
Date Sun, 24 Sep 2006 13:44:40 GMT
On 23/09/2006, at 5:25 PM, David Jencks wrote:

>
> On Sep 22, 2006, at 6:38 PM, Gianny Damour wrote:
>
>> On 23/09/2006, at 11:06 AM, David Jencks wrote:
>>
>>>
>>> I haven't looked into the wadi stuff yet.  I believe greg has  
>>> committed the changes I wanted so we can import and export  
>>> sessions, but I haven't hooked up to them yet.
>> Greg has added addSession(Session session, boolean created) and  
>> removeSession(Session session, boolean invalidate) which do  
>> exactly that. It seems that there is a compilation issue with  
>> Jetty6 TransformingWebAppClassLoader.getResources overrides the  
>> final method ClassLoader. getResources and hence it is not  
>> possible to build jetty6 from trunk.
>
> I was seeing jetty 6 test failures but not this problem.  On the  
> other hand codehaus svn doesn't seem to be available right now here.
My bad. I was trying to compile with 1.4 and Jetty6 requires 1.5,  
where ClassLoader.getResources is no more final. I also see these  
test failures.

>>
>> I am still investigating why the console is not working and I am  
>> stuck: this works on my box and after a review of the code I do  
>> not see where the problem could be. Do you have any idea how I  
>> could proceed (I debugged end-to-end the handling of a request and  
>> I do not really see a problem)?
>
> I couldn't see where the problem was being introduced either, but I  
> get it consistently.  I'll see if I can figure out what is going  
> on.... or maybe we can just move to jetty 6 :-)
Many thanks for the fix. I really do not understand why I was not  
able to reproduce.

>
>
> BTW I noticed the geronimo-clustering-wadi module has a dependency  
> on geronimo-jetty.  This is going to make it hard to use with  
> jetty6.  Is there some reasonable way to eliminate that dependency?
I see two ways of doing that:
1. we move WADIClusteredHandleInterceptor currently in geronimo- 
clustering-wadi in its own module. geronimo-clustering-wadi loses its  
dependency on geronimo-jetty and the new module depends on geronimo- 
jetty. To support Jetty6, this new module is duplicated and the new  
copy depends on geronimo-jetty6; or
2. we try to extract a more generic interface from HandleInterceptor  
and we move it to geronimo-clustering. geronimo-clustering-wadi  
implements this extracted interface and loses its dependency on  
geronimo-jetty.

I would prefer 1. and do 2. when we add support for Tomcat  
clustering, if this is a good approach.

In the case of 1., the new WADIClusteredHandleInterceptor must  
implement the Jetty6 AbstractClusteredHandleInterceptor.

On another front, I have progressed further the WADI integration:  
worker name, i.e. hint for sticky load balancing, is re-enabled; and  
Session are imported and exported via the Jetty6 convenience methods.  
I had to add a new constructor to AbstractSessionManager.Session such  
that it is easier to create a Session with a given ID (required in  
the case of an inbound Session migration event). I will send an email  
to the Jetty mailing list to see if this convenience constructor can  
be added.

Thanks,
Gianny

>
> thanks
> david jencks
>


Mime
View raw message