Fwd: svn commit: r1877430 - /comdev/projects.apache.org/trunk/data/projects.xml

[sebb AT ASF]

Please update project.xml with the new location.

-- Forwarded message -
From: 
Date: Wed, 6 May 2020 at 12:39
Subject: svn commit: r1877430 -
/comdev/projects.apache.org/trunk/data/projects.xml
To: 


Author: sebb
Date: Wed May  6 11:39:14 2020
New Revision: 1877430

URL: http://svn.apache.org/viewvc?rev=1877430&view=rev
Log:
Tomcat RDC DOAP disappeared

Modified:
comdev/projects.apache.org/trunk/data/projects.xml

Modified: comdev/projects.apache.org/trunk/data/projects.xml
URL: 
http://svn.apache.org/viewvc/comdev/projects.apache.org/trunk/data/projects.xml?rev=1877430&r1=1877429&r2=1877430&view=diff
==
--- comdev/projects.apache.org/trunk/data/projects.xml (original)
+++ comdev/projects.apache.org/trunk/data/projects.xml Wed May  6 11:39:14 2020
@@ -294,7 +294,7 @@
   
http://svn.apache.org/repos/asf/tika/site/src/site/resources/doap.rdf
   
http://svn.apache.org/repos/asf/tiles/site/doap_Tiles.rdf
   
http://svn.apache.org/repos/asf/tomcat/site/trunk/docs/doap_Tomcat.rdf
-  
http://svn.apache.org/repos/asf/tomcat/taglibs/rdc/trunk/doap_rdc.rdf
+  
   
http://svn.apache.org/repos/asf/tomee/tomee/trunk/doap_tomee.rdf
   
https://gitbox.apache.org/repos/asf?p=trafficserver.git;a=blob_plain;f=doc/doap.rdf;hb=HEAD
   
https://gitbox.apache.org/repos/asf?p=trafodion.git;a=blob_plain;f=doap.rdf;hb=HEAD

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Fwd: Cannot find doap file: http://svn.apache.org/repos/asf/tomcat/taglibs/rdc/trunk/doap_rdc.rdf

[sebb]

Please can someone update
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
with the new location of the DOAP?

Thanks.
-- Forwarded message -
From: Projects 
Date: Wed, 29 Apr 2020 at 03:01
Subject: Cannot find doap file:
http://svn.apache.org/repos/asf/tomcat/taglibs/rdc/trunk/doap_rdc.rdf
To: Site Development 


URL: http://svn.apache.org/repos/asf/tomcat/taglibs/rdc/trunk/doap_rdc.rdf
HTTP Error 404: Not Found
Source: 
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Fwd: Error when processing doap file http://svn.apache.org/repos/asf/tomcat/site/trunk/docs/doap_Tomcat.rdf:

[sebb]

Please can you fix the syntax error in the DOAP?

-- Forwarded message -
From: Projects 
Date: Wed, 27 Feb 2019 at 02:03
Subject: Error when processing doap file
http://svn.apache.org/repos/asf/tomcat/site/trunk/docs/doap_Tomcat.rdf:
To: Site Development 


URL: http://svn.apache.org/repos/asf/tomcat/site/trunk/docs/doap_Tomcat.rdf
not well-formed (invalid token): line 89, column 7
Source: 
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] Apache Tomcat Connectors 1.2.43 released

[sebb]

What is the project about? Why should I be interested in it?
[rhetorical questions]

The Announce emails are sent to people not on the developer or user lists.
Most will have no idea what the project is about.

So the e-mails should contain at least brief details of what the
product does, and some info on why the new release might be of
interest to them.

Readers should not have to click the link to find out the basic information
(although of course it is useful to have such links for further detail).

Please can you add that information to future announce mails?

Thanks.

On 7 March 2018 at 16:38, Mark Thomas  wrote:
> The Apache Tomcat Project is proud to announce the release of version
> 1.2.43 of the Apache Tomcat Connectors.
> This version fixes a number of bugs found in previous releases.
>
> Full details of these changes and new features,
> are available in the Apache Tomcat Connectors changelog:
> https://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html
>
> In addition to the usual source release, this release includes Windows
> binaries for the JK ISAPI connector for IIS.
>
> Downloads:
> https://tomcat.apache.org/download-connectors.cgi
>
> Thank you,
> --
> The Apache Tomcat Team
>
>
> For details of the "Tomcat for Administrators" training course being
> held in Manchester, UK please see:
> https://tomcat.apache.org/conference.html

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] Apache Tomcat 7.0.84 released

[sebb]

Might be an idea to include a link to the main Tomcat page somewhere
in the announce?

On 25 January 2018 at 08:44, Violeta Georgieva  wrote:
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 7.0.84.
>
> Apache Tomcat is an open source software implementation of the Java
> Servlet, JavaServer Pages, Java Expression Language and Java
> WebSocket technologies.
>
> This release contains a number of bug fixes and improvements compared to
> version 7.0.82. The notable changes since 7.0.82 include:
>
>
> - Java 9 is fully supported
>
> - Update the packaged version of the Tomcat Native Library to
>   1.2.16 to pick up the latest Windows binaries built with
>   APR 1.6.3 and OpenSSL 1.0.2m
>
> - Add a new system property
>   (org.apache.jasper.runtime.BodyContentImpl.BUFFER_SIZE) to control the
>   size of the buffer used by Jasper when buffering tag bodies.
>
>
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
>
> Downloads:
> http://tomcat.apache.org/download-70.cgi
>
> Migration guides from Apache Tomcat 5.5.x and 6.0.x:
> http://tomcat.apache.org/migration.html
>
> Enjoy
>
> The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1817993 - /gump/metadata/project/tomcat-trunk.xml

[sebb]

On 14 December 2017 at 15:20, Mark Thomas  wrote:
> On 14/12/17 13:18, Konstantin Kolinko wrote:
>> Hi, Mark!
>>
>> To dev@tomcat, cc: general@gump.
>>
>>
>> The result of this change is that Gump building Tomcat downloads
>> tar.gz for Commons-Daemon from mirrors.
>
> Drat. That wasn't the intention at all.
>
> 
>
>> The "mvn package" command used by Gump does not build the src.tar.gz file.
>>
>> The file can be built by "mvn assembly:single" command, [4]
>> but HOWTO-RELEASE.txt file does not mention it so I wonder what is
>> actually used by Commons Daemon here.
>
> The command 'mvn deploy -Prelease' creates it. I suspect that isn't
> appropriate for Gump.

FTR:

You can add the following options to deploy to target/deploy and not
sign the artifacts:

-Ptest-deploy -Dgpg.skip

Documented here:

http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate

>> So this can be fixed by updating Gump configuration for commons-daemon to do
>>  and
>> >  id="native-distro" />
>>
>>
>> Alternatively, a question is whether the "deploy" target in Tomcat
>> actually has a need to copy the *.tar.gz files to CATALINA_HOME/bin/.
>> Those source file are needed when redistributing Tomcat, but they are
>> not actually needed when running it.
>
> Good point.
>
> The Windows binaries are only copied to /bin for the dist-static target.
> I can't see a reason not to treat the *.tar.gz src files the same way.
>
> Mark
>
> -
> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [SECURITY] CVE-2015-5345 Apache Tomcat Directory disclosure

[sebb]

On 22 February 2016 at 11:23, Mark Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> CVE-2015-5345 Apache Tomcat Directory disclosure
>
> Severity: Low
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> - - Apache Tomcat 6.0.0 to 6.0.44
> - - Apache Tomcat 7.0.0 to 7.0.66
> - - Apache Tomcat 8.0.0.RC1 to 8.0.29
> - - Apache Tomcat 9.0.0.M1
> - - Earlier, unsupported Tomcat versions may be affected
>
> Description:
> When accessing a directory protected by a security constraint with a URL
> that did not end in a slash, Tomcat would redirect to the URL with the
> trailing slash thereby confirming the presence of the directory before
> processing the security constraint. It was therefore possible for a user
> to determine if a directory existed or not, even if the user was not
> permitted to view the directory. The issue also occurred at the root of
> a web application in which case the presence of the web application was
> confirmed, even if a user did not have access.
>
> The solution was to implement the redirect in the DefaultServlet so that
> any security constraints and/or security enforcing Filters were
> processed before the redirect. The Tomcat team recognised that moving
> the redirect could cause regressions to two new Context configuration

s/to two/so two/ ?

> options (mapperContextRootRedirectEnabled and
> mapperDirectoryRedirectEnabled) were introduced. The initial default was
> false for both since this was more secure. However, due to regressions
> such as Bug 58765 [1] the default for mapperContextRootRedirectEnabled
> was later changed to true since it was viewed that the regression was
> more serious than the security risk of associated with being able to
> determine if a web application was deployed at a given path.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - - Upgrade to Apache Tomcat 9.0.0.M3 or later
>   (9.0.0.M2 has the fix but was not released)
> - - Upgrade to Apache Tomcat 8.0.30 or later
> - - Upgrade to Apache Tomcat 7.0.67 or later
> - - Upgrade to Apache Tomcat 6.0.45 or later
>
>
> Credit:
> This issue was discovered by Mark Koek of QCSec.
>
> References:
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58765
> [2] http://tomcat.apache.org/security-9.html
> [3] http://tomcat.apache.org/security-8.html
> [4] http://tomcat.apache.org/security-7.html
> [5] http://tomcat.apache.org/security-6.html
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWyu+lAAoJEBDAHFovYFnnFrYP+wZwqPsP6vtAn4VrIslTxrkO
> A31WCsXwnvggSIBLdITCwpJFywqPfpurFhce38Chgznli9E46Pr6dukTC56NhjmB
> Cv7+PTdpJxM3vKFw+OlLrfIrxEFtHbYOTI6q7NgjfVjdbG9LbVgG3JRTmf3tT+GN
> DU165VK7TxvBj68ll05gLECgAtrGFAEQl+51VlfWRZw8wXGFni2X43kEwUpihgHj
> Ci4W1+sBUln0ww+aKa6sRpJTi/s3tKPWckjMY//bDIMfd4gdK7N6CJSrRMbj6Gsw
> gfm1ixWlJJPKVvokH08NKvxcpwvRX4D1RD80WkaCrC7WMKzK8ohmhxxhIDXHmPE8
> kibaJuy1WqQG+G/H00LTGpGkeevyg4/mH2hDxDbDJ5ye1RMA9GsKFC1YpDzugTxO
> zr9lX9QRWpPNEJDXSipdjs27p8hcF+vgwI5eVd5R721wpv17IEg0Lsy4zvvswFik
> t3rIj6wwVYHFoMNpwA/sojaRTGb62nqGREYiGMX4fPPd2OCtl1J4I8oZ3x4Q2gkJ
> WRX98z6a04zMisiGNeTjl7ZkgEjNNW8/XG4J5sFmgSo5p2XwBCINLyWfnYiQporj
> Ym0Ig9k8t5BHntgkP02a+CF9GScdkxNq8UC8Ad2oAHBqOEXd/9DHv80fA7ApvG7e
> HnSzWGDdd63z0ixY0g2I
> =6UrH
> -END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: buildbot exception in ASF Buildbot on tomcat-8-trunk

[sebb]

On 5 October 2015 at 06:08, Christopher Schultz
 wrote:
> All,
>
> On 10/5/15 12:22 AM, build...@apache.org wrote:
>> The Buildbot has detected a build exception on builder tomcat-8-trunk while 
>> building ASF Buildbot. Full details are available at:
>> http://ci.apache.org/builders/tomcat-8-trunk/builds/173
>>
>> Buildbot URL: http://ci.apache.org/
>>
>> Buildslave for this Build: silvanus_ubuntu
>>
>> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' 
>> triggered this build
>> Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1706746
>> Blamelist: schultz
>>
>> BUILD FAILED: exception upload_2
>>
>> Sincerely,
>>  -The Buildbot
>
> I'm fairly confident I haven't broken anything. If I have, please let me
> know how best to diagnose and fix whatever it was.

The final line of the log for the failed svn step [1] says:

Corrupted xml, aborting step

This looks to me like a problem with the buildbot config.

[1] 
https://ci.apache.org/builders/tomcat-8-trunk/builds/173/steps/svn/logs/stdio

> Thanks,
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1686442 - /tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java

[sebb]

