[Bug 55675] New: Checking and handling invalid configuration option values

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55675

Bug ID: 55675
   Summary: Checking and handling invalid configuration option
values
   Product: Tomcat 8
   Version: trunk
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: racezh...@gmail.com

Hi all,

I was using Tomcat for a while, but found Tomcat sometimes does not handle
misconfiguration well, which causes unnecessary confusion. 

Specifically, when users provide a wrong configuration option and Tomcat
produces a wrong result (or crashes), Tomcat should explicitly dump error
message pointing to the mis-configured option, rather than just dumping stack
traces, or simply restoring to the default behavior. At least, the invalid
configuration values should be logged. 

Strictly speaking, this may not be a bug, but (I think) it is definitely worth
improving to give better user experience. I have found many places in Tomcat.
Here is a very simple case for illustration purpose (I have more complex
examples, which I can post if they are of general interest):

In McastService.java

public long getDropTime() {
String p = properties.getProperty("memberDropTime");
return new Long(p).longValue();
}

If a careless user uses "1o" (not 0) as the value of configuration option:
"memberDropTime", Tomcat will throw an exception when parsing this string.
Similar cases occur to me a few times; often, the effect of a misconfigured
option propagates through the program and causes some *delayed* problem, making
it even harder to localize the original misconfigured option.

I would suggest to add timely check immediate after reading a configuration
option value. For the above case, check whether p is a long value or not, and
also checking its permitted ranges. (yes, many places in Tomcat do this, but
still many places like the above case miss the checking). I would like Tomcat
to explicitly warn the user (or at least log) which option is misconfigured
rather than delaying the effect until the program crashes.

I found a couple of such places. and wondering whether Tomcat developers would
like to know them, and how do you think about such "mis-handling"? 

Thanks 

-Sai

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 55674] New: ThreadLocal memory leak clean-up causes huge log

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55674

Bug ID: 55674
   Summary: ThreadLocal memory leak clean-up causes huge log
   Product: Tomcat 7
   Version: 7.0.42
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: ugo.scaie...@gmail.com

ThreadLocal memory leak detection code is fine, but when it tries to clean-up
ThreadLocal maps, it prints something like this in catalina.out:

Oct 18, 2013 2:32:59 PM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks
SEVERE: The web application [/...] created a ThreadLocal with key of type [...]
(value [...]) and a value of type [java.text.SimpleDateFormat] (value
[java.text.SimpleDateFormat@6b2ed43a]) but failed to remove it when the web
application was stopped. Threads are going to be renewed over time to try and
avoid a probable memory leak.

Now, if the object contained in the ThreadLocal is very big and the toString
method dumps all the data of that object, log could become very huge. Eg, in
our application, we store a big HashMap in ThreadLocal and the trace above is
about 700Mb because it recursively calls toString methods of all objects
contained in the map.

Is it necessary to log values contained in ThreadLocal maps during clean-up
process?
Additionaly, log level for that message is set to SEVERE and there's no way to
specify logging details for that message.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely

2013-10-18 Thread Bob DeRemer 
Hi Guys,

In our implementation, we have a gateway app that uses jsr websockets to 
communication with our main application server.  In a small system, we want to 
run them both on a single Tomcat instance using the same Tomcat NIO connector, 
but directing to different respective WS paths.  This works fine if you deploy 
the MAIN first, then the GW - so that MAIN is already up and running.  If you 
restart Tomcat when both webapps are deployed - and the GW (client) starts 
first, it hangs indefinitely in the following code trying to establish a WS 
connection:

Is this a bug or a known limitation when a client/server in the same webapp try 
to connect at startup?

Thanks

"localhost-startStop-1" daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting 
on condition [0x1046e000]
   java.lang.Thread.State: WAITING (parking)
   at sun.misc.Unsafe.park(Native Method)
   - parking to wait for  <0x0007d6d98b18> (a 
java.util.concurrent.CountDownLatch$Sync)
   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
   at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
   at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
   at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
   at sun.nio.ch.PendingFuture.get(PendingFuture.java:180)
   at 
org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:568)
   at 
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:317)
   at 
com.thingworx.core.communication.channels.jsr356.client.Jsr356ClientChannel.connect(Jsr356ClientChannel.java:57)
   at 
com.thingworx.core.communication.endpoints.CommunicationEndpoint.connect(CommunicationEndpoint.java:186)
   at 
com.thingworx.core.communication.CommunicationSubsystem.startSubsystem(CommunicationSubsystem.java:88)
   at 
com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)
   at 
com.thingworx.apiserver.APIServerManager.startSubsystem(APIServerManager.java:92)
   at 
com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)
   at 
