[Bug 61877] use web.xml from CATALINA_HOME by default
https://bz.apache.org/bugzilla/show_bug.cgi?id=61877 --- Comment #6 from Mark Thomas --- (In reply to Christopher Schultz from comment #4) > (In reply to Mark Thomas from comment #1) > > As far as I recall, no configuration files are read from CATALINA_HOME. They > > are always read, and only read, from CATALINA_BASE. I don't think making the > > default web.xml an exception is a good idea. > > Counterexamples: if CATALINA_BASE/conf/context.xml is not present, > CATALINA_HOME/conf/context.xml will be read instead. Code reference please. The only code I can find always reads from CATALINA_BASE. > Also, > CATALINA_HOME/bin/setenv.sh is executed if CATALINA_BASE/bin/setenv.sh does > not exist (this may be considered something other than a "configuration > file", but I think it helps illustrate the point). That is historical. Originally, it was read only from CATALINA_HOME. The point was made (bug 43594) that it made more sense to be read from CATALINA_BASE. The fall-back to CATALINA_HOME is there for backwards compatibility. > There are at least *some* files that Tomcat will fall-back to in > CATALINA_HOME if they are not present in CATALINA_BASE. It's "surprising"[1] > to find out that a "stock" configuration file -- one users are actively > discouraged from editing -- does not enjoy this kind of fall-back semantics. > > [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment As far as I can tell there is a single file and it behaves this way for backwards compatibility reasons. In all other cases configuration is read only from CATALINA_BASE. I would argue that it is more surprising to change that. Additionally, web.xml has merging rules applied to it. Is the proposal that CATALINA_BASE/conf/web.xml is merged on top of CATALINA_HOME/conf/web.xml or only CATALINA_BASE/conf/web.xml is used? With the former option, a complex process will get more complex and user applications might break - in theory a security issue be introduced. That means the behaviour needs to be made optional which creates more complexity. With the latter option, the same issues exists except the merging complexity. Overall, this seems like an awful lot of effort to address a documentation issue that looks like it could be fixed with a couple of sentences. -- 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 61880] Tomcat server 5: java process crashing
https://bz.apache.org/bugzilla/show_bug.cgi?id=61880 San changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from San --- Hi, Thank you for responding to the bug. I understand Tomcat 5 is desupported. We are having an issue in production env where the tomcat server is crashing. We see below OOM errors, Would you be able to comment as what area needs investigation? Is it the jdbc driver which is causing the issue? We have upgrade to jdbc driver 7 but still haivng below issue. Any comment/guideline much appreciated. Thanks. 2017-12-01 08:20:38,943|ERROR|TP-Processor1|42286971| Exception [Java heap space] in action [class org.apache.struts.action.ActionMapping] com.capula.eoasis.EoasisException: Java heap space at com.capula.eoasis.actions.EoasisDispatchAction.execute(EoasisDispatchAction.java:46) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.capula.eoasis.actions.EoasisDispatchAction.execute(EoasisDispatchAction.java:40) ... 42 more Caused by: java.lang.OutOfMemoryError: Java heap space at java.lang.reflect.Array.newInstance(Array.java:70) at oracle.jdbc.driver.BufferCache.get(BufferCache.java:226) at oracle.jdbc.driver.PhysicalConnection.getCharBuffer(PhysicalConnection.java:7422) at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:983) at oracle.jdbc.driver.T4CTTIdcb.receiveCommon(T4CTTIdcb.java:273) at oracle.jdbc.driver.T4CTTIdcb.receiveFromRefCursor(T4CTTIdcb.java:157) at oracle.jdbc.driver.T4CResultSetAccessor.unmarshalOneRow(T4CResultSetAccessor.java:197) at oracle.jdbc.driver.T4CTTIrxd.unmarshal(T4CTTIrxd.java:916) at oracle.jdbc.driver.T4CTTIrxd.unmarshal(T4CTTIrxd.java:835) at oracle.jdbc.driver.T4C8Oall.readRXD(T4C8Oall.java:658) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:328) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:521) at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:202) at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:1005) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1307) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3449) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3550) at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4693) at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1086) at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:168) at com.capula.eoasis.model.dao.PatientDAO.getPatientDetails(PatientDAO.java:215) at com.capula.eoasis.model.dao.TheatreDAO.getAppointmentNew(TheatreDAO.java:2023) at com.capula.eoasis.model.dao.TheatreDAO.getMicroSessionAppointmentsNew(TheatreDAO.java:1915) at com.capula.eoasis.model.theatre.TheatreViewManagerImpl.getMicroSessionsNew(TheatreViewManagerImpl.java:309) at com.capula.eoasis.model.theatre.TheatreViewManagerImpl.getMicroSessions(TheatreViewManagerImpl.java:88) at com.capula.eoasis.model.theatre.TheatreViewManagerImpl.getMicroSessions(TheatreViewManagerImpl.java:81) at com.capula.eoasis.model.theatre.TheatreViewManagerImpl.getMicroSessions(TheatreViewManagerImpl.java:77) at com.capula.eoasis.model.theatre.TheatreViewManagerImpl.getMicroSessions(TheatreViewManagerImpl.java:73) at sun.reflect.GeneratedMethodAccessor662.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) -- 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 61886] New: 7.0.83 Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE]
https://bz.apache.org/bugzilla/show_bug.cgi?id=61886 Bug ID: 61886 Summary: 7.0.83 Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE] Product: Tomcat 7 Version: trunk Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com Target Milestone: --- Release candidate of 7.0.83 - Java 8u152 - NIO connector - Compression enabled - Running with Security Manager I noted the following error in catalina.2017-12-11.log while running the async examples (for sake of smoke-testing): There are two log messages. The first INFO one is OK (though why we are logging it at all?), the second one is WARNING and is unexpected. [[[ дек 11, 2017 1:38:44 PM org.apache.coyote.AbstractProcessor setErrorState INFO: An error occurred in processing while on a non-container thread. The connection will be closed immediately java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение (English Translation: "The program on your host computer has broken the established connection") at sun.nio.ch.SocketDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:125) at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:164) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:243) at org.apache.coyote.http11.InternalNioOutputBuffer.flush(InternalNioOutputBuffer.java:95) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:828) at org.apache.coyote.Response.action(Response.java:171) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:366) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:334) at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:98) at async.AsyncStockServlet.writeStock(AsyncStockServlet.java:102) at async.AsyncStockServlet.tick(AsyncStockServlet.java:82) at async.Stockticker.run(Stockticker.java:84) at java.lang.Thread.run(Thread.java:748) дек 11, 2017 1:38:44 PM org.apache.catalina.core.AsyncContextImpl setErrorState WARNING: onError() failed for listener of type [org.apache.catalina.core.AsyncListenerWrapper] java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE] at org.apache.coyote.AsyncStateMachine.doComplete(AsyncStateMachine.java:291) at org.apache.coyote.AsyncStateMachine.asyncComplete(AsyncStateMachine.java:275) at org.apache.coyote.http11.Http11NioProcessor.actionInternal(Http11NioProcessor.java:516) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:946) at org.apache.coyote.Request.action(Request.java:345) at org.apache.catalina.core.AsyncContextImpl.complete(AsyncContextImpl.java:103) at async.AsyncStockServlet.onError(AsyncStockServlet.java:118) at org.apache.catalina.core.AsyncListenerWrapper.fireOnError(AsyncListenerWrapper.java:54) at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:455) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:298) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1713) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:616) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1775) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1734) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) ]]] -- 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 61875] Investigate whether Xalan can be removed
https://bz.apache.org/bugzilla/show_bug.cgi?id=61875
--- Comment #7 from Matthew Broadhead ---
i stepped through ForEachTagTest.java
line 140 if (tag.doStartTag() == IterationTag.EVAL_BODY_INCLUDE) {
seems to take a long time
line 142 result = dot.evaluate(tag.getCurrent());
takes virtually no time but the iterations seem to add up to a lot of time in
total
i don't really understand the ins and outs but it seems like every element has
been split up and stored separately instead of being stored as an xml
structure. so the xml search tools don't work very well it is like loading a
separate document for each search.
is there any way to access the low level dtm stuff through the javax.xml.*?
--
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 61880] Tomcat server 5: java process crashing
https://bz.apache.org/bugzilla/show_bug.cgi?id=61880 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Mark Thomas --- Tomcat 5 is no longer supported - and hasn't been for over 5 years. Even if it were, Bugzilla is not a support forum. You want the Apache Tomcat users mailing list. -- 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: r1817765 - in /tomcat/trunk/java: javax/websocket/WebSocketContainer.java org/apache/tomcat/websocket/WsWebSocketContainer.java
Author: markt
Date: Mon Dec 11 11:17:07 2017
New Revision: 1817765
URL: http://svn.apache.org/viewvc?rev=1817765&view=rev
Log:
Revert 1816420
Can't change WebSocket API
Modified:
tomcat/trunk/java/javax/websocket/WebSocketContainer.java
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
Modified: tomcat/trunk/java/javax/websocket/WebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/WebSocketContainer.java?rev=1817765&r1=1817764&r2=1817765&view=diff
==
--- tomcat/trunk/java/javax/websocket/WebSocketContainer.java (original)
+++ tomcat/trunk/java/javax/websocket/WebSocketContainer.java Mon Dec 11
11:17:07 2017
@@ -33,6 +33,17 @@ public interface WebSocketContainer {
* Set the default timeout for sending a message asynchronously.
* @param timeout The new default timeout in milliseconds. A non-positive
*value means an infinite timeout.
+ *
+ * @deprecated This will be removed in Tomcat 9.
+ * Use {@link #setDefaultAsyncSendTimeout(long)}
+ */
+@Deprecated
+void setAsyncSendTimeout(long timeout);
+
+/**
+ * Set the default timeout for sending a message asynchronously.
+ * @param timeout The new default timeout in milliseconds. A non-positive
+ *value means an infinite timeout.
*/
void setDefaultAsyncSendTimeout(long timeout);
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1817765&r1=1817764&r2=1817765&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Mon
Dec 11 11:17:07 2017
@@ -986,6 +986,18 @@ public class WsWebSocketContainer implem
* The default value for this implementation is -1.
*/
@Override
+@Deprecated
+public void setAsyncSendTimeout(long timeout) {
+this.defaultAsyncTimeout = timeout;
+}
+
+
+/**
+ * {@inheritDoc}
+ *
+ * The default value for this implementation is -1.
+ */
+@Override
public void setDefaultAsyncSendTimeout(long timeout) {
this.defaultAsyncTimeout = timeout;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1817766 - in /tomcat/trunk: java/javax/websocket/WebSocketContainer.java java/org/apache/tomcat/websocket/WsWebSocketContainer.java test/org/apache/tomcat/websocket/TestWsWebSocketContain
Author: markt
Date: Mon Dec 11 11:17:44 2017
New Revision: 1817766
URL: http://svn.apache.org/viewvc?rev=1817766&view=rev
Log:
Revert 1816418
Can't change WebSocket API
Modified:
tomcat/trunk/java/javax/websocket/WebSocketContainer.java
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Modified: tomcat/trunk/java/javax/websocket/WebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/WebSocketContainer.java?rev=1817766&r1=1817765&r2=1817766&view=diff
==
--- tomcat/trunk/java/javax/websocket/WebSocketContainer.java (original)
+++ tomcat/trunk/java/javax/websocket/WebSocketContainer.java Mon Dec 11
11:17:44 2017
@@ -33,20 +33,9 @@ public interface WebSocketContainer {
* Set the default timeout for sending a message asynchronously.
* @param timeout The new default timeout in milliseconds. A non-positive
*value means an infinite timeout.
- *
- * @deprecated This will be removed in Tomcat 9.
- * Use {@link #setDefaultAsyncSendTimeout(long)}
*/
-@Deprecated
void setAsyncSendTimeout(long timeout);
-/**
- * Set the default timeout for sending a message asynchronously.
- * @param timeout The new default timeout in milliseconds. A non-positive
- *value means an infinite timeout.
- */
-void setDefaultAsyncSendTimeout(long timeout);
-
Session connectToServer(Object endpoint, URI path)
throws DeploymentException, IOException;
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1817766&r1=1817765&r2=1817766&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Mon
Dec 11 11:17:44 2017
@@ -986,22 +986,10 @@ public class WsWebSocketContainer implem
* The default value for this implementation is -1.
*/
@Override
-@Deprecated
public void setAsyncSendTimeout(long timeout) {
this.defaultAsyncTimeout = timeout;
}
-
-/**
- * {@inheritDoc}
- *
- * The default value for this implementation is -1.
- */
-@Override
-public void setDefaultAsyncSendTimeout(long timeout) {
-this.defaultAsyncTimeout = timeout;
-}
-
/**
* Cleans up the resources still in use by WebSocket sessions created from
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java?rev=1817766&r1=1817765&r2=1817766&view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
(original)
+++ tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Mon Dec 11 11:17:44 2017
@@ -325,7 +325,7 @@ public class TestWsWebSocketContainer ex
// Set the async timeout
if (setTimeoutOnContainer) {
-wsContainer.setDefaultAsyncSendTimeout(TIMEOUT_MS);
+wsContainer.setAsyncSendTimeout(TIMEOUT_MS);
}
tomcat.start();
@@ -606,7 +606,7 @@ public class TestWsWebSocketContainer ex
sc.addEndpoint(ServerEndpointConfig.Builder.create(
ConstantTxEndpoint.class, PATH).build());
if (TestWsWebSocketContainer.timeoutOnContainer) {
-sc.setDefaultAsyncSendTimeout(TIMEOUT_MS);
+sc.setAsyncSendTimeout(TIMEOUT_MS);
}
} catch (DeploymentException e) {
throw new IllegalStateException(e);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57434] Race condition in EL1.0 validation
https://bz.apache.org/bugzilla/show_bug.cgi?id=57434 --- Comment #1 from Tomas Hofman --- This concurrency issue was also hit in EAP/Wildfly. It is an issue even if the library is included inside a web application, e.g. when two different JSPs are requested and evaluated concurrently. Tested with taglibs-standard-jstlel 1.2.5. I'm attaching a suggested patch. -- 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 57434] Race condition in EL1.0 validation
https://bz.apache.org/bugzilla/show_bug.cgi?id=57434 --- Comment #2 from Tomas Hofman --- Created attachment 35602 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35602&action=edit Patch -- 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 7.0.83
2017-11-30 22:37 GMT+03:00 Violeta Georgieva : > The proposed Apache Tomcat 7.0.83 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.83/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1163/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_83/ > > The proposed 7.0.83 release is: > [x] Broken - do not release > [ ] Stable - go ahead and release as 7.0.83 Stable 1. Unit tests - OK. Tested BIO,NIO,APR(32-bit) with Java 6, 7, 8u152. The following test fails with 8u152, regardless of connector: org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream [[[ Testcase: testBug52121 took 0,025 sec Caused an ERROR invalid code lengths set java.util.zip.ZipException: invalid code lengths set at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.catalina.util.IOTools.flow(IOTools.java:74) at org.apache.catalina.util.IOTools.flow(IOTools.java:85) at org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream.testBug52121(TestFlushableGZIPOutputStream.java:74) ]]] This is the known regression of Java 8u151/152. It is not a bug in Tomcat. 2. I smoke-tested running with compression enabled and Java 8u152. Generally, it looks OK. 3. There is an issue noted when testing the Async example, I filed it into bugzilla https://bz.apache.org/bugzilla/show_bug.cgi?id=61886 It needs further investigation. I am voting "Broken" because of it. 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: r1817767 - in /tomcat/tc8.5.x/trunk: ./ java/javax/websocket/WebSocketContainer.java java/org/apache/tomcat/websocket/WsWebSocketContainer.java test/org/apache/tomcat/websocket/TestWsWebSo
Author: markt Date: Mon Dec 11 11:39:18 2017 New Revision: 1817767 URL: http://svn.apache.org/viewvc?rev=1817767&view=rev Log: Revert 1816419 Can't change WebSocket API Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/java/javax/websocket/WebSocketContainer.java tomcat/tc8.5.x/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java tomcat/tc8.5.x/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Dec 11 11:39:18 2017 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1761572,1761574,1761625-1761626,1761628,1761682,1761740,1761752,1762051-176205 3,1762123,1762168,1762172,1762182,1762201-1762202,1762204,1762208,1762288,1762296,1762324,1762348,1762353,1762362,1762374,1762492,1762503,1762505,1762541,1762608,1762710,1762753,1762766,1762769,1762944,1762947,1762953,1763167,1763179,1763232,1763259,1763271-1763272,1763276-1763277,1763319-176332
[Bug 61831] NIO2 connector becomes intermittently unresponsive after some period of time
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831 Piotr changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID --- Comment #3 from Piotr --- We think we figured it out to be a Java Bug in asynchronous server socket implementation. Please see the following bug report which seems to exhibit a similar issue. https://bugs.openjdk.java.net/browse/JDK-8172750 -- 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 61886] 7.0.83 Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE]
https://bz.apache.org/bugzilla/show_bug.cgi?id=61886
Konstantin Kolinko changed:
What|Removed |Added
OS||All
--- Comment #1 from Konstantin Kolinko ---
1) The second exception happens in error handling in example
async.AsyncStockServlet.onError(AsyncStockServlet.java:118)
This is implemented as
@Override
public void onError(AsyncEvent event) throws IOException {
event.getAsyncContext().complete();
}
2) Javadoc in AsyncStateMachine
* MUST_COMPLETE- ServletRequest.startAsync() followed by complete() have
*been called during a single Servlet.service() method. The
*complete() will be processed as soon as the request
*finishes.
It says that both startAsync() and complete() have been called by
Servlet.service() method.
How is it? There is no such code in AsyncStockServlet.
3) Can we ignore duplicate complete() calls?
--
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 61831] NIO2 connector becomes intermittently unresponsive after some period of time
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831 --- Comment #4 from Remy Maucherat --- Ok, maybe. Let us know if you find some elements demonstrating an issue in Tomcat. -- 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 7.0.83
Hi Konstantin, Am 11.12.2017 um 12:30 schrieb Konstantin Kolinko: ... The following test fails with 8u152, regardless of connector: org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream [[[ Testcase: testBug52121 took 0,025 sec Caused an ERROR invalid code lengths set java.util.zip.ZipException: invalid code lengths set at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.catalina.util.IOTools.flow(IOTools.java:74) at org.apache.catalina.util.IOTools.flow(IOTools.java:85) at org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream.testBug52121(TestFlushableGZIPOutputStream.java:74) ]]] This is the known regression of Java 8u151/152. It is not a bug in Tomcat. I can reproduce, but shouldn't that have been fixed in r1816712 and r1816713? Or is our test class just not using the workaround, so the test is broken? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.83
2017-12-11 15:37 GMT+03:00 Rainer Jung : > Hi Konstantin, > > Am 11.12.2017 um 12:30 schrieb Konstantin Kolinko: > ... >> >> The following test fails with 8u152, regardless of connector: >> org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream >> [[[ >> Testcase: testBug52121 took 0,025 sec >> Caused an ERROR >> invalid code lengths set >> java.util.zip.ZipException: invalid code lengths set >> at >> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) >> at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117) >> at java.io.FilterInputStream.read(FilterInputStream.java:107) >> at org.apache.catalina.util.IOTools.flow(IOTools.java:74) >> at org.apache.catalina.util.IOTools.flow(IOTools.java:85) >> at >> org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream.testBug52121(TestFlushableGZIPOutputStream.java:74) >> ]]] >> >> This is the known regression of Java 8u151/152. It is not a bug in Tomcat. > > > I can reproduce, but shouldn't that have been fixed in r1816712 and > r1816713? Or is our test class just not using the workaround, so the test is > broken? Nothing is broken here. I am just noting for an archive that JRE bug is visible here. (It is a pity that nobody tested an early build of 8u151 with 7.0.x. They could have seen the bug.) The test tests FlushableGZIPOutputStream directly. That class is not used when running on Java 7+. I manually tested that Tomcat runs correctly with compression enabled. My concern with 7.0.83 is error handling in async (bug 61886). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.83
Am 11.12.2017 um 14:02 schrieb Konstantin Kolinko: 2017-12-11 15:37 GMT+03:00 Rainer Jung : Hi Konstantin, Am 11.12.2017 um 12:30 schrieb Konstantin Kolinko: ... The following test fails with 8u152, regardless of connector: org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream [[[ Testcase: testBug52121 took 0,025 sec Caused an ERROR invalid code lengths set java.util.zip.ZipException: invalid code lengths set at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.catalina.util.IOTools.flow(IOTools.java:74) at org.apache.catalina.util.IOTools.flow(IOTools.java:85) at org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream.testBug52121(TestFlushableGZIPOutputStream.java:74) ]]] This is the known regression of Java 8u151/152. It is not a bug in Tomcat. I can reproduce, but shouldn't that have been fixed in r1816712 and r1816713? Or is our test class just not using the workaround, so the test is broken? Nothing is broken here. I am just noting for an archive that JRE bug is visible here. (It is a pity that nobody tested an early build of 8u151 with 7.0.x. They could have seen the bug.) The test tests FlushableGZIPOutputStream directly. That class is not used when running on Java 7+. I manually tested that Tomcat runs correctly with compression enabled. Thanks for confirming. My concern with 7.0.83 is error handling in async (bug 61886). Understood. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57434] Race condition in EL1.0 validation
https://bz.apache.org/bugzilla/show_bug.cgi?id=57434 --- Comment #3 from Jeremy Boynes --- I believe this patch reduces the window for the race but does not fully close it as another thread could still modify the field between when it is set and then read. It would be unlikely due to variable caching but still possible. -- 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 57434] Race condition in EL1.0 validation
https://bz.apache.org/bugzilla/show_bug.cgi?id=57434 --- Comment #4 from Jeremy Boynes --- The current implementation disables caching while expressions are being validated during the translation process. This has the side effect of disabling the cache for evaluations that occur concurrently i.e. if a JSP is being translated at the same time a request is occurring. I don't think this was the intent but hesitate to change the behaviour given the age of this library. If we think this is safe, we could simply pass the flag as a parameter to parseExpressionString and eliminate the field entirely. -- 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: Migrating to git
On Wed, Dec 6, 2017 at 2:54 PM, Mark Thomas wrote: > On 06/12/17 11:30, Mark Thomas wrote: > > On 06/12/17 10:34, Konstantin Kolinko wrote: > > > > >> If the goal is to create a single Git repository from our several ones, > >> my suggestion is to create a repository and pull in the branches from > >> the existing 7/8/8.5/9 git mirrors. > > > > > Sounds good. And it can be tested without impacting on any of the > > current public repos. I'll try it out and report back. > > I've tested this with trunk and 8.5.x. and it works well. It is also > very quick. Much better than my original plan. We would be able to add > the older branches to the existing git mirror of trunk. That would make > the process something like: > > - make svn read-only for trunk, 8.5.x, 8.0.x and 7.0.x > - disable svn->git mirroring > - make git for trunk read/write (we could switch to github as the master > at the same time) > - merge in branches for 8.5.x, 8.0.x and 7.0.x > - clean-up tags > - update CI systems, web pages etc for new locations > - move trunk, 8.5.x, 8.0.x and 7.0.x to the archive > > Before we do this, there are a number of points we should think about. > You listed a couple below. There are others on some older threads on > this topic. > > I suggest we write up (I'm happy to start it) a list of potential issues > and solutions on the wiki and make sure we are happy with those > solutions before we migrate. > > Do we get a "demo" repo to see the result ? Rémy
Re: Migrating to git
On 11/12/17 15:27, Rémy Maucherat wrote: > On Wed, Dec 6, 2017 at 2:54 PM, Mark Thomas wrote: > >> On 06/12/17 11:30, Mark Thomas wrote: >>> On 06/12/17 10:34, Konstantin Kolinko wrote: >> >> >> If the goal is to create a single Git repository from our several ones, my suggestion is to create a repository and pull in the branches from the existing 7/8/8.5/9 git mirrors. >> >> >> >>> Sounds good. And it can be tested without impacting on any of the >>> current public repos. I'll try it out and report back. >> >> I've tested this with trunk and 8.5.x. and it works well. It is also >> very quick. Much better than my original plan. We would be able to add >> the older branches to the existing git mirror of trunk. That would make >> the process something like: >> >> - make svn read-only for trunk, 8.5.x, 8.0.x and 7.0.x >> - disable svn->git mirroring >> - make git for trunk read/write (we could switch to github as the master >> at the same time) >> - merge in branches for 8.5.x, 8.0.x and 7.0.x >> - clean-up tags >> - update CI systems, web pages etc for new locations >> - move trunk, 8.5.x, 8.0.x and 7.0.x to the archive >> >> Before we do this, there are a number of points we should think about. >> You listed a couple below. There are others on some older threads on >> this topic. >> >> I suggest we write up (I'm happy to start it) a list of potential issues >> and solutions on the wiki and make sure we are happy with those >> solutions before we migrate. >> > Do we get a "demo" repo to see the result ? Because the plan above starts with the existing git mirror when we do decide to migrate it will be directly on the live repo. However, I'm happy to pull together a (read-only) demo git repo of what it would look like based on a point in time snapshot. I should be able to do that this week. I also need to get that list of potential issues and solutions written up. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1817791 - /tomcat/trunk/webapps/docs/config/listeners.xml
Author: csutherl
Date: Mon Dec 11 16:31:45 2017
New Revision: 1817791
URL: http://svn.apache.org/viewvc?rev=1817791&view=rev
Log:
Follow-up to r1816546 The Listener was removed, removing documentation
reference.
Modified:
tomcat/trunk/webapps/docs/config/listeners.xml
Modified: tomcat/trunk/webapps/docs/config/listeners.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/listeners.xml?rev=1817791&r1=1817790&r2=1817791&view=diff
==
--- tomcat/trunk/webapps/docs/config/listeners.xml (original)
+++ tomcat/trunk/webapps/docs/config/listeners.xml Mon Dec 11 16:31:45 2017
@@ -571,15 +571,6 @@
-
-
-This listener performs system property replacement using the property
- source configured on the digester. When ${parameter}
- denoted parameters are found in the values of system properties,
- the property source will be invoked to attempt to replace it.
-
-
-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61886] 7.0.83 Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE]
https://bz.apache.org/bugzilla/show_bug.cgi?id=61886 --- Comment #2 from Mark Thomas --- I can repeat this. I'm looking into why it happens. The spec is clear about when it is legal to call this method, but unclear as to what to do if it is called illegally. Generally that means the container can handle it however it pleases. I'd lean towards an error of some kind because the API is being used incorrectly. I'm not sure at this point how long it will take to figure out what is going on. From experience it will either be a few minutes or a few days. -- 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: r1817792 - /tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
Author: markt
Date: Mon Dec 11 16:53:55 2017
New Revision: 1817792
URL: http://svn.apache.org/viewvc?rev=1817792&view=rev
Log:
Remove unused code.
This protection is not required in 7.0.x since the refactoring that triggered
the issue has not be back-ported.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java?rev=1817792&r1=1817791&r2=1817792&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
Mon Dec 11 16:53:55 2017
@@ -150,8 +150,6 @@ public class AsyncContextImpl implements
public boolean timeout() {
AtomicBoolean result = new AtomicBoolean();
request.getCoyoteRequest().action(ActionCode.ASYNC_TIMEOUT, result);
-// Avoids NPEs during shutdown. A call to recycle will null this field.
-Context context = this.context;
if (result.get()) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1817800 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/security/SecurityClassLoad.java webapps/docs/changelog.xml
Author: markt
Date: Mon Dec 11 17:47:03 2017
New Revision: 1817800
URL: http://svn.apache.org/viewvc?rev=1817800&view=rev
Log:
Pre-load additional classes to prevent SecurityExceptions if the first request
received when running under a security manager is an asynchronous servlet.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1817800&r1=1817799&r2=1817800&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
Mon Dec 11 17:47:03 2017
@@ -163,6 +163,10 @@ public final class SecurityClassLoad {
private static final void loadCoyotePackage(ClassLoader loader)
throws Exception {
final String basePackage = "org.apache.coyote.";
+// Classes created by the Java 6 compiler because we use switch with
an enum
+loader.loadClass(basePackage + "http11.Http11Processor$1");
+loader.loadClass(basePackage + "http11.Http11NioProcessor$1");
+loader.loadClass(basePackage + "http11.Http11AprProcessor$1");
loader.loadClass(basePackage + "http11.AbstractOutputBuffer$1");
loader.loadClass(basePackage + "http11.Constants");
// Make sure system property is read at this point
@@ -292,6 +296,7 @@ public final class SecurityClassLoad {
"util.net.NioBlockingSelector$BlockPoller$2");
loader.loadClass(basePackage +
"util.net.NioBlockingSelector$BlockPoller$3");
+loader.loadClass(basePackage + "util.net.SendfileState");
loader.loadClass(basePackage + "util.net.SSLSupport$CipherData");
// security
loader.loadClass(basePackage + "util.security.PrivilegedGetTccl");
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=1817800&r1=1817799&r2=1817800&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Dec 11 17:47:03 2017
@@ -58,6 +58,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Pre-load additional classes to prevent SecurityExceptions
+if the first request received when running under a
+SecurityManager is an asynchronous Servlet. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1817801 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Author: markt Date: Mon Dec 11 17:49:14 2017 New Revision: 1817801 URL: http://svn.apache.org/viewvc?rev=1817801&view=rev Log: This appears to be the root cause of BZ 61886 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=1817801&r1=1817800&r2=1817801&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Dec 11 17:49:14 2017 @@ -61,9 +61,10 @@ -Pre-load additional classes to prevent SecurityExceptions -if the first request received when running under a -SecurityManager is an asynchronous Servlet. (markt) +61886: Pre-load additional classes to prevent +SecurityExceptions if the first request received when +running under a SecurityManager is an asynchronous Servlet. +(markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61886] 7.0.83 Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE]
https://bz.apache.org/bugzilla/show_bug.cgi?id=61886 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Thomas --- When I started to investigate this I was getting unexpected 500 responses if I accessed the example directly. The root cause of that was an AccessControlException retying to load an anonymous inner class generated by the compiler when enums are used with switch. Fixing that appears to have fixed this bug too. With the necessary classes pre-loaded, I can't recreate this. It is speculation but I suspect what was happening was that the AccessControlException was causing errors in the error handling and Tomcat's attempts to clean up after this were causing the ISE. -- 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: r1817800 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/security/SecurityClassLoad.java webapps/docs/changelog.xml
Mark,
On 12/11/17 12:47 PM, ma...@apache.org wrote:
> Author: markt
> Date: Mon Dec 11 17:47:03 2017
> New Revision: 1817800
>
> URL: http://svn.apache.org/viewvc?rev=1817800&view=rev
> Log:
> Pre-load additional classes to prevent SecurityExceptions if the first
> request received when running under a security manager is an asynchronous
> servlet.
>
> Modified:
>
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1817800&r1=1817799&r2=1817800&view=diff
> ==
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
> (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
> Mon Dec 11 17:47:03 2017
> @@ -163,6 +163,10 @@ public final class SecurityClassLoad {
> private static final void loadCoyotePackage(ClassLoader loader)
> throws Exception {
> final String basePackage = "org.apache.coyote.";
> +// Classes created by the Java 6 compiler because we use switch with
> an enum
> +loader.loadClass(basePackage + "http11.Http11Processor$1");
> +loader.loadClass(basePackage + "http11.Http11NioProcessor$1");
> +loader.loadClass(basePackage + "http11.Http11AprProcessor$1");
I find it fragile to whitelist anonymous inner classes in this way. A
change to the target class (e.g. Http11Processor) could change the
meaning of the whitelist.
Are there significant objections to making these into NAMED inner
classes? I believe it will be safer, and since this is intended to be a
SecurityManager-related whitelist, safer is better.
Thanks,
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1817800 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/security/SecurityClassLoad.java webapps/docs/changelog.xml
On 11/12/17 18:05, Christopher Schultz wrote:
> Mark,
>
> On 12/11/17 12:47 PM, ma...@apache.org wrote:
>> Author: markt
>> Date: Mon Dec 11 17:47:03 2017
>> New Revision: 1817800
>>
>> URL: http://svn.apache.org/viewvc?rev=1817800&view=rev
>> Log:
>> Pre-load additional classes to prevent SecurityExceptions if the first
>> request received when running under a security manager is an asynchronous
>> servlet.
>>
>> Modified:
>>
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
>> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>
>> Modified:
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1817800&r1=1817799&r2=1817800&view=diff
>> ==
>> ---
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
>> (original)
>> +++
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
>> Mon Dec 11 17:47:03 2017
>> @@ -163,6 +163,10 @@ public final class SecurityClassLoad {
>> private static final void loadCoyotePackage(ClassLoader loader)
>> throws Exception {
>> final String basePackage = "org.apache.coyote.";
>> +// Classes created by the Java 6 compiler because we use switch
>> with an enum
>> +loader.loadClass(basePackage + "http11.Http11Processor$1");
>> +loader.loadClass(basePackage + "http11.Http11NioProcessor$1");
>> +loader.loadClass(basePackage + "http11.Http11AprProcessor$1");
>
> I find it fragile to whitelist anonymous inner classes in this way. A
> change to the target class (e.g. Http11Processor) could change the
> meaning of the whitelist.
>
> Are there significant objections to making these into NAMED inner
> classes? I believe it will be safer, and since this is intended to be a
> SecurityManager-related whitelist, safer is better.
Given that these classes are auto-generated by the compiler, how do you
propose to do that?
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrating to git
On 11/12/17 16:24, Mark Thomas wrote: > On 11/12/17 15:27, Rémy Maucherat wrote: >> Do we get a "demo" repo to see the result ? > > Because the plan above starts with the existing git mirror when we do > decide to migrate it will be directly on the live repo. However, I'm > happy to pull together a (read-only) demo git repo of what it would look > like based on a point in time snapshot. I should be able to do that this > week. If all goes to plan, the current apache/tomcat git repo would look like this: https://github.com/markt-asf/tomcat It won't be a fork so the UI behaviour will be slightly different but that should be enough to give you the idea. The migration steps are documented here: https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration The good news is that I can run though this process in less than an hour so if: - we are happy with this; and - we are happy with the issues and proposed solutions; and - we agree to migrate to git it can happen pretty quickly and minimal impact / downtime for development. > I also need to get that list of potential issues and solutions written up. I'll work on filling in the issues section tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.48
2017-11-30 19:19 GMT+02:00 Violeta Georgieva : > > The proposed Apache Tomcat 8.0.48 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.48/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1162/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_48/ > > The proposed 8.0.48 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.0.48 +1 Regards, Violeta
Re: [RESULT][VOTE] Release Apache Tomcat 8.0.48
Hi, 2017-11-30 19:19 GMT+02:00 Violeta Georgieva : > > The proposed Apache Tomcat 8.0.48 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.48/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1162/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_48/ > > The proposed 8.0.48 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 8.0.48 +1 (binding):fschumacher, csutherl, violetagg No other voters were cast. The vote has passed. I'll do the release shortly and announce it once the mirrors catch up. Regards, Violeta
Re: Migrating to git
On Mon, Dec 11, 2017 at 10:28 PM, Mark Thomas wrote: > On 11/12/17 16:24, Mark Thomas wrote: > > On 11/12/17 15:27, Rémy Maucherat wrote: > > > > >> Do we get a "demo" repo to see the result ? > > > > Because the plan above starts with the existing git mirror when we do > > decide to migrate it will be directly on the live repo. However, I'm > > happy to pull together a (read-only) demo git repo of what it would look > > like based on a point in time snapshot. I should be able to do that this > > week. > > If all goes to plan, the current apache/tomcat git repo would look like > this: > https://github.com/markt-asf/tomcat > Ok, so that looks good. Thanks. > > It won't be a fork so the UI behaviour will be slightly different but > that should be enough to give you the idea. > > The migration steps are documented here: > https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration > > The good news is that I can run though this process in less than an hour > so if: > - we are happy with this; and > - we are happy with the issues and proposed solutions; and > - we agree to migrate to git > > it can happen pretty quickly and minimal impact / downtime for development. > > > I also need to get that list of potential issues and solutions written > up. > > I'll work on filling in the issues section tomorrow. > Rémy
svn commit: r23598 - /dev/tomcat/tomcat-8/v8.0.48/ /release/tomcat/tomcat-8/v8.0.48/
Author: violetagg Date: Tue Dec 12 07:02:08 2017 New Revision: 23598 Log: Release 8.0.48 Added: release/tomcat/tomcat-8/v8.0.48/ - copied from r23597, dev/tomcat/tomcat-8/v8.0.48/ Removed: dev/tomcat/tomcat-8/v8.0.48/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1817884 - /tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
Author: violetagg Date: Tue Dec 12 07:14:41 2017 New Revision: 1817884 URL: http://svn.apache.org/viewvc?rev=1817884&view=rev Log: Update the release date for 8.0.48 Modified: tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml?rev=1817884&r1=1817883&r2=1817884&view=diff == --- tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Tue Dec 12 07:14:41 2017 @@ -88,7 +88,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [CANCEL][VOTE] Release Apache Tomcat 7.0.83
Hi, 2017-11-30 21:37 GMT+02:00 Violeta Georgieva : > > The proposed Apache Tomcat 7.0.83 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.83/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1163/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_83/ > > The proposed 7.0.83 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 7.0.83 Stable I'm canceling the vote because of the issue with the Async example. I'll pick up the fix and prepare a new vote shortly. Regards, Violeta
svn commit: r1817885 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Author: violetagg Date: Tue Dec 12 07:25:21 2017 New Revision: 1817885 URL: http://svn.apache.org/viewvc?rev=1817885&view=rev Log: 7.0.83 did not pass the vote 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=1817885&r1=1817884&r2=1817885&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Dec 12 07:25:21 2017 @@ -90,7 +90,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r23599 - /dev/tomcat/tomcat-7/v7.0.83/
Author: violetagg Date: Tue Dec 12 07:26:45 2017 New Revision: 23599 Log: Tomcat 7.0.83 did not pass the vote Removed: dev/tomcat/tomcat-7/v7.0.83/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