On 19 June 2015 at 17:06,   wrote:
> Author: remm
> Date: Fri Jun 19 16:06:55 2015
> New Revision: 1686442
>
> URL: http://svn.apache.org/r1686442
> Log:
> Add IAE, although it cannot happen.
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java
>
> Modified: 
> tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java?rev=1686442&r1=1686441&r2=1686442&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java 
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java Fri 
> Jun 19 16:06:55 2015
> @@ -145,6 +145,9 @@ public final class FastHttpDateFormat {
>  if (cachedDate != null) {
>  return cachedDate.longValue();
>  }
> +if (threadLocalformats == null) {
> +throw new IllegalArgumentException();
> +}
>
>  Long date = null;
>  if (threadLocalformats != null) {

The condition will now always be true, so can be eliminated.

>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1686432 - /tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java

[sebb]

On 19 June 2015 at 16:16,   wrote:
> Author: remm
> Date: Fri Jun 19 15:16:51 2015
> New Revision: 1686432
>
> URL: http://svn.apache.org/r1686432
> Log:
> Remove unused shared formats.
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java
>
> Modified: 
> tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java?rev=1686432&r1=1686431&r2=1686432&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java 
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/http/FastHttpDateFormat.java Fri 
> Jun 19 15:16:51 2015
> @@ -49,16 +49,6 @@ public final class FastHttpDateFormat {
>  new SimpleDateFormat(RFC1123_DATE, Locale.US);
>
>
> -/**
> - * The set of SimpleDateFormat formats to use in getDateHeader().
> - */
> -private static final SimpleDateFormat formats[] = {
> -new SimpleDateFormat(RFC1123_DATE, Locale.US),
> -new SimpleDateFormat("EE, dd-MMM-yy HH:mm:ss zzz", Locale.US),
> -new SimpleDateFormat("EEE  d HH:mm:ss ", Locale.US)
> -};
> -
> -
>  private static final TimeZone gmtZone = TimeZone.getTimeZone("GMT");
>
>
> @@ -66,13 +56,7 @@ public final class FastHttpDateFormat {
>   * GMT timezone - all HTTP dates are on GMT
>   */
>  static {
> -
>  format.setTimeZone(gmtZone);
> -
> -formats[0].setTimeZone(gmtZone);
> -formats[1].setTimeZone(gmtZone);
> -formats[2].setTimeZone(gmtZone);
> -
>  }
>
>
> @@ -166,9 +150,6 @@ public final class FastHttpDateFormat {
>  if (threadLocalformats != null) {

Does it make sense to allow null?
It won't crash, but it won't return anything useful (unless some other
caller has populated the relevant cache entry).

I would have thought it might be more useful to throw an IAE / NPE at
the start of the method if the parameter is null.

>  date = internalParseDate(value, threadLocalformats);
>  updateParseCache(value, date);
> -} else {
> -date = internalParseDate(value, formats);
> -updateParseCache(value, date);
>  }
>  if (date == null) {
>  return (-1L);
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1681300 - in /tomcat/native/trunk: build.properties.default build.xml java/ java/org/ java/org/apache/ java/org/apache/tomcat/ java/org/apache/tomcat/Apr.java java/org/apache/tomcat/a

[sebb]

On 23 May 2015 at 10:44,   wrote:
> Author: rjung
> Date: Sat May 23 09:44:41 2015
> New Revision: 1681300
>
> URL: http://svn.apache.org/r1681300
> Log:
> Make tcnative trunk more consistent with 1.1 branch:
>
> - use externals for jni Java classes, but here
>   pointing to TC trunk
>
> - remove download and copy targets for jni
>   Java classes in build script
>
> - add Apr.java and apr.properties from 1.1a
>
> In addition:
> - use Java 8 in trunk

Is Java 8 really necessary?

If so README.txt needs to be updated.

> - expect next version to be 1.2 instead of 2.0
>
> Added:
> tomcat/native/trunk/java/
> tomcat/native/trunk/java/org/
> tomcat/native/trunk/java/org/apache/
> tomcat/native/trunk/java/org/apache/tomcat/   (with props)
> tomcat/native/trunk/java/org/apache/tomcat/Apr.java   (with props)
> tomcat/native/trunk/java/org/apache/tomcat/apr.properties   (with props)
> Modified:
> tomcat/native/trunk/build.properties.default
> tomcat/native/trunk/build.xml
>
> Modified: tomcat/native/trunk/build.properties.default
> URL: 
> http://svn.apache.org/viewvc/tomcat/native/trunk/build.properties.default?rev=1681300&r1=1681299&r2=1681300&view=diff
> ==
> --- tomcat/native/trunk/build.properties.default (original)
> +++ tomcat/native/trunk/build.properties.default Sat May 23 09:44:41 2015
> @@ -16,8 +16,8 @@
>  #
>
>  # - Version Control Flags -
> -version.major=2
> -version.minor=0
> +version.major=1
> +version.minor=2
>  version.build=0
>  version.patch=0
>  version.suffix=-dev
> @@ -30,8 +30,8 @@ base.path=/usr/share/java
>  #base.path=C:/path/to/the/repository
>  #base.path=/usr/local
>
> -compile.source=1.4
> -compile.target=1.4
> +compile.source=1.8
> +compile.target=1.8
>  compile.debug=off
>  compile.deprecation=on
>  compile.optimize=on
> @@ -39,16 +39,6 @@ compile.optimize=on
>  base-tomcat.loc=http://archive.apache.org/dist/tomcat
>  base-sf.loc=http://downloads.sourceforge.net
>
> -# - Tomcat native Java sources -
> -# The Tomcat 6 version we use for getting the Java sources
> -tomcat.version=6.0.20
> -# The directory containing your source distribution of Tomcat
> -# It will be automatically downloaded if it doesn't exist
> -tomcat.src=${base.path}/apache-tomcat-${tomcat.version}-src
> -#tomcat.src=/usr/local/apache-tomcat-${tomcat.version}-src
> -# The URL used to download Tomcat if needed
> -tomcat.loc=${base-tomcat.loc}/tomcat-6/v${tomcat.version}/src/apache-tomcat-${tomcat.version}-src.tar.gz
> -
>  # - JUnit Unit Test Suite, version 3.8 or later -
>  # The JUnit version we will use
>  junit.version=3.8.2
>
> Modified: tomcat/native/trunk/build.xml
> URL: 
> http://svn.apache.org/viewvc/tomcat/native/trunk/build.xml?rev=1681300&r1=1681299&r2=1681300&view=diff
> ==
> --- tomcat/native/trunk/build.xml (original)
> +++ tomcat/native/trunk/build.xml Sat May 23 09:44:41 2015
> @@ -31,8 +31,8 @@
>  
>  
>  
> -
> -
> +
> +
>  
>  
>  
> @@ -54,8 +54,8 @@
>  
>  
>
> -
> -
> +
> +
>  
>  
>  
> @@ -153,10 +153,6 @@
>  
>
>
> -  
> -
> -
> -  
>
>
>  
> @@ -215,12 +211,6 @@ limitations under the License.-->">
>  
>  
>  
> -
> -
> - dir="${base.path}/apache-tomcat-${tomcat.version}-src/java">
> -
> -
> -
>  
>  
>  
>
> Propchange: tomcat/native/trunk/java/org/apache/tomcat/
> --
> --- svn:externals (added)
> +++ svn:externals Sat May 23 09:44:41 2015
> @@ -0,0 +1 @@
> +^/tomcat/trunk/java/org/apache/tomcat/jni@1678592 jni
>
> Added: tomcat/native/trunk/java/org/apache/tomcat/Apr.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/native/trunk/java/org/apache/tomcat/Apr.java?rev=1681300&view=auto
> ==
> --- tomcat/native/trunk/java/org/apache/tomcat/Apr.java (added)
> +++ tomcat/native/trunk/java/org/apache/tomcat/Apr.java Sat May 23 09:44:41 
> 2015
> @@ -0,0 +1,41 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" 

Re: [SECURITY] CVE-2014-0227 Apache Tomcat Request Smuggling

[sebb]

On 9 February 2015 at 09:12, Mark Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> CVE-2014-0227 Request Smuggling
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> - - Apache Tomcat 8.0.0-RC1 to 8.0.8
> - - Apache Tomcat 7.0.0 to 7.0.54
> - - Apache Tomcat 6.0.0 to 6.0.41
>
> Description:
> It was possible to craft a malformed chunk as part of a chucked request

s/chucked/chunked/?

> that caused Tomcat to read part of the request body as a new request.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - - Upgrade to Apache Tomcat 8.0.9 or later
> - - Upgrade to Apache Tomcat 7.0.55 or later
> - - Upgrade to Apache Tomcat 6.0.43 or later
>   (6.0.42 contains the fix but was not released)
>
> Credit:
> This issue was identified by the Tomcat security team.
>
> References:
> [1] http://tomcat.apache.org/security-8.html
> [2] http://tomcat.apache.org/security-7.html
> [3] http://tomcat.apache.org/security-6.html
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
>
> iQIcBAEBAgAGBQJU2HoOAAoJEBDAHFovYFnn/3wP/A3qNw/M6hrPYGtZJGtHmb3b
> B7VMHvhW18nTVUIuS6pg/FIcLg//dRpzzosHGAygGZJRTqW6am3TF9IEGrtaqXED
> 3cLbIUcIlay8grokG5Ci4fduZ3pouVA8/xbWTW6ND0KORAAsCeeIVVs3+/IdyBrM
> hRMST00A/ryXEBCzUdVATjd7bpdOAnRW/lSUI5/Ap+zQN1SR6rBdF224UaWRiZrr
> 4t55ZnStDQ10OT5a8R/uSZAftnRD3wRzOCquYHA7PbzpjDDmwbz00BQWErmlmgs/
> ElN9Dmdn+/dFaaU9AGOLEhsse3KajfjgdWVXRoB2BJW3/GFgPT9vcHswINEgAZtp
> HoNFavmlZr0bs+1YdSEx8qtitB6Wr4QiwWYzfwLMhZ3qx6g0NSTMY6g+JH7BVIOL
> 3xGf1B42LidgMqqpcyddLW3HFICRI6wX1IgK+rF8Obaga6UOCHgmCKTL4YBxe5XK
> +YqEgH3HE1jwTL04FGsVMSAUIx4Z5wkm0rXsf3emHsyDytFQOyrJqI8AdGVMyOwO
> ZEjqwFDCjW36I2YsoE4HffO/ZnTxJrZzOZOXXt7N7zfFfxXsJsSuBBM3il0VIPyB
> AdmOl1RoeGx5Gj2WGIgXjPLCcOHaNTobClasFMvuzgPmxIHPViT1fhM/M41cre8M
> v3iXCWFfOe15UtdBy57w
> =BK1a
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Recreate missing TC commit emails

[sebb]

On 6 December 2014 at 16:48, Rainer Jung  wrote:
> Am 06.12.2014 um 15:17 schrieb sebb:
>>
>> On 6 December 2014 at 13:19, Rainer Jung  wrote:
>>>
>>> The following commit emails are missing currently for the TC project:
>>>
> ...
>
>>> The list was crated by comparing the mails that I received with the svn
>>> log
>>> of the main tomcat directory.
>>>
>>> I wrote a simple perl script that gets the log and commit data from svn
>>> and
>>> sends a mail similar to the normal commit email. The mails will come from
>>> me
>>> and the subject will be
>>>
>>> [BACKUP] svn commit:
>>>
>>> to make them distinguishable from the automated ones.
>>
>>
>> INFRA already have a script to do this. It resends the exact original
>> e-mail.
>> (The only obvious difference is the time of the e-mail)
>> I had assumed that it was part of the subversion toolkit, but perhaps
>> it is homegrown.
>
>
> I guess infra still has higher priorities. I wanted to provide an interim
> solution for the projects I'm involved with.
>
>> Using a different subject line might cause some tools/mailing list
>> rules to break; might be better to add [RESEND] to the body.
>
>
> I have deliberately chosen this subject to not indicate the mail would be
> authoritative.

Good point.

> It wouldn't harm if we get the original emails, once infra

ditto

> has sorted out a repos wide solution to send the missing mails.

Last time SVN mails were lost, I think each project had to ask for
their missing mails.

If INFRA don't plan on resending the emails automatically, it may well
be worth asking for the Tomcat project specifically so the archives
are complete.

Infra may be able to set the correct sender as well, so it looks more
like the original.


>
> Regards,
>
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Recreate missing TC commit emails

[sebb]

On 6 December 2014 at 13:19, Rainer Jung  wrote:
> The following commit emails are missing currently for the TC project:
>
> r1643041
> r1643045
> r1643054
> r1643055
> r1643065
> r1643066
> r1643069
> r1643100
> r1643104
> r1643109
> r1643121
> r1643126
>
> The list was crated by comparing the mails that I received with the svn log
> of the main tomcat directory.
>
> I wrote a simple perl script that gets the log and commit data from svn and
> sends a mail similar to the normal commit email. The mails will come from me
> and the subject will be
>
> [BACKUP] svn commit:
>
> to make them distinguishable from the automated ones.

INFRA already have a script to do this. It resends the exact original e-mail.
(The only obvious difference is the time of the e-mail)
I had assumed that it was part of the subversion toolkit, but perhaps
it is homegrown.

Using a different subject line might cause some tools/mailing list
rules to break; might be better to add [RESEND] to the body.

> I'll send the 12 mails out in a few minutes.
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1629770 - /tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml

[sebb]

On 6 October 2014 22:38,   wrote:
> Author: rjung
> Date: Mon Oct  6 21:38:24 2014
> New Revision: 1629770
>
> URL: http://svn.apache.org/r1629770
> Log:
> Typo in changelog.
>
> Modified:
> tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
>
> Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
> URL: 
> http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1629770&r1=1629769&r2=1629770&view=diff
> ==
> --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
> +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Mon Oct  6 21:38:24 2014
> @@ -45,7 +45,7 @@
>
>  
>
> -57060: Alow building out of source tree.
> +57060: Allow building out of source tree.

s/out of/from outside/

"Out of" is ambiguous; in this context it would normally be read as
meaning "using the source tree" or similar.

>  Patch contributed by Petr Sumbera. (rjung)
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Tomcat BCEL and Commons BCEL

[sebb]

It seems that Tomcat's version of BCEL is diverging significantly from
Commons BCEL.

Is there any mileage in trying to re-organise Commons BCEL so it is
more easily usable by Tomcat?

For example, I gather that Tomcat only uses a small portion of Commons BCEL.
Maybe the Commons code could be divided in some way to reflect this need?
There are probably other projects that just need the read-only parts of BCEL.

Tomcat would presumably still need to change the package name, but
that can be automated as is done for Commons Pool.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1622302 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/Request.java test/org/apache/catalina/connector/TestRequest.java test/org/apache/catalina/connector/TesterReq

[sebb]

On 4 September 2014 10:52, Mark Thomas  wrote:
> On 04/09/2014 10:50, Mark Thomas wrote:
>> On 04/09/2014 10:16, Mark Thomas wrote:
>>> On 04/09/2014 10:11, Mark Thomas wrote:
 On 04/09/2014 08:05, Martin Grigorov wrote:
> On Wed, Sep 3, 2014 at 8:37 PM,  wrote:
>
>> Author: markt
>> Date: Wed Sep  3 17:37:51 2014
>> New Revision: 1622302

 
>> ---
>> tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestRequest.java
>> (original)
>> +++
>> tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestRequest.java
>> Wed Sep  3 17:37:51 2014
>> @@ -28,6 +28,7 @@ import java.net.URL;
>>  import java.util.ArrayList;
>>  import java.util.Enumeration;
>>  import java.util.List;
>> +import java.util.Locale;
>>  import java.util.TreeMap;
>>
>>  import javax.servlet.ServletException;
>> @@ -40,6 +41,7 @@ import static org.junit.Assert.assertNot
>>  import static org.junit.Assert.assertTrue;
>>  import static org.junit.Assert.fail;
>>
>> +import org.junit.Assert;
>>  import org.junit.Test;
>>
>>  import org.apache.catalina.Context;
>> @@ -660,7 +662,7 @@ public class TestRequest extends TomcatB
>>  writer.append("Content-Disposition: form-data;
>> name=\"part\"\r\n");
>>  writer.append("Content-Type: text/plain; 
>> charset=UTF-8\r\n");
>>  writer.append("\r\n");
>> -writer.append("äö").append("\r\n");
>> +writer.append("��").append("\r\n");
>>
>
> It looks like there is an encoding issue here ?!

 No. There is a known issue with the code that generates the commit mails
 and UTF-8.
>>>
>>> Saying that, that diff does look a little odd. The original looks more
>>> reasonable but looking back at the history with viewvc shows the same
>>> unprintable characters throughout which is odd.
>>>
>>> I wonder if there is a platform related thing going on here. The tests
>>> pass - which is the main thing - but I'll do some more digging on this.
>>
>> Looks like the commit mailer issue is fixed (I haven't checked for a
>> while).
>
> I take that back. The mailer isn't fixed. viewvc is fine.

The SVN mailer needs to know the file encoding.

For a specific file, one can add a property:

svn pset svnmailer:content-charset utf-8  TestRequest.java

If this is not defined, then the mailer looks for the property in
parent directories [1]

It's possible that the default it is detecting is ASCII or similar.

[1] http://opensource.perlig.de/svnmailer/doc-1.0/#groups-charset-property

> Mark
>
>> viewvc also shows UTF-8 correctly as well.
>>
>> Moral of this thread. If we see something that looks like character
>> corruption in commit logs or viewvc then now it probably is.
>>
>> Note that Windows uses cp1252 by default rather than UTF-8. I suspect
>> that that is where the corruption sneaked in and I have changed the
>> default for my Windows dev environment.
>>
>> Corruption fixed in trunk and 7.0.x.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: git (yet again)

[sebb]

On 3 September 2014 16:10, Martin Grigorov  wrote:
> On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig  wrote:
>
>> On 2014-09-03, sebb wrote:
>>
>> > Maybe it's possible to configure the commit messages so that diffs are
>> > shown; if not, then perhaps there needs to be a convention for how to
>> > comment on commits.
>>
>> Might be something that can be configured per project, we do get diffs
>> for commits in Ant-land: for example
>>
>> http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
>
>
> Diffs in mail notifications come for free in the ASF Git setup.

OK, good.

I was going by the infra puppet diffs on  infrastructure-cvs which
only have a compare URL.

But it seems these are github commits.

> Commenting on diffs in the email is not the important thing. Having an
> email means that another committer (i.e. someone with more knowledge) did
> something.
> The new thing is being able to comment on "the patch" (the Pull Request)
> provided by a contributor *before* it gets in the repo. Usually the
> contributors don't have the whole picture.

Yes, this would be useful.

However, it is fairly common for Tomcat committers to comment on each
other's commits, either as part of CTR or sometimes to provide
feedback. etc.
A quick scan of some recent commits shows 5-10% with comments.

>
>>
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: git (yet again)

[sebb]

On 3 September 2014 10:41, Rainer Jung  wrote:
>
> Am 02.09.2014 um 18:41 schrieb Mark Thomas:
>
>> I've been looking at this again (anything to get a break from writing
>> parsers for cookies) and chatting with some of the infra folks that look
>> after the ASF's git repos.
>>
>> There are a couple of things we need to do:
>> a) decide how we want to organise development in git
>> b) decide if we want to move to git
>>
>> Now the decision we make for a) might influence some folks to make a
>> different decision for b). On the other hand, there is no point debating
>> a) if we are never going to move.
>>
>> So, how do folks want to approach this?
>
>
>> A: Vote to move to git and then figure out how best to use it? or
>> B: Agree our git workflows and then have a vote on moving to git with
>> those workflows?
>>

There's one aspect of Git that does not seem to have been covered here:
the commit messages don't seem to include what was actually changed.

So in order to review a commit, it is necessary to click the link.
In turn, this makes it harder to comment on a change.
This is something that happens quite frequently with the SVN commit messages.

Maybe it's possible to configure the commit messages so that diffs are
shown; if not, then perhaps there needs to be a convention for how to
comment on commits.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: git (yet again)

[sebb]

On 2 September 2014 20:25, Filip Hanik  wrote:
> On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat  wrote:
>
>> 2014-09-02 18:41 GMT+02:00 Mark Thomas :
>>
>> > I'm leaning towards A myself.
>>
>
>
> The move to git clears a huge hurdle, and that is managing contributions.
> The patch system is very difficult, and impossible to maintain. A pull
> request stays alive
> and can be maintained through code changes
> . I believe we can get more contributions by moving to Git.
>
>
>
>> >
>>
>> Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
>> we should also move to it first, then think about how to use it later,
>> otherwise people will never vote in favor)
>>
>
> Let's skip Maven and move straight to Gradle, it has the benefit of not
> needing a build system installed on the developers machine, as it gets
> downloaded by the wrapper checked into the repo. This is yet one less

AIUI the wrapper is not source, it is binary.
Generally only source code is allowed in repos, so will this cause an issue?

> version that is required by the contributor.
> It's built on top of Ant, and should give us all the flexibility we need.
>
>
>>
>> :)
>>
>> Rémy
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "Security/Heartbleed" by KonstantinKolinko

[sebb]

On 18 April 2014 14:56, Apache Wiki  wrote:

> The "Security/Heartbleed" page has been changed by KonstantinKolinko:

> https://wiki.apache.org/tomcat/Security/Heartbleed?action=diff&rev1=10&rev2=11
> +  1. Update OpenSSL to a version that includes the fix. The natural version 
> number for this is 1.0.1g, though some package maintainers have chosen to 
> back-port their fixes to versions with a lower patch-level. Among such 
> maintainers are Debian and probably also Debian-based distributions such as 
> Ubuntu.<><>Tomcat Native 1.1.30 and later include patched versions of 
> OpenSSL.<><>To install updated Tomcat Native on Windows without 
> updating Tomcat itself you have to 
> [[http://tomcat.apache.org/download-native.cgi|download it]] and replace 
> `tcnative-1.dll` in your installation with a new one.

Just wondering - is tcnative-1.dll backwards compatible with all
versions of Tomcat?
i.e. if they have an old version of Tomcat and just replace tcnative
will that work OK?

Might be worth pointing to a page that describes the version compatibility.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Bug 50078] Concurrent access to WeakHashMap in ConcurrentCache causes infinite loop, 100% CPU usage

[sebb]

On 16 April 2014 11:04, Mark Thomas  wrote:
> On 16/04/2014 10:56, Konstantin Kolinko wrote:
>> 2014-04-16 13:48 GMT+04:00 Mark Thomas :
>>> On 16/04/2014 10:36, bugzi...@apache.org wrote:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=50078

 --- Comment #4 from Andrea Wilson  ---
>>>
>>> This idiot has had their account locked. I also deleted the spam comment.
>>>
>>
>> There is also a spam comment here (#25)
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43327
>
> I'll delete that in a sec - after I have done a global search for
> comments with that text.

The same happened on Feb 17, with the same text (different e-mail):

https://issues.apache.org/bugzilla/show_bug.cgi?id=53969

--- Comment #3 from Jackie Rosen  ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain 
Page where seen: 
Marked for reference. Resolved as fixed @bugzilla.

Just wondering: does Bugzilla support any form of BadContent checking?

> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [off-list] Heartbleed info

[sebb]

On 14 April 2014 21:34, Mark Thomas  wrote:
> On 14/04/2014 20:45, Tim Whittington wrote:
>>
>> On 15/04/2014, at 1:26 am, Christopher Schultz 
>>  wrote:
>>
>>> Mark,
>>>
>>> On 4/13/14, 10:29 AM, Mark Thomas wrote:
 On 13/04/2014 08:18, Christopher Schultz wrote:
> Mark,
>
> On 4/13/14, 10:10 AM, Mark Thomas wrote:
>> On 13/04/2014 08:09, Christopher Schultz wrote:
>>> All,
>>>
>>> I've taken the liberty of creating a Heartbleed info page on
>>> the wiki. I'm going to add a mention of it under the "Not a
>>> vulnerability in Tomcat" section for the security pages for
>>> Tomcats 6, 7, and 8.
>>
>> And tc-native please.
>>
>>> Shall I also add something to the home page as well? Or shall
>>> we just roll that into the upcoming announcement of tcnative
>>> 1.1.30? I kind of think it should do with the tcnative
>>> announcement, but Mladen hasn't yet closed the vote, published
>>> the build, etc. and I wanted to get something up sooner rather
>>> than later.
>>
>> +1 to the native announcement.
>>
>>> Does anyone have any suggestions for how to proceed?
>>
>> Your plan looks good to me.
>
> Okay, good. I've updated the Tomcat security info (will do
> tcnative soon). Once I've done that, what's the process to actually
> refresh the website? I re-built and committed the .html files from
> svn already.

 That is all you need to do. The site should update a few seconds later.
>>>
>>> Great, I can see my updates posted, now.
>>>
>>> I neglected to change my password in the open window set by the infra
>>> team, so it's been reset. The web-based reset tool isn't working for me
>>> so I sent a message to r...@apache.org explaining the situation. I
>>> haven't heard back, yet.
>>>
>>> So I'm a little stuck until I can get a password reset. I can access
>>> people.apache.org with my ssh2 key. Is this something you might be able
>>> to goose-along?
>>>
>>
>> http://id.apache.org/reset/ worked for me, but it might require a GPG key 
>> registered in your profile (my reset came GPG encrypted).
>
> id.a.o does not require GPG but if you have a public key set then it
> will always use it. If you have lost your private key and forgotten your
> password root can remove the key from the ID if you ask nicely.
>
> The alternative is to ssh to people.a.o with you ssh key and use passwd.

Did not know about that option.
Should that be added here [1] ?

I'm happy to update the page if so.

[1] https://www.apache.org/dev/infra-contact#regain-account

> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Bug 56248] Automatic deployment with TCD deletes customized context.xml file

[sebb]

On 13 March 2014 15:30,   wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56248
>
> Mark Thomas  changed:
>
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
>
> --- Comment #1 from Mark Thomas  ---
> This has been fixed in 8.0.x for 8.0.4 onwards and in 7.0.x for 5.0.53 
> onwards.

5.0.53 ??

> --
> You are receiving this mail because:
> You are the assignee for the bug.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git

[sebb]

AIUI SVN will still be mandated by Infra for
- release publishing
- site publishing

Release publishing should not cause an issue.

However site publishing may perhaps be tricker to do from a GIT repo;
might need to consider leaving site docs in SVN.

On 24 February 2014 17:43, Jeremy Boynes  wrote:
> Setting aside Maven and Gradle, did we reach any consensus on Git?
>
> On Jan 26, 2014, at 5:34 PM, Costin Manolache  wrote:
>
>> Gradle is becoming the standard build tool for android.
>> I didn't like it at first - I don't really see the point of groovy - but
>> it's still better than 'programming'
>> in ant, and you don't have to touch any XML. You can use any ant task from
>> gradle - best to think of it as a non-xml ant file, with reasonable
>> defaults and less typing for the most common operations.
>>
>> Git is best.
>>
>> Costin
>>
>>
>> On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat  wrote:
>>
>>> 2014/1/21 Yoav Shapira 
>>>
 Also +1 to separating the git vs svn discussion from the build system
 discussion (Maven, Ant, whatever.) (Side note: been using gradle
 recently, fun.)

>>>
>>> +1
>>>
>>> Never used that Gradle yet though.
>>>
>>> Rémy
>>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: ASF svn server certficate + svn client

[sebb]

On 21 February 2014 16:09, sebb  wrote:
> The certs were changed recently. The new fingerprints should be on the
> infra website somewhere.
>
> A quick search found the outdated details for svn.apache.org:
>
> http://www.apache.org/dev/version-control.html#cert

I've updated the details.

> The uptodate list seems to be here:
>
> http://www.apache.org/dev/machines.html#ssl-keys
>
>
> On 21 February 2014 15:59, Christopher Schultz
>  wrote:
>> All,
>>
>> I just tried to do an 'svn up' for tcnative and I got this response:
>>
>> $ svn up
>> Updating '.':
>> Error validating server certificate for 'https://svn.apache.org:443':
>>  - The certificate is not issued by a trusted authority. Use the
>>fingerprint to validate the certificate manually!
>> Certificate information:
>>  - Hostname: *.apache.org
>>  - Valid: from Feb  7 00:00:00 2014 GMT until Apr  7 23:59:59 2016 GMT
>>  - Issuer: Thawte, Inc., US
>>  - Fingerprint: DD:73:02:E6:4F:9E:FC:48:82:CC:61:68:F6:98:F0:AA:66:43:84:78
>> (R)eject, accept (t)emporarily or accept (p)ermanently?
>>
>> Is this just a problem with Subversion? I notice that the cert is a
>> wildcard cert but the error is about the CA. Am I missing something?
>>
>> I use brew to install recent svn versions onto Mac OS X Mavericks, and I
>> made sure I was using the latest svn version available via brew. Firefox
>> seems happy, so I suspect it's just a missing CA intermediate
>> certificate or something.
>>
>> Any suggestions?
>>
>> Thanks,
>> -chris
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: ASF svn server certficate + svn client

