Re: Redirect to buffer strategy may not work properly on Tomcat 7.0.29

[Martin Grigorov]

Hi Pedro,

I've CC-ed Tomcat's team, so they can explain better what Tomcat does.

On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos
pedros...@gmail.com wrote:
 Hi Martin,

 I don't see how to wrap the request or the response can be useful here. Even 
 if we decorate the container request to return its URI based on the page 
 being rendered address it will not be enough because Servlet API does not 
 allow us to change the composition of a response. i.e. we are not able to set 
 on which request URI the encode method of the response will work on (Tomcat 
 API allows such thing but I'd rather not use to it).

I don't quite understand what you mean with the above.
As far as I understood Mark he suggests to use
HttpServletRequestWrapper which should return the proper base url when
asked (#getRequestURI, #getPath, etc.)

Thinking more about it now I don't see how this will help actually
because this wrapper will be reachable only by Wicket code. To encode
an URL Wicket calls HttpServletResponse#encodeURL(), note this is the
*response*, and it has no reference from the response to the wrapped
request, so Tomcat will be able to find and use only the original
request.
Wrapping the response and link it to it the wrapped request wont help
because Tomcat wont be able to cast to our custom wrappers.


 I simply don't get why Tomcat added such validation in the encode method. To 
 redirect the request to a buffered response is a very common strategy that 
 has being saving tons of applications from double form submissions for 
 instance rather than a weird web framework implementation like I read in the 
 ticket.

Do you know of another bigger web framework that uses this approach ?
If you know please mention it in the ticket. This will be a stronger
argument for Tomcat to not ignore this solution.

It all started with a ticket by me in Tomcat's Bugzilla to normalize
the absolute urls which are send in Location response header. This
is the redirect url. Before the ticket Tomcat was sending urls like
'http://www.example.com/a/b/../c/d.html' and '..' in this url caused
some problems in some cases, e.g. JMeter complained about it, and
Chris Colman reported an issue with IE when using Tomcat virtual
hosts.
So now Tomcat normalizes the url to
'http://www.example.com/a/c/d.html' before sending it to the client.
All good so far.

The new problem is that Tomcat uses the normalization even in
#encodeURL(), this method just encodes jsessionid if needed, even for
relative urls. To decide whether the relative url is part of the
current application Tomcat makes the url absolute and normalizes it.
When Wicket starts rendering the rendering for PageB (from my first
mail) it produces relative urls to PageB, but later Tomcat normalizes
them against PageA and url like
'http://www.example.com/a/b/../../../../c/d.html' fails because there
are too many '..'s.

I hope the problem is more clear now.


 It looks like the response will not encode the session id to links and 
 callbacks in the buffered pages in a deeper path from Tomcat 7.0.29 on. I'm 
 OK with the way the Tomcat team worked around this issue. Who knows if they 
 aren't only doing some good by preventing some session fixation attacks.

They didn't workaround it yet. For now we discuss possible solutions
for the next version.


 Pedro Santos

 Em 25/07/2012, às 16:42, Martin Grigorov escreveu:

 Hi,

 Please take a look at 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=53469.
 This issue describes a problem which prevents Wicket's default
 RenderStrategy - REDIRECT_TO_BUFFER.

 Basically the problem is:
 - PageA mounted at /mount/pageA is requested
 - the code uses setResponsePage(PageB.class) which is mounted at
 /deeper/mount/path/pageB
 - Wicket starts to render PageB (in the same request cycle) and for
 each url in the page it asks the web container to encode it
 (HttpServletResponse#encodeURL())
 - here Tomcat 7.0.29+ tries to find whether the url to encode is part
 of the web app. To do this it makes the relative url passed by Wicket
 to absolute by using the HttpServletRequest's requestURI (i.e.
 /mount/pageA). This may get wrong because Wicket actually generates
 the urls against /deeper/mount/path/pageB

 Mark Thomas (Tomcat dev) suggests that Wicket could use
 HttpServletRequestWrapper which should return the correct requestURI
 depending on the current request cycle baseUrl.

 Any ideas and comments are welcome!

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: latency - websockets vs. REST

[Martin Grigorov]

You can check with Google Chrome and/or IE10 to see whether it is not
something in Firefox


On Tue, Jan 29, 2013 at 9:19 PM, Michael Roberts m...@7f.com wrote:

 This was using .35 with the default connector (just a generic tomcat
 install using the installer, on windows 7 64bit) from current firefox.  I
 can't tell you the exact time difference currently, but I can say that if I
 chain the calling of the REST API off the end off the completion of the
 WebSocket's sendMessage, the REST API call will consistently beat the web
 socket to the end point.  Which (I think) means that either it's latency in
 moz's web socket implementation, or it's at the server end.

 I will make a test case which does exact timing and is separated from our
 application and report back on what I find.

 MR

 On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas ma...@apache.org wrote:

  On 29/01/2013 20:04, Michael Roberts wrote:
   I'm seeing some differences in the latency of making a post request via
   jQuery versus sending a websockets message.  It maybe that this is
  overhead
   in my application caused by processing the json I am sending in the
   message, but I find this hard to believe.  I imagined that web socket
   connection should be faster than REST due to it not creating and
  destroying
   the socket, however this does not seem to be the case.  Is there a
 reason
   why websockets should be slower?
  
   I thing I can code up a small test case to illustrate this if this is
   something people are interested in ..
 
  Tomcat version?
  Connector?
  How much difference?
 
  REST can (and should for performance) use HTTP keep-alive.
 
  There is some overhead in upgrading an HTTP connection to use WebSocket
  so for a single request I'd expect the REST request to be faster. Once
  both connections are established, WebSocket should be faster (note that
  binary messages will be faster than text ones).
 
  If you have a test case that demonstrates this with established
  connections I'd certainly be interested.
 
  Mark
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: dev-h...@tomcat.apache.org
 
 




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/

Re: [ANN] New Tomcat committer: Violeta Georgieva (violetagg)

[Martin Grigorov]

Welcome, Violeta!

I'm glad SAP decided to use an open source web container for its
application server!
Some day I'll convince them to use another good Apache product instead of
Web Dynpro! ;-)


On Thu, Jan 31, 2013 at 5:22 PM, Mark Thomas ma...@apache.org wrote:

 On behalf of the Tomcat committers I am pleased to announce that Violeta
 Georgieva (violetagg) has been voted in as a new Tomcat committer.

 Please join me in welcoming her.

 Mark

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




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/

Re: URIs, %nn decoding and error handling

[Martin Grigorov]

Hi,

Recently we had a bug report at Apache Wicket about this problem [1] - when
the user agent sends a request with wrong URL encoding (in the query
string) then Wicket throws an exception which was not easy to be handled by
the application. The exception was 1) logged by the web container and 2)
error code 500 returned. And 1) was the biggest problem - an attacker can
easily flood the application logs by just issuing a request with bad url
encoding.
I've checked how Jetty and Tomcat react on such requests with a plain
Servlet and the results were:
-- jetty - throw an exception + error code 400
-- tomcat - fully ignore the bad url encoding

I've thought that Tomcat intentionally behaves like this to prevent the
problem above.

Wicket uses custom UrlDecoder implementation so it was easy to change the
behavior. Now Wicket logs an INFO message and drops the badly url encoded
entity. This way the application developers have better control on handling
this type of error - they can ignore it completely by configuring their
preferred logging library or log it in separate (rotating) log file.


1. https://issues.apache.org/jira/browse/WICKET-4803


