You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by jean-frederic clere <jf...@gmail.com> on 2009/12/22 17:11:33 UTC
[VOTE] Release build 6.0.21 (try 2)
The candidates binaries are available here:
http://people.apache.org/~jfclere/tomcat-6/v6.0.21-try2/
According to the release process, the 6.0.21 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable
The differences are only the tcnative windows binary files: tcnative was
broken in the previous try.
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mark Thomas <ma...@apache.org>.
On 22/12/2009 20:27, Mark Thomas wrote:
> On 22/12/2009 16:11, jean-frederic clere wrote:
>> The candidates binaries are available here:
>> http://people.apache.org/~jfclere/tomcat-6/v6.0.21-try2/
>>
>> According to the release process, the 6.0.21 tag is:
>> [X] Broken
>> [ ] Alpha
>> [ ] Beta
>> [ ] Stable
>>
>> The differences are only the tcnative windows binary files: tcnative was
>> broken in the previous try.
<snip/>
> JSP TCK passes - 1 failure
>
> This one, however, can't be ignored. Remy hinted at it early today. The
> fix for bug 47453 created a regression in that the constraint expressed
> in JSP.2.3.4 namely that <quote>A String literal can be provided, as
> long as the return type of the deferred method signature is not
> void</quote> is not enforced. This needs to be fixed for 6.0.21 and
> will, therefore, require a re-tag.
>
> I am starting to look at this now.
I have a patch for this. Just running the full JSP TCK to make sure it
doesn't break anything else.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mark Thomas <ma...@apache.org>.
On 22/12/2009 20:38, A. Weinert wrote:
> Hi all,
>
> full install of
> 22.12.2009 17:32 6.865.003 apache-tomcat-6.0.21.exe
> on actual XP home won't even start with:
>
> 22.12.2009 21:19:46 org.apache.tomcat.util.digester.Digester startElement
> SCHWERWIEGEND: Begin event threw exception
> java.lang.ClassNotFoundException:
> org.apache.catalina.core.JreMemoryLeakPreventionListener
Works for me on:
- XP Pro 64-bit
- XP Pro 32-bit
- XP Home 32-bit
Maybe an issue with your environment? You can follow that up on the
users list if you need help to debug it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by "A. Weinert" <al...@a-weinert.de>.
Hi all,
full install of
22.12.2009 17:32 6.865.003 apache-tomcat-6.0.21.exe
on actual XP home won't even start with:
22.12.2009 21:19:46 org.apache.tomcat.util.digester.Digester startElement
SCHWERWIEGEND: Begin event threw exception
java.lang.ClassNotFoundException:
org.apache.catalina.core.JreMemoryLeakPreventionListener
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
.... and 12kB more ...
in catalina....log
Service started and stopped.
No directories etc. made in C:\Programme\Apache\Tomcat\conf yet.
Had a similar problem with 6.0.20 on actual Windows server 2003
enterprise. In that case dropping the "native" helped. In the XP
case now that changes nothing.
Thought it might be of interest.
Regards Albrecht
Mark Thomas schrieb:
> On 22/12/2009 16:11, jean-frederic clere wrote:
>> The candidates binaries are available here:
>> http://people.apache.org/~jfclere/tomcat-6/v6.0.21-try2/
>>
>> According to the release process, the 6.0.21 tag is:
>> [X] Broken
>> [ ] Alpha
>> [ ] Beta
>> [ ] Stable
>>
>> The differences are only the tcnative windows binary files: tcnative was
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/23/2009 01:38 PM, Mark Thomas wrote:
> On 23/12/2009 08:55, jean-frederic clere wrote:
>> On 12/22/2009 09:27 PM, Mark Thomas wrote:
>>> Servlet TCK passes
>>> JSP TCK passes - 1 failure
>>>
>>> This one, however, can't be ignored. Remy hinted at it early today. The
>>> fix for bug 47453 created a regression in that the constraint expressed
>>> in JSP.2.3.4 namely that<quote>A String literal can be provided, as
>>> long as the return type of the deferred method signature is not
>>> void</quote> is not enforced. This needs to be fixed for 6.0.21 and
>>> will, therefore, require a re-tag.
>>
>> Sure.
>
> Are you going to re-tag trunk as 6.0.21 or 6.0.22.
I will re-tag trunk as 6.0.22
I have no strong
> preference. Whilst this is happening in the open, it is only happening
> on the dev list and folks on the dev list are not end users so I am not
> concerned about re-using 6.0.21
>
> If you do want to go for 6.0.22, we'll need to modify the changelog to
> reflect which changes were post the 6.0.21 tag.
Yep.
>
> Before tagging I think we should try and commit the MD5 fix and the
> source file line endings fix.
Sure
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mark Thomas <ma...@apache.org>.
On 23/12/2009 08:55, jean-frederic clere wrote:
> On 12/22/2009 09:27 PM, Mark Thomas wrote:
>> Servlet TCK passes
>> JSP TCK passes - 1 failure
>>
>> This one, however, can't be ignored. Remy hinted at it early today. The
>> fix for bug 47453 created a regression in that the constraint expressed
>> in JSP.2.3.4 namely that<quote>A String literal can be provided, as
>> long as the return type of the deferred method signature is not
>> void</quote> is not enforced. This needs to be fixed for 6.0.21 and
>> will, therefore, require a re-tag.
>
> Sure.
Are you going to re-tag trunk as 6.0.21 or 6.0.22. I have no strong
preference. Whilst this is happening in the open, it is only happening
on the dev list and folks on the dev list are not end users so I am not
concerned about re-using 6.0.21
If you do want to go for 6.0.22, we'll need to modify the changelog to
reflect which changes were post the 6.0.21 tag.
Before tagging I think we should try and commit the MD5 fix and the
source file line endings fix.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/22/2009 09:27 PM, Mark Thomas wrote:
> Servlet TCK passes
> JSP TCK passes - 1 failure
>
> This one, however, can't be ignored. Remy hinted at it early today. The
> fix for bug 47453 created a regression in that the constraint expressed
> in JSP.2.3.4 namely that<quote>A String literal can be provided, as
> long as the return type of the deferred method signature is not
> void</quote> is not enforced. This needs to be fixed for 6.0.21 and
> will, therefore, require a re-tag.
Sure.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/23/2009 02:12 AM, Rainer Jung wrote:
> On 23.12.2009 00:45, Konstantin Kolinko wrote:
>> 2009/12/22 Mark Thomas<ma...@apache.org>:
>>> (...)
>>> Since we are going to have to re-tag anyway, it would be good if the
>>> patches required to fix the various niggles above were applied before
>>> the tag.
>>>
>>> Mark
>>
>> +1 to re-tag.
>>
>> And I would like the fix to 47413 to be included in it. Patch already
>> proposed, though there might be comments.
>>
>> To be sure: while applying the patches, we are still updating the
>> "6.0.21" section of changelog.xml?
>> That is, everybody agrees that the next tag will be 6.0.21 again? I am
>> +1 to drop the current TOMCAT_6_0_21/ and recreate it after the fixes
>> are applied.
>
> IMHO: Our whole release process happens in public. So our artefacts can
> be retrieved from the dev download pages and from looking at the files
> there is nothing to decide, whether it is a later withdrawn release
> candidate of 6.0.21 or the real release. So since we don't do real
> release candidates (marking the files with rcX or dev or whatever) the
> only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
+1
>
> The same problem IMHO applies to editing files in an svn tag (at least
> if more than a couple of minutes have passed since tagging). After
> editing it's not any more a tag that uniquely describes one version of
> the code, instead it becomes a branch.
Well probably that is also a good idea.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mladen Turk <mt...@apache.org>.
On 12/23/2009 11:59 AM, Rainer Jung wrote:
>
> So I suggest we try that for TC 7 and find out how to do that in a good
> way (or not) before we try with 6.0. Let's stick to the existing process
> for 6.0 and do the experiments with 7.
>
We can easily make a script similar to the one we have for mod_jk
It can either come from tag or trunk (in which case it caries rXXXXX)
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Rainer Jung <ra...@kippdata.de>.
On 23.12.2009 10:33, Konstantin Kolinko wrote:
> 2009/12/23 Mladen Turk<mt...@apache.org>:
>> On 12/23/2009 02:12 AM, Rainer Jung wrote:
>>>
>>> release candidates (marking the files with rcX or dev or whatever) the
>>> only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
>>>
>>
>> +1
>>
>> Let's make a proper release.
>
> +1
>
>>
>> I'd suggest to make a release on a specific SVN revision instead tag.
>> That way if voted it can easily be tagged as 6.0.22 (that revision
>> instead 6.0.x trunk)
>> Having that, RM can have as many candidates without re-tagging or
>> creating useless tags.
>>
>
> 1. Rainer states a valid point that if those files are named "6.0.22"
> someone can download them from people.apache.org and claim later that
> it is ours.
>
> If those are named differently, will PGP signatures still apply?
>
> Though it would be good to do some testing with a 6.0.0-dev build as a
> RC after several months of active development, or after reconfiguring
> the build environment.
>
> 2. Do we change 6.0.0-dev -> 6.0.22 in the properties file in SVN
> before that revision, or in the tag only, or change it only locally?
> I would prefer it to be changed in the tag.
>
> 3. While RC voting goes, should we make "6.0.(n+1)" section
> in changelog.xml and add new items there, optionally moving them
> into "6.0.n" section if voting fails?
>
> I think it is OK to trash one or more version numbers. It preserves consistency.
> And will we ever beat HTTPD with their *.*.63 for 2.0.x?
I expect making RC from some svn revision and then rebrand as release
after voting needs some experimentation in order to find a stable
process for it (where is the version number hidden in the RC, how easy
can the RC be differentiated from the full release). Using an RC tag or
an svn revision for that will be the smallest problem.
We can inspect, how the commons people do their RCs and releases.
So I suggest we try that for TC 7 and find out how to do that in a good
way (or not) before we try with 6.0. Let's stick to the existing process
for 6.0 and do the experiments with 7.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2009/12/23 Mladen Turk <mt...@apache.org>:
> On 12/23/2009 02:12 AM, Rainer Jung wrote:
>>
>> release candidates (marking the files with rcX or dev or whatever) the
>> only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
>>
>
> +1
>
> Let's make a proper release.
+1
>
> I'd suggest to make a release on a specific SVN revision instead tag.
> That way if voted it can easily be tagged as 6.0.22 (that revision
> instead 6.0.x trunk)
> Having that, RM can have as many candidates without re-tagging or
> creating useless tags.
>
1. Rainer states a valid point that if those files are named "6.0.22"
someone can download them from people.apache.org and claim later that
it is ours.
If those are named differently, will PGP signatures still apply?
Though it would be good to do some testing with a 6.0.0-dev build as a
RC after several months of active development, or after reconfiguring
the build environment.
2. Do we change 6.0.0-dev -> 6.0.22 in the properties file in SVN
before that revision, or in the tag only, or change it only locally?
I would prefer it to be changed in the tag.
3. While RC voting goes, should we make "6.0.(n+1)" section
in changelog.xml and add new items there, optionally moving them
into "6.0.n" section if voting fails?
I think it is OK to trash one or more version numbers. It preserves consistency.
And will we ever beat HTTPD with their *.*.63 for 2.0.x?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mladen Turk <mt...@apache.org>.
On 12/23/2009 02:12 AM, Rainer Jung wrote:
> release candidates (marking the files with rcX or dev or whatever) the
> only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
>
+1
Let's make a proper release.
I'd suggest to make a release on a specific SVN revision instead tag.
That way if voted it can easily be tagged as 6.0.22 (that revision
instead 6.0.x trunk)
Having that, RM can have as many candidates without re-tagging or
creating useless tags.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Rainer Jung <ra...@kippdata.de>.
On 23.12.2009 00:45, Konstantin Kolinko wrote:
> 2009/12/22 Mark Thomas<ma...@apache.org>:
>> (...)
>> Since we are going to have to re-tag anyway, it would be good if the
>> patches required to fix the various niggles above were applied before
>> the tag.
>>
>> Mark
>
> +1 to re-tag.
>
> And I would like the fix to 47413 to be included in it. Patch already
> proposed, though there might be comments.
>
> To be sure: while applying the patches, we are still updating the
> "6.0.21" section of changelog.xml?
> That is, everybody agrees that the next tag will be 6.0.21 again? I am
> +1 to drop the current TOMCAT_6_0_21/ and recreate it after the fixes
> are applied.
IMHO: Our whole release process happens in public. So our artefacts can
be retrieved from the dev download pages and from looking at the files
there is nothing to decide, whether it is a later withdrawn release
candidate of 6.0.21 or the real release. So since we don't do real
release candidates (marking the files with rcX or dev or whatever) the
only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
The same problem IMHO applies to editing files in an svn tag (at least
if more than a couple of minutes have passed since tagging). After
editing it's not any more a tag that uniquely describes one version of
the code, instead it becomes a branch.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2009/12/22 Mark Thomas <ma...@apache.org>:
>(...)
> Since we are going to have to re-tag anyway, it would be good if the
> patches required to fix the various niggles above were applied before
> the tag.
>
> Mark
+1 to re-tag.
And I would like the fix to 47413 to be included in it. Patch already
proposed, though there might be comments.
To be sure: while applying the patches, we are still updating the
"6.0.21" section of changelog.xml?
That is, everybody agrees that the next tag will be 6.0.21 again? I am
+1 to drop the current TOMCAT_6_0_21/ and recreate it after the fixes
are applied.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release build 6.0.21 (try 2)
Posted by Mark Thomas <ma...@apache.org>.
On 22/12/2009 16:11, jean-frederic clere wrote:
> The candidates binaries are available here:
> http://people.apache.org/~jfclere/tomcat-6/v6.0.21-try2/
>
> According to the release process, the 6.0.21 tag is:
> [X] Broken
> [ ] Alpha
> [ ] Beta
> [ ] Stable
>
> The differences are only the tcnative windows binary files: tcnative was
> broken in the previous try.
Source files:
src.tar.gz == src.zip
MD5s match
Signatures good
Key in ASF web of trust
All the source files have linux line-endings. I think this is a
side-effect of building on linux rather than Windows and has been this
way for the last few releases. There is a patch proposed to fix this but
I don't view this as a show stopper.
There is also a difference between the tag and the source files. The
diff is:
---
D:/repos/asf/public/tomcat/tc6.0.x/tags/TOMCAT_6_0_21/build.properties.default
Tue Dec 22 17:10:53 2009
+++
D:/tmp/apache-tomcat-6.0.21-src-zip/apache-tomcat-6.0.21-src/build.properties.default
Tue Dec 22 17:31:18 2009
@@ -44,7 +44,7 @@
compile.debug=true
base-commons.loc=http://archive.apache.org/dist/commons
-base-tomcat.loc=http://archive.apache.org/dist/tomcat
+base-tomcat.loc=http://people.apache.org/~jfclere/
base-sf.loc=http://downloads.sourceforge.net
# ----- Commons Logging, version 1.1 or later -----
I assume this was done to include the desired windows binaries. However,
this means that anyone trying to build from the src distro will be
pulling the Windows binaries from the wrong place. The correct way to do
this would have been to create a build.properties file and override the
base-tomcat.loc setting in that file.
The tag is correct, the source bundles just need re-building from the tag.
Binaries:
apache-tomcat-6.0.21.zip.md5 is broken. If lists multiple files but the
MD5 is only correct for the first file in the list. The root cause is a
copy and paster error in the build file (patch already proposed to fix
it). Applying this fix would mean a re-tag. However, I'd be happy with
manually fixing the generated MD5s to fix this to save the re-tag.
Servlet TCK passes
JSP TCK passes - 1 failure
This one, however, can't be ignored. Remy hinted at it early today. The
fix for bug 47453 created a regression in that the constraint expressed
in JSP.2.3.4 namely that <quote>A String literal can be provided, as
long as the return type of the deferred method signature is not
void</quote> is not enforced. This needs to be fixed for 6.0.21 and
will, therefore, require a re-tag.
I am starting to look at this now.
Since we are going to have to re-tag anyway, it would be good if the
patches required to fix the various niggles above were applied before
the tag.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org