Re: Tomcat 5.0.28 release
Overall, JAXP is a very painful thing to those deploying any intensive XML or XSLT that might care what implementation is used and not having the luxury of dictating this implementation to everything else in the JVM. For instance, JAXP requires a separate classloader to change the XML or XSLT implementation used (i.e. to override the meta-inf/services entries as needed) -- yet one can't just create one's own classloader with a rigid security manager in place (e.g. in an applet). Even for per-JVM manipulation, JAXP requires fairly intrusive screwing with one's jars (to remove unwanted meta-inf entries) or command lines or creation of endorsed directories. In the end, I've resorted to using my own static factories to look up and instantiate JAXP implementation. From there on out, the JAXP APIs are fairly nice and easy to use, so the result is having only a single non-standard line of code per XML or XSLT factory. -- Jess Holle Shapira, Yoav wrote: Hola, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. JDK 1.4 was the first one to include JAXP and an XML parser implementation (Crimson) in the JDK itself. This presented difficulties to all container writers, including Tomcat, because they had to jump through special hoops to allow user web applications to override the parser and JAXP interfaces that shipped with the JDK. The typical use-case is a user wishing to use Xerces version X, which provides new features not available in Crimson and not accessible via the JAXP APIs, but relying on new DOM or SAX classes. The user needs both the xml-apis.jar and the xercesImpl.jar from his WAR file to be loaded, overriding those in the JDK itself (old JAXP and old Crimson parser). The endorsed classloading mechanism is the approach suggested by Sun and adopted by Tomcat. Endorsed means that classes from that repository can override those classes with the same name that ship with the JDK. The XML parsers are the classic example, but there are others. Our classloader how-to (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html ) and Sun's documentation on the mechanism in general (http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain additional explanations. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Jeanfrancois Arcand wrote: [back from vacation :-)] Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) Couldn't the use of XML be forced in a manner that is completely independent of JAXP? This could try for the 1.5 Xerces (once at startup) and then fail over to the 1.4 Xerces which it would always deliver, etc. Just a thought -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
[back from vacation :-)] Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) -- Jeanfrancois them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: - jdk1.3 - it'll work if you add your own parser in common/lib or jre/lib/ext or classpath - jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema validation might fail, everything else should work. - jdk1.5 - AFAIK everything should work. The reason endorsed was added is JDK1.4, where we had to add newer org.apache.xerces and javax.xml ( replacing what's in rt.jar ). Costin Why not only support JDK 1.4 and above? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Jeanfrancois Arcand wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) Yes, schema validation on JDK1.4 is lost because the parser doesn't support it well enough. I think it may be better to just check if the parser supports schema validation, and if not just display a warning that schema validation is disabled on parser that don't support it. It's easy to detect what version of xerces or if crimson is used. Fact is a lot of parsers don't support schema validation, and it is better to allow tomcat to work with any parser than try to force a specific version of parser. Well, the right solution is to just remove the option to turn schema validation on at startup - it is a huge waste of time at startup, it should be done only at deploy time by deploy tools :-) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) I don't think many pull parsers support schema, they are supposed to be faster and simpler :-) It's not about dropping xerces - we will still use the xerces inside jdk1.4 and jdk1.5 - we just shouldn't force a specific version and take all the pain for endorsed.dir - but let the user use whatever Jaxp parser he wants and disable schema validation if the parser doesn't support it. Costin -- Jeanfrancois them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
We are using it also and it is very helpful. It is one of the standard product features of a container to be able to seperate container product installation from runtime instance specific files. It works very nicely with tomcat. We can even allow instance admins to extend TC by changing to an alternate catalina.properties file (classloader definitions). It's not just a question of users sharing the base installation. I have a small enhancement request: we regularly change catalina.sh to include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We do this immediately after CATALINA_TEMPDIR is set. This way all instances share the same catalina.sh and instance specific commandline flags (memory sizing, catalina.properties, ...) can be done in the instance local setenvInstance.sh without changing the product installation. Please keep the separation of product installation and runtime instance. Rainer Jung kippdata informationstechnologie George Sexton wrote: How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hola, OK, feedback well put. Thanks, Yoav Shapira Millennium Research Informatics -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 4:10 AM To: Tomcat Developers List Subject: Re: Tomcat 5.0.28 release We are using it also and it is very helpful. It is one of the standard product features of a container to be able to seperate container product installation from runtime instance specific files. It works very nicely with tomcat. We can even allow instance admins to extend TC by changing to an alternate catalina.properties file (classloader definitions). It's not just a question of users sharing the base installation. I have a small enhancement request: we regularly change catalina.sh to include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We do this immediately after CATALINA_TEMPDIR is set. This way all instances share the same catalina.sh and instance specific commandline flags (memory sizing, catalina.properties, ...) can be done in the instance local setenvInstance.sh without changing the product installation. Please keep the separation of product installation and runtime instance. Rainer Jung kippdata informationstechnologie George Sexton wrote: How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. Hi Tomcat developers, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. Thanks in advance. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hola, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. JDK 1.4 was the first one to include JAXP and an XML parser implementation (Crimson) in the JDK itself. This presented difficulties to all container writers, including Tomcat, because they had to jump through special hoops to allow user web applications to override the parser and JAXP interfaces that shipped with the JDK. The typical use-case is a user wishing to use Xerces version X, which provides new features not available in Crimson and not accessible via the JAXP APIs, but relying on new DOM or SAX classes. The user needs both the xml-apis.jar and the xercesImpl.jar from his WAR file to be loaded, overriding those in the JDK itself (old JAXP and old Crimson parser). The endorsed classloading mechanism is the approach suggested by Sun and adopted by Tomcat. Endorsed means that classes from that repository can override those classes with the same name that ship with the JDK. The XML parsers are the classic example, but there are others. Our classloader how-to (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html ) and Sun's documentation on the mechanism in general (http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain additional explanations. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Petr Jiricka wrote: Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. Hi Tomcat developers, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. If you remove common/endorsed: - jdk1.3 - it'll work if you add your own parser in common/lib or jre/lib/ext or classpath - jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema validation might fail, everything else should work. - jdk1.5 - AFAIK everything should work. The reason endorsed was added is JDK1.4, where we had to add newer org.apache.xerces and javax.xml ( replacing what's in rt.jar ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
To clarify: I wasn't proposing to remove the separate product installation and runtime, but the contrary - to make that the default. Right now tomcat operates in 2 modes - one where CATALINA_HOME is identical with CATALINA_BASE, and one where you have them separate ( like you use ). I think it would be cleaner if separate mode will be the default, with the runtime files always in a separate hierarchy. But it's more of a cosmetic change. Costin Rainer Jung wrote: We are using it also and it is very helpful. It is one of the standard product features of a container to be able to seperate container product installation from runtime instance specific files. It works very nicely with tomcat. We can even allow instance admins to extend TC by changing to an alternate catalina.properties file (classloader definitions). It's not just a question of users sharing the base installation. I have a small enhancement request: we regularly change catalina.sh to include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We do this immediately after CATALINA_TEMPDIR is set. This way all instances share the same catalina.sh and instance specific commandline flags (memory sizing, catalina.properties, ...) can be done in the instance local setenvInstance.sh without changing the product installation. Please keep the separation of product installation and runtime instance. Rainer Jung kippdata informationstechnologie George Sexton wrote: How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: If you remove common/endorsed: - jdk1.3 - it'll work if you add your own parser in common/lib or jre/lib/ext or classpath - jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema validation might fail, everything else should work. - jdk1.5 - AFAIK everything should work. The reason endorsed was added is JDK1.4, where we had to add newer org.apache.xerces and javax.xml ( replacing what's in rt.jar ). Very good summary :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
FYI - progress on the 5.0.28 changes: Petr Jiricka wrote: - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. Thanks to Jan Luehe, these fixes are now integrated to the TOMCAT_5_0 branch. See also the release notes for the list of issues ported from trunk. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) My coworkers at Sun are investigating the possible approaches to make the same distribution of Tomcat work on both JDK 1.4 and 1.5, including Costin's idea. If you have any additional thoughts or suggestions in this area, please post them. Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
I'm sorry, but can't remember - why do we still need the endorsed ? I tought they were a temporary solution for JDK1.4 and some validation problems - tomcat should work fine with any SAX/DOM parser, including the one in JDK1.4. The only problem is JDK1.3 - and I agree that it would be better to just provide a patch for 1.3 ( or ask the user to install a parser in jre/ext or classpath, to get the same behavior as in 1.4 ). Or even better - in Bootstrap check if we're in 1.3 and add the parser to the classpath, otherwise use whatever is in jdk ( and maybe turn validation of if the version of jdk and parser is not the right one ). In any case - modularizing the distribution would be really good. Having a core JDK1.5 distro, and additional packages to add JDK1.4 and JDK1.3 support is good. It would also be good to distribute more components as optional plug-ins. Again - I missed a lot of discussions, probably most of this has been discussed, I'll try more searches on the archives :-) Costin Tim Funk wrote: Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Shapira, Yoav wrote: Hi, A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm not gung-ho about making significant Tomcat 5.0 additions and enhancements, given the advanced state of Tomcat 5.1 development. If there's a showstopper, security, or spec-compliance bug than of course it will be fixed and additional releases made. I didn't know there was a branch already! Thanks - that's great. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. However, if you really want this strongly, feel free to submit patches back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and we'll look at them. Thanks. As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without needing to modify anything. Tomcat 5.0 doesn't make that claim, but it does let you modify parsers as you want using the standard endorsed classloading mechanism. Of course I've already said that on the bug report ;) I guess there are two possible perceptions of this problem. One is that we should strive for the cleanest possible architecture, and have multiple releases each targetting a particular platform. The other is that there should be a single universal release that supports a range of platforms, and the architecture should be able to accomodate all of them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. Hi, Oh and BTW, definitely -1 on committing to regular monthly releases. They'll come when they're ready: that's always been the process. And ready itself is also ambiguously defined as a critical fix, significant enhancements, large number of bug fixes, or a combination thereof. If the average duration between releases for us has been 1 month, that's great, but it's a coincidence that I don't want to commit to ;) There are far too many variables in our work for that. Agreed, it is not reasonable to commit to regular release schedule (based on my own experience ;) In my mind, release schedule is an approximate guideline, not committment. Yoav Shapira Millennium Research Informatics Petr -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue
Re: Tomcat 5.0.28 release
Remy Maucherat wrote: Petr Jiricka wrote: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. I do manage to integrate patches in the JBoss tree without the need for a stable release, whenever I really need a particular fix. IMO, you should be prepared to do the same once in a while, it's easier for everyone. I believe Tomcat is used in a number of high profile servers (in addition to your usage), so making a release each time someone needs something (I suppose in the few days before a freeze of the relevant products, it would probably be every 5 minutes ;) ) isn't possible. The advantage of stable releases is that these are much more thoroughly tested by the community than ad-hoc builds. Also, a stable release is a way of saying to the community that we believe that what we have now works together, it is safe to use the fixes that have come in. We should not be asking why to do a release - let's ask why not?. We could easily do a custom build with just the bugfixes we need, but I think the community would benefit if the fixes are exposed in a public release. As for the other part of your question - yes, our main motivation for a new release is to use it in our product, but we are not talking about days. In fact, we have been testing NetBeans with Tomcat 5 since January, and submitted a fair number of bug reports since then. I believe monthly releases are reasonable - we are definitely not talking about a release every 5 minutes :) - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) This is disruptive for 5.0.x. So, sorry, but I vote no for that one. My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). Ok, we have a different opinion here, see my reply to Yoav. - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. This makes sense, but you need to indicate which patches need to be backported. I expect it's the JSP debugging related fixes then ? Yes, we'd like to see the JSP debugging bugfixes in, but I am not only talking about bugfixes requested by Sun. If the community feels strongly that a particular bugfix should be ported to 5.0.x, then it can be done. This should be a community effort, not a Sun release. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Nice plan :) (ok, actually, we did that already before starting the refactoring, as Yoav mentioned) Thanks again. Petr Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: I'm sorry, but can't remember - why do we still need the endorsed ? I tought they were a temporary solution for JDK1.4 and some validation problems - tomcat should work fine with any SAX/DOM parser, including the one in JDK1.4. This would be good, if it's indeed possible. I just tried removing common/endorsed/*.jar from Tomcat 5.0.27, and it seemed to work ok on JDK 1.4.2_04. I didn't try any XML tags in JSTL (which often prove fragile wrt. parser configuration), but at first sight it works. The only problem is JDK1.3 - and I agree that it would be better to just provide a patch for 1.3 ( or ask the user to install a parser in jre/ext or classpath, to get the same behavior as in 1.4 ). Or even better - in Bootstrap check if we're in 1.3 and add the parser to the classpath, otherwise use whatever is in jdk ( and maybe turn validation of if the version of jdk and parser is not the right one ). In any case - modularizing the distribution would be really good. Having a core JDK1.5 distro, and additional packages to add JDK1.4 and JDK1.3 support is good. It would also be good to distribute more components as optional plug-ins. I agree this is a good plan, as long as there is a way to build a single distribution that supports all the supported platforms (or at least JDK 1.4.x + 1.5). Thanks Petr Again - I missed a lot of discussions, probably most of this has been discussed, I'll try more searches on the archives :-) Costin Tim Funk wrote: Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. Ahh -- that's good. Please make sure to note them as such when you report them. It will raise their importance significantly. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? The rest of what you said, I agree with. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
I for one use the CATALINA_BASE vs CATALINA_HOME Mitchell Marx -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 8:53 AM To: Tomcat Developers List Subject: RE: Tomcat 5.0.28 release Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. Ahh -- that's good. Please make sure to note them as such when you report them. It will raise their importance significantly. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? The rest of what you said, I agree with. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
I would have to agree with the gentlemen from Sun and NetBeans that it is preferable to have a standard stable version bundled with other products as opposed to some other file set which one cannot independently reproduce. Why? Users of NetBeans, etc, would like to know that they can reproduce the same behavior outside the IDE by grabbing the same version label from Jakarta. If NetBeans uses its own set of source versions, then users never know what might differ between the NetBeans Tomcat behavior and standard Tomcat releases. I happen to be responsible for the redistribution of a modified Tomcat and have come to noting each and every deviation (change or addition) from the standard Tomcat release upon which I'm based for this reason. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hola, I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. It's the same good reason as for every upgrade: so that you (as the user) can use code that's simpler and more efficient because it doesn't have to account for differences between JDKs. This is not specific to Tomcat, it's a more generic product development decision. At some point you want to drop support for an older version of X because the cost of supporting it isn't worth the benefit. I'm not saying we've reached that point with JDK 1.3 yet, but the possibility must be reconsidered periodically and/or every time we're debating the work for a major new release branch. How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. That's not a bad idea. I wouldn't mind it. It doesn't seem any worse than the current $CATALINA_HOME/$CATALINA_BASE approach. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hi, A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm not gung-ho about making significant Tomcat 5.0 additions and enhancements, given the advanced state of Tomcat 5.1 development. If there's a showstopper, security, or spec-compliance bug than of course it will be fixed and additional releases made. However, if you really want this strongly, feel free to submit patches back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and we'll look at them. As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without needing to modify anything. Tomcat 5.0 doesn't make that claim, but it does let you modify parsers as you want using the standard endorsed classloading mechanism. Of course I've already said that on the bug report ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Thanks in advance for your comments. Petr Jiricka Sun Developer Tools group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
Hi, Oh and BTW, definitely -1 on committing to regular monthly releases. They'll come when they're ready: that's always been the process. And ready itself is also ambiguously defined as a critical fix, significant enhancements, large number of bug fixes, or a combination thereof. If the average duration between releases for us has been 1 month, that's great, but it's a coincidence that I don't want to commit to ;) There are far too many variables in our work for that. Yoav Shapira Millennium Research Informatics -Original Message- From: Shapira, Yoav Sent: Monday, August 09, 2004 1:05 PM To: Tomcat Developers List Subject: RE: Tomcat 5.0.28 release Hi, A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm not gung-ho about making significant Tomcat 5.0 additions and enhancements, given the advanced state of Tomcat 5.1 development. If there's a showstopper, security, or spec-compliance bug than of course it will be fixed and additional releases made. However, if you really want this strongly, feel free to submit patches back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and we'll look at them. As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without needing to modify anything. Tomcat 5.0 doesn't make that claim, but it does let you modify parsers as you want using the standard endorsed classloading mechanism. Of course I've already said that on the bug report ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Thanks in advance for your comments. Petr Jiricka Sun Developer Tools group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential
Re: Tomcat 5.0.28 release
Petr Jiricka wrote: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. I do manage to integrate patches in the JBoss tree without the need for a stable release, whenever I really need a particular fix. IMO, you should be prepared to do the same once in a while, it's easier for everyone. I believe Tomcat is used in a number of high profile servers (in addition to your usage), so making a release each time someone needs something (I suppose in the few days before a freeze of the relevant products, it would probably be every 5 minutes ;) ) isn't possible. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) This is disruptive for 5.0.x. So, sorry, but I vote no for that one. My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. This makes sense, but you need to indicate which patches need to be backported. I expect it's the JSP debugging related fixes then ? From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Nice plan :) (ok, actually, we did that already before starting the refactoring, as Yoav mentioned) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