On Fri, Mar 1, 2013 at 10:36 PM, Mark Thomas ma...@apache.org wrote:

 Due to bug 54602 [1] I have been writing some test cases to examine how we
 handle invalid bytes sequences in URIs.

 My expectation was:
 - valid byte sequence for expected encoding - 200 (assuming no other
   problems)
 - invalid byte sequence for expected encoding - 400
 - partial byte sequence for expected encoding - 400

 However, that isn't what happens and I currently believe that this should
 happen. The purpose of this e-mail is, therefore, to get agreement on what
 should happen.

 There are multiple moving parts here so forgive me if this e-mail gets a
 little long. There are multiple decisions and I expect some to be less
 contentious than others.

 These issues were observed with UTF-8. Other encodings may have similar
 issues. May aim is to get a consistent approach regardless of encoding.

 Issue 1: URI ends with partial byte sequence
 Currently the partial byte sequences are ignored. I think the B2CConverter
 should throw an Exception if the full input (i.e. when endOfInput == true)
 ends in with a partial byte sequence

 Issue 2: URI ends with invalid byte sequence
 This appears to be a bug in the UTF-8 decoder provided by the JVM. [1] has
 provided one set of input bytes that triggers this. Currently the invalid
 data is ignored. I think that B2CConverter should throw an Exception as
 soon as it can determine that input is invalid. This would require:
 - switching to the Harmony based UTF-8 decoder used by WebSocket
 - further testing of the JRE and Harmony UTF-8 decoders to check for other
 potential issues

 Issue 3: Fall back to 'ASCII'
 If the conversion fails (i.e. throws an exception for any reason) [2], the
 CoyoteAdapter attempts to decode the provided URI using 'ASCII' rather than
 the configured connector encoding. I say 'ASCII because the comments say
 ASCII but it is actually ISO-8859-1.
 I don't believe it appropriate to fall back to anything here. The fall
 back code has been present since conversion support was added but I can't
 think of any scenario where this stands any chance of working reliably. I
 would like to remove this fall back code.

 I would like to make these changes in trunk and 7.0.x.

 I expect to have a similar discussion about request bodies once URIs are
 resolved where I have essentially the same view - a decoding error should
 lead to a request failure.

 Thoughts?

 Mark


 [1] 
 https://issues.apache.org/**bugzilla/show_bug.cgi?id=54602https://issues.apache.org/bugzilla/show_bug.cgi?id=54602
 [2] http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/**
 catalina/connector/**CoyoteAdapter.java?view=**annotatehttp://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=annotate(line
  ~1054)

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




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/

Re: svn commit: r1509143 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/ha/deploy/FileMessageFactory.java webapps/docs/changelog.xml

[Martin Grigorov]

Hi,


On Thu, Aug 1, 2013 at 11:25 AM, kfuj...@apache.org wrote:

 Author: kfujino
 Date: Thu Aug  1 09:25:12 2013
 New Revision: 1509143

 URL: http://svn.apache.org/r1509143
 Log:
 Fix NPE in FileMessageFactory.main when specify empty file as arguments.

 Modified:

 tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java
 tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

 Modified:
 tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java
 URL:
 http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java?rev=1509143r1=1509142r2=1509143view=diff

 ==
 ---
 tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java
 (original)
 +++
 tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java
 Thu Aug  1 09:25:12 2013
 @@ -376,6 +376,10 @@ public class FileMessageFactory {
  FileMessageFactory write = getInstance(new File(args[1]), true);
  FileMessage msg = new FileMessage(null, args[0], args[0]);
  msg = read.readMessage(msg);
 +if (msg == null) {
 +System.out.println(Empty input file :  + args[0]);


Do you really mean System.out here ?
Usually loggers are used.


 +return;
 +}
  System.out.println(Expecting to write  + msg.getTotalNrOfMsgs()
  +  messages.);


I see it is used even before.


  int cnt = 0;

 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=1509143r1=1509142r2=1509143view=diff

 ==
 --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
 +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Aug  1 09:25:12
 2013
 @@ -193,6 +193,10 @@
  bug55301/bug: Fix codeIllegalArgumentException/code
 thrown by
  simple test for McastService. (kfujino)
/fix
 +  fix
 +bug55332/bug: Fix NPE in codeFileMessageFactory.main/code
 when
 +specify empty file as arguments. (kfujino)
 +  /fix
  /changelog
/subsection
subsection name=Other



 -
 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-RC1

[Martin Grigorov]

Hi,

I'm playing with the WebSocket impl and started seeing this NPE in my logs.
I have no idea yet what started causing it.

== logs/catalina.out ==
Aug 02, 2013 6:03:21 PM
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
SEVERE: Error reading request, ignored
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124)
 at
java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1162)
at org.apache.tomcat.websocket.WsSession.init(WsSession.java:148)
 at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:118)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
 at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592)
 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)



On Thu, Aug 1, 2013 at 10:53 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.0 release candidate 1 is now available
 for voting.

 Given this is a release candidate I am working on the basis that it is
 equivalent to an alpha. That said:
 - Servlet 3.1 is complete
 - JSP 2.3 is complete
 - EL 3.0 is complete
 - WebSocket 1.0 is complete
 - DBCP2 is working but in a state of flux but the early stages of JMX
   monitoring are available


 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC1/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-048/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC1/

 The proposed 8.0.0-RC1 release is:
 [ ] Broken - do not release
 [ ] Alpha - go ahead and release as 8.0.0-RC1 alpha

 Cheers,

 Mark

 -
 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-RC1

[Martin Grigorov]

I cannot login to Bugzilla with my account ...

The problem is:
this.userProperties.putAll(endpointConfig.getUserProperties());

a HashMap is copied into ConcurrentHashMap and null values cause the
problem.


On Fri, Aug 2, 2013 at 6:06 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 I'm playing with the WebSocket impl and started seeing this NPE in my logs.
 I have no idea yet what started causing it.

 == logs/catalina.out ==
 Aug 02, 2013 6:03:21 PM
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
 SEVERE: Error reading request, ignored
 java.lang.NullPointerException
 at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124)
  at
 java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1162)
 at org.apache.tomcat.websocket.WsSession.init(WsSession.java:148)
  at
 org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:118)
 at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
  at
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
 at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592)
  at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:724)



 On Thu, Aug 1, 2013 at 10:53 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.0 release candidate 1 is now available
 for voting.

 Given this is a release candidate I am working on the basis that it is
 equivalent to an alpha. That said:
 - Servlet 3.1 is complete
 - JSP 2.3 is complete
 - EL 3.0 is complete
 - WebSocket 1.0 is complete
 - DBCP2 is working but in a state of flux but the early stages of JMX
   monitoring are available


 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC1/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-048/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC1/

 The proposed 8.0.0-RC1 release is:
 [ ] Broken - do not release
 [ ] Alpha - go ahead and release as 8.0.0-RC1 alpha

 Cheers,

 Mark

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

Re: svn commit: r1509847 - in /tomcat/trunk/java/javax/websocket: DefaultClientEndpointConfig.java server/DefaultServerEndpointConfig.java

[Martin Grigorov]

Hi Mark,

Thanks for the fix!

On Fri, Aug 2, 2013 at 10:28 PM, ma...@apache.org wrote:

 Author: markt
 Date: Fri Aug  2 20:28:12 2013
 New Revision: 1509847

 URL: http://svn.apache.org/r1509847
 Log:
 Use the same Map implementation for user properties to prevent
 implementation conflicts

 Modified:
 tomcat/trunk/java/javax/websocket/DefaultClientEndpointConfig.java

 tomcat/trunk/java/javax/websocket/server/DefaultServerEndpointConfig.java


Is it OK to change the JSR API jars ?
The change is binary compatible per se, but I wonder whether such changes
in classes would not lead to different behavior in different web containers.




 Modified:
 tomcat/trunk/java/javax/websocket/DefaultClientEndpointConfig.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/DefaultClientEndpointConfig.java?rev=1509847r1=1509846r2=1509847view=diff

 ==
 --- tomcat/trunk/java/javax/websocket/DefaultClientEndpointConfig.java
 (original)
 +++ tomcat/trunk/java/javax/websocket/DefaultClientEndpointConfig.java Fri
 Aug  2 20:28:12 2013
 @@ -16,9 +16,9 @@
   */
  package javax.websocket;

 -import java.util.HashMap;
  import java.util.List;
  import java.util.Map;
 +import java.util.concurrent.ConcurrentHashMap;

  final class DefaultClientEndpointConfig implements ClientEndpointConfig {

 @@ -26,7 +26,7 @@ final class DefaultClientEndpointConfig
  private final ListExtension extensions;
  private final ListClass? extends Encoder encoders;
  private final ListClass? extends Decoder decoders;
 -private final MapString,Object userProperties = new HashMap();
 +private final MapString,Object userProperties = new
 ConcurrentHashMap();
  private final Configurator configurator;



 Modified:
 tomcat/trunk/java/javax/websocket/server/DefaultServerEndpointConfig.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/server/DefaultServerEndpointConfig.java?rev=1509847r1=1509846r2=1509847view=diff

 ==
 ---
 tomcat/trunk/java/javax/websocket/server/DefaultServerEndpointConfig.java
 (original)
 +++
 tomcat/trunk/java/javax/websocket/server/DefaultServerEndpointConfig.java
 Fri Aug  2 20:28:12 2013
 @@ -16,9 +16,9 @@
   */
  package javax.websocket.server;

 -import java.util.HashMap;
  import java.util.List;
  import java.util.Map;
 +import java.util.concurrent.ConcurrentHashMap;

  import javax.websocket.Decoder;
  import javax.websocket.Encoder;
 @@ -36,7 +36,7 @@ final class DefaultServerEndpointConfig
  private final ListClass? extends Encoder encoders;
  private final ListClass? extends Decoder decoders;
  private final Configurator serverEndpointConfigurator;
 -private final MapString,Object userProperties = new HashMap();
 +private final MapString,Object userProperties = new
 ConcurrentHashMap();

  DefaultServerEndpointConfig(
  Class? endpointClass, String path,



 -
 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-RC3

[Martin Grigorov]

On Fri, Sep 20, 2013 at 12:36 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.0 release candidate 3 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 RC1 are:
 - Updated spec implementations with results of various grey area
 discussions from the EG mailing lists
 - Now uses UTF-8 by default
 - Switch to async logging and one-line log format by default
 - New doc style
 - Refactored TLD parsing (work in progress)
 - Fixed all the issues reported against RC1  RC2
 - Add Servlet 3.1 non-blocking support to the AJP connectors
 - Fix an issue with the new WebResources and packed WAR files

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-080/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/

 The proposed 8.0.0-RC3 release is:
 [ ] Broken - do not release
 [X] Alpha - go ahead and release as 8.0.0-RC3 alpha


Apache Wicket Native WebSockets based on JSR356 works fine.


 Cheers,

 Mark

 -
 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.44

[Martin Grigorov]

On Mon, Sep 23, 2013 at 10:58 PM, Violeta Georgieva miles...@gmail.comwrote:

 The proposed Apache Tomcat 7.0.44 release is now available for voting.
 This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
 Note that use of this functionality requires Java 7.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.44/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-090/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_44/

 The proposed 7.0.44 release is:
 [ ] Broken - do not release
 [X] Stable - go ahead and release as 7.0.44 Stable


Tested Apache Wicket Native WebSocket with both Tomcat 7 websocket impl and
the new JSR356 impl.



 Regards
 Violeta

Re: [VOTE] Release Apache Tomcat 7.0.44

[Martin Grigorov]

Hi Rossen,


On Tue, Sep 24, 2013 at 4:35 PM, Rossen Stoyanchev 
rstoyanc...@gopivotal.com wrote:

 I am getting a ClassCastException when using (non JSR-356) upgrade,
 i.e. WsServerContainer.doUpgrade:

 Caused by: java.lang.ClassCastException:

 org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper
 cannot be cast to org.apache.catalina.connector.RequestFacade


See
https://github.com/apache/wicket/blob/master/wicket-experimental/wicket-native-websocket/wicket-native-websocket-tomcat/src/main/java/org/apache/wicket/protocol/ws/tomcat7/Tomcat7WebSocketFilter.java#L81

I had to add this code exactly because of Spring Security -
https://issues.apache.org/jira/browse/WICKET-5266. But it is valid for any
other usage of HttpServletRequestWrapper


 at
 org.apache.tomcat.websocket.server.UpgradeUtil.doUpgrade(UpgradeUtil.java:183)
 at
 org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(WsServerContainer.java:235)
 at
 org.springframework.web.socket.server.support.TomcatRequestUpgradeStrategy.upgradeInternal(TomcatRequestUpgradeStrategy.java:77)
 at
 org.springframework.web.socket.server.support.AbstractStandardUpgradeStrategy.upgrade(AbstractStandardUpgradeStrategy.java:59)
 at
 org.springframework.web.socket.server.DefaultHandshakeHandler.doHandshake(DefaultHandshakeHandler.java:183)
 at
 org.springframework.web.socket.sockjs.transport.handler.WebSocketTransportHandler.handleRequest(WebSocketTransportHandler.java:82)

 Also what's the equivalent of the Tomcat 8 tomcat-websocket
 dependency? I see the 7.0.44 binary has tomcat7-websocket.jar but I


Here is what I use for Apache Wicket integration:
https://github.com/apache/wicket/blob/master/wicket-experimental/wicket-native-websocket/wicket-native-websocket-tomcat/pom.xml#L43


 can't find such a dependency in the staging maven repository.

 Thanks,
 Rossen


 On Mon, Sep 23, 2013 at 4:58 PM, Violeta Georgieva miles...@gmail.com
 wrote:
  The proposed Apache Tomcat 7.0.44 release is now available for voting.
  This release candidate contains JSR-356 Java WebSocket 1.0
 implementation.
  Note that use of this functionality requires Java 7.
 
  It can be obtained from:
  https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.44/
  The Maven staging repo is:
  https://repository.apache.org/content/repositories/orgapachetomcat-090/
  The svn tag is:
  http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_44/
 
  The proposed 7.0.44 release is:
  [ ] Broken - do not release
  [ ] Stable - go ahead and release as 7.0.44 Stable
 
  Regards
  Violeta

 -
 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

[Martin Grigorov]

On Wed, Sep 25, 2013 at 3:37 PM, Violeta Georgieva miles...@gmail.comwrote:

 The proposed Apache Tomcat 7.0.45 release is now available for voting.
 This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
 Note that use of this functionality requires Java 7.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.45/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-098/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_45/

 The proposed 7.0.45 release is:
 [ ] Broken - do not release
 [X] Stable - go ahead and release as 7.0.45 Stable

 Regards
 Violeta

Re: WebappClassLoader and prohibited classes/packages

[Martin Grigorov]

Hi,


On Wed, Oct 23, 2013 at 6:38 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 All,

 I went looking into WebappClassLoader's validateJarFile() and filter()
 methods, and I noticed two things:

 1. The error message for locating an illegal class being loaded from a
 JAR file references servlet spec 2.3 section 9.7.2. The current
 published version of the spec (3.0) is now section 10.7.2. Any
 objections to changing the message to reflect the new spec version
 supported by Tomcat and the new section number?


+1


 2. In spite of the above spec section, Tomcat only checks for
 javax.servlet.Servlet and/or javax.el.Expression and then rejects the
 entire JAR file. It doesn't look like classes such as java.lang.String
 or javax.xml.parsers.SAXParser, etc. are prohibited. This seems to be a
 spec violation.


It is not allowed to create a custom class in java.* package.
You can probably put java.lang.String in a custom jar, but it will be the
same class as provided by the JDK. It could be a different version than the
runtime JRE though ...
So I agree that it should be rejected.

I'm not 100% certain but I think it is OK to create custom classes in
javax.** package. So I think these should not be prohibited.



 3. If a JAR file is found to contain a prohibited class, the entire JAR
 file is rejected. This behavior is not mandated by the servlet spec and
 may be over-reaching.


Do you know what would be the performance effect of rejecting just the
problematic class and check the rest of the classes in the JAR ?
The current fail-fast behavior seems like a good optimization to me.



 I'm sure there are all kinds of practical reasons to only look for
 certain classes, and not to prohibit replacement of things like JSTL,
 etc. But it seems like this should be tightened-up a bit, even if
 through configuration things can be relaxed to their current state.

 Any thoughts?

 -chris

Re: Git

[Martin Grigorov]

Hi Rainer,


On Tue, Jan 21, 2014 at 1:01 PM, Rainer Jung rainer.j...@kippdata.dewrote:

 On 21.01.2014 10:58, Mark Thomas wrote:
  I've been using Git more and more for Tomcat development and was
  wondering what folks thought about moving Tomcat to git. This isn't a
  formal proposal or a vote, I'm just trying to gather some views.
 
  On the plus side:
  - it is much easier to have multiple issues in progress at the
same time and switch between them
  - being able to work off-line but still commit is a huge benefit
when working on a complex issue and you don't have internet
access
  - merging between branches (assuming all supported branches were in a
single repo) is simpler
 
  Neutral
  - we would need to agree some simple guidelines for how we used git
  - tooling seems equivalent to that available for svn (at for what I
use anyway)
 
  On the down side:
  - there is much more potential to mess things up
  - cleaning up is potentially more complex
  - the disruption of the move - particularly if we want to move to a
single git repo - could be significant
 
 
  Thoughts?

 I am slightly positive for a move but there's one thing I was negatively
 surprised a couple of times: commit emails. Our current commit emails
 are very easy to read and contain all the needed information. I guess
 some of that will be adjustable for the git commit mails, but the ones I
 looked at today (using wicket as an example), had something like the
 first line of the commit log as the mail subject. That could be better
 or worse than what we have in svn currently, depending on the log message.


Yes, this is adjustable.
Just it is in the hands of Apache Infra.
I have asked once for read-only access to the Git hooks (
http://git-scm.com/book/en/Customizing-Git-Git-Hooks) but they rejected.
I guess it will be easier for you or Mark as Infra members.



 I remember having seen many merge type commit messages somewhere,
 where the subject basically carries no information on what was changed,
 because it always says Merge. Sometimes such mails do not contain a
 diff in the body but only the information, which ids have been merged
 between which branches. These are the ones I find really unhelpful. I
 haven't dug deeper into it though.


The merge commits appear when you use git merge or git pull in the
fix/feature branch.
If you stick to git rebase or git pull --rebase then there is no such
noise in the Git history.
I use git pull --rebase daily and had no merge problems.



 The PHP project has a weekly or so message automated about pull requests
 waiting to be handled. Something like that might be needed because if we
 move to git the community will expect us to watch for contributions
 coming via GitHub.


Contributions via GitHub doesn't work well at the moment with Apache
projects. There are few discussions about this in members@.
I use https://github.com/github/hub to make it easier to merge remote
branches. I prefer command line but many devs don't.



 My 2ct.

 Rainer

 -
 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

[Martin Grigorov]

Hi,

Broken - do not release.

It seems WebSocket support is broken for Google Chrome 32+.

I tested Apache Wicket integration and it failed with:
WebSocket connection to
'ws://localhost:8080/ws/wicket/websocket?pageId=0wicket-ajax-baseurl=behavior?0'
failed: Invalid UTF-8 sequence in header value

So I tested Tomcat's demo apps:
http://localhost:8080/examples/websocket/echo.xhtml

And I see the same error.

Joakin from Jetty team recently informed me that there is a breaking change
in Chrome's behavior in ver. 32:
https://issues.apache.org/jira/browse/WICKET-5453?focusedCommentId=13853464page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13853464

I run Ubuntu 13.10 and my Chrome version is 32.0.1700.77

Martin Grigorov
Wicket Training and Consulting


On Tue, Jan 28, 2014 at 9:28 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.0 release is now available for voting.

 This is the first non-RC release so I am leaving all the stability
 options open to get an idea of where folks think we currently stand.

 The main changes since RC10 are:
 - Fix broken sendfile support in NIO
 - Add a readOnly option for WebResourceSet
 - Fix the regression in handling ternary expressions
 - Separate out JARs for EL, JSP and WebSocket for embedded
 - Remove svn keywords from source
 - Numerous bug fixes and improvements

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1002/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0/

 The proposed 8.0.0 release is:
 [ ] Broken - do not release
 [ ] Alpha  - go ahead and release as 8.0.0 (alpha)
 [ ] Beta   - go ahead and release as 8.0.0 (beta)
 [ ] Stable - go ahead and release as 8.0.0 (stable)

 Cheers,

 Mark

 -
 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

[Martin Grigorov]

On Wed, Jan 29, 2014 at 12:37 PM, Mark Thomas ma...@apache.org wrote:

 On 29/01/2014 10:11, Martin Grigorov wrote:
  Hi,
 
  Broken - do not release.
 
  It seems WebSocket support is broken for Google Chrome 32+.
 
  I tested Apache Wicket integration and it failed with:
  WebSocket connection to
 
 'ws://localhost:8080/ws/wicket/websocket?pageId=0wicket-ajax-baseurl=behavior?0'
  failed: Invalid UTF-8 sequence in header value
 
  So I tested Tomcat's demo apps:
  http://localhost:8080/examples/websocket/echo.xhtml
 
  And I see the same error.

 Thanks for the report. Tomcat was incorrectly sending back a value of 
 rather than not sending the header at all. I've fixed that for 7.0.x and
 8.0.x.

 I'm currently leaning towards not cancelling the release solely because
 of this issue. I think there is value in making 8.0.0 available even if
 8.0.1 follows fairly quickly. My main reasoning is that this issue
 exists in both 8.0.0-RC10 and 8.0.0 and overall, 8.0.0 is better quality
 than 8.0.0.


I'm OK with this. I can use Firefox or older Chrome until the next release.
Thanks!



 Mark


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

Request parameters in HandshakeRequest

[Martin Grigorov]

Hi,

Apologies in advance if this is for users@.

Should javax.websocket.server.HandshakeRequest#getParameterMap() contain
the parameters from the query string ?

There is javax.websocket.server.HandshakeRequest#getQueryString() but I
don't see how WebSocket request can be done with POST method so I this the
parameter map should contain the parsed query string, no ?

In the voted 8.0.0 release the map is empty when there is non-empty query
string.

Thanks!

Martin Grigorov
Wicket Training and Consulting

Re: Request parameters in HandshakeRequest

[Martin Grigorov]

On Wed, Jan 29, 2014 at 1:06 PM, Mark Thomas ma...@apache.org wrote:

 On 29/01/2014 11:44, Martin Grigorov wrote:
  Hi,
 
  Apologies in advance if this is for users@.
 
  Should javax.websocket.server.HandshakeRequest#getParameterMap() contain
  the parameters from the query string ?

 It should.

  There is javax.websocket.server.HandshakeRequest#getQueryString() but I
  don't see how WebSocket request can be done with POST method so I this
 the
  parameter map should contain the parsed query string, no ?

 RFC6455 requires that only GET is used.

  In the voted 8.0.0 release the map is empty when there is non-empty query
  string.

 Mark


False alarm.
The problem was in my code. Found it while creating a demo app.
Thanks!



 -
 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.1

[Martin Grigorov]

[ X ] Stable - go ahead and release as 8.0.1 (stable)

I see no problems with 8.0.1

Martin Grigorov
Wicket Training and Consulting


On Thu, Jan 30, 2014 at 12:43 AM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.1 release is now available for voting.

 This should be the first non-RC release so I am leaving all the
 stability options open to get an idea of where folks think we currently
 stand.

 The main changes since RC10 are:
 - Fix broken sendfile support in NIO
 - Add a readOnly option for WebResourceSet
 - Fix the regression in handling ternary expressions
 - Separate out JARs for EL, JSP and WebSocket for embedded
 - Remove svn keywords from source
 - Numerous bug fixes and improvements
 The fixes since 8.0.0 are:
 - Fix regression in async timeout
 - Fix WebSocket bug that broke WebSocket support with newer versions of
   Chrome

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.1/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1003/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_1/

 The proposed 8.0.1 release is:
 [ ] Broken - do not release
 [ ] Alpha  - go ahead and release as 8.0.1 (alpha)
 [ ] Beta   - go ahead and release as 8.0.1 (beta)
 [ ] Stable - go ahead and release as 8.0.1 (stable)

 Cheers,

 Mark

 -
 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.52

[Martin Grigorov]

[ X ] Stable - go ahead and release as 7.0.52 Stable

Tested Wicket Native WebSocket old and new impls

Martin Grigorov
Wicket Training and Consulting


On Thu, Feb 13, 2014 at 9:17 AM, Violeta Georgieva miles...@gmail.comwrote:

 The proposed Apache Tomcat 7.0.52 release is now available for voting.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.52/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1007/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_52/

 The proposed 7.0.52 release is:
 [ ] Broken - do not release
 [ ] Stable - go ahead and release as 7.0.52 Stable

 Regards
 Violeta

Re: [VOTE] Release Apache Tomcat 8.0.4

[Martin Grigorov]

On Thu, Mar 20, 2014 at 3:35 PM, Jeanfrancois Arcand jfarcand@gmail.com
 wrote:


 On 2014-03-19, 5:14 PM, Mark Thomas wrote:

 http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_4/

 The proposed 8.0.4 release is:
 [ ] Broken - do not release
 [ ] Alpha  - go ahead and release as 8.0.4 (alpha)
 [ ] Beta   - go ahead and release as 8.0.4 (beta)
 [X] Stable - go ahead and release as 8.0.4 (stable)

 Tested WebSocket (jsr356) and AsyncContext, with all major Browsers and
 WebSocket Client.

 -- Jeanfrancois


 Cheers,

 Mark


[X] Stable - go ahead and release as 8.0.4 (stable)

Martin Grigorov
Wicket Training and Consulting



  -
 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: CI

[Martin Grigorov]

Hi,

There are failed disks with BuildBot's master server (hostname: aegis).
pctony (infra guy) said that they have ordered new ones and they will
replace them today (US time ?!).

Martin Grigorov
Wicket Training and Consulting


On Thu, Apr 17, 2014 at 3:37 PM, Rémy Maucherat r...@apache.org wrote:

 Hi,

 I'm a bit confused about the infra for CI.

 - ci.apache.org seems down
 - http://vmgump.apache.org/gump/public/tomcat-trunk/ does mostly the same,
 isn't down but apparently doesn't have a build status history; also it has
 a tomcat-trunk-test-nio2
 http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-nio2/index.html
 which
 was added by someone

 Thanks,
 Rémy

Re: Tomcat Buildbot configuration - JIRA issue

[Martin Grigorov]

Hi Konstantin,

On Mon, May 26, 2014 at 2:59 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 Hi!

 I filed the issue for our Buildbot configuration:
 https://issues.apache.org/jira/browse/INFRA-7807

 You may want to keep a watch on it or add a comment.

 Best regards,
 Konstantin Kolinko


I don't remember whether I have asked INFRA for commit rights or I have
them because I am a committer at Wicket project but I can edit
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/wicket.conf
.
The BuildBot job is restarted/recreated at most 5 mins after a commit. If
there are any errors in the new configuration then the old one is still
used and the errors are mailed to the commit author so you can fix them.

All I'm saying is that you can fix all the issues yourself if you know
BuildBot's DSL. Otherwise Gavin is your contact at INFRA for BuildBot stuff.



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

Re: Git (again)

[Martin Grigorov]

Hi,


On Mon, May 26, 2014 at 4:18 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2014-05-24 0:51 GMT+04:00 Sylvain Laurent slaur...@apache.org:
  Hello,
 
  Back in january/february there was a thread on moving to git with many
 +1 for it. Are there any concrete plans for this ?
 
  I'm looking forward to it as using SVN from Europe is so slow... or
 maybe I'm now too accustomed to git's speed ;-)
 
  I was wondering what the workflow would be for tomcat development with
 git : currently some commits are made on trunk, then potentially
 selectively merged to tomcat 7 then 6.
  With git, how would it look like ? cherry picks ? that's not very in the
 spirit of git.
  Or fixes on tomcat 6 or 7 and then merge to 8 ? In that case tomcat 8
 would be branch master and tomcat 6 and 7 would be on their own branch and
 merges would look like 6 - 7 - master ?
  I'm quite used to such a workflow for enterprise app dev where we add
 features to master, very rarely to the old/stable version... but this is
 actually not the case with tomcat...

 I think we can be friendly to git mirrors with our svn configuration,
 but I am that that we cannot move Tomcat to git now.

 My technical reasons:
 1. There is svn externals reference from Tomcat Native to Tomcat Trunk.


I am not expert in neither SVN externals nor in Git submodules but I think
this should be OK with Git submodules assuming that both Tomcat and Tomcat
Native are Git repos.
See http://git-scm.com/book/en/Git-Tools-Submodules


 2. svn revision numbers are used on the config difference form in the
 migration guide.


I guess this may become Git commit ids after the migration.


 3. The plan to create a Maven build (BZ 56397) relies on svn externals.

 My subjective reasons:
 4. I do not believe that git will be faster.

 - For Subversion there is mirror in Europe and svn up runs
 considerably fast. For Git at Apache I think there is only one server
 in USA, so I expect it to be slower.


My experience is the opposite. I live in Bulgaria and when Wicket used SVN
even the EU mirror was very slow for me. With Git (US server!) it is
definitely better.



 - Subversion Commit is expected to be slower, because it has to go to
 US server (via write-through proxy in Europe) and it has to trigger
 post-commit hooks.

 - With Subversion I have a single working copy that spans all 3 active
 branches which I can update at once.


With Git this is possible too.
I use git-new-workdir for that. See
http://thejspr.com/blog/work-on-multiple-branches-with-git-workdir/
So I have three different folders on my file system - one for wicket-1.5.x
branch, one for wicket-6.x and one for wicket-7.x (master) that all share
the same .git/ folder.
So git fetch updates all of them in one step.



 Is there a way to configure Git locally in the same way? Do I miss
 something?

 My understanding that with Git I need to have several local
 repositories, because working copy is tied to a repository instance
 (the .git subdirectory).

 Even with configuration that Mark proposed (all branches in the same
 repository), I would have several local copies of that repository.

 5. I think Subversion is a lover entrance barrier than Git. As of now,


s/lover/lower/ ;)
Yes, SVN is simpler.


 we support both systems.

 - Subversion checkouts take less disk space.
 - Subversion configuration on Windows platform is easier.

 Best regards,
 Konstantin Kolinko

 -
 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.9

[Martin Grigorov]

[X] Stable - go ahead and release as 8.0.9 (stable)


On Mon, Jun 23, 2014 at 11:52 AM, Mark Thomas ma...@apache.org wrote:

 On 19/06/2014 15:00, Mark Thomas wrote:
  The proposed Apache Tomcat 8.0.9 release is now available for voting.
 
  The main changes since 8.0.8 are:
  - Start to move towards RFC6265 for cookie handling
  - Better error handling when the error occurs after the response has
been committed
  - Various Jasper improvements to make it easier for other containers
(e.g. Jetty) to consume
 
  It can be obtained from:
  https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.9/
  The Maven staging repo is:
  https://repository.apache.org/content/repositories/orgapachetomcat-1016/
  The svn tag is:
  http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_9/
 
  The proposed 8.0.9 release is:
  [ ] Broken - do not release
  [ ] Alpha  - go ahead and release as 8.0.9 (alpha)
  [ ] Beta   - go ahead and release as 8.0.9 (beta)
  [X] Stable - go ahead and release as 8.0.9 (stable)

 Unit tests pass on 64-bit Windows, Linux and OSX with BIO, NIO, NIO2 and
 APR/native (native 1.1.30).

 Mark


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

Re: svn commit: r1605890 - in /tomcat/trunk/java/org/apache/tomcat/websocket: LocalStrings.properties TransformationFactory.java

[Martin Grigorov]

Hi Mark,


On Thu, Jun 26, 2014 at 10:44 PM, ma...@apache.org wrote:

 Author: markt
 Date: Thu Jun 26 19:44:54 2014
 New Revision: 1605890

 URL: http://svn.apache.org/r1605890
 Log:
 Fix an i18n TODO

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/LocalStrings.properties

 tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/LocalStrings.properties
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/LocalStrings.properties?rev=1605890r1=1605889r2=1605890view=diff

 ==
 --- tomcat/trunk/java/org/apache/tomcat/websocket/LocalStrings.properties
 (original)
 +++ tomcat/trunk/java/org/apache/tomcat/websocket/LocalStrings.properties
 Thu Jun 26 19:44:54 2014
 @@ -33,6 +33,8 @@ perMessageDeflate.duplicateParameter=Dup
  perMessageDeflate.invalidWindowSize=An invalid windows of [{1}] size was
 specified for [{0}]. Valid values are whole numbers from 8 to 15 inclusive.
  perMessageDeflate.unknownParameter=An unknown extension parameter [{0}]
 was defined

 +transformerFactory.unsupportedExtension=The extension [{0}] is not
 supported
 +
  util.notToken=An illegal extension parameter was specified with name
 [{0}] and value [{1}]
  util.invalidMessageHandler=The message handler provided does not have an
 onMessage(Object) method
  util.invalidType=Unable to coerce value [{0}] to type [{1}]. That type is
 not supported.

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java?rev=1605890r1=1605889r2=1605890view=diff

 ==
 ---
 tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java
 (original)
 +++
 tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java
 Thu Jun 26 19:44:54 2014
 @@ -20,8 +20,12 @@ import java.util.List;

  import javax.websocket.Extension;

 +import org.apache.tomcat.util.res.StringManager;
 +
  public class TransformationFactory {

 +private static final StringManager sm =
 StringManager.getManager(Constants.PACKAGE_NAME);
 +
  private static final TransformationFactory factory = new
 TransformationFactory();

  private TransformationFactory() {
 @@ -36,7 +40,6 @@ public class TransformationFactory {
  if (PerMessageDeflate.NAME.equals(name)) {
  return PerMessageDeflate.negotiate(preferences);
  }
 -// TODO i18n
 -throw new IllegalArgumentException(Unsupported extension);
 +throw new
 IllegalArgumentException(sm.getString(transformerFactory.unsupportedExtension));


[{0}] in
+transformerFactory.unsupportedExtension=The extension [{0}] is not
supported

suggests that there will be a replacement of the extension's name but I see
no String.format() or something similar in

+throw new
IllegalArgumentException(sm.getString(transformerFactory.unsupportedExtension));

 }
  }



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

Re: Too few fatal log ststements

[Martin Grigorov]

Hi,

On Mon, Aug 11, 2014 at 11:45 AM, Leon Rosenberg rosenberg.l...@gmail.com
wrote:

 maybe tomcat is just so robust, that nothing is fatal to it ;-)
 Leon


 On Mon, Aug 11, 2014 at 11:41 AM, sangeeta lal sangeeta.6...@gmail.com
 wrote:

  Hi Mark,
 
  Actually I have data for other log levels also. Debug =600 statements,
  error=400 statements, trace =90 statements etc.
 
  I am just curious, what could be the possible reason for having such few
  fatal statements. Can you give your opinion about this?


It seems you don't know what is the purpose of the log messages.
Fatal log level is used to indicate that there is a such a problem that
Tomcat cannot even start, e.g. some configuration issue.
Error level is used to indicate that there is a serious problem but Tomcat
can still work, e.g. some request failed somehow and all its resources will
be released, but Tomcat will continue serving more requests.
Debug and  Trace log levels are used for debugging. Usually they are not
enabled.


  
  Thanks! for reply.
 
 
  On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas ma...@apache.org wrote:
 
   On 11/08/2014 09:14, sangeeta lal wrote:
Hello Team,
   
   
I am sangeeta PhD scholar and Researcher working in the are of mining
software repositories.
   
Currently I am working on the *tomcat *platform. I am parsing the
 code
  of
tomcat (version 8)  and I discovered that there are only *10-11
   log.fatal
statement.*
   
I am just curious,  is it normal?
  
   That depends on your definition of normal.
  
and why is it so?
  
   Because that this how the Tomcat developers wrote the code.
  
Why there so few*log.fatal *statements?
  
   That questions assumes that Tomcat has fewer than the normal number of
   fatal log statements. As per my comment above, that depends on how
   normal is defined.
  
   Mark
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: dev-h...@tomcat.apache.org
  
  
 
 
  --
  Regards...
  Sangeeta
  Assistant Professor
  CSE Department @JIIT Noida
 

Re: git (yet again)

[Martin Grigorov]

Hi all,

On Sep 3, 2014 12:42 PM, Rainer Jung rainer.j...@kippdata.de 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?

 I'm leaning towards A myself.


 It looks like the discussion in january and the answers on this thread
show a majority for a move to git (not necessarily a consensus). I'd prefer
if we knew more about the details before finally voting on it, so B, and
I expect the time and work needed for that will not be wasted.

 I agree with others about items for a). Things that come into my mind:

 - one repos or multiple: Actually I dont't care about that question per
