https://issues.apache.org/bugzilla/show_bug.cgi?id=55570
--- Comment #2 from Sander ---
thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55588
Bug ID: 55588
Summary: Tomcat randomly crashes with
[libtcnative-1.so+0x12e39]
Java_org_apache_tomcat_jni_Socket_sendbb+0x59
Product: Tomcat Native
Version:
I already explained how t8 loader and WebResource breaks libs based on std
URLClassLoader
Here is the class in xbean
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/main/java/org/apache/xbean/finder/ClassLoaders.java
I know we can workaround it but then we miss classes in th
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project tomcat-trunk-test has an issue affecting its community integration.
This i
The Buildbot has detected a new failure on builder tomcat-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/4999
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: bb-vm_ubuntu
Build Reason: scheduler
Build Source St
All,
On 9/23/13 4:58 PM, Christopher Schultz wrote:
> Someone recently on the users list[1] had some trouble building mod_jk
> and it turned out that the problem was a missing c++ compiler.
>
> I did some quick checking and it doesn't look like mod_jk requires a c++
> compiler for any actual comp
Chuck,
On 9/23/13 5:09 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Why does mod_jk require a C++ compiler instead of just C?
>
>> everything is declared as "extern C"
>
> Wouldn't such declarations require a C++ compiler? I don
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Why does mod_jk require a C++ compiler instead of just C?
> everything is declared as "extern C"
Wouldn't such declarations require a C++ compiler? I don't think C can parse
that. Perhaps the fix would be to wrapper
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Author: violetagg
Date: Mon Sep 23 21:02:01 2013
New Revision: 1525703
URL: http://svn.apache.org/r1525703
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.propert
On 23/09/2013 13:47, Nick Williams wrote:
tldr: I'd say that is a WebLogic bug
> This is very off topic, and for that I apologize. I'm working on
> fixing a bug in Log4j 2, and we've discovered something that just
> doesn't make any sense to me. I /believe/ it's a problem with
> WebLogic's implem
All,
Someone recently on the users list[1] had some trouble building mod_jk
and it turned out that the problem was a missing c++ compiler.
I did some quick checking and it doesn't look like mod_jk requires a c++
compiler for any actual compilation -- that is, everything is declared
as "extern C"
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
Author: markt
Date: Mon Sep 23 20:52:58 2013
New Revision: 1525696
URL: http://svn.apache.org/r1525696
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
Preserve the order that request parameters were presented by the client.
Modified:
tomcat/trunk/java/org/apache/catalina/uti
This is very off topic, and for that I apologize. I'm working on fixing a bug
in Log4j 2, and we've discovered something that just doesn't make any sense to
me. I /believe/ it's a problem with WebLogic's implementation of the Servlet
3.0 specification, but I could be wrong, and based on my previ
Author: markt
Date: Mon Sep 23 20:44:33 2013
New Revision: 2955
Log:
Release Apache Tomcat 8.0.0-RC3
Added:
release/tomcat/tomcat-8/v8.0.0-RC3/
- copied from r2954, dev/tomcat/tomcat-8/v8.0.0-RC3/
Removed:
dev/tomcat/tomcat-8/v8.0.0-RC3/
---
Author: markt
Date: Mon Sep 23 20:44:33 2013
New Revision: 2955
Log:
Release Apache Tomcat 8.0.0-RC3
Added:
release/tomcat/tomcat-8/v8.0.0-RC3/
- copied from r2954, dev/tomcat/tomcat-8/v8.0.0-RC3/
Removed:
dev/tomcat/tomcat-8/v8.0.0-RC3/
---
+1 (alpha) : binding - markt, schultz, rjung, jfarcand
non-binding - Martin Grigorov
No other votes were cast. The vote therefore passes.
I'll start the process of releasing the bits.
Mark
-
To unsubscribe, e-mail:
Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc
==
--- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc (added)
+++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.
On 23/09/2013 13:29, Romain Manni-Bucau wrote:
> Xbean (so openwebbeans), groovy (so spring lang, groovy etc...)
That doesn't help. It needs to be of the form "With Tomcat 7 we got...
but with Tomcat 8 we get...".
It might also need a "and it doesn't work because..." depending on how
obvious
Xbean (so openwebbeans), groovy (so spring lang, groovy etc...)
Le 23 sept. 2013 22:27, "Mark Thomas" a écrit :
> On 23/09/2013 13:21, Romain Manni-Bucau wrote:
> > The main issue of t8 is it breaks some scanning features when relying on
> > URLClassLoader (getURLs()), not perfect but common
Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc
==
--- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc (added)
+++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.
On 23/09/2013 13:21, Romain Manni-Bucau wrote:
> The main issue of t8 is it breaks some scanning features when relying on
> URLClassLoader (getURLs()), not perfect but common in libs...
Example(s) please.
Mark
-
To unsubscribe,
The main issue of t8 is it breaks some scanning features when relying on
URLClassLoader (getURLs()), not perfect but common in libs...
Le 23 sept. 2013 19:00, "Mark Thomas" a écrit :
> On 23/09/2013 09:08, Rainer Jung wrote:
> > On 23.09.2013 17:27, Mark Thomas wrote:
> >> I've mentioned on a cou
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
--- Comment #6 from mgrigorov ---
In my opinion this requirement and the use case are weak.
In the best case I'd try to avoid depending on any ordering in the application.
But if ordering is really required then I would encode the paramet
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
Mark Thomas changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving this mail
Author: violetagg
Date: Mon Sep 23 19:37:37 2013
New Revision: 1525678
URL: http://svn.apache.org/r1525678
Log:
Tag 7.0.44
Added:
tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ (props changed)
- copied from r1525674, tomcat/tc7.0.x/trunk/
Modified:
tomcat/tc7.0.x/tags/TOMCAT_7_0_44/build.prop
Author: violetagg
Date: Mon Sep 23 19:32:48 2013
New Revision: 1525677
URL: http://svn.apache.org/r1525677
Log:
Remove tag TOMCAT_7_0_44 - subclipse:tags property was not removed.
Removed:
tomcat/tc7.0.x/tags/TOMCAT_7_0_44/
---
Author: violetagg
Date: Mon Sep 23 19:30:21 2013
New Revision: 1525675
URL: http://svn.apache.org/r1525675
Log:
Tag 7.0.44
Added:
tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ (props changed)
- copied from r1525674, tomcat/tc7.0.x/trunk/
Modified:
tomcat/tc7.0.x/tags/TOMCAT_7_0_44/build.prop
Hi Mark,
Unless I missed something, Websockets 1.0 on Servlet 3.1 upgrade doesn't
do much flushing, so that the IS/OS used in upgrade must effectively
just write immediately the data (and ensure it is really sent over the
wire).
I find that a bit weird, since during the design of Servlets 3.1, th
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
--- Comment #5 from corythearchit...@outlook.com ---
"Or are you building a system where the order of the parameters in the request
dictates the way validation is performed?"
Essentially, yes.
--
You are receiving this mail because:
You a
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
--- Comment #4 from Christopher Schultz ---
(In reply to corythearchitect from comment #3)
> The general use case is the servicing of a request in which the order of
> parameter evaluation is significant.
>
> http://host/resource?country=C
On 23/09/2013 09:08, Rainer Jung wrote:
> On 23.09.2013 17:27, Mark Thomas wrote:
>> I've mentioned on a couple of different threads that refactoring how the
>> class loader accesses resources was on my TODO list. I haven't done any
>> implementation yet but I have some ideas that I wanted to get s
[X] Alpha - go ahead and release as 8.0.0-RC3 alpha
Tested with Atmosphere jsr356 and Servlet 3 Async API.
-- Jeanfrancois
On 2013-09-20 6:36 AM, Mark Thomas 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 20.09.2013 12:36, Mark Thomas wrote:
> The proposed 8.0.0-RC3 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 8.0.0-RC3 alpha
+1 as alpha.
Overview:
- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src consistent with svn t
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
--- Comment #3 from corythearchit...@outlook.com ---
Thomas, thank you for your rapid evaluation and response on this matter.
The general use case is the servicing of a request in which the order of
parameter evaluation is significant.
htt
On 23.09.2013 14:44, Christopher Schultz wrote:
> Mark,
>
> On 9/20/13 7:05 AM, Mark Thomas wrote:
>> On 20/09/2013 11:57, Jeanfrancois Arcand wrote:
>>>
>>> On 2013-09-20 6:26 AM, Mark Thomas wrote:
On 20/09/2013 11:24, Jeanfrancois Arcand wrote:
> Hi,
>
> [X] Broken - do not rel
On 23.09.2013 17:27, Mark Thomas wrote:
> I've mentioned on a couple of different threads that refactoring how the
> class loader accesses resources was on my TODO list. I haven't done any
> implementation yet but I have some ideas that I wanted to get some
> feedback on before I start work.
>
> T
I've mentioned on a couple of different threads that refactoring how the
class loader accesses resources was on my TODO list. I haven't done any
implementation yet but I have some ideas that I wanted to get some
feedback on before I start work.
The things I have in mind at this point are:
- Extrac
Mark,
On 9/20/13 6:36 AM, Mark Thomas 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
--- Comment #2 from Christopher Schultz ---
(In reply to Mark Thomas from comment #1)
> I am curious as to the use case that supports it. Can you elaborate on why
> it might be important for the parameters to be returned in the same order a
Author: markt
Date: Mon Sep 23 13:58:50 2013
New Revision: 1525595
URL: http://svn.apache.org/r1525595
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582
Correct concurrency issue that can result in two instances of JspServletWrapper
being created for one tag.
Patch provided by Sheldon
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Author: markt
Date: Mon Sep 23 13:54:31 2013
New Revision: 1525593
URL: http://svn.apache.org/r1525593
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582
Correct concurrency issue that can result in two instances of JspServletWrapper
being created for one tag.
Patch provided by Sheldon
On Fri, Sep 20, 2013 at 12:36 PM, Mark Thomas 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 implemen
2013/9/20 Mark Thomas
>
> 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 variou
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
OS|
On 23/09/2013 06:20, Henri Gomez wrote:
> Hi Mark
>
> What kind of tests, specific to TC 8.0 are awaited to 'qualify' ?
Not sure what you mean.
The only tests we have are the unit tests. We do not have access to the
Java EE 7 TCKs.
In terms of this release, I am personally happy if the unit tes
Hi Mark
What kind of tests, specific to TC 8.0 are awaited to 'qualify' ?
2013/9/23 Mark Thomas
> On 20/09/2013 12:35, Mark Thomas wrote:
> > On 20/09/2013 11:36, Mark Thomas wrote:
> >> The proposed Apache Tomcat 8.0.0 release candidate 3 is now available
> >> for voting.
> >>
> >> Given this
On 20/09/2013 12:35, Mark Thomas wrote:
> On 20/09/2013 11:36, Mark Thomas 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 RC
Mark,
On 9/20/13 7:05 AM, Mark Thomas wrote:
> On 20/09/2013 11:57, Jeanfrancois Arcand wrote:
>>
>> On 2013-09-20 6:26 AM, Mark Thomas wrote:
>>> On 20/09/2013 11:24, Jeanfrancois Arcand wrote:
Hi,
[X] Broken - do not release
I do test/use Tomcat with WebSocket since 7.0.
On 22/09/2013 10:55, Jeremy Boynes wrote:
> On Sep 22, 2013, at 1:44 AM, Mark Thomas wrote:
>
>> On 22/09/2013 00:27, Jeremy Boynes wrote:
>>
>>> As a concrete example of how this impacts the behaviour, consider
>>> the case where the application includes its own JSP engine. With
>>> the RI's de
Author: markt
Date: Mon Sep 23 11:02:18 2013
New Revision: 1525548
URL: http://svn.apache.org/r1525548
Log:
ServerContainerProvider was removed from JSR-356
Removed:
tomcat/tc7.0.x/trunk/res/META-INF/tomcat7-websocket.jar/services/javax.websocket.server.ServerContainerProvider
Author: markt
Date: Mon Sep 23 11:00:19 2013
New Revision: 1525547
URL: http://svn.apache.org/r1525547
Log:
ServerContainerProvider was removed from JSR-356
Removed:
tomcat/trunk/res/META-INF/tomcat-websocket.jar/services/javax.websocket.server.ServerContainerProvider
-
On 09/23/2013 09:54 AM, Rainer Jung wrote:
On 23.09.2013 07:27, Mladen Turk wrote:
The patch seems fine. I mean any return value should do in theory.
The main question is why is particular socket removed twice
from the Poller.
I agree that there's probably another problem further up the sta
Author: rjung
Date: Mon Sep 23 08:08:56 2013
New Revision: 1525525
URL: http://svn.apache.org/r1525525
Log:
Change return code when removing a socket from a poller, that was
actually not in the poller from APR_SUCCESS to APR_NOTFOUND.
This lead to corrupt poller handling in the Tomcat APR connect
On 23.09.2013 07:27, Mladen Turk wrote:
> On 09/22/2013 03:39 PM, Rainer Jung wrote:
>> On 22.09.2013 13:17, Rainer Jung wrote:
>>> I debugged around my occasional failures for TestCoyoteAdapter when
>>> using APR.
>>>
>>> Error is:
>>>
>>> SEVERE [http-apr-127.0.0.1-auto-13-Poller]
>>> org.apache.
57 matches
Mail list logo
