svn commit: r1558331 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Jan 15 09:58:54 2014 New Revision: 1558331 URL: http://svn.apache.org/r1558331 Log: Formatting tweaks Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1558331&r1=1558330&r2=1558331&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jan 15 09:58:54 2014 @@ -24,14 +24,18 @@ $Id$ RELEASE SHOWSTOPPERS: +None + PATCHES ACCEPTED TO BACKPORT: [ start all new proposals below, under PATCHES PROPOSED. ] +None + + PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] - * Back-port some XML processing improvements (part 4) Add a unit test for the new descriptor Note I am generating the patches using git so the patch shows whole new files @@ -69,5 +73,6 @@ PATCHES PROPOSED TO BACKPORT: -1: -PATCHES/ISSUES THAT ARE STALLED +PATCHES/ISSUES THAT ARE STALLED: +None \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1558332 - in /tomcat/site/trunk: docs/migration-8.html xdocs/migration-8.xml
Author: markt Date: Wed Jan 15 10:09:53 2014 New Revision: 1558332 URL: http://svn.apache.org/r1558332 Log: Update 8.0.x migration information Modified: tomcat/site/trunk/docs/migration-8.html tomcat/site/trunk/xdocs/migration-8.xml Modified: tomcat/site/trunk/docs/migration-8.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/migration-8.html?rev=1558332&r1=1558331&r2=1558332&view=diff == --- tomcat/site/trunk/docs/migration-8.html (original) +++ tomcat/site/trunk/docs/migration-8.html Wed Jan 15 10:09:53 2014 @@ -344,6 +344,28 @@ of Apache Tomcat. documentation provides details on how the new implementation may be used. + +The refactoring of resources has also resulted in a number of attributes +being removed from the default Context implementation +(org.apache.catalina.core.StandardContext). The following attributes may now +be configured via the +resources implementation +used by the web application: + + + +allowLinking + +cachingAllowed + +cacheMaxSize + +cacheObjectMaxSize + +cacheTTL + + + Modified: tomcat/site/trunk/xdocs/migration-8.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/migration-8.xml?rev=1558332&r1=1558331&r2=1558332&view=diff == --- tomcat/site/trunk/xdocs/migration-8.xml (original) +++ tomcat/site/trunk/xdocs/migration-8.xml Wed Jan 15 10:09:53 2014 @@ -82,6 +82,20 @@ of Apache Tomcat. documentation provides details on how the new implementation may be used. +The refactoring of resources has also resulted in a number of attributes +being removed from the default Context implementation +(org.apache.catalina.core.StandardContext). The following attributes may now +be configured via the +resources implementation +used by the web application: + + allowLinking + cachingAllowed + cacheMaxSize + cacheObjectMaxSize + cacheTTL + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56013] New: SpnegoAuthenticator not working in IBM JDK v7 for Kerberos due to incorrect credential lifetime
https://issues.apache.org/bugzilla/show_bug.cgi?id=56013 Bug ID: 56013 Summary: SpnegoAuthenticator not working in IBM JDK v7 for Kerberos due to incorrect credential lifetime Product: Tomcat 7 Version: 7.0.50 Hardware: Other OS: AIX Status: NEW Severity: major Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: arunav.sanya...@gmail.com Created attachment 31208 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31208&action=edit Unified GNU diff format of SpnegoAuthenticator.java and its updated version Hi SpnegoAuthenticator is not working with IBM JDK v7. The option GSSCredential.DEFAULT_LIFETIME specified while generating ticket creates the following exception:- major code: 11, minor code: 0 major string: General failure, unspecified at GSSAPI level minor string: Desired initLifetime zero or less) However specifying GSSCredential.INDEFINITE_LIFETIME as lifetime of credential resolves the issue. I am attaching a patch which optionally chooses cred lifetime as indefinite or default depending on whether the JDK is IBM JDK or Oracle/Sun JDK. This patch is with respect to SpnegoAuthenticator.java of tomcat v 7.0.50 Impact of fix:- 1. If not fixed then Tomcat does not work out of the box for Spnego Authentication(Kerberos) for IBM JDK v7 2. The fix affects only IBM JDK and does not change the execution flow for Oracle/Sun JDK Yours sincerely Arunav Sanyal -- 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: Context switch integration
On 14/01/2014 17:03, Rémy Maucherat wrote: > Hi, > > In Tomcat, entering a context is done simply by setting the context > classloader and sometimes firing some random events (like the ones from the > ServletRequestListener). This isn't so good for integration and could use > improvements, in addition to at least one place where this is not done at > all (very recently a bug reported to me that indicated there was an issue > with SSO session expiration, and indeed it expires sessions from other > contexts just like that). > > So I would propose harmonizing this (and fix the SSO issue too, obviously), > with a new dedicated ThreadBindingListener interface (two methods: > bind/unbind) and a get/set for it also in Context, to be used for > integration. Although usually generic listeners are used (and there can be > multiple ones), this has worked well for me so far. > > Ideally I would have liked to also take over the privileged actions in a > utility class, but this would make PA use less optimal (for example in the > request dispatcher). > > Comments ? (or better ideas ?) If folks integrating with Tomcat need to extend / replace what is currently in StandardContext.bindThread() and StandardContext.unbindThread() having a listener for this rather than having to extend StandardContext makes sense to me. I'm not sure I follow what you are proposing for PAs. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Status of cookies proposals
Does any one have anything else to add to http://wiki.apache.org/tomcat/Cookies ? It feels like we should be looking to make some decisions on where to go with this. My $0.02 to start this discussion is that we should adopt the all of the proposed changes with the following notes: - C1 rather C1a - G1a rather than G1 (we need to keep an option to switch for backwards compatibility) - G3a rather than G3 (Tomcat currently handles quoting / escaping for RFC2109 cookies so it needs to continue to do so for backwards compatibility) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1558355 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ test/org/apache/catalina/core/ test/org/apache/catalina/startup/ web
Author: markt
Date: Wed Jan 15 12:23:23 2014
New Revision: 1558355
URL: http://svn.apache.org/r1558355
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55855
Provide a context level option to exclude container SCIs.
Modified:
tomcat/trunk/java/org/apache/catalina/Context.java
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/FailedContext.java
tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
tomcat/trunk/test/org/apache/catalina/startup/TestWebappServiceLoader.java
tomcat/trunk/webapps/docs/config/context.xml
Modified: tomcat/trunk/java/org/apache/catalina/Context.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Context.java?rev=1558355&r1=1558354&r2=1558355&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Context.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Context.java Wed Jan 15 12:23:23 2014
@@ -694,9 +694,34 @@ public interface Context extends Contain
*/
public void setInstanceManager(InstanceManager instanceManager);
-// - Public Methods
+/**
+ * Sets the regular expression that specifies which container provided SCIs
+ * should be filtered out and not used for this context. Matching uses
+ * {@link java.util.regex.Matcher#find()} so the regular expression only
has
+ * to match a sub-string of the fully qualified class name of the container
+ * provided SCI for it to be filtered out.
+ *
+ * @param containerSciFilter The regular expression against which the fully
+ * qualified class name of each container
provided
+ * SCI should be checked
+ */
+public void setContainerSciFilter(String containerSciFilter);
+
+/**
+ * Obtains the regular expression that specifies which container provided
+ * SCIs should be filtered out and not used for this context. Matching uses
+ * {@link java.util.regex.Matcher#find()} so the regular expression only
has
+ * to match a sub-string of the fully qualified class name of the container
+ * provided SCI for it to be filtered out.
+ *
+ * @return The regular expression against which the fully qualified class
+ * name of each container provided SCI will be checked
+ */
+public String getContainerSciFilter();
+// - Public Methods
+
/**
* Add a new Listener class name to the set of Listeners
* configured for this application.
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1558355&r1=1558354&r2=1558355&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Wed Jan 15
12:23:23 2014
@@ -805,10 +805,24 @@ public class StandardContext extends Con
private Map postConstructMethods = new HashMap<>();
private Map preDestroyMethods = new HashMap<>();
+private String containerSciFilter;
+
// - Context Properties
@Override
+public void setContainerSciFilter(String containerSciFilter) {
+this.containerSciFilter = containerSciFilter;
+}
+
+
+@Override
+public String getContainerSciFilter() {
+return containerSciFilter;
+}
+
+
+@Override
public boolean getSendRedirectBody() {
return sendRedirectBody;
}
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1558355&r1=1558354&r2=1558355&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Wed Jan 15
12:23:23 2014
@@ -1595,7 +1595,7 @@ public class ContextConfig implements Li
List detectedScis;
try {
WebappServiceLoader loader =
-new WebappServiceLoader<>(servletContext);
+new WebappServiceLoader<>(servletContext,
context.getContainerSciFilter());
detectedScis = loader.load(ServletContainerInitializer.class);
} catch (IOException e) {
log.error(sm.getString(
Modified: tomcat/trunk/java/org/apache/catalina/startup
svn commit: r1558357 - in /tomcat/trunk: conf/catalina.properties conf/context.xml webapps/docs/config/jar-scan-filter.xml
Author: markt Date: Wed Jan 15 12:24:13 2014 New Revision: 1558357 URL: http://svn.apache.org/r1558357 Log: Simplify configuration now that the SCI does not use the JarScanner for container JARs. Modified: tomcat/trunk/conf/catalina.properties tomcat/trunk/conf/context.xml tomcat/trunk/webapps/docs/config/jar-scan-filter.xml Modified: tomcat/trunk/conf/catalina.properties URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/catalina.properties?rev=1558357&r1=1558356&r2=1558357&view=diff == --- tomcat/trunk/conf/catalina.properties (original) +++ tomcat/trunk/conf/catalina.properties Wed Jan 15 12:24:13 2014 @@ -97,9 +97,9 @@ bootstrap.jar,commons-daemon.jar,tomcat- annotations-api.jar,el-api.jar,jsp-api.jar,servlet-api.jar,websocket-api.jar,\ catalina.jar,catalina-ant.jar,catalina-ha.jar,catalina-storeconfig.jar,\ catalina-tribes.jar,\ -jasper-el.jar,ecj-*.jar,\ +jasper.jar,jasper-el.jar,ecj-*.jar,\ tomcat-api.jar,tomcat-util.jar,tomcat-util-scan.jar,tomcat-coyote.jar,\ -tomcat-dbcp.jar,tomcat-jni.jar,tomcat-spdy.jar,\ +tomcat-dbcp.jar,tomcat-jni.jar,tomcat-spdy.jar,tomcat-websocket.jar,\ tomcat-i18n-en.jar,tomcat-i18n-es.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,\ tomcat-juli-adapters.jar,catalina-jmx-remote.jar,catalina-ws.jar,\ tomcat-jdbc.jar,\ Modified: tomcat/trunk/conf/context.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/context.xml?rev=1558357&r1=1558356&r2=1558357&view=diff == --- tomcat/trunk/conf/context.xml (original) +++ tomcat/trunk/conf/context.xml Wed Jan 15 12:24:13 2014 @@ -33,17 +33,4 @@ - - - - - - - - - - - Modified: tomcat/trunk/webapps/docs/config/jar-scan-filter.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/jar-scan-filter.xml?rev=1558357&r1=1558356&r2=1558357&view=diff == --- tomcat/trunk/webapps/docs/config/jar-scan-filter.xml (original) +++ tomcat/trunk/webapps/docs/config/jar-scan-filter.xml Wed Jan 15 12:24:13 2014 @@ -141,6 +141,13 @@ +Note that excluding a JAR from the pluggability scan will prevent a +ServletContainerInitializer from being loaded from a web application JAR +(i.e. one located in /WEB-INF/lib) but it will not prevent +a ServletContainerInitializer from being loaded from the container. To +prevent a ServletContainerInitializer from being loaded from the container, +use the containerSciFilter property of the Context. + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55855] Unexpected WsFilter is configured in a webapp that does not use WebSocket
https://issues.apache.org/bugzilla/show_bug.cgi?id=55855 --- Comment #3 from Mark Thomas --- A new option, containerSciFilter, has been added to the Context in 8.0.x and will be included in 8.0.0 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1558371 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java java/org/apache/catalina/startup/WebappServiceLoader.java test/org/apache/catalina/startup/TestW
Author: markt
Date: Wed Jan 15 13:09:01 2014
New Revision: 1558371
URL: http://svn.apache.org/r1558371
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55287
ServletContainerInitializer in container classloaders may not be found
Added:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
- copied, changed from r1507870,
tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/startup/TestWebappServiceLoader.java
- copied, changed from r1507870,
tomcat/trunk/test/org/apache/catalina/startup/TestWebappServiceLoader.java
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1507870,1508259,1510271,1524707,1524719,1524727
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1558371&r1=1558370&r2=1558371&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
Wed Jan 15 13:09:01 2014
@@ -16,14 +16,11 @@
*/
package org.apache.catalina.startup;
-import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
-import java.io.InputStreamReader;
-import java.io.UnsupportedEncodingException;
import java.net.JarURLConnection;
import java.net.MalformedURLException;
import java.net.URISyntaxException;
@@ -117,9 +114,6 @@ public class ContextConfig implements Li
private static final Log log = LogFactory.getLog( ContextConfig.class );
-private static final String SCI_LOCATION =
-"META-INF/services/javax.servlet.ServletContainerInitializer";
-
/**
* The string resources for this package.
@@ -1269,7 +1263,7 @@ public class ContextConfig implements Li
// Step 3. Look for ServletContainerInitializer implementations
if (ok) {
-processServletContainerInitializers(orderedFragments);
+processServletContainerInitializers(context.getServletContext());
}
if (!webXml.isMetadataComplete() || typeInitializerMap.size() > 0) {
@@ -1539,149 +1533,63 @@ public class ContextConfig implements Li
/**
* Scan JARs for ServletContainerInitializer implementations.
- * Implementations will be added in web-fragment.xml priority order.
*/
-protected void processServletContainerInitializers(
-Set fragments) {
+protected void processServletContainerInitializers(ServletContext
servletContext) {
-for (WebXml fragment : fragments) {
-URL url = fragment.getURL();
-Jar jar = null;
-InputStream is = null;
-List detectedScis = null;
+List detectedScis;
+try {
+WebappServiceLoader loader =
+new
WebappServiceLoader(servletContext);
+detectedScis = loader.load(ServletContainerInitializer.class);
+} catch (IOException e) {
+log.error(sm.getString(
+"contextConfig.servletContainerInitializerFail",
+context.getName()),
+e);
+ok = false;
+return;
+}
+
+for (ServletContainerInitializer sci : detectedScis) {
+initializerClassMap.put(sci, new HashSet>());
+
+HandlesTypes ht;
try {
-if ("jar".equals(url.getProtocol())) {
-jar = JarFactory.newInstance(url);
-is = jar.getInputStream(SCI_LOCATION);
-} else if ("file".equals(url.getProtocol())) {
-String path = url.getPath();
-File file = new File(path, SCI_LOCATION);
-if (file.exists()) {
-is = new FileInputStream(file);
-}
-}
-if (is != null) {
-detectedScis = getServletContainerInitializers(is);
-}
-} catch (IOException ioe) {
-log.error(sm.getString(
-"contextConfig.servletContainerInitializerFail", url,
-context.getName()));
-ok = false;
-return;
-} finally {
-if (is != null) {
-try {
-is.close();
-} catch (IOException e) {
-
[Bug 55287] ServletContainerInitializer in parent classloader may not be found
https://issues.apache.org/bugzilla/show_bug.cgi?id=55287 --- Comment #3 from Mark Thomas --- This has also been fixed in 7.0.x for 7.0.51 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1558379 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ test/org/apache/catalina/core/ test/org/apache/catalina/s
Author: markt
Date: Wed Jan 15 13:36:29 2014
New Revision: 1558379
URL: http://svn.apache.org/r1558379
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55855
Provide a context level option to exclude container SCIs.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/Context.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/FailedContext.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/core/TesterContext.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/startup/TestWebappServiceLoader.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/context.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1558355
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/Context.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/Context.java?rev=1558379&r1=1558378&r2=1558379&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/Context.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/Context.java Wed Jan 15
13:36:29 2014
@@ -752,9 +752,34 @@ public interface Context extends Contain
*/
public void setInstanceManager(InstanceManager instanceManager);
-// - Public Methods
+/**
+ * Sets the regular expression that specifies which container provided SCIs
+ * should be filtered out and not used for this context. Matching uses
+ * {@link java.util.regex.Matcher#find()} so the regular expression only
has
+ * to match a sub-string of the fully qualified class name of the container
+ * provided SCI for it to be filtered out.
+ *
+ * @param containerSciFilter The regular expression against which the fully
+ * qualified class name of each container
provided
+ * SCI should be checked
+ */
+public void setContainerSciFilter(String containerSciFilter);
+
+/**
+ * Obtains the regular expression that specifies which container provided
+ * SCIs should be filtered out and not used for this context. Matching uses
+ * {@link java.util.regex.Matcher#find()} so the regular expression only
has
+ * to match a sub-string of the fully qualified class name of the container
+ * provided SCI for it to be filtered out.
+ *
+ * @return The regular expression against which the fully qualified class
+ * name of each container provided SCI will be checked
+ */
+public String getContainerSciFilter();
+// - Public Methods
+
/**
* Add a new Listener class name to the set of Listeners
* configured for this application.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1558379&r1=1558378&r2=1558379&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Wed
Jan 15 13:36:29 2014
@@ -893,10 +893,24 @@ public class StandardContext extends Con
private Map preDestroyMethods =
new HashMap();
+private String containerSciFilter;
+
// - Context Properties
@Override
+public void setContainerSciFilter(String containerSciFilter) {
+this.containerSciFilter = containerSciFilter;
+}
+
+
+@Override
+public String getContainerSciFilter() {
+return containerSciFilter;
+}
+
+
+@Override
public boolean getSendRedirectBody() {
return sendRedirectBody;
}
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1558379&r1=1558378&r2=1558379&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
Wed Jan 15 13:36:29 2014
@@ -1539,7 +1539,8 @@ public class ContextConfig implements Li
List detectedScis;
try {
WebappServiceLoader loader =
[Bug 55855] Unexpected WsFilter is configured in a webapp that does not use WebSocket
https://issues.apache.org/bugzilla/show_bug.cgi?id=55855 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Thomas --- The option has been back-ported to 7.0.x and will be included in 7.0.51 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1558381 - /tomcat/trunk/java/org/apache/catalina/WebResourceSet.java
Author: markt Date: Wed Jan 15 13:41:02 2014 New Revision: 1558381 URL: http://svn.apache.org/r1558381 Log: Correct Javadoc Modified: tomcat/trunk/java/org/apache/catalina/WebResourceSet.java Modified: tomcat/trunk/java/org/apache/catalina/WebResourceSet.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/WebResourceSet.java?rev=1558381&r1=1558380&r2=1558381&view=diff == --- tomcat/trunk/java/org/apache/catalina/WebResourceSet.java (original) +++ tomcat/trunk/java/org/apache/catalina/WebResourceSet.java Wed Jan 15 13:41:02 2014 @@ -74,8 +74,7 @@ public interface WebResourceSet extends /** * Create a new resource at the requested path using the provided - * InputStream. If a resource already exists at the provided path it will - * not be overwritten. + * InputStream. * * @param path The path to be used for the new Resource. It is relative * to the root of the web application and must start with - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1679 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1558371 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5399 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1558357 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
svn commit: r1558395 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/webresources/ test/org/apache/catalina/webresources/ webapps/docs/config/
Author: markt
Date: Wed Jan 15 14:31:57 2014
New Revision: 1558395
URL: http://svn.apache.org/r1558395
Log:
Add support (with tests) for read-only web resource sets.
Added:
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java
(with props)
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java
(with props)
tomcat/trunk/test/org/apache/catalina/webresources/TestDirResourceSetReadOnly.java
(with props)
tomcat/trunk/test/org/apache/catalina/webresources/TestFileResourceSetReadOnly.java
(with props)
Modified:
tomcat/trunk/java/org/apache/catalina/WebResourceSet.java
tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResourceSet.java
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java
tomcat/trunk/java/org/apache/catalina/webresources/FileResource.java
tomcat/trunk/java/org/apache/catalina/webresources/FileResourceSet.java
tomcat/trunk/java/org/apache/catalina/webresources/LocalStrings.properties
tomcat/trunk/test/org/apache/catalina/webresources/TestDirResourceSet.java
tomcat/trunk/test/org/apache/catalina/webresources/TestFileResourceSet.java
tomcat/trunk/webapps/docs/config/resources.xml
Modified: tomcat/trunk/java/org/apache/catalina/WebResourceSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/WebResourceSet.java?rev=1558395&r1=1558394&r2=1558395&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/WebResourceSet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/WebResourceSet.java Wed Jan 15
14:31:57 2014
@@ -95,9 +95,9 @@ public interface WebResourceSet extends
* Are resources provided by this resource set only intended for use by
* calls to {@link WebResourceRoot#getClassLoaderResource(String)}.
*
- * @return true if these resources should only be used for calls to
- * {@link WebResourceRoot#getClassLoaderResource(String)},
otherwise
- * false
+ * @return true if these resources should only be used for
+ * calls to {@link WebResourceRoot#getClassLoaderResource(String)},
+ * otherwise false
*/
boolean getClassLoaderOnly();
@@ -109,4 +109,25 @@ public interface WebResourceSet extends
* manager.
*/
URL getBaseUrl();
+
+/**
+ * Configures whether or not this set of resources is read-only.
+ *
+ * @param readOnly true if this set of resources should be
+ * configured to be read-only
+ *
+ * @throws IllegalArgumentException if an attempt is made to configure a
+ * {@link WebResourceSet} that is hard-coded to be read-only as
+ * writable
+ */
+void setReadOnly(boolean readOnly);
+
+/**
+ * Obtains the current value of the read-only setting for this set of
+ * resources.
+ *
+ * @return true if this set of resources is configured to be
+ * read-only, otherwise false
+ */
+boolean isReadOnly();
}
Modified:
tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResourceSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResourceSet.java?rev=1558395&r1=1558394&r2=1558395&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResourceSet.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResourceSet.java
Wed Jan 15 14:31:57 2014
@@ -244,4 +244,20 @@ public abstract class AbstractArchiveRes
protected abstract WebResource createArchiveResource(JarEntry jarEntry,
String webAppPath, Manifest manifest);
+
+@Override
+public final boolean isReadOnly() {
+return true;
+}
+
+@Override
+public void setReadOnly(boolean readOnly) {
+if (readOnly) {
+// This is the hard-coded default - ignore the call
+return;
+}
+
+throw new IllegalArgumentException(
+sm.getString("abstractArchiveResourceSet.setReadOnlyFalse"));
+}
}
Modified:
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?rev=1558395&r1=1558394&r2=1558395&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
Wed Jan 15 14:31:57 2014
@@ -31,6 +31,7 @@ public abstract class AbstractFileResour
private File f
buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1680 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1558379 Blamelist: markt Build succeeded! sincerely, -The Buildbot
Re: Context switch integration
2014/1/15 Mark Thomas > > If folks integrating with Tomcat need to extend / replace what is > currently in StandardContext.bindThread() and > StandardContext.unbindThread() having a listener for this rather than > having to extend StandardContext makes sense to me. > Ok. > > I'm not sure I follow what you are proposing for PAs. > > Nothing, if a utility class was doing the PA itself to make it easier and do PA + setContextCL + call the listener, there would be more PAs (maybe a performance impact). Rémy
[jira] [Created] (MTOMCAT-255) Getting tTarget Unreachable, identifier 'managedBean' resolved to null on tomcat:run but not in tomcat:run-war
Gilberto C Andrade created MTOMCAT-255: -- Summary: Getting tTarget Unreachable, identifier 'managedBean' resolved to null on tomcat:run but not in tomcat:run-war Key: MTOMCAT-255 URL: https://issues.apache.org/jira/browse/MTOMCAT-255 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.2 Environment: gilberto.andrade@A37710:~$ mvn -version Apache Maven 3.0.4 (r1232337; 2012-01-17 05:44:56-0300) Maven home: /home/gilberto.andrade/bin/maven Java version: 1.7.0_45, vendor: Oracle Corporation Java home: /usr/java/jdk1.7.0_45/jre Default locale: pt_BR, platform encoding: UTF-8 OS name: "linux", version: "3.7.10-1.24-desktop", arch: "amd64", family: "unix" Reporter: Gilberto C Andrade Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. 1 Run mvn clean tomcat7:run 2 hitting http://localhost:8080/consulta-prototipo/pessoaView.xhtml 3 enter some value on field or click the consultar button The same steps works when using tomcat7:run-war. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-255) Getting tTarget Unreachable, identifier 'managedBean' resolved to null on tomcat:run but not in tomcat:run-war
[ https://issues.apache.org/jira/browse/MTOMCAT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilberto C Andrade updated MTOMCAT-255: --- Description: Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. 1 Run mvn clean tomcat7:run 2 hitting http://localhost:8080/MTOMCAT-255/pessoaView.xhtml 3 enter some value on field or click the consultar button The same steps works when using tomcat7:run-war. was: Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. 1 Run mvn clean tomcat7:run 2 hitting http://localhost:8080/consulta-prototipo/pessoaView.xhtml 3 enter some value on field or click the consultar button The same steps works when using tomcat7:run-war. > Getting tTarget Unreachable, identifier 'managedBean' resolved to null on > tomcat:run but not in tomcat:run-war > -- > > Key: MTOMCAT-255 > URL: https://issues.apache.org/jira/browse/MTOMCAT-255 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.2 > Environment: gilberto.andrade@A37710:~$ mvn -version > Apache Maven 3.0.4 (r1232337; 2012-01-17 05:44:56-0300) > Maven home: /home/gilberto.andrade/bin/maven > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: /usr/java/jdk1.7.0_45/jre > Default locale: pt_BR, platform encoding: UTF-8 > OS name: "linux", version: "3.7.10-1.24-desktop", arch: "amd64", family: > "unix" >Reporter: Gilberto C Andrade >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > > Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. > 1 Run mvn clean tomcat7:run > 2 hitting http://localhost:8080/MTOMCAT-255/pessoaView.xhtml > 3 enter some value on field or click the consultar button > The same steps works when using tomcat7:run-war. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Status of cookies proposals
On Jan 15, 2014, at 2:38 AM, Mark Thomas wrote: > Does any one have anything else to add to > http://wiki.apache.org/tomcat/Cookies ? It feels like we should be > looking to make some decisions on where to go with this. There are two things on my mind I’ve not had a chance to write up yet: 1) Clearer distinction between name-only and value-only cookies. Existing code treats a name-value pair of «X» as being name-only but the browsers treat that as being the value of a cookie-with-no-name. 2) How to handle cookies whose name might be valid RF6265 but won’t be allowed by Cookie’s constructor e.g. «Expires», «$Foo» or the «» name from above. If an application sub-classes Cookie so getName() returns such a value, will we still generate the header as we currently do? If the browser sends such a header should we just drop it (meaning the app would need to parse the Cookie header itself and it’s not round-trippable), or should we allow it (which would mean we would need a sub-class, see C1a)? > My $0.02 to start this discussion is that we should adopt the all of the > proposed changes with the following notes: > - C1 rather C1a > - G1a rather than G1 > (we need to keep an option to switch for backwards compatibility) > - G3a rather than G3 > (Tomcat currently handles quoting / escaping for RFC2109 cookies so > it needs to continue to do so for backwards compatibility) The concern I have with G1a and G3a is that the browsers are not round-tripping the cookies in RFC2109 format. So although we can add quotes to make it a valid RFC2109 value when we send it, when we get it back we will see a RFC6265 format header with no indicator on whether the quotes were there originally or if we added them. The best I’ve come up with, which seems lame, is to have individual flags controlling this behaviour: * escape-on-write, when enabled would escape any non-cookie-octet values, implies quote-on-write * quote-on-write, when enabled would add dquotes to anything with a non-cookie-octet value * unquote-on-read, when enabled would remove leading and trailing quotes * unescape-on-read, when enabled would also replace any ‘\’ escaped characters, implies unquote-on-read This would allow an application owner to run in one of three modes: * new, where client and server views of the value are the same * compatible, where client sees quoted and server sees unquoted * transitional, where quotes are stripped on read and no longer added on write In “transitional" mode, the browser would send a quoted value previously set, we would strip the quotes when returning the value to the application, the application would re-set the cookie, we would send that without quotes, and any client-side code working with that response would always see the new unquoted value. An application could transition by switching directly to “new” mode where we would pass it the quoted value and it would handle removing the quotes. That would give it more control but would require code changes. signature.asc Description: Message signed with OpenPGP using GPGMail
[jira] [Updated] (MTOMCAT-255) Getting tTarget Unreachable, identifier 'managedBean' resolved to null on tomcat:run but not in tomcat:run-war
[ https://issues.apache.org/jira/browse/MTOMCAT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilberto C Andrade updated MTOMCAT-255: --- Attachment: MTOMCAT-255.zip > Getting tTarget Unreachable, identifier 'managedBean' resolved to null on > tomcat:run but not in tomcat:run-war > -- > > Key: MTOMCAT-255 > URL: https://issues.apache.org/jira/browse/MTOMCAT-255 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.2 > Environment: gilberto.andrade@A37710:~$ mvn -version > Apache Maven 3.0.4 (r1232337; 2012-01-17 05:44:56-0300) > Maven home: /home/gilberto.andrade/bin/maven > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: /usr/java/jdk1.7.0_45/jre > Default locale: pt_BR, platform encoding: UTF-8 > OS name: "linux", version: "3.7.10-1.24-desktop", arch: "amd64", family: > "unix" >Reporter: Gilberto C Andrade >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: MTOMCAT-255.zip > > > Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. > 1 Run mvn clean tomcat7:run > 2 hitting http://localhost:8080/MTOMCAT-255/pessoaView.xhtml > 3 enter some value on field or click the consultar button > The same steps works when using tomcat7:run-war. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-255) Getting "Target Unreachable, identifier 'pessoaBean' resolved to null" on tomcat:run but not in tomcat:run-war
[ https://issues.apache.org/jira/browse/MTOMCAT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilberto C Andrade updated MTOMCAT-255: --- Summary: Getting "Target Unreachable, identifier 'pessoaBean' resolved to null" on tomcat:run but not in tomcat:run-war (was: Getting tTarget Unreachable, identifier 'managedBean' resolved to null on tomcat:run but not in tomcat:run-war) > Getting "Target Unreachable, identifier 'pessoaBean' resolved to null" on > tomcat:run but not in tomcat:run-war > -- > > Key: MTOMCAT-255 > URL: https://issues.apache.org/jira/browse/MTOMCAT-255 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.2 > Environment: gilberto.andrade@A37710:~$ mvn -version > Apache Maven 3.0.4 (r1232337; 2012-01-17 05:44:56-0300) > Maven home: /home/gilberto.andrade/bin/maven > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: /usr/java/jdk1.7.0_45/jre > Default locale: pt_BR, platform encoding: UTF-8 > OS name: "linux", version: "3.7.10-1.24-desktop", arch: "amd64", family: > "unix" >Reporter: Gilberto C Andrade >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: MTOMCAT-255.zip > > > Simple JSF 2.2 project with just one manage bean(PessoaMb) and one xhtml page. > 1 Run mvn clean tomcat7:run > 2 hitting http://localhost:8080/MTOMCAT-255/pessoaView.xhtml > 3 enter some value on field or click the consultar button > The same steps works when using tomcat7:run-war. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5401 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1558395 Blamelist: markt Build succeeded! sincerely, -The Buildbot
Re: Status of cookies proposals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/01/2014 16:58, Jeremy Boynes wrote: > On Jan 15, 2014, at 2:38 AM, Mark Thomas wrote: > >> Does any one have anything else to add to >> http://wiki.apache.org/tomcat/Cookies ? It feels like we should >> be looking to make some decisions on where to go with this. > > There are two things on my mind I’ve not had a chance to write up > yet: OK. No rush. Better we get everything sorted before we start coding. > 1) Clearer distinction between name-only and value-only cookies. > Existing code treats a name-value pair of «X» as being name-only > but the browsers treat that as being the value of a > cookie-with-no-name. This could be problematic. We have had explicit requests for name only cookie support. > 2) How to handle cookies whose name might be valid RF6265 but won’t > be allowed by Cookie’s constructor e.g. «Expires», «$Foo» or the «» > name from above. If an application sub-classes Cookie so getName() > returns such a value, will we still generate the header as we > currently do? If the browser sends such a header should we just > drop it (meaning the app would need to parse the Cookie header > itself and it’s not round-trippable), or should we allow it (which > would mean we would need a sub-class, see C1a)? Remind me why aren't those allowable. Looking at the Javadoc, the default is RFC2109 but we can optionally support Netscape. >> My $0.02 to start this discussion is that we should adopt the all >> of the proposed changes with the following notes: - C1 rather >> C1a - G1a rather than G1 (we need to keep an option to switch for >> backwards compatibility) - G3a rather than G3 (Tomcat currently >> handles quoting / escaping for RFC2109 cookies so it needs to >> continue to do so for backwards compatibility) > > The concern I have with G1a and G3a is that the browsers are not > round-tripping the cookies in RFC2109 format. So although we can > add quotes to make it a valid RFC2109 value when we send it, when > we get it back we will see a RFC6265 format header with no > indicator on whether the quotes were there originally or if we > added them. Browsers might not be but browsers are not the only user agents used with Tomcat. Generally, I'd like to avoid anything that will break existing functionality unless a configuration option is available to provide backwards compatibility. > The best I’ve come up with, which seems lame, is to have individual > flags controlling this behaviour: * escape-on-write, when enabled > would escape any non-cookie-octet values, implies quote-on-write * > quote-on-write, when enabled would add dquotes to anything with a > non-cookie-octet value * unquote-on-read, when enabled would remove > leading and trailing quotes * unescape-on-read, when enabled would > also replace any ‘\’ escaped characters, implies unquote-on-read > > This would allow an application owner to run in one of three > modes: * new, where client and server views of the value are the > same * compatible, where client sees quoted and server sees > unquoted * transitional, where quotes are stripped on read and no > longer added on write > > In “transitional" mode, the browser would send a quoted value > previously set, we would strip the quotes when returning the value > to the application, the application would re-set the cookie, we > would send that without quotes, and any client-side code working > with that response would always see the new unquoted value. > > An application could transition by switching directly to “new” mode > where we would pass it the quoted value and it would handle > removing the quotes. That would give it more control but would > require code changes. I'm not a fan of that either. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1tVlAAoJEBDAHFovYFnnhAQP/3CljClDnU8uP25lHM6b3EuV jTPdQda0gFMKIfYCi6WEOwl+r1XOOwGW3ZYrc0WuohyEUuZUViv6pPxRJXJofVbu EosOJ+nEry77fgRoNDzKND+R+/mgaEMOYMZKOL74XC6BKNnu5fq2NOI+ddRwsvvJ CZScia/oLi+ZDogngCZV1dk5iTI+v0pif0ad2FSIQsYsBFwMXCwtUvfM5DMo6dOn a/m3ND4ia1PGxrdeAUsUlYkRoydP7AS1wkF5BPcpXP7pSyldgF4MFdKVtlNknOmA t3Y0EE2S31ZSRjrrHOoUJdRhCuQDBJ7Xx7iQuMYA2LPSbsb5GvAnbyauFCO909nT 43jaCC+qMfGi9ZTlfnL6FpfCftGrJeYATD5N8l3WRVma0Ff6Rb5Nq9qX/XsZq6ea Hl/gNvl17Bsli7VRIOOCDlj3M92j4obyw21gGCUBVzOruHRuAYm/M7wpy7YoCwDA U7T4WYSortvfZNz3dHQ2UbewNvJall4YGBC2NXCUEiQw1zaiWbv8tZV8wFs/MXnV TuzgDPPP20m4QZbxgkxpyYxY6rytmzg+KEdGulpgaAAdVPejl2M1dIeJtiwYI3TH 91/CpDR0w8DBkLpytECKXu5+SOLb+TrepieCSwwwXnRUcXJ2ywEIagJu/l4I9l6Z hffjNkZxg6pE/hcdtK9j =0o2e -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: name only cookies
On Jan 15, 2014, at 10:37 AM, Mark Thomas wrote: > On 15/01/2014 16:58, Jeremy Boynes wrote: > > > 1) Clearer distinction between name-only and value-only cookies. > > Existing code treats a name-value pair of «X» as being name-only > > but the browsers treat that as being the value of a > > cookie-with-no-name. > > This could be problematic. We have had explicit requests for name only > cookie support. Sorry, I was rushing so perhaps wasn’t clear. Based on where things end up being stored client-side, browsers seem to treat: «X» as unnamed with just a value, same as «=X» although they do not actually send that «X=» as named with no value «X=“”» as named with a value comprising 2 dquotes On write, although Cookie will not allow the first form, it can be sub-classed so getName() could return null or an empty String. As an application actually had to create and use a sub-class to do that, there’s an argument we should respect their intent by writing the anonymous cookie (i.e. «value»), at least if version == 0; I’m not sure I buy that argument, just calling it out as we allow it now (addCookie() does not recheck the name). If getValue() returns null or an empty String, then the application is setting a name-only cookie and: * for V0, we emit «name=» * for V1, we either emit «name=“”» if auto-quoting is enabled or throw an IAE if not (as it is not a valid VALUE). On read, if there is a ‘=‘ present then everything before it is the name and everything after is the value. The change would be that «value» would now be treated as a value-only cookie rather than a name-only one. However, Cookie’s constructor won’t allow an empty name so if we are going to return it to the application we would need to use a sub-class to bypass the checks. My proposal would be to drop the cookie by default, potentially with a property to enable a value-only cookie. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: allowed cookie names
On Jan 15, 2014, at 10:37 AM, Mark Thomas wrote: > On 15/01/2014 16:58, Jeremy Boynes wrote: > > 2) How to handle cookies whose name might be valid RF6265 but won’t > > be allowed by Cookie’s constructor e.g. «Expires», «$Foo» or the «» > > name from above. If an application sub-classes Cookie so getName() > > returns such a value, will we still generate the header as we > > currently do? If the browser sends such a header should we just > > drop it (meaning the app would need to parse the Cookie header > > itself and it’s not round-trippable), or should we allow it (which > > would mean we would need a sub-class, see C1a)? > > Remind me why aren't those allowable. Looking at the Javadoc, the > default is RFC2109 but we can optionally support Netscape. RFC2109 syntax allows names starting with “$” but there’s a semantic constraint in 4.2.2 that says they are reserved so rejecting those seems right. The JavaDoc refers to "matches a token reserved for use by the cookie protocol” which we’ve taken to include the attributes names but strictly they are a different part of the protocol and there is no ambiguity. I think we are being over restrictive here in excluding them; IMO it may be confusing but it is valid. Strictly Netscape does not preclude an empty name either so perhaps turning that mode on should also allow that by suppressing the "null or empty” clause in the JavaDoc. This would also address the value-only cookie problem and allow them to be round-tripped. We could make STRICT_NAMING multi-valued: - if it’s “false” or “netscape” allow anything per Netscape’s spec including empty - if it’s “true” or “rfc2109” allow anything per RFC2109 (i.e. token and not starting with ‘$’) - if it’s unset or “rfc6265” allow anything per RFC6265 (i.e. token and may start with ‘$’) with STRICT_SERVLET_COMPLIANCE implying "rfc2109" signature.asc Description: Message signed with OpenPGP using GPGMail
[Bug 56016] New: DigesterFactory.idFor(...) assumes that javax.servlet.jsp.resources.** are available from the same class loader that defines javax.servlet.ServletContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=56016 Bug ID: 56016 Summary: DigesterFactory.idFor(...) assumes that javax.servlet.jsp.resources.** are available from the same class loader that defines javax.servlet.ServletContext Product: Tomcat 7 Version: 7.0.50 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: dmitri.bourlatch...@gmail.com Created attachment 31214 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31214&action=edit Patch for DigesterFactory.ifFor(...) method to relax assumptions related to class loading The idFor(String url) method in org.apache.tomcat.util.descriptor.DigesterFactory appears to try loading resources from the javax.servlet.jsp.resources package using the defining class loader of javax.servlet.ServletContext. This is perfectly fine for standalone Tomcat, of course. However, in our application we run embedded Tomcat in an isolated class loader, which includes all of Tomcat's jar files _except_ servlet-api.jar. servlet-api.jar is part of the class loader that is a parent of the class loader for the embedded Tomcat. Tomcat 7.0.47 worked well in this setup. However in 7.0.50 we hit exceptions like the following: java.lang.ExceptionInInitializerError at org.apache.catalina.startup.TldConfig.createTldDigester(TldConfig.java:94) at org.apache.catalina.startup.TldConfig.init(TldConfig.java:576) at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:559) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:634) [...] Caused by: java.lang.NullPointerException at org.apache.tomcat.util.descriptor.DigesterFactory.idFor(DigesterFactory.java:107) at org.apache.tomcat.util.descriptor.DigesterFactory.(DigesterFactory.java:59) ... 25 more The reason why the resource is not found is apparently that the class loader of ServletContext does not 'see' resources from jsp-api.jar. We can work around that by placing jsp-api.jar into the same class loader that has servlet-api.jar, however this workaround is not ideal from our design perspective. >From the source of the idFor(...) method one could guess that the fallback attempt to find the requested resource in the javax.servlet.jsp.resources package is meant to look in jsp-api.jar. For that reason, would it be appropriate to perform the fallback lookup in the defining class loader of javax.servlet.jsp.JspContext? A patch file for the proposed fix is attached. If it is accepted please credit Juan Carlos Estibariz with it. -- 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 56016] DigesterFactory.idFor(...) assumes that javax.servlet.jsp.resources.** are available from the same class loader that defines javax.servlet.ServletContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=56016 --- Comment #1 from Dmitri Bourlatchkov --- The affected url parameter for the idFor(...) method in this case is "web-jsptaglibrary_1_1.dtd" -- 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