se, but more about the implications that will have (which I'm not sure
about). For instance, does it matter in git, that we would only have one
master (trunk), and the heads of the versions only as branches?

I am not sure how merging/cherry-pucking would work in separate repos.
As I said before I use git-new-workdir to have different local working
folders for branches of the same repo. This way I can have several branches
opened simultaneously in the IDE. Konstantin noted that this doesn't work
on Windows at the moment.


 - backport workflow
   I find trunk first, then version branches slightly better, but it
might depend on details unknown to me. Concerning cherry-pick this seems
to break the link between the original (e.g. master) commit and the commit
on the branch. Not a good thing IMHO.

Each cherry picked commit has the sha id of the original in its message
automatically. Additionally with git cherry you can check the branches a
commit has been picked.


 - use of temporary feature or backport branches: delete after merge?

Branching in Git is cheap. You can keep them if you want. Feature branches
are usually deleted after merge.


 - handling pull requests (tracking patch authors)

Apache committers don't have write access to GitHub mirrors. I have a Shell
script to merge Pull Requests and preserve the authorship.
The PR is automatically closed once the code is sync-ed as Mark already
said.

Commenting on code in a feature branch at GitHub UI doesn't notify the
author nor the team. Not ideal!


 - move tomcat-connectors as well, same repos? No preference here.

 - move old branches to simplify code archeology? I'd prefer so.

Most svn2git scripts support this.


 - sources for the web site remain in svn?

This is the case for Apache Wicket. I'd like to change it to Git too.


 - is there (in principle) a way back from git to svn, or is this a one
way street? No details needed, but if the project finds out the move was a
bad thing, are we confident, that we can get back?

 - Konstantin provided some reasons against git during the last three
discussions. Some of the might be mitigated by now (e.g. svn externals vs.
git submodules? Version diffs), some of them might not (Buildbot and
Jenkins integration, missing EU mirror).

We use BuildBot without problems.

For me US Git is much faster than EU SVN. I live in Bulgaria.


 I guess experienced git users (like Martin Grigorov) could answer most
questions easily, but I don't have the experience with git allowing me to
understand implications of decisions.

 Regards,

 Rainer


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

Re: git (yet again)

[Martin Grigorov]

On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig bode...@apache.org 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.

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.




 Stefan

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

Re: git (yet again)

[Martin Grigorov]

On Thu, Sep 4, 2014 at 12:46 AM, sebb seb...@gmail.com wrote:

 On 3 September 2014 16:10, Martin Grigorov mgrigo...@apache.org wrote:
  On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig bode...@apache.org
 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.


I also noticed those commits.
I'll ask Tony (tonypc) how this works for them.
I know Joe (joes) was strongly against using non-ASF services for Apache
needs. Apparently this changed!
I see Apache Spark also makes a heavy use of GitHub but I don't know the
details again.
Joe (and the whole Infra team) was against using Atlassian Stash (
https://www.atlassian.com/software/stash) on ASF hardware. ASF already uses
several other Atlassian product like JIRA, Confluence, HipChat, FishEye.
Stash is the application behind bitbucket.org. I find it even better than
GitHub user experience.



  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: 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

[Martin Grigorov]

Hi,

On Wed, Sep 3, 2014 at 8:37 PM, ma...@apache.org wrote:

 Author: markt
 Date: Wed Sep  3 17:37:51 2014
 New Revision: 1622302

 URL: http://svn.apache.org/r1622302
 Log:
 Correctly handle multiple accept-language headers rather than just using
 the first header to determine the user's preferred Locale.

 Modified:
 tomcat/tc7.0.x/trunk/   (props changed)
 tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java

 tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestRequest.java

 tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TesterRequest.java
 tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

 Propchange: tomcat/tc7.0.x/trunk/

 --
   Merged /tomcat/trunk:r1618112

 Modified:
 tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java
 URL:
 http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java?rev=1622302r1=1622301r2=1622302view=diff

 ==
 --- tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java
 (original)
 +++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java
 Wed Sep  3 17:37:51 2014
 @@ -3226,26 +3226,33 @@ public class Request

  localesParsed = true;

 +// Store the accumulated languages that have been requested in
 +// a local collection, sorted by the quality value (so we can
 +// add Locales in descending order).  The values will be
 ArrayLists
 +// containing the corresponding Locales to be added
 +TreeMapDouble, ArrayListLocale locales = new TreeMapDouble,
 ArrayListLocale();
 +
  EnumerationString values = getHeaders(accept-language);

  while (values.hasMoreElements()) {
  String value = values.nextElement();
 -parseLocalesHeader(value);
 +parseLocalesHeader(value, locales);
  }

 +// Process the quality values in highest-lowest order (due to
 +// negating the Double value when creating the key)
 +for (ArrayListLocale list : locales.values()) {
 +for (Locale locale : list) {
 +addLocale(locale);
 +}
 +}
  }


  /**
   * Parse accept-language header value.
   */
 -protected void parseLocalesHeader(String value) {
 -
 -// Store the accumulated languages that have been requested in
 -// a local collection, sorted by the quality value (so we can
 -// add Locales in descending order).  The values will be
 ArrayLists
 -// containing the corresponding Locales to be added
 -TreeMapDouble, ArrayListLocale locales = new TreeMapDouble,
 ArrayListLocale();
 +protected void parseLocalesHeader(String value, TreeMapDouble,
 ArrayListLocale locales) {

  // Preprocess the value to remove all whitespace
  int white = value.indexOf(' ');
 @@ -3340,17 +3347,7 @@ public class Request
  locales.put(key, values);
  }
  values.add(locale);
 -
 -}
 -
 -// Process the quality values in highest-lowest order (due to
 -// negating the Double value when creating the key)
 -for (ArrayListLocale list : locales.values()) {
 -for (Locale locale : list) {
 -addLocale(locale);
 -}
  }
 -
  }



 Modified:
 tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestRequest.java
 URL:
 http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestRequest.java?rev=1622302r1=1622301r2=1622302view=diff

 ==
 ---
 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 ?!


  writer.flush();

  writer.append(\r\n);
 @@ -687,7 +689,7 @@ public class TestRequest extends TomcatB
   

Re: svn commit: r1622434 - /tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java

[Martin Grigorov]

On Thu, Sep 4, 2014 at 12:42 PM, ma...@apache.org wrote:

 Author: markt
 Date: Thu Sep  4 09:42:04 2014
 New Revision: 1622434

 URL: http://svn.apache.org/r1622434
 Log:
 Fix corrupted characters.

 Modified:
 tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java

 Modified: tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?rev=1622434r1=1622433r2=1622434view=diff

 ==
 --- tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java
 (original)
 +++ tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java Thu
 Sep  4 09:42:04 2014
 @@ -661,7 +661,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);


