RE: 3.3: nightly, updating the parser, options
I'm working on restoring the nightly buildtest, 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 ). +1 - 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). Fine
Re: 3.3: nightly, updating the parser, options
+1 Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 06/21/01 02:18AM Hi, I'm working on restoring the nightly buildtest, 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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, 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
RE: 3.3: nightly, updating the parser, options
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 21 de junio de 2001 10:19 Para: [EMAIL PROTECTED] Asunto: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, 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
RE: 3.3: nightly, updating the parser, options
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 12:59 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, 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
