svn commit: r691887 - /tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java
Author: rjung
Date: Thu Sep 4 00:02:33 2008
New Revision: 691887
URL: http://svn.apache.org/viewvc?rev=691887&view=rev
Log:
Reduce log statement to 1 line using
more precise info, in the expected case and only
log the detailed info in the unexpected case.
Modified:
tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java
Modified: tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java?rev=691887&r1=691886&r2=691887&view=diff
==
--- tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java (original)
+++ tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java Thu Sep 4
00:02:33 2008
@@ -19,11 +19,13 @@
import java.io.File;
import java.io.FileInputStream;
+import java.io.FilePermission;
import java.io.IOException;
import java.io.InputStream;
import java.net.URLClassLoader;
import java.security.AccessControlException;
import java.security.AccessController;
+import java.security.Permission;
import java.security.PrivilegedAction;
import java.util.Collections;
import java.util.Enumeration;
@@ -308,10 +310,15 @@
if (info != null) {
Logger log = info.loggers.get("");
if (log != null) {
-log.warning("You need to permit read access to your
context specific java.util.logging logging configuration to " +
ClassLoaderLogManager.class);
-log.warning("See \"per context logging\" in the
default catalina.policy file.");
+Permission perm = ace.getPermission();
+if (perm instanceof FilePermission &&
perm.getActions().equals("read")) {
+log.warning("Reading " + perm.getName() + " is not
permitted. See \"per context logging\" in the default catalina.policy file.");
+}
+else {
+log.warning("Reading logging.properties is not
permitted in some context. See \"per context logging\" in the default
catalina.policy file.");
log.warning("Original error was: " + ace.getMessage());
- }
+}
+}
}
}
if ((is == null) && (classLoader ==
ClassLoader.getSystemClassLoader())) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45737] New: AcessControlException when using security manager: juli can't read logging.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=45737 Summary: AcessControlException when using security manager: juli can't read logging.properties Product: Tomcat 5 Version: 5.5.26 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the security manager with the default security policy (catalina.policy), Tomcat 5.5.26 and 5.5.27 will throw an AccessControlException for each loaded context during startup. Workaround -- Check the contents of the files WEB-INF/lib/logging.properties for each of your contexts. If those look safe, you can add read permission for these files to the juli package in your security policy. See "per context logging" in catalina.policy. Note that by CVE-2007-5342 you should make sure, that the webapp provided logging.properties do not try to manipulate data outdise of the context, like overwriting other contexts log files. Fix --- A fix has been proposed for backport from trunk. It will log the situation and no longer throw an exception. This issue is meant as a reference for users running into the problem. It should be closed after the backport. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r691894 - /tomcat/current/tc5.5.x/STATUS.txt
Author: rjung Date: Thu Sep 4 00:35:51 2008 New Revision: 691894 URL: http://svn.apache.org/viewvc?rev=691894&view=rev Log: Enhance backport proposal. Modified: tomcat/current/tc5.5.x/STATUS.txt Modified: tomcat/current/tc5.5.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=691894&r1=691893&r2=691894&view=diff == --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Thu Sep 4 00:35:51 2008 @@ -70,6 +70,7 @@ per context logging under the security manager. http://svn.apache.org/viewvc?rev=691675&view=rev http://svn.apache.org/viewvc?rev=691677&view=rev + http://svn.apache.org/viewvc?rev=691887&view=rev The backport needs a couple of casts, because we don't have generics. Note: for some reason handlers for the root logger are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r691893 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Thu Sep 4 00:35:31 2008 New Revision: 691893 URL: http://svn.apache.org/viewvc?rev=691893&view=rev Log: Enhance backport proposal. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=691893&r1=691892&r2=691893&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 4 00:35:31 2008 @@ -152,6 +152,7 @@ per context logging under the security manager. http://svn.apache.org/viewvc?rev=691675&view=rev http://svn.apache.org/viewvc?rev=691677&view=rev + http://svn.apache.org/viewvc?rev=691887&view=rev I suggest to also backport http://svn.apache.org/viewvc?view=rev&revision=687508 because it is low risk (generics) and keeps the class @@ -159,3 +160,4 @@ +1: rjung 0: remm: the logging should be grouped into a single log entry, I think -1: + rjung: improved the logging with r691887. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat-Lite - part 1
On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache <[EMAIL PROTECTED]> wrote: > On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <[EMAIL PROTECTED]> wrote: > >> Costin Manolache wrote: >> >>> >> >> Cool. In a nutshell - I like all the ideas. >> >> But while I like the idea of ditching Valves/LifecycleListeners - how does >> this work when the component needs to work across multiple ServletContext's? >> The only reason I see that Valves/LifecycleListeners need to yet exist is to >> handle those kind of issues. Examples: AccessLogValve or any Valve which >> needs to act on an the entire Container or a single virtual host. > > Using Filter interface doesn't mean we need to restrict it to a single > ServletContext or not have access to internal objects, > it should be possible to set them at container level. In tomcat-lite I tried > either using the ROOT context, or using a super-context > that comes before root - the filter chain in this context will replace the > existing catalina valve chain. > > There is also a package - java/o.a.tomcat.servlets.addon ( like everything > else in tomcat-lite, name and interfaces are subject to review and > change ) with an attempt to abstract common interfaces that a filter could > use to get extra-access to the container internals. > The interfaces can be implemented by catalina, the new tomcat-lite - and > maybe other containers if the choose so. > Ideally, an extension will check if the container supports the extra > interfaces and if not degrade to single-context mode if not. > > Costin I also like seeing discussion around new ideas for improving Tomcat, and I agree that a minimalistic Tomcat jar distribution could strike a chord with many developers who otherwise use a different servlet container since Tomcat doesn't offer that. Thanks for your work on it! I think one important feature would be the availability of a Tomcat jar, and docs that show how to embed it in a standalone Java application. Even if that was available and the size of the jar was still rather large, people would still use it, I think. Hard disk capacities are getting quite large, machines are getting faster at moving bits around, and having all of Tomcat's regular features and compatibility packaged as a jar file would be worth it. If it could be possible to make the jar file smaller (by offering build-time subsetting maybe? with popular subset jars up for download?), while still maintaining a high degree of compatibility with the full Tomcat distribution, that would be even better. About Valves versus Filters.. I don't see the advantages of using Filters in the container instead of Valves. Here are some reasons I've heard for either completely removing Valves, or for using something else instead of Valves, and my thoughts on each: Reason 1: Valves complicate the container, and are a layer that can be removed. I don't agree that it can just be removed and nothing added right back to replace it. You're talking about replacing Valves with Filters, so no layer would be removed in that case. The feature like Valves is useful, which is why you're suggesting Filters as a replacement. If Tomcat lite's embedding code had a runtime configuration feature for turning off Valves, that would allow a developer to choose to have it as part of the request processing or not (though doing that wouldn't make the Tomcat jar any smaller). Still, if you want Filters where Valves currently are, then you probably wouldn't the binary significantly smaller doing that. Reason 2: Valves are Tomcat-specific and are not cross-container like Filters, so if we used Filters then developers on other servlet containers could also develop and use the Filters. Web container-space code is intentionally not specified in the Servlet Specification, maybe to promote creativity and flexibility in the implementation of web containers. This is a zone where servlet container teams compete with one another, and try to offer value in the form of better capabilities or better performance. They can't offer a better servlet API. That part has to work like it does in all of the other servlet containers. So non-standardized features like Valves and different packaging/embedding models, additional useful configuration options, and better overall performance make people decide to use one servlet container over another. We could try to standardize more features that the Servlet spec does not attempt to standardize, but I think most people won't want to, partially for competitive reasons. We could attempt to adapt Filters to this job, which are already standardized, but their behavior is specified only for webapp-space use, and using Filters for container-space would confuse a lot of people. We would have to have two different kinds of filter mappings, one in web.xml and another in server.xml (right?). I also do favor the strong type differences between Valve and Filter. Right now, it's perfectly clear which is which, and what they're each
Re: [VOTE] Release build 5.5.27
Filip Hanik - Dev Lists wrote: The candidates binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.27/ According to the release process, the 5.5.27 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Even considering the discussion about the startup problems when the security manager and the default policy are used, I think 5.5.27 is stable. I opened up BZ 45737 to make the configuration workaround available to the general user audience. A patch is in trunk and the backport proposal has been added to the STATUS files. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r691963 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm Date: Thu Sep 4 04:06:57 2008 New Revision: 691963 URL: http://svn.apache.org/viewvc?rev=691963&view=rev Log: - Votes. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=691963&r1=691962&r2=691963&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 4 04:06:57 2008 @@ -157,7 +157,10 @@ http://svn.apache.org/viewvc?view=rev&revision=687508 because it is low risk (generics) and keeps the class in sync between trunk and tc6.0.x. - +1: rjung - 0: remm: the logging should be grouped into a single log entry, I think + +1: rjung, remm -1: rjung: improved the logging with r691887. + +* ETag improvement: https://issues.apache.org/bugzilla/show_bug.cgi?id=45735 + +1: remm + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.27
On Sep 2, 2008, at 2:37 PM, Filip Hanik - Dev Lists wrote: The candidates binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.27/ According to the release process, the 5.5.27 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45745] New: memory leak after SecurityException from HostConfig.deployDescriptor
https://issues.apache.org/bugzilla/show_bug.cgi?id=45745 Summary: memory leak after SecurityException from HostConfig.deployDescriptor Product: Tomcat 6 Version: 6.0.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Configure an invalid Context - e.g. with InvokerServlet yet unprivileged. This generates the following exception: Sep 2, 2008 5:26:57 PM org.apache.catalina.startup.HostConfig deployDescriptor SEVERE: Error deploying configuration descriptor vOacisHelp.xml java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.InvokerServlet is privileged and cannot be loaded by this web application at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1134) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4364) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Result: memory leak by repeated attempts to to deploy the Context. Jprofiler clearly shows that the ContextBindings hold on to all the repeatedly created ApplicationContexts even though the Context wasn't successfully deployed. You might argue that this is an avoidable scenario, but I suspect that the Exception handling isn't quite right here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat-Lite - part 1
On Thu, Sep 4, 2008 at 12:47 AM, Jason Brittain <[EMAIL PROTECTED]>wrote: > On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <[EMAIL PROTECTED]> wrote: > > > >> Costin Manolache wrote: > >> > >>> > >> > >> Cool. In a nutshell - I like all the ideas. > >> > >> But while I like the idea of ditching Valves/LifecycleListeners - how > does > >> this work when the component needs to work across multiple > ServletContext's? > >> The only reason I see that Valves/LifecycleListeners need to yet exist > is to > >> handle those kind of issues. Examples: AccessLogValve or any Valve > which > >> needs to act on an the entire Container or a single virtual host. > > > > Using Filter interface doesn't mean we need to restrict it to a single > > ServletContext or not have access to internal objects, > > it should be possible to set them at container level. In tomcat-lite I > tried > > either using the ROOT context, or using a super-context > > that comes before root - the filter chain in this context will replace > the > > existing catalina valve chain. > > > > There is also a package - java/o.a.tomcat.servlets.addon ( like > everything > > else in tomcat-lite, name and interfaces are subject to review and > > change ) with an attempt to abstract common interfaces that a filter > could > > use to get extra-access to the container internals. > > The interfaces can be implemented by catalina, the new tomcat-lite - and > > maybe other containers if the choose so. > > Ideally, an extension will check if the container supports the extra > > interfaces and if not degrade to single-context mode if not. > > > > Costin > > I also like seeing discussion around new ideas for improving Tomcat, > and I agree that a minimalistic Tomcat jar distribution could strike a > chord with many developers who otherwise use a different servlet > container since Tomcat doesn't offer that. Thanks for your work on > it! I think one important feature would be the availability of a > Tomcat jar, and docs that show how to embed it in a standalone Java > application. Even if that was available and the size of the jar was > still rather large, people would still use it, I think. Hard disk > capacities are getting quite large, machines are getting faster at > moving bits around, and having all of Tomcat's regular features and > compatibility packaged as a jar file would be worth it. If it could > be possible to make the jar file smaller (by offering build-time > subsetting maybe? with popular subset jars up for download?), while > still maintaining a high degree of compatibility with the full Tomcat > distribution, that would be even better. The 'lite' is more about complexity and layer reduction, size is just an extra benefit. I care more about the source size than the jar size - while disk is cheap, the time required to understand and maintain a large code is not. > > Reason 1: Valves complicate the container, and are a layer that can be > removed. > I don't agree that it can just be removed and nothing added right back > to replace it. You're talking about replacing Valves with Filters, so > no layer would be removed in that case. The feature like Valves is > useful, which is why you're suggesting Filters as a replacement. If > Tomcat lite's embedding code had a runtime configuration feature for > turning off Valves, that would allow a developer to choose to have it > as part of the request processing or not (though doing that wouldn't > make the Tomcat jar any smaller). Still, if you want Filters where > Valves currently are, then you probably wouldn't the binary > significantly smaller doing that. You can see the code in sandbox/tomcat-lite - the code is currently not using Vavles, Listeners, server.xml, and many other things from catalina, just coyote and filters ( which are mostly refactored from original catalina valves ). That doesn't mean that Valves will dissapear - the plan is to add tomcat-lite engine as an alternative ( module ), but catalina will still be there and I don't plan to remove anything from it. Sure - replacing a Valve with a Filter in lite doesn't change the execution path. However it eliminates all the duplicated code for managing the valve pipeline, configuring valves, etc - we have to do it for Filter ( and in a certain way ), why have 2 times that ? I think the container code is also simpler and cleaner - again, you only have to understand and maintain Filters and filter chains ( very well documented and specified ). > > Reason 2: Valves are Tomcat-specific and are not cross-container like > Filters, so if we used Filters then developers on other servlet > containers could also develop and use the Filters. That's probably the biggest reason I'm proposing Filters instead of Valves :-) The interaction between the Filters and container in tomcat-lite is specified in java/org/apache/tomcat/servlets/addon/, and the goal is to
DO NOT REPLY [Bug 41059] WebAppClassLoader clearReferences code break running threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=41059 Gili <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|enhancement |major OS/Version|other |All Platform|Other |All --- Comment #11 from Gili <[EMAIL PROTECTED]> 2008-09-04 19:04:22 PST --- BTW, this causes Tomcat to hang when shutting down (randomly) for me. It happens rather frequently and is a problem because I restart Tomcat nightly (due to unrelated memory leak problems). I am increasing severity to "major" but leaving the priority as is. Curt I will gladly test out your patch if you can provide me with a drop-in JAR file or otherwise indicate how I can patch my existing Tomcat system without rebuilding the entire thing from source. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