this is what I call wtf-8 encoding :-)
the important thing is the tests to work fine


  writer.flush();

  writer.append(\r\n);
 @@ -682,7 +682,7 @@ public class TestRequest extends TomcatB
  while ((line = reader.readLine()) != null) {
  response.add(line);
  }
 -assertTrue(response.contains(Part ��));
 +assertTrue(response.contains(Part äö));
  }
  } else {
  fail(OK status was expected:  + status);



 -
 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.14

[Martin Grigorov]

[ X ] Stable - go ahead and release as 8.0.14

Tested Apache Wicket impl for JSR 356 with the tar.gz bundle.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Sep 24, 2014 at 11:07 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.14 release is now available for voting.

 The main changes since 8.0.12 are:
 - Windows service runner, Windows service manager and Windows installer
   are digitally signed with the new ASF code signing service
 - Implement Java WebSocket 1.1
 - Improvements to start times by reducing overhead of annotation
   scanning
 - Optional RFC6265 compliant cookie parser (Note that this is
   experimental and that the configuration options for this will change
   in the next release)

 There is also the usual collection of bug fixes, new features and
 performance improvements. For full details, see the changelog:
 http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.14/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1022/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_14/

 The proposed 8.0.14 release is:
 [ ] Broken - do not release
 [ ] Stable - go ahead and release as 8.0.14

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

Re: svn commit: r1628984 - in /tomcat/trunk/webapps/docs: changelog.xml config/engine.xml

[Martin Grigorov]

Hi,

On Thu, Oct 2, 2014 at 4:36 PM, schu...@apache.org wrote:

 Author: schultz
 Date: Thu Oct  2 14:36:27 2014
 New Revision: 1628984

 URL: http://svn.apache.org/r1628984
 Log:
 Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57049
 Clarified that jvmRoute can be set using Engine.jvmRoute or a system
 property.

 Modified:
 tomcat/trunk/webapps/docs/changelog.xml
 tomcat/trunk/webapps/docs/config/engine.xml

 Modified: tomcat/trunk/webapps/docs/changelog.xml
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1628984r1=1628983r2=1628984view=diff

 ==
 --- tomcat/trunk/webapps/docs/changelog.xml (original)
 +++ tomcat/trunk/webapps/docs/changelog.xml Thu Oct  2 14:36:27 2014
 @@ -109,7 +109,12 @@
  Correct documentation for
 codeServerCookie.ALLOW_NAME_ONLY/code
  system property. (kkolinko)
/fix
 -/changelog
 +  fix
 +bug57049/bug: Clarified that codejvmRoute/code can be set
 in
 +codelt;Enginegt;/code's codejvmRoute/code or in a system
 +property. (schultz)
 +  /fix
 +  /changelog
/subsection
  /section
  section name=Tomcat 8.0.14 (markt) rtext=2014-09-29

 Modified: tomcat/trunk/webapps/docs/config/engine.xml
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/engine.xml?rev=1628984r1=1628983r2=1628984view=diff

 ==
 --- tomcat/trunk/webapps/docs/config/engine.xml (original)
 +++ tomcat/trunk/webapps/docs/config/engine.xml Thu Oct  2 14:36:27 2014
 @@ -93,6 +93,12 @@
  the generated session identifier, therefore allowing the front end
  proxy to always forward a particular session to the same Tomcat
  instance./p
 +p
 +Note that the codejvmRoute/code can also be set using the
 +codejvmRoute/code system property. The
 codejvmRoute/code
 +set in an codelt;Enginegt;/code attribute will override
 +any codejvmRoute/code system property.
 +/p


This sounds counter intuitive.
Usually manually provided settings, like system properties, have higher
priority than ones provided in configuration files.


/attribute

attribute name=name required=true



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

Re: svn commit: r1628984 - in /tomcat/trunk/webapps/docs: changelog.xml config/engine.xml

[Martin Grigorov]

On Thu, Oct 2, 2014 at 9:14 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 Mark,

 On 10/2/14 10:54 AM, Mark Thomas wrote:
  On 02/10/2014 15:41, Martin Grigorov wrote:
  Hi,
 
  On Thu, Oct 2, 2014 at 4:36 PM, schu...@apache.org wrote:
 
  Author: schultz
  Date: Thu Oct  2 14:36:27 2014
  New Revision: 1628984
 
  URL: http://svn.apache.org/r1628984
  Log:
  Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57049
  Clarified that jvmRoute can be set using Engine.jvmRoute or a system
  property.
 
  Modified:
  tomcat/trunk/webapps/docs/changelog.xml
  tomcat/trunk/webapps/docs/config/engine.xml
 
  Modified: tomcat/trunk/webapps/docs/changelog.xml
  URL:
 
 http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1628984r1=1628983r2=1628984view=diff
 
 
 ==
  --- tomcat/trunk/webapps/docs/changelog.xml (original)
  +++ tomcat/trunk/webapps/docs/changelog.xml Thu Oct  2 14:36:27 2014
  @@ -109,7 +109,12 @@
   Correct documentation for
  codeServerCookie.ALLOW_NAME_ONLY/code
   system property. (kkolinko)
 /fix
  -/changelog
  +  fix
  +bug57049/bug: Clarified that codejvmRoute/code can be
 set
  in
  +codelt;Enginegt;/code's codejvmRoute/code or in a
 system
  +property. (schultz)
  +  /fix
  +  /changelog
 /subsection
   /section
   section name=Tomcat 8.0.14 (markt) rtext=2014-09-29
 
  Modified: tomcat/trunk/webapps/docs/config/engine.xml
  URL:
 
 http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/engine.xml?rev=1628984r1=1628983r2=1628984view=diff
 
 
 ==
  --- tomcat/trunk/webapps/docs/config/engine.xml (original)
  +++ tomcat/trunk/webapps/docs/config/engine.xml Thu Oct  2 14:36:27
 2014
  @@ -93,6 +93,12 @@
   the generated session identifier, therefore allowing the
 front end
   proxy to always forward a particular session to the same
 Tomcat
   instance./p
  +p
  +Note that the codejvmRoute/code can also be set using
 the
  +codejvmRoute/code system property. The
  codejvmRoute/code
  +set in an codelt;Enginegt;/code attribute will
 override
  +any codejvmRoute/code system property.
  +/p
 
 
  This sounds counter intuitive.
  Usually manually provided settings, like system properties, have higher
  priority than ones provided in configuration files.
 
  Not in Tomcat they don't.
 
  System properties are often introduced to provide configuration options
  where there isn't an obvious / easy element on which to place a
  configuration attribute.
 
  At some point in the future, things are refactored making it possible to
  have per element configuration. At this point the system property
  becomes the default and the element level always overrides it.
 
  The ideal solution would be to never use system properties in the first
  place.

 +1

 Also, I disagree with Martin's initial assertion. Instead, the more
 fine-grained configuration should override the more coarse-grained
 configuration.


Just saying how the other 99% of the software (I have worked with!) works.
Just put yourself in DevOps shoes - it is much easier for them to use
CATALINA_OPTS to tune something for some specific case than patch a .xml
file.

But since this is the Tomcat's convention then everything is fine.



 -chris

Re: svn commit: r1630065 - in /tomcat/trunk: java/org/apache/tomcat/websocket/ java/org/apache/tomcat/websocket/server/ test/org/apache/tomcat/websocket/ webapps/docs/

[Martin Grigorov]

Hi,

On Wed, Oct 8, 2014 at 12:38 PM, ma...@apache.org wrote:

 Author: markt
 Date: Wed Oct  8 10:38:33 2014
 New Revision: 1630065

 URL: http://svn.apache.org/r1630065
 Log:
 Extend support for permessage-deflate to the WebSocket client
 implementation.

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java
 tomcat/trunk/java/org/apache/tomcat/websocket/PerMessageDeflate.java

 tomcat/trunk/java/org/apache/tomcat/websocket/TransformationFactory.java
 tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameClient.java
 tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
 tomcat/trunk/java/org/apache/tomcat/websocket/server/UpgradeUtil.java

 tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
 tomcat/trunk/webapps/docs/changelog.xml

 Modified: tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java?rev=1630065r1=1630064r2=1630065view=diff

 ==
 --- tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java (original)
 +++ tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java Wed Oct
 8 10:38:33 2014
 @@ -61,6 +61,8 @@ public class Constants {
  WS_PROTOCOL_HEADER_NAME.toLowerCase(Locale.ENGLISH);
  public static final String WS_EXTENSIONS_HEADER_NAME =
  Sec-WebSocket-Extensions;
 +public static final Object WS_EXTENSIONS_HEADER_NAME_LOWER =


Why the type is Object ?
It is enough for the single use later in Map#get() but someone else may
need it as a String later ?


 +WS_EXTENSIONS_HEADER_NAME.toLowerCase(Locale.ENGLISH);

  public static final boolean STRICT_SPEC_COMPLIANCE =
  Boolean.getBoolean(

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/PerMessageDeflate.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/PerMessageDeflate.java?rev=1630065r1=1630064r2=1630065view=diff

 ==
 --- tomcat/trunk/java/org/apache/tomcat/websocket/PerMessageDeflate.java
 (original)
 +++ tomcat/trunk/java/org/apache/tomcat/websocket/PerMessageDeflate.java
 Wed Oct  8 10:38:33 2014
 @@ -48,6 +48,7 @@ public class PerMessageDeflate implement
  private final int serverMaxWindowBits;
  private final boolean clientContextTakeover;
  private final int clientMaxWindowBits;
 +private final boolean isServer;
  private final Inflater inflater = new Inflater(true);
  private final ByteBuffer readBuffer =
 ByteBuffer.allocate(Constants.DEFAULT_BUFFER_SIZE);
  private final Deflater deflater = new
 Deflater(Deflater.DEFAULT_COMPRESSION, true);
 @@ -58,8 +59,8 @@ public class PerMessageDeflate implement
  private volatile ByteBuffer writeBuffer =
 ByteBuffer.allocate(Constants.DEFAULT_BUFFER_SIZE);
  private volatile boolean firstCompressedFrameWritten = false;

 -static PerMessageDeflate negotiate(ListListParameter preferences)
 {
 -// Accept the first preference that the server is able to support
 +static PerMessageDeflate negotiate(ListListParameter preferences,
 boolean isServer) {
 +// Accept the first preference that the endpoint is able to
 support
  for (ListParameter preference : preferences) {
  boolean ok = true;
  boolean serverContextTakeover = true;
 @@ -142,7 +143,7 @@ public class PerMessageDeflate implement
  }
  if (ok) {
  return new PerMessageDeflate(serverContextTakeover,
 serverMaxWindowBits,
 -clientContextTakeover, clientMaxWindowBits);
 +clientContextTakeover, clientMaxWindowBits,
 isServer);
  }
  }
  // Failed to negotiate agreeable terms
 @@ -151,11 +152,12 @@ public class PerMessageDeflate implement


  private PerMessageDeflate(boolean serverContextTakeover, int
 serverMaxWindowBits,
 -boolean clientContextTakeover, int clientMaxWindowBits) {
 +boolean clientContextTakeover, int clientMaxWindowBits,
 boolean isServer) {
  this.serverContextTakeover = serverContextTakeover;
  this.serverMaxWindowBits = serverMaxWindowBits;
  this.clientContextTakeover = clientContextTakeover;
  this.clientMaxWindowBits = clientMaxWindowBits;
 +this.isServer = isServer;
  }


 @@ -211,7 +213,8 @@ public class PerMessageDeflate implement
  }
  }
  } else if (written == 0) {
 -if (fin  !serverContextTakeover) {
 +if (fin  (isServer  !serverContextTakeover ||
 +!isServer  !clientContextTakeover)) {
  inflater.reset();
  }
  return 

Re: svn commit: r1630065 - in /tomcat/trunk: java/org/apache/tomcat/websocket/ java/org/apache/tomcat/websocket/server/ test/org/apache/tomcat/websocket/ webapps/docs/

[Martin Grigorov]

On Wed, Oct 8, 2014 at 1:02 PM, Mark Thomas ma...@apache.org wrote:

 On 08/10/2014 11:41, Martin Grigorov wrote:

 It really helps if you are going to comment on a small part of a large
 commit if you trim the irrelevant parts of the original in your reply.


I'll try to remember for the next time.
In my mail client it is a matter of a single click to see what is before or
after such inline comment, so I thought it is easy for others too.



  Modified: tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java
  URL:
 
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java?rev=1630065r1=1630064r2=1630065view=diff
 
 
 ==
  --- tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java
 (original)
  +++ tomcat/trunk/java/org/apache/tomcat/websocket/Constants.java Wed Oct
  8 10:38:33 2014
  @@ -61,6 +61,8 @@ public class Constants {
   WS_PROTOCOL_HEADER_NAME.toLowerCase(Locale.ENGLISH);
   public static final String WS_EXTENSIONS_HEADER_NAME =
   Sec-WebSocket-Extensions;
  +public static final Object WS_EXTENSIONS_HEADER_NAME_LOWER =
 
 
  Why the type is Object ?

 Because I got the IDE to generate the code and didn't notice it created
 a String. I'll get that fixed.

 Mark


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

Re: Summary: Migration from svn to git

[Martin Grigorov]

Hi,

On Thu, Oct 16, 2014 at 9:38 PM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 Just several technical notes,



 If anyone wants to comment on Github, I think that it is already
 possible. I think that it works and the messages are forwarded to the
 dev list.


Unfortunately this is not true.
At the moment notifications for comments on a commit in GitHub mirror are
being sent only to the committer of this particular commit.



 Best regards,
 Konstantin Kolinko

 -
 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.15

[Martin Grigorov]

[X] Stable - go ahead and release as 8.0.15

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Nov 4, 2014 at 3:54 PM, Rémy Maucherat r...@apache.org wrote:

 2014-11-03 10:51 GMT+01:00 Mark Thomas ma...@apache.org:

  The proposed 8.0.15 release is:
  [ ] Broken - do not release
  [X] Stable - go ahead and release as 8.0.15
 
  Rémy

Re: svn commit: r1642307 - in /tomcat/trunk: java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java test/org/apache/tomcat/websocket/TestCaseInsensitiveKeyMap.java

[Martin Grigorov]

Hi,

Performance wise isn't it better to transform the String key to lowerCase
at Key construction time and later use it in equals/hashCode ?
Now the lower-ification would happen for most Map operation.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Nov 28, 2014 at 3:53 PM, ma...@apache.org wrote:

 Author: markt
 Date: Fri Nov 28 14:53:15 2014
 New Revision: 1642307

 URL: http://svn.apache.org/r1642307
 Log:
 Add a map that supports case insensitive keys. E.g. for use with HTTP
 headers.

 Added:

 tomcat/trunk/java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java
  (with props)

 tomcat/trunk/test/org/apache/tomcat/websocket/TestCaseInsensitiveKeyMap.java
  (with props)

 Added:
 tomcat/trunk/java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java?rev=1642307view=auto

 ==
 ---
 tomcat/trunk/java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java
 (added)
 +++
 tomcat/trunk/java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java
 Fri Nov 28 14:53:15 2014
 @@ -0,0 +1,206 @@
 +/*
 + * 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 BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
 implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +package org.apache.tomcat.websocket;
 +
 +import java.util.AbstractMap;
 +import java.util.AbstractSet;
 +import java.util.HashMap;
 +import java.util.Iterator;
 +import java.util.Locale;
 +import java.util.Map;
 +import java.util.Set;
 +
 +/**
 + * A Map implementation that uses case-insensitive (using {@link
 Locale#ENGLISH}
 + * strings as keys.
 + * p
 + * This implementation is not thread-safe.
 + *
 + * @param V Type of values placed in this Map.
 + */
 +public class CaseInsensitiveKeyMapV extends AbstractMapString,V {
 +
 +private final MapKey,V map = new HashMap();
 +
 +
 +@Override
 +public V get(Object key) {
 +return map.get(Key.getInstance(key));
 +}
 +
 +
 +@Override
 +public V put(String key, V value) {
 +return map.put(Key.getInstance(key), value);
 +}
 +
 +
 +/**
 + * {@inheritDoc}
 + * p
 + * bUse this method with caution/b. If the input Map contains
 duplicate
 + * keys when the keys are compared in a case insensitive manner then
 some
 + * values will be lost when inserting via this method.
 + */
 +@Override
 +public void putAll(Map? extends String, ? extends V m) {
 +super.putAll(m);
 +}
 +
 +
 +@Override
 +public boolean containsKey(Object key) {
 +return map.containsKey(Key.getInstance(key));
 +}
 +
 +
 +@Override
 +public V remove(Object key) {
 +return map.remove(Key.getInstance(key));
 +}
 +
 +
 +@Override
 +public SetEntryString, V entrySet() {
 +return new EntrySet(map.entrySet());
 +}
 +
 +
 +private static class EntrySetV extends AbstractSetEntryString,V
 {
 +
 +private final SetEntryKey,V entrySet;
 +
 +public EntrySet(SetMap.EntryKey,V entrySet) {
 +this.entrySet = entrySet;
 +}
 +
 +@Override
 +public IteratorEntryString,V iterator() {
 +return new EntryIterator(entrySet.iterator());
 +}
 +
 +@Override
 +public int size() {
 +return entrySet.size();
 +}
 +}
 +
 +
 +private static class EntryIteratorV implements
 IteratorEntryString,V {
 +
 +private final IteratorEntryKey,V iterator;
 +
 +public EntryIterator(IteratorEntryKey,V iterator) {
 +this.iterator = iterator;
 +}
 +
 +@Override
 +public boolean hasNext() {
 +return iterator.hasNext();
 +}
 +
 +@Override
 +public EntryString,V next() {
 +EntryKey,V entry = iterator.next();
 +return new EntryImpl(entry.getKey().getKey(),
 entry.getValue());
 +}
 +
 +@Override
 +public void remove() {
 +iterator.remove();
 +}
 +}
 +
 +
 +private static class EntryImplV implements EntryString,V {
 +
 +private final String key;
 +private final V value

Re: svn commit: r1642307 - in /tomcat/trunk: java/org/apache/tomcat/websocket/CaseInsensitiveKeyMap.java test/org/apache/tomcat/websocket/TestCaseInsensitiveKeyMap.java

[Martin Grigorov]

Hi Remy,

On Fri, Nov 28, 2014 at 4:13 PM, Rémy Maucherat r...@apache.org wrote:

 2014-11-28 16:05 GMT+01:00 Martin Grigorov mgrigo...@apache.org:

  Hi,
 
  Performance wise isn't it better to transform the String key to lowerCase
  at Key construction time and later use it in equals/hashCode ?
  Now the lower-ification would happen for most Map operation.
 



The current is not spec compliant since headers.get(myHeader.toUpperCase())
 is supposed to work.


I'm not sure I follow you.
Assuming 'headers' is an instance of CaseInsensitiveKeyMap then:
- headers.get(BLAH) will delegate to innerMap.get(key{blah})   //
Perl-ish syntax to express what I mean
- headers.get(bLAh) will also delegate to innerMap.get(key{blah})

so everything should be OK


 Rémy

Re: Moderators wanted

[Martin Grigorov]

Hi,

On Mon, Dec 1, 2014 at 4:56 PM, Mark Thomas ma...@apache.org wrote:

 Hi,

 I've been reviewing the moderators for our various lists and if I ignore
 the no longer active ones we are below the 3 moderators the ASF likes to
 have on a number of lists.

 Therefore, can I have some volunteers for the following lists:

 users@tomcat.a.o- Need two moderators
 dev@tomct.a.o   - Need one moderator
 announce@tomcat.a.o - Need one moderator
 private@tomcat.a.o  - Need one moderator
 security@tomcat.a.o - Need one moderator

 You can volunteer for more than one :)

 There is typically less than one message a week that requires moderator
 input (security@ is a little higher) which is usually explaining to
 folks how to unsubscribe themselves or doing it for them if they are
 unable to.

 Note all of our public lists automatically reject mails from
 unsubscribed users so there is no moderator traffic from that source.



 Generally, you need to be a committer to moderate a list.
 To moderate the private and security list you need to be a PMC member.


As an ASF Member I already have access to those lists. I'd volunteer for
private@ and security@ if this is OK with you.



 Cheers,

 Mark

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

Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Martin Grigorov]

Hi,

On Mon, Dec 1, 2014 at 6:55 PM, r...@apache.org wrote:

 Author: remm
 Date: Mon Dec  1 17:55:07 2014
 New Revision: 1642721

 URL: http://svn.apache.org/r1642721
 Log:
 Try a better origin header.

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

 Modified:
 tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1642721r1=1642720r2=1642721view=diff

 ==
 ---
 tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
 (original)
 +++
 tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Mon
 Dec  1 17:55:07 2014
 @@ -224,8 +224,6 @@ public class WsWebSocketContainer
  clientEndpointConfiguration.getConfigurator().
  beforeRequest(reqHeaders);

 -ByteBuffer request = createRequest(path, reqHeaders);
 -
  SocketAddress sa;
  if (port == -1) {
  if (ws.equalsIgnoreCase(scheme)) {
 @@ -244,6 +242,20 @@ public class WsWebSocketContainer
  sa = new InetSocketAddress(host, port);
  }

 +// Origin header
 +if (!reqHeaders.containsKey(Constants.ORIGIN_HEADER_NAME)) {




 +ListString originValues = new ArrayList(1);
 +StringBuffer originValue = new StringBuffer();


Prefer StringBuilder than StringBuffer for local variables to avoid
unnecessary synchronizations.


 +
 originValue.append(path.getScheme()).append(://).append(path.getHost());
 +if (port != -1) {
 +originValue.append(':').append(port);
 +}
 +originValues.add(originValue.toString());
 +reqHeaders.put(Constants.ORIGIN_HEADER_NAME, originValues);
 +}
 +
 +ByteBuffer request = createRequest(path, reqHeaders);
 +
  AsynchronousSocketChannel socketChannel;
  try {
  socketChannel =
 AsynchronousSocketChannel.open(getAsynchronousChannelGroup());
 @@ -476,11 +488,6 @@ public class WsWebSocketContainer
  generateExtensionHeaders(extensions));
  }

 -// Origin header
 -ListString originValues = new ArrayList(1);
 -originValues.add(path.toString());
 -headers.put(Constants.ORIGIN_HEADER_NAME, originValues);
 -
  return headers;
  }




 -
 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.18

[Martin Grigorov]

On Fri, Jan 23, 2015 at 3:09 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.18 release is now available for voting.

 The main changes since 8.0.17 are:
 - Fix a regression that resulted in truncated responses for
   forwarded responses larger than the output buffer

 There is also the usual collection of bug fixes, new features and
 performance improvements. For full details, see the changelog:

 http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.18/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1030/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_18/

 The proposed 8.0.18 release is:
 [ ] Broken - do not release
 [ X ] Stable - go ahead and release as 8.0.18


Tested Apache Wicket integration for JSR356.



 -
 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.17

[Martin Grigorov]

On Fri, Jan 9, 2015 at 7:26 PM, Mark Thomas ma...@apache.org wrote:

 The proposed Apache Tomcat 8.0.17 release is now available for voting.

 The changes since 8.0.16 are:
 - Fix a RequestListener regression
 - Fix a bug in NIO2 with sending 100-Continue responses

 The main changes since 8.0.15 are:
 - Correct a regression in annotation scanning introduced in 8.0.15
 - The RemoteAddrValve and RemoteHostValve can now optionally include
   the port when filtering along with a new option to trigger
   authentication rather than denying access
 - Various edge cases fixes in WebSocket

 There is also a large collection of bug fixes, new features and
 performance improvements. For full details, see the changelog:

 http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.17/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-1029/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_17/

 The proposed 8.0.17 release is:
 [ ] Broken - do not release
 [ ] Stable - go ahead and release as 8.0.17


[ X ] Stable - go ahead and release as 8.0.17

Tested Wicket integration with Tomcat's JSR356 impl.





 -
 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.21

[Martin Grigorov]

 The proposed 8.0.21 release is:
 [ ] Broken - do not release
 [ X ] Stable - go ahead and release as 8.0.21




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

Re: svn commit: r1678210 - /tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java

[Martin Grigorov]

You can remove 'public' too.

On Thu, May 7, 2015 at 4:54 PM, r...@apache.org wrote:

 Author: remm
 Date: Thu May  7 13:54:58 2015
 New Revision: 1678210

 URL: http://svn.apache.org/r1678210
 Log:
 This was at some point an abstract class, so cleanup.

 Modified:
 tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java

 Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java?rev=1678210r1=1678209r2=1678210view=diff

 ==
 --- tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java (original)
 +++ tomcat/trunk/java/org/apache/tomcat/util/net/SSLContext.java Thu May
 7 13:54:58 2015
 @@ -34,15 +34,15 @@ import javax.net.ssl.TrustManager;
   */
  public interface SSLContext {

 -public abstract void init(KeyManager[] kms, TrustManager[] tms,
 +public void init(KeyManager[] kms, TrustManager[] tms,
  SecureRandom sr) throws KeyManagementException;

 -public abstract SSLSessionContext getServerSessionContext();
 +public SSLSessionContext getServerSessionContext();

 -public abstract SSLEngine createSSLEngine();
 +public SSLEngine createSSLEngine();

 -public abstract SSLServerSocketFactory getServerSocketFactory();
 +public SSLServerSocketFactory getServerSocketFactory();

 -public abstract SSLParameters getSupportedSSLParameters();
 +public SSLParameters getSupportedSSLParameters();

  }



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

Re: svn commit: r1678339 - in /tomcat/trunk: conf/ java/org/apache/catalina/filters/ webapps/docs/config/

[Martin Grigorov]

Hi Mark,

On Fri, May 8, 2015 at 3:32 PM, ma...@apache.org wrote:

 Author: markt
 Date: Fri May  8 12:32:11 2015
 New Revision: 1678339

 URL: http://svn.apache.org/r1678339
 Log:
 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=54618
 Add the HSTS header by default as recommended by RFC 7527

 Added:

 tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
  (with props)
 Modified:
 tomcat/trunk/conf/web.xml
 tomcat/trunk/java/org/apache/catalina/filters/Constants.java
 tomcat/trunk/java/org/apache/catalina/filters/CorsFilter.java
 tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java
 tomcat/trunk/java/org/apache/catalina/filters/LocalStrings.properties
 tomcat/trunk/webapps/docs/config/filter.xml

 Modified: tomcat/trunk/conf/web.xml
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/conf/web.xml?rev=1678339r1=1678338r2=1678339view=diff

 ==
 --- tomcat/trunk/conf/web.xml (original)
 +++ tomcat/trunk/conf/web.xml Fri May  8 12:32:11 2015
 @@ -395,6 +395,29 @@

!-- == Built In Filter Definitions
 = --

 +  !-- A filter that sets various security related HTTP Response
 headers.   --
 +  !-- This filter supports the following initialization parameters
--
 +  !-- (default values are in square brackets):
--
 +  !--
   --
 +  !--   hstsEnabled Should the HTTP Strict Transport Security
   --
 +  !--   (HSTS) header be added to the response? See
   --
 +  !--   RFC 6797 for more information on HSTS.
 [true]  --
 +  !--
   --
 +  !--   hstsMaxAgeSeconds   The max age value that should be used in
 the   --
 +  !--   HSTS header. Negative values will be
 treated   --
 +  !--   as zero. [0]
--
 +  !--
   --
 +  !--   hstsIncludeSubDomains
   --
 +  !--   Should the includeSubDomains parameter be
   --
 +  !--   included in the HSTS header.
--
 +  !--
   --
 +
 +filter
 +filter-namehttpHeaderSecurity/filter-name
 +
 filter-classorg.apache.catalina.filters.HttpHeaderSecurityFilter/filter-class
 +async-supportedtrue/async-supported
 +/filter
 +
!-- A filter that sets character encoding that is used to decode --
!-- parameters in a POST request --
  !--
 @@ -483,6 +506,13 @@

!--  Built In Filter Mappings
 == --

 +  !-- The mapping for the HTTP header security Filter --
 +filter-mapping
 +filter-namehttpHeaderSecurity/filter-name
 +url-pattern/*/url-pattern
 +dispatcherREQUEST/dispatcher
 +/filter-mapping
 +
!-- The mapping for the Set Character Encoding Filter --
  !--
  filter-mapping

 Modified: tomcat/trunk/java/org/apache/catalina/filters/Constants.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/Constants.java?rev=1678339r1=1678338r2=1678339view=diff

 ==
 --- tomcat/trunk/java/org/apache/catalina/filters/Constants.java (original)
 +++ tomcat/trunk/java/org/apache/catalina/filters/Constants.java Fri May
 8 12:32:11 2015
 @@ -25,8 +25,6 @@ package org.apache.catalina.filters;
   */
  public final class Constants {

 -public static final String Package = org.apache.catalina.filters;
 -
  public static final String CSRF_NONCE_SESSION_ATTR_NAME =
  org.apache.catalina.filters.CSRF_NONCE;


 Modified: tomcat/trunk/java/org/apache/catalina/filters/CorsFilter.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/CorsFilter.java?rev=1678339r1=1678338r2=1678339view=diff

 ==
 --- tomcat/trunk/java/org/apache/catalina/filters/CorsFilter.java
 (original)
 +++ tomcat/trunk/java/org/apache/catalina/filters/CorsFilter.java Fri May
 8 12:32:11 2015
 @@ -79,9 +79,7 @@ import org.apache.tomcat.util.res.String
  public final class CorsFilter implements Filter {

  private static final Log log = LogFactory.getLog(CorsFilter.class);
 -
 -private static final StringManager sm =
 -StringManager.getManager(Constants.Package);
 +private static final StringManager sm =
 StringManager.getManager(CorsFilter.class);


  /**

 Modified: tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java
 URL:
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?rev=1678339r1=1678338r2=1678339view=diff

 ==
 --- tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java
 (original)
 +++ tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java Fri May
 8 12:32:11 2015
 @@ -35,8 +35,7 @@ import org.apache.tomcat.util.res.String
   */
  public 

Re: svn commit: r1710734 - in /tomcat/site/trunk: docs/whoweare.html xdocs/whoweare.xml

[Martin Grigorov]

On Tue, Oct 27, 2015 at 2:59 PM, Konstantin Kolinko <knst.koli...@gmail.com>
wrote:

> This page is sorted by family name. So I expect yours to be between
> Gomez and  Hanik.
>

Fixed!
Thanks!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: [VOTE] Switch 6.0.x from RTC to CTR

[Martin Grigorov]

On Thu, Oct 29, 2015 at 12:42 AM, Mark Thomas  wrote:

> [ ] Continue to use RTC for 6.0.x
> [ X ] Switch 6.0.x to CTR
>

Re: [ANN] New committer: Ognjen Blagojevic

[Martin Grigorov]

Congratulations, Ognjen!

Re: [ANN] New committer: Martin Grigorov

[Martin Grigorov]

On Tue, Oct 27, 2015 at 3:00 PM, Konstantin Kolinko <knst.koli...@gmail.com>
wrote:

> 2015-10-26 17:35 GMT+03:00 Mark Thomas <ma...@apache.org>:
> > On behalf of the Tomcat committers I am pleased to announce that
> > Martin Grigorov (mgrigorov) has been voted in as a new Tomcat committer.
> >
>
> Welcome!
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Thank you everyone for the warm welcome!

Re: svn commit: r1713285 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/session/ java/org/apache/catalina/util/ test/org/apache/catalina/util/

[Martin Grigorov]

On Sun, Nov 8, 2015 at 9:05 PM,  wrote:

> public void testValidateWithJvmRouteWithPerid() {
>

I'd fix it myself with my new superpowers but I'm not sure whether there is
a typo in Period above or it is just my non-native English.

Re: Time for 9.0.0.RC1

[Martin Grigorov]

Hi,

On Thu, Nov 12, 2015 at 11:22 AM, Rémy Maucherat  wrote:

> 2015-11-12 9:26 GMT+01:00 Mark Thomas :
>
> > The announcements, download page, which version etc. will all make it
> > clear that this a work in progress.
> >
> > To make it clearer, I'll label the version M1 (milestone 1) rather than
> > RC1.
> >
> > This naming is new in Tomcat. It could be just M, with 9.0.0.M, then
> 9.0.1.M, etc. Or 9.0.0.Alpha. Or 9.0.0.M1 as you said, then 9.0.0.M2 until
> it gets to 9.0.0.Alpha/Beta/etc once the relevant specifications are out.
> Either way, it's 1+ years of alphas ahead.
>

I think the best for Tomcat would be: M1, M2, ..., 9.0.0, 9.0.1, ...
No need of alpha/beta/rc.
The current approach with releasing X.0.0 as non-stable works quite well!
More people start to test/use it earlier and report problems.


>
> Rémy
>

Re: Issues when building Tomcat 9 + tcnative

[Martin Grigorov]

On Sun, Nov 15, 2015 at 3:10 PM, Rainer Jung <rainer.j...@kippdata.de>
wrote:

> Am 15.11.2015 um 13:59 schrieb Martin Grigorov:
>
>> On Sun, Nov 15, 2015 at 1:35 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>
> To setup HTTP2 I follow the steps done by Konstantin Kolinko at
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58605
>> But here it fails with:
>>
>> 15-Nov-2015 13:40:37.505 INFO [main]
>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
>> based Apache Tomcat Native library 1.2.2 using APR version 1.5.2.
>> 15-Nov-2015 13:40:37.506 INFO [main]
>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
>> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
>> [true].
>> 15-Nov-2015 13:40:37.508 INFO [main]
>> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
>> successfully initialized (OpenSSL 1.0.2d 9 Jul 2015)
>> 15-Nov-2015 13:40:37.612 INFO [main]
>> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
>> ["http-apr-8080"]
>> 15-Nov-2015 13:40:37.619 INFO [main]
>> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
>> The ["https-apr-8443"] connector has been configured to support
>> negotiation
>> to [h2] via ALPN
>> 15-Nov-2015 13:40:37.620 INFO [main]
>> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
>> ["https-apr-8443"]
>> 15-Nov-2015 13:40:37.622 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
>> associated with ProtocolHandler ["https-apr-8443"]
>>   java.lang.Exception: Unable to load certificate key
>> /tmp/tc9/apache-tomcat-9.0.0.M1/conf/localhost-key.pem (error:0906D06C:PEM
>> routines:PEM_read_bio:no start line)
>>  at org.apache.tomcat.jni.SSLContext.setCertificate(Native Method)
>>
> ...
>
> The connector config is:
>> > protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150"
>> SSLEnabled="true" >
>>  > className="org.apache.coyote.http2.Http2Protocol"
>> />
>>  
>>  >   certificateFile="conf/localhost-cert.pem"
>>   type="RSA" />
>>  
>>  
>>
>> Ideas what could be wrong ?
>>
>
> Shooting from the hip:
>
> /tmp/tc9/apache-tomcat-9.0.0.M1/conf/localhost-key.pem (error:0906D06C:PEM
> routines:PEM_read_bio:no start line)
>
> sounds like the key file is not in valid PEM format, ie. it doesn't start
> with a
>
> -BEGIN RSA PRIVATE KEY-
>

Thanks, Rainer!
Somehow I messed up my Tomcat SVN working dir here and both
localhost-cert.pem and localhost-key.pem had the same content!
svn revert + copy again the -key.pem file to conf/ fixed the issue!


> line. Could you check, what the format of that file is?
>
> You can also use the openssl command from the same openssl installation
> that was used to build your tcnative and read the key file contents using
> it:
>
> /path/to/openssl rsa -inform pem -in
> /tmp/tc9/apache-tomcat-9.0.0.M1/conf/localhost-key.pem -text
>
> Finally, could it be, that your Tomcat runtime user can not read the file?
>
> Regards,
>
> Rainer



Overall everything looks good now!
Tomcat default apps run OK. Both Firefox and Google Chrome report H2.

It is just my own application that doesn't work in HTTP2 mode.
http://localhost:8080/wicket-websocket/ works fine
But https://localhost:8443/wicket-websocket/ redirects immediately with 302
to http://localhost/wicket-websocket/ (and Tomcat is not responsible for
port 80 here)
I've changed the name of the app (i.e. the .war) but it behaves the same
way. I'll try to debug it.



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

Re: [VOTE] Release Apache Tomcat 9.0.0.M1

[Martin Grigorov]

On Fri, Nov 13, 2015 at 1:12 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.0.M1 release is now available for voting.
>
> This is the first milestone release for the 9.0.x branch. It should be
> noted that, as a milestone release:
> - Servlet 4.0 is not finalised
> - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
> The major changes compared to the 8.0.x branch are:
> - Requires Java 8
> - BIO, Comet and Windows Itanium support have been removed
> - Support for TLS virtual hosting, ALPN, HTTP/2 and OpenSSL with
>   NIO/NIO2 has been added
> - Lots of internal refactoring to support the above changes
>
> For full details, see the changelog:
> http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M1/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1054/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcattags/TOMCAT_9_0_0_M1/
>
> The proposed 9.0.0.M1 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 9.0.0.M1
>

Environment: Ubuntu 15.10, Firefox 42.0, Google Chrome 46

Tested:
- Apache Wicket WebSocket demo application (uses JSR 356 web sockets) with
HTTP2.
- Apache Wicket examples application

The only problem I faced was with Wicket-Atmosphere integration (Atmosphere
ver. 2.2.8):

1)
ERROR - AtmosphereFramework- AtmosphereFramework exception
java.lang.IllegalStateException: A filter or servlet of the current chain
does not support asynchronous operations.
at org.apache.catalina.connector.Request.startAsync(Request.java:1571)
at
org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1037)
at
org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:723)
at
org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:93)
at
org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:68)
at
org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2078)
at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198)