com.thingworx.apiserver.Bootstrapper.contextInitialized(Bootstrapper.java:57)
   at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939)
   at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
   - locked <0x0007da3e0308> (a 
org.apache.catalina.core.StandardContext)
   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
   - locked <0x0007da3e0308> (a 
org.apache.catalina.core.StandardContext)
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   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:744)

   Locked ownable synchronizers:
   - <0x0007da3a7ab0> (a java.util.concurrent.ThreadPoolExecutor$Worker)



Bob DeRemer
Senior Director, Architecture and Development

[Description: Description: Description: Description: 
cid:image001.png@01CBE3DE.51A12030]
http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)

2013-10-18 Thread Mark Thomas 
On 18/10/2013 13:54, Mark Thomas wrote:
> On 18/10/2013 12:48, Mark Thomas wrote:
>> When it goes wrong, the sequence is:
>> Read result [1]
>> Read result [48]
>> Read result [-20014]
>> 18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1]
>> websocket.drawboard.DrawboardEndpoint.onError onError:
>> java.io.IOException: Unexpected error [20,014] reading data from the
>> APR/native socket [364,180,784].
> 
> I've dug in to what could trigger the 20014 error code. I've got as far
> as ssl_socket_recv() in native\src\sslnetwork.c
> 
> There appear to be a number of ways that the code could end up returning
> 20014. The next step is to figure out which it is.

I've made some progress. I've captured a failure with Wireshark with an
SSL configuration that Wireshark can decrypt with the server's private
key (SSLProtocol="SSLv3", SSLCipherSuite="RC4-MD5") and it shows nothing
unusual until Tomcat initiates the close.

To progress I need to create a new tcnative with some debug info so I
guess I'll have to return to trying to get my local build environment
set up correctly.

Mark


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

RE: Possible IIS SPDY Redirector for Tomcat

2013-10-18 Thread Konstantin Preißer 
Hi all,

I would like to let you know some updates on this:

1) Results of performance measurement with various configurations and the 
SPDY-Redirector
2) Switching to Async I/O for the implementation of the IIS module


1) Performance

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Monday, September 30, 2013 8:53 PM
> To: Tomcat Developers List
> Subject: Re: Possible IIS SPDY Redirector for Tomcat
> 
> Konstantin,
> 
> > So it seems that the main performance problem is IIS when using
> > managed code/ASP.Net to write to the response, but I need to do
> > additional testing.
> 
> Wow. Are you sure the thread burning the CPU is the one running the
> above code? Seems ... unfortunate.

I have now done additional testing with various configurations and I think my 
previous statement was wrong - IIS is not the culprit here. I guess it's the 
multiplexing that the SPDY Redirector is doing (multiplexing multiple HTTP 
requests on a single TCP connection) that causes the CPU usage. However, I 
don't think that there is a real problem here comparing the performance/CPU 
usage to Jetty.

To measure performance (speed and CPU usage), I set up a 2-CPU VM with IIS 8.5 
(Windows Server 2012 R2 x64), Tomcat 7.0.42 (for ISAPI Redirector) and Jetty 
8.1.13 (for SPDY Redirector). For IIS, I created one web application using the 
SPDY Redirector (connecting to Jetty) and one web application using the ISAPI 
Redirector (connecting to Tomcat).
I then created a Servlet 3.0 webapp with a Servlet that produces ~ 700 MB of 
random data, sending it in 32 KB chunks to the client, using the following code:

protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
response.addHeader("Content-Disposition", "attachment; 
filename=\"myTextfile.txt\"");

byte[] bytes = new byte[32768];
for (int i = 0; i < bytes.length; i++) {
bytes[i] = (byte)'a';
}

long bytesWritten = 0;
long lastDisplay = 0;
try (OutputStream out = response.getOutputStream()) {
while (true) {
out.write(bytes);
bytesWritten += bytes.length;

if (bytesWritten - lastDisplay > 500 * 1024) {
lastDisplay = bytesWritten + 500 * 1024;
System.out.println(bytesWritten + " Bytes written 
(completely).");
}

if (bytesWritten > 700 * 1024 * 1024)
break;
}
}
}


Then, I created a C# application that creates a TCP connection and sending the 
following raw request:
GET /TestSpdyServer/BigFileProducerServlet HTTP/1.1
Host: localhost
Connection: close

and reads from the TCP connection until it is closed, counting the bytes and 
milliseconds to calculate the average speed.
I then tested the speed when 1) connecting directly to Jetty (HTTP), 2) 
connecting directly to Tomcat (HTTP), 3)+4) connecting to IIS with 
SPDY-Redirector, 5) connecting to IIS with ISAPI redirector, 6) connecting to 
IIS using a ASP.Net handler producing 700 MB of random data, equally to the 
Servlet above.
This is what I got:

1) JettyHttp-Direct: 260 MB/s (Jetty: 47% CPU)
2) TomcatHttpBio-Direct: 275 MB/s (Tomcat: 45% CPU)
3) Iis-SpdyRedirector(Async)-JettySpdy (64 KB initial window size): 170 MB/s 
(Jetty: 35% CPU, IIS: 43% CPU)
4) Iis-SpdyRedirector(Async)-JettySpdy (128 KB initial window size): 205 MB/s 
(Jetty: 40% CPU, IIS: 50% CPU)
5) Iis-IsapiRedirector-TomcatAjpBio: 190 MB/s (Tomcat: 10% CPU, IIS: 20% CPU)
6) Iis-Asp.Net-Handler-Direct: 400 MB/s, 50% CPU

As you can see, with the SPDY redirector, both Jetty and IIS have a high amount 
of CPU usage (probably the costs of multiplexing) whereas the ISAPI redirector 
had a low CPU usage. However, I'm pretty happy with the current performance of 
the SPDY redirector.


2) Switching the implementation of the IIS module to Async I/O - see [1]: 
"Scalable Apps with Asynchronous Programming in ASP.NET"

.Net 4.5 introduces new "async" and "await" keywords for C# that allow you to 
easily create asynchronous code. E.g. you can write code just as you would with 
synchronous operations, and the compiler will create the Async State Machine 
for you.

As the previous implementation of the SPDY Redirector used blocking/synchronous 
IO for the IIS module, it meant that 1 thread was used per request. Now imagine 
you have 200 clients that simultaneously do requests to a resource that 
produces the response body very slowly, it would mean that IIS had to create 
200 threads for serving the requests. This can be a problem also e.g. for 
long-polling comet applications (where it may take some time until the HTTP 
response is sent) or Websocket connections (however WebSockets with I

[Bug 55671] Backport genStringAsCharArray patch to Tomcat 6.x branch.

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55671

Jeremy Whiting  changed:

   What|Removed |Added

   Keywords||PortBack

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 55671] New: Backport genStringAsCharArray patch to Tomcat 6.x branch.

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55671

Bug ID: 55671
   Summary: Backport genStringAsCharArray patch to Tomcat 6.x
branch.
   Product: Tomcat 6
   Version: 6.0.37
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: jwhit...@redhat.com

Hi,
 In the 6.x branch of Tomcat an inconsistent naming of the JSP compiler key
name for using char array type instead of String causes the compiler feature to
not work. I first noticed this when looking at the generated Servlet source
then using a debugger to double check.
 The code has been patched in the 7.x branch in rev 889966. It corrects the key
name from "genStrAsCharArray" to "genStringAsCharArray" in a couple of files.

http://svn.apache.org/viewvc?view=revision&revision=889966

 Is it possible this individual revision can be back-ported to Tomcat 6 ?

Regards,
Jeremy

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1533437 - /tomcat/tc6.0.x/trunk/STATUS.txt

2013-10-18 Thread kkolinko 
Author: kkolinko
Date: Fri Oct 18 13:04:59 2013
New Revision: 1533437

URL: http://svn.apache.org/r1533437
Log:
vote

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1533437&r1=1533436&r2=1533437&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Oct 18 13:04:59 2013
@@ -110,7 +110,7 @@ PATCHES PROPOSED TO BACKPORT:
   Notice files are corrected according to
   http://www.apache.org/legal/src-headers.html#notice
   http://svn.apache.org/r1533312
-  +1: violetagg
+  +1: violetagg, kkolinko
   -1:
 
 



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

svn commit: r1533433 - /tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice

2013-10-18 Thread kkolinko 
Author: kkolinko
Date: Fri Oct 18 12:59:49 2013
New Revision: 1533433

URL: http://svn.apache.org/r1533433
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55663
Notice files are corrected according to 
http://www.apache.org/legal/src-headers.html#notice

Followup to r1533316.
Apply the same fix to a file that does not exist in Tomcat trunk.

Modified:
tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice

Modified: tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice?rev=1533433&r1=1533432&r2=1533433&view=diff
==
--- tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice (original)
+++ tomcat/tc7.0.x/trunk/res/META-INF/jsp-api.jar.notice Fri Oct 18 12:59:49 
2013
@@ -1,7 +1,7 @@
 Apache Tomcat
 Copyright 1999-@YEAR@ The Apache Software Foundation
 
-This product includes software developed by
+This product includes software developed at
 The Apache Software Foundation (http://www.apache.org/).
 
 The original XML Schemas for Java EE Deployment Descriptors:



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

Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)

