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