Is it a good idea (and possible) to print which filter or servlet is not
properly configured? For better debug info.

2)
java.lang.NullPointerException
at
org.apache.catalina.connector.Request.getServletContext(Request.java:1559)
at org.apache.catalina.connector.Request.getContextPath(Request.java:1894)
at
org.apache.catalina.connector.RequestFacade.getContextPath(RequestFacade.java:783)
at
org.atmosphere.cpr.AtmosphereRequest.getContextPath(AtmosphereRequest.java:359)
at
javax.servlet.http.HttpServletRequestWrapper.getContextPath(HttpServletRequestWrapper.java:150)
at org.apache.wicket.atmosphere.EventBus$2.getContextPath(EventBus.java:473)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:184)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:112)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.(ServletWebRequest.java:82)

I believe this issue has been discussed before. Either here or in
Atmosphere forums.


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

Re: Issues when building Tomcat 9 + tcnative

[Martin Grigorov]

On Sun, Nov 15, 2015 at 1:35 PM, Mark Thomas <ma...@apache.org> wrote:

> On 15/11/2015 11:54, Martin Grigorov wrote:
>
> 
>
> > Running just 'ant' downloads tomcat-native.tar.gz (1.2.2) to base.path.
> > But this file is just copied in ./output/build/bin/, it is not untar-ed.
>
> Correct. The source ships in that directory for the Tomcat .tar.gz
> distro. Users of that distro are expected to build tc-native themselves.
>
> > So I've checked in build.xml and saw that at line 1927 it copies the .dll
> > files, as part of "dist-static" target. Executing "ant dist-target" leads
> > to:
> 
> > Why win32 ?!
> > Later I see the Unix versions being downloaded too, so maybe it just
> > download everything and then decides which ones to actually use. Not a
> big
> > issue.
>
> Because the Tomcat binary distros for Windows ship with the pre-built
> tc-native binaries.
>
> > 2) at step "extras-commons-logging" it fails with:
>
> Looks like you are using a version of Ant with known issues.
>
> Mark
>

I was using Ant 1.9.4. Upgraded it to 1.9.6 and the problem is gone!

Thanks!


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

Issues when building Tomcat 9 + tcnative

[Martin Grigorov]

Hi devs,

I'm trying to build 9.0.0.M1 from sources to test the HTTP2 functionalities.
I haven't built Tomcat + tcnative before so I may be doing something
wrong...

I run Ubuntu 15.10 here.

Running just 'ant' downloads tomcat-native.tar.gz (1.2.2) to base.path.
But this file is just copied in ./output/build/bin/, it is not untar-ed.

So I've checked in build.xml and saw that at line 1927 it copies the .dll
files, as part of "dist-static" target. Executing "ant dist-target" leads
to:

1) trydownload:
  [get] Getting:
http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.2.2/binaries/tomcat-native-1.2.2-win32-bin.zip

and

testexist:
 [echo] Testing  for /tmp/tc9/commons-daemon-1.0.15/windows/prunmgr.exe

and

trydownload:
  [get] Getting:
http://www.apache.org/dist/commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
  [get] To: /tmp/tc9/download-530232362.zip

and the same for makensis.exe

Why win32 ?!
Later I see the Unix versions being downloaded too, so maybe it just
download everything and then decides which ones to actually use. Not a big
issue.


2) at step "extras-commons-logging" it fails with:

extras-commons-logging:
   [gunzip] Expanding
/tmp/tc9/commons-logging-1.1.3/commons-logging-1.1.3-src.tar.gz to
/tmp/tc9/apache-tomcat-9.0.0.M1-src/output/extras/logging/commons-logging-src.tar
[untar] Expanding:
/tmp/tc9/apache-tomcat-9.0.0.M1-src/output/extras/logging/commons-logging-src.tar
into /tmp/tc9/apache-tomcat-9.0.0.M1-src/output/extras/logging

BUILD FAILED
/tmp/tc9/apache-tomcat-9.0.0.M1-src/build.xml:1651: Error while expanding
/tmp/tc9/apache-tomcat-9.0.0.M1-src/output/extras/logging/commons-logging-src.tar
java.io.IOException: Error detected parsing the header
at org.apache.tools.tar.TarInputStream.getNextEntry(TarInputStream.java:292)
at org.apache.tools.ant.taskdefs.Untar.expandStream(Untar.java:165)
at org.apache.tools.ant.taskdefs.Untar.expandFile(Untar.java:114)
at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:132)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.Main.runBuild(Main.java:851)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.IllegalArgumentException: Invalid byte 32 at offset 7
in '   {NUL}' len=8
at org.apache.tools.tar.TarUtils.parseOctal(TarUtils.java:134)
at org.apache.tools.tar.TarUtils.parseOctalOrBinary(TarUtils.java:172)
at org.apache.tools.tar.TarEntry.parseTarHeader(TarEntry.java:912)
at org.apache.tools.tar.TarEntry.parseTarHeader(TarEntry.java:899)
at org.apache.tools.tar.TarEntry.(TarEntry.java:323)
at org.apache.tools.tar.TarInputStream.getNextEntry(TarInputStream.java:290)
... 19 more


$ tar xvf commons-logging-src.tar
works just fine, but it seems the Java library used for untar-ing doesn't
like the content

I'll try with apache-tomcat-9.0.0.M1.tar.gz  +
http://tomcat.apache.org/native-doc/ (configure+make)


Cheers
Martin

Re: Issues when building Tomcat 9 + tcnative

[Martin Grigorov]

On Sun, Nov 15, 2015 at 12:54 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

>
> So I've checked in build.xml and saw that at line 1927 it copies the .dll
> files, as part of "dist-static" target. Executing "ant dist-target" leads
> to:
>

Uh. Of course ".dll" means that it will deal with Windows stuff...


I have the natives properly set up! Now I'll test the HTTP2 connector.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: Issues when building Tomcat 9 + tcnative

[Martin Grigorov]

On Sun, Nov 15, 2015 at 1:35 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

>
> On Sun, Nov 15, 2015 at 12:54 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>>
>> So I've checked in build.xml and saw that at line 1927 it copies the .dll
>> files, as part of "dist-static" target. Executing "ant dist-target" leads
>> to:
>>
>
> Uh. Of course ".dll" means that it will deal with Windows stuff...
>
>
> I have the natives properly set up! Now I'll test the HTTP2 connector.
>
>
To setup HTTP2 I follow the steps done by Konstantin Kolinko at
https://bz.apache.org/bugzilla/show_bug.cgi?id=58605
But here it fails with:

15-Nov-2015 13:40:37.505 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library 1.2.2 using APR version 1.5.2.
15-Nov-2015 13:40:37.506 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
15-Nov-2015 13:40:37.508 INFO [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized (OpenSSL 1.0.2d 9 Jul 2015)
15-Nov-2015 13:40:37.612 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-apr-8080"]
15-Nov-2015 13:40:37.619 INFO [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-apr-8443"] connector has been configured to support negotiation
to [h2] via ALPN
15-Nov-2015 13:40:37.620 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-apr-8443"]
15-Nov-2015 13:40:37.622 SEVERE [main]
org.apache.coyote.AbstractProtocol.init Failed to initialize end point
associated with ProtocolHandler ["https-apr-8443"]
 java.lang.Exception: Unable to load certificate key
/tmp/tc9/apache-tomcat-9.0.0.M1/conf/localhost-key.pem (error:0906D06C:PEM
routines:PEM_read_bio:no start line)
at org.apache.tomcat.jni.SSLContext.setCertificate(Native Method)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:487)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:790)
at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:544)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:67)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:978)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:569)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:851)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:600)
at org.apache.catalina.startup.Catalina.load(Catalina.java:623)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484)

The connector config is:







Ideas what could be wrong ?

Martin

Re: svn commit: r1713158 - /tomcat/tc6.0.x/trunk/test/org/apache/catalina/tribes/group/TestGroupChannelSenderConnections.java

[Martin Grigorov]

On Sat, Nov 7, 2015 at 7:35 PM, Rémy Maucherat  wrote:

> 2015-11-07 18:17 GMT+01:00 :
>
> > Author: kkolinko
> > Date: Sat Nov  7 17:17:55 2015
> > New Revision: 1713158
> >
> > URL: http://svn.apache.org/viewvc?rev=1713158=rev
> > Log:
> > Copy test implementation from Tomcat 7.
> > This a) uses logging instead of System.out,
> > b) validates result of the test and fail()s, instead of just printing a
> > message onto System.out
> >
> > When I voted for CTR on 6, it was agreed upon that only critical fixes
> would go in 6. Obviously, there's no regression risk with the testsuite,
> but what is the rationale with such an upgrade ?
>

I've also asked the same myself.
My answer is: to be better prepared for the eventual fixes later :-)


>
> Rémy
>

Re: Moderators wanted

[Martin Grigorov]

Hi Mark,

On Thu, Oct 15, 2015 at 12:24 PM, Mark Thomas <ma...@apache.org> wrote:

> On 01/12/2014 16:24, Martin Grigorov wrote:
> > Hi,
> >
> > On Mon, Dec 1, 2014 at 4:56 PM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> Hi,
> >>
> >> I've been reviewing the moderators for our various lists and if I ignore
> >> the no longer active ones we are below the 3 moderators the ASF likes to
> >> have on a number of lists.
> >>
> >> Therefore, can I have some volunteers for the following lists:
> >>
> >> users@tomcat.a.o- Need two moderators
> >> dev@tomct.a.o   - Need one moderator
> >> announce@tomcat.a.o - Need one moderator
> >> private@tomcat.a.o  - Need one moderator
> >> security@tomcat.a.o - Need one moderator
> >>
> >> You can volunteer for more than one :)
> >>
> >> There is typically less than one message a week that requires moderator
> >> input (security@ is a little higher) which is usually explaining to
> >> folks how to unsubscribe themselves or doing it for them if they are
> >> unable to.
> >>
> >> Note all of our public lists automatically reject mails from
> >> unsubscribed users so there is no moderator traffic from that source.
> >>
> >>
> >
> >> Generally, you need to be a committer to moderate a list.
> >> To moderate the private and security list you need to be a PMC member.
> >>
> >
> > As an ASF Member I already have access to those lists. I'd volunteer for
> > private@ and security@ if this is OK with you.
>
> Martin,
>
> Sorry I dropped the ball on this. Is this still something you are
> willing to take on?
>

Sure!


>
> Mark
>
>
> -
> 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.65

[Martin Grigorov]

[ X ] Stable - go ahead and release as 7.0.65 Stable

Tested our main application. No issues found!

On Fri, Oct 9, 2015 at 1:04 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.65 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.65/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1053/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_65/
>
> The proposed 7.0.65 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.65 Stable
>
> Regards,
> Violeta
>

Re: svn commit: r1708968 - in /tomcat/site/trunk: docs/migration-9.html docs/migration.html xdocs/migration-9.xml xdocs/migration.xml

[Martin Grigorov]

Hi,

On Fri, Oct 16, 2015 at 2:03 PM, <ma...@apache.org> wrote:

> In JSP pages that use wildcard import syntax the new classes added in
> +Servlet API may conflict with ones in web applications.
> +For example, if package "a" contains class
> +PushBuilder, the following JSP page will cease to
> compile in
> +Tomcat 8:
>

I think this should say "Tomcat 9".


> +
> +
>



Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: svn commit: r1708968 - in /tomcat/site/trunk: docs/migration-9.html docs/migration.html xdocs/migration-9.xml xdocs/migration.xml

[Martin Grigorov]

On Fri, Oct 16, 2015 at 2:03 PM, <ma...@apache.org> wrote:

> 


s/virtua/virtuaL/

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: [VOTE] Release Apache Tomcat 8.0.30

[Martin Grigorov]

On Wed, Dec 2, 2015 at 1:02 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.0.30 release is now available for voting.
>
> The main changes since 8.0.29 are:
>
> - Location headers for redirects now use relative URIs. This can
>   be controlled by Context with the useRelativeRedirects attribute.
>
> - Correct a regression in 8.0.29 that broke redirects for context
>   roots.
>
> - Restore the default setting of quoteAttributeEL in Jasper to true
>   to align with 8.0.26/7.0.64 and earlier as well as other JSP
>   implementations.
>
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.30/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1057/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_30/
>
> The proposed 8.0.30 release is:
> [ ] Broken - do not release
>


> [ X ] Stable - go ahead and release as 8.0.30
>



>
> -
> 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.29

[Martin Grigorov]

On Fri, Nov 20, 2015 at 11:00 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.0.29 release is now available for voting.
>
> The main changes since 8.0.28 are:
>
> - Add an option to control (per context) quoting of EL expressions in
>   JSP attributes
>
> - Correct a regression in the fix for 56777 that added support for
>   URIs in config file locations
>
> - Add a new RestCsrfPreventionFilter that provides basic CSRF
>   protection for REST APIs
>
> -  Use instance manager for WebSocket server endpoint instances
>
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.29/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1055/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_29/
>
> The proposed 8.0.29 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.0.29
>

Tested our main application and Apache Wicket's examples app


>
> -
> 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: Apache Tomcat YouTube channel

[Martin Grigorov]

Hi Mark,

Please add me.

Martin

On Thu, Nov 19, 2015 at 2:44 PM, Mark Thomas  wrote:

> Hi,
>
> In readiness for the Webinar recordings, I have created the Apache
> Tomcat YouTube channel.
>
> If any committer wants to help manage that channel, just let me know and
> I'll add you (via you asf e-mail so this needs to be linked to your
> Google account).
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Using modern development tools for friendlier environment for newcomers

[Martin Grigorov]

Hi devs,

Recently a colleague of mine asked me what it takes to become an Apache
committer.
I've explained him that he has to choose a project that is interesting to
him and start participating in the mailing lists (helping others at users@,
giving opinion and testing releases at dev@), providing patches for open
issues, etc.
Few days later he came back with the following questions:

1) Why Tomcat still uses SVN?
I've told him that this is the SCM tool most of the committers have
experience with and there were some discussions to move to Git several
months back.
I've recommended him to use GitHub's Pull Requests for the time being - PRs
are monitored and merged if approved. Even if Tomcat was using Git, Apache
Infra doesn't provide tool with Pull Request support (GitLab, Gerrit, or
similar) anyway so there is no big difference from a contributor point of
view.

2) Why Tomcat uses Bugzilla?
It is archaic and its UI is unfriendly - he said.
To be honest I didn't have a good answer here. I also don't like Bugzilla.
Everybody knows how to use JIRA! It is hard to explain that Apache JIRA
runs on Tomcat, but Tomcat project itself uses Perl software for issue
tracking (no matter how good Bugzilla is).

I know that SVN, Git, JIRA, Bugzilla are just tools. We can do our work
with any of them.
Maybe there are more (and more important!) reasons why my colleague didn't
start contributing to Tomcat yet but I also agree with him that by moving
to more modern tools Tomcat will become easier and friendlier for newcomers.


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: Using modern development tools for friendlier environment for newcomers

[Martin Grigorov]

Hi,


On Tue, Jun 7, 2016 at 11:33 AM, Mark Thomas <ma...@apache.org> wrote:

> On 07/06/2016 10:17, Martin Grigorov wrote:
> > Hi devs,
> >
> > Recently a colleague of mine asked me what it takes to become an Apache
> > committer.
> > I've explained him that he has to choose a project that is interesting to
> > him and start participating in the mailing lists (helping others at
> users@,
> > giving opinion and testing releases at dev@), providing patches for open
> > issues, etc.
> > Few days later he came back with the following questions:
> >
> > 1) Why Tomcat still uses SVN?
> > I've told him that this is the SCM tool most of the committers have
> > experience with and there were some discussions to move to Git several
> > months back.
> > I've recommended him to use GitHub's Pull Requests for the time being -
> PRs
> > are monitored and merged if approved. Even if Tomcat was using Git,
> Apache
> > Infra doesn't provide tool with Pull Request support (GitLab, Gerrit, or
> > similar) anyway so there is no big difference from a contributor point of
> > view.
>
> If I recall correctly, the consensus last time around was that there was
> merit in exploring the options for using git further with a view to
> migrating if the majority were convinced there was a benefit to the move.
>
> There is an outstanding task (I need to chase it up) for the infra team
> to look at if we could move to a single git repo for multiple branches
> or would need multiple repos.
>

One repo should be possible.
Even if there are some problems with the initial conversion from SVN to Git
the person dealing with it could create N Git repos and then with the help
of "git remote add" combine them into one with N branches and finally push
those branches into a single repository.


>
> > 2) Why Tomcat uses Bugzilla?
> > It is archaic and its UI is unfriendly - he said.
> > To be honest I didn't have a good answer here. I also don't like
> Bugzilla.
> > Everybody knows how to use JIRA! It is hard to explain that Apache JIRA
> > runs on Tomcat, but Tomcat project itself uses Perl software for issue
> > tracking (no matter how good Bugzilla is).
>
> My personal view is Jira is overly complex and horribly slow. Bugzilla
>

I think JIRA is slower because the majority of the projects are there.
But I guess it would be an overkill for Infra to maintain several instances
of JIRA (e.g. sharded by project name).


> just works. We don't need any of the extra features Jira offers. Do we
> want any of them? None come to mind. Others may have a different view.
>

I personally like the JIRA plugins that integrate with the SCM tools.
Committing with "PROJECT_NAME-1234" in the commit message automatically
adds a comment to the respective ticket with a link to Git/SVN repo. It is
very easy to explore the history of a ticket.
Also it has a proper "Fix version" field. With it it is much easier to
create a changelog. No need to maintain one manually.


>
> > I know that SVN, Git, JIRA, Bugzilla are just tools. We can do our work
> > with any of them.
> > Maybe there are more (and more important!) reasons why my colleague
> didn't
> > start contributing to Tomcat yet but I also agree with him that by moving
> > to more modern tools Tomcat will become easier and friendlier for
> newcomers.
>
> The Tomcat community tends to change development technology when it can
> see some direct benefit from the change. It doesn't change just to use
> the latest shiny new toy.
>

I totally agree with "see some benefit"!
I don't agree with "new" :-) Both Git and JIRA are on the market for quite
some time.


>
> git does have some benefits but also some potential complications. My
> view is we are around the tipping point for svn -> git.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 9.0.0.M8

[Martin Grigorov]

On Tue, Jun 7, 2016 at 6:02 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.0.M8 release is now available for voting.
>
> This is a milestone release for the 9.0.x branch. It should be
> noted that, as a milestone release:
> - Servlet 4.0 is not finalised
> - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
> The major changes compared to the 9.0.0.M6 release are:
> - Improvements to memory leak detection and prevention including the
>   change RMI memory leaks are now correctly treated as application bugs
>   rather than a JRE bug
> - Fix a couple of memory leaks found in Tomcat
> - The HTTP Server header is no longer set by default
>
> For full details, see the changelog:
> http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M8/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1085/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M8/
>
> The proposed 9.0.0.M8 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 9.0.0.M8
>

