DO NOT REPLY [Bug 50504] New: Allow setting query string character set trough request attribute
https://issues.apache.org/bugzilla/show_bug.cgi?id=50504 Summary: Allow setting query string character set trough request attribute Product: Tomcat 7 Version: 7.0.5 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: kiralyattila...@gmail.com Currently tomcat is using ISO-8859-1 by default to decode query parameters. This can be modified with connector attributes like URIEncoding and useBodyEncodingForURI, however these are server wide settings and affect every web application served trough that connector. I suggest an alternative, optional way: to define query encoding with a special request attribute. It has the benefit that it allows to use different query parameter encoding per web application (per request). So a new application can use UTF-8 without effecting old ones. Jetty has a similar approach: it is using org.eclipse.jetty.server.Request.queryEncoding for that (however in Jetty UTF-8 is the default encoding for query parameters). This is also similar to how content type charset is set for UTF-8 POST-s (using request.setCharacterEncoding()). Without this in mixed environments (where already existing applications are served with the default settings of tomcat) new, UTF-8 based applications can not use query parameters because browsers are using the served html page's character set to encode query parameters (the same they are doing with POST bodies). I am attaching a patch containing the suggested changes with a new junit test. I named the special request attribute org.apache.tomcat.request.query_encoding. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50504] Allow setting query string character set trough request attribute
https://issues.apache.org/bugzilla/show_bug.cgi?id=50504 --- Comment #1 from Attila Király kiralyattila...@gmail.com 2010-12-21 04:17:22 EST --- Created an attachment (id=26432) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26432) Patch implementing the suggestion + junit test Attaching patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50504] Allow setting query string character set trough request attribute
https://issues.apache.org/bugzilla/show_bug.cgi?id=50504 Attila Király kiralyattila...@gmail.com changed: What|Removed |Added CC||kiralyattila...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50342] Exception on the Host request-header field included colon(':')
https://issues.apache.org/bugzilla/show_bug.cgi?id=50342 --- Comment #4 from Kim Yong Hwan kni...@nhn.com 2010-12-21 04:40:46 EST --- Could you give more information when java.io.CharConversionException is thrown. In present, I do not know why the exception is thrown and what character is transfered from client. So, I hope to add a information below. in org.apache.jk.commo.HandlerRequest.java in present : throw new CharConversionException(Invalid char in port: + valueB[i + valueS]); to be : throw new CharConversionException(Invalid char in port: + valueB[i + valueS] + , invalid string is + new String(valueB)); -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1051433 - in /tomcat/trunk/java/org/apache/catalina/loader: LocalStrings.properties WebappClassLoader.java
Author: kfujino
Date: Tue Dec 21 09:47:15 2010
New Revision: 1051433
URL: http://svn.apache.org/viewvc?rev=1051433view=rev
Log:
Fix webappClassLoader.clearJbdc message key and message in
LocalStrings.properties.
Jbdc is corrected to jdbc.
Modified:
tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=1051433r1=1051432r2=1051433view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties Tue
Dec 21 09:47:15 2010
@@ -39,7 +39,7 @@ webappClassLoader.jdbcRemoveFailed=JDBC
webappClassLoader.jdbcRemoveStreamError=Exception closing input stream during
JDBC driver de-registration for web application [{0}]
webappClassLoader.stopped=Illegal access: this web application instance has
been stopped already. Could not load {0}. The eventual following stack trace
is caused by an error thrown for debugging purposes as well as to attempt to
terminate the thread which caused the illegal access, and has no functional
impact.
webappClassLoader.readError=Resource read error: Could not load {0}.
-webappClassLoader.clearJbdc=The web application [{0}] registered the JBDC
driver [{1}] but failed to unregister it when the web application was stopped.
To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
+webappClassLoader.clearJdbc=The web application [{0}] registered the JDBC
driver [{1}] but failed to unregister it when the web application was stopped.
To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
webappClassLoader.clearReferencesResourceBundlesCount=Removed [{0}]
ResourceBundle references from the cache for web application [{1}]
webappClassLoader.clearReferencesResourceBundlesFail=Failed to clear
ResourceBundle references for web application [{0}]
webappClassLoader.clearRmiInfo=Failed to find class sun.rmi.transport.Target
to clear context class loader for web application [{0}]. This is expected on
non-Sun JVMs.
Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=1051433r1=1051432r2=1051433view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Tue Dec
21 09:47:15 2010
@@ -1999,7 +1999,7 @@ public class WebappClassLoader
ListString driverNames = (ListString) obj.getClass().getMethod(
clearJdbcDriverRegistrations).invoke(obj);
for (String name : driverNames) {
-log.error(sm.getString(webappClassLoader.clearJbdc,
+log.error(sm.getString(webappClassLoader.clearJdbc,
contextName, name));
}
} catch (Exception e) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50505] New: 505 HTTP Version Not Supported
https://issues.apache.org/bugzilla/show_bug.cgi?id=50505
Summary: 505 HTTP Version Not Supported
Product: Tomcat 6
Version: 6.0.29
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
AssignedTo: dev@tomcat.apache.org
ReportedBy: kni...@nhn.com
My Service used CometProcessor, using tomcat 6.0.29 server.
505 HTTP Version Not Supported error happened.
So, I changed to tomcat 6.0.20 server instead of 6.0.29. There is no error.
I did not change any configuration and just changed tomcat server.
in server.xml
Connector acceptorThreadCount=4 socket.tcpNoDelay=true
connectionTimeout=2
port=10129 maxThreads=512 backlog=1000
protocol=org.apache.coyote.http11.Http11NioProtocol
useComet=true redirectPort=8443 /
I saw the HTTP11NioProtocol
source(java\org\apache\coyote\http11\Http11NioProtocol.java) and found
difference of Http11NioProtocol.java between tomcat 6.0.20 and 6.0.29.
in Http11NioProtocol.java
public SocketState process(NioChannel socket) {
..
if (processor.comet) {
NioEndpoint.KeyAttachment att =
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
socket.getPoller().add(socket,att.getCometOps());
} else {
release(socket); == 6.0.29 added
socket.getPoller().add(socket);
}
..
}
is it possible to 505 error when releasing socket???
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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: r1051439 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
Author: kfujino
Date: Tue Dec 21 10:00:12 2010
New Revision: 1051439
URL: http://svn.apache.org/viewvc?rev=1051439view=rev
Log:
Backport r1051433 from trunk.
This rev is a correction only of message.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=1051439r1=1051438r2=1051439view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
Tue Dec 21 10:00:12 2010
@@ -39,7 +39,7 @@ webappClassLoader.jdbcRemoveFailed=JDBC
webappClassLoader.jdbcRemoveStreamError=Exception closing input stream during
JDBC driver de-registration for web application [{0}]
webappClassLoader.stopped=Illegal access: this web application instance has
been stopped already. Could not load {0}. The eventual following stack trace
is caused by an error thrown for debugging purposes as well as to attempt to
terminate the thread which caused the illegal access, and has no functional
impact.
webappClassLoader.readError=Resource read error: Could not load {0}.
-webappClassLoader.clearJbdc=The web application [{0}] registered the JBDC
driver [{1}] but failed to unregister it when the web application was stopped.
To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
+webappClassLoader.clearJbdc=The web application [{0}] registered the JDBC
driver [{1}] but failed to unregister it when the web application was stopped.
To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
webappClassLoader.clearReferencesResourceBundlesCount=Removed [{0}]
ResourceBundle references from the cache for web application [{1}]
webappClassLoader.clearReferencesResourceBundlesFail=Failed to clear
ResourceBundle references for web application [{0}]
webappClassLoader.clearRmiInfo=Failed to find class sun.rmi.transport.Target
to clear context class loader for web application [{0}]. This is expected on
non-Sun JVMs.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-6-trunk
The Buildbot has detected a restored build of tomcat-6-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-6-trunk/builds/173 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: Build Source Stamp: [branch tomcat/tc6.0.x/trunk] 1051439 Blamelist: kfujino,kkolinko,slaurent Build succeeded! sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1051539 - /tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
Author: fhanik
Date: Tue Dec 21 16:14:24 2010
New Revision: 1051539
URL: http://svn.apache.org/viewvc?rev=1051539view=rev
Log:
make shared variable volatile
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java?rev=1051539r1=1051538r2=1051539view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java Tue Dec
21 16:14:24 2010
@@ -49,7 +49,7 @@ public class CounterLatch {
private final Sync sync;
private final AtomicLong count;
-private long signal;
+private volatile long signal;
private volatile boolean released = false;
/**
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1051540 - /tomcat/trunk/build.xml
Author: fhanik
Date: Tue Dec 21 16:15:16 2010
New Revision: 1051540
URL: http://svn.apache.org/viewvc?rev=1051540view=rev
Log:
Allow to specify the test on the command line
ant -Dtest.name=**/TestMax** test
Without the parameter, the default is all tests as specified before
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1051540r1=1051539r2=1051540view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Tue Dec 21 16:15:16 2010
@@ -141,6 +141,8 @@
property name=catalina-jmx-remote-src.jar
value=${tomcat.extras.sources}/catalina-jmx-remote-src.jar/
property name=tomcat-embed-log4j-src.jar
value=${tomcat.embed.sources}/tomcat-embed-logging-log4j-src.jar/
+ !-- Tests To Run --
+ property name=test.name value=**/Test*.java/
!-- Classpaths --
path id=compile.classpath
pathelement location=${jdt.jar}/
@@ -1063,7 +1065,7 @@
haltonfailure=${test.haltonfailure}
fileset dir=test
!-- Include all by default --
-include name=**/Test*.java /
+include name=${test.name} /
!-- Exclude helper classes --
exclude name=**/Tester*.java /
!-- Exclude the tests known to fail --
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1051576 - /tomcat/trunk/build.xml
Author: fhanik
Date: Tue Dec 21 17:39:11 2010
New Revision: 1051576
URL: http://svn.apache.org/viewvc?rev=1051576view=rev
Log:
Allow to set log formatter when running Junit tests
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1051576r1=1051575r2=1051576view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Tue Dec 21 17:39:11 2010
@@ -143,6 +143,8 @@
!-- Tests To Run --
property name=test.name value=**/Test*.java/
+ property name=test.formatter
value=-Dorg.apache.juli.formatter=java.util.logging.SimpleFormatter/
+
!-- Classpaths --
path id=compile.classpath
pathelement location=${jdt.jar}/
@@ -1047,6 +1049,7 @@
junit printsummary=yes fork=yes dir=. showoutput=yes
jvmarg value=-Djava.library.path=${test.apr.loc}/
+jvmarg value=${test.formatter}/
classpath refid=tomcat.test.classpath /
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1051577 - /tomcat/trunk/modules/jdbc-pool/.classpath
Author: fhanik Date: Tue Dec 21 17:40:34 2010 New Revision: 1051577 URL: http://svn.apache.org/viewvc?rev=1051577view=rev Log: Fix classpath Modified: tomcat/trunk/modules/jdbc-pool/.classpath Modified: tomcat/trunk/modules/jdbc-pool/.classpath URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/.classpath?rev=1051577r1=1051576r2=1051577view=diff == --- tomcat/trunk/modules/jdbc-pool/.classpath (original) +++ tomcat/trunk/modules/jdbc-pool/.classpath Tue Dec 21 17:40:34 2010 @@ -2,9 +2,9 @@ classpath classpathentry kind=src path=java/ classpathentry kind=src path=test/ - classpathentry combineaccessrules=false kind=src path=/tomcat-trunk/ classpathentry kind=con path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/ - classpathentry kind=var path=TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/tomcat-dbcp.jar sourcepath=/TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/src/java/ + classpathentry kind=var path=TOMCAT_LIBS_BASE/tomcat7-deps/dbcp/tomcat-dbcp.jar sourcepath=/TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/src/java/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ + classpathentry combineaccessrules=false kind=src path=/tomcat-7.0.x/ classpathentry kind=output path=bin/ /classpath - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1051578 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AbstractEndpoint.java AprEndpoint.java JIoEndpoint.java NioEndpoint.java
Author: fhanik
Date: Tue Dec 21 17:40:57 2010
New Revision: 1051578
URL: http://svn.apache.org/viewvc?rev=1051578view=rev
Log:
refactor latch usage, since its shared by all connectors
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1051578r1=1051577r2=1051578view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Tue Dec
21 17:40:57 2010
@@ -126,7 +126,7 @@ public abstract class AbstractEndpoint {
/**
* counter for nr of connections handled by an endpoint
*/
-protected volatile CounterLatch connectionCounterLatch = null;
+private volatile CounterLatch connectionCounterLatch = null;
/**
* Socket properties
@@ -576,6 +576,43 @@ public abstract class AbstractEndpoint {
protected abstract Log getLog();
public abstract boolean getUseSendfile();
+
+protected CounterLatch initializeConnectionLatch() {
+if (connectionCounterLatch==null) {
+connectionCounterLatch = new CounterLatch(0,getMaxConnections());
+}
+return connectionCounterLatch;
+}
+
+protected void releaseConnectionLatch() {
+CounterLatch latch = connectionCounterLatch;
+if (latch!=null) latch.releaseAll();
+connectionCounterLatch = null;
+}
+
+protected void awaitConnection() throws InterruptedException {
+CounterLatch latch = connectionCounterLatch;
+if (latch!=null) latch.await();
+}
+
+protected long countUpConnection() {
+CounterLatch latch = connectionCounterLatch;
+if (latch!=null) return latch.countUp();
+else return -1;
+}
+
+protected long countDownConnection() {
+CounterLatch latch = connectionCounterLatch;
+if (latch!=null) {
+long result = latch.countDown();
+if (result0) {
+getLog().warn(Incorrect connection count, multiple
socket.close called on the same socket. );
+}
+return result;
+} else return -1;
+}
+
+
// SSL related properties
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1051578r1=1051577r2=1051578view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Dec 21
17:40:57 2010
@@ -40,6 +40,7 @@ import org.apache.tomcat.jni.SSLSocket;
import org.apache.tomcat.jni.Socket;
import org.apache.tomcat.jni.Status;
import org.apache.tomcat.util.ExceptionUtils;
+import org.apache.tomcat.util.threads.CounterLatch;
/**
@@ -531,6 +532,8 @@ public class AprEndpoint extends Abstrac
if (getExecutor() == null) {
createExecutor();
}
+
+initializeConnectionLatch();
// Start poller threads
pollers = new Poller[pollerThreadCount];
@@ -592,6 +595,7 @@ public class AprEndpoint extends Abstrac
*/
@Override
public void stopInternal() {
+releaseConnectionLatch();
if (!paused) {
pause();
}
@@ -885,6 +889,7 @@ public class AprEndpoint extends Abstrac
// parent pool or acceptor socket.
// In any case disable double free which would cause JVM core.
Socket.destroy(socket);
+countDownConnection();
}
}
@@ -926,8 +931,12 @@ public class AprEndpoint extends Abstrac
break;
}
try {
+//if we have reached max connections, wait
+awaitConnection();
// Accept the next incoming connection from the server
socket
long socket = Socket.accept(serverSock);
+//increment socket count
+countUpConnection();
/*
* In the case of a deferred accept unlockAccept needs to
* send data. This data will be rubbish, so destroy the
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
URL:
svn commit: r1051682 - in /tomcat/trunk/java/org/apache/tomcat/util/threads: LocalStrings.properties ThreadPoolExecutor.java res/LocalStrings.properties res/LocalStrings_es.properties res/LocalStrings
Author: slaurent
Date: Tue Dec 21 22:26:55 2010
New Revision: 1051682
URL: http://svn.apache.org/viewvc?rev=1051682view=rev
Log:
bug 49159: Improve ThreadLocal memory leak clean-up
https://issues.apache.org/bugzilla/show_bug.cgi?id=49159
- merged LocalStrings.properties file from package o.a.t.u.threads to
o.a.t.u.threads.res
- removed 3 i18n keys that are no longer used by tc7. They were used by the old
ThreadPool implementation of tc6
Removed:
tomcat/trunk/java/org/apache/tomcat/util/threads/LocalStrings.properties
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_es.properties
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_fr.properties
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_ja.properties
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java?rev=1051682r1=1051681r2=1051682view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
Tue Dec 21 22:26:55 2010
@@ -42,7 +42,7 @@ public class ThreadPoolExecutor extends
* The string manager for this package.
*/
protected static final StringManager sm = StringManager
-.getManager(Constants.Package);
+.getManager(org.apache.tomcat.util.threads.res);
private static final Log log = LogFactory.getLog(ThreadPoolExecutor.class);
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings.properties?rev=1051682r1=1051681r2=1051682view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings.properties
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings.properties
Tue Dec 21 22:26:55 2010
@@ -13,6 +13,4 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-threadpool.busy=All threads ({0}) are currently busy, waiting. Increase
maxThreads ({1}) or check the servlet status
-threadpool.max_threads_too_low=maxThreads setting ({0}) too low, set to {1}
-threadpool.thread_error=Caught exception ({0}) executing {1}, terminating
thread
+threadPoolExecutor.threadStoppedToAvoidPotentialLeak=Stopping thread {0} to
avoid potential memory leaks after a context was stopped.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_es.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_es.properties?rev=1051682r1=1051681r2=1051682view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_es.properties
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_es.properties
Tue Dec 21 22:26:55 2010
@@ -13,6 +13,3 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-threadpool.busy=Todos los hilos ({0}) est\u00e1n ahora ocupados, esperando.
Incremente maxThreads ({1}) o revise el estado del servlet
-threadpool.max_threads_too_low=valor de maxThreads ({0}) demasiado bajo,
puesto a {1}
-threadpool.thread_error=Cogida excepci\u00f3n ({0}) ejecutando {1}, terminando
hilo
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_fr.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_fr.properties?rev=1051682r1=1051681r2=1051682view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_fr.properties
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_fr.properties
Tue Dec 21 22:26:55 2010
@@ -13,6 +13,3 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-threadpool.busy=Tous les threads ({0}) sont actuellement occup\u00e9s,
attente. Augmentez maxThreads ({1}) ou v\u00e9rifiez le servlet status
-threadpool.max_threads_too_low=le r\u00e9glage maxThreads ({0}) est trop bas,
mis \u00e0 {1}
-threadpool.thread_error=R\u00e9ception d''une exception ({0}) en
ex\u00e9cutant {1}, arr\u00eat du thread
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/res/LocalStrings_ja.properties
URL:
DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462 --- Comment #3 from Rex Wang rwo...@gmail.com 2010-12-21 21:15:19 EST --- (In reply to comment #2) It's marked optional in Maven as it is only needed if someone is using the XML tags. Is there a way to mimic that with the OSGi references? Not sure about that. At least, IMO, that is not the correct way by using optional:=resolution in import-package to achieve the requirement. I think the optional:=resolution directive is used to express that if osgi framework can not resolve the package, the codes in this bundle may use the implementation from itself or from jdk. So if the codes have hard dependency to (explicitly import) a package, we should not make it as optional resolution. -Rex -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50414] tlv package cause another split package issue in impl and jstlel bundles
https://issues.apache.org/bugzilla/show_bug.cgi?id=50414 --- Comment #5 from Rex Wang rwo...@gmail.com 2010-12-21 21:18:04 EST --- sure. will do. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: svn commit: r1051539 - /tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
On 21 December 2010 16:14, fha...@apache.org wrote:
Author: fhanik
Date: Tue Dec 21 16:14:24 2010
New Revision: 1051539
URL: http://svn.apache.org/viewvc?rev=1051539view=rev
Log:
make shared variable volatile
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java?rev=1051539r1=1051538r2=1051539view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java Tue
Dec 21 16:14:24 2010
@@ -49,7 +49,7 @@ public class CounterLatch {
private final Sync sync;
private final AtomicLong count;
- private long signal;
+ private volatile long signal;
It would be cheaper to make it final as it's only ever set in the ctor
and is immutable.
private volatile boolean released = false;
/**
-
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
DO NOT REPLY [Bug 50064] bundle-ify the taglibs jars
https://issues.apache.org/bugzilla/show_bug.cgi?id=50064 --- Comment #10 from Rex Wang rwo...@gmail.com 2010-12-21 21:43:05 EST --- hi should we also remove the dependency in jstlel and compat? dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.7.1/version scopeprovided/scope /dependency I did not find any class import the packages from xalan in these two projects. -Rex -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50250] Split package issue in impl and jstlel bundles
https://issues.apache.org/bugzilla/show_bug.cgi?id=50250 Rex Wang rwo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Rex Wang rwo...@gmail.com 2010-12-21 21:50:04 EST --- resolved, thanks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
On Dec 21, 2010, at 6:15 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50462 --- Comment #3 from Rex Wang rwo...@gmail.com 2010-12-21 21:15:19 EST --- (In reply to comment #2) It's marked optional in Maven as it is only needed if someone is using the XML tags. Is there a way to mimic that with the OSGi references? Not sure about that. At least, IMO, that is not the correct way by using optional:=resolution in import-package to achieve the requirement. I think the optional:=resolution directive is used to express that if osgi framework can not resolve the package, the codes in this bundle may use the implementation from itself or from jdk. So if the codes have hard dependency to (explicitly import) a package, we should not make it as optional resolution. Perhaps the changes needed to address the performance issue in #27717 are relevant here. These stem from issues in Xalan's implementation which would also apply if we tried to use the JDK's implementation. I had a prototype working with Jaxen but the project is pushing builds to the Maven repos and does not seem very active (like, no-one replied to a recent committer call) so depending on it could be problematic. I was thinking of using JXPath instead (from commons). With multiple options out there, perhaps we could just have taglibs use an interface and provide wrappers for each as separate modules. if we did that, is that something that could be easily handled with OSGi? Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] XPath support
2010/10/3 Jeremy Boynes jboy...@apache.org On Jul 15, 2010, at 12:19 AM, Henri Yandell wrote: On Wed, Jul 14, 2010 at 8:45 PM, Jeremy Boynes jboy...@apache.org wrote: On Jul 12, 2010, at 7:04 PM, Jeremy Boynes wrote: I'm going to ping Xalan about the increase in time taken as expressions are evaluated as I would assume I'm doing something silly. I looked into the Xalan implementation and the problem appears to be in creation of the DTM used by the underlying implementation. To evaluate the expression it walks up the DOM tree to the parent and then iterates forward over the tree until it reaches the initial context node. This leads to a linear increase in execution time as the context node progresses through the NodeList from the forEach. I changed x:forEach and x:out to use Jaxen and did not see this issue. The execution time for xpath evalutation over 1000 iterations was constant and substantially faster than with Xalan: total of 62ms reparsing each time or 21ms if precompiled, down from 1800ms. In light of this I'd like to propose we switch to Jaxen and add it as a dependency. Absolutely: +1 Great work :) I've not committed these changes as the latest version of Jaxen is not available in the Maven repo and there did not appear to be much interest in doing so. We might be able to get similar improvements using JXPath. Could we start the release process without resolving this performance issue? If not, the servicemix bundled jaxen http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.jaxen/1.1.1_1/ might be a good choice as the dependency. -Rex -- Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Lei Wang (Rex) rwonly AT apache.org
DO NOT REPLY [Bug 50064] bundle-ify the taglibs jars
https://issues.apache.org/bugzilla/show_bug.cgi?id=50064 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Depends on||50414, 50462 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50414] tlv package cause another split package issue in impl and jstlel bundles
https://issues.apache.org/bugzilla/show_bug.cgi?id=50414 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Blocks||50064 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Blocks||50064 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50068] Memory leak with Driver registration
https://issues.apache.org/bugzilla/show_bug.cgi?id=50068 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Jeremy Boynes jboy...@apache.org 2010-12-21 22:51:28 EST --- Resolving per Henri's option 1 that this is a feature and the advice is to use a DataSource from the container rather than a raw JDBC Driver. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50263] README_src.txt out of date
https://issues.apache.org/bugzilla/show_bug.cgi?id=50263 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50511] New: WARNING about Internal Dummy Connection of Apache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50511 Summary: WARNING about Internal Dummy Connection of Apache Product: Tomcat Connectors Version: 1.2.30 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: kikuchi...@jp.fujitsu.com When my system is highly-loaded, the messeges are printed in mod_jk.log. [mod_jk.log] [Tue Dec 21 11:31:25.958 2010] [4744:3086915888] [warn] map_uri_to_worker_ext::jk_uri_worker_map.c (962): Uri * is invalid. Uri must start with / I assume the messages are caused by Internal Dummy Connection of Apache by the access_log. [access_log] ::1 - - [21/Dec/2010:11:31:25 +0900] OPTIONS * HTTP/1.0 200 - The OPTIONS request is valid, but mod_jk forejudges it as a WARNING. I made small patch when the uri of request matches '*', mod_jk doesn't print WARNING log. But I think it should be adjusted by the category of methods. (For example, if method is OPTIONS and uri is '*', debug message would output.) Best regards, -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50511] WARNING about Internal Dummy Connection of Apache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50511 --- Comment #1 from kikuchi yu kikuchi...@jp.fujitsu.com 2010-12-22 00:02:09 EST --- Created an attachment (id=26438) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26438) ignore the request which uri matches * -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
2010/12/22 Jeremy Boynes jboy...@apache.org On Dec 21, 2010, at 6:15 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50462 --- Comment #3 from Rex Wang rwo...@gmail.com 2010-12-21 21:15:19 EST --- (In reply to comment #2) It's marked optional in Maven as it is only needed if someone is using the XML tags. Is there a way to mimic that with the OSGi references? Not sure about that. At least, IMO, that is not the correct way by using optional:=resolution in import-package to achieve the requirement. I think the optional:=resolution directive is used to express that if osgi framework can not resolve the package, the codes in this bundle may use the implementation from itself or from jdk. So if the codes have hard dependency to (explicitly import) a package, we should not make it as optional resolution. Perhaps the changes needed to address the performance issue in #27717 are relevant here. These stem from issues in Xalan's implementation which would also apply if we tried to use the JDK's implementation. I had a prototype working with Jaxen but the project is pushing builds to the Maven repos and does not seem very active (like, no-one replied to a recent committer call) so depending on it could be problematic. I was thinking of using JXPath instead (from commons). I also don't find JXPATH in maven repo.. However, you also can use the servicemix bundled one: http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath, But that is not the least version 1.3. With multiple options out there, perhaps we could just have taglibs use an interface and provide wrappers for each as separate modules. if we did that, is that something that could be easily handled with OSGi? I am not very familiar with XPATH. Do you mean the approach like spi? IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory and javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose it as the xpath implementation. I am not sure if jaxen and jxpath implement the spi either. Why not move to the standard api in jdk instead of defining new apis and wrappers? -Rex Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Lei Wang (Rex) rwonly AT apache.org
OAuth Support in Tomcat
Hi, I was wondering if there are any plans to build an OAuth stack into the Tomcat server to support OAuth 2.0 flows, instead of forcing the hosted applications to build the logic themselves. Thanks, -Andrew
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
On Dec 21, 2010, at 10:28 PM, Rex Wang wrote: 2010/12/22 Jeremy Boynes jboy...@apache.org Perhaps the changes needed to address the performance issue in #27717 are relevant here. These stem from issues in Xalan's implementation which would also apply if we tried to use the JDK's implementation. I had a prototype working with Jaxen but the project is pushing builds to the Maven repos and does not seem very active (like, no-one replied to a recent committer call) so depending on it could be problematic. I was thinking of using JXPath instead (from commons). I also don't find JXPATH in maven repo.. However, you also can use the servicemix bundled one: http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath, But that is not the least version 1.3. The official one is at: http://repo2.maven.org/maven2/commons-jxpath/commons-jxpath/1.3/ Not sure if it's an OSGi bundle though. Is that what ServiceMix is doing when repackaging? With multiple options out there, perhaps we could just have taglibs use an interface and provide wrappers for each as separate modules. if we did that, is that something that could be easily handled with OSGi? I am not very familiar with XPATH. Do you mean the approach like spi? IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory and javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose it as the xpath implementation. I am not sure if jaxen and jxpath implement the spi either. Why not move to the standard api in jdk instead of defining new apis and wrappers? The XPath implementation in Oracle's JDK was originally based on Xalan and has the same performance issue. One issue with the JAXP API is that it does not allow context to be passed to the evaluation and so the XPath position() and last() functions can't be supported (at least, I've not figured out how). Now the current implementation does not support them either (see #22765) so this may not be a major issue, but the proprietary APIs in Jaxen and JXPath should enable this (would need to code it to be sure). How about: * define our own API that allows context to be passed * create a context-free wrapper for JAXP and remove the hard dependency on Xalan (solving the optional bundle issue) * create other wrappers for Jaxen and/or JXPath that can use the context We could proceed with a release based on the first two steps alone as there's no regression. -- Jeremy
