Re: [5] New Coyote Branch

2002-08-02 Thread costinm

On 2 Aug 2002, Bob Herrmann wrote:

> Adding to repository "jakarta-tomcat-connectors" a directory;
> 
>   coyote/src/java/org/apache/coyote5/

You mean:
coyote/src/java/org/apache/coyote/tomcat5 

> and in coyote5 the Request and Response classes implement the interfaces

tomcat4 Request/Response - yes. 

coyote/Request and coyote/Response has nothing to do with the servlet
interfaces, they are low-level ( use MessageBytes instead of Strings,
etc ).

> I am looking to add methods login(Username,Password), login(X590Cert..),
> logout() to the Request class (and jakarta-serveletapi-5) as per the
> Serlvet 2.4 working groups latest recommendation.  I will also move the
> "setCharacterEncoding()" and "getContentType()" to the tomcat5 (and out
> of tomcat4) if I understand this all correctly.

What ? I missed that one. Well, if it is in the spec you'll have to add 
it... 

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




[5] New Coyote Branch

2002-08-02 Thread Bob Herrmann


So to ensure I understand, the "New Coyote Branch" means

Adding to repository "jakarta-tomcat-connectors" a directory;

  coyote/src/java/org/apache/coyote5/

which initially is a copy of 

  coyote/src/java/org/apache/coyote4/

and in coyote5 the Request and Response classes implement the interfaces
in "jakarta-servletapi-5" and build.xml conditionally compiles the right
thing and some factory somewhere knows which classes to switch in? (When
being used at runtime by tomcat 5.)

I am looking to add methods login(Username,Password), login(X590Cert..),
logout() to the Request class (and jakarta-serveletapi-5) as per the
Serlvet 2.4 working groups latest recommendation.  I will also move the
"setCharacterEncoding()" and "getContentType()" to the tomcat5 (and out
of tomcat4) if I understand this all correctly.

Cheers,
-bob




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




Re: New coyote branch

2002-08-01 Thread costinm

What about this: 

- make the changes in CoyoteRequest 
- after we cleanup/enhance the ActionCode and hooking in 
coyote - we use it instead ( and support connector attributes
and lazy eval )

BTW, it would be quite interesting to have this 'close' to
the semantics of JMX notifications.

It is nice to have all requests as mbeans  - not for admin
but for instrumentation ( what requests are active at each 
moment, statistical data, etc - eventually some methods like
interrupt ). Attribute changes ( at context/session level ) 
could be bridged into jmx notifications. 
 

Costin

On Thu, 1 Aug 2002, Craig R. McClanahan wrote:

> 
> 
> On Thu, 1 Aug 2002 [EMAIL PROTECTED] wrote:
> 
> > Date: Thu, 1 Aug 2002 14:40:33 -0700 (PDT)
> > From: [EMAIL PROTECTED]
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: New coyote branch
> >
> > On Thu, 1 Aug 2002, Craig R. McClanahan wrote:
> >
> > > o.a.coyote.Request doesn't have setAttribute() or replaceAttribute()
> > > methods, so I don't see why it would be affected -- only the Servlet 2.4
> > > version of CoyoteRequest would seem to matter.
> >
> > ???
> >
> > Are we talking about the same thing ?
> > j-t-c/coyote/src/java/org/apache/coyote/Request.java does have
> > setAttribute().
> 
> Well it does now ... it didn't in the version I had checked out (with a
> sticky tag so I wasn't seeing all he recent changes) :-).
> 
> I see what you're talking about now -- but I'd bet you can still isolate
> the changes into CoyoteRequest by putting some stuff into
> setCoyoteRequest() to fire the event notifications.
> 
> >
> > The request attributes are set by the connector - SSL stuff. For
> > lazy evaluation we also need a getAttribute callback.
> >
> > I don't think coyote or connectors will replace attributes - at least
> > the attributes in 2.3 are only set once ( and in theory before the
> > request is served ).
> >
> 
> That makes sense.
> 
> >
> > > I don't understand what these have to do with the
> > > ServletRequest.removeAttribute() and ServletRequest.setAttribute() method
> > > implementations.
> >
> > If you want to be notified when an attribute is added to the request -
> > it's not only ServletRequest.setAttribute that does that.
> >
> > Again, if the spec requires notifications _only_ for attribute
> > changes initiated by a servlet - then it's fine to implement this
> > only in ServletRequest.setAttribute().
> >
> > Costin
> >
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


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