2013-10-18 Thread Mark Thomas 
On 18/10/2013 12:48, Mark Thomas wrote:
> When it goes wrong, the sequence is:
> Read result [1]
> Read result [48]
> Read result [-20014]
> 18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1]
> websocket.drawboard.DrawboardEndpoint.onError onError:
> java.io.IOException: Unexpected error [20,014] reading data from the
> APR/native socket [364,180,784].

I've dug in to what could trigger the 20014 error code. I've got as far
as ssl_socket_recv() in native\src\sslnetwork.c

There appear to be a number of ways that the code could end up returning
20014. The next step is to figure out which it is.

Mark

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

Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)

2013-10-18 Thread Mark Thomas 
On 18/10/2013 13:46, Konstantin Kolinko wrote:
> 2013/10/18 Mark Thomas :
>> On 17/10/2013 00:44, Konstantin Preißer wrote:
>>
>> 
>>
>>
>> There is a long series of these results:
>> Read result [1]
>> Read result [48]
>> Read result [-120002]
>>
>> which looks fairly normal (I need to look into why we see a single byte
>> and then 48 bytes rather than 49 bytes).
>>
> 
> A 1/(n-1) split is usually a counter-measure against BEAST attack on
> TLS 1.0 (CVE-2011-3389)
> 
> (I have not looked whether it is what actually happens here, but just
> noting to save you some time, as the scheme sounds familiar).

Thanks. That makes sense.

Mark

> 
> http://www.mail-archive.com/openssl-dev@openssl.org/msg29810.html
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389
> http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)

2013-10-18 Thread Konstantin Kolinko 
2013/10/18 Mark Thomas :
> On 17/10/2013 00:44, Konstantin Preißer wrote:
>
> 
>
>
> There is a long series of these results:
> Read result [1]
> Read result [48]
> Read result [-120002]
>
> which looks fairly normal (I need to look into why we see a single byte
> and then 48 bytes rather than 49 bytes).
>

A 1/(n-1) split is usually a counter-measure against BEAST attack on
TLS 1.0 (CVE-2011-3389)

(I have not looked whether it is what actually happens here, but just
noting to save you some time, as the scheme sounds familiar).

http://www.mail-archive.com/openssl-dev@openssl.org/msg29810.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389
http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html

Best regards,
Konstantin Kolinko

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

svn commit: r1533416 - /tomcat/tc6.0.x/trunk/STATUS.txt

2013-10-18 Thread violetagg 
Author: violetagg
Date: Fri Oct 18 12:15:58 2013
New Revision: 1533416

URL: http://svn.apache.org/r1533416
Log:
Proposal

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1533416&r1=1533415&r2=1533416&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Oct 18 12:15:58 2013
@@ -106,6 +106,13 @@ PATCHES PROPOSED TO BACKPORT:
   +1: markt
   -1:
 
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55663
+  Notice files are corrected according to
+  http://www.apache.org/legal/src-headers.html#notice
+  http://svn.apache.org/r1533312
+  +1: violetagg
+  -1:
+
 
 PATCHES/ISSUES THAT ARE STALLED
 



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

[Bug 55663] Incorrect text in NOTICE file

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55663

Violeta Georgieva  changed:

   What|Removed |Added

  Component|Catalina|Catalina
Version|trunk   |6.0.37
Product|Tomcat 8|Tomcat 6

--- Comment #1 from Violeta Georgieva  ---
Fixed in trunk and 7.0.x and will be included in 8.0.0-RC6 and 7.0.47 onwards.
Moving to Tomcat 6.

Regards
Violeta

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: [VOTE] Release Apache Tomcat 8.0.0-RC5

2013-10-18 Thread Violeta Georgieva 
2013/10/16 Mark Thomas 
>
> The proposed Apache Tomcat 8.0.0 release candidate 5 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 RC4 are:
> - Stability fixes in the APR/native connector
> - Stability fixes for non-blocking IO and WebSocket
> - Improvements to unit tests to reduce incidence of false reports
> - Add a drawing board example to the WebSocket examples
> - A handful of bug fixes
> - A small number of enhancements including direct gzip support in the
>   default Servlet
> - More HTML clean-up
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC5/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-186/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC5/
>
> The proposed 8.0.0-RC5 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 8.0.0-RC5 alpha

Checked with applications that use the new specifications features.

Regards
Violeta

Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)

2013-10-18 Thread Mark Thomas 
On 17/10/2013 00:44, Konstantin Preißer wrote:



> Additional information:
> When I try this with r1532720, then when this close of the Websocket 
> connection happens, Tomcat logs following exception:
> 
> 17-Oct-2013 01:38:28.378 SEVERE [http-apr-8443-exec-1] 
> websocket.drawboard.DrawboardEndpoint.onError onError: java.io.IOException: 
> Unexpected error [20,014] reading data from the APR/native socket 
> [245,310,416].
>  java.io.IOException: Unexpected error [20,014] reading data from the 
> APR/native socket [245,310,416].
>   at 
> org.apache.coyote.http11.upgrade.AprServletInputStream.doRead(AprServletInputStream.java:104)
>   at 
> org.apache.coyote.http11.upgrade.AbstractServletInputStream.read(AbstractServletInputStream.java:116)
>   at 
> org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:46)
>   at 
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:192)
>   at 
> org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:169)
>   at 
> org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:95)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:640)
>   at 
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:282)
>   at 
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2461)
>   at 
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2450)
>   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:744)
> 
> However, since r1532721, when the closing of Websocket/TCP connection 
> happens, no exception is logged.

I think this might be a bug in the tc-native library. I added some debug
logging to AprServletInputStream and recorded the value of result in the
doRead() method for every read.

There is a long series of these results:
Read result [1]
Read result [48]
Read result [-120002]

which looks fairly normal (I need to look into why we see a single byte
and then 48 bytes rather than 49 bytes).

When it goes wrong, the sequence is:
Read result [1]
Read result [48]
Read result [-20014]
18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1]
websocket.drawboard.DrawboardEndpoint.onError onError:
java.io.IOException: Unexpected error [20,014] reading data from the
APR/native socket [364,180,784].

which suggests to me that something goes wrong at a lower level than the
Java code. I've checked the state of the byte array when the error
occurs and it is an empty 8k array with offset of 0.

The other possibility is that I am not using the API correctly. There
was an issue with SSL writes that meant that I needed to use a dedicated
ByteBuffer for all SSL writes. It might be the case that I need to do
something similar for reads. Hopefully Mladen can comment on that.

Mark

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

svn commit: r1533391 - in /tomcat/tc7.0.x/trunk: build.properties.default res/maven/mvn.properties.default

2013-10-18 Thread violetagg 
Author: violetagg
Date: Fri Oct 18 11:18:33 2013
New Revision: 1533391

URL: http://svn.apache.org/r1533391
Log:
Prep for next version

Modified:
tomcat/tc7.0.x/trunk/build.properties.default
tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default

Modified: tomcat/tc7.0.x/trunk/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/build.properties.default?rev=1533391&r1=1533390&r2=1533391&view=diff
==
--- tomcat/tc7.0.x/trunk/build.properties.default (original)
+++ tomcat/tc7.0.x/trunk/build.properties.default Fri Oct 18 11:18:33 2013
@@ -27,7 +27,7 @@
 # - Version Control Flags -
 version.major=7
 version.minor=0
-version.build=47
+version.build=48
 version.patch=0
 version.suffix=-dev
 

Modified: tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default?rev=1533391&r1=1533390&r2=1533391&view=diff
==
--- tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default (original)
+++ tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default Fri Oct 18 11:18:33 
2013
@@ -35,7 +35,7 @@ maven.asf.release.repo.url=https://repos
 maven.asf.release.repo.repositoryId=apache.releases
 
 # Release version info
-maven.asf.release.deploy.version=7.0.47
+maven.asf.release.deploy.version=7.0.48
 
 #Where do we load the libraries from
 tomcat.lib.path=../../output/build/lib



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

[VOTE] Release Apache Tomcat 7.0.47

2013-10-18 Thread Violeta Georgieva 
The proposed Apache Tomcat 7.0.47 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.47/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-192/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_47/

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

Regards
Violeta

svn commit: r3293 [2/2] - in /dev/tomcat/tomcat-7/v7.0.47: ./ bin/ bin/embed/ bin/extras/ src/

2013-10-18 Thread violetagg 
Added: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.asc
==
--- dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.asc (added)
+++ dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.asc Fri Oct 
18 10:50:02 2013
@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v2.0.21 (MingW32)
+
+iQIcBAABCgAGBQJSYQ88AAoJECCLCrHWMBHHYcQP/RwMofLVtWTfFi5jRpfyx9Sr
+v2VT9XXZ9tIUIj1gEbncG2vy3agV9GuIPd8Hs4ONmte5UC0+hKEgLNaEDXL9I51e
+VOKCVSZxdav+8Sa5IKVzzCwwUSRwqY5lr4/uHWW94U8kBPwvC7M1x+IABxV745Cp
+0FJu9nMRKbKOLIi7gv5whb50An0/UAe5xPhpRVu6u+I/Gn9HqAIkLvqo7iPnEANS
+DXale2pYe9t3YFnjk96svdZP7bKGbtb8WoNe4n+ONbJqFK8oUw04ExR9zhAks+MZ
+/5yuwXPlpb7vCBavzb1WX5kbQ2ERGbx5XbAHMvAPfgskAYkxuTZvzsVV+V3NCOUb
+C2eR8Q6Kt+WzTDoGACfJWUIhcgb7vg8r9zpsOg+RZ7stjw7XC5Z/VS4brgDjz6Ew
+1zlTP7180CO3pnjJyFjYPumj3nqYEENycttSjtPgEhPkp/A6n04U/3COdIMHIRDF
+pZWFwotOgyndn+a528NIJhukyXgEHOUYf7NMo33Cmf4xlMOhwHchDNTbF2o4Bs+H
+OD6SbFaJwker7jiGCDf5jikLPz850ul0d14uyPAINoqWkT/+1f0LCWV//IcKXDjs
+8JA8YCA+hoEMUn8VpMywSPFHIX37i95g4iKaijQsbfFAUWe9m6L+VjTW7wa9EYvj
+B3tdkoaRjzzjrgvM580e
+=HaR4
+-END PGP SIGNATURE-

Added: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.md5
==
--- dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.md5 (added)
+++ dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.tar.gz.md5 Fri Oct 
18 10:50:02 2013
@@ -0,0 +1 @@
+4ee89bfd85f6afb31c7675b05f0469cb *apache-tomcat-7.0.47-src.tar.gz
\ No newline at end of file

Added: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip
==
Binary file - no diff available.

Propchange: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip
--
svn:mime-type = application/octet-stream

Added: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.asc
==
--- dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.asc (added)
+++ dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.asc Fri Oct 18 
10:50:02 2013
@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v2.0.21 (MingW32)
+
+iQIcBAABCgAGBQJSYQ7FAAoJECCLCrHWMBHH/yAP/3JVGa1xkFflDzwxW37IfYkF
++ZUWNoyOWcsnKd10XoxU4964Rr7OuRXjoxxrTCje58wDRu3JsDxrn33Q4/8cy3WJ
+edYckqqpOQOIK3QX26kJXDPKJGtGDw6yXrqRukxi9Lg902c32We5Gk0rAoFEaodP
+48eNiL9kFRf8WoVvJWk8cT6gngDpXzJo0Qpf+Nv9UePhIYrqgluHqjRRP6LiMzYs
+YmDgpJgLA/nUXZMPrwLjHL4EaeGvdtpTc7zMaPVyQ3HxO6hg/pXj2RfgXszR0hxZ
++TUJGQS1THeT0Ds5NXv8xJssyNDa741KeSV69AR6U8cVgr+pXS+vpfpoS4Y8i+5k
+Pvxdh9CrFx552wEEPYLH1h/Gi4swgpnysaVfG8Zl7ZoLzN/4KlA79tGSQzZn9N9E
++6fLF2hLSsGfo9Kc+Ua1Maz+4RC6AfbzllmST/7aAbJV20F8EtxnipEqL9QW9Crm
++hkZmQY4k3OWqLR1Jt4Xzs/QY9MVsbQYD0cvpb/ic1p9tIwZ6CvCXh+VAPIkK8tV
+n27Cfhw6Y+Fdf7wAhS1RFGLVoQDcJrfEoyD8XbphkXO02u5Nq50DUGDym3dhLOVa
+34v0zZU/QJnxA84LkQgrv/CM+l6/eWqaE5suQyOfU63bpQl4OVrlRjEXnfnTyKaG
+m6otQjtSB5zFAAowUkGv
+=hsB/
+-END PGP SIGNATURE-

Added: dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.md5
==
--- dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.md5 (added)
+++ dev/tomcat/tomcat-7/v7.0.47/src/apache-tomcat-7.0.47-src.zip.md5 Fri Oct 18 
10:50:02 2013
@@ -0,0 +1 @@
+6a1f93cbef8dd98bdd4e02eb3a9ffbb3 *apache-tomcat-7.0.47-src.zip
\ No newline at end of file



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

2013-10-18 Thread Yoav Shapira 
On Wed, Oct 16, 2013 at 2:21 PM, Mark Thomas  wrote:
> The proposed 8.0.0-RC5 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 8.0.0-RC5 alpha

Yoav

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

2013-10-18 Thread Ognjen Blagojevic 

Mark,

On 16.10.2013 20:21, Mark Thomas wrote:

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

...

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


Tested .zip distribution on Windows 7 64-bit, and .tar.gz on CentOS 5 
64-bit:


- Tested SSL/TLS connectivity for BIO, NIO and APR connectors (Windows).

- Crawled all links (except /manager, /host-manager and 
/examples/async*). No broken links found, except links to JavaDocs 
(Windows).