[sebb]

The certs were changed recently. The new fingerprints should be on the
infra website somewhere.

A quick search found the outdated details for svn.apache.org:

http://www.apache.org/dev/version-control.html#cert

The uptodate list seems to be here:

http://www.apache.org/dev/machines.html#ssl-keys


On 21 February 2014 15:59, Christopher Schultz
 wrote:
> All,
>
> I just tried to do an 'svn up' for tcnative and I got this response:
>
> $ svn up
> Updating '.':
> Error validating server certificate for 'https://svn.apache.org:443':
>  - The certificate is not issued by a trusted authority. Use the
>fingerprint to validate the certificate manually!
> Certificate information:
>  - Hostname: *.apache.org
>  - Valid: from Feb  7 00:00:00 2014 GMT until Apr  7 23:59:59 2016 GMT
>  - Issuer: Thawte, Inc., US
>  - Fingerprint: DD:73:02:E6:4F:9E:FC:48:82:CC:61:68:F6:98:F0:AA:66:43:84:78
> (R)eject, accept (t)emporarily or accept (p)ermanently?
>
> Is this just a problem with Subversion? I notice that the cert is a
> wildcard cert but the error is about the CA. Am I missing something?
>
> I use brew to install recent svn versions onto Mac OS X Mavericks, and I
> made sure I was using the latest svn version available via brew. Firefox
> seems happy, so I suspect it's just a missing CA intermediate
> certificate or something.
>
> Any suggestions?
>
> Thanks,
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Improvement fo org.apache.tomcat.util.net.jsse.JSSESupport class

[sebb]

On 5 February 2014 15:14, Mark Thomas  wrote:
> On 05/02/2014 14:56, Maxim Kirilov wrote:
>> Hi,
>>
>> I've noticed that some code inside *handshake()* method can be omitted.
>> After executing the
>> call to: *ssl.startHandshake()*, according to SSLSocket
>> javadoc,
>> after returning from this call the negotiated handshake is complete. So the
>> following code that tries to read bytes from the socket
>> is useless since errors during handshake process would be thrown earlier.
>>
>> Am I missing something?
>
> Look at the history of that file in svn to see why the code is there.
> Once you know why that code was written, you can make an informed
> decision as to whether or not it should still be there.

If the svn log is necessary to understand the code, it seems to me
that the code needs to be commented with the relevant information.

After all, the ASF releases source, and that does not include the svn history.

> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Permissions to create release directory for taglibs?

[sebb]

On 2 January 2014 22:24, Jeremy Boynes  wrote:
> On Dec 29, 2013, at 3:10 PM, Mark Thomas  wrote:
>>
>> > I’ve uploaded a copy of the source release here:
>> > https://dist.apache.org/repos/dist/dev/tomcat/taglibs/taglibs-standard-1.2.1/
>> >
>> >  Is that what you had in mind? Do I just svn mv that to “release”
>> > when done?
>>
>> Yes and yes.
>
> I am trying to create the parent directory for this but do not have 
> permission:
> $ svn --username jboynes mkdir 
> https://dist.apache.org/repos/dist/release/tomcat/taglibs -m"create release 
> directory for taglibs"
> svn: E175013: Access to '/repos/dist/!svn/ver/3994/release/tomcat’ forbidden
>
> Am I going about this the wrong way or do I just not have enough karma?

No and yes!

AIUI the default permission scheme set up by Infra is to restrict
dist/release to PMC members.

I guess the PMC could ask to have this changed for Tomcat.

> Thanks
> Jeremy
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "Cookies" by markt

[sebb]

On 1 January 2014 18:32, Jeremy Boynes  wrote:
> On Dec 31, 2013, at 12:46 PM, Mark Thomas  wrote:
>
>> Signed PGP part
>> On 31/12/2013 20:29, Mark Thomas wrote:
>> > On 31/12/2013 17:03, Jeremy Boynes wrote:
>> >> On Dec 31, 2013, at 3:55 AM, Mark Thomas 
>> >> wrote:
>> >
>> >>> On 31/12/2013 11:39, Apache Wiki wrote:
>>  Dear Wiki user,
>> 
>>  You have subscribed to a wiki page or wiki category on
>>  "Tomcat Wiki" for change notification.
>> 
>>  The "Cookies" page has been changed by markt:
>>  https://wiki.apache.org/tomcat/Cookies
>> 
>>  New page: #acl AdminGroup:read,write All:read ##language:en
>> 
>>  = Cookies =
>> >
>> >> I’m not able to edit that page - is the acl right?
>> >
>> > No, it isn't. It was copied from another page. I'll go through the
>> > wiki and check all of the pages.
>>
>> Try now. I just got locked out for requesting too many pages too fast
>> but I think the cookie page should be editable by anyone in the
>> contributors group now. If you aren't in that group reply with your
>> wiki ID and someone will add you.
>
> I still don’t have an “Edit” action - my wiki id is jboynes.

Not surprising, as you were not in the ContributorsGroup - see the
second para on the Front page.

Try again now.

> Thanks
> Jeremy
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.0.0-RC10

[sebb]

On 19 December 2013 18:38, Mark Thomas  wrote:
> The proposed Apache Tomcat 8.0.0 release candidate 10 is now available
> for voting.
>
> Given this is a release candidate I am working on the basis that it is
> equivalent to an alpha. The main changes since RC5 are:
> - Better handling of generic types in the WebSocket 1.0 implementation
> - Refactor resource handling for the class loader
> - Add Cobertura support to the unit tests
> - Remove anti-Jar locking feature and replace it with open stream
>   tracking
> - Update to a post Commons Pool 2.0 release snapshot
> - Complete refactoring of TLD handling including caching of parsed TLDs
> - More consistent handling of XML validation options
> - Much more detailed visibility of DBCP connections pools in JMX
> - Better organisation of JMX beans in the default JConsole view
> - Performance improvements
> - Numerous bug fixes
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC10/

I get 404 for that URL

> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-002/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC10/

The NOTICE & LICENSE files in the source archive mention various 3rd
party items of software that are not actually included in the source
archive.
AIUI, it is vital that the N&L files *only* reference the bits that
are actually included in the distribution to which they apply [1]

Also, some of the NOTICE entries look as though they may be
superfluous anyway [2]


[1] http://www.apache.org/dev/licensing-howto.html#step-by-step (see 3.)
[2] http://www.apache.org/dev/licensing-howto.html#mod-notice

> The proposed 8.0.0-RC10 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 8.0.0-RC10 alpha
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] Apache Tomcat Native 1.1.29 released

[sebb]

Thanks!

On 19 December 2013 10:09, Konstantin Kolinko  wrote:
> 2013/12/16 sebb :
>> On 15 October 2013 14:53, Mladen Turk  wrote:
>>> The Apache Tomcat team announces the immediate availability of Apache
>>> Tomcat Native 1.1.29 stable.
>>
>> Please can someone now remove the old version?
>>
>> https://dist.apache.org/repos/dist/release/tomcat/tomcat-connectors/native/1.1.28/
>>
>
>
> Done.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1551729 - /tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java

[sebb]

On 17 December 2013 21:43,   wrote:
> Author: rjung
> Date: Tue Dec 17 21:43:02 2013
> New Revision: 1551729
>
> URL: http://svn.apache.org/r1551729
> Log:
> Fix occasional test failure.
>
> The WebSocketClient first read headers via
> a BufferedReader, then tried to read the body
> via the underlying InputStream. Depending on
> the structure of the incoming packets reading
> the body failed because some bytes were already
> buffered in the reader and no longer available
> by the stream. The switch between rader and stream
> was motivated, because the decoding also had to
> switch from ISO-8859-1 (headers) to UTF-8 (body).
>
> We now simulate a rudimentary reader which always
> reads from the stream and allows to change the
> decoding charset while reading.

It would be helpful to include this log message in the code comments.

The commit log is basically ephemeral - it should (only) document why
the commit was made.
In this case "Fix occasional test failure." would be sufficient.

Comments that may be needed to understand why the code behaves in a
particular way belong as comments in the code.
After all, the mission of the ASF is to release source, which should
be able to stand on its own.

> Modified:
> tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java
>
> Modified: 
> tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java?rev=1551729&r1=1551728&r2=1551729&view=diff
> ==
> --- 
> tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java 
> (original)
> +++ 
> tomcat/tc7.0.x/trunk/test/org/apache/catalina/websocket/TestWebSocket.java 
> Tue Dec 17 21:43:02 2013
> @@ -16,13 +16,11 @@
>   */
>  package org.apache.catalina.websocket;
>
> -import java.io.BufferedReader;
> +import java.io.BufferedInputStream;
>  import java.io.IOException;
>  import java.io.InputStream;
> -import java.io.InputStreamReader;
>  import java.io.OutputStream;
>  import java.io.OutputStreamWriter;
> -import java.io.Reader;
>  import java.io.Writer;
>  import java.net.InetSocketAddress;
>  import java.net.Socket;
> @@ -382,12 +380,11 @@ public class TestWebSocket extends Tomca
>
>  private static class WebSocketClient {
>  private OutputStream os;
> -private InputStream is;
>  private boolean isContinuation = false;
>  final String encoding = "ISO-8859-1";
> -private Socket socket ;
> -private Writer writer ;
> -private BufferedReader reader;
> +private Socket socket;
> +private Writer writer;
> +private CustomReader reader;
>
>  public WebSocketClient(int port) {
>  SocketAddress addr = new InetSocketAddress("localhost", port);
> @@ -397,9 +394,7 @@ public class TestWebSocket extends Tomca
>  socket.connect(addr, 1);
>  os = socket.getOutputStream();
>  writer = new OutputStreamWriter(os, encoding);
> -is = socket.getInputStream();
> -Reader r = new InputStreamReader(is, encoding);
> -reader = new BufferedReader(r);
> +reader = new CustomReader(socket.getInputStream(), encoding);
>  } catch (Exception e) {
>  throw new RuntimeException(e);
>  }
> @@ -449,28 +444,100 @@ public class TestWebSocket extends Tomca
>  }
>
>  private String readMessage() throws IOException {
> -ByteChunk bc = new ByteChunk(125);
> -CharChunk cc = new CharChunk(125);
>
>  // Skip first byte
> -is.read();
> +reader.read();
>
>  // Get payload length
> -int len = is.read() & 0x7F;
> +int len = reader.read() & 0x7F;
>  assertTrue(len < 126);
>
>  // Read payload
> -int read = 0;
> -while (read < len) {
> -read = read + is.read(bc.getBytes(), read, len - read);
> +reader.setEncoding("UTF-8");
> +return reader.read(len);
> +}
> +/*
> + * This is not a real reader but just a thin wrapper around
> + * an input stream that allows to switch encoding during
> + * reading.
> + * An example is reading headers using ISO-8859-1 and a body
> + * using UTF-8.
> + * The class is not thread-safe and not well-performing.
> + */
> +private class CustomReader {
> +private InputStream is;
> +private String encoding;
> +private boolean markSupported;
> +private B2CConverter b2c;
> +
> +public CustomReader(InputStream is, String encoding) throws 
> IOException {
> +this.is = new BufferedInputStream(is);
> +thi

Re: [ANN] Apache Tomcat Native 1.1.29 released

[sebb]

On 15 October 2013 14:53, Mladen Turk  wrote:
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat Native 1.1.29 stable.

Please can someone now remove the old version?

https://dist.apache.org/repos/dist/release/tomcat/tomcat-connectors/native/1.1.28/

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tagging 7.0.47

[sebb]

Please note https://issues.apache.org/bugzilla/show_bug.cgi?id=55663

The text in the NOTICE file is wrong.

On 17 October 2013 13:15, Violeta Georgieva  wrote:
> Hi,
>
> I'm starting with Tomcat 7.0.47 tagging.
>
> Regards
> Violeta

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]

[sebb]

On 2 October 2013 06:18, Mladen Turk  wrote:
> On 10/01/2013 07:32 PM, sebb wrote:
>>
>>
>> If a Java application succeeds in crashing the JVM, then IMO the JVM
>> has a bug. I believe that all native code should strive to behave the
>> same way.
>>
>
> This is conceptual difference.

Partly.

> Most of those checks are done again inside Java.
> However inside JVM the Java API hides its native methods and
> ensures params are validated.
> Our API is Servlet spec and our VM is Tomcat.

AFAIK tcnative does not hide its native methods.
If it did, I agree it should be possible to guarantee correct
parameters, regardless of application code behaviour.

> All the invalid data should be checked in java part which can be
> invalid as part of normal operation. Our native code already checks
> for some invalid data which can be invalid in such situations.
> OTOH invalid data passed to native caused by bug is just that, a bug.
> So fix the bug and you won't need the check.

The problem is that bugs that reveal themselves as JVM crashes are
much harder to debug.

> We can add compile time '#if defined(MAINTAINER_MODE) ... #endif' checks
> for easier debugging at development,

Any crashes that occur in a released version of TC are likely to be
fairly rare, otherwise they would be detected in testing.
So the MAINTAINER_MODE is not likely to be much use after the initial
shakedown period.
Unless the debugging checks are expensive, why not leave them in?

> but all the checks inside native method
> can be equally well coded before the actual JNI call and since our API is
> servlet
> and no use code can pass beyond that.
>

Tomcat code that calls tcnative directly needs to validate its
parameters; the more places that TC code has direct access to
tcnative, the more likely that some checks will be overlooked. And
more effort will be required to retro-fit any extra checks that are
found necessary.

Also AIUI tcnative code may be used separately from Tomcat.

>
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]

[sebb]

On 1 October 2013 15:47, Christopher Schultz
 wrote:
> Mladen,
>
> On 10/1/13 10:39 AM, Mladen Turk wrote:
>> On 10/01/2013 04:15 PM, Christopher Schultz wrote:
>>> Mladen and Rainer,
>
> -1. You are just hiding the reason for crash.
>>>
>>> I disagree: the reason for the crash can still be reported. It just
>>> won't be reported with a JVM crash: instead, there will be an exception.
>>
>> I disagree on your disagreement :)
>
> ;)
>
> Just to be sure: I'm not arguing against fixing the Java code, or
> providing checks in the Java code to avoid SIGSEGVs. I'm just saying
> that native code should be as safe as reasonably possible. NULL-checks
> are cheap, too, so I don't think there's any reason to avoid them in
> native code.
>
>> This can be easily done in Java with much cheaper computing cost.
>
> Agreed. Feel free to avoid native calls if you know the data is bad. But
> we can't force people to use specific versions of Tomcat and tcnative
> together (though obviously, newer versions of Tomcat can refuse to load
> older versions of tcnative). Someone pointed out in Bugzilla (though it
> mostly fell on deaf ears) that tcnative isn't used exclusively for
> Tomcat: some folks are using it as a convenient library to access APR
> and other native capabilities in a Java wrapper.
>
>> If you suspect the data fed to native call can be faulty, well check it
>> and throw java exception instead calling native, and distinguishing
>> between valid
>> and error return values from native and then still have a code which will
>> pass/throw.
>
> I was suggesting throwing an exception directly from native code, not
> trying to return a status code and then throwing from Java-land.
>
>> I know it requires a different thinking then average library,
>> but it's not an average library. It's wrapper for APR and APR expects you
>> provide valid data.
>>
>> Even checking in native won't solve crashes. You can fed a long (pointer)
>> which is in zombie state (closed but not null) and you'll have a memory
>> location which will pass null check but can still crash or even corrupt
>> other memory location if it was reused by another alloc.
>
> Sure, but a NULL-check (whether in Java or C) isn't going to catch that
> either way, and nothing we've been discussing here will have any bearing
> on that situation: it will still fail, it will likely still crash or
> behave strangely and ...
>
>> Much harder to track down.
>
> ... it will be hard to track down. Adding NULL-checks will not
> complicate any of that. It will not mask any of that. It will make it no
> more difficult to track-down or debug. It will only prevent the JVM
> going down when a pointer ends up being NULL, which is the only reason
> I'm suggesting it.
>
> Given the two -1s and lack of any +1s on this suggestion, I won't be
> committing anything, but I still think it's a worthwhile endeavor
> because it's so easy to do and protects us from such disastrous results.

+1 (non-binding!)

I agree with Mladen that relying on tcnative to do all the validation
is wrong; the Java code should be written so as to only pass valid
parameters. But mistakes happen, and not all applications using
tcnative are written by Tomcat developers who should be familiar with
the calling conventions.

The JVM throws an exception if a Java application uses an invalid
array index or tries to read past the end of an iterator. That does
not mean that Java applications should use these exceptions as part of
standard coding; of course the application should try to use valid
parameters. The point is that such exceptions make debugging much
easier. If Java crashed whenever an invalid parameter was provided, it
would not be very popular with developers.

If a Java application succeeds in crashing the JVM, then IMO the JVM
has a bug. I believe that all native code should strive to behave the
same way.

> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: International characters in source files and SVN commit messages (was: RE:r1525975)

[sebb]

On 26 September 2013 23:29, Konstantin Kolinko  wrote:
> 2013/9/26 sebb :
>> On 25 September 2013 17:02, Konstantin Preißer  wrote:
>>> Mark,
>>>
>>>> -Original Message-
>>>> From: Mark Thomas [mailto:ma...@apache.org]
>>>> Sent: Wednesday, September 25, 2013 5:54 PM
>>>
>>>> I'd say yes. Property files are a 'special' case:
>>>> http://stackoverflow.com/questions/4659929/how-to-use-utf-8-in-
>>>> resource-properties-with-resourcebundle
>>>
>>> OK, thank you for the clarification.
>>>
>>>> It doesn't bother me but I'm only one committer. I think this falls
>>>> under the category if someone cares enough about the commit e-mails
>>>> using UTF-8 then they need to work with infra to make that happen. I'm
>>>> happy with things as they are.
>>
>> There is a property that can be used to change the encoding used by
>> the SVN mailer, for example:
>>
>> svn:mime-type text/xml; charset=utf-8
>>
>> Make sure this agrees with the contents and any xml encoding attribute.
>>
>
> -1 for changing svn:mime-type in such a way.
> Placing an encoding into svn:mime-type is wrong, as
> a) It is not portable. (Git does not have svn properties).

There are other svn properties that are required, so that does not make sense.

> b) It is hard to keep in sync.  Beware that case may matter for some
> software (UTF-8 vs utf-8).

How often does the encoding change?

> ( c) You may be relying on an undocumented feature. I remember some
> long discussions several years ago on whether file encoding can be
> part of svn:mime-type, or it should be a separate property, with no
> clear outcome.

See http://opensource.perlig.de/svnmailer/doc-1.0/#groups-charset-property

> http://subversion.tigris.org/issues/show_bug.cgi?id=2329
> http://subversion.tigris.org/issues/show_bug.cgi?id=2194
> )
>
> Regarding whoweare.xml file,  you need to add explicit encoding to the
> top of the file (like it is done in
> tc7.0.x/trunk/webapps/docs/changelog.xml).  Without that I consider
> those files as ISO-8859-1, like the rest of our sources.

The default for XML is UTF-8.

>
> I think commit mailer should treat the files as ISO-8859-1, as such

XML is UTF-8 by default

> interpretation does not lose any data and as that is the format of
> unified diff.

Not sure about those last two assertions.

> In the past there were several cases when accented characters in
> Tomcat's changelog files were corrupted during editing (due to a
> conversion done in someone's editor). It was seen in commit message.
> Last time it happened two or three years ago.

That may be so, but I'm not sure what bearing that has on the svn
commit message encoding.

> http://svn.apache.org/r83
> http://svn.apache.org/r1196769
>
> As of now, several xml files in Tomcat (those changelogs) are
> officially UTF-8, and I am OK with people using accented characters
> for new text there until something breaks.
> (Personally, I will probably still use numeric entities, as I do not
> have those characters on my keyboard.)
>
> AFAIK, TortoiseSVN diff viewer has some logic to autodetect the use of UTF-8.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.45

[sebb]

On 26 September 2013 19:46, Konstantin Preißer  wrote:
> Hi Rainer,
>
>> -Original Message-
>> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
>> Sent: Thursday, September 26, 2013 8:22 PM
>
>> Any chance you can try current trunk? Mark added more fixes to
>> AprEndpoint after r1523781. It would be great if you could check
>> r1526052 (or later).
>
> I just tried with current trunk (r1526565) and with Native 1.1.28, and I
> still get the same crash in tcnative-1.dll.

