Re: svn commit: r1491940 - in /tomcat/trunk: java/org/apache/catalina/core/AsyncContextImpl.java java/org/apache/catalina/core/LocalStrings.properties test/org/apache/catalina/core/TestAsyncContextImp
2013/6/11 ma...@apache.org Author: markt Date: Tue Jun 11 20:18:10 2013 New Revision: 1491940 URL: http://svn.apache.org/r1491940 Log: Servlet 3.1 requires an ISE if getRequest() or getResponse() are called after complete() or dispatch() Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java?rev=1491940r1=1491939r2=1491940view=diff == --- tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java (original) +++ tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java Tue Jun 11 20:18:10 2013 @@ -64,8 +64,8 @@ public class AsyncContextImpl implements protected static final StringManager sm = StringManager.getManager(Constants.Package); -private ServletRequest servletRequest = null; -private ServletResponse servletResponse = null; +private volatile ServletRequest servletRequest = null; +private volatile ServletResponse servletResponse = null; private final ListAsyncListenerWrapper listeners = new ArrayList(); private boolean hasOriginalRequestAndResponse = true; private volatile Runnable dispatch = null; @@ -90,6 +90,7 @@ public class AsyncContextImpl implements check(); request.getCoyoteRequest().action(ActionCode.COMMIT, null); request.getCoyoteRequest().action(ActionCode.ASYNC_COMPLETE, null); +clearServletRequestResposne(); } Is that mean that if I have AsyncListener that does some work in onComplete() then I will not be able to use the request and response objects? Thanks Violeta
Re: svn commit: r1492331 - in /tomcat/tc7.0.x/trunk: ./ java/javax/servlet/ java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/catalina/deploy/ java/org/apache/catalina/startup/
2013/6/12 ma...@apache.org
Author: markt
Date: Wed Jun 12 18:31:30 2013
New Revision: 1492331
URL: http://svn.apache.org/r1492331
Log:
With clarification from the EG for Servlet 3.1 section 4.4 finally makes
sense. Implement the necessary restriction and add a test case.
I think that we should provide the same restriction for the
ServletContextListeners that are not described in web.xml/web-fragment.xml
or are not annotated. For example such listeners can be added by
ServletContainerInitializer.
What do you think?
o.a.catalina.core.ApplicationContext.addListener(T t)
...
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
-context.addApplicationLifecycleListener(t);
match = true;
}
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 03:31, Christopher Schultz wrote: It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. That is what ServletContainerIniiializers are for. They only handle class files but the other types (e.g. TLDs) are always in known locations and are inexpensive to find. The expensive bit is scanning all the classes and SCIs provide a mechanism to do that only once for all interested parties. Another option would be to have a scanner that would scan for everything and then notify registered listeners. If you only care about TLDs, you just register a TLD listener. For classes, you register a class listener. A listener-based scanner would even open the doors for a webapp to be able to register its own listeners to sniff scanner events during context startup. That is exactly what SCIs do. I know this all sounds way over-engineered, but there are quite a few webapps that, when they first launch, go ahead and scan the entire reachable class loader hierarchy for classes with annotations, etc. so you get this environment where the same classes are being scanner over and over and over again just because they have to be scanned in different places for different reasons. Then the libraries doing the scanning need to be updated to use the container provided scanning mechanism that is already in place. I spoke with David Blevins about this way back in Vancouver: applications that endlessly perform JAR scanning just because the components can't seem to coordinate with each other. If there were a scanner component that could allow these unrelated components to share infrastructure, we could all save a lot of time. Such a scanning component could, much like the Digester, graduate from Tomcat and become more widely useful. I really don't see the need for this at all given that SCIs are available. If there are use cases that SCIs don't meet then extending SCIs is the way to go so the same feature is available in any container. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
i think all containers actually hack this part since it doesn't match the need when you are just a little bit bigger than tomcat. today almost all apps scans (even spring ;) so would be great to get a nicer scanner. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 03:31, Christopher Schultz wrote: It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. That is what ServletContainerIniiializers are for. They only handle class files but the other types (e.g. TLDs) are always in known locations and are inexpensive to find. The expensive bit is scanning all the classes and SCIs provide a mechanism to do that only once for all interested parties. Another option would be to have a scanner that would scan for everything and then notify registered listeners. If you only care about TLDs, you just register a TLD listener. For classes, you register a class listener. A listener-based scanner would even open the doors for a webapp to be able to register its own listeners to sniff scanner events during context startup. That is exactly what SCIs do. I know this all sounds way over-engineered, but there are quite a few webapps that, when they first launch, go ahead and scan the entire reachable class loader hierarchy for classes with annotations, etc. so you get this environment where the same classes are being scanner over and over and over again just because they have to be scanned in different places for different reasons. Then the libraries doing the scanning need to be updated to use the container provided scanning mechanism that is already in place. I spoke with David Blevins about this way back in Vancouver: applications that endlessly perform JAR scanning just because the components can't seem to coordinate with each other. If there were a scanner component that could allow these unrelated components to share infrastructure, we could all save a lot of time. Such a scanning component could, much like the Digester, graduate from Tomcat and become more widely useful. I really don't see the need for this at all given that SCIs are available. If there are use cases that SCIs don't meet then extending SCIs is the way to go so the same feature is available in any container. Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 08:18, Romain Manni-Bucau wrote: i think all containers actually hack this part since it doesn't match the need when you are just a little bit bigger than tomcat. What requirements can't be met with an SCI? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 04:05, Nick Williams wrote: On Jun 13, 2013, at 11:23 AM, Mark Thomas wrote: As I make my way through the Servlet 3.1 spec reviewing all the changes to make sure they have all been implemented, I have reached section 8.2. There are a number of related issues here. 1. Three known issues with the current SCI / fragment handling [1] - SCI scan does not obey class loader ordering - fragments in container JARs are processed - Container SCIs may be exluded 2. A wish for per context jarsToSkip [2] 3. A wish for greater control over jarsToSkip [3] These issues are all inter-related. Fixing them is going to require either some very ugly hacks or changes to the JarScanner API. I have started down the route of the JAR scanner API changes. The overall idea is: - jarsToSkip is replaced by a JarScanFilter with the default implementation doing what jarsToSkip currently does I would request doing what jarsToSkip currently does plus what is wanted with jarsToScan in 3. If it wasn't clear from my original e-mail, that is exactly what these changes are intended to do. It shouldn't be extra complicated or require re- or duplicate-configuration of anything to whitelist one JAR. It is in no-ones interest to make anything more complicated than it needs to be. If a user wants to whitelist one JAR they are going to have to reconfigure something. Tomcat can't read minds. I agree duplicating configuration is something to be avoided where practical. Also, it's very important that log4j-core*.jar and log4j-taglib*.jar be whitelisted by default. I agree we don't want to exclude those JARs from scanning by default. Whitelisting isn't the only way of doing that. A less broad entry in the skip list would achieve the same result. That said, using whitelisting for these would be a nice example to users of how it works. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1491940 - in /tomcat/trunk: java/org/apache/catalina/core/AsyncContextImpl.java java/org/apache/catalina/core/LocalStrings.properties test/org/apache/catalina/core/TestAsyncContextImp
On 14/06/2013 07:00, Violeta Georgieva wrote: 2013/6/11 ma...@apache.org Author: markt Date: Tue Jun 11 20:18:10 2013 New Revision: 1491940 URL: http://svn.apache.org/r1491940 Log: Servlet 3.1 requires an ISE if getRequest() or getResponse() are called after complete() or dispatch() Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java?rev=1491940r1=1491939r2=1491940view=diff == --- tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java (original) +++ tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java Tue Jun 11 20:18:10 2013 @@ -64,8 +64,8 @@ public class AsyncContextImpl implements protected static final StringManager sm = StringManager.getManager(Constants.Package); -private ServletRequest servletRequest = null; -private ServletResponse servletResponse = null; +private volatile ServletRequest servletRequest = null; +private volatile ServletResponse servletResponse = null; private final ListAsyncListenerWrapper listeners = new ArrayList(); private boolean hasOriginalRequestAndResponse = true; private volatile Runnable dispatch = null; @@ -90,6 +90,7 @@ public class AsyncContextImpl implements check(); request.getCoyoteRequest().action(ActionCode.COMMIT, null); request.getCoyoteRequest().action(ActionCode.ASYNC_COMPLETE, null); +clearServletRequestResposne(); } Is that mean that if I have AsyncListener that does some work in onComplete() then I will not be able to use the request and response objects? Yes and no. You can't call getRequest() or getResponse() on the AsyncContext but you can get the objects from getSuppliedRequest() and getSuppliedResposne() on the AsyncEvent object. The Tomcat unit tests were updated to do things this way as a number of them started failing as they were calling getRequest() or getResponse() during onComplete() Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
wait SCIs stands for ServletContainerInitializer right? if so just think all apps are not only webapps (ear typically) + the issue is really tomcat scanning shouldn't occur if already done (or the opposite, myfaces should reuse tomcat scanned info is here, cxf, spring, cdi container...). *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 08:18, Romain Manni-Bucau wrote: i think all containers actually hack this part since it doesn't match the need when you are just a little bit bigger than tomcat. What requirements can't be met with an SCI? Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492973 - in /tomcat/trunk/java/org/apache: catalina/startup/ContextConfig.java catalina/startup/TldConfig.java jasper/compiler/TldLocationsCache.java tomcat/JarScanner.java tomcat/util/s
Author: markt
Date: Fri Jun 14 07:38:09 2013
New Revision: 1492973
URL: http://svn.apache.org/r1492973
Log:
Remove class loader from the scan method as class loader is accessible
from ServletContext.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
tomcat/trunk/java/org/apache/tomcat/JarScanner.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
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=1492973r1=1492972r2=1492973view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
07:38:09 2013
@@ -2042,8 +2042,7 @@ public class ContextConfig implements Li
JarScanner jarScanner = context.getJarScanner();
FragmentJarScannerCallback callback = new FragmentJarScannerCallback();
-jarScanner.scan(context.getServletContext(),
-context.getLoader().getClassLoader(), callback,
+jarScanner.scan(context.getServletContext(), callback,
pluggabilityJarsToSkip);
return callback.getFragments();
Modified: tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java?rev=1492973r1=1492972r2=1492973view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java Fri Jun 14
07:38:09 2013
@@ -263,7 +263,6 @@ public final class TldConfig implements
// Stages 3b 4
JarScanner jarScanner = context.getJarScanner();
jarScanner.scan(context.getServletContext(),
-context.getLoader().getClassLoader(),
new TldJarScannerCallback(), noTldJars);
// Now add all the listeners we found to the listeners for this context
Modified: tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java?rev=1492973r1=1492972r2=1492973view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java Fri Jun
14 07:38:09 2013
@@ -242,9 +242,7 @@ public class TldLocationsCache {
JarScanner jarScanner = JarScannerFactory.getJarScanner(ctxt);
if (jarScanner != null) {
-jarScanner.scan(ctxt,
-Thread.currentThread().getContextClassLoader(),
-new TldJarScannerCallback(), noTldJars);
+jarScanner.scan(ctxt, new TldJarScannerCallback(), noTldJars);
}
initialized = true;
Modified: tomcat/trunk/java/org/apache/tomcat/JarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/JarScanner.java?rev=1492973r1=1492972r2=1492973view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/JarScanner.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/JarScanner.java Fri Jun 14 07:38:09 2013
@@ -33,12 +33,10 @@ public interface JarScanner {
*
* @param context The ServletContext - used to locate and access
* WEB-INF/lib
- * @param classloader The classloader - used to access JARs not in
- * WEB-INF/lib
* @param callback The handler to process any JARs found
* @param jarsToSkipList of JARs to ignore
*/
-public void scan(ServletContext context, ClassLoader classloader,
-JarScannerCallback callback, SetString jarsToSkip);
+public void scan(ServletContext context, JarScannerCallback callback,
+SetString jarsToSkip);
}
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1492973r1=1492972r2=1492973view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java Fri
Jun 14 07:38:09 2013
@@ -127,16 +127,14 @@ public class StandardJarScanner implemen
*
* @param context The
Re: svn commit: r1491940 - in /tomcat/trunk: java/org/apache/catalina/core/AsyncContextImpl.java java/org/apache/catalina/core/LocalStrings.properties test/org/apache/catalina/core/TestAsyncContextImp
2013/6/14 Mark Thomas wrote: On 14/06/2013 07:00, Violeta Georgieva wrote: Is that mean that if I have AsyncListener that does some work in onComplete() then I will not be able to use the request and response objects? Yes and no. You can't call getRequest() or getResponse() on the AsyncContext but you can get the objects from getSuppliedRequest() and getSuppliedResposne() on the AsyncEvent object. The Tomcat unit tests were updated to do things this way as a number of them started failing as they were calling getRequest() or getResponse() during onComplete() Mark Agh You are right. Thanks
svn commit: r1492974 - /tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Author: markt
Date: Fri Jun 14 07:38:41 2013
New Revision: 1492974
URL: http://svn.apache.org/r1492974
Log:
Already skipped WEB-INF/lib so no need to skip those JARs again
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1492974r1=1492973r2=1492974view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java Fri
Jun 14 07:38:41 2013
@@ -227,12 +227,9 @@ public class StandardJarScanner implemen
// Extract the jarName if there is one to be found
String jarName = getJarName(urls[i]);
-// Skip JARs known not to be interesting and JARs
-// in WEB-INF/lib we have already scanned
-if (jarName != null
-!(Matcher.matchPath(ignoredJarsTokens, jarName) ||
-urls[i].toString().contains(
-Constants.WEB_INF_LIB + jarName))) {
+// Skip JARs known not to be interesting
+if (jarName != null !Matcher.matchPath(
+ignoredJarsTokens, jarName)) {
if (log.isDebugEnabled()) {
log.debug(sm.getString(jarScan.classloaderJarScan, urls[i]));
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492975 - in /tomcat/trunk/java/org/apache: catalina/startup/ContextConfig.java catalina/startup/TldConfig.java jasper/compiler/TldLocationsCache.java tomcat/JarScannerCallback.java tomca
Author: markt
Date: Fri Jun 14 07:39:32 2013
New Revision: 1492975
URL: http://svn.apache.org/r1492975
Log:
Enable client of JarScanner to determine if JAR is part of a web
application or provided by the container.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
tomcat/trunk/java/org/apache/tomcat/JarScannerCallback.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
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=1492975r1=1492974r2=1492975view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
07:39:32 2013
@@ -2743,7 +2743,8 @@ public class ContextConfig implements Li
private final MapString,WebXml fragments = new HashMap();
@Override
-public void scan(JarURLConnection jarConn) throws IOException {
+public void scan(JarURLConnection jarConn, boolean isWebapp)
+throws IOException {
URL url = jarConn.getURL();
URL resourceURL = jarConn.getJarFileURL();
@@ -2790,7 +2791,7 @@ public class ContextConfig implements Li
}
@Override
-public void scan(File file) throws IOException {
+public void scan(File file, boolean isWebapp) throws IOException {
InputStream stream = null;
WebXml fragment = new WebXml();
Modified: tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java?rev=1492975r1=1492974r2=1492975view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java Fri Jun 14
07:39:32 2013
@@ -287,12 +287,13 @@ public final class TldConfig implements
private class TldJarScannerCallback implements JarScannerCallback {
@Override
-public void scan(JarURLConnection urlConn) throws IOException {
+public void scan(JarURLConnection urlConn, boolean isWebapp)
+throws IOException {
tldScanJar(urlConn);
}
@Override
-public void scan(File file) {
+public void scan(File file, boolean isWebapp) {
File metaInf = new File(file, META-INF);
if (metaInf.isDirectory()) {
tldScanDir(metaInf);
Modified: tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java?rev=1492975r1=1492974r2=1492975view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java Fri Jun
14 07:39:32 2013
@@ -255,12 +255,13 @@ public class TldLocationsCache {
private class TldJarScannerCallback implements JarScannerCallback {
@Override
-public void scan(JarURLConnection urlConn) throws IOException {
+public void scan(JarURLConnection urlConn, boolean isWebapp)
+throws IOException {
tldScanJar(urlConn);
}
@Override
-public void scan(File file) throws IOException {
+public void scan(File file, boolean isWebapp) throws IOException {
File metaInf = new File(file, META-INF);
if (metaInf.isDirectory()) {
tldScanDir(metaInf);
Modified: tomcat/trunk/java/org/apache/tomcat/JarScannerCallback.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/JarScannerCallback.java?rev=1492975r1=1492974r2=1492975view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/JarScannerCallback.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/JarScannerCallback.java Fri Jun 14
07:39:32 2013
@@ -31,17 +31,24 @@ public interface JarScannerCallback {
* further processing via the provided URL connection.
*
* @param urlConn The connection to the identified JAR
+ * @param isWebapp Indicates if the JAR was found within a web
application.
+ * If codefalse/code the JAR should be treated as
+ * being provided by the container
*/
-public void scan(JarURLConnection urlConn) throws IOException;
+public void
svn commit: r1492976 - in /tomcat/trunk/java/org/apache: catalina/startup/TldConfig.java jasper/compiler/TldLocationsCache.java
Author: markt
Date: Fri Jun 14 07:40:09 2013
New Revision: 1492976
URL: http://svn.apache.org/r1492976
Log:
Add a comment on TLD JARs since no distinction is made between
TLDs provided by an application and by the container.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java?rev=1492976r1=1492975r2=1492976view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java Fri Jun 14
07:40:09 2013
@@ -289,11 +289,15 @@ public final class TldConfig implements
@Override
public void scan(JarURLConnection urlConn, boolean isWebapp)
throws IOException {
+// Note: TLDs are processed the same way for application and
+// container provided JARs.
tldScanJar(urlConn);
}
@Override
public void scan(File file, boolean isWebapp) {
+// Note: TLDs are processed the same way for application and
+// container provided JARs.
File metaInf = new File(file, META-INF);
if (metaInf.isDirectory()) {
tldScanDir(metaInf);
Modified: tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java?rev=1492976r1=1492975r2=1492976view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java Fri Jun
14 07:40:09 2013
@@ -257,11 +257,15 @@ public class TldLocationsCache {
@Override
public void scan(JarURLConnection urlConn, boolean isWebapp)
throws IOException {
+// Note: TLDs are processed the same way for application and
+// container provided JARs.
tldScanJar(urlConn);
}
@Override
public void scan(File file, boolean isWebapp) throws IOException {
+// Note: TLDs are processed the same way for application and
+// container provided JARs.
File metaInf = new File(file, META-INF);
if (metaInf.isDirectory()) {
tldScanDir(metaInf);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492977 - /tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Author: markt
Date: Fri Jun 14 07:40:40 2013
New Revision: 1492977
URL: http://svn.apache.org/r1492977
Log:
Shared loader should be treated as a source of application JARs
Commons and Server loaders should be treated as a source of container
JARs
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1492977r1=1492976r2=1492977view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java Fri
Jun 14 07:40:40 2013
@@ -220,8 +220,15 @@ public class StandardJarScanner implemen
// already scanned WEB-INF/lib and WEB-INF/classes
classLoader = classLoader.getParent();
+// JARs are treated as application provided until the common class
+// loader is reached.
+boolean isWebapp = true;
+
while (classLoader != null classLoader != stopLoader) {
if (classLoader instanceof URLClassLoader) {
+if (isWebapp) {
+isWebapp = isWebappClassLoader(classLoader);
+}
URL[] urls = ((URLClassLoader) classLoader).getURLs();
for (int i=0; iurls.length; i++) {
// Extract the jarName if there is one to be found
@@ -234,7 +241,7 @@ public class StandardJarScanner implemen
log.debug(sm.getString(jarScan.classloaderJarScan, urls[i]));
}
try {
-process(callback, urls[i], false);
+process(callback, urls[i], isWebapp);
} catch (IOException ioe) {
log.warn(sm.getString(
jarScan.classloaderFail,urls[i]),
ioe);
@@ -251,6 +258,34 @@ public class StandardJarScanner implemen
}
}
+
+/*
+ * Since class loader hierarchies can get complicated, this method attempts
+ * to apply the following rule: A class loader is a web application class
+ * loader unless it loaded this class (StandardJarScanner) or is a parent
+ * of the class loader that loaded this class.
+ *
+ * This should mean:
+ * the webapp class loader is an application class loader
+ * the shared class loader is an application class loader
+ * the server class loader is not an application class loader
+ * the common class loader is not an application class loader
+ * the system class loader is not an application class loader
+ * the bootstrap class loader is not an application class loader
+ */
+private boolean isWebappClassLoader(ClassLoader classLoader) {
+ClassLoader nonWebappLoader =
StandardJarScanner.class.getClassLoader();
+
+while (nonWebappLoader != null) {
+if (nonWebappLoader == classLoader) {
+return false;
+}
+nonWebappLoader = nonWebappLoader.getParent();
+}
+return true;
+}
+
+
/*
* Scan a URL for JARs with the optional extensions to look at all files
* and all directories.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492978 - in /tomcat/trunk/java/org/apache: catalina/startup/ContextConfig.java catalina/startup/TldConfig.java jasper/compiler/TldLocationsCache.java tomcat/JarScanType.java tomcat/JarSc
Author: markt
Date: Fri Jun 14 07:41:33 2013
New Revision: 1492978
URL: http://svn.apache.org/r1492978
Log:
Add the type of scan to the JarScanner API
This is preparation for changing how jarsToSkip are handled.
Added:
tomcat/trunk/java/org/apache/tomcat/JarScanType.java
- copied, changed from r1492977,
tomcat/trunk/java/org/apache/tomcat/JarScanner.java
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
tomcat/trunk/java/org/apache/tomcat/JarScanner.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
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=1492978r1=1492977r2=1492978view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
07:41:33 2013
@@ -95,6 +95,7 @@ import org.apache.catalina.util.ContextN
import org.apache.catalina.util.Introspection;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.JarScanType;
import org.apache.tomcat.JarScanner;
import org.apache.tomcat.JarScannerCallback;
import org.apache.tomcat.util.ExceptionUtils;
@@ -2042,8 +2043,8 @@ public class ContextConfig implements Li
JarScanner jarScanner = context.getJarScanner();
FragmentJarScannerCallback callback = new FragmentJarScannerCallback();
-jarScanner.scan(context.getServletContext(), callback,
-pluggabilityJarsToSkip);
+jarScanner.scan(JarScanType.SERVLET3_PLUGGABILITY,
+context.getServletContext(), callback, pluggabilityJarsToSkip);
return callback.getFragments();
}
Modified: tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java?rev=1492978r1=1492977r2=1492978view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java Fri Jun 14
07:41:33 2013
@@ -37,6 +37,7 @@ import org.apache.catalina.LifecycleEven
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.deploy.ApplicationListener;
+import org.apache.tomcat.JarScanType;
import org.apache.tomcat.JarScanner;
import org.apache.tomcat.JarScannerCallback;
import org.apache.tomcat.util.ExceptionUtils;
@@ -262,7 +263,7 @@ public final class TldConfig implements
// Stages 3b 4
JarScanner jarScanner = context.getJarScanner();
-jarScanner.scan(context.getServletContext(),
+jarScanner.scan(JarScanType.TLD, context.getServletContext(),
new TldJarScannerCallback(), noTldJars);
// Now add all the listeners we found to the listeners for this context
Modified: tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java?rev=1492978r1=1492977r2=1492978view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java Fri Jun
14 07:41:33 2013
@@ -37,6 +37,7 @@ import org.apache.jasper.xmlparser.Parse
import org.apache.jasper.xmlparser.TreeNode;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.JarScanType;
import org.apache.tomcat.JarScanner;
import org.apache.tomcat.JarScannerCallback;
import org.apache.tomcat.util.scan.Jar;
@@ -242,7 +243,8 @@ public class TldLocationsCache {
JarScanner jarScanner = JarScannerFactory.getJarScanner(ctxt);
if (jarScanner != null) {
-jarScanner.scan(ctxt, new TldJarScannerCallback(), noTldJars);
+jarScanner.scan(JarScanType.TLD, ctxt,
+new TldJarScannerCallback(), noTldJars);
}
initialized = true;
Copied: tomcat/trunk/java/org/apache/tomcat/JarScanType.java (from r1492977,
tomcat/trunk/java/org/apache/tomcat/JarScanner.java)
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/JarScanType.java?p2=tomcat/trunk/java/org/apache/tomcat/JarScanType.javap1=tomcat/trunk/java/org/apache/tomcat/JarScanner.javar1=1492977r2=1492978rev=1492978view=diff
svn commit: r1492979 - in /tomcat/trunk: conf/ java/org/apache/catalina/startup/ java/org/apache/jasper/ java/org/apache/jasper/compiler/ java/org/apache/tomcat/ java/org/apache/tomcat/util/scan/
Author: markt
Date: Fri Jun 14 07:42:41 2013
New Revision: 1492979
URL: http://svn.apache.org/r1492979
Log:
Get JarScanFilter working with default values
Added:
tomcat/trunk/java/org/apache/tomcat/JarScanFilter.java
- copied, changed from r1492978,
tomcat/trunk/java/org/apache/tomcat/JarScanType.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
Modified:
tomcat/trunk/conf/catalina.properties
tomcat/trunk/java/org/apache/catalina/startup/Constants.java
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/TldConfig.java
tomcat/trunk/java/org/apache/jasper/Constants.java
tomcat/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
tomcat/trunk/java/org/apache/tomcat/JarScanType.java
tomcat/trunk/java/org/apache/tomcat/JarScanner.java
tomcat/trunk/java/org/apache/tomcat/util/scan/Constants.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Modified: tomcat/trunk/conf/catalina.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/conf/catalina.properties?rev=1492979r1=1492978r2=1492979view=diff
==
--- tomcat/trunk/conf/catalina.properties (original)
+++ tomcat/trunk/conf/catalina.properties Fri Jun 14 07:42:41 2013
@@ -73,13 +73,14 @@ server.loader=
# starting with file:.
shared.loader=
-# List of JAR files that should not be scanned using the JarScanner
+# Default list of JAR files that should not be scanned using the JarScanner
# functionality. This is typically used to scan JARs for configuration
# information. JARs that do not contain such information may be excluded from
# the scan to speed up the scanning process. This is the default list. JARs on
-# this list are excluded from all scans. Scan specific lists (to exclude JARs
-# from individual scans) follow this. The list must be a comma separated list
of
-# JAR file names.
+# this list are excluded from all scans. The list must be a comma separated
list
+# of JAR file names.
+# The list of JARs to skip may be over-ridden at a Context level for individual
+# scan types by configuring a JarScanner with a nested JarScanFilter.
# The JARs listed below include:
# - Tomcat Bootstrap JARs
# - Tomcat API JARs
@@ -87,7 +88,7 @@ shared.loader=
# - Jasper JARs
# - Tomcat JARs
# - Common non-Tomcat JARs
-tomcat.util.scan.DefaultJarScanner.jarsToSkip=\
+tomcat.util.scan.StandardJarScanFilter.jarsToSkip=\
bootstrap.jar,commons-daemon.jar,tomcat-juli.jar,\
annotations-api.jar,el-api.jar,jsp-api.jar,servlet-api.jar,\
catalina.jar,catalina-ant.jar,catalina-ha.jar,catalina-tribes.jar,\
@@ -109,17 +110,13 @@ jmx-tools.jar,jta*.jar,log4j*.jar,mail*.
xercesImpl.jar,xmlParserAPIs.jar,xml-apis.jar,\
junit.jar,junit-*.jar,ant-launcher.jar
-# Additional JARs (over and above the default JARs listed above) to skip when
-# scanning for Servlet 3.0 pluggability features. These features include web
-# fragments, annotations, SCIs and classes that match @HandlesTypes. The list
-# must be a comma separated list of JAR file names.
-org.apache.catalina.startup.ContextConfig.jarsToSkip=
+# Default list of JAR files that should be scanned that overrides the default
+# jarsToSkip list above. This is typically used to include a specific JAR that
+# has been excluded by a broad file name pattern in the jarsToSkip list.
+# The list of JARs to scan may be over-ridden at a Context level for individual
+# scan types by configuring a JarScanner with a nested JarScanFilter.
+tomcat.util.scan.StandardJarScanFilter.jarsToScan=
-# Additional JARs (over and above the default JARs listed above) to skip when
-# scanning for TLDs. The list must be a comma separated list of JAR file names.
-org.apache.catalina.startup.TldConfig.jarsToSkip=
-
-#
# String cache configuration.
tomcat.util.buf.StringCache.byte.enabled=true
#tomcat.util.buf.StringCache.char.enabled=true
Modified: tomcat/trunk/java/org/apache/catalina/startup/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Constants.java?rev=1492979r1=1492978r2=1492979view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Constants.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Constants.java Fri Jun 14
07:42:41 2013
@@ -34,13 +34,6 @@ public final class Constants {
public static final String HostContextXml = context.xml.default;
public static final String HostWebXml = web.xml.default;
-public static final String DEFAULT_JARS_TO_SKIP =
-tomcat.util.scan.DefaultJarScanner.jarsToSkip;
-public static final String PLUGGABILITY_JARS_TO_SKIP =
-org.apache.catalina.startup.ContextConfig.jarsToSkip;
-public static final String TLD_JARS_TO_SKIP =
-
svn commit: r1492980 - in /tomcat/trunk/java/org/apache: catalina/startup/ContextRuleSet.java tomcat/JarScanner.java tomcat/util/scan/StandardJarScanner.java
Author: markt
Date: Fri Jun 14 07:43:23 2013
New Revision: 1492980
URL: http://svn.apache.org/r1492980
Log:
Add getter/setter for JarScanFilter to JarScanner
Enable JarScanFilter to be configured via a context.xml file (and
server.xml)
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextRuleSet.java
tomcat/trunk/java/org/apache/tomcat/JarScanner.java
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextRuleSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextRuleSet.java?rev=1492980r1=1492979r2=1492980view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextRuleSet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextRuleSet.java Fri Jun
14 07:43:23 2013
@@ -228,6 +228,14 @@ public class ContextRuleSet extends Rule
setJarScanner,
org.apache.tomcat.JarScanner);
+digester.addObjectCreate(prefix + Context/JarScanner/JarScanFilter,
+
org.apache.tomcat.util.scan.StandardJarScanFilter,
+ className);
+digester.addSetProperties(prefix + Context/JarScanner/JarScanFilter);
+digester.addSetNext(prefix + Context/JarScanner/JarScanFilter,
+setJarScanFilter,
+org.apache.tomcat.JarScanFilter);
+
}
}
Modified: tomcat/trunk/java/org/apache/tomcat/JarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/JarScanner.java?rev=1492980r1=1492979r2=1492980view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/JarScanner.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/JarScanner.java Fri Jun 14 07:43:23 2013
@@ -39,4 +39,7 @@ public interface JarScanner {
public void scan(JarScanType scanType, ServletContext context,
JarScannerCallback callback);
+public JarScanFilter getJarScanFilter();
+
+public void setJarScanFilter(JarScanFilter jarScanFilter);
}
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1492980r1=1492979r2=1492980view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java Fri
Jun 14 07:43:23 2013
@@ -111,9 +111,11 @@ public class StandardJarScanner implemen
* Controls the filtering of the results from the scan for JARs
*/
private JarScanFilter jarScanFilter = new StandardJarScanFilter();
+@Override
public JarScanFilter getJarScanFilter() {
return jarScanFilter;
}
+@Override
public void setJarScanFilter(JarScanFilter jarScanFilter) {
this.jarScanFilter = jarScanFilter;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492981 - /tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
Author: markt
Date: Fri Jun 14 07:43:55 2013
New Revision: 1492981
URL: http://svn.apache.org/r1492981
Log:
Add some Javadoc
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java?rev=1492981r1=1492980r2=1492981view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java
Fri Jun 14 07:43:55 2013
@@ -49,6 +49,35 @@ public class StandardJarScanFilter imple
private SetString[] pluggabilityScanSet = new HashSet();
private boolean defaultPluggabilityScan = true;
+/**
+ * This is the standard implementation of {@link JarScanFilter}. By
default,
+ * the following filtering rules are used:
+ * ul
+ * liJARs that match neither the skip nor the scan list will be included
+ * in scan results./li
+ * liJARs that match the skip list but not the scan list will be excluded
+ * from scan results./li
+ * liJARs that match the scan list will be included from scan results.
+ * /li
+ * /ul
+ * The default skip list and default scan list are obtained from the system
+ * properties {@link Constants#SKIP_JARS_PROPERTY} and
+ * {@link Constants#SCAN_JARS_PROPERTY} respectively. These default values
+ * may be over-ridden for the {@link JarScanType#TLD} and
+ * {@link JarScanType#PLUGGABILITY} scans. The filtering rules may also be
+ * modified for these scan types using {@link #setDefaultTldScan(boolean)}
+ * and {@link #setDefaultPluggabilityScan(boolean)}. If set to
+ * codefalse/code, the following filtering rules are used for
associated
+ * type:
+ * ul
+ * liJARs that match neither the skip nor the scan list will be excluded
+ * from scan results./li
+ * liJARs that match the scan list but not the skip list will be included
+ * in scan results./li
+ * liJARs that match the skip list will be excluded from scan results.
+ * /li
+ * /ul
+ */
public StandardJarScanFilter() {
// Set the defaults from the system properties
defaultSkip = System.getProperty(Constants.SKIP_JARS_PROPERTY);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492983 - in /tomcat/trunk/webapps/docs/config: jar-scan-filter.xml jar-scanner.xml project.xml
Author: markt Date: Fri Jun 14 07:44:22 2013 New Revision: 1492983 URL: http://svn.apache.org/r1492983 Log: Add some documentation Added: tomcat/trunk/webapps/docs/config/jar-scan-filter.xml Modified: tomcat/trunk/webapps/docs/config/jar-scanner.xml tomcat/trunk/webapps/docs/config/project.xml Added: 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=1492983view=auto == --- tomcat/trunk/webapps/docs/config/jar-scan-filter.xml (added) +++ tomcat/trunk/webapps/docs/config/jar-scan-filter.xml Fri Jun 14 07:44:22 2013 @@ -0,0 +1,149 @@ +?xml version=1.0? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +!DOCTYPE document [ + !ENTITY project SYSTEM project.xml +] +document url=jar-scan-filter.html + + project; + + properties +titleThe Jar Scan Filter Component/title + /properties + +body + +section name=Table of Contents +toc/ +/section + +section name=Introduction + + pThe strongJar Scan Filter/strong element represents the component that + filters results from the a href=jar-scanner.htmlJar Scanner/a before + they are passed back to the application. It is typically used to skip the + scanning of JARs that are known not to be relevant to some or all types of + scan./p + + pA Jar Scan Filter element MAY be nested inside a + a href=jar-scanner.htmlJar Scanner/a component. If it is not included, + a default Jar Scan Filter configuration will be created automatically, which + is sufficient for most requirements./p + +/section + + +section name=Attributes + + subsection name=Common Attributes + +pAll implementations of strongJar Scan Filter/strong +support the following attributes:/p + +attributes + + attribute name=className required=false +pJava class name of the implementation to use. This class must +implement the codeorg.apache.tomcat.JarScanFilter/code interface. +If not specified, the standard value (defined below) will be used./p + /attribute + +/attributes + + /subsection + + + subsection name=Standard Implementation + +pThe standard implementation of strongJar Scan Filter/strong is +strongorg.apache.tomcat.util.scan.StandardJarScanFilter/strong. +It supports the following additional attributes (in addition to the +common attributes listed above):/p + +attributes + + attribute name=tldSkip required=false + pThe comma separated list of JAR file name patterns to skip when + scanning for TLDs. If not specified, the default is obtained from the + codetomcat.util.scan.StandardJarScanFilter.jarsToSkip/code system + property./p + /attribute + + attribute name=tldScan required=false + pThe comma separated list of JAR file name patterns to scan when + scanning for TLDs. If not specified, the default is obtained from the + codetomcat.util.scan.StandardJarScanFilter.jarsToScan/code system + property./p + /attribute + + attribute name=defaultTldScan required=false + pControls if JARs are scanned or skipped by default. If + codetrue/code, JARs are scanned unless they match one or more TLD + skip patterns and don't match any TLD scan patterns. If + codefalse/code, JARs are skipped unless they match one or more TLD + scan patterns and don't match any TLD skip patterns. If not specified, + the default value is codetrue/code./p + /attribute + + attribute name=pluggableSkip required=false + pThe comma separated list of JAR file name patterns to skip when + scanning for pluggable features. If not specified, the default is + obtained from the + codetomcat.util.scan.StandardJarScanFilter.jarsToSkip/code system + property./p + /attribute + + attribute name=pluggableScan required=false + pThe comma separated list of JAR file name patterns to scan when + scanning for pluggable features. If not specified, the default is + obtained from the + codetomcat.util.scan.StandardJarScanFilter.jarsToScan/code system + property./p + /attribute
svn commit: r1492984 - in /tomcat/trunk/java/org/apache/catalina: deploy/WebXml.java startup/ContextConfig.java
Author: markt
Date: Fri Jun 14 07:44:57 2013
New Revision: 1492984
URL: http://svn.apache.org/r1492984
Log:
Make flag that indicates if JAR is from webapp or container visible to
fragment processing code.
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java?rev=1492984r1=1492983r2=1492984view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java (original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java Fri Jun 14
07:44:57 2013
@@ -597,6 +597,16 @@ public class WebXml {
public void setJarName(String jarName) { this.jarName = jarName; }
public String getJarName() { return jarName; }
+// Is this JAR part of the application or is it a container JAR? Assume it
+// is.
+private boolean webappJar = true;
+public void setWebappJar(boolean webappJar) {
+this.webappJar = webappJar;
+}
+public boolean getWebappJar() {
+return webappJar;
+}
+
@Override
public String toString() {
StringBuilder buf = new StringBuilder(32);
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=1492984r1=1492983r2=1492984view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
07:44:57 2013
@@ -2731,6 +2731,8 @@ public class ContextConfig implements Li
InputStream is = null;
WebXml fragment = new WebXml();
+fragment.setWebappJar(isWebapp);
+
try {
jar = JarFactory.newInstance(url);
is = jar.getInputStream(FRAGMENT_LOCATION);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 08:35, Romain Manni-Bucau wrote: wait SCIs stands for ServletContainerInitializer right? if so just think all apps are not only webapps (ear typically) I'd disagree. I'd say WARs are far more popular than EARs. For EARs if there is a case for application wide scanning (not sure there is but I don't know the rest of the J2EE spec well enough to be certain) then such scanning needs to be provided by the container in the same way SCIs provide scanning in Servlet containers. In a full J2EE container it should be possible for the results of the application wide scan to be fed to the SCI so there is no need for multiple scans. + the issue is really tomcat scanning shouldn't occur if already done (or the opposite, myfaces should reuse tomcat scanned info is here, cxf, spring, cdi container...). Then MyFaces should use an SCI. As should any other library that needs to scan the WAR for classes and/or annotations in a Servlet container. If there is something one of these libraries needs that can't be done with an SCI then that needs to be raised with the Servlet EG. The downside of using an SCI is that it requires Servlet 3. Some library developers may not like the idea of introducing a dependency on Servlet 3.0. I'd suggest the way forward is to use an SCI if available and if not, then fall-back to whatever internal scanning is currently used. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
that's what we do in TomEE but i don't get how a SCI (order is not deterministic IIRC) can solve the issue. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 08:35, Romain Manni-Bucau wrote: wait SCIs stands for ServletContainerInitializer right? if so just think all apps are not only webapps (ear typically) I'd disagree. I'd say WARs are far more popular than EARs. For EARs if there is a case for application wide scanning (not sure there is but I don't know the rest of the J2EE spec well enough to be certain) then such scanning needs to be provided by the container in the same way SCIs provide scanning in Servlet containers. In a full J2EE container it should be possible for the results of the application wide scan to be fed to the SCI so there is no need for multiple scans. + the issue is really tomcat scanning shouldn't occur if already done (or the opposite, myfaces should reuse tomcat scanned info is here, cxf, spring, cdi container...). Then MyFaces should use an SCI. As should any other library that needs to scan the WAR for classes and/or annotations in a Servlet container. If there is something one of these libraries needs that can't be done with an SCI then that needs to be raised with the Servlet EG. The downside of using an SCI is that it requires Servlet 3. Some library developers may not like the idea of introducing a dependency on Servlet 3.0. I'd suggest the way forward is to use an SCI if available and if not, then fall-back to whatever internal scanning is currently used. Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1492983 - in /tomcat/trunk/webapps/docs/config: jar-scan-filter.xml jar-scanner.xml project.xml
2013/6/14 ma...@apache.org: Author: markt Date: Fri Jun 14 07:44:22 2013 New Revision: 1492983 URL: http://svn.apache.org/r1492983 Log: Add some documentation Added: tomcat/trunk/webapps/docs/config/jar-scan-filter.xml and also in a earlier commit tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java svn propset svn:eol-style is missing If I have not missed anything, other files were created as copies from existing ones so they should have that svn property. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 08:54, Romain Manni-Bucau wrote: that's what we do in TomEE but i don't get how a SCI (order is not deterministic IIRC) can solve the issue. You have yet to articulate exactly what the issue is. You are correct that SCI processing order is not fully deterministic. Container SCIs are under the control of the container so can be processed in any order the container sees fit so that part can be deterministic. Application SCIs do not have an order defined. If that is a problem, raise it with the EG. I'd suggest the simple solution (which Tomcat already implements) is to treat JARs without a fragment as if it contains an empty fragment and then process SCIs in the same order as fragments are processed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1492983 - in /tomcat/trunk/webapps/docs/config: jar-scan-filter.xml jar-scanner.xml project.xml
On 14/06/2013 09:08, Konstantin Kolinko wrote: 2013/6/14 ma...@apache.org: Author: markt Date: Fri Jun 14 07:44:22 2013 New Revision: 1492983 URL: http://svn.apache.org/r1492983 Log: Add some documentation Added: tomcat/trunk/webapps/docs/config/jar-scan-filter.xml and also in a earlier commit tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java svn propset svn:eol-style is missing If I have not missed anything, other files were created as copies from existing ones so they should have that svn property. Thanks. Checking those properties is on my TODO list. I've been busy writing e-mail about SCIs so haven't done it yet. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1492990 - in /tomcat/trunk: java/org/apache/tomcat/util/scan/StandardJarScanFilter.java webapps/docs/config/jar-scan-filter.xml
Author: markt Date: Fri Jun 14 08:12:57 2013 New Revision: 1492990 URL: http://svn.apache.org/r1492990 Log: Fix line endings Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java (props changed) tomcat/trunk/webapps/docs/config/jar-scan-filter.xml (props changed) Propchange: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanFilter.java -- svn:eol-style = native Propchange: tomcat/trunk/webapps/docs/config/jar-scan-filter.xml -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
well i think it will be handled for next spec as it was for interceptors (but it is not that important for initializer in *applications*). I don't get what's the issue using a scanner registry with get or create semantic. Is it only tomcat doesn't need it by itself? If so my point is today tomcat is almost nothing without libs and most of libs scan so IMO it would be a nice have to get it (even if not mandatory). *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 08:54, Romain Manni-Bucau wrote: that's what we do in TomEE but i don't get how a SCI (order is not deterministic IIRC) can solve the issue. You have yet to articulate exactly what the issue is. You are correct that SCI processing order is not fully deterministic. Container SCIs are under the control of the container so can be processed in any order the container sees fit so that part can be deterministic. Application SCIs do not have an order defined. If that is a problem, raise it with the EG. I'd suggest the simple solution (which Tomcat already implements) is to treat JARs without a fragment as if it contains an empty fragment and then process SCIs in the same order as fragments are processed. Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 13/06/2013 17:23, Mark Thomas wrote: As I make my way through the Servlet 3.1 spec reviewing all the changes to make sure they have all been implemented, I have reached section 8.2. There are a number of related issues here. 1. Three known issues with the current SCI / fragment handling [1] - SCI scan does not obey class loader ordering - fragments in container JARs are processed - Container SCIs may be exluded 2. A wish for per context jarsToSkip [2] 3. A wish for greater control over jarsToSkip [3] snip/ I currently have the start of this in a local git repo. Any objections to me committing what I have to trunk and continuing there? No objections and some good discussion that I think will be helped if there is something concrete to discuss so I have committed the work so far. Issues 2 3 have been implemented and the information (container vs application JAR) is now available to implement 1 but there is still work required to resolve the issues identified in 1. Mark [1] http://markmail.org/message/22e3sjmsy2gt4tkw [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 09:14, Romain Manni-Bucau wrote: well i think it will be handled for next spec as it was for interceptors (but it is not that important for initializer in *applications*). I don't get what's the issue using a scanner registry with get or create semantic. Is it only tomcat doesn't need it by itself? If so my point is today tomcat is almost nothing without libs and most of libs scan so IMO it would be a nice have to get it (even if not mandatory). The issue is that you are advocating a solution (a scanner registry although you have not defined what one of those is) without describing a problem. Both container and application components that need to scan JARs for classes and/or annotations can use an SCI which will result in a single scan being performed. You have yet to articulate a requirement that cannot be met with an SCI. If the problem you are trying to solve is that lots of libraries perform scans then I see no point in implementing a proprietary solution (a scanner registry) when there is a standard solution (SCIs) available. Libraries are going to have to change their code for either solution so using the specification defined standard solution rather than a single proprietary solution used by only one container is clearly the way to go. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
SCIs are too webapp linked to be usable by others, that's the point so it needs to be proprietary ATM + SCI doesn't scan eveything (thinking to cdi you cannot guess a bean is a cdi one before having analyzed it). *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 09:14, Romain Manni-Bucau wrote: well i think it will be handled for next spec as it was for interceptors (but it is not that important for initializer in *applications*). I don't get what's the issue using a scanner registry with get or create semantic. Is it only tomcat doesn't need it by itself? If so my point is today tomcat is almost nothing without libs and most of libs scan so IMO it would be a nice have to get it (even if not mandatory). The issue is that you are advocating a solution (a scanner registry although you have not defined what one of those is) without describing a problem. Both container and application components that need to scan JARs for classes and/or annotations can use an SCI which will result in a single scan being performed. You have yet to articulate a requirement that cannot be met with an SCI. If the problem you are trying to solve is that lots of libraries perform scans then I see no point in implementing a proprietary solution (a scanner registry) when there is a standard solution (SCIs) available. Libraries are going to have to change their code for either solution so using the specification defined standard solution rather than a single proprietary solution used by only one container is clearly the way to go. Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 09:28, Romain Manni-Bucau wrote: SCIs are too webapp linked to be usable by others, that's the point so it needs to be proprietary ATM If the problem you are trying to solve is JAR scanning outside of the Servlet container then that - frankly - isn't a Tomcat problem. Tomcat is concerned about scanning for classes and annotations within a web application and the standard API for that is an SCI. SCIs are just an interface so if a broader scanning solution was available (either in Java EE or Java SE) then that broader solution could be taken advantage of either directly in Tomcat or by whatever product was embedding Tomcat. If TomEE has a broader solution and it could be easier to plug the results of that into Tomcat so make them available through the SCI interface then present some concrete proposals on changes to make the scanning more pluggable and they'll be considered. + SCI doesn't scan eveything (thinking to cdi you cannot guess a bean is a cdi one before having analyzed it). SCIs don't scan anything. SCIs are merely the interface through which clients declare their interests and the servlet container passes back the results. It is certainly the case that every class has to be scanned if a @HandlesType is present on any SCI. If you are saying that CDI implementations need information that isn't available though the SCI interface then that is something that needs to be raised with the Servlet EG. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1492331 - in /tomcat/tc7.0.x/trunk: ./ java/javax/servlet/ java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/catalina/deploy/ java/org/apache/catalina/startup/
On 14/06/2013 07:55, Violeta Georgieva wrote:
2013/6/12 ma...@apache.org
Author: markt
Date: Wed Jun 12 18:31:30 2013
New Revision: 1492331
URL: http://svn.apache.org/r1492331
Log:
With clarification from the EG for Servlet 3.1 section 4.4 finally makes
sense. Implement the necessary restriction and add a test case.
I think that we should provide the same restriction for the
ServletContextListeners that are not described in web.xml/web-fragment.xml
or are not annotated. For example such listeners can be added by
ServletContainerInitializer.
What do you think?
Short answer - yes, I agree.
I then went to look at the code to figure out how / where to do this and
it took me a little while to figure out what was going on. I've added a
bunch of comments to clarify things that I'll commit shortly. Now I
understand the code again, the fix looks simple.
Mark
o.a.catalina.core.ApplicationContext.addListener(T t)
...
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
-context.addApplicationLifecycleListener(t);
match = true;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
can work this way, today that's not as easy as it could to replace tomat scanning(s) (tld, classes) by tomee one. About CDI: you basically need to pass all classes on jars with a beans.xml to the CDI container so @HandlesType doesn't match this need really well. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas ma...@apache.org On 14/06/2013 09:28, Romain Manni-Bucau wrote: SCIs are too webapp linked to be usable by others, that's the point so it needs to be proprietary ATM If the problem you are trying to solve is JAR scanning outside of the Servlet container then that - frankly - isn't a Tomcat problem. Tomcat is concerned about scanning for classes and annotations within a web application and the standard API for that is an SCI. SCIs are just an interface so if a broader scanning solution was available (either in Java EE or Java SE) then that broader solution could be taken advantage of either directly in Tomcat or by whatever product was embedding Tomcat. If TomEE has a broader solution and it could be easier to plug the results of that into Tomcat so make them available through the SCI interface then present some concrete proposals on changes to make the scanning more pluggable and they'll be considered. + SCI doesn't scan eveything (thinking to cdi you cannot guess a bean is a cdi one before having analyzed it). SCIs don't scan anything. SCIs are merely the interface through which clients declare their interests and the servlet container passes back the results. It is certainly the case that every class has to be scanned if a @HandlesType is present on any SCI. If you are saying that CDI implementations need information that isn't available though the SCI interface then that is something that needs to be raised with the Servlet EG. Mark --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493011 - in /tomcat/trunk/java/org/apache/catalina/core: ApplicationContext.java StandardContext.java
Author: markt
Date: Fri Jun 14 09:43:27 2013
New Revision: 1493011
URL: http://svn.apache.org/r1493011
Log:
Improve comments.
Rename local variable for clarity.
Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=1493011r1=1493010r2=1493011view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java Fri Jun
14 09:43:27 2013
@@ -1271,6 +1271,8 @@ public class ApplicationContext
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
+// Add listener directly to the list of instances rather than to
+// the list of class names.
context.addApplicationLifecycleListener(t);
match = true;
}
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=1493011r1=1493010r2=1493011view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun 14
09:43:27 2013
@@ -227,8 +227,8 @@ public class StandardContext extends Con
/**
- * The set of application listeners configured for this application, in the
- * order they were encountered in the web.xml file.
+ * The set of application listener class names configured for this
+ * application, in the order they were encountered in the web.xml file.
*/
private ApplicationListener applicationListeners[] =
new ApplicationListener[0];
@@ -237,14 +237,18 @@ public class StandardContext extends Con
/**
- * The set of instantiated application event listener objects/code.
+ * The set of instantiated application event listener objects. Note that
+ * SCIs and other code may use the pluggability APIs to add listener
+ * instances directly to this list before the application starts.
*/
private Object applicationEventListenersObjects[] =
new Object[0];
/**
- * The set of instantiated application lifecycle listener objects/code.
+ * The set of instantiated application lifecycle listener objects. Note
that
+ * SCIs and other code may use the pluggability APIs to add listener
+ * instances directly to this list before the application starts.
*/
private Object applicationLifecycleListenersObjects[] =
new Object[0];
@@ -4721,7 +4725,7 @@ public class StandardContext extends Con
ApplicationListener listeners[] = findApplicationListeners();
Object results[] = new Object[listeners.length];
boolean ok = true;
-SetObject tldListeners = new HashSet();
+SetObject noPluggabilityListeners = new HashSet();
for (int i = 0; i results.length; i++) {
if (getLogger().isDebugEnabled())
getLogger().debug( Configuring event listener class ' +
@@ -4731,7 +4735,7 @@ public class StandardContext extends Con
results[i] = instanceManager.newInstance(
listener.getClassName());
if (listener.isPluggabilityBlocked()) {
-tldListeners.add(results[i]);
+noPluggabilityListeners.add(results[i]);
}
} catch (Throwable t) {
t = ExceptionUtils.unwrapInvocationTargetException(t);
@@ -4764,7 +4768,11 @@ public class StandardContext extends Con
}
}
-//Listeners may have been added by ServletContextInitializers. Put
them after the ones we know about.
+// Listener instances may have been added directly to this Context by
+// ServletContextInitializers and other code via the pluggability APIs.
+// Put them these listeners after the ones defined in web.xml and/or
+// annotations then overwrite the list of instances with the new, full
+// list.
for (Object eventListener: getApplicationEventListeners()) {
eventListeners.add(eventListener);
}
@@ -4791,7 +4799,7 @@ public class StandardContext extends Con
ServletContextEvent event =
new ServletContextEvent(getServletContext());
ServletContextEvent tldEvent = null;
-if (tldListeners.size() 0) {
+if (noPluggabilityListeners.size() 0) {
tldEvent =
Re: svn commit: r1493011 - in /tomcat/trunk/java/org/apache/catalina/core: ApplicationContext.java StandardContext.java
2013/6/14 ma...@apache.org: Author: markt Date: Fri Jun 14 09:43:27 2013 New Revision: 1493011 URL: http://svn.apache.org/r1493011 Log: Improve comments. Rename local variable for clarity. Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java tomcat/trunk/java/org/apache/catalina/core/StandardContext.java 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=1493011r1=1493010r2=1493011view=diff == --- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original) +++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun 14 09:43:27 2013 @@ -227,8 +227,8 @@ public class StandardContext extends Con /** - * The set of application listeners configured for this application, in the - * order they were encountered in the web.xml file. + * The set of application listener class names configured for this + * application, in the order they were encountered in the web.xml file. BTW, in the order they were encountered in the web.xml file. comment does not say anything about web fragments. */ private ApplicationListener applicationListeners[] = new ApplicationListener[0]; @@ -237,14 +237,18 @@ public class StandardContext extends Con - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493013 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Author: markt Date: Fri Jun 14 09:52:53 2013 New Revision: 1493013 URL: http://svn.apache.org/r1493013 Log: More clarity Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java 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=1493013r1=1493012r2=1493013view=diff == --- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original) +++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun 14 09:52:53 2013 @@ -228,7 +228,8 @@ public class StandardContext extends Con /** * The set of application listener class names configured for this - * application, in the order they were encountered in the web.xml file. + * application, in the order they were encountered in the resulting merged + * web.xml file. */ private ApplicationListener applicationListeners[] = new ApplicationListener[0]; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493014 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Author: markt
Date: Fri Jun 14 09:53:49 2013
New Revision: 1493014
URL: http://svn.apache.org/r1493014
Log:
Further restriction as per Servlet 3.1 section 4.4
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
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=1493014r1=1493013r2=1493014view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun 14
09:53:49 2013
@@ -4780,6 +4780,9 @@ public class StandardContext extends Con
setApplicationEventListeners(eventListeners.toArray());
for (Object lifecycleListener: getApplicationLifecycleListeners()) {
lifecycleListeners.add(lifecycleListener);
+if (lifecycleListener instanceof ServletContextListener) {
+noPluggabilityListeners.add(lifecycleListener);
+}
}
setApplicationLifecycleListeners(lifecycleListeners.toArray());
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493015 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ApplicationContext.java java/org/apache/catalina/core/StandardContext.java
Author: markt
Date: Fri Jun 14 10:00:57 2013
New Revision: 1493015
URL: http://svn.apache.org/r1493015
Log:
As per review from voiletagg, restrictions from in Servlet 3.0, section 4.0
apply to listeners added through the pluggability API as well as via TLDs.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1493011,1493013-1493014
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=1493015r1=1493014r2=1493015view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
Fri Jun 14 10:00:57 2013
@@ -1329,6 +1329,8 @@ public class ApplicationContext
if (t instanceof HttpSessionListener
|| (t instanceof ServletContextListener
newServletContextListenerAllowed)) {
+// Add listener directly to the list of instances rather than to
+// the list of class names.
context.addApplicationLifecycleListener(t);
match = true;
}
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=1493015r1=1493014r2=1493015view=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 Fri
Jun 14 10:00:57 2013
@@ -242,8 +242,9 @@ public class StandardContext extends Con
/**
- * The set of application listeners configured for this application, in the
- * order they were encountered in the web.xml file.
+ * The set of application listener class names configured for this
+ * application, in the order they were encountered in the resulting merged
+ * web.xml file.
*/
private ApplicationListener applicationListeners[] =
new ApplicationListener[0];
@@ -252,14 +253,18 @@ public class StandardContext extends Con
/**
- * The set of instantiated application event listener objects/code.
+ * The set of instantiated application event listener objects. Note that
+ * SCIs and other code may use the pluggability APIs to add listener
+ * instances directly to this list before the application starts.
*/
private Object applicationEventListenersObjects[] =
new Object[0];
/**
- * The set of instantiated application lifecycle listener objects/code.
+ * The set of instantiated application lifecycle listener objects. Note
that
+ * SCIs and other code may use the pluggability APIs to add listener
+ * instances directly to this list before the application starts.
*/
private Object applicationLifecycleListenersObjects[] =
new Object[0];
@@ -4839,7 +4844,7 @@ public class StandardContext extends Con
ApplicationListener listeners[] = applicationListeners;
Object results[] = new Object[listeners.length];
boolean ok = true;
-SetObject tldListeners = new HashSetObject();
+SetObject noPluggabilityListeners = new HashSetObject();
for (int i = 0; i results.length; i++) {
if (getLogger().isDebugEnabled())
getLogger().debug( Configuring event listener class ' +
@@ -4849,7 +4854,7 @@ public class StandardContext extends Con
results[i] = instanceManager.newInstance(
listener.getClassName());
if (listener.isPluggabilityBlocked()) {
-tldListeners.add(results[i]);
+noPluggabilityListeners.add(results[i]);
}
} catch (Throwable t) {
t = ExceptionUtils.unwrapInvocationTargetException(t);
@@ -4881,13 +4886,20 @@ public class StandardContext extends Con
}
}
-//Listeners may have been added by ServletContextInitializers. Put
them after the ones we know about.
+// Listener instances may have been added directly to this Context by
+// ServletContextInitializers and other code via the pluggability APIs.
+// Put them these listeners after the ones defined in web.xml and/or
+// annotations then overwrite the list of instances with the new, full
+// list.
for (Object
Re: svn commit: r1493015 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ApplicationContext.java java/org/apache/catalina/core/StandardContext.java
2013/6/14 ma...@apache.org: Author: markt Date: Fri Jun 14 10:00:57 2013 New Revision: 1493015 URL: http://svn.apache.org/r1493015 Log: As per review from voiletagg, restrictions from in Servlet 3.0, section 4.0 apply to listeners added through the pluggability API as well as via TLDs. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java The LocalStrings message added in http://svn.apache.org/r1492331 now becomes too specific as it does not reflect this change. I mean: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties?view=diffr1=1492330r2=1492331pathrev=1492331 tldListenerServletContext.notAllowed=Section 4.4 of the Servlet 3.0 specification does not permit this method to be called from a ServletContextListener that is defined in a TLD - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54770] Add jarsToScan properties to counteract jarsToSkip exclusions; support per-web-app properties; port to Tomcat 7
https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 --- Comment #3 from Mark Thomas ma...@apache.org --- This has been implemented in trunk for Tomcat 8. The changes are non-trivial to back-port. I don't intend proposing a back-port of these changes. The log4j issue can be resolved by a less broad exclusion in jarsToSkip such as log4j-1*.jar (although I note log4j-core.jar shipped with 1.0.x and 1.1.x and is not log4j-2.x specific). I'll leave this open a little while in case someone wants to look at a back port. In not, I'll change the version to 8.0.x and resolve it as fixed. -- 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 54083] Provide jarsToSkip on a per-webapp basis
https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 --- Comment #1 from Mark Thomas ma...@apache.org --- This has been implemented in trunk for Tomcat 8. The changes are non-trivial to back-port. I don't intend proposing a back-port of these changes. I'll leave this open a little while in case someone wants to look at a back port. In not, I'll change the version to 8.0.x and resolve it as fixed. -- 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: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Fri Jun 14 13:43:56 2013
New Revision: 1493066
URL: http://svn.apache.org/r1493066
Log:
Container provided JARs should not be scanned for deployment annotations nor
should they be checked for web-fragment.xml files.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1493066r1=1493065r2=1493066view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
13:43:56 2013
@@ -1149,9 +1149,10 @@ public class ContextConfig implements Li
// Ordering is important here
-// Step 1. Identify all the JARs packaged with the application
-// If the JARs have a web-fragment.xml it will be parsed at this
-// point.
+// Step 1. Identify all the JARs packaged with the application and
those
+// provided by the container. If any of the application JARs have a
+// web-fragment.xml it will be parsed at this point. web-fragment.xml
+// files are ignored for container provided JARs.
MapString,WebXml fragments = processJarsForWebFragments();
// Step 2. Order the fragments.
@@ -2734,8 +2735,12 @@ public class ContextConfig implements Li
fragment.setWebappJar(isWebapp);
try {
-jar = JarFactory.newInstance(url);
-is = jar.getInputStream(FRAGMENT_LOCATION);
+// Only web application JARs are scanned for deployment
+// annotations and web-fragment.xml files
+if (isWebapp) {
+jar = JarFactory.newInstance(url);
+is = jar.getInputStream(FRAGMENT_LOCATION);
+}
if (is == null) {
// If there is no web.xml, normal JAR no impact on
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493067 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Fri Jun 14 13:44:43 2013
New Revision: 1493067
URL: http://svn.apache.org/r1493067
Log:
Whoops. Better comment.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1493067r1=1493066r2=1493067view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
13:44:43 2013
@@ -2735,8 +2735,8 @@ public class ContextConfig implements Li
fragment.setWebappJar(isWebapp);
try {
-// Only web application JARs are scanned for deployment
-// annotations and web-fragment.xml files
+// Only web application JARs are checked for web-fragment.xml
+// files
if (isWebapp) {
jar = JarFactory.newInstance(url);
is = jar.getInputStream(FRAGMENT_LOCATION);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493069 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Fri Jun 14 13:46:42 2013
New Revision: 1493069
URL: http://svn.apache.org/r1493069
Log:
Container provided JARs should not be scanned for deployment annotations.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1493069r1=1493068r2=1493069view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
13:46:42 2013
@@ -2031,16 +2031,20 @@ public class ContextConfig implements Li
protected void processAnnotations(SetWebXml fragments,
boolean handlesTypesOnly) {
for(WebXml fragment : fragments) {
-WebXml annotations = new WebXml();
-// no impact on distributable
-annotations.setDistributable(true);
-URL url = fragment.getURL();
-processAnnotationsUrl(url, annotations,
-(handlesTypesOnly || fragment.isMetadataComplete()));
-SetWebXml set = new HashSet();
-set.add(annotations);
-// Merge annotations into fragment - fragment takes priority
-fragment.merge(set);
+if (fragment.getWebappJar()) {
+// Only web application JARs should be scanned for deployment
+// annotations
+WebXml annotations = new WebXml();
+// no impact on distributable
+annotations.setDistributable(true);
+URL url = fragment.getURL();
+processAnnotationsUrl(url, annotations,
+(handlesTypesOnly || fragment.isMetadataComplete()));
+SetWebXml set = new HashSet();
+set.add(annotations);
+// Merge annotations into fragment - fragment takes priority
+fragment.merge(set);
+}
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493071 - in /tomcat/trunk/java/org/apache/catalina/core: LocalStrings.properties StandardContext.java
Author: markt
Date: Fri Jun 14 13:50:21 2013
New Revision: 1493071
URL: http://svn.apache.org/r1493071
Log:
Rename string and update text
Modified:
tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Modified: tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=1493071r1=1493070r2=1493071view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties Fri Jun
14 13:50:21 2013
@@ -90,6 +90,7 @@ naming.unbindFailed=Failed to unbind obj
naming.invalidEnvEntryType=Environment entry {0} has an invalid type
naming.invalidEnvEntryValue=Environment entry {0} has an invalid value
naming.namingContextCreationFailed=Creation of the naming context failed: {0}
+noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebLister
standardContext.invalidWrapperClass={0} is not a subclass of StandardWrapper
standardContext.applicationListener=Error configuring application listener of
class {0}
standardContext.applicationSkipped=Skipped installing application listeners
due to previous error(s)
@@ -183,8 +184,6 @@ standardWrapper.waiting=Waiting for {0}
threadLocalLeakPreventionListener.lifecycleEvent.error=Exception processing
lifecycle event {0}
threadLocalLeakPreventionListener.containerEvent.error=Exception processing
container event {0}
-tldListenerServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that is defined in a TLD
-
defaultInstanceManager.restrictedServletsResource=Restricted servlets property
file not found
defaultInstanceManager.restrictedFiltersResource=Restricted filters property
file not founddefaultInstanceManager.privilegedFilter=Filter of class {0} is
privileged and cannot be loaded by this web application
defaultInstanceManager.restrictedListenersResources=Restricted listeners
property file not found
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=1493071r1=1493070r2=1493071view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun 14
13:50:21 2013
@@ -6582,13 +6582,13 @@ public class StandardContext extends Con
@Override
public int getEffectiveMajorVersion() {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public int getEffectiveMinorVersion() {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
@@ -6678,7 +6678,7 @@ public class StandardContext extends Con
@Override
public boolean setInitParameter(String name, String value) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
@@ -6709,147 +6709,147 @@ public class StandardContext extends Con
@Override
public Dynamic addServlet(String servletName, String className) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public Dynamic addServlet(String servletName, Servlet servlet) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public Dynamic addServlet(String servletName,
Class? extends Servlet servletClass) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
svn commit: r1493073 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/LocalStrings.properties java/org/apache/catalina/core/StandardContext.java
Author: markt
Date: Fri Jun 14 13:51:13 2013
New Revision: 1493073
URL: http://svn.apache.org/r1493073
Log:
Rename string and update text
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1493071
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=1493073r1=1493072r2=1493073view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
Fri Jun 14 13:51:13 2013
@@ -105,6 +105,7 @@ naming.unbindFailed=Failed to unbind obj
naming.invalidEnvEntryType=Environment entry {0} has an invalid type
naming.invalidEnvEntryValue=Environment entry {0} has an invalid value
naming.namingContextCreationFailed=Creation of the naming context failed: {0}
+noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebLister
standardContext.invalidWrapperClass={0} is not a subclass of StandardWrapper
standardContext.alreadyStarted=Context has already been started
standardContext.applicationListener=Error configuring application listener of
class {0}
@@ -267,8 +268,6 @@ standardWrapper.waiting=Waiting for {0}
threadLocalLeakPreventionListener.lifecycleEvent.error=Exception processing
lifecycle event {0}
threadLocalLeakPreventionListener.containerEvent.error=Exception processing
container event {0}
-tldListenerServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that is defined in a TLD
-
defaultInstanceManager.restrictedServletsResource=Restricted servlets property
file not found
defaultInstanceManager.privilegedServlet=Servlet of class {0} is privileged
and cannot be loaded by this web application
defaultInstanceManager.restrictedFiltersResource=Restricted filters property
file not found
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=1493073r1=1493072r2=1493073view=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 Fri
Jun 14 13:51:13 2013
@@ -6775,13 +6775,13 @@ public class StandardContext extends Con
@Override
public int getEffectiveMajorVersion() {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public int getEffectiveMinorVersion() {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
@@ -6871,7 +6871,7 @@ public class StandardContext extends Con
@Override
public boolean setInitParameter(String name, String value) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
@@ -6902,147 +6902,147 @@ public class StandardContext extends Con
@Override
public Dynamic addServlet(String servletName, String className) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public Dynamic addServlet(String servletName, Servlet servlet) {
throw new UnsupportedOperationException(
-sm.getString(tldListenerServletContext.notAllowed));
+sm.getString(noPluggabilityServletContext.notAllowed));
}
@Override
public Dynamic addServlet(String servletName,
Class? extends Servlet servletClass) {
throw new UnsupportedOperationException(
-
svn commit: r1493080 - in /tomcat/trunk/java/org/apache/catalina: deploy/WebXml.java startup/ContextConfig.java
Author: markt
Date: Fri Jun 14 14:14:00 2013
New Revision: 1493080
URL: http://svn.apache.org/r1493080
Log:
Always process container JARs for SCIs
Order of SCI processing for container JARs compared to web application JARs
should be the same as class loading order.
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java?rev=1493080r1=1493079r2=1493080view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java (original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/WebXml.java Fri Jun 14
14:14:00 2013
@@ -600,12 +600,13 @@ public class WebXml {
// Is this JAR part of the application or is it a container JAR? Assume it
// is.
private boolean webappJar = true;
-public void setWebappJar(boolean webappJar) {
-this.webappJar = webappJar;
-}
-public boolean getWebappJar() {
-return webappJar;
-}
+public void setWebappJar(boolean webappJar) { this.webappJar = webappJar; }
+public boolean getWebappJar() { return webappJar; }
+
+// Does this web application delegate first for class loading?
+private boolean delegate = false;
+public boolean getDelegate() { return delegate; }
+public void setDelegate(boolean delegate) { this.delegate = delegate; }
@Override
public String toString() {
@@ -2109,9 +2110,21 @@ public class WebXml {
orderFragments(orderedFragments, afterSet);
}
+// Container fragments are always included
+SetWebXml containerFragments = new LinkedHashSet();
+// Find all the container fragments and remove any present from the
+// ordered list
+for (WebXml fragment : fragments.values()) {
+if (!fragment.getWebappJar()) {
+containerFragments.add(fragment);
+orderedFragments.remove(fragment);
+}
+}
+
// Avoid NPE when unit testing
if (servletContext != null) {
-// Publish the ordered fragments
+// Publish the ordered fragments. The app does not need to know
+// about container fragments
ListString orderedJarFileNames = null;
if (orderingPresent) {
orderedJarFileNames = new ArrayList();
@@ -2123,7 +2136,21 @@ public class WebXml {
orderedJarFileNames);
}
-return orderedFragments;
+// The remainder of the processing needs to know about container
+// fragments
+if (containerFragments.size() 0) {
+SetWebXml result = new LinkedHashSet();
+if (containerFragments.iterator().next().getDelegate()) {
+result.addAll(containerFragments);
+result.addAll(orderedFragments);
+} else {
+result.addAll(orderedFragments);
+result.addAll(containerFragments);
+}
+return result;
+} else {
+return orderedFragments;
+}
}
private static void decoupleOtherGroups(SetWebXml group) {
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=1493080r1=1493079r2=1493080view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Jun 14
14:14:00 2013
@@ -2737,6 +2737,9 @@ public class ContextConfig implements Li
WebXml fragment = new WebXml();
fragment.setWebappJar(isWebapp);
+if (context instanceof StandardContext) {
+fragment.setDelegate(((StandardContext)
context).getDelegate());
+}
try {
// Only web application JARs are checked for web-fragment.xml
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493113 - /tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
Author: kkolinko
Date: Fri Jun 14 15:23:34 2013
New Revision: 1493113
URL: http://svn.apache.org/r1493113
Log:
Followup to r1493073: correct a typo.
Modified:
tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=1493113r1=1493112r2=1493113view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties Fri Jun
14 15:23:34 2013
@@ -90,7 +90,7 @@ naming.unbindFailed=Failed to unbind obj
naming.invalidEnvEntryType=Environment entry {0} has an invalid type
naming.invalidEnvEntryValue=Environment entry {0} has an invalid value
naming.namingContextCreationFailed=Creation of the naming context failed: {0}
-noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebLister
+noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebListener
standardContext.invalidWrapperClass={0} is not a subclass of StandardWrapper
standardContext.applicationListener=Error configuring application listener of
class {0}
standardContext.applicationSkipped=Skipped installing application listeners
due to previous error(s)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493115 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/LocalStrings.properties
Author: kkolinko
Date: Fri Jun 14 15:25:05 2013
New Revision: 1493115
URL: http://svn.apache.org/r1493115
Log:
Merged r1493113 from tomcat/trunk:
Followup to r1493073: correct a typo.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1493113
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=1493115r1=1493114r2=1493115view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
Fri Jun 14 15:25:05 2013
@@ -105,7 +105,7 @@ naming.unbindFailed=Failed to unbind obj
naming.invalidEnvEntryType=Environment entry {0} has an invalid type
naming.invalidEnvEntryValue=Environment entry {0} has an invalid value
naming.namingContextCreationFailed=Creation of the naming context failed: {0}
-noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebLister
+noPluggabilityServletContext.notAllowed=Section 4.4 of the Servlet 3.0
specification does not permit this method to be called from a
ServletContextListener that was not defined in web.xml, a web-fragment.xml file
nor annotated with @WebListener
standardContext.invalidWrapperClass={0} is not a subclass of StandardWrapper
standardContext.alreadyStarted=Context has already been started
standardContext.applicationListener=Error configuring application listener of
class {0}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
On 14.06.2013 15:43, ma...@apache.org wrote: Author: markt Date: Fri Jun 14 13:43:56 2013 New Revision: 1493066 URL: http://svn.apache.org/r1493066 Log: Container provided JARs should not be scanned for deployment annotations nor should they be checked for web-fragment.xml files. Sorry I haven't really investigated this, but: - I think I have seen you committing a change that labels common loader loaded Jars as container provided - we usually suggest to pack JDBC drivers into the common loader, right? So as a general consistency check to the above: we don't expect JDBC drivers to contain relevant annotations, web fragments etc. in the near future? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
On 14/06/2013 16:38, Rainer Jung wrote: On 14.06.2013 15:43, ma...@apache.org wrote: Author: markt Date: Fri Jun 14 13:43:56 2013 New Revision: 1493066 URL: http://svn.apache.org/r1493066 Log: Container provided JARs should not be scanned for deployment annotations nor should they be checked for web-fragment.xml files. Sorry I haven't really investigated this, but: - I think I have seen you committing a change that labels common loader loaded Jars as container provided Correct. - we usually suggest to pack JDBC drivers into the common loader, right? Correct. So as a general consistency check to the above: we don't expect JDBC drivers to contain relevant annotations, web fragments etc. in the near future? I certainly don't. Note that any framework JARs in the common loader will always have SCIs processed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
Mark, On 6/14/13 3:16 AM, Mark Thomas wrote: On 14/06/2013 03:31, Christopher Schultz wrote: It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. That is what ServletContainerIniiializers are for. Well, crap. I had never seen those before. I'm curious, though. Thinking about this the other day with a colleague who was complaining about some kind of Spring configuration that evidently loaded every class available on the classpath and kept them in memory (thus leading to heap and PermGen issues), I concluded that the only sane way to do this kind of probing would be to probe everything in a ClassLoader that was intended to be discarded after the probing as to avoid loading classes unnecessarily. If an SCI retains a reference to any of the Class objects in the SetClass parameter, that hypothetical throw-away ClassLoader is no longer thrown-away. They only handle class files but the other types (e.g. TLDs) are always in known locations and are inexpensive to find. The expensive bit is scanning all the classes and SCIs provide a mechanism to do that only once for all interested parties. Thanks for pointing that out. I actually had no idea. I really don't see the need for this at all given that SCIs are available. If there are use cases that SCIs don't meet then extending SCIs is the way to go so the same feature is available in any container. I think you are absolutely right. My idea was born before I knew that SCIs existed. Time to re-read the API now that I'm actually starting to update all my webapps towards 3.0. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Jar scanning, SCI scanning, fragment scanning
Romain,
On 6/14/13 5:38 AM, Romain Manni-Bucau wrote:
can work this way, today that's not as easy as it could to replace tomat
scanning(s) (tld, classes) by tomee one.
About CDI: you basically need to pass all classes on jars with a beans.xml
to the CDI container so @HandlesType doesn't match this need really well.
It's a pathological case, but there's nothing stopping you from doing this:
@HandlesType('java.lang.Object')
That way, you'll get everything. Then you can scan the Class objects to
your heart's content looking for whatever you need. CDI can be
implemented this way: just replace the library JAR scanner with an SCI
that responds as if it had scanned all the classes itself.
I have to imaging any JAR scanner would be written with a callback
interface, so just loop-over all the Classes in the Set you get and
fire-off those call-backs: you get the scanning for free already done by
Tomcat. Set a global-ish flag in the library saying that scanning has
been done and stop.
Then your fall-back scanner runs just in case SCIs aren't available
(pre-3.0 container for example -- the Servlet EG recently clarified that
even a webapp with a pre-3.0 deployment descriptor still needs to have
all its 3.0-type features fired which is a decision which seems
astoundingly foolish to me) -- check the aforementioned flag and skip
traditional scanning if you already got it for free.
The only thing missing is a standard scanner -- which was what I was
suggesting. If you implement a standard scanner and it's good, maybe
Tomcat will adopt it and wire it through SCIs because that's what
web containers do.
-chris
signature.asc
Description: OpenPGP digital signature
Re: Jar scanning, SCI scanning, fragment scanning
Cdi handle interfaces too which are not Object.
About throwing away classloader that's what we do in tomee.
Le 14 juin 2013 18:09, Christopher Schultz ch...@christopherschultz.net
a écrit :
Romain,
On 6/14/13 5:38 AM, Romain Manni-Bucau wrote:
can work this way, today that's not as easy as it could to replace tomat
scanning(s) (tld, classes) by tomee one.
About CDI: you basically need to pass all classes on jars with a
beans.xml
to the CDI container so @HandlesType doesn't match this need really well.
It's a pathological case, but there's nothing stopping you from doing this:
@HandlesType('java.lang.Object')
That way, you'll get everything. Then you can scan the Class objects to
your heart's content looking for whatever you need. CDI can be
implemented this way: just replace the library JAR scanner with an SCI
that responds as if it had scanned all the classes itself.
I have to imaging any JAR scanner would be written with a callback
interface, so just loop-over all the Classes in the Set you get and
fire-off those call-backs: you get the scanning for free already done by
Tomcat. Set a global-ish flag in the library saying that scanning has
been done and stop.
Then your fall-back scanner runs just in case SCIs aren't available
(pre-3.0 container for example -- the Servlet EG recently clarified that
even a webapp with a pre-3.0 deployment descriptor still needs to have
all its 3.0-type features fired which is a decision which seems
astoundingly foolish to me) -- check the aforementioned flag and skip
traditional scanning if you already got it for free.
The only thing missing is a standard scanner -- which was what I was
suggesting. If you implement a standard scanner and it's good, maybe
Tomcat will adopt it and wire it through SCIs because that's what
web containers do.
-chris
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Mark, On 6/14/13 11:54 AM, Mark Thomas wrote: On 14/06/2013 16:38, Rainer Jung wrote: On 14.06.2013 15:43, ma...@apache.org wrote: Author: markt Date: Fri Jun 14 13:43:56 2013 New Revision: 1493066 URL: http://svn.apache.org/r1493066 Log: Container provided JARs should not be scanned for deployment annotations nor should they be checked for web-fragment.xml files. Sorry I haven't really investigated this, but: - I think I have seen you committing a change that labels common loader loaded Jars as container provided Correct. - we usually suggest to pack JDBC drivers into the common loader, right? Correct. So as a general consistency check to the above: we don't expect JDBC drivers to contain relevant annotations, web fragments etc. in the near future? I certainly don't. I was actually hoping that certain JDBC drivers would start packaging a listener that could do things like stop driver-launched threads, etc. that the user doesn't really know have been started. Will this then always be a requirement of the webapp to provide a listener that essentially does nothing on startup but then terminates things on shutdown? Or is the idea that these issues are moot unless the driver is actually in WEB-INF/lib and in that case the listeners will actually be discovered and fire? -chris signature.asc Description: OpenPGP digital signature
Re: Jar scanning, SCI scanning, fragment scanning
Romain,
On 6/14/13 12:13 PM, Romain Manni-Bucau wrote:
Cdi handle interfaces too which are not Object.
There are interfaces which are do not extend Object?
There is essentially a base interface that declares every method in
java.lang.Object. It's simply not possible to have an instance of an
interface that does not have a toString method, for example.
java.lang.Object.class.isAssignableFrom([any class or interface]) will
always return true.
So I would expect that @HandlesType('java.lang.Object') will work.
I have not actually tested it, though.
-chris
signature.asc
Description: OpenPGP digital signature
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 16:57, Christopher Schultz wrote: Mark, On 6/14/13 3:16 AM, Mark Thomas wrote: On 14/06/2013 03:31, Christopher Schultz wrote: It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. That is what ServletContainerIniiializers are for. Well, crap. I had never seen those before. I'm curious, though. Thinking about this the other day with a colleague who was complaining about some kind of Spring configuration that evidently loaded every class available on the classpath and kept them in memory (thus leading to heap and PermGen issues), I concluded that the only sane way to do this kind of probing would be to probe everything in a ClassLoader that was intended to be discarded after the probing as to avoid loading classes unnecessarily. If an SCI retains a reference to any of the Class objects in the SetClass parameter, that hypothetical throw-away ClassLoader is no longer thrown-away. The early Tomcat 7 implementations did it like this - loaded every class and then examined the class object. More recent implementations use BCEL to look at the byte code. It is faster and uses less memory. We also use caching to ensure each class is only processed once. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
On 14/06/2013 17:15, Christopher Schultz wrote: I was actually hoping that certain JDBC drivers would start packaging a listener that could do things like stop driver-launched threads, etc. that the user doesn't really know have been started. Will this then always be a requirement of the webapp to provide a listener that essentially does nothing on startup but then terminates things on shutdown? They'd have to include an SCI (which is always processed) and that SCI can register a ServletContextListener. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
Mark,
On 6/14/13 12:21 PM, Mark Thomas wrote:
On 14/06/2013 16:57, Christopher Schultz wrote:
Mark,
On 6/14/13 3:16 AM, Mark Thomas wrote:
On 14/06/2013 03:31, Christopher Schultz wrote:
It might be nice if this were not a one-of-many decision, but if a
client could choose more than one type. A bit-mask or a list of
scan-types would be nice. I could see the same type of scanner being
used for multiple different purposes.
That is what ServletContainerIniiializers are for.
Well, crap. I had never seen those before.
I'm curious, though. Thinking about this the other day with a colleague
who was complaining about some kind of Spring configuration that
evidently loaded every class available on the classpath and kept them in
memory (thus leading to heap and PermGen issues), I concluded that the
only sane way to do this kind of probing would be to probe everything in
a ClassLoader that was intended to be discarded after the probing as to
avoid loading classes unnecessarily.
If an SCI retains a reference to any of the Class objects in the
SetClass parameter, that hypothetical throw-away ClassLoader is no
longer thrown-away.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
Cool. What Classloader gets used to actually load the Class objects,
though? In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?
One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Mark, On 6/14/13 12:22 PM, Mark Thomas wrote: On 14/06/2013 17:15, Christopher Schultz wrote: I was actually hoping that certain JDBC drivers would start packaging a listener that could do things like stop driver-launched threads, etc. that the user doesn't really know have been started. Will this then always be a requirement of the webapp to provide a listener that essentially does nothing on startup but then terminates things on shutdown? They'd have to include an SCI (which is always processed) and that SCI can register a ServletContextListener. Sorry... I'm not yet sensitive to the different language being used here. I read the original commit comment as don't scan container JARs at all instead of what you said which was to not scan for annotations. Big difference ;) -chris signature.asc Description: OpenPGP digital signature
Re: Jar scanning, SCI scanning, fragment scanning
On 14 June 2013 17:35, Christopher Schultz ch...@christopherschultz.net wrote:
Mark,
On 6/14/13 12:21 PM, Mark Thomas wrote:
On 14/06/2013 16:57, Christopher Schultz wrote:
Mark,
On 6/14/13 3:16 AM, Mark Thomas wrote:
On 14/06/2013 03:31, Christopher Schultz wrote:
It might be nice if this were not a one-of-many decision, but if a
client could choose more than one type. A bit-mask or a list of
scan-types would be nice. I could see the same type of scanner being
used for multiple different purposes.
That is what ServletContainerIniiializers are for.
Well, crap. I had never seen those before.
I'm curious, though. Thinking about this the other day with a colleague
who was complaining about some kind of Spring configuration that
evidently loaded every class available on the classpath and kept them in
memory (thus leading to heap and PermGen issues), I concluded that the
only sane way to do this kind of probing would be to probe everything in
a ClassLoader that was intended to be discarded after the probing as to
avoid loading classes unnecessarily.
If an SCI retains a reference to any of the Class objects in the
SetClass parameter, that hypothetical throw-away ClassLoader is no
longer thrown-away.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.
Cool. What Classloader gets used to actually load the Class objects,
though?
BCEL reads class files as files.
http://commons.apache.org/proper/commons-bcel/
In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?
One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
FYI xbean has runtime constraints bcel skips (valid read and loaded info
are consistent)
Le 14 juin 2013 18:56, sebb seb...@gmail.com a écrit :
On 14 June 2013 17:35, Christopher Schultz ch...@christopherschultz.net
wrote:
Mark,
On 6/14/13 12:21 PM, Mark Thomas wrote:
On 14/06/2013 16:57, Christopher Schultz wrote:
Mark,
On 6/14/13 3:16 AM, Mark Thomas wrote:
On 14/06/2013 03:31, Christopher Schultz wrote:
It might be nice if this were not a one-of-many decision, but if a
client could choose more than one type. A bit-mask or a list of
scan-types would be nice. I could see the same type of scanner being
used for multiple different purposes.
That is what ServletContainerIniiializers are for.
Well, crap. I had never seen those before.
I'm curious, though. Thinking about this the other day with a colleague
who was complaining about some kind of Spring configuration that
evidently loaded every class available on the classpath and kept them
in
memory (thus leading to heap and PermGen issues), I concluded that the
only sane way to do this kind of probing would be to probe everything
in
a ClassLoader that was intended to be discarded after the probing as to
avoid loading classes unnecessarily.
If an SCI retains a reference to any of the Class objects in the
SetClass parameter, that hypothetical throw-away ClassLoader is no
longer thrown-away.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.
Cool. What Classloader gets used to actually load the Class objects,
though?
BCEL reads class files as files.
http://commons.apache.org/proper/commons-bcel/
In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?
One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
Sebb, On 6/14/13 12:55 PM, sebb wrote: On 14 June 2013 17:35, Christopher Schultz ch...@christopherschultz.net wrote: Mark, On 6/14/13 12:21 PM, Mark Thomas wrote: On 14/06/2013 16:57, Christopher Schultz wrote: Mark, On 6/14/13 3:16 AM, Mark Thomas wrote: On 14/06/2013 03:31, Christopher Schultz wrote: It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. That is what ServletContainerIniiializers are for. Well, crap. I had never seen those before. I'm curious, though. Thinking about this the other day with a colleague who was complaining about some kind of Spring configuration that evidently loaded every class available on the classpath and kept them in memory (thus leading to heap and PermGen issues), I concluded that the only sane way to do this kind of probing would be to probe everything in a ClassLoader that was intended to be discarded after the probing as to avoid loading classes unnecessarily. If an SCI retains a reference to any of the Class objects in the SetClass parameter, that hypothetical throw-away ClassLoader is no longer thrown-away. The early Tomcat 7 implementations did it like this - loaded every class and then examined the class object. More recent implementations use BCEL to look at the byte code. It is faster and uses less memory. We also use caching to ensure each class is only processed once. That functionality sounds like it might be useful as a general purpose library item, possibly as part of a utility jar for Commons BCEL. For example JMeter has to scan classes for certain interfaces on startup. It's current implementation is a bit wasteful. Cool. What Classloader gets used to actually load the Class objects, though? BCEL reads class files as files. http://commons.apache.org/proper/commons-bcel/ No, I get that, but the scanner ultimately has to use a ClassLoader to load Class objects so they can be passed-off to the SCIs. Which ClassLoader does that? -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1493066 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
On 14.06.2013 18:36, Christopher Schultz wrote: Mark, On 6/14/13 12:22 PM, Mark Thomas wrote: On 14/06/2013 17:15, Christopher Schultz wrote: I was actually hoping that certain JDBC drivers would start packaging a listener that could do things like stop driver-launched threads, etc. that the user doesn't really know have been started. Will this then always be a requirement of the webapp to provide a listener that essentially does nothing on startup but then terminates things on shutdown? They'd have to include an SCI (which is always processed) and that SCI can register a ServletContextListener. Sorry... I'm not yet sensitive to the different language being used here. I read the original commit comment as don't scan container JARs at all instead of what you said which was to not scan for annotations. Big difference ;) Yup, later commit by mark http://svn.apache.org/r1493080 clarified SCI use for container Jars. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
Geronimo's xbean-finder also supplies this functionality using asm.
david jencks
On Jun 14, 2013, at 9:55 AM, sebb seb...@gmail.com wrote:
On 14 June 2013 17:35, Christopher Schultz ch...@christopherschultz.net
wrote:
Mark,
On 6/14/13 12:21 PM, Mark Thomas wrote:
On 14/06/2013 16:57, Christopher Schultz wrote:
Mark,
On 6/14/13 3:16 AM, Mark Thomas wrote:
On 14/06/2013 03:31, Christopher Schultz wrote:
It might be nice if this were not a one-of-many decision, but if a
client could choose more than one type. A bit-mask or a list of
scan-types would be nice. I could see the same type of scanner being
used for multiple different purposes.
That is what ServletContainerIniiializers are for.
Well, crap. I had never seen those before.
I'm curious, though. Thinking about this the other day with a colleague
who was complaining about some kind of Spring configuration that
evidently loaded every class available on the classpath and kept them in
memory (thus leading to heap and PermGen issues), I concluded that the
only sane way to do this kind of probing would be to probe everything in
a ClassLoader that was intended to be discarded after the probing as to
avoid loading classes unnecessarily.
If an SCI retains a reference to any of the Class objects in the
SetClass parameter, that hypothetical throw-away ClassLoader is no
longer thrown-away.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.
Cool. What Classloader gets used to actually load the Class objects,
though?
BCEL reads class files as files.
http://commons.apache.org/proper/commons-bcel/
In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?
One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493194 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java
Author: markt
Date: Fri Jun 14 18:32:18 2013
New Revision: 1493194
URL: http://svn.apache.org/r1493194
Log:
Special handling for isUserInRole(*)
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Request.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1493194r1=1493193r2=1493194view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Jun 14
18:32:18 2013
@@ -2296,6 +2296,12 @@ public class Request
return false;
}
+// If the role is * then the return value must be false
+// Servlet 31, section 13.3
+if (*.equals(role)) {
+return false;
+}
+
Realm realm = context.getRealm();
if (realm == null) {
return false;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On 14/06/2013 18:53, Christopher Schultz wrote: BCEL reads class files as files. http://commons.apache.org/proper/commons-bcel/ No, I get that, but the scanner ultimately has to use a ClassLoader to load Class objects so they can be passed-off to the SCIs. Which ClassLoader does that? The web application class loader. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493197 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java
Author: markt
Date: Fri Jun 14 18:43:13 2013
New Revision: 1493197
URL: http://svn.apache.org/r1493197
Log:
Special handling for isUserInRole(**)
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Request.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1493197r1=1493196r2=1493197view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Jun 14
18:43:13 2013
@@ -2302,6 +2302,12 @@ public class Request
return false;
}
+// If the role is ** then, unless the application defines a role with
+// that name, only check if the user is authenticated
+if (**.equals(role) !context.findSecurityRole(**)) {
+return userPrincipal != null;
+}
+
Realm realm = context.getRealm();
if (realm == null) {
return false;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1493231 - /tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java
Author: markt Date: Fri Jun 14 20:14:05 2013 New Revision: 1493231 URL: http://svn.apache.org/r1493231 Log: Fix typos Modified: tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java Modified: tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java?rev=1493231r1=1493230r2=1493231view=diff == --- tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java (original) +++ tomcat/trunk/test/org/apache/catalina/authenticator/TestFormAuthenticator.java Fri Jun 14 20:14:05 2013 @@ -47,13 +47,13 @@ import org.apache.tomcat.websocket.serve *achievable with servlets, jsps, jstl (all of which which can ask for an *encoded url to be inserted into the dynamic web page). It cannot work *with static html. - *note: this test class uses the tomcat somaple jsps, which conform. + *note: this test class uses the Tomcat sample jsps, which conform. * * 3. Therefore, any webapp that MIGHT need to authenticate a client that *does not accept cookies MUST generate EVERY protected resource url *dynamically (so that it will include the current session ID). * - * 4. Any webapp that cannot satify case 3 MUST turn off + * 4. Any webapp that cannot satisfy case 3 MUST turn off *changeSessionIdOnAuthentication for its Context and thus degrade the *session fixation protection for ALL of its clients. *note from MarkT: Not sure I agree with this. If the URLs aren't - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