- Smoke tests of BIO, NIO and APR, with and without TLS, all passed 
(Windows).


- Tested with several webapps that are in active development (Linux).


-Ognjen


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

[Bug 55664] [websocket] NPE in Util$DecoderMatch during application start

2013-10-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55664

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 OS||All

--- Comment #1 from Mark Thomas  ---
Thanks for the report and the test case.

I have fixed this in 8.0.x for 8.0.0-RC6 onwards and in 7.0.x for 7.0.48
onwards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1533350 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

2013-10-18 Thread markt 
Author: markt
Date: Fri Oct 18 07:44:43 2013
New Revision: 1533350

URL: http://svn.apache.org/r1533350
Log:
Provide credit for the test case.

Modified:
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

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=1533350&r1=1533349&r2=1533350&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Fri Oct 18 07:44:43 2013
@@ -66,7 +66,8 @@
   
 55664: Correctly handle JSR 356 WebSocket Encoder, Decoder
 and MessageHandler implementations that use a generic type such as
-Encoder.Text>. (markt)
+Encoder.Text>. Includes a test
+case by Niki Dokovski. (markt)
   
 
   



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

svn commit: r1533349 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/websocket/Util.java test/org/apache/tomcat/websocket/TestUtil.java test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding

2013-10-18 Thread markt 
Author: markt
Date: Fri Oct 18 07:43:42 2013
New Revision: 1533349

URL: http://svn.apache.org/r1533349
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55664
Correctly handle Encoder, Decoder and MessageHandler implementations that use a 
generic type such as Encoder.Text>

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/Util.java
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestUtil.java

tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1533347

Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/Util.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/Util.java?rev=1533349&r1=1533348&r2=1533349&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/Util.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/Util.java Fri Oct 18 
07:43:42 2013
@@ -164,8 +164,8 @@ public class Util {
 }
 
 