[ X ] Alpha - go ahead and release as 9.0.0.M8

Regards,
Martin



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

Re: Using modern development tools for friendlier environment for newcomers

[Martin Grigorov]

Hi Chris,

On Fri, Jun 17, 2016 at 12:51 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Martin,
>
> On 6/8/16 3:25 AM, Martin Grigorov wrote:
> > On Tue, Jun 7, 2016 at 11:33 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 07/06/2016 10:17, Martin Grigorov wrote:
> >>> Hi devs,
> >>>
> >>> Recently a colleague of mine asked me what it takes to become an Apache
> >>> committer.
> >>> I've explained him that he has to choose a project that is interesting
> to
> >>> him and start participating in the mailing lists (helping others at
> >> users@,
> >>> giving opinion and testing releases at dev@), providing patches for
> open
> >>> issues, etc.
> >>> Few days later he came back with the following questions:
> >>>
> >>> 1) Why Tomcat still uses SVN?
> >>> I've told him that this is the SCM tool most of the committers have
> >>> experience with and there were some discussions to move to Git several
> >>> months back.
> >>> I've recommended him to use GitHub's Pull Requests for the time being -
> >> PRs
> >>> are monitored and merged if approved. Even if Tomcat was using Git,
> >> Apache
> >>> Infra doesn't provide tool with Pull Request support (GitLab, Gerrit,
> or
> >>> similar) anyway so there is no big difference from a contributor point
> of
> >>> view.
> >>
> >> If I recall correctly, the consensus last time around was that there was
> >> merit in exploring the options for using git further with a view to
> >> migrating if the majority were convinced there was a benefit to the
> move.
> >>
> >> There is an outstanding task (I need to chase it up) for the infra team
> >> to look at if we could move to a single git repo for multiple branches
> >> or would need multiple repos.
> >>
> >
> > One repo should be possible.
> > Even if there are some problems with the initial conversion from SVN to
> Git
> > the person dealing with it could create N Git repos and then with the
> help
> > of "git remote add" combine them into one with N branches and finally
> push
> > those branches into a single repository.
> >
> >
> >>
> >>> 2) Why Tomcat uses Bugzilla?
> >>> It is archaic and its UI is unfriendly - he said.
> >>> To be honest I didn't have a good answer here. I also don't like
> >> Bugzilla.
> >>> Everybody knows how to use JIRA! It is hard to explain that Apache JIRA
> >>> runs on Tomcat, but Tomcat project itself uses Perl software for issue
> >>> tracking (no matter how good Bugzilla is).
> >>
> >> My personal view is Jira is overly complex and horribly slow. Bugzilla
> >>
> >
> > I think JIRA is slower because the majority of the projects are there.
> > But I guess it would be an overkill for Infra to maintain several
> instances
> > of JIRA (e.g. sharded by project name).
>
> I think it's slower because it's a sledgehammer where a screwdriver will
> do the job. I've never liked JIRA, but as was previously said "tools are
> tools".
>

At my $dailyJob JIRA is not slow at all.
It is Apache JIRA installation problem, not every JIRA installation.
If you are subscribed to infra@ you will see that people complain
relatively often that it is either down or slow. Last such mail is from
yesterday!
IMO Apache JIRA should be split into several instances.
But here is not the place to discuss this topic!

What I was trying to explain is that Tomcat looks like an ageing product
from a tooling point of view: Bugzilla, SVN, ANT, Gump.
It is hard to make Tomcat development attractive to work with tools from
the 90s (figuratively said).

I am not saying that by changing the tooling suddenly a lot of developers
will want to contribute!
I just share the opinion that many developers consider these things when
trying to find an OSS to contribute to.


> >> just works. We don't need any of the extra features Jira offers. Do we
> >> want any of them? None come to mind. Others may have a different view.
> >>
> >
> > I personally like the JIRA plugins that integrate with the SCM tools.
> > Committing with "PROJECT_NAME-1234" in the commit message automatically
> > adds a comment to the respective ticket with a link to Git/SVN repo. It
> is
> > very easy to explore the history of a ticket.
>
> All of this can be done with svn + bugzilla, too. I guess just nobody
> bothered to do it @ASF until JIRA came along.
>
&

Re: [VOTE] Release Apache Tomcat 7.0.70

[Martin Grigorov]

On Wed, Jun 15, 2016 at 9:47 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.70 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.70/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1088/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_70/
>
> The proposed 7.0.70 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.70 Stable
>

[ X ] Stable - go ahead and release as 7.0.70 Stable

Tested our main application and Apache Wicket WebSockets integration.


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 8.0.32

[Martin Grigorov]

On Wed, Feb 3, 2016 at 10:05 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.0.32 release is now available for voting.
>
> The main changes since 8.0.30 are:
>
> - Restore the default for mapperContextRootRedirectEnabled to true
>
> - Update the packaged version of the Tomcat Native Library to 1.2.4
>   to pick up the Windows binaries that are based on OpenSSL 1.0.2e
>
> - Expand session attribute filtering on load/unload to all managers
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.32/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1063/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_32/
>
> The proposed 8.0.32 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.0.32
>
>
Regards,
Martin


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

Re: [VOTE] Release Apache Tomcat 9.0.0.M3

[Martin Grigorov]

On Tue, Feb 2, 2016 at 1:20 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.0.M3 release is now available for voting.
>
> This is a milestone release for the 9.0.x branch. It should be
> noted that, as a milestone release:
> - Servlet 4.0 is not finalised
> - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
> The major changes compared to the 9.0.0.M1 branch are:
> - Ability to use OpenSSL with JSSE configuration
> - Update to Tomcat-native 1.2.4 to pick up Windows binaries based on
>   OpenSSL 1.0.2e
> - Allow HTTP redirects to be relative
> - Lots of bug fixes
>
> For full details, see the changelog:
> http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M3/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1062/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M3/
>
> The proposed 9.0.0.M3 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 9.0.0.M3
>
>
Regards,
Martin


> -
> 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.68

[Martin Grigorov]

On Tue, Feb 9, 2016 at 8:18 AM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.68 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.68/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1064/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_68/
>
> The proposed 7.0.68 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.68 Stable
>

Tested our main application and Apache Wicket WebSocket integration.


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 9.0.0.M2

[Martin Grigorov]

On Thu, Jan 21, 2016 at 1:38 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.0.M2 release is now available for voting.
>
> This is the second milestone release for the 9.0.x branch. It should be
> noted that, as a milestone release:
> - Servlet 4.0 is not finalised
> - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
> The major changes compared to the 9.0.0.M1 branch are:
> - Ability to use OpenSSL with JSSE configuration
> - Update to Tomcat-native 1.2.4 to pick up Windows binaries based on
>   OpenSSL 1.0.2e
> - Allow HTTP redirects to be relative
> - Lots of bug fixes
>
> For full details, see the changelog:
> http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M2/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1059/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M2/
>
> The proposed 9.0.0.M2 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 9.0.0.M2
>

With Rémy's help I was able to test my apps with HTTP2 without APR.
My conf/server.conf looks like:







Thanks, 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: [VOTE] Release Apache Tomcat 9.0.0.M2

[Martin Grigorov]

Hi,


On Fri, Jan 22, 2016 at 11:22 PM, Mark Thomas  wrote:

> On 21/01/2016 12:38, Mark Thomas wrote:
> > The proposed Apache Tomcat 9.0.0.M2 release is now available for voting.
> >
> > This is the second milestone release for the 9.0.x branch. It should be
> > noted that, as a milestone release:
> > - Servlet 4.0 is not finalised
> > - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
> >
> > The major changes compared to the 9.0.0.M1 branch are:
> > - Ability to use OpenSSL with JSSE configuration
> > - Update to Tomcat-native 1.2.4 to pick up Windows binaries based on
> >   OpenSSL 1.0.2e
> > - Allow HTTP redirects to be relative
> > - Lots of bug fixes
> >
> > For full details, see the changelog:
> >
> http://svn.us.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M2/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1059/
> > The svn tag is:
> > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M2/
> >
> > The proposed 9.0.0.M2 release is:
> > [ ] Broken - do not release
> > [X] Alpha - go ahead and release as 9.0.0.M2
>
> Unit tests pass.
> Simple smoke tests pass.
>
> Mark
>
>


Here 9.0.0.M2 fails to start the AprEndpoint.


3-Jan-2016 17:36:58.787 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.library.path=/usr/local/apr/lib/
23-Jan-2016 17:36:58.787 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.base=/tmp/tc9.0.0.M2/apache-tomcat-9.0.0.M2
23-Jan-2016 17:36:58.787 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.home=/tmp/tc9.0.0.M2/apache-tomcat-9.0.0.M2
23-Jan-2016 17:36:58.788 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.io.tmpdir=/tmp/tc9.0.0.M2/apache-tomcat-9.0.0.M2/temp
23-Jan-2016 17:36:58.788 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library 1.2.4 using APR version 1.5.2.
23-Jan-2016 17:36:58.788 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
23-Jan-2016 17:36:58.791 INFO [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized (OpenSSL 1.0.2e 3 Dec 2015)
23-Jan-2016 17:36:58.891 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-apr-8080"]
23-Jan-2016 17:36:58.899 INFO [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-apr-8443"] connector has been configured to support negotiation
to [h2] via ALPN
23-Jan-2016 17:36:58.900 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-apr-8443"]
23-Jan-2016 17:36:58.900 SEVERE [main]
org.apache.coyote.AbstractProtocol.init Failed to initialize end point
associated with ProtocolHandler ["https-apr-8443"]
 java.lang.NullPointerException
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:366)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:790)
at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:855)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)

Line 366 is: for (String protocol : sslHostConfig.getEnabledProtocols()) {
sshHostConfig is used earlier, so it seems the result of
#getEnabledProtocols() is null.

My conf/server.conf looks like:







I just uncommented it and changed the paths to the certificate files.

I run Ubuntu 15.10, Apr 1.5.2, Openssl 

Re: [VOTE] Release Apache Tomcat 8.0.31

[Martin Grigorov]

On Fri, Jan 22, 2016 at 11:21 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.0.31 release is now available for voting.
>
> The main changes since 8.0.30 are:
>
> - Restore the default for mapperContextRootRedirectEnabled to true
>
> - Update the packaged version of the Tomcat Native Library to 1.2.4
>   to pick up the Windows binaries that are based on OpenSSL 1.0.2e
>
> - Expand session attribute filtering on load/unload to all managers
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.31/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1060/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_31/
>
> The proposed 8.0.31 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.0.31
>

Tested my main application and Apache Wicket WebSocket integration (JSR356).


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

Re: [VOTE] Release Apache Tomcat 9.0.0.M2

[Martin Grigorov]

Hi Rémy,


On Sat, Jan 23, 2016 at 6:37 PM, Rémy Maucherat <r...@apache.org> wrote:

> 2016-01-23 17:51 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
>
> > Hi,
> > 23-Jan-2016 17:36:58.900 SEVERE [main]
> > org.apache.coyote.AbstractProtocol.init Failed to initialize end point
> > associated with ProtocolHandler ["https-apr-8443"]
> >  java.lang.NullPointerException
> > at
> > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:366)
> >
>
>
> > Line 366 is: for (String protocol : sslHostConfig.getEnabledProtocols())
> {
> > sshHostConfig is used earlier, so it seems the result of
> > #getEnabledProtocols() is null.
> >
> > My conf/server.conf looks like:
> >  > protocol="org.apache.coyote.http11.Http11AprProtocol"
> >maxThreads="150" SSLEnabled="true" >
> >  className="org.apache.coyote.http2.Http2Protocol"
> > />
> > 
> >  > certificateKeyFile="/tmp/tc9.0.0.M2/private-key.pem"
> >  certificateFile="/tmp/tc9.0.0.M2/cert.pem"
> >  type="RSA" />
> > 
> > 
> >
> > I just uncommented it and changed the paths to the certificate files.
> >
> > I run Ubuntu 15.10, Apr 1.5.2, Openssl 1.0.2e, Tomcat Native 1.2.4.
> > Please let me know if you need more information!
> >
> > Ok, well, it doesn't work ... Maybe it would be a great time to give a
> shot to the NIO(2) + OpenSSL support ! :)
>

What changes I should apply to be able to test HTTP2 ?
I've changed the protocol:







and created ~/.keystore.
Now I can start Tomcat and test my apps successfully with HTTP 1.1.
The "Server" response header is "Apache-Coyote/1.1". And my plugin for
Google Chrome says that SPDY/HTTP2 is not enabled.


>
> Besides that, the JSSE code went into a refactoring, and the APR connector
> didn't get it. The enabled protocols are now parsed in the superclass of
> the SSLUtil and the set on the host config, that doesn't happen with APR. I
> don't really understand why the APR connector didn't continue using
> sslHostConfig.getProtocols.
>
> Rémy
>

Re: [VOTE] Release Apache Tomcat 7.0.69

[Martin Grigorov]

On Mon, Apr 11, 2016 at 12:55 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.69 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.69/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1074/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_69/
>
> The proposed 7.0.69 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.69 Stable
>

[X] Stable - go ahead and release as 7.0.69 Stable

Tested Apache Wicket native web socket examples.


> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 8.5.0

[Martin Grigorov]

On Thu, Mar 17, 2016 at 9:00 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.0 release is now available for voting.
>
> This is the first release of the 8.5.x branch. The release is, in essence:
> - Based on a copy of the 9.0.0.M4 tag
> - All 9.0.x changes to the specification APIs have been reverted. The
>   specification APIs should match 8.0.x exactly
> - Java 8 specific code has been re-written for Java 7
> - Tomcat and specification versions have been set
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.0/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1066/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_0/
>
> The proposed 8.5.0 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 8.5.0
> [ ] Beta   - go ahead and release as 8.5.0
> [ ] Stable - go ahead and release as 8.5.0
>
>
[ X ] Beta   - go ahead and release as 8.5.0


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

Re: svn commit: r1733080 - in /tomcat/trunk: java/org/apache/tomcat/util/buf/UriUtil.java webapps/docs/changelog.xml

[Martin Grigorov]

Hi Mark,

On Tue, Mar 1, 2016 at 3:37 PM,  wrote:

> Author: markt
> Date: Tue Mar  1 14:37:46 2016
> New Revision: 1733080
>
> URL: http://svn.apache.org/viewvc?rev=1733080=rev
> Log:
> Expand the fix for BZ 59001 to cover the special sequences used in
> Tomcat's custom jar:war: URL
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/buf/UriUtil.java
> tomcat/trunk/webapps/docs/changelog.xml
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/UriUtil.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/UriUtil.java?rev=1733080=1733079=1733080=diff
>
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/buf/UriUtil.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/UriUtil.java Tue Mar  1
> 14:37:46 2016
> @@ -106,6 +106,9 @@ public final class UriUtil {
>  private static String makeSafeForJarUrl(String input) {
>



>  // Since "!/" has a special meaning in a JAR URL, make sure that
> the
>  // sequence is properly escaped if present.
> -return input.replaceAll("!/", "%21/");
> +String tmp = input.replaceAll("!/", "%21/");
> +// Tomcat's custom jar:war: URL handling treats */ and ^/ as
> special
> +tmp = tmp.replaceAll("^/", "%5e/");
> +return tmp.replaceAll("\\*/", "%2a/");
>

How often this method is expected to be called? I guess at least once per
request.

My concern is about the performance of String#replaceAll. It uses Regex and
is slower than custom solutions like
https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java#L748

When I don't have access to such util methods in the classpath then I
prefer to pre-compile the Pattern as a constant and just match on it:
e.g. PERCENT_21_PATTERN.matcher(input).replaceAll("%21/")

Additionally I have the feeling that 'tmp.replaceAll("^/", "%5e/");' won't
behave as desired. I think it would match for any String that starts with a
slash because of '^'. You may need to Pattern.quote() it.


>  }
>  }
>
> Modified: tomcat/trunk/webapps/docs/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1733080=1733079=1733080=diff
>
> ==
> --- tomcat/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/trunk/webapps/docs/changelog.xml Tue Mar  1 14:37:46 2016
> @@ -107,6 +107,10 @@
>  59001: Correctly handle the case when Tomcat is
> installed on
>  a path where one of the segments ends in an exclamation mark.
> (markt)
>
> +  
> +Expand the fix for 59001 to cover the special
> sequences used
> +in Tomcats custom jar:war: URLs. (markt)
> +  
>
>  Switch to the web application class loader to the
>  ParallelWebappClassLoader by default. (markt)
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: svn commit: r1733080 - in /tomcat/trunk: java/org/apache/tomcat/util/buf/UriUtil.java webapps/docs/changelog.xml

[Martin Grigorov]

Hi Mark,


On Tue, Mar 1, 2016 at 6:53 PM, Mark Thomas <ma...@apache.org> wrote:

> On 01/03/2016 14:57, Martin Grigorov wrote:
> > On Tue, Mar 1, 2016 at 3:37 PM, <ma...@apache.org> wrote:
> >
> >> Author: markt
> >> Date: Tue Mar  1 14:37:46 2016
> >> New Revision: 1733080
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1733080=rev
> >> Log:
> >> Expand the fix for BZ 59001 to cover the special sequences used in
> >> Tomcat's custom jar:war: URL
>
> 
>
> > How often this method is expected to be called? I guess at least once per
> > request.
>
> That is not correct. It is generally called during web application
> start. I'd typically expect it to be called twice per JAR plus a few
> more times per web application for configuration files (depending on
> Host configuration).
>

OK. If the method is not called very often then it is not a big deal.


>
> > My concern is about the performance of String#replaceAll. It uses Regex
> and
> > is slower than custom solutions like
> >
> https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java#L748
> >
> > When I don't have access to such util methods in the classpath then I
> > prefer to pre-compile the Pattern as a constant and just match on it:
> > e.g. PERCENT_21_PATTERN.matcher(input).replaceAll("%21/")
>
> Given how infrequently this code will be called, when it will be called
> and the overhead of JAR handling overall compared to the contribution of
> these calls I don't think a custom replaceAll() is necessary (although
> if user feedback is different for some use cases we can always revisit
> that).
>
> The pre-compiled Pattern approach might be worth looking at. I'll see if
> I can put together a simple benchmark and add it to the unit tests.
>

I've seen the following commit with the compiled Pattern!


>
> > Additionally I have the feeling that 'tmp.replaceAll("^/", "%5e/");'
> won't
> > behave as desired. I think it would match for any String that starts
> with a
> > slash because of '^'. You may need to Pattern.quote() it.
>
> It does behave as intended. There was a test case that checked that that
> wasn't checked in with the original commit.
>

Are you sure? ;-)

public static void main(String[] args) {
System.err.println("aaa^/bbb".replaceAll("^/", "C"));
System.err.println("aaa^/bbb".replaceAll("\\^/", "C"));
}

Executing this prints:
aaa^/bbb
aaaCbbb

In the following commit this is escaped and works correctly!
Thanks!


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

Maven snapshot builds

[Martin Grigorov]

Hi,

Does anyone know what is the reason for the missing -SNAPSHOT builds at
https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/tomcat-catalina/
(RAO) ?

https://tomcat.apache.org/tomcat-8.5-doc/maven-jars.html says that the
snapshots should be at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tomcat/ but
this gives 404.

The last 8.0-SNAPSHOT at RAO is from Feb 23th.
I actually need 8.5-SNAPSHOT with the fix for ClassCastException when
trying to get the ApplicationPushBuilder.

Another option for me is to build and install the Maven jars locally. Any
hints for the Ant commands to do this ?

Thank you!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

Re: Maven snapshot builds

[Martin Grigorov]

On Fri, Apr 1, 2016 at 10:07 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> Does anyone know what is the reason for the missing -SNAPSHOT builds at
> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/tomcat-catalina/
> (RAO) ?
>
> https://tomcat.apache.org/tomcat-8.5-doc/maven-jars.html says that the
> snapshots should be at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/tomcat/
> but this gives 404.
>
> The last 8.0-SNAPSHOT at RAO is from Feb 23th.
> I actually need 8.5-SNAPSHOT with the fix for ClassCastException when
> trying to get the ApplicationPushBuilder.
>
> Another option for me is to build and install the Maven jars locally. Any
> hints for the Ant commands to do this ?
>

I didn't find a way to install them just locally so I've uploaded
8.5-SNAPSHOT at
https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/tomcat-catalina/8.5-SNAPSHOT/
by following the steps at res/maven/README.txt.


>
> Thank you!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>

Re: [VOTE] Release Apache Tomcat 8.0.33

[Martin Grigorov]

On Fri, Mar 18, 2016 at 9:55 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.0.33 release is now available for voting.
>
> The main changes since 8.0.32 are:
>
> - Correct a false positive warning for ThreadLocal related memory
>   leaks when the key class but not the value class has been loaded
>   by the web application class loader.
>
> - Improve the performance of
>   javax.servlet.jsp.el.ScopedAttributeELResolver when resolving
>   attributes that do not exist.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.5
>   to pick up the Windows binaries that are based on OpenSSL 1.0.2g
>   and APR 1.5.1.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.33/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1067/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_33/
>
> The proposed 8.0.33 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.0.33
>

[ X ] Stable - go ahead and release as 8.0.33


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

Re: memory leak in Tomcat 8.0.9

[Martin Grigorov]

Hi,


On Fri, May 20, 2016 at 2:55 PM, Sanka, Ambica  wrote:

> Support Team,
>
> We have been using Tomcat 8.0.9 for our applications. We noticed below
> memo= ry leak error and out tomcat could not stopped. We had to kill the
> process = manually. I was reading articles in the internet and this got
> address after=  tomcat 6. But we found error in higher versions. We are not
> sure where to = fix this? Below is the error we are getting
>
> 2016-05-19 14:03:31,161 [localhost-startStop-2] WARN
> org.apache.catalina.l=
>
> oader.WebappClassLoader- The web application [/fmDirectoryService] appears
> = to have started a thread named [Thread-6] but has failed to stop it. This
> i= s very likely to create a memory leak. Stack trace of thread:
>
> java.lang.Thread.sleep(Native Method)
>
> net.atpco.cluster.support.BaseLocator$AdminTask.run(BaseLocator.java:141)
>
> 2016-05-19 14:03:31,197 [localhost-startStop-2] INFO
> org.apache.catalina.c=
>
> ore.ContainerBase.[Catalina].[localhost].[/fmbootstrap]- Destroying Spring
> = FrameworkServlet 'dispatcherServlet'
>
> 2016-05-19 14:03:31,210 [localhost-startStop-2] INFO
> org.apache.catalina.c=
>
> ore.ContainerBase.[Catalina].[localhost].[/fmbootstrap]- Closing Spring
> roo= t WebApplicationContext
>
> 2016-05-19 14:03:31,210 [localhost-startStop-2] INFO
> org.springframework.b=
>
> oot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext-
> Closing=
> org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebAppli=
>
> cationContext@5e119034 org.springframework.boot.context.embedded.Ann cationContext@5e119034
> %3cmailto:org.springframework.boot.context.embedded.Ann>=
>
> otationConfigEmbeddedWebApplicationContext@5e119034>: startup date [Thu
> May=
>
> 19 08:17:39 EDT 2016]; root of context hierarchy May 19, 2016 2:03:31 PM
> com.mongodb.util.management.jmx.JMXMBeanServer unre= gisterMBean
>
> WARNING: Unable to register MBean
> org.mongodb.driver:type=3DConnectionPool,=
>
> clusterId=3D1,host=3Dlocalhost,port=3D27017
>
> javax.management.InstanceNotFoundException:
> org.mongodb.driver:type=3DConne=
>
> ctionPool,clusterId=3D1,host=3Dlocalhost,port=3D27017
>
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(D=
>
> efaultMBeanServerInterceptor.java:1095)
>
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveU=
>
> nregisterMBean(DefaultMBeanServerInterceptor.java:427)
>
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregister=
>
> MBean(DefaultMBeanServerInterceptor.java:415)
>
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanS=
>
> erver.java:546)
>
> at
> com.mongodb.util.management.jmx.JMXMBeanServer.unregisterMBean(J=
>
> MXMBeanServer.java:52)
>
> at
> com.mongodb.JMXConnectionPoolListener.connectionPoolClosed(JMXCo=
>
> nnectionPoolListener.java:68)
>
> at
> com.mongodb.PooledConnectionProvider.close(PooledConnectionProvi=
>
> der.java:107)
>
>
>
> Any kind of help is appreciated.
>

To get some free support please ask at us...@tomcat.apache.org mailing list.
Also please update to latest version of Tomcat (8.0.35) and try again.


>
> Thanks
>
> Ambica.
>
>

Re: Regarding files generated by "JJTree"

[Martin Grigorov]

Hello Sangeeta,

Yes, those files are auto-generated by a tool: https://javacc.java.net/.


On Fri, May 20, 2016 at 11:41 AM, sangeeta lal 
wrote:

> Dear Dev Team,
>
> Can anyone please give me little information about these files?
>
> Thank You
>
> On Thu, May 19, 2016 at 8:22 PM, sangeeta lal 
> wrote:
>
> >
> > Dear Dev Team,
> >
> >
> > I am Sangeeta. I am a PhD Scholar in the area of automated software
> > engineering. I am currently studying source code of Apache Tomcat
> project.
> > While studying the source code. I noticed a folder in Apache Tomcat
> project
> > consisting of 58 files having following line written in them:
> >
> >
> > "/* *Generated By:JJTree: Do not edit this line. AstLambdaExpression.java
> > Version 4.3 */"*
> >
> >
> > Can anyone please explain me little about the meaning of this line? Are
> > all such files  generated by this tool have no contribution from the
> human
> > developers?
> >
> > I highly appreciate your help!
> >
> > Thanks You
> > Sangeeta
> >
> > --
> > Regards...
> > Sangeeta
> > Assistant Professor
> > CSE Department @JIIT Noida
> >
> >
>
>
> --
> Regards...
> Sangeeta
> Assistant Professor
> CSE Department @JIIT Noida
>

Re: Regarding files generated by "JJTree"

[Martin Grigorov]

Hi,

I guess your question is related to
http://markmail.org/message/kw4erakv272hsy3o where someone else already
told you about JavaCC.
AFAIK JavaCC is the only tool used by Tomcat that generates classes.
The number of classes depends on the parser rules so it could be N today
and M tomorrow.
Just grep the sources for this header and use the returned number.


On Fri, May 20, 2016 at 12:01 PM, sangeeta lal <sangeeta.6...@gmail.com>
wrote:

> Dear Sir,
>
> *Thanks for your reply!*
>
> Could you please tell me,  if there is any listing about all the  auto-
> generated files. I have manually identified 59 files in the folder "
> *tomcat\java\org\apache\el\parser*" which are auto generated.
>
> I have following two questions:
>
> 1. Can tomcat project have auto-generated files in some other folder also?
> 2. Is the "JavaCC" only tool which is used to auto-generate the files ? or
> there are some other tools as well?
>
>
> I highly *appreciate your help* and time!
>
> Thank You
> Sangeeta
>
> On Fri, May 20, 2016 at 3:14 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > Hello Sangeeta,
> >
> > Yes, those files are auto-generated by a tool: https://javacc.java.net/.
> >
> >
> > On Fri, May 20, 2016 at 11:41 AM, sangeeta lal <sangeeta.6...@gmail.com>
> > wrote:
> >
> > > Dear Dev Team,
> > >
> > > Can anyone please give me little information about these files?
> > >
> > > Thank You
> > >
> > > On Thu, May 19, 2016 at 8:22 PM, sangeeta lal <sangeeta.6...@gmail.com
> >
> > > wrote:
> > >
> > > >
> > > > Dear Dev Team,
> > > >
> > > >
> > > > I am Sangeeta. I am a PhD Scholar in the area of automated software
> > > > engineering. I am currently studying source code of Apache Tomcat
> > > project.
> > > > While studying the source code. I noticed a folder in Apache Tomcat
> > > project
> > > > consisting of 58 files having following line written in them:
> > > >
> > > >
> > > > "/* *Generated By:JJTree: Do not edit this line.
> > AstLambdaExpression.java
> > > > Version 4.3 */"*
> > > >
> > > >
> > > > Can anyone please explain me little about the meaning of this line?
> Are
> > > > all such files  generated by this tool have no contribution from the
> > > human
> > > > developers?
> > > >
> > > > I highly appreciate your help!
> > > >
> > > > Thanks You
> > > > Sangeeta
> > > >
> > > > --
> > > > Regards...
> > > > Sangeeta
> > > > Assistant Professor
> > > > CSE Department @JIIT Noida
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards...
> > > Sangeeta
> > > Assistant Professor
> > > CSE Department @JIIT Noida
> > >
> >
>
>
>
> --
> Regards...
> Sangeeta
> Assistant Professor
> CSE Department @JIIT Noida
>

Re: [VOTE] Release Apache Tomcat 8.5.2

[Martin Grigorov]

On Thu, May 12, 2016 at 12:22 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.2 release is now available for voting.
>
> 8.5.2 corrects a regression found in 8.5.1.
>
> The major changes compared to the 8.5.0 release are:
> - Add the org.apache.catalina.servlet4preview package that can be
>   used to gain early access to Servlet 4.0 features. Note that this
>   package will not be present in Tomcat 9.
> - Make default TLS configuration more secure
> - Add direct HTTP/2 connection support
> - Update the packaged version of the Tomcat Native Library to 1.2.7 to
>   pick up the Windows binaries that are based on OpenSSL 1.0.2h and
>   APR 1.5.2.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.2/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1081/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_2/
>
> The proposed 8.5.2 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 8.5.2
> [X] Beta   - go ahead and release as 8.5.2
> [ ] Stable - go ahead and release as 8.5.2
>

Tested Apache Wicket WebSocket


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

Re: Looking for mentor

[Martin Grigorov]

Hi,

On Sat, Apr 16, 2016 at 9:34 PM, Abdessamed MANSOURI 
wrote:

> Thank you for your response and your time, i checkouted svn trunk and built
> Tomcat successfully, its works fine, i also run ant test, for unit testing,
> but it ended with some errors (i've used IBM J9), now i completed this
> step, what do you suggests me to do now?? :)
>

Out of curiosity: Why do you use J9 ?
I guess your first task could be to make all Tomcat tests running on J9 ;-)


>
> I can't find Tomcat on Jira, why?? :)
>

Tomcat is using Bugzilla.
Check http://tomcat.apache.org/bugreport.html


>
> Thank you for your time again.
>
> 2016-04-16 16:25 GMT+01:00 Mark Thomas :
>
> > On 15/04/2016 17:59, Abdessamed MANSOURI wrote:
> > > Hello all,
> > >
> > > I'm newcomer and i want to contribute to Tomcat developement, i have
> some
> > > free time (alots of time), so i want to be useful in this world better
> > than
> > > sleeping all the day, so i'm looking for applying Apache mentoring
> > program,
> > > i'm not guru in Java but not totaly a newbie, so i want to try all my
> > best
> > > to help you guys, who want to be my mentor??
> >
> > Welcome to the Tomcat development community. Feel free to ask any
> > questions you have on this list.
> >
> > > Note : i still student, but i'm not looking to do Tomcat as my final
> > > project (i already have a final project), i wan't to help you (as much
> > as i
> > > can).
> > >
> > > Thank you all for your time.
> >
> > The first step is to make sure you can build Tomcat locally. Follow the
> > instructions in [1] to checkout the latest Tomcat source and and build
> it.
> >
> > Note that the URL you'll need to checkout Tomcat trunk is:
> > https://svn.apache.org/viewvc/tomcat/trunk
> >
> > If you have any questions, just ask.
> >
> > Mark
> >
> >
> > [1] https://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?view=markup
> >
> >
> > -
> > 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.5.4

[Martin Grigorov]

On Wed, Jul 6, 2016 at 11:42 AM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.4 release is now available for voting.
>
> The major changes compared to the 8.5.3 release are:
>
> - Correct a regression in the embedded packaging
>
> - Add the ability to control the degree of concurrency when processing
>   HTTP/2 connections
>
> - Update to Tomcat Native 1.2.8
>
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.4/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1090/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_4/
>
> The proposed 8.5.4 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 8.5.4
> [ ] Beta   - go ahead and release as 8.5.4
>

[ X ] Stable - go ahead and release as 8.5.4


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

Re: [VOTE] Release Apache Tomcat 9.0.0.M9

[Martin Grigorov]

On Mon, Jul 4, 2016 at 9:03 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.0.M9 release is now available for voting.
>
> This is a milestone release for the 9.0.x branch. It should be
> noted that, as a milestone release:
> - Servlet 4.0 is not finalised
> - The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
> The major changes compared to the 9.0.0.M8 release are:
>
> For full details, see the changelog:
> http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M9/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1089/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M9/
>
> The proposed 9.0.0.M9 release is:
> [ ] Broken - do not release
>

[ X ] Alpha - go ahead and release as 9.0.0.M9


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

Re: Read events suspend/resume logic in websocket impl to achieve backpressure

[Martin Grigorov]

Hi Violeta,

On Mon, Feb 6, 2017 at 8:55 PM, Violeta Georgieva 
wrote:

> Hi,
>
> Currently JSR356 provides possibility to add message handlers in order to
> receive web socket
> messages but there is no way to instruct the web socket implementation to
> suspend for a while
> the incoming messages (backpressure) so that the application is able to
> process the already delivered messages.
> The other web containers (Jetty, Undertow) supports such functionality so I
> would like to introduce it in Tomcat.
> Here [1] I prepared one possible implementation.
>
> What do you think about this feature and the proposed implementation?
>

It think it would be better to create a Pull Request even if the work is
not complete.
This way others will be able to comment on the changes and everyone here at
dev@ will see the comments.
At the moment it is possible to comment on your commits (in your repo) but
then only you will receive the feedback.
With [2] it is much easier to see the whole diff but it is not possible to
comment on it.


>
> Regards,
> Violeta
> [1] https://github.com/violetagg/tomcat/commits/ws-suspend-resume
>

[2]
https://github.com/apache/tomcat/compare/trunk...violetagg:ws-suspend-resume

Re: [ANN] New committer: Emmanuel Bourg

[Martin Grigorov]

On Jan 20, 2017 7:12 PM, "Mark Thomas"  wrote:

On behalf of the Tomcat committers I am pleased to announce that
Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Welcome, Emmanuel!
And thank you for your work on Debian too!


Regards,

Mark

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

Re: Publish snapshots from the Buidlbot

[Martin Grigorov]

Hi,

On Mon, Jan 23, 2017 at 11:53 AM, Mark Thomas  wrote:

> I think it would be useful if we configured buildbot to publish
> snapshots (probably as part of the daily build) to repository.a.o.
> Therefore I have requested the appropriate credentials from infra and
> when I have them I'll make the necessary changes tot he buildbot config.
> It might also be necessary to tweak our build scripts.
>

+1
I think Spring Boot folks will find them useful! And anyone else who embeds
Tomcat.



>
> Mark
>
> -
> 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.40

[Martin Grigorov]

On Fri, Jan 13, 2017 at 1:39 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 8.0.40 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.40/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1116/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_40/
>
> The proposed 8.0.40 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.0.40
>

Regards,
Martin


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 7.0.74

[Martin Grigorov]

On Fri, Jan 13, 2017 at 11:55 AM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.74 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.74/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1115/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_74/
>
> The proposed 7.0.74 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.74 Stable
>

Regards,
Martin


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 8.0.41

[Martin Grigorov]

On Thu, Jan 19, 2017 at 12:07 AM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 8.0.41 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.41/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1118/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_41/
>
> The proposed 8.0.41 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.0.41
>

Regards,
Martin


>
> Regards,
> Violeta
>