If it's possible to crash TC from Java, then IMO a fix really ought to
go into TC Native.
Changes to the Java code may avoid the crash, but that won't fix the
underlying issue.

>
> Regards,
> Konstantin Preißer
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: International characters in source files and SVN commit messages (was: RE:r1525975)

[sebb]

On 25 September 2013 17:02, Konstantin Preißer  wrote:
> Mark,
>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Wednesday, September 25, 2013 5:54 PM
>
>> I'd say yes. Property files are a 'special' case:
>> http://stackoverflow.com/questions/4659929/how-to-use-utf-8-in-
>> resource-properties-with-resourcebundle
>
> OK, thank you for the clarification.
>
>> It doesn't bother me but I'm only one committer. I think this falls
>> under the category if someone cares enough about the commit e-mails
>> using UTF-8 then they need to work with infra to make that happen. I'm
>> happy with things as they are.

There is a property that can be used to change the encoding used by
the SVN mailer, for example:

svn:mime-type text/xml; charset=utf-8

Make sure this agrees with the contents and any xml encoding attribute.

> OK.
>
> Thanks!
>
> Konstantin
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Issues in Apache Taglibs 1.2.0-RC1

[sebb]

On 18 September 2013 08:01, Jeremy Boynes  wrote:
> On Sep 15, 2013, at 4:49 PM, sebb  wrote:
>
>> On 14 September 2013 17:09, Jeremy Boynes  wrote:
>>>
>>> I think addressed those issues in the following changes:
>>> http://svn.apache.org/r1512150
>>> http://svn.apache.org/r1512151
>>> http://svn.apache.org/r1512153
>>> http://svn.apache.org/r1512158
>>
>> BTW, there was no need to drop @version entirely; it was only the
>> $Date$ part that causes problems.
>
> They had been removed from the rest of the codebase previously; I did that to 
> match.
>
>>
>>> http://svn.apache.org/r1512166
>>> http://svn.apache.org/r1512172
>>
>> Those changes look OK at first glance.
>>
>>> except for the "several files without AL headers." I'll look to see which 
>>> those are but pointers would help.
>>
>> I just ran RAT.
>> Sorry, but I did not keep the report.
>
> I see RAT has a Maven plugin - would it make sense to add that to the release 
> profile for the project?

That should probably be the subject of a new mail thread.

> Thanks
> Jeremy
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [RESULT] Was: [VOTE] Release Apache Tomcat Native 1.1.28

[sebb]

http://people.apache.org/committers-by-project.html#tomcat-pmc

On 16 September 2013 14:47, Christopher Schultz
 wrote:
> Mladen,
>
> On 9/16/13 1:43 AM, Mladen Turk wrote:
>> With 5 bining (Mark, Rainer, Henri, Chris, Mladen)
>
> I'm not sure I'm binding, though it does not matter as you still have
> plenty of votes.
>
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Issues in Apache Taglibs 1.2.0-RC1

[sebb]

On 14 September 2013 17:09, Jeremy Boynes  wrote:
> On Aug 7, 2013, at 4:41 AM, sebb  wrote:
>
>> On 2 August 2013 20:32, Jeremy Boynes  wrote:
>>> A proposed release candidate Apache Taglibs 1.2.0-RC1 is now available for 
>>> voting.
>>>
>>> This is release candidate for an implementation of JSTL 1.2 and can be 
>>> obtained from the staging repo at:
>>>  https://repository.apache.org/content/repositories/orgapachetomcat-053/
>>>
>>> The source distribution can be obtained from:
>>>  
>>> https://repository.apache.org/content/repositories/orgapachetomcat-053/org/apache/taglibs/taglibs-standard/1.2.0-RC1/
>>>
>>> The proposed 1.2.0-RC1 candidate is:
>>> [X] Broken - do not release
>>> [ ] Alpha - can be released as 1.2.0-RC1 alpha
>>>
>>> This is the first release in a long time, and the first since switching to 
>>> Maven. If there are issues, please list all concerns so they can be 
>>> addressed.
>>
>> Please include the SVN tag and revision number in all vote e-mails.
>>
>> Otherwise it's not possible to check provenance of the the source files.
>> Nor can one check if there are files missing from the source archive
>> (or accidentally added).
>>
>> A link to the KEYS file should also be included so the sigs can be checked.
>>
>> ==
>>
>> The NOTICE file says:
>>>>>
>> Apache Tomcat Standard Taglib
>> Copyright 2001-2012 The Apache Software Foundation
>>
>> This product includes software developed by
>> The Apache Software Foundation (http://www.apache.org/).
>> <<<
>>
>> The year should possibly be updated to 2013.
>>
>> "developed by" MUST be changed to "developed at"
>>
>> The NOTICE files in the META-INF jar directories don't have the full
>> name of the component. The name must include the "Apache Tomcat
>> Standard Taglib" prefix. However, the NOTICE files do say "developed
>> at".
>>
>> There are several files without AL headers.
>>
>> Several source files contain the SVN tag $Date$.
>> This is generated using the local timezone, so the source archive will
>> be different depending where it is generated. Best to avoid $Date$; if
>> you want a date, use $Id$ instead, though $Revision$ should be
>> sufficient.
>>
>> The source archive top-level directory includes the suffix RC1; that is 
>> unusual.
>>
>> The file JSTLVariableStackTest.java does not have svn:eolstyle native set.
>> The file ParamSupport.java is marked as executable in SVN props.
>
> I think addressed those issues in the following changes:
> http://svn.apache.org/r1512150
> http://svn.apache.org/r1512151
> http://svn.apache.org/r1512153
> http://svn.apache.org/r1512158

BTW, there was no need to drop @version entirely; it was only the
$Date$ part that causes problems.

> http://svn.apache.org/r1512166
> http://svn.apache.org/r1512172

Those changes look OK at first glance.

> except for the "several files without AL headers." I'll look to see which 
> those are but pointers would help.

I just ran RAT.
Sorry, but I did not keep the report.

> After those changes do you see any additional problems?

Not sure without an RC.

> Thanks
> Jeremy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1523127 - /tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml

[sebb]

On 13 September 2013 23:14,   wrote:
> Author: schultz
> Date: Fri Sep 13 22:14:13 2013
> New Revision: 1523127
>
> URL: http://svn.apache.org/r1523127
> Log:
> Added changelog item to match the patch in r1518225.
>
> Modified:
> tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
>
> Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
> URL: 
> http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml?rev=1523127&r1=1523126&r2=1523127&view=diff
> ==
> --- tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml (original)
> +++ tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Fri Sep 13 
> 22:14:13 2013
> @@ -54,6 +54,10 @@
>51655 Added a decent description of what tcnative actually 
> is.
>(schultz)
>  
> +
> +  51813 Add NULL-checking for s->net to
> +  avoid SIGSEGV in situations where it appears a socket bas been 
> recycled.

s/bas/has/

> +
>
>  
>  
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1522018 - in /tomcat/trunk/webapps/docs: images/docs-stylesheet-ie-fix.css images/docs-stylesheet.css tomcat-docs.xsl

[sebb]

On 11 September 2013 21:09,   wrote:
> Author: markt
> Date: Wed Sep 11 20:09:40 2013
> New Revision: 1522018
>
> URL: http://svn.apache.org/r1522018
> Log:
> IE <=9 fixes without the conditional comments
>

IE8 now looks much better.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Need guidance for writing unit tests for 55317

[sebb]

On 21 August 2013 20:21, Christopher Schultz
 wrote:
> Sebb,
>
> On 8/21/13 1:46 PM, sebb wrote:
>> On 21 August 2013 14:48, Christopher Schultz
>>  wrote:
>>> Nick,
>>>
>>> On 8/20/13 8:24 PM, Nick Williams wrote:
>>>> I ran in to a roadblock with this idea. Part of the byte code of a
>>>> class includes the fully-qualified class name. If I create a class,
>>>> say UnweavedClass, and replace its byte code in my fake transformer
>>>> with that of another class, the FQCN changes. This results in a
>>>> NoClassDefFoundError because the class loader is looking for
>>>> UnweavenClass in be in the byte code when really some other class
>>>> is.
>>>>
>>>> My backup idea is slightly less clean but, IMO, still more clean than
>>>> adding ASM as a test-time dependency and trying to figure all of that
>>>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>>>> (with the modified behavior) and then translated each version into a
>>>> Java byte array definition. (These are extremely simple on-line,
>>>> one-method classes, so the byte arrays are relatively short.) I then
>>>> simply embedded the byte array definitions as static final byte[]
>>>> fields the test class and replaced the byte code in my fake
>>>> transformer with those embedded fields' content. I've tested this and
>>>> it works great.
>>>
>>> Any reason not to simply compile some .java source into a .class file
>>> and read it from the disk instead of shoving it into a byte array?
>>> There's nothing stopping you from doing an offline-compile of a .java
>>> file into a .class file and committing both to svn. You don't have to
>>> compile the .java source as part of the test -- just load it off disk as
>>> part of the test.
>>>
>>> This will allow easier inspection of the .class file, and not be such a
>>> pain in the neck to change the bytecode if necessary.
>>
>> Is there any mileage in using the features of JSR199?
>
> Is that widely-deployed? I don't believe its a part of, for instance,
> Java 7 SE.

I understood it to be part of Java 6 [1], but perhaps I misunderstood.

Alternatively, since Tomcat uses ECJ, it could perhaps use that to compile.
The Commons JCI component has an Eclipse compiler; however there is an
issue with it at present [2]

[1] https://blogs.oracle.com/jjg/entry/jsr_199_meets_jsr_203
[2] https://issues.apache.org/jira/browse/JCI-59

> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Need guidance for writing unit tests for 55317

[sebb]

On 21 August 2013 14:48, Christopher Schultz
 wrote:
> Nick,
>
> On 8/20/13 8:24 PM, Nick Williams wrote:
>> I ran in to a roadblock with this idea. Part of the byte code of a
>> class includes the fully-qualified class name. If I create a class,
>> say UnweavedClass, and replace its byte code in my fake transformer
>> with that of another class, the FQCN changes. This results in a
>> NoClassDefFoundError because the class loader is looking for
>> UnweavenClass in be in the byte code when really some other class
>> is.
>>
>> My backup idea is slightly less clean but, IMO, still more clean than
>> adding ASM as a test-time dependency and trying to figure all of that
>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>> (with the modified behavior) and then translated each version into a
>> Java byte array definition. (These are extremely simple on-line,
>> one-method classes, so the byte arrays are relatively short.) I then
>> simply embedded the byte array definitions as static final byte[]
>> fields the test class and replaced the byte code in my fake
>> transformer with those embedded fields' content. I've tested this and
>> it works great.
>
> Any reason not to simply compile some .java source into a .class file
> and read it from the disk instead of shoving it into a byte array?
> There's nothing stopping you from doing an offline-compile of a .java
> file into a .class file and committing both to svn. You don't have to
> compile the .java source as part of the test -- just load it off disk as
> part of the test.
>
> This will allow easier inspection of the .class file, and not be such a
> pain in the neck to change the bytecode if necessary.

Is there any mileage in using the features of JSR199?

> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs 1.2.0-RC1

[sebb]

On 2 August 2013 20:32, Jeremy Boynes  wrote:
> A proposed release candidate Apache Taglibs 1.2.0-RC1 is now available for 
> voting.
>
> This is release candidate for an implementation of JSTL 1.2 and can be 
> obtained from the staging repo at:
>   https://repository.apache.org/content/repositories/orgapachetomcat-053/
>
> The source distribution can be obtained from:
>   
> https://repository.apache.org/content/repositories/orgapachetomcat-053/org/apache/taglibs/taglibs-standard/1.2.0-RC1/
>
> The proposed 1.2.0-RC1 candidate is:
> [X] Broken - do not release
> [ ] Alpha - can be released as 1.2.0-RC1 alpha
>
> This is the first release in a long time, and the first since switching to 
> Maven. If there are issues, please list all concerns so they can be addressed.

Please include the SVN tag and revision number in all vote e-mails.

Otherwise it's not possible to check provenance of the the source files.
Nor can one check if there are files missing from the source archive
(or accidentally added).

A link to the KEYS file should also be included so the sigs can be checked.

==

The NOTICE file says:
>>>
Apache Tomcat Standard Taglib
Copyright 2001-2012 The Apache Software Foundation

This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
<<<

The year should possibly be updated to 2013.

"developed by" MUST be changed to "developed at"

The NOTICE files in the META-INF jar directories don't have the full
name of the component. The name must include the "Apache Tomcat
Standard Taglib" prefix. However, the NOTICE files do say "developed
at".

There are several files without AL headers.

Several source files contain the SVN tag $Date$.
This is generated using the local timezone, so the source archive will
be different depending where it is generated. Best to avoid $Date$; if
you want a date, use $Id$ instead, though $Revision$ should be
sufficient.

The source archive top-level directory includes the suffix RC1; that is unusual.

The file JSTLVariableStackTest.java does not have svn:eolstyle native set.
The file ParamSupport.java is marked as executable in SVN props.

> Thanks
> Jeremy
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Various shell-scripting idioms in bin/daemon.sh

[sebb]

On 18 July 2013 10:13, Rainer Jung  wrote:
> On 18.07.2013 06:04, Mladen Turk wrote:
>> On 07/17/2013 11:59 PM, sebb wrote:
>>> Regardless, please consider documenting the script to explain why it
>>> does not use -n/-z if that is necessary to avoid bugs.
>>>
>>
>> It would be the same as documenting why one uses a+=1 instead a++ :)
>> I don't see where its written that one *must* use -n/-z at the first place.
>
> Coming from SunOS 4 times I agree. That "X$var" comparing with "Xvalue"
> idiom is or at least was very common in system shell scripts. No need to
> document, that is just practical shell language programming knowledge.

I'm willing to accept that; though I think the use of . is not ideal.

> The same to not using "-n" or "-z" for platform independent shell
> script. It seems to me that POSIX and the later Unix standards still do
> not standardize the allowed shell expression syntax. There is a standard
> "test" commandline util, but IMHO that's not the same.

This is different, because for many, using -n or -z is going to be
common practise.
If it's important *not* to use them here, then it should be documented why.

Clearly the OP did not know why -n and -z were not used.
Please let future maintainers know.

> Regards,
>
> Rainer
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Various shell-scripting idioms in bin/daemon.sh

[sebb]

Regardless, please consider documenting the script to explain why it
does not use -n/-z if that is necessary to avoid bugs.

On 17 July 2013 20:26, Christopher Schultz  wrote:
> Mladen,
>
> On 7/17/13 1:07 PM, Mladen Turk wrote:
>> On 07/17/2013 06:05 PM, sebb wrote:
>>>
>>> Why not use:
>>>
>>> if [ "$FOO" != "" ]
>>>
>>
>> Some shells do not allow that (comparing empty strings)
>
> I don't know of a shell where "$FOO" would be unset and yet expand to
> some non-zero-length string in a command. If that were the case, ".$FOO"
> would then expand to the same non-zero-length string with a dot
> pre-pended to it and the comparison wouldn't work, anyway.
>
> In my patch, I used a "-z". I'll remove it if there is significant
> concern that it is very non-standard.
>
> Sebb, one reason to use the ".$FOO" trick can be found in O'Reilly's
> /Unix Power Tools/. They point out that by testing for "$FOO" like this:
>
> if [ "$FOO" = "somestring" ] ;
>
> You run the risk of $FOO expanding to something like "-z" where it would
> not result in a string comparison. I like the use of ".$FOO" (leading
> dot) because it avoids this issue, but I think it's moot because of the
> availability of the "-z" test.
>
> I couldn't find a man page online for the "test" program (but of course
> searching for "test man page" yields completely useless results).
>
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Various shell-scripting idioms in bin/daemon.sh

[sebb]

On 17 July 2013 15:50, Mladen Turk  wrote:
> On 07/17/2013 04:01 PM, sebb wrote:
>>
>> May I suggest a short comment is added to the script to document why
>> -z and -n are not used?
>> Someone else reading the script in the future is going to wonder the
>> same-z and -n
>
>
> Some shells do not work well if variable is not set when using -z and -n.
> In case FOO was not set at all they break, but work if FOO="" as expected.

OK, well that information could be added to the script.

> Anyhow, IMHO 'if [ ".$FOO" != . ]' is more readable then 'if [ -n "$FOO" ]'

Why not use:

if [ "$FOO" != "" ]

The . is not very obvious in some fonts, and it's more symmetrical to
quote both sides.

> I always end wondering if I should use -z or -n :)
>
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Various shell-scripting idioms in bin/daemon.sh

[sebb]

On 17 July 2013 12:59, Mladen Turk  wrote:
> On 07/16/2013 11:42 PM, Christopher Schultz wrote:
>>
>> All,
>>
>> While doing the trivial fix for
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55268, I noticed a
>> few idioms being used in bin/daemon.sh that struck me as odd. For example:
>>
>> while [ ".$1" != . ]
>> do
>>case "$1" in
>>  --java-home )
>>  JAVA_HOME="$2"
>>  shift; shift;
>>  continue
>>  ;;
>>
>>
>> This example actually illustrates the two main questions I had:
>>
>> 1. Why use [ ".$FOO" != . ] instead of simply [ -n "$FOO" ] (Corollary:
>> why use [ ".$FOO" = . ] instead of [ -z "$FOO" ])?
>>
>
> Because some shell scripts does dot handle -z or -n well.
>
>
>> 2. Why have a "continue" at the end of every case option, since the
>> whole body of the while loop is nothing but the case construct?
>>
>
> That might be an extra directive, true.
> Probably a leftover from multiple case directives in while loop.
>

But safer than forgetting to add the continue if another case is ever added.

>
>
>> I may be spoiled by using Linux and bash for most of my career, but I
>> believe these are fairly standard POSIX-compliant things that should
>> work on all *NIX systems.
>>
>
> Sadly that's not the case IMHO.

May I suggest a short comment is added to the script to document why
-z and -n are not used?
Someone else reading the script in the future is going to wonder the same.

>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1495875 - in /tomcat/tc7.0.x/trunk: ./ build.xml webapps/docs/changelog.xml

[sebb]

On 23 June 2013 20:24,   wrote:
> Author: markt
> Date: Sun Jun 23 19:24:21 2013
> New Revision: 1495875
>
> URL: http://svn.apache.org/r1495875
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55119
> Ensure that the build process produces Javadoc that is not vulnerable to 
> CVE-2013-1571.
> Based on a patch by Uwe Schindler.
> See https://issues.apache.org/jira/browse/LUCENE-5072

Great!

I've copied the macro for JMeter.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 20 June 2013 16:33, Christopher Schultz  wrote:
> Sebb,
>
> On 6/20/13 9:31 AM, sebb wrote:
>> On 20 June 2013 14:16, Christopher Schultz  
>> wrote:
>>> Sebb,
>>>
>>> On 6/19/13 4:26 AM, sebb wrote:
>>>> On 19 June 2013 09:15, Mark Thomas  wrote:
>>>>> On 19/06/2013 00:42, Nick Williams wrote:
>>>>>>
>>>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>>>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>>>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>>>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>>>>> they can using Java 7u25. For all practical purses, the vulnerability
>>>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>>>>>> existing Maven artifacts, downloads, and archived downloads really
>>>>>> doesn't have to be worried about (not that we could do anything about
>>>>>> it). My thoughts on this:
>>>>>>
>>>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>>>>> the website for Tomcat 6 and Tomcat 7.
>>>>>
>>>>>
>>>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains
>>>>> available.
>>>>>
>>>>> I'll get on to this now.
>>>>>
>>>>>
>>>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>>>>> better.
>>>>>
>>>>>
>>>>> Hmm. That will need some thought as the build needs to be run with the
>>>>> minimum Java version required for that major version. Maybe we can just 
>>>>> run
>>>>> the Javadoc part with a different JDK. Either that, or run the fix tool 
>>>>> over
>>>>> the result. This needs some investigation.
>>>>>
>>>>>
>>>>>> There will be no fix for Java 5 or 6. Thankfully, generating
>>>>>> Javadoc using a different JDK than you used to compile is quite easy
>>>>>> in both Maven and Ant. In fact, I personally prefer it that way,
>>>>>> because the Javadoc is much more visually attractive in Java 7.
>>>>>
>>>>>
>>>>> Hopefully it will be as simple as you suggest.
>>>>>
>>>>
>>>> I found for JMeter that the only file that needed fixing was the
>>>> top-level index.html.
>>>> If always true that reduces what needs to be checked-out/put back.
>>>>
>>>> There's also a bug in the quick-fix tool - it fails to delete the
>>>> renamed original file (on Windows, which locks files from delete)
>>>> because it fails to call fis.close() first.
>>>> [The code does not check that the delete is successful either.]
>>>>
>>>> Should be easily possible to run the (fixed) tool on locally generated
>>>> javadoc before committing in future.
>>>
>>> Wow, the code for that quick-fix tool really is awful. If run in
>>> recursuve-mode, it will leave every file that matches the "file list"
>>> (index.html, etc.) open until the finalizers run (hah). There are also
>>> swallowed exceptions, no finally blocks, etc.
>>
>> I've made some fixes (resource closures); these are at:
>>
>> https://svn.apache.org/repos/asf/commons/proper/commons-javadocfix-plugin/trunk/src/main/java/org/apache/commons/plugins/javadocfix/JavadocFixTool.java
>>
>> Comments welcome if you spot any more.
>
> I think you want to do a lot of the close() operations in finally
> blocks, in case exceptions occur.

Agreed, but it was simpler to just fix the main-line code.
At least now the resources are closed if exceptions don't occur -
which was not the case previously.

> While it probably won't allow the
> program to function any better (that is, the old file need not be
> deleted unless it is successfully-processed), it will reduce the number
> of file handles kept open by the process.

Just noticed that the original file is renamed too early.
If the code generates an IOE before the temporary file is completed
and the rename attempted, the user is not informed that the file has
been renamed.

> -chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 20 June 2013 14:16, Christopher Schultz  wrote:
> Sebb,
>
> On 6/19/13 4:26 AM, sebb wrote:
>> On 19 June 2013 09:15, Mark Thomas  wrote:
>>> On 19/06/2013 00:42, Nick Williams wrote:
>>>>
>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>>> they can using Java 7u25. For all practical purses, the vulnerability
>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>>>> existing Maven artifacts, downloads, and archived downloads really
>>>> doesn't have to be worried about (not that we could do anything about
>>>> it). My thoughts on this:
>>>>
>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>>> the website for Tomcat 6 and Tomcat 7.
>>>
>>>
>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains
>>> available.
>>>
>>> I'll get on to this now.
>>>
>>>
>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>>> better.
>>>
>>>
>>> Hmm. That will need some thought as the build needs to be run with the
>>> minimum Java version required for that major version. Maybe we can just run
>>> the Javadoc part with a different JDK. Either that, or run the fix tool over
>>> the result. This needs some investigation.
>>>
>>>
>>>> There will be no fix for Java 5 or 6. Thankfully, generating
>>>> Javadoc using a different JDK than you used to compile is quite easy
>>>> in both Maven and Ant. In fact, I personally prefer it that way,
>>>> because the Javadoc is much more visually attractive in Java 7.
>>>
>>>
>>> Hopefully it will be as simple as you suggest.
>>>
>>
>> I found for JMeter that the only file that needed fixing was the
>> top-level index.html.
>> If always true that reduces what needs to be checked-out/put back.
>>
>> There's also a bug in the quick-fix tool - it fails to delete the
>> renamed original file (on Windows, which locks files from delete)
>> because it fails to call fis.close() first.
>> [The code does not check that the delete is successful either.]
>>
>> Should be easily possible to run the (fixed) tool on locally generated
>> javadoc before committing in future.
>
> Wow, the code for that quick-fix tool really is awful. If run in
> recursuve-mode, it will leave every file that matches the "file list"
> (index.html, etc.) open until the finalizers run (hah). There are also
> swallowed exceptions, no finally blocks, etc.

I've made some fixes (resource closures); these are at:

https://svn.apache.org/repos/asf/commons/proper/commons-javadocfix-plugin/trunk/src/main/java/org/apache/commons/plugins/javadocfix/JavadocFixTool.java

Comments welcome if you spot any more.

[If you checkout [1] and "mvn install" the plugin, you should be able
to run it locally]

[1] 
https://svn.apache.org/repos/asf/commons/proper/commons-javadocfix-plugin/trunk/

> It looks like it was written by a novice Java programmer.

Who either did not use an IDE or ignored the warnings.

> The good news is that the license allows you (we) to modify the source
> code and redistribute it. So, we can even publish a fixed version if we
> choose to (rather than merely keeping it for ourselves).

That's how I read it too.

> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 19 June 2013 15:36, Mark Thomas  wrote:
> On 19/06/2013 15:12, sebb wrote:
>>
>> On 19 June 2013 14:12, Konstantin Kolinko  wrote:
>>>
>>> 2013/6/19 sebb :
>>>>
>>>> On 19 June 2013 13:12, sebb  wrote:
>>>>>
>>>>> On 19 June 2013 13:03, Nick Williams 
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Jun 19, 2013, at 3:15 AM, Mark Thomas wrote:
>>>>>>
>>>>>>> On 19/06/2013 00:42, Nick Williams wrote:
>>>>>>>>
>>>>>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>>>>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or
>>>>>>>> Java
>>>>>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>>>>>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>>>>>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>>>>>>> they can using Java 7u25. For all practical purses, the
>>>>>>>> vulnerability
>>>>>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in
>>>>>>>> our
>>>>>>>> existing Maven artifacts, downloads, and archived downloads really
>>>>>>>> doesn't have to be worried about (not that we could do anything
>>>>>>>> about
>>>>>>>> it). My thoughts on this:
>>>>>>>>
>>>>>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>>>>>>> the website for Tomcat 6 and Tomcat 7.
>>>>>>>
>>>>>>>
>>>>>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but
>>>>>>> remains available.
>>>>>>>
>>>>>>> I'll get on to this now.
>>>>>>>
>>>>>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>>>>>>> better.
>>>>>>>
>>>>>>>
>>>>>>> Hmm. That will need some thought as the build needs to be run with
>>>>>>> the minimum Java version required for that major version. Maybe we can 
>>>>>>> just
>>>>>>> run the Javadoc part with a different JDK. Either that, or run the fix 
>>>>>>> tool
>>>>>>> over the result. This needs some investigation.
>>>>>
>>>>>
>>>>> I'd recommend running the fix tool after running javadoc; it's quick
>>>>> and the license looks OK to include in an SVN build tools area.
>>>>>
>>>>> It's not just that you have to use Java 7, you have to use Java 7 u25
>>>>> or later.
>>>>> Can that be detected reliably?
>>>>
>>>>
>>>> Just to make it more fun, the javadoc tool does not display its
>>>> version...
>>>>
>>>
>>>> javadoc.exe -J-version
>>>
>>>
>>> java version "1.7.0_21"
>>> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
>>> Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing)
>>
>>
>> Thanks; would not have thought of that.
>>
>> 
>> Should be OK unless javadoc.exe is somehow left over from an older
>> installation. [Yes, it's rather unlikely]
>> I just deleted my previous Java 7 installation so I cannot try it at
>> present.
>> I tried Javadoc.exe 6 and it does not work with Java 7 nor vice-versa,
>> but might possibly work with the same version.
>> I guess it depends on how compatible the dynamic libraries etc. are.
>> 
>>
>> Anyway, back to the problem:
>>
>> I've been thinking how to run the Javadoc fix tool, in Maven and Ant
>> builds
>> Also where to store (source and) binary version of the tool.
>> Seems wasteful if every project has their own version in SVN.
>>
>> It occurred to me that it might be useful to create a Maven plugin as
>> well as a jar (hopefully the same one) that can be run from the
>> command-line.
>> I can create some code in Commons Sandbox to do this.
>> Anyone could then check it out of SVN and build locally (would need
>> Maven) and use for trialling fixes to Ant/Maven build scripts.
>>
>> If the approach works, then it should be fairly quick to get the
>> plugin voted on and released in Commons, and it would then be usable
>> by all.
>>
>> Does that sound like something Tomcat could use?
>
>
> Nope. Tomcat builds with Ant, not Maven.

I know, that is why the jar would have a main manifest entry as well.

> The Oracle provided JAR is fine.

Sort of - it does not work properly on Windows (fails to delete the
old copy of the file) .

Now Eclipse tells me it fails to close some resources.
It's unlikely that the resource leaks would cause failures except in
pathological cases, but still.

> The JAR is so small (5k) that multiple copies in svn really isn't an issue.

I know.
It was more that having compiled versions of source in SVN is not a
good precedent.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 19 June 2013 14:12, Konstantin Kolinko  wrote:
> 2013/6/19 sebb :
>> On 19 June 2013 13:12, sebb  wrote:
>>> On 19 June 2013 13:03, Nick Williams  wrote:
>>>>
>>>> On Jun 19, 2013, at 3:15 AM, Mark Thomas wrote:
>>>>
>>>>> On 19/06/2013 00:42, Nick Williams wrote:
>>>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>>>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>>>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>>>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>>>>> they can using Java 7u25. For all practical purses, the vulnerability
>>>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>>>>>> existing Maven artifacts, downloads, and archived downloads really
>>>>>> doesn't have to be worried about (not that we could do anything about
>>>>>> it). My thoughts on this:
>>>>>>
>>>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>>>>> the website for Tomcat 6 and Tomcat 7.
>>>>>
>>>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains 
>>>>> available.
>>>>>
>>>>> I'll get on to this now.
>>>>>
>>>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>>>>> better.
>>>>>
>>>>> Hmm. That will need some thought as the build needs to be run with the 
>>>>> minimum Java version required for that major version. Maybe we can just 
>>>>> run the Javadoc part with a different JDK. Either that, or run the fix 
>>>>> tool over the result. This needs some investigation.
>>>
>>> I'd recommend running the fix tool after running javadoc; it's quick
>>> and the license looks OK to include in an SVN build tools area.
>>>
>>> It's not just that you have to use Java 7, you have to use Java 7 u25 or 
>>> later.
>>> Can that be detected reliably?
>>
>> Just to make it more fun, the javadoc tool does not display its version...
>>
>
>>javadoc.exe -J-version
>
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing)

Thanks; would not have thought of that.


Should be OK unless javadoc.exe is somehow left over from an older
installation. [Yes, it's rather unlikely]
I just deleted my previous Java 7 installation so I cannot try it at present.
I tried Javadoc.exe 6 and it does not work with Java 7 nor vice-versa,
but might possibly work with the same version.
I guess it depends on how compatible the dynamic libraries etc. are.


Anyway, back to the problem:

I've been thinking how to run the Javadoc fix tool, in Maven and Ant builds
Also where to store (source and) binary version of the tool.
Seems wasteful if every project has their own version in SVN.

It occurred to me that it might be useful to create a Maven plugin as
well as a jar (hopefully the same one) that can be run from the
command-line.
I can create some code in Commons Sandbox to do this.
Anyone could then check it out of SVN and build locally (would need
Maven) and use for trialling fixes to Ant/Maven build scripts.

If the approach works, then it should be fairly quick to get the
plugin voted on and released in Commons, and it would then be usable
by all.

Does that sound like something Tomcat could use?

> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 19 June 2013 13:12, sebb  wrote:
> On 19 June 2013 13:03, Nick Williams  wrote:
>>
>> On Jun 19, 2013, at 3:15 AM, Mark Thomas wrote:
>>
>>> On 19/06/2013 00:42, Nick Williams wrote:
>>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>>> they can using Java 7u25. For all practical purses, the vulnerability
>>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>>>> existing Maven artifacts, downloads, and archived downloads really
>>>> doesn't have to be worried about (not that we could do anything about
>>>> it). My thoughts on this:
>>>>
>>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>>> the website for Tomcat 6 and Tomcat 7.
>>>
>>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains 
>>> available.
>>>
>>> I'll get on to this now.
>>>
>>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>>> better.
>>>
>>> Hmm. That will need some thought as the build needs to be run with the 
>>> minimum Java version required for that major version. Maybe we can just run 
>>> the Javadoc part with a different JDK. Either that, or run the fix tool 
>>> over the result. This needs some investigation.
>
> I'd recommend running the fix tool after running javadoc; it's quick
> and the license looks OK to include in an SVN build tools area.
>
> It's not just that you have to use Java 7, you have to use Java 7 u25 or 
> later.
> Can that be detected reliably?

Just to make it more fun, the javadoc tool does not display its version...

>> As long as Ant knows where to find the JDK (environmental variable or 
>> something) it can generate Javadoc with Java 7 while Ant runs with Java 5/6. 
>> Ant does not have to run with Java 7. See the Ant documentation for the 
>> Javadoc task [1], refer to the "executable" attribute. By default Ant looks 
>> for "javadoc" in the same JDK Ant as running under, but you can specify a 
>> path to a different JDK using the executable attribute. Only downside is 
>> that the building instructions will have to say that Java _ /and/ Java 7u25 
>> are required to build, and that a certain environmental variable has to 
>> exist pointing to the JDK7 installation. Might be best to make this 
>> "conditional" so that it falls back to the default if it can't find Java 7 
>> (makes it easier for home builders).
>>
>> [1] http://ant.apache.org/manual/Tasks/javadoc.html
>>
>>>
>>>> There will be no fix for Java 5 or 6. Thankfully, generating
>>>> Javadoc using a different JDK than you used to compile is quite easy
>>>> in both Maven and Ant. In fact, I personally prefer it that way,
>>>> because the Javadoc is much more visually attractive in Java 7.
>>>
>>> Hopefully it will be as simple as you suggest.
>>>
>>>> I will file an issue about this two, but I wanted to go ahead and
>>>> make the list aware.
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>>
>>>> Nick
>>>>
>>>> [1]
>>>> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
>>>>
>>>>
>>> [2] http://www.kb.cert.org/vuls/id/225657
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 19 June 2013 13:03, Nick Williams  wrote:
>
> On Jun 19, 2013, at 3:15 AM, Mark Thomas wrote:
>
>> On 19/06/2013 00:42, Nick Williams wrote:
>>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>>> provided a repair-in-place tool for Javadoc that cannot be easily
>>> regenerated, but is urging developers to regenerate whatever Javadoc
>>> they can using Java 7u25. For all practical purses, the vulnerability
>>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>>> existing Maven artifacts, downloads, and archived downloads really
>>> doesn't have to be worried about (not that we could do anything about
>>> it). My thoughts on this:
>>>
>>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>>> the website for Tomcat 6 and Tomcat 7.
>>
>> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains 
>> available.
>>
>> I'll get on to this now.
>>
>>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>>> better.
>>
>> Hmm. That will need some thought as the build needs to be run with the 
>> minimum Java version required for that major version. Maybe we can just run 
>> the Javadoc part with a different JDK. Either that, or run the fix tool over 
>> the result. This needs some investigation.

I'd recommend running the fix tool after running javadoc; it's quick
and the license looks OK to include in an SVN build tools area.

It's not just that you have to use Java 7, you have to use Java 7 u25 or later.
Can that be detected reliably?

> As long as Ant knows where to find the JDK (environmental variable or 
> something) it can generate Javadoc with Java 7 while Ant runs with Java 5/6. 
> Ant does not have to run with Java 7. See the Ant documentation for the 
> Javadoc task [1], refer to the "executable" attribute. By default Ant looks 
> for "javadoc" in the same JDK Ant as running under, but you can specify a 
> path to a different JDK using the executable attribute. Only downside is that 
> the building instructions will have to say that Java _ /and/ Java 7u25 are 
> required to build, and that a certain environmental variable has to exist 
> pointing to the JDK7 installation. Might be best to make this "conditional" 
> so that it falls back to the default if it can't find Java 7 (makes it easier 
> for home builders).
>
> [1] http://ant.apache.org/manual/Tasks/javadoc.html
>
>>
>>> There will be no fix for Java 5 or 6. Thankfully, generating
>>> Javadoc using a different JDK than you used to compile is quite easy
>>> in both Maven and Ant. In fact, I personally prefer it that way,
>>> because the Javadoc is much more visually attractive in Java 7.
>>
>> Hopefully it will be as simple as you suggest.
>>
>>> I will file an issue about this two, but I wanted to go ahead and
>>> make the list aware.
>>
>> Thanks,
>>
>> Mark
>>
>>
>>> Nick
>>>
>>> [1]
>>> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
>>>
>>>
>> [2] http://www.kb.cert.org/vuls/id/225657
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CVE-2013-1571, VU#225657

[sebb]

On 19 June 2013 09:15, Mark Thomas  wrote:
> On 19/06/2013 00:42, Nick Williams wrote:
>>
>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>> provided a repair-in-place tool for Javadoc that cannot be easily
>> regenerated, but is urging developers to regenerate whatever Javadoc
>> they can using Java 7u25. For all practical purses, the vulnerability
>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>> existing Maven artifacts, downloads, and archived downloads really
>> doesn't have to be worried about (not that we could do anything about
>> it). My thoughts on this:
>>
>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>> the website for Tomcat 6 and Tomcat 7.
>
>
> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains
> available.
>
> I'll get on to this now.
>
>
>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>> better.
>
>
> Hmm. That will need some thought as the build needs to be run with the
> minimum Java version required for that major version. Maybe we can just run
> the Javadoc part with a different JDK. Either that, or run the fix tool over
> the result. This needs some investigation.
>
>
>> There will be no fix for Java 5 or 6. Thankfully, generating
>> Javadoc using a different JDK than you used to compile is quite easy
>> in both Maven and Ant. In fact, I personally prefer it that way,
>> because the Javadoc is much more visually attractive in Java 7.
>
>
> Hopefully it will be as simple as you suggest.
>

I found for JMeter that the only file that needed fixing was the
top-level index.html.
If always true that reduces what needs to be checked-out/put back.

There's also a bug in the quick-fix tool - it fails to delete the
renamed original file (on Windows, which locks files from delete)
because it fails to call fis.close() first.
[The code does not check that the delete is successful either.]

Should be easily possible to run the (fixed) tool on locally generated
javadoc before committing in future.

>
>> I will file an issue about this two, but I wanted to go ahead and
>> make the list aware.
>
>
> Thanks,
>
> Mark
>
>
>
>> Nick
>>
>> [1]
>>
>> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
>>
>>
> [2] http://www.kb.cert.org/vuls/id/225657
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Jar scanning, SCI scanning, fragment scanning

[sebb]

On 14 June 2013 17:35, Christopher Schultz  wrote:
> Mark,
>
> On 6/14/13 12:21 PM, Mark Thomas wrote:
>> On 14/06/2013 16:57, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 6/14/13 3:16 AM, Mark Thomas wrote:
 On 14/06/2013 03:31, Christopher Schultz wrote:

> It might be nice if this were not a one-of-many decision, but if a
> client could choose more than one type. A bit-mask or a list of
> scan-types would be nice. I could see the same type of scanner being
> used for multiple different purposes.

 That is what ServletContainerIniiializers are for.
>>>
>>> Well, crap. I had never seen those before.
>>>
>>> I'm curious, though. Thinking about this the other day with a colleague
>>> who was complaining about some kind of Spring configuration that
>>> evidently loaded every class available on the classpath and kept them in
>>> memory (thus leading to heap and PermGen issues), I concluded that the
>>> only sane way to do this kind of probing would be to probe everything in
>>> a ClassLoader that was intended to be discarded after the probing as to
>>> avoid loading classes unnecessarily.
>>>
>>> If an SCI retains a reference to any of the Class objects in the
>>> Set parameter, that hypothetical throw-away ClassLoader is no
>>> longer thrown-away.
>>
>> The early Tomcat 7 implementations did it like this - loaded every class
>> and then examined the class object. More recent implementations use BCEL
>> to look at the byte code. It is faster and uses less memory. We also use
>> caching to ensure each class is only processed once.

That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.

> Cool. What Classloader gets used to actually load the Class objects,
> though?

BCEL reads class files as files.

http://commons.apache.org/proper/commons-bcel/

> In the pathological case of @HandlesType('java.lang.Object')
> that means everything gets loaded into .. the WebappClassLoader?
>
> One could imagine a case where an SCI wants to look at everything, but
> then only ends up caring about 2% of what's been loaded. Is that just
> the price you have to pay for inspecting everything -- that you
> seriously waste PermGen? (at least for current Oracle JVMs)
>
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Created] (MTOMCAT-226) Wasted work in AbstractCatalinaMojo#getManager()

[Sebb (JIRA)]

Sebb created MTOMCAT-226:


 Summary: Wasted work in AbstractCatalinaMojo#getManager()
 Key: MTOMCAT-226
 URL: https://issues.apache.org/jira/browse/MTOMCAT-226
 Project: Apache Tomcat Maven Plugin
  Issue Type: Improvement