-public static Class getDecoderType(Class Decoder) {
-return (Class) Util.getGenericType(Decoder.class, Decoder);
+public static Class getDecoderType(Class decoder) {
+return (Class) Util.getGenericType(Decoder.class, decoder);
 }
 
 
@@ -229,6 +229,8 @@ public class Util {
 private static Object getTypeParameter(Class clazz, Type argType) {
 if (argType instanceof Class) {
 return argType;
+} else if (argType instanceof ParameterizedType) {
+return ((ParameterizedType) argType).getRawType();
 } else {
 TypeVariable[] tvs = clazz.getTypeParameters();
 for (int i = 0; i < tvs.length; i++) {

Modified: tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestUtil.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestUtil.java?rev=1533349&r1=1533348&r2=1533349&view=diff
==
--- tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestUtil.java 
(original)
+++ tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestUtil.java Fri Oct 
18 07:43:42 2013
@@ -16,6 +16,8 @@
  */
 package org.apache.tomcat.websocket;
 
+import java.util.List;
+
 import javax.websocket.EncodeException;
 import javax.websocket.Encoder;
 import javax.websocket.EndpointConfig;
@@ -101,6 +103,13 @@ public class TestUtil {
 }
 
 
+@Test
+public void testGetEncoderTypeSimpleWithGenericType() {
+Assert.assertEquals(List.class,
+Util.getEncoderType(SimpleEncoderWithGenericType.class));
+}
+
+
 private static class SimpleMessageHandler
 implements MessageHandler.Whole {
 @Override
@@ -281,4 +290,24 @@ public class TestUtil {
 // NO-OP
 }
 }
+
+
+private static class SimpleEncoderWithGenericType
+implements Encoder.Text> {
+
+@Override
+public void init(EndpointConfig endpointConfig) {
+// NO-OP
+}
+
+@Override
+public void destroy() {
+// NO-OP
+}
+
+@Override
+public String encode(List object) throws EncodeException {
+return null;
+}
+}
 }

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java?rev=1533349&r1=1533348&r2=1533349&view=diff
==
--- 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
 Fri Oct 18 07:43:42 2013
@@ -46,7 +46,6 @@ import javax.websocket.server.ServerCont
 import javax.websocket.server.ServerEndpoint;
 import javax.websocket.server.ServerEndpointConfig;
 
-
 import org.junit.Assert;
 import org.junit.Test;
 
@@ -64,6 +63,7 @@ public class TestEncodingDecoding extend
 private static final String MESSAGE_ONE = "message-one";
 private static final String PATH_PROGRAMMATIC_EP = "/echoProgrammaticEP";
 private static final String PATH_ANNOTATED_EP = "/echoAnnotatedEP";
+private static final String PATH_GENERICS_EP = "/echoGenericsEP";
 
 
 @Test
@@ -174,6 +174,56 @@ public class TestEncodingDecoding extend
 }
 
 
+@Test
+public void testGenericsCoders() throws Exception {
+// Set up utility classes
+GenericsServer server = new GenericsServer();
+SingletonConfigurator.setInstance(server);
+Se

svn commit: r1533347 - in /tomcat/trunk: java/org/apache/tomcat/websocket/Util.java test/org/apache/tomcat/websocket/TestUtil.java test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java

2013-10-18 Thread markt 
Author: markt
Date: Fri Oct 18 07:40:00 2013
New Revision: 1533347

URL: http://svn.apache.org/r1533347
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55664
Correctly handle Encoder, Decoder and MessageHandler implementations that use a 
generic type such as Encoder.Text>

Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/Util.java
tomcat/trunk/test/org/apache/tomcat/websocket/TestUtil.java
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java

Modified: tomcat/trunk/java/org/apache/tomcat/websocket/Util.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/Util.java?rev=1533347&r1=1533346&r2=1533347&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/Util.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/Util.java Fri Oct 18 07:40:00 
2013
@@ -164,8 +164,8 @@ public class Util {
 }
 
 
-public static Class getDecoderType(Class Decoder) {
-return (Class) Util.getGenericType(Decoder.class, Decoder);
+public static Class getDecoderType(Class decoder) {
+return (Class) Util.getGenericType(Decoder.class, decoder);
 }
 
 
@@ -229,6 +229,8 @@ public class Util {
 private static Object getTypeParameter(Class clazz, Type argType) {
 if (argType instanceof Class) {
 return argType;
+} else if (argType instanceof ParameterizedType) {
+return ((ParameterizedType) argType).getRawType();
 } else {
 TypeVariable[] tvs = clazz.getTypeParameters();
 for (int i = 0; i < tvs.length; i++) {

Modified: tomcat/trunk/test/org/apache/tomcat/websocket/TestUtil.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TestUtil.java?rev=1533347&r1=1533346&r2=1533347&view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/websocket/TestUtil.java (original)
+++ tomcat/trunk/test/org/apache/tomcat/websocket/TestUtil.java Fri Oct 18 
07:40:00 2013
@@ -16,6 +16,8 @@
  */
 package org.apache.tomcat.websocket;
 
+import java.util.List;
+
 import javax.websocket.EncodeException;
 import javax.websocket.Encoder;
 import javax.websocket.EndpointConfig;
@@ -101,6 +103,13 @@ public class TestUtil {
 }
 
 
+@Test
+public void testGetEncoderTypeSimpleWithGenericType() {
+Assert.assertEquals(List.class,
+Util.getEncoderType(SimpleEncoderWithGenericType.class));
+}
+
+
 private static class SimpleMessageHandler
 implements MessageHandler.Whole {
 @Override
@@ -281,4 +290,24 @@ public class TestUtil {
 // NO-OP
 }
 }
+
+
+private static class SimpleEncoderWithGenericType
+implements Encoder.Text> {
+
+@Override
+public void init(EndpointConfig endpointConfig) {
+// NO-OP
+}
+
+@Override
+public void destroy() {
+// NO-OP
+}
+
+@Override
+public String encode(List object) throws EncodeException {
+return null;
+}
+}
 }

Modified: 
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java?rev=1533347&r1=1533346&r2=1533347&view=diff
==
--- 
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
(original)
+++ 
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
Fri Oct 18 07:40:00 2013
@@ -46,7 +46,6 @@ import javax.websocket.server.ServerCont
 import javax.websocket.server.ServerEndpoint;
 import javax.websocket.server.ServerEndpointConfig;
 
-
 import org.junit.Assert;
 import org.junit.Test;
 
@@ -64,6 +63,7 @@ public class TestEncodingDecoding extend
 private static final String MESSAGE_ONE = "message-one";
 private static final String PATH_PROGRAMMATIC_EP = "/echoProgrammaticEP";
 private static final String PATH_ANNOTATED_EP = "/echoAnnotatedEP";
+private static final String PATH_GENERICS_EP = "/echoGenericsEP";
 
 
 @Test
@@ -174,6 +174,56 @@ public class TestEncodingDecoding extend
 }
 
 
+@Test
+public void testGenericsCoders() throws Exception {
+// Set up utility classes
+GenericsServer server = new GenericsServer();
+SingletonConfigurator.setInstance(server);
+ServerConfigListener.setPojoClazz(GenericsServer.class);
+
+Tomcat tomcat = getTomcatInstance();
+// Must have a real docBase - just use temp
+Context ctx =
+tomcat.addContext("", System.getProperty("java.io.tmpdir"));
+ctx.addApplicationListener(new ApplicationListener(
+ServerConfigListener.class.getName(),