Re: New coyote branch

2002-08-01 Thread Craig R. McClanahan



On Thu, 1 Aug 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 1 Aug 2002 14:40:33 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: New coyote branch
>
> On Thu, 1 Aug 2002, Craig R. McClanahan wrote:
>
> > o.a.coyote.Request doesn't have setAttribute() or replaceAttribute()
> > methods, so I don't see why it would be affected -- only the Servlet 2.4
> > version of CoyoteRequest would seem to matter.
>
> ???
>
> Are we talking about the same thing ?
> j-t-c/coyote/src/java/org/apache/coyote/Request.java does have
> setAttribute().

Well it does now ... it didn't in the version I had checked out (with a
sticky tag so I wasn't seeing all he recent changes) :-).

I see what you're talking about now -- but I'd bet you can still isolate
the changes into CoyoteRequest by putting some stuff into
setCoyoteRequest() to fire the event notifications.

>
> The request attributes are set by the connector - SSL stuff. For
> lazy evaluation we also need a getAttribute callback.
>
> I don't think coyote or connectors will replace attributes - at least
> the attributes in 2.3 are only set once ( and in theory before the
> request is served ).
>

That makes sense.

>
> > I don't understand what these have to do with the
> > ServletRequest.removeAttribute() and ServletRequest.setAttribute() method
> > implementations.
>
> If you want to be notified when an attribute is added to the request -
> it's not only ServletRequest.setAttribute that does that.
>
> Again, if the spec requires notifications _only_ for attribute
> changes initiated by a servlet - then it's fine to implement this
> only in ServletRequest.setAttribute().
>
> Costin
>

Craig


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




Re: New coyote branch

2002-08-01 Thread costinm

On Thu, 1 Aug 2002, Craig R. McClanahan wrote:

> o.a.coyote.Request doesn't have setAttribute() or replaceAttribute()
> methods, so I don't see why it would be affected -- only the Servlet 2.4
> version of CoyoteRequest would seem to matter.

???

Are we talking about the same thing ?
j-t-c/coyote/src/java/org/apache/coyote/Request.java does have 
setAttribute().

The request attributes are set by the connector - SSL stuff. For 
lazy evaluation we also need a getAttribute callback. 

I don't think coyote or connectors will replace attributes - at least
the attributes in 2.3 are only set once ( and in theory before the 
request is served ). 


> I don't understand what these have to do with the
> ServletRequest.removeAttribute() and ServletRequest.setAttribute() method
> implementations.

If you want to be notified when an attribute is added to the request - 
it's not only ServletRequest.setAttribute that does that.

Again, if the spec requires notifications _only_ for attribute
changes initiated by a servlet - then it's fine to implement this
only in ServletRequest.setAttribute().

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread Craig R. McClanahan



On Thu, 1 Aug 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 1 Aug 2002 09:51:09 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: New coyote branch
>
> On Thu, 1 Aug 2002, Craig R. McClanahan wrote:
>
> > > >  Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't 
>look like
> > > > jakarta-tomcat-connectors has been branched yet. I checked the archives
> > > > and saw the vote results where it was decided that the HEAD of
> > > > jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would
> > > > be branched.
> > > >
> > > > I'd like to request that this branch be created. Remy?
> > > >
> > > > The reason I ask is that I'm working on a servlet 2.4 servlet request
> > > > events implementation which involves modifying CoyoteRequest.java.
> > >
> > > What kind of changes ? Coyote should be independent of servlet,
> > > if you need to add something you can add it to the main branch.
> > >
> > > 2.4 should be backward compatible - so it shouldn't change any
> > > behavior.
> > >
> >
> > Servlet 2.4 introduces attribute change listeners on the ServletRequest
> > interface, analogous to the ones on sessions and contexts.  The
> > implementation of these features has to be in the concrete ServletRequest
> > instance's removeAttribute() and setAttribute() methods.  See the public
> > draft spec for details.
> >
> > In the current Catalina archtecture, the connector provides this concrete
> > class -- and in the case at hand, it's CoyoteRequest.
>
> Few alternatives to branching:
> - move CoyoteRequest to jakarta-catalina ( we could also move Tomcat33
> classes in tomcat33 cvs ). We agreed that tomcat depends on coyote,
> not the reverse.
> - create a tomcat5 dir with the new methods.
>
> One important note: if the spec wants notification for _all_ request
> attribute changes, we'll also need to implement this in coyote.Request.
> Currently that require 2 new ActionCodes.
>