Reporter: Sebb


AbstractCatalinaMojo#getManager() fetches AuthenticationInfo for the server 
from the wagon and only then checks if the user/pass has been provided on the 
command-line. At which point the AuthenticationInfo is not actually needed, so 
the work was wasted.

The code should check for the command line override first, and only fetch the 
AuthenticationInfo if necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: OT: How do I subscribe to the Tomcat Dev/User lists with my @apache.org address?

[sebb]

On 15 May 2013 00:37, Christopher Schultz  wrote:
> Nick,
>
> On 5/14/13 6:35 PM, Nick Williams wrote:
>> I recently became a committer on the Logging project and thus I now have an 
>> @apache.org address. Since it's a forwarding address, I'm having it forward 
>> to my Google Apps email address (the address I'm sending from now).
>>
>> I'd like to subscribe to the Tomcat Dev and User lists with my @apache.org 
>> address. I've set up my @apache.org address as an additional "From" address 
>> in GMail. If I send an email from GMail to my $work address and select my 
>> @apache.org address is my from address, it shows up as "from" my @apache.org 
>> address when I receive the email on the other end. But when I tried to 
>> subscribe by sending an email from my @apache.org address to 
>> dev-subscr...@tomcat.apache.org, it replied that my GMail address was 
>> already subscribed.
>>
>> Does anyone have any experience with this? How do you subscribe your 
>> @apache.org addresses?
>
> You have to configure your @apache.org address as a /sender/ and not
> just a recipient. Basically, your email client needs to have an account
> with y...@apache.org.
>
> Or you could just do what I do and not bother with using the @apache.org
> on the mailing lists.

Indeed, but if you really want to subscribe as your ASF address:

The mailing list software supports 3rd party [un]subscriptions, see:

http://www.apache.org/foundation/mailinglists.html#subscribing

Just change

list-unsubscribe-user=...

to

list-subscribe-user=...

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1479953 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/http/parser/HttpParser.java test/org/apache/tomcat/util/http/parser/TestMediaType.java webapps/docs/changelog.xml

[sebb]

On 7 May 2013 16:54,   wrote:
> Author: markt
> Date: Tue May  7 15:54:36 2013
> New Revision: 1479953
>
> URL: http://svn.apache.org/r1479953
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54703
> Be tolerant of applications that pass CR or LF in setHeader() values.
> Fix some whitespace parsing issues idnetifed by the extended test cases in 
> readTokenOrQuotedString()
>
> Modified:
> tomcat/tc7.0.x/trunk/   (props changed)
> 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/HttpParser.java
> 
> tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java
> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>
> Propchange: tomcat/tc7.0.x/trunk/
> --
>   Merged /tomcat/trunk:r1479248,1479951
>
> Modified: 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/HttpParser.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/HttpParser.java?rev=1479953&r1=1479952&r2=1479953&view=diff
> ==
> --- 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/HttpParser.java 
> (original)
> +++ 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/HttpParser.java 
> Tue May  7 15:54:36 2013
> @@ -262,17 +262,34 @@ public class HttpParser {
>  }
>  }
>
> -private static SkipConstantResult skipConstant(StringReader input,
> -String constant) throws IOException {
> -int len = constant.length();
> +// Skip any LWS and return the next char
> +private static int skipLws(StringReader input, boolean withReset)
> +throws IOException {
>
> +if (withReset) {
> +input.mark(1);
> +}
>  int c = input.read();
>
> -// Skip lws
> -while (c == 32 || c == 9) {
> +while (c == 32 || c == 9 || c == 10 || c == 13) {

There are some other characters that could be considered as WS, e.g. FF and VT.
Should those be allowed for?

Also perhaps easier to read the comparisons as

while (c == ' ' || c == '\t' || c == '\n' || c == '\r') {

That also agrees with how the test case is written.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[sebb]

Is all of that URL spammy?

I specifically included most of the path because I thought there might be
valid content elsewhere on the site.


On 25 April 2013 13:46, Apache Wiki  wrote:

> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for
> change notification.
>
> The "LocalBadContent" page has been changed by ChuckCaldarale:
> http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=149&rev2=150
>
>   webdesigner-essen\.de
>   webs\.com
>   webstarts\.com
> - weeklyvolcano\.com/community/people/ChristoperB
> + weeklyvolcano\.com
>   weho\.org
>   weloveourlake\.com
>   whatisms
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [Tomcat Wiki] Update of "LocalBadContent" by KonstantinKolinko

[sebb]

On 15 April 2013 15:43, Konstantin Kolinko  wrote:

> 2013/4/15 Pid :
> > Is it me or has the wiki-spam been on the increase lately?
> >
>
> Yes,
>
> I think it a constant stream, started a month ago.
>
> When I added some common phrases to the filter page (like "my\s+name")
> it slowed for a week or two, but now they are using some random text
> excerpts.
>
> It comes from different user names and different IPs, so I think that
> it may be something automated.
>
>
>
There is an automated solution as well:

http://s.apache.org/moin-wiki-access-control

It's all very well deleting the spam after the event, but by then it has
already been published to mailing lists as well.
And there's no easy way to clean up the mailing lists (and it is against
standard policy to do so).

> On 15/04/2013 08:47, Apache Wiki wrote:
> >> Dear Wiki user,
> >>
> >> You have subscribed to a wiki page or wiki category on "Tomcat Wiki"
> for change notification.
> >>
> >> The "LocalBadContent" page has been changed by KonstantinKolinko:
> >>
> http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=133&rev2=134
> >>
> >> (...)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Use of JAXB api to process Base64 in Tomcat 7 and 8

[sebb]

On 21 March 2013 09:39, Mark Thomas  wrote:
> On 21/03/2013 05:35, Konstantin Kolinko wrote:
>> Hi!
>>
>> Recent Mark's commits in Tomcat 7, 8 replaced custom
>> implementations(*) of base64
>> with use of the following class from JAXB:
>>
>> javax.xml.bind.DatatypeConverter
>>
>> This affects base64 processing in our own classes and in our copy of
>> Commons FileUpload.
>> The original fileupload library in commons was not changed (I do not
>> see [1] change in [2] @1459121).
>>
>> [1] http://svn.apache.org/r1458726
>> [2] 
>> http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup
>>
>> First, it seems wrong, as this JAXB API was not designed as a general
>> purpose base64 codec.
>>
>> I hereby -1 on this change, on the following ground:
>
> OK. While I don't agree with you completely, I do agree that it would be
> better to find an alternative solution. I suggest that we copy the
> Base64 decoder/encoder from Commons Codec to a new o.a.tomcat.util.codec
> package and update Tomcat 7 & 8 to use that (and point the deprecation
> markers to this implementation) rather than DatatypeConverter.

Also, there are a couple of fairly basic bugs in the Java 6 method as
currently implemented.
It cannot handle non-ASCII input (codepoints above 127) - instead of
being ignored as non-Base64, they cause AIOOB Exceptions.

As does a trailing pad if it immediately follows a 4-char chunk ending
in a pad, for example:

"Zm8==" => AIOOBE: 1
whereas
"Zm8=A" => OK, ignores the trailing "A"

> I have some other bits and bobs to look at first today but I start on
> this shortly unless anyone raises an objection.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[sebb]

On 21 March 2013 17:48, Apache Wiki  wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for 
> change notification.
>
> The "LocalBadContent" page has been changed by ChuckCaldarale:
> http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=97&rev2=98

By the way, as per [1], if you update the master BadContent page at
[2] instead (or as well), the prohibition will be applied to all
MoinMoin Wikis worldwide (and of course all ASF Wikis).

[1] http://wiki.apache.org/general/OurWikiFarm#BadContent
[2] http://master.moinmo.in/BadContent

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale

[sebb]

On 18 March 2013 21:54, Mark Thomas  wrote:
> On 18/03/2013 21:46, Apache Wiki wrote:
>> Dear Wiki user,
>>
>> You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for 
>> change notification.
>>
>> The "LocalBadContent" page has been changed by ChuckCaldarale:
>
> I've raised it before and folks weren't interested but I think it is
> time to consider [1] again.

+1 (not binding) [2]

> I'll note that while the spammers entries to the wiki get removed pretty
> quickly (thanks Chunk) their content is in our mail archive which is

s/Chunk/Chuck/ !

> indexed all over the place so their aim has already been achieved even
> if we remove the content from the Wiki. I'd really like to put a stop to
> this abuse of our Wiki.

Good point.

> Mark
>
>
> [1]
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot

[2] 
http://mail-archives.apache.org/mod_mbox/tomcat-dev/201106.mbox/%3CBANLkTi%3Df468hoHxnY3Ug%2Bxg20fj4nTOXiQ%40mail.gmail.com%3E

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Tomcat Wiki] Update of "LocalBadContent" by KonstantinKolinko

[sebb]

On 19 March 2013 16:06, Apache Wiki  wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for 
> change notification.
>
> The "LocalBadContent" page has been changed by KonstantinKolinko:
> http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=88&rev2=89
>
> Comment:
> Try to block a frequently used phrase
>
>   #
>   # This page can contain additional items not in the BadContent database.
>   # But please only add terms here if they apply to the entire Apache wiki 
> farm.

The above line should be deleted - AFAIK it's no longer true.

> + #
> + # About: http://moinmo.in/AntiSpamFeatures
> + # Regex syntax: http://docs.python.org/2/library/re.html#re-syntax
>
>   ##++Apache/LocalBadContent
>   100freemb\.com
> @@ -197, +200 @@
>
>   zjeyu\.com
>   zx\.slave\.ca
>   zyseo\.com
> + (my)[\s]+(name)
>   ##--Apache/LocalBadContent
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Checkstyle errors in storeconfig in trunk

[sebb]

On 9 February 2013 09:42, Remy Maucherat  wrote:
> On Sat, 2013-02-09 at 05:19 +0400, Konstantin Kolinko wrote:
>> 2013/2/8 Konstantin Kolinko :
>> > Hi!
>> >
>> > FYI, there are a lot of checkstyle errors in o.a.c.storeconfig package,
>> >
>> > a) tabs in server-registry.xml
>> > b) a lot of trailing whitespace
>>
>> Fixed.
>
> Thanks !
>
>> Further notices:
>> 1. In a lot of places the code uses name "childs" instead of "children".
>>
>> E.g. childs="true" in server-registry.xml
>> E.g. storeChilds(..) method in StoreFactoryBase class
>
> This probably didn't change from the initial revision of the component.
> I guess I didn't event notice it (ahah). Is it worth fixing ? (probably)
>
>> 2. Javadoc for StoreLoader documents XML format for a registry file.
>>
>> What I see there is not what I see in server-registry.xml file in the
>> storeconfig package.
>>
>> E.g. documented
>>  ,
>> actual
>>  

The mail also reports different spelling.

> I suppose the XML was a bit simplified after the doc was written.
>
>> 3. Checkstyle now shows a number (27) of "disallowed import" warnings.
>> Those are imports from "o.a.catalina.tribes" and "o.a.catalina.ha".
>>
>> I think it just means that this component depends on those,
>> and Checkstyle rules needs adjustment here.
>
> Storeconfig needs that dependency (obvious), so the warning should be
> silenced or ignored.
>
> Rémy
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1440892 - in /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner: Tomcat7Runner.java Tomcat7RunnerCli.java

[sebb]

On 31 January 2013 09:58,   wrote:
> Author: olamy
> Date: Thu Jan 31 09:58:49 2013
> New Revision: 1440892
>
> URL: http://svn.apache.org/viewvc?rev=1440892&view=rev
> Log:
> fix possible values for clientAuth
>
> Modified:
> 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
> 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
>
> Modified: 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java?rev=1440892&r1=1440891&r2=1440892&view=diff
> ==
> --- 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
>  (original)
> +++ 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
>  Thu Jan 31 09:58:49 2013
> @@ -90,7 +90,7 @@ public class Tomcat7Runner
>
>  public boolean debug = false;
>
> -public boolean clientAuth = false;
> +public String clientAuth = "false";
>
>  public String keyAlias = null;

Do these mutable values really need to be public?
Could they be private or package protected?

Exposing mutable fields makes it harder to test properly, as changes
may occur at any time.
Also changes to mutable fields are not thread-safe without synchronisation.

>
> Modified: 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java?rev=1440892&r1=1440891&r2=1440892&view=diff
> ==
> --- 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
>  (original)
> +++ 
> tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
>  Thu Jan 31 09:58:49 2013
> @@ -178,7 +178,7 @@ public class Tomcat7RunnerCli
>  }
>  if ( line.hasOption( clientAuth.getOpt() ) )
>  {
> -tomcat7Runner.clientAuth = true;
> +tomcat7Runner.clientAuth = clientAuth.getOpt();
>  }
>  if ( line.hasOption( keyAlias.getOpt() ) )
>  {
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1397522 - in /tomcat/trunk/java/javax/net: ./ websocket/ websocket/annotations/ websocket/extensions/

[sebb]

On 12 October 2012 13:39, Mark Thomas  wrote:
> On 12/10/2012 13:24, Martin Grigorov wrote:
>
> Please use quoting, particularly when you have a few short comments on a
> very large e-mail. Without quoting, your comments were more effort to find.
>
>>> Added: tomcat/trunk/java/javax/net/websocket/HandshakeRequest.java
>>> URL: 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/net/websocket/HandshakeRequest.java?rev=1397522&view=auto
>
> 
>
>>> +Object getSession();
>>
>> ^^
>> Shouldn't this return a Session instead ?
>
> No. That is an HTTP Session object and Object is used to avoid a
> dependency on the Servlet spec. I'll add some Javadoc. (I can't just
> copy the RI's Javadoc because of licensing).
>
>
>>> Added: tomcat/trunk/java/javax/net/websocket/Session.java
>>> URL: 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/net/websocket/Session.java?rev=1397522&view=auto
>
> 
>
>>> +RemoteEndpoint getRemote();
>>> +
>>> +RemoteEndpoint getRemoteL(Class c);
>>
>> Is there a typo in the method name ? Is the 'L' needed ?
>
> That is what the spec currently says. It looks like a typo. I've raised
> it with the EG.

In which case it might help to comment this in the code, so people
reading the source are aware?

> Thanks for the review.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Re-factoring TLD parsing

[sebb]

On 17 August 2012 05:00, Christopher Schultz
 wrote:
> Sebb,
>
> On 8/16/12 7:11 PM, sebb wrote:
>> On 16 August 2012 23:44, Christopher Schultz
>>  wrote:
>>>
>>> I had a conversation in Vancouver with David Blevins about the scourge
>>> of JAR-scanning in general (in that case, we were discussing
>>> annotation-processing) and I suggested that a generic JAR scanner could
>>> be built that would simply scan JARs and emit events like "found
>>> annotation" or "found JAR" or "found file" or whatever.
>>
>> What about timing?
>> If the components start up independently, there could be issues with
>> knowing when all interested parties have declared themselves and when
>> it is safe to start the scan. Equally, one component may require the
>> information before another registers.
>
> Obviously, timing can be an issue. If the scan is already done and the
> events haven't been stored somewhere, the scan needs to be re-done. At
> that point, it's no worse than the situation as it stands, today. The
> components that can benefit from this idea can, while others will not
> suffer any worse than they already do.

Provided that the scan only does what is needed by that component.
If the scanner performs multiple types of scan each time, some of that
work will be wasted.

So the components would need to be able to register for specific scan types.
The scanner would also need to keep track of which scan types are
outstanding requests.

Obviously if the scanner can cache the info, this would not apply.

> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Re-factoring TLD parsing

[sebb]

On 16 August 2012 23:44, Christopher Schultz
 wrote:
> All,
>
> The first item in the TOMCAT-NEXT.txt is this:
>
>  1. Refactor the TLD parsing. TLDs are currently parsed twice. Once by
> Catalina looking for listeners and once by Jasper.
>
> I had a conversation in Vancouver with David Blevins about the scourge
> of JAR-scanning in general (in that case, we were discussing
> annotation-processing) and I suggested that a generic JAR scanner could
> be built that would simply scan JARs and emit events like "found
> annotation" or "found JAR" or "found file" or whatever.
>
> I don't know enough about how Catalina and Jasper each handle these
> things, but would such a scanning component be helpful to them? If both
> components (Catalina and Jasper, other components) could register event
> handlers with the scanner, the number of times each JAR would be scanned
> would be limited to 1.
>
> Perhaps this strategy could be extended to TLD processing as well: the
> scanner could be configured to send TLD-specific notifications (or maybe
> just have a TLD-specific listener registered with the scanner that
> generates events like "read TLD component" or what have you).
>
> I guess the question is whether each component (Catalina, Jasper,
> whatever add-ons might be interested in similar information) can cleanly
> register their interest in receiving notification of these kinds of
> events. Is there a convenient place where components hosted by Catalina
> could naturally register for these kinds of events (or even request that
> a JAR scan occur)?

What about timing?
If the components start up independently, there could be issues with
knowing when all interested parties have declared themselves and when
it is safe to start the scan. Equally, one component may require the
information before another registers.

> Is this kind of thing overkill, or does it sound like it would be a
> truly useful utility?
>
> Thanks,
> -chris
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1358055 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/

[sebb]

On 6 July 2012 07:53,   wrote:
> Author: fhanik
> Date: Fri Jul  6 06:53:52 2012
> New Revision: 1358055
>
> URL: http://svn.apache.org/viewvc?rev=1358055&view=rev
> Log:
> implement rev 1 of async/non blocking writes
>
>

> Modified: 
> tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=1358055&r1=1358054&r2=1358055&view=diff
> ==
> --- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java 
> (original)
> +++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java 
> Fri Jul  6 06:53:52 2012

> @@ -146,8 +226,12 @@ public class InternalNioOutputBuffer ext
>   * @throws IOException
>   * TODO Fix non blocking write properly
>   */
> +int total = 0;

The above is in the wrong place; it should either be before the
Javadoc or after the private method body, not between them.

>  private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean 
> block, boolean flip) throws IOException {
> -if ( flip ) bytebuffer.flip();
> +if ( flip ) {
> +bytebuffer.flip();
> +flipped = true;
> +}
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat-maven-plugin] Is it only for Maven 3 and later? (was: svn commit r1367640)

[sebb]

On 1 August 2012 19:39, Konstantin Kolinko  wrote:
> 2012/7/31  :
>> Author: olamy
>> Date: Tue Jul 31 16:01:20 2012
>> New Revision: 1367640
>>
>> URL: http://svn.apache.org/viewvc?rev=1367640&view=rev
>> Log:
>> [MTOMCAT-157] use new Maven Plugins annotations. done for tomcat6 mojos.
>>
>> Modified:
>> tomcat/maven-plugin/trunk/pom.xml
>>(...)
>
>>
>> +org.apache.maven.plugin-tools
>> +maven-plugin-annotations
>> +3.1
>> +compile
>> +  
>
> Hi!
>
> Just to confirm:
>
>  is tomcat-maven-plugin currently designed for Apache Maven 3 and later only?

If so, can the required maven dependency be added to the pom please?

> There is a project on Jenkins "TomcatMavenPlugin-mvn2.x" [1] that is
> in the failed state for many months (and it nags me with an e-mail
> every time it builds).
>
> If maven 2 is not supported, then maybe it is now time to remove this
> project from Jenkins?
>
> [1] https://builds.apache.org/job/TomcatMavenPlugin-mvn2.x/
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1364419 - /tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java

[sebb]

On 22 July 2012 20:55,   wrote:
> Author: markt
> Date: Sun Jul 22 19:55:50 2012
> New Revision: 1364419
>
> URL: http://svn.apache.org/viewvc?rev=1364419&view=rev
> Log:
> Fingbugs: Fix possible NPE
>
> Modified:
> 
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
>
> Modified: 
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1364419&r1=1364418&r2=1364419&view=diff
> ==
> --- 
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
>  (original)
> +++ 
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
>  Sun Jul 22 19:55:50 2012
> @@ -122,13 +122,14 @@ public class TcpPingInterceptor extends
>  }
>
>  protected void sendPing() {
> -if (failureDetector.get()!=null) {
> -//we have a reference to the failure detector
> -//piggy back on that dude
> +if (failureDetector.get() != null) {
> +// We have a reference to the failure detector
> +// Piggy back on it
>  failureDetector.get().checkMembers(true);

If it's necessary to pre-fetch staticMembers just once (as below) is
it not also necessary to pre-fetch failureDetector (above) ?

They are both WeakReference fields, so surely both can return null at any time?

> -}else {
> -if (staticOnly && staticMembers.get()!=null) {
> -sendPingMessage(staticMembers.get().getMembers());
> +} else {
> +StaticMembershipInterceptor smi = staticMembers.get();
> +if (staticOnly && smi != null) {
> +sendPingMessage(smi.getMembers());
>  } else {
>  sendPingMessage(getMembers());
>  }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1358055 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/

[sebb]

On 6 July 2012 07:53,   wrote:
> Author: fhanik
> Date: Fri Jul  6 06:53:52 2012
> New Revision: 1358055
>
> URL: http://svn.apache.org/viewvc?rev=1358055&view=rev
> Log:
> implement rev 1 of async/non blocking writes
>
> @@ -146,8 +226,12 @@ public class InternalNioOutputBuffer ext
>   * @throws IOException
>   * TODO Fix non blocking write properly
>   */
> +int total = 0;

The field is misplaced; it should not be between the Javadoc and the method.

>  private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean 
> block, boolean flip) throws IOException {
> -if ( flip ) bytebuffer.flip();
> +if ( flip ) {
> +bytebuffer.flip();
> +flipped = true;
> +}
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/

[sebb]

On 15 July 2012 20:54, Mark Thomas  wrote:
> On 15/07/2012 20:49, Filip Hanik Mailing Lists wrote:
>> not sure if they want to make Java 7 minimum requirement

I'd forgotten that DBCP stands for the Don't Be Compatible Project ...

>
> That will need a discussion on the commons dev list. If no-one brings it
> up sooner, I'll bring it up once Pool2 is sorted as work will naturally
> move to dbcp2 at that point.
>
> Mark
>
>>
>> - Original Message -
>>> From: "sebb" 
>>> To: "Tomcat Developers List" 
>>> Sent: Saturday, July 14, 2012 8:04:42 PM
>>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
>>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ 
>>> res/dbcp/
>>>
>>> Do these patches need to be fed back to Commons DBCP?
>>>
>>> Or do they only apply to the version embedded by Tomcat?
>>>
>>> On 14 July 2012 21:47, Rainer Jung  wrote:
>>>> On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote:
>>>>>
>>>>> I know, it's the same patch for DBCP as for DBCP2.
>>>>
>>>>
>>>> Roger that.
>>>>
>>>>
>>>>> we can fix it, not urgent though
>>>>
>>>>
>>>> No hurry, maybe we'll be on DBCP2 until the first TC 8 release.
>>>>
>>>> Rainer
>>>>
>>>>
>>>>> - Original Message -
>>>>>>
>>>>>> From: "Rainer Jung" 
>>>>>> To: dev@tomcat.apache.org
>>>>>> Sent: Friday, July 13, 2012 3:47:27 AM
>>>>>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
>>>>>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/
>>>>>> res/dbcp/
>>>>>>
>>>>>> On 12.07.2012 17:38, fha...@apache.org wrote:
>>>>>>>
>>>>>>> Author: fhanik
>>>>>>> Date: Thu Jul 12 15:38:28 2012
>>>>>>> New Revision: 1360729
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=1360729&view=rev
>>>>>>> Log:
>>>>>>> Configure Tomcat trunk to build with Java 7.
>>>>>>> This includes adding a patch to the Commons-DBCP code from
>>>>>>> res/dbcp
>>>>>>>
>>>>>>>
>>>>>>> Added:
>>>>>>>   tomcat/trunk/res/dbcp/
>>>>>>>   tomcat/trunk/res/dbcp/dbcp-java-7.patch   (with props)
>>>>>>
>>>>>>
>>>>>> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a
>>>>>> few
>>>>>> minutes ago, many of the offsets when applying the patch were
>>>>>> quite
>>>>>> big:
>>>>>>
>>>>>>[copy] Copying 68 files to
>>>>>> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java
>>>>>>   [patch] Hunk #1 succeeded at 660 (offset -114 lines).
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/DelegatingResultSet.java
>>>>>>   [patch] Hunk #1 succeeded at 1078 (offset -196 lines).
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/PoolingDataSource.java
>>>>>>   [patch] Hunk #1 succeeded at 437 (offset -52 lines).
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/DelegatingConnection.java
>>>>>>   [patch] Hunk #1 succeeded at 678 (offset -126 lines).
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/PoolingDriver.java
>>>>>>   [patch] Hunk #1 succeeded at 496 (offset -5 lines).
>>>>>>   [patch] patching file
>>>>>> src/java/org/apache/commons/dbcp/DelegatingStatement.java
>>>>>>   [patch] Hunk #1 succeeded at 385 (offset -144 lines).
>>>>>>   [patch] patching file
>>>>>> sr

Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/

[sebb]

Do these patches need to be fed back to Commons DBCP?

Or do they only apply to the version embedded by Tomcat?

On 14 July 2012 21:47, Rainer Jung  wrote:
> On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote:
>>
>> I know, it's the same patch for DBCP as for DBCP2.
>
>
> Roger that.
>
>
>> we can fix it, not urgent though
>
>
> No hurry, maybe we'll be on DBCP2 until the first TC 8 release.
>
> Rainer
>
>
>> - Original Message -
>>>
>>> From: "Rainer Jung" 
>>> To: dev@tomcat.apache.org
>>> Sent: Friday, July 13, 2012 3:47:27 AM
>>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./
>>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/
>>> res/dbcp/
>>>
>>> On 12.07.2012 17:38, fha...@apache.org wrote:

 Author: fhanik
 Date: Thu Jul 12 15:38:28 2012
 New Revision: 1360729

 URL: http://svn.apache.org/viewvc?rev=1360729&view=rev
 Log:
 Configure Tomcat trunk to build with Java 7.
 This includes adding a patch to the Commons-DBCP code from res/dbcp


 Added:
   tomcat/trunk/res/dbcp/
   tomcat/trunk/res/dbcp/dbcp-java-7.patch   (with props)
>>>
>>>
>>> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a few
>>> minutes ago, many of the offsets when applying the patch were quite
>>> big:
>>>
>>>[copy] Copying 68 files to
>>> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java
>>>   [patch] Hunk #1 succeeded at 660 (offset -114 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/DelegatingResultSet.java
>>>   [patch] Hunk #1 succeeded at 1078 (offset -196 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/PoolingDataSource.java
>>>   [patch] Hunk #1 succeeded at 437 (offset -52 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/DelegatingConnection.java
>>>   [patch] Hunk #1 succeeded at 678 (offset -126 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/PoolingDriver.java
>>>   [patch] Hunk #1 succeeded at 496 (offset -5 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/DelegatingStatement.java
>>>   [patch] Hunk #1 succeeded at 385 (offset -144 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java
>>>   [patch] Hunk #1 succeeded at 1206 (offset -171 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/BasicDataSource.java
>>>   [patch] Hunk #1 succeeded at 28 with fuzz 1.
>>>   [patch] Hunk #2 succeeded at 1580 (offset -221 lines).
>>>   [patch] patching file
>>> src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java
>>>   [patch] Hunk #1 succeeded at 887 (offset -1 lines).
>>>
>>> Compilation for everything including DBCP works though.
>>>
>>> Regards,
>>>
>>> Rainer
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.28

[sebb]

On 15 June 2012 10:14, Mark Thomas  wrote:
> The proposed Apache Tomcat 7.0.28 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.28/

The NOTICE file for the source archive includes references to Nullsoft
and Eclipse which AFAICT are not actually present in the archive.

AFAIK, the NOTICE file should only be for required notices.

The way I look at this is: if Tomcat were released as source only (no
binaries) would the entries in NOTICE be required?

> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-243/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_28/
>
> The proposed 7.0.27 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.28 Stable
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] Apache Tomcat Native 1.1.24 released

[sebb]

On 14 June 2012 15:58, Mladen Turk  wrote:
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat Native 1.1.24 stable.

Please include a brief synopsis (1 or 2 sentences) of the purpose of
the TLP/Product in all announcements sent outside the TLP mailing
lists.

The developers and users will (presumably) know what the product is
about, but others are unlikely to know.

S.
P.S. Just about every other TLP includes this information, including HTTD...
> Please refer to the change log for the list of changes:
> http://tomcat.apache.org/native-doc/miscellaneous/changelog.html
>
> Downloads:
> http://tomcat.apache.org/download-native.cgi
>
> Thank you,
> --
> The Apache Tomcat Team
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: native connector tool chain

[sebb]

On 21 May 2012 21:01, Mark Thomas  wrote:
> On 21/05/2012 17:52, Mladen Turk wrote:
>> On 05/21/2012 02:05 PM, Mark Thomas wrote:
>>> I am trying to build the 1.1.x native connector from trunk so I can test
>>> the changes I plan to make to support per socket time outs. I can build
>>> using dynamic linking but not statically. What tool chain are folks
>>> currently using to build the native connector binaries we currently ship?
>>>
>>> My current issue relates to statically linking to OpenSSL. I get the
>>> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using:
>>> - Visual Studio 6 + SP6
>>> - Win 2003 r2 Platform SDK
>>> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html
>>
>> If those binaries were not compiled with VS6 you can't statically link
>> them. When I build binaries I build both of those (and apr) with the
>> same compiler.
>>
>> Yeah, it's not trivial task.
>
> :) Got it working!
>
> For the benefit of the archives, I ended up using:

Maybe this info should also be saved somewhere in SVN?

> - Visual Studio 6 + SP6
> - Win 2003 r2 Platform SDK
> - OpenSSL source bundle 0.9.x
> - APR 1.4.x src (I used the 1.4.6 tag)
> - native source (I used the 1.1.x branch)
>
> OpenSSL 1.x will not work with the VS6 tool chain.
>
> My aim is to build the 64-bit APR/native DLL. 32-bit should be pretty similar.
>
> Stage 1: OpenSSL build
> This is pretty close to the OpenSSL docs INSTALL.W64
> - Set up the environment to build with the Platform SDK
>  %PLATFORM_SDK_HOME%\SetEnv.Cmd /X64 /RETAIL
> - Follow the OpenSSL build instructions
>  perl Configure VC-WIN64A
>  ms\do_win64a
>  nmake -f ms\nt.mak
>
> The *.lib files you'll need are in the out32 directory.
>
> Stage 2: Start VS6 in x64 mode
> You'll need a batch file that looks something like this:
> call "C:\Program Files\PlatformSDK\SetEnv.Cmd" /X64 /RETAIL
> start "" "C:\Program Files (x86)\Microsoft Visual 
> Studio\Common\MSDev98\Bin\MSDEV.EXE" /useenv
>
> Stage 3: Open the workspace
> Depending on where APR is, you'll need to specify paths to the projects
>
> Stage 4: Build APR
> Make sure you can build the "apr x64" Release target
> You may need to tweak src and library paths.
>
> Stage 5: Create a tcnative x64 target
> Copy the Win32 release configuration and name it x64 Release
> Add /machine:AMD64 to the link options (you can't remove the I368 option - 
> just make sure you add the new one after it)
> Tweak the src and library paths as required.
>
> For both stage 4 and 5 you may need to add additional standard libraries. 
> Google the linking error you get to figure out which.
>
> HTH,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.36

[sebb]

On 9 May 2012 15:25, Mladen Turk  wrote:
> Hi,
>
> Apache Tomcat Connectors 1.2.36 release candidate is ready
> for vote at [1]. This version solves shared memorz regression(s)
> found in released version 1.2.35 and allows )again= compiling
> against old httpd 1.3.x.
>
>
> The VOTE will remain open for at least 48 hours.

Just curious - why only 48 hours? The normal rule is a minimum of 72 hours.

> The Apache Tomcat Connectors 1.2.36 is
>  [ ] Stable, go ahead and release
>  [ ] Broken because of ...
>
>
>
>  [1] http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.36/
>
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1336516 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AbstractEndpoint.java webapps/docs/changelog.xml

[sebb]

On 10 May 2012 08:50,   wrote:
> Author: rjung
> Date: Thu May 10 07:50:29 2012
> New Revision: 1336516
>
> URL: http://svn.apache.org/viewvc?rev=1336516&view=rev
> Log:
> Add public method to retrieve the current connectionCount
> from an endpoint.
>
> It will also show up in the ThreadPool MBean.
>
> Backport of r1336515 from trunk.
>
> Modified:
>    tomcat/tc7.0.x/trunk/   (props changed)
>    tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
>    tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>
> Propchange: tomcat/tc7.0.x/trunk/
> --
>  Merged /tomcat/trunk:r1336515
>
> Modified: 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1336516&r1=1336515&r2=1336516&view=diff
> ==
> --- 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
> (original)
> +++ 
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
> Thu May 10 07:50:29 2012
> @@ -173,6 +173,14 @@ public abstract class AbstractEndpoint {
>     }
>
>     public int  getMaxConnections() { return this.maxConnections; }
> +

Javadoc?
In particular, it would help if the condition under which -1 is
returned were documented. ...

> +    public long getConnectionCount() {
> +        if (connectionLimitLatch != null) {
> +            return connectionLimitLatch.getCount();
> +        }
> +        return -1;
> +    }
> +
>     /**
>      * External Executor based thread pool.
>      */
>
> Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
> URL: 
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1336516&r1=1336515&r2=1336516&view=diff
> ==
> --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu May 10 07:50:29 2012
> @@ -121,6 +121,11 @@
>         The new default value will never go above 2 regardless of
>         available processors. (fhanik)
>       
> +      
> +        Allow to retrieve the current connectionCount
> +        via getter from the endpoint and as JMX attribute of the ThreadPool
> +        mbean. (rjung)
> +      
>     
>   
>   
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Taglibs build #2 failed due to Hudson error

[sebb]

On 31 March 2012 03:23, Jeremy Boynes  wrote:
> From the log:
> https://builds.apache.org/job/taglib-standard/2/consoleText
>
> Parsing POMs
> ERROR: Failed to parse POMs
> hudson.util.IOException2: remote file operation failed: 
> /home/jenkins/jenkins-slave/workspace/taglib-standard at 
> hudson.remoting.Channel@1c4071a9:ubuntu3
>        at hudson.FilePath.act(FilePath.java:828)
>        at hudson.FilePath.act(FilePath.java:814)
>        at 
> hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:914)
>        at 
> hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:658)
>        at 
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
>        at hudson.model.Run.run(Run.java:1410)
>        at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
>        at hudson.model.ResourceController.execute(ResourceController.java:88)
>        at hudson.model.Executor.run(Executor.java:238)
> Caused by: java.io.FileNotFoundException: 
> /tmp/hudson-remoting6347775300781058040/META-INF/plexus/components.xml (No 
> such file or directory)
>        at java.io.FileOutputStream.open(Native Method)
>        at java.io.FileOutputStream.(FileOutputStream.java:194)
>        at java.io.FileOutputStream.(FileOutputStream.java:145)
>        at 
> hudson.remoting.RemoteClassLoader.makeResource(RemoteClassLoader.java:270)
>        at 
> hudson.remoting.RemoteClassLoader.findResources(RemoteClassLoader.java:237)
>        at java.lang.ClassLoader.getResources(ClassLoader.java:1040)
>        at java.lang.ClassLoader.getResources(ClassLoader.java:1036)
>        at 
> hudson.maven.MavenUtil$MaskingClassLoader.getResources(MavenUtil.java:291)
>        at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:199)
>        at 
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1218)
>        at 
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1049)
>        at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
>        at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>        at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>        at hudson.remoting.Request$2.run(Request.java:287)
>        at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>        at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>        at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>        at java.lang.Thread.run(Thread.java:662)
>
> Resubmitting the build worked fine. What causes this type of problem?

Jenkins bug or problem with Jenkins hosts.

> Thanks
> Jeremy
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 2

[sebb]

On 24 March 2012 14:45, Jeremy Boynes  wrote:
> The proposed 2 release of Apache Taglibs Parent POM is now available for 
> voting.
>
> This release addresses issues found during the 1 release process including 
> duplicate LICENSE files and poor site configuration.
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-107/
>
> and SVN tag is:
> http://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs-parent-2/

NOTICE says
Copyright 2009-2012

pom.xml has
2000

These are inconsistent.

> Please vote on whether Apache Taglibs Parent 2 should be:
> [+1] Released, or
> [-1] Not released because ...
>
> Thanks
> Jeremy
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: License/Notice Files

[sebb]

On 18 March 2012 16:05, Jeremy Boynes  wrote:
> It looks like the source assembly that packages the source distributions will 
> prefer files in the project over files from the remote resources bundle. So 
> is we rename LICENSE.txt to just LICENSE there will only be one copy and it 
> will be the one from this project. I'm going to do that for the files in the 
> root of each trunk so that they will be in the top level of anything checked 
> out from SVN, and remove the ones further down the directory tree leaving it 
> to the plugin to add them to each distribution. If in the future we add 
> dependencies with notice requirements we can add that to the particular 
> module at that time.

OK, great.

> On Mar 4, 2012, at 5:40 PM, sebb wrote:
>
>> On 4 March 2012 03:44, Jeremy Boynes  wrote:
>>> On Feb 29, 2012, at 11:37 AM, sebb wrote:
>>>
>>>> On 29 February 2012 19:15, Olivier Lamy  wrote:
>>>>> Perso, I prefer using something which read pom and generate
>>>>> automatically N&L from metadatas rather than maintaining those files
>>>>> manually (for me manually means you always missed to add/modify :-) )
>>>>> (but sure it's my POV)
>>>>
>>>> AFAICT that just moves the work from maintaining the N&L to creating
>>>> and maintaining the metadata.
>>>>
>>>> It also means that the N&L files are not present in SVN (unless they
>>>> are checked in after generation).
>>>
>>> My preference here is also to have them generated. We want the metadata in 
>>> the project descriptor to be valid anyway, and maintaining the templates 
>>> for LICENSE and NOTICE would be handled by maintainers of the Apache 
>>> resources. We don't have any dependencies requiring a notice, and if we do 
>>> this should be covered with append-resources.
>>>
>>> The files wouldn't be in SVN but will be in the distributed archives. 
>>> Having this done automatically rather than by configuring each archiver 
>>> will be easier to keep straight.
>>
>> I think just about every project has N&L files at the top-level of SVN.
>> [If they don't, perhaps they should]
>>
>> Not sure it is an absolute requirement (unlike in archives and jars)
>> but it is helpful for 3rd parties who browse the SVN tree.
>>
>>> --
>>> Jeremy
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: License/Notice Files

[sebb]

On 4 March 2012 03:44, Jeremy Boynes  wrote:
> On Feb 29, 2012, at 11:37 AM, sebb wrote:
>
>> On 29 February 2012 19:15, Olivier Lamy  wrote:
>>> Perso, I prefer using something which read pom and generate
>>> automatically N&L from metadatas rather than maintaining those files
>>> manually (for me manually means you always missed to add/modify :-) )
>>> (but sure it's my POV)
>>
>> AFAICT that just moves the work from maintaining the N&L to creating
>> and maintaining the metadata.
>>
>> It also means that the N&L files are not present in SVN (unless they
>> are checked in after generation).
>
> My preference here is also to have them generated. We want the metadata in 
> the project descriptor to be valid anyway, and maintaining the templates for 
> LICENSE and NOTICE would be handled by maintainers of the Apache resources. 
> We don't have any dependencies requiring a notice, and if we do this should 
> be covered with append-resources.
>
> The files wouldn't be in SVN but will be in the distributed archives. Having 
> this done automatically rather than by configuring each archiver will be 
> easier to keep straight.

I think just about every project has N&L files at the top-level of SVN.
[If they don't, perhaps they should]

Not sure it is an absolute requirement (unlike in archives and jars)
but it is helpful for 3rd parties who browse the SVN tree.

> --
> Jeremy
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1295724 - in /tomcat/trunk/webapps/examples/WEB-INF: classes/websocket/EchoMessage.java web.xml

[sebb]

On 1 March 2012 18:27,   wrote:
> Author: fhanik
> Date: Thu Mar  1 18:27:56 2012
> New Revision: 1295724
>
> URL: http://svn.apache.org/viewvc?rev=1295724&view=rev
> Log:
> Allow the examples to configure the buffer on the fly
>
> Modified:
>    tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
>    tomcat/trunk/webapps/examples/WEB-INF/web.xml
>
> Modified: 
> tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java?rev=1295724&r1=1295723&r2=1295724&view=diff
> ==
> --- tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java 
> (original)
> +++ tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java 
> Thu Mar  1 18:27:56 2012
> @@ -20,6 +20,8 @@ import java.io.IOException;
>  import java.nio.ByteBuffer;
>  import java.nio.CharBuffer;
>
> +import javax.servlet.ServletException;
> +
>  import org.apache.catalina.websocket.MessageInbound;
>  import org.apache.catalina.websocket.StreamInbound;
>  import org.apache.catalina.websocket.WebSocketServlet;
> @@ -28,13 +30,40 @@ import org.apache.catalina.websocket.Web
>  public class EchoMessage extends WebSocketServlet {
>
>     private static final long serialVersionUID = 1L;
> +    private volatile int byteBufSize;
> +    private volatile int charBufSize;
> +
> +    @Override
> +    public void init() throws ServletException {
> +        super.init();
> +        byteBufSize = getInitParameterIntValue("byteBufferMaxSize", 2097152);
> +        charBufSize = getInitParameterIntValue("charBufferMaxSize", 2097152);

Value does not agree with below.
Is that intended?

> +    }
> +
> +    public int getInitParameterIntValue(String name, int defaultValue) {
> +        String val = this.getInitParameter(name);
> +        int result = defaultValue;
> +        try {
> +            result = Integer.parseInt(val);
> +        }catch (Exception x) {
> +        }
> +        return result;
> +    }
> +
> +
>
>     @Override
>     protected StreamInbound createWebSocketInbound(String subProtocol) {
> -        return new EchoMessageInbound();
> +        return new EchoMessageInbound(byteBufSize,charBufSize);
>     }
>
>     private static final class EchoMessageInbound extends MessageInbound {
> +
> +        public EchoMessageInbound(int byteBufferMaxSize, int 
> charBufferMaxSize) {
> +            super();
> +            setByteBufferMaxSize(byteBufferMaxSize);
> +            setCharBufferMaxSize(charBufferMaxSize);
> +        }
>
>         @Override
>         protected void onBinaryMessage(ByteBuffer message) throws IOException 
> {
>
> Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1295724&r1=1295723&r2=1295724&view=diff
> ==
> --- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original)
> +++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Thu Mar  1 18:27:56 2012
> @@ -359,6 +359,8 @@
>     
>       wsEchoMessage
>       websocket.EchoMessage
> +      
> byteBufferMaxSize20971520
> +      
> charBufferMaxSize20971520

Value does not agree with above.
Is that intended?

>     
>     
>       wsEchoMessage
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 1

[sebb]

On 29 February 2012 19:15, Olivier Lamy  wrote:
> Perso, I prefer using something which read pom and generate
> automatically N&L from metadatas rather than maintaining those files
> manually (for me manually means you always missed to add/modify :-) )
> (but sure it's my POV)

AFAICT that just moves the work from maintaining the N&L to creating
and maintaining the metadata.

It also means that the N&L files are not present in SVN (unless they
are checked in after generation).

> BTW Did you create any issues for that ?
>
> 2012/2/29 sebb :
>> On 29 February 2012 05:11, Konstantin Kolinko  wrote:
>>> 2012/2/29 Jeremy Boynes :
>>>> Removed from svn. A dry run of the next release shows they are 
>>>> automatically added to the source bundle.
>>>>
>>>
>>> 1. Where it takes those files from?  Is their content correct.
>>>
>>> Besides extra blank lines before and after the text in NOTICE file,
>>
>> I'd forgotten about that - that's one reason why we don't use the
>> auto-generated N&L files in Commons.
>> [In a previous Maven release, IIRC the NOTICE file had even more
>> extraneous text]
>>
>> Personally, I think it's a big mistake for the Apache Parent to
>> generate these files automatically.
>> They only apply to projects with no 3rd party dependencies or code.
>> IMO the N&L files are too important to be auto-generated.
>>
>> Also, by using the auto-generated copies, SVN is left without any N&L
>> files at the head of the tree.
>>
>> I would urge taglibs to use local copies of N&L files which can be
>> properly maintained in SVN, and ignore the auto-generated ones.
>>
>>> there is small difference:
>>> NOTICE:
>>> Copyright 2000-2012 The Apache Software Foundation
>>> NOTICE.txt:
>>> Copyright 2009-2012 The Apache Software Foundation
>>>
>>> Is  in pom.xml correct (2000) ?
>>>
>>>
>>> 2. Looking at site.xml in source bundle and current site at
>>> http://tomcat.apache.org/taglibs/
>>>
>>> - I do not see a link to  http://www.apache.org/licenses/
>>> - I do not see a link to  http://tomcat.apache.org/security.html
>>>
>>> 3. commons-skin dependency says v.2.  I see that there is v.3 at Maven 
>>> Central.
>>>
>>>
>>> [x] +1 to go, but I think v2 will be needed before we release any of
>>> the taglibs.
>>>
>>> It is hard to judge without looking at a site generated from this parent 
>>> pom.
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>>
>>>> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote:
>>>>
>>>>> On 02/28/2012 08:57 PM, sebb wrote:
>>>>>> On 28 February 2012 16:43, Mladen Turk  wrote:
>>>>>>>
>>>>>>> Although not sure why you have LICENSE and LICENSE.txt as well
>>>>>>> as NOTICE and NOTICE.txt with the same content
>>>>>>
>>>>>> That is probably caused by the Apache POM, which tries to be helpful
>>>>>> by adding the N&L for you.
>>>>>>
>>>>>
>>>>> Right, that should be the cause.
>>>>>
>>>>>> We had to disable that part in Commons, because we don't use the same
>>>>>> naming convention (and the AP does not allow for the names to be
>>>>>> changed).
>>>>>>
>>>>>
>>>>> Whatever... Think that this should be easy to solve.
>>>>> Just rm extra files if maven will add them automatically
>>>>> and the content is satisfactory.
>>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 1

[sebb]

On 29 February 2012 18:07, Jeremy Boynes  wrote:
> Reverted r1294943.
>
> Do you know how this was addressed in Commons?

Yes, see commons-parent pom

http://repo1.maven.org/maven2/org/apache/commons/commons-parent/23/commons-parent-23.pom

search for NOTICE

> Any patches? :)
>
> On Feb 29, 2012, at 9:14 AM, sebb wrote:
>
>> On 29 February 2012 05:11, Konstantin Kolinko  wrote:
>>> 2012/2/29 Jeremy Boynes :
>>>> Removed from svn. A dry run of the next release shows they are 
>>>> automatically added to the source bundle.
>>>>
>>>
>>> 1. Where it takes those files from?  Is their content correct.
>>>
>>> Besides extra blank lines before and after the text in NOTICE file,
>>
>> I'd forgotten about that - that's one reason why we don't use the
>> auto-generated N&L files in Commons.
>> [In a previous Maven release, IIRC the NOTICE file had even more
>> extraneous text]
>>
>> Personally, I think it's a big mistake for the Apache Parent to
>> generate these files automatically.
>> They only apply to projects with no 3rd party dependencies or code.
>> IMO the N&L files are too important to be auto-generated.
>>
>> Also, by using the auto-generated copies, SVN is left without any N&L
>> files at the head of the tree.
>>
>> I would urge taglibs to use local copies of N&L files which can be
>> properly maintained in SVN, and ignore the auto-generated ones.
>>
>>> there is small difference:
>>> NOTICE:
>>> Copyright 2000-2012 The Apache Software Foundation
>>> NOTICE.txt:
>>> Copyright 2009-2012 The Apache Software Foundation
>>>
>>> Is  in pom.xml correct (2000) ?
>>>
>>>
>>> 2. Looking at site.xml in source bundle and current site at
>>> http://tomcat.apache.org/taglibs/
>>>
>>> - I do not see a link to  http://www.apache.org/licenses/
>>> - I do not see a link to  http://tomcat.apache.org/security.html
>>>
>>> 3. commons-skin dependency says v.2.  I see that there is v.3 at Maven 
>>> Central.
>>>
>>>
>>> [x] +1 to go, but I think v2 will be needed before we release any of
>>> the taglibs.
>>>
>>> It is hard to judge without looking at a site generated from this parent 
>>> pom.
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>>
>>>> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote:
>>>>
>>>>> On 02/28/2012 08:57 PM, sebb wrote:
>>>>>> On 28 February 2012 16:43, Mladen Turk  wrote:
>>>>>>>
>>>>>>> Although not sure why you have LICENSE and LICENSE.txt as well
>>>>>>> as NOTICE and NOTICE.txt with the same content
>>>>>>
>>>>>> That is probably caused by the Apache POM, which tries to be helpful
>>>>>> by adding the N&L for you.
>>>>>>
>>>>>
>>>>> Right, that should be the cause.
>>>>>
>>>>>> We had to disable that part in Commons, because we don't use the same
>>>>>> naming convention (and the AP does not allow for the names to be
>>>>>> changed).
>>>>>>
>>>>>
>>>>> Whatever... Think that this should be easy to solve.
>>>>> Just rm extra files if maven will add them automatically
>>>>> and the content is satisfactory.
>>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1294943 - in /tomcat/taglibs/taglibs-parent/trunk: LICENSE.txt NOTICE.txt

[sebb]

On 29 February 2012 02:19,   wrote:
> Author: jboynes
> Date: Wed Feb 29 02:19:53 2012
> New Revision: 1294943
>
> URL: http://svn.apache.org/viewvc?rev=1294943&view=rev
> Log:
> remove LICENCE.txt and NOTICE.txt as they are automatically added by Maven 
> release process

-1

I think that's the wrong solutiion; see my comments on the dev list thread.

> Removed:
>    tomcat/taglibs/taglibs-parent/trunk/LICENSE.txt
>    tomcat/taglibs/taglibs-parent/trunk/NOTICE.txt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 1

[sebb]

On 29 February 2012 05:11, Konstantin Kolinko  wrote:
> 2012/2/29 Jeremy Boynes :
>> Removed from svn. A dry run of the next release shows they are automatically 
>> added to the source bundle.
>>
>
> 1. Where it takes those files from?  Is their content correct.
>
> Besides extra blank lines before and after the text in NOTICE file,

I'd forgotten about that - that's one reason why we don't use the
auto-generated N&L files in Commons.
[In a previous Maven release, IIRC the NOTICE file had even more
extraneous text]

Personally, I think it's a big mistake for the Apache Parent to
generate these files automatically.
They only apply to projects with no 3rd party dependencies or code.
IMO the N&L files are too important to be auto-generated.

Also, by using the auto-generated copies, SVN is left without any N&L
files at the head of the tree.

I would urge taglibs to use local copies of N&L files which can be
properly maintained in SVN, and ignore the auto-generated ones.

> there is small difference:
> NOTICE:
> Copyright 2000-2012 The Apache Software Foundation
> NOTICE.txt:
> Copyright 2009-2012 The Apache Software Foundation
>
> Is  in pom.xml correct (2000) ?
>
>
> 2. Looking at site.xml in source bundle and current site at
> http://tomcat.apache.org/taglibs/
>
> - I do not see a link to  http://www.apache.org/licenses/
> - I do not see a link to  http://tomcat.apache.org/security.html
>
> 3. commons-skin dependency says v.2.  I see that there is v.3 at Maven 
> Central.
>
>
> [x] +1 to go, but I think v2 will be needed before we release any of
> the taglibs.
>
> It is hard to judge without looking at a site generated from this parent pom.
>
> Best regards,
> Konstantin Kolinko
>
>
>> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote:
>>
>>> On 02/28/2012 08:57 PM, sebb wrote:
>>>> On 28 February 2012 16:43, Mladen Turk  wrote:
>>>>>
>>>>> Although not sure why you have LICENSE and LICENSE.txt as well
>>>>> as NOTICE and NOTICE.txt with the same content
>>>>
>>>> That is probably caused by the Apache POM, which tries to be helpful
>>>> by adding the N&L for you.
>>>>
>>>
>>> Right, that should be the cause.
>>>
>>>> We had to disable that part in Commons, because we don't use the same
>>>> naming convention (and the AP does not allow for the names to be
>>>> changed).
>>>>
>>>
>>> Whatever... Think that this should be easy to solve.
>>> Just rm extra files if maven will add them automatically
>>> and the content is satisfactory.
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 1

[sebb]

On 28 February 2012 16:43, Mladen Turk  wrote:
> On 02/27/2012 12:33 AM, Jeremy Boynes wrote:
>>
>> OK. Artefacts re-staged at
>> https://repository.apache.org/content/repositories/orgapachetomcat-084/
>>
>
> +1
> Signatures and content OK.
>
> Although not sure why you have LICENSE and LICENSE.txt as well
> as NOTICE and NOTICE.txt with the same content
> (well, the only difference is that .txt files are missing
>  trailing new lines).
>
> I could understand if they were LF/CRL-LF, but as they are currently
> it makes no sense.
> You should probably fix that in future releases.
>

That is probably caused by the Apache POM, which tries to be helpful
by adding the N&L for you.

We had to disable that part in Commons, because we don't use the same
naming convention (and the AP does not allow for the names to be
changed).

> Regards
> --
> ^TM
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Taglibs Parent POM 1

[sebb]

On 26 February 2012 23:33, Jeremy Boynes  wrote:
> OK. Artefacts re-staged at
> https://repository.apache.org/content/repositories/orgapachetomcat-084/

Looks a bit odd to have

orgapachetomcat

above

yet the Maven package is org.apache.taglibs ?
But perhaps that's just a feature of Nexus.

Using o.a.taglibs looks like the TLP name is taglibs - is that likely
to cause a problem in future?

>
> Thanks
> Jeremy
>
> On Feb 26, 2012, at 3:00 PM, Olivier Lamy wrote:
>
>> 2012/2/26 Jeremy Boynes :
>>> I do but I can't as it seems I signed with the wrong key - a subkey that is 
>>> not recognized.
>>>
>>> Can I just delete the subkey from my keyring and re-run release:perform?
>> Yup.
>> Just delete the current staging repository.
>> If you still have the target/checkout directory locally, run: mvn
>> deploy -Papache-release
>>
>>
>>>
>>> On Feb 26, 2012, at 11:20 AM, Olivier Lamy wrote:
>>>
 Hello Jeremy,
 I think you must first close the repository in the "Staging
 repositories" entry menu.
 After that the url
 (https://repository.apache.org/content/repositories/orgapachetomcat-068/)
 will be available.


 2012/2/25 Jeremy Boynes :
> The proposed Apache Taglibs Parent POM v1 release is now available for 
> voting.
>
> This contains Maven project metadata for building and releasing the 
> actual Taglibs project files.
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-068/
>
> The svn tag is:
> https://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs-parent-1/
>
> The proposed v1 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as v1 Stable
>
> Cheers
> Jeremy
>



 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1292891 - /tomcat/trunk/bin/daemon.sh

[sebb]

On 23 February 2012 19:00, Konstantin Kolinko  wrote:
> 2012/2/23  :
>> Author: markt
>> Date: Thu Feb 23 18:44:02 2012
>> New Revision: 1292891
>>
>> URL: http://svn.apache.org/viewvc?rev=1292891&view=rev
>> Log:
>> Fix BZ52750. Correctly parse command options
>> Port of r1292878 from 7.0.x
>>
>> Modified:
>>    tomcat/trunk/bin/daemon.sh   (contents, props changed)
>>
>> Modified: tomcat/trunk/bin/daemon.sh
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/bin/daemon.sh?rev=1292891&r1=1292890&r2=1292891&view=diff
>> ==
>> --- tomcat/trunk/bin/daemon.sh (original)
>> +++ tomcat/trunk/bin/daemon.sh Thu Feb 23 18:44:02 2012
>> @@ -34,9 +34,9 @@ while [ -h "$ARG0" ]; do
>>  done
>>  DIRNAME="`dirname $ARG0`"
>>  PROGRAM="`basename $ARG0`"
>> -for o
>> +while [ ".$1" != . ]
>
> Maybe:
> while [ -n "$1" ]
>  (though both variants should work work)
>
>>  do
>> -  case "$o" in
>> +  case "$o=1" in
>
> What the above line is about?

I wondered the same myself;
it so happens that the "=" key is next to the "Backspace" key, so I
suspect the intention was to delete the "o" ...

> Was it supposed to be:
>  case "$1" in
>
>>     --java-home )
>>         JAVA_HOME="$2"
>>         shift; shift;
>>
>> Propchange: tomcat/trunk/bin/daemon.sh
>>            ('svn:executable' removed)
>>
>
> 231                     echo "Unkown command: \`$1'"
>
> Unknown
>
> 232                     echo "Usage: $PROGRAM ( commands ... )"
>
> $PROGRAM [--options] ( commands ... )
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat web site UI update

[sebb]

On 15 February 2012 20:04, Jeremy Brown  wrote:
>>That is a comment that the layout needs to be
>>cleaner (a comment I agree with).
>
> I agree too. I tried to create a cleaner layout and I posted a mockup for
> all to see and voice their opinions.
>
> https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg

Looks good.

There's no obvious link to the Tomcat License - this is a problem with
the existing site, but perhaps could be fixed at the same time.

> I'll leave it to Mark, Konstantin, Wesley and whomever else to let me know
> when it is reasonable to move forward.
>
> Cheers, Jeremy
>
>
>
> On Tue, Feb 14, 2012 at 11:40 AM, Mark Thomas  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 14/02/2012 16:21, Christopher Schultz wrote:
>> > Mark,
>> >
>> > On 2/13/12 5:28 PM, Mark Thomas wrote:
>> >> On 13/02/2012 20:11, Christopher Schultz wrote:
>> >>>
>> >>> IIRC, Pid did a bunch of work toward that end and it was
>> >>> ultimately vetoed
>> >>
>> >> Reference please. That is not my recollection at all.
>> >
>> > Markmail remembers:
>> >
>> > http://markmail.org/message/og235cbvrdluiejg
>>
>> That isn't a veto. That is a comment that the layout needs to be
>> cleaner (a comment I agree with). From a style point of view it is a
>> big improvement.
>>
>> Mark
>>
>> >
>> >> My recollection was that pid started down this road but hasn't
>> >> found the time to finish it, or at least get it to a state where
>> >> enough was complete that it could be committed.
>> >
>> > Konstantin liked it for the ROOT webapp, but not the Tomcat main
>> > site. Same with Wesley Acheson.
>> >
>> > -chris
>> >
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQIcBAEBAgAGBQJPOpx3AAoJEBDAHFovYFnnxEIP/Rvhm+UYlVq5enUzWlPbLmWC
>> ZPXcduolPXTVwU2jpIZpSw020677h92kq3dWFL7JSlKNhuHK2C/fS0iI9YYY0Xp/
>> L9qYf7fvzSvzka7wUFJxFXLwPX6uoDAFwFtr+KSBmus3S206elkCCtILB/z06itA
>> VE31NVqOmXqLq7ZrqsE+4oxzqdkiJV1Cl1uKfR+O0LRJJ39Yl5+LyjThRDWdandC
>> JoWDnJhz/rAWC473X4NWh9q0LXK04uiufvHN3qtq1tbjl2YQ2tkEdcgJilXXCOF/
>> NgcnvBlWw5R6o9w2Hm7X5xu6YAi8FS1sdWZ5QAihMud23pxT4KCUlK7DSzz2v3Yt
>> vWXEWpbaOD7kFa2c1Wj8dxED4q9ZB8UZZfBkCpG/AGXA1W1DrygPOePkRCNMzBSe
>> L7JWBU5CBJ6avlSnEFMXZIgXg/iVf0bGJUSZr+nL9auoDmJwyN46/HyDeK9ucWyn
>> O6TTzCFgCrcI01k7sVt3vrmtX2/JcvF2O0XMGRYTD/6trFWg96eA7NeOab7Rq90S
>> S6HcEFWGgM52/SibK49yc1J1oQvwNFHzZ2FNINMLBHRI4FjnbLbwxqF8IcZtKs+5
>> YlbpiiXz+9LIUS8negOTTStXJFqmGaauYMZmIDf7JxFfxozCCQsayifzn+62STrX
>> bx3sI4uobJxVqoNNe++B
>> =F97+
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1243508 - in /tomcat/site/trunk: docs/tools.html xdocs/tools.xml

[sebb]

On 13 February 2012 13:50,   wrote:
> Author: kkolinko
> Date: Mon Feb 13 13:50:43 2012
> New Revision: 1243508
>
> URL: http://svn.apache.org/viewvc?rev=1243508&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52652
> Correct typos in tools.html
>
> s/licence/license/ seems to be GB vs UK. IDE hilights "licence" as 
> misspelled, event though m dictionary knows this word.

[GB vs US?]

In the UK, different spellings are used for the noun (licence) and the
verb (license).
"Get your licence from the licensing authority".
See for example the Ofcom website [1]

Similarly for practice/practise.

However, the US seems to use license for both noun and verb.

[1] http://licensing.ofcom.org.uk/

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org