tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <Larry.Isa...@sas.com>
Subject RE: 3.3: nightly, updating the parser, options
Date Thu, 21 Jun 2001 20:00:34 GMT
Costin,

I'm fine with saving these changes until after Milestone 4.
I'll add a note to the readme about the availability of
Jasper34 and how to enable it.

It would help if you could take a quick look at an NPE
that is occurring when Tomcat 3.3 is connected to Apache
with mod_jserv.  The problem is in
org.apache.tomcat.modules.mappers.DecodeInterceptor's
postReadRequest() method.  Unlike mod_jk and directly
hitting Tomcat, mod_jserv creates pathMB as a String.  If
the request contains a '%', such as HelloWorld%2Ejsp,
the handling is trigger that results in
"pathMB.resetStringValue()" being called.  The next
"pathMB.indexOf()" will NPE.  If you could find a
quick fix, I would appreciate it.  If there isn't one,
let me know and I'll proceed with Milestone 4.

Cheers,
Larry
 

> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Thursday, June 21, 2001 12:59 PM
> To: 'tomcat-dev@jakarta.apache.org'
> Subject: RE: 3.3: nightly, updating the parser, options
> 
> 
> Hi Larry,
> 
> Those options are already implemented - it's just a matter of 
> turning them
> on or off, and I wasn't targeting M4. 
> 
> There are few issues building in JDK1.1, but I think we are ok with
> building M4 this night ( with the "final" tommorow ). 
> 
> Regarding jasper34, it passes all watchdog/sanity checks - 
> but it should
> be your choice to include it or not. 
> 
> Given your vacation, I would vote for not defaulting to 
> jasper34 ( I am
> confident the refactoring was "safe" enough so far , the extra testing
> would be nice but not a necesity. )
> 
> ( let me know if there is any problem with M4, this should be 
> the biggest
> priority for today/tommorow )
> 
> 
> Costin
> 
> 
> 
> On Thu, 21 Jun 2001, Larry Isaacs wrote:
> 
> > Hi Costin,
> > 
> > I'm fine with including these if you are confident that they don't
> > contain any show stoppers and can be done quickly.  I go on vacation
> > this Saturday for a week.  As a result, I can't wait too long before
> > putting Milestone 4 together. I'm was hoping to get the bulk of the
> > files there tonight so I can fix mistakes on Friday, if needed.
> > 
> > Are we still "go" for enabling Jasper34 by default?  I have been
> > working on other small problems and haven't actually tried Jasper34
> > yet.
> > 
> > Cheers,
> > Larry
> > 
> > > -----Original Message-----
> > > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > > Sent: Thursday, June 21, 2001 4:19 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: 3.3: nightly, updating the parser, options
> > > 
> > > 
> > > Hi,
> > > 
> > > I'm working on restoring the nightly build&test, probably 
> this evening
> > > we'll have them ( I was close last night ).
> > > 
> > > Few issues, need feedback: 
> > > 
> > > - I would like to update to the latest jaxp, we are still 
> > > building with
> > > jaxp1.0 ( it's about the default build, of course you can 
> build/use
> > > whatever you want ). 
> > > 
> > > - There are few module options that are set for "backward
> > > compatibility" right now, but it would be very usefull otherwise.
> > > 
> > > One is the "autodeploy" ( detect when the .WAR file changes, 
> > > and redeploy
> > > and reload the context - same as if a .class file changes ). 
> > > 
> > > The other is the vhost-based layout for the webapps dir (
> > > use webapps/virtual.host.com/context, with DEFAULT as 
> keyword for the 
> > > main host ). That would allow easier auto-configuration for 
> > > virtual hosts.
> > > ( as you should know, the location of webapp and it's 
> behavior can be
> > > easily controlled in server.xml, it's just a matter of setting the
> > > default).
> > > 
> > > In the configurations, I would also like to change the 
> log options in
> > > examples to go to the default logger ( instead of 
> examples.log ). I am
> > > going to fix some modules to use the context logger for all 
> > > the messages
> > > where a context is available ( so a context log file will 
> have all the
> > > informations related with a context, and the "main" logger 
> > > will be used
> > > only for bad requests and server-wide events. ). I think 
> this is the
> > > correct behavior, but that would mean people will no 
> longer see the
> > > /examples logs in the console window. 
> > > 
> > > 
> > > Costin
> > > 
> > 
> 

Mime
View raw message