o.a.coyote.Request doesn't have setAttribute() or replaceAttribute()
methods, so I don't see why it would be affected -- only the Servlet 2.4
version of CoyoteRequest would seem to matter.

> We should also add an ActionCode for _get_ attribute, to support 'lazy'
> evaluation of some attributes.
>
> 3.3 uses a get/setInfo hook - it works for both Request and Context
> attributes.
>

I don't understand what these have to do with the
ServletRequest.removeAttribute() and ServletRequest.setAttribute() method
implementations.

> Costin
>

Craig


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




Re: New coyote branch

2002-08-01 Thread costinm

Justy,

You'll also need to change coyote.Request - since it is the real
attribute store.

As I mentioned, you'll need to add 2 ActionCodes. That's the correct
implementation IMHO ( independent of where you put the 
CoyoyteRequest ). 

If it can wait a bit - I can help. 

Costin

On Thu, 1 Aug 2002, Justyna Horwat wrote:

> Craig summed it up well in his e-mail. The attribute change listeners 
> are explicitly required by the proposed servlet 2.4 spec. I need to 
> modify the ServletRequest instance which happens to be present in Coyote.
> 
> Both Costin and Remy brought up issues related to as well as good 
> solutions to branching. I like Remy's idea of creating a Tomcat 5 
> adapter which would be consistent with the Tomcat 3 & 4 adapters.
> 
> (The javax.servlet API changes I made to jakarta-servletapi-5 will not 
> affect whether Coyote builds or not. These are additions with no 
> modification to the existing API's. I submitted a patch for these 
> additions a couple of days ago but since there's no implementation you 
> won't see any changes to the behavior.)
> 
> Justy
> 
> Patrick Luby wrote:
> 
> > Justy,
> >
> > I verified that Tomcat 5 builds and runs and most of the servlet tests 
> > in Watchdog pass with the current Coyote connector. Of course, I don't 
> > think any of the changes in the proposed 2.4 spec have been 
> > implemented yet.
> >
> > Are there any changes to Coyote that are explicitly or implicitly 
> > required by the spec? Or is the problem that API changes to the 
> > javax/servlet classes that are required by the new spec will cause 
> > Coyote to not build?
> >
> > Thanks,
> >
> > Patrick
> >
> > [EMAIL PROTECTED] wrote:
> >
> >> On Wed, 31 Jul 2002, Peter Lin wrote:
> >>
> >>
> >>> Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it 
> >>> doesn't look like jakarta-tomcat-connectors has been branched yet. I 
> >>> checked the archives and saw the vote results where it was decided 
> >>> that the HEAD of jakarta-tomcat-connectors will be used for Tomcat 5 
> >>> and Coyote 1.0 would be branched.
> >>>
> >>> I'd like to request that this branch be created. Remy?
> >>>
> >>> The reason I ask is that I'm working on a servlet 2.4 servlet 
> >>> request events implementation which involves modifying 
> >>> CoyoteRequest.java.
> >>
> >>
> >>
> >> What kind of changes ? Coyote should be independent of servlet,
> >> if you need to add something you can add it to the main branch.
> >> 2.4 should be backward compatible - so it shouldn't change any behavior.
> >> Costin
> >>
> >>
> >> -- 
> >> To unsubscribe, e-mail:   
> >> 
> >> For additional commands, e-mail: 
> >> 
> >
> >
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread Justyna Horwat

Craig summed it up well in his e-mail. The attribute change listeners 
are explicitly required by the proposed servlet 2.4 spec. I need to 
modify the ServletRequest instance which happens to be present in Coyote.

Both Costin and Remy brought up issues related to as well as good 
solutions to branching. I like Remy's idea of creating a Tomcat 5 
adapter which would be consistent with the Tomcat 3 & 4 adapters.

(The javax.servlet API changes I made to jakarta-servletapi-5 will not 
affect whether Coyote builds or not. These are additions with no 
modification to the existing API's. I submitted a patch for these 
additions a couple of days ago but since there's no implementation you 
won't see any changes to the behavior.)

Justy

Patrick Luby wrote:

> Justy,
>
> I verified that Tomcat 5 builds and runs and most of the servlet tests 
> in Watchdog pass with the current Coyote connector. Of course, I don't 
> think any of the changes in the proposed 2.4 spec have been 
> implemented yet.
>
> Are there any changes to Coyote that are explicitly or implicitly 
> required by the spec? Or is the problem that API changes to the 
> javax/servlet classes that are required by the new spec will cause 
> Coyote to not build?
>
> Thanks,
>
> Patrick
>
> [EMAIL PROTECTED] wrote:
>
>> On Wed, 31 Jul 2002, Peter Lin wrote:
>>
>>
>>> Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it 
>>> doesn't look like jakarta-tomcat-connectors has been branched yet. I 
>>> checked the archives and saw the vote results where it was decided 
>>> that the HEAD of jakarta-tomcat-connectors will be used for Tomcat 5 
>>> and Coyote 1.0 would be branched.
>>>
>>> I'd like to request that this branch be created. Remy?
>>>
>>> The reason I ask is that I'm working on a servlet 2.4 servlet 
>>> request events implementation which involves modifying 
>>> CoyoteRequest.java.
>>
>>
>>
>> What kind of changes ? Coyote should be independent of servlet,
>> if you need to add something you can add it to the main branch.
>> 2.4 should be backward compatible - so it shouldn't change any behavior.
>> Costin
>>
>>
>> -- 
>> To unsubscribe, e-mail:   
>> 
>> For additional commands, e-mail: 
>> 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread costinm

On Thu, 1 Aug 2002, Craig R. McClanahan wrote:

> > >  Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look 
>like
> > > jakarta-tomcat-connectors has been branched yet. I checked the archives
> > > and saw the vote results where it was decided that the HEAD of
> > > jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would
> > > be branched.
> > >
> > > I'd like to request that this branch be created. Remy?
> > >
> > > The reason I ask is that I'm working on a servlet 2.4 servlet request
> > > events implementation which involves modifying CoyoteRequest.java.
> >
> > What kind of changes ? Coyote should be independent of servlet,
> > if you need to add something you can add it to the main branch.
> >
> > 2.4 should be backward compatible - so it shouldn't change any
> > behavior.
> >
> 
> Servlet 2.4 introduces attribute change listeners on the ServletRequest
> interface, analogous to the ones on sessions and contexts.  The
> implementation of these features has to be in the concrete ServletRequest
> instance's removeAttribute() and setAttribute() methods.  See the public
> draft spec for details.
> 
> In the current Catalina archtecture, the connector provides this concrete
> class -- and in the case at hand, it's CoyoteRequest.

Few alternatives to branching:
- move CoyoteRequest to jakarta-catalina ( we could also move Tomcat33 
classes in tomcat33 cvs ). We agreed that tomcat depends on coyote, 
not the reverse.
- create a tomcat5 dir with the new methods.

One important note: if the spec wants notification for _all_ request
attribute changes, we'll also need to implement this in coyote.Request.
Currently that require 2 new ActionCodes. 

We should also add an ActionCode for _get_ attribute, to support 'lazy'
evaluation of some attributes.

3.3 uses a get/setInfo hook - it works for both Request and Context 
attributes.

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread Craig R. McClanahan



On Thu, 1 Aug 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 1 Aug 2002 07:10:09 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: New coyote branch
>
> On Wed, 31 Jul 2002, Peter Lin wrote:
>
> >  Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look 
>like
> > jakarta-tomcat-connectors has been branched yet. I checked the archives
> > and saw the vote results where it was decided that the HEAD of
> > jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would
> > be branched.
> >
> > I'd like to request that this branch be created. Remy?
> >
> > The reason I ask is that I'm working on a servlet 2.4 servlet request
> > events implementation which involves modifying CoyoteRequest.java.
>
> What kind of changes ? Coyote should be independent of servlet,
> if you need to add something you can add it to the main branch.
>
> 2.4 should be backward compatible - so it shouldn't change any
> behavior.
>

Servlet 2.4 introduces attribute change listeners on the ServletRequest
interface, analogous to the ones on sessions and contexts.  The
implementation of these features has to be in the concrete ServletRequest
instance's removeAttribute() and setAttribute() methods.  See the public
draft spec for details.

In the current Catalina archtecture, the connector provides this concrete
class -- and in the case at hand, it's CoyoteRequest.

> Costin
>

Craig


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




Re: New coyote branch

2002-08-01 Thread Patrick Luby

Justy,

I verified that Tomcat 5 builds and runs and most of the servlet tests 
in Watchdog pass with the current Coyote connector. Of course, I don't 
think any of the changes in the proposed 2.4 spec have been implemented yet.

Are there any changes to Coyote that are explicitly or implicitly 
required by the spec? Or is the problem that API changes to the 
javax/servlet classes that are required by the new spec will cause 
Coyote to not build?

Thanks,

Patrick

[EMAIL PROTECTED] wrote:
> On Wed, 31 Jul 2002, Peter Lin wrote:
> 
> 
>> Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like 
>>jakarta-tomcat-connectors has been branched yet. I checked the archives 
>>and saw the vote results where it was decided that the HEAD of 
>>jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
>>be branched.
>>
>>I'd like to request that this branch be created. Remy?
>>
>>The reason I ask is that I'm working on a servlet 2.4 servlet request 
>>events implementation which involves modifying CoyoteRequest.java.
> 
> 
> What kind of changes ? Coyote should be independent of servlet,
> if you need to add something you can add it to the main branch. 
> 
> 2.4 should be backward compatible - so it shouldn't change any 
> behavior. 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 

Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread costinm

On Wed, 31 Jul 2002, Peter Lin wrote:

>  Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like 
> jakarta-tomcat-connectors has been branched yet. I checked the archives 
> and saw the vote results where it was decided that the HEAD of 
> jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
> be branched.
> 
> I'd like to request that this branch be created. Remy?
> 
> The reason I ask is that I'm working on a servlet 2.4 servlet request 
> events implementation which involves modifying CoyoteRequest.java.

What kind of changes ? Coyote should be independent of servlet,
if you need to add something you can add it to the main branch. 

2.4 should be backward compatible - so it shouldn't change any 
behavior. 

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-08-01 Thread Remy Maucherat

Justyna Horwat wrote:
> I looked in jakarta-tomcat-connectors and it doesn't look like 
> jakarta-tomcat-connectors has been branched yet. I checked the archives 
> and saw the vote results where it was decided that the HEAD of 
> jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
> be branched.
> 
> I'd like to request that this branch be created. Remy?
> 
> The reason I ask is that I'm working on a servlet 2.4 servlet request 
> events implementation which involves modifying CoyoteRequest.java.

There are a couple issues which should be fixed first if possible (see 
the i18n bugs in BZ).

Note that the branch will be created when we actually start to make API 
changes. For the new API support, I was planning to add a new Tomcat 5 
adapter (next to the Tomcat 3 and Tomcat 4 adapters).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: New coyote branch

2002-07-31 Thread Peter Lin


 
I believe remmy is on vacation and is moving to france :)
I guess someone else will have to do it.
 
peter
 Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like 
jakarta-tomcat-connectors has been branched yet. I checked the archives 
and saw the vote results where it was decided that the HEAD of 
jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
be branched.

I'd like to request that this branch be created. Remy?

The reason I ask is that I'm working on a servlet 2.4 servlet request 
events implementation which involves modifying CoyoteRequest.java.

Thanks!

Justy



--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do You Yahoo!?
Yahoo! Health - Feel better, live better


New coyote branch

2002-07-31 Thread Justyna Horwat

I looked in jakarta-tomcat-connectors and it doesn't look like 
jakarta-tomcat-connectors has been branched yet. I checked the archives 
and saw the vote results where it was decided that the HEAD of 
jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
be branched.

I'd like to request that this branch be created. Remy?

The reason I ask is that I'm working on a servlet 2.4 servlet request 
events implementation which involves modifying CoyoteRequest.java.

Thanks!

Justy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: