svn commit: r1590911 - /tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java
Author: markt
Date: Tue Apr 29 08:10:26 2014
New Revision: 1590911
URL: http://svn.apache.org/r1590911
Log:
Correct unit tests now EL Parser has been fixed to correctly parse "\$" as "$".
Modified:
tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java
Modified: tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java?rev=1590911&r1=1590910&r2=1590911&view=diff
==
--- tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java (original)
+++ tomcat/trunk/test/org/apache/jasper/compiler/TestELParser.java Tue Apr 29
08:10:26 2014
@@ -232,13 +232,13 @@ public class TestELParser {
@Test
public void testEscape04() throws JasperException {
-doTestParser("\\$", "\\$");
+doTestParser("\\$", "$");
}
@Test
public void testEscape05() throws JasperException {
-doTestParser("\\#", "\\#");
+doTestParser("\\#", "#");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1590912 - in /tomcat/tc7.0.x/trunk: ./ test/org/apache/jasper/compiler/TestELParser.java
Author: markt
Date: Tue Apr 29 08:12:46 2014
New Revision: 1590912
URL: http://svn.apache.org/r1590912
Log:
Correct unit tests now EL Parser has been fixed to correctly parse "\$" as "$".
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/test/org/apache/jasper/compiler/TestELParser.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1590911
Modified: tomcat/tc7.0.x/trunk/test/org/apache/jasper/compiler/TestELParser.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/jasper/compiler/TestELParser.java?rev=1590912&r1=1590911&r2=1590912&view=diff
==
--- tomcat/tc7.0.x/trunk/test/org/apache/jasper/compiler/TestELParser.java
(original)
+++ tomcat/tc7.0.x/trunk/test/org/apache/jasper/compiler/TestELParser.java Tue
Apr 29 08:12:46 2014
@@ -232,13 +232,13 @@ public class TestELParser {
@Test
public void testEscape04() throws JasperException {
-doTestParser("\\$", "\\$");
+doTestParser("\\$", "$");
}
@Test
public void testEscape05() throws JasperException {
-doTestParser("\\#", "\\#");
+doTestParser("\\#", "#");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1590913 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt
Date: Tue Apr 29 08:14:23 2014
New Revision: 1590913
URL: http://svn.apache.org/r1590913
Log:
Additional patch (I'm assuming Konstantin isn't going to be against this fix to
the unit tests)
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=1590913&r1=1590912&r2=1590913&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Apr 29 08:14:23 2014
@@ -98,6 +98,7 @@ PATCHES PROPOSED TO BACKPORT:
require that "\$" or "\#" must be followed by "{" in order for the back-slash
escaping to take effect.
http://svn.apache.org/r1590838
+ http://svn.apache.org/r1590912
+1: markt, kkolinko
-1:
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1590914 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Tue Apr 29 08:15:53 2014 New Revision: 1590914 URL: http://svn.apache.org/r1590914 Log: Vote 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=1590914&r1=1590913&r2=1590914&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Apr 29 08:15:53 2014 @@ -104,7 +104,7 @@ PATCHES PROPOSED TO BACKPORT: * Additional fixes for BZ 56334 http://svn.apache.org/r1590848 - +1: kkolinko + +1: kkolinko, markt -1: kkolinko: I expect to prepare a more formal patch for this later. The merge is unlikely to complete cleanly without Mark's - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 8.0.6
2014-04-27 1:03 GMT+02:00 Konstantin Kolinko : > If someone is able to edit Buildbot configuration, > maybe it is possible to skip that "RAT report publishing" step? > > The build is now going further, but it seems a folder is missing. http://ci.apache.org/builders/tomcat-trunk/builds/39/steps/MasterShellCommand/logs/stdio Rémy
[Bug 56472] New: All classes remain in memory after stop of web application, when LDAP was used.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56472
Bug ID: 56472
Summary: All classes remain in memory after stop of web
application, when LDAP was used.
Product: Tomcat 7
Version: 7.0.52
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: stefan_fri...@qvc.com
Created attachment 31573
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31573&action=edit
Classes that hold a reference to WebappClassLoader
I have a problem with unloading casses of a web application when I stop it.
All threads are closed, but all 6.000 classes remain in memory. The GC cannot
destroy WebappClassLoader because it is held by a static hashMap of the naming
services which is hold by the VM.
See attached image.
The problem occurs only when the application uses the naming service. I
identified the first method in my application that triggers the problem:
public class MyBindAuthenticator extends BindAuthenticator {
...
@Override
public DirContextOperations authenticate(Authentication authentication) {
...
List userns=getUserDns(username);
...
}
...
}
When I replace this line by a hardcoded list of strings, then the problem gets
triggered by the next call of any naming service method. When I replace the
whole authenticate() method by an empty one, then the problem disappears. But I
need it for security reason.
Unfortunately, the problematic hashmap (with name securityTokens) is not
accessible to me, so I cannot remove the references. I seems that all related
classes are part of Catalina and not reachable from outside.
I would appreciate a workaround, if not bugfix is available.
--
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
udp port used by the tribes tests
Hi, Does someone know which upd ports are used by the tribes tests? I tried to allow 4000-4005 but that didn't help :-( Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: udp port used by the tribes tests
2014-04-29 18:41 GMT+04:00 jean-frederic clere : > Hi, > > Does someone know which upd ports are used by the tribes tests? > I tried to allow 4000-4005 but that didn't help :-( > >From old e-mails in my mailbox I think so. (Some test error messages mention port numbers). I have not looked into the code. Maybe try running org.apache.catalina.tribes.TesterMulticast ? It is mentioned in BUILDING.txt Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: udp port used by the tribes tests
2014-04-29 18:57 GMT+04:00 Konstantin Kolinko : > 2014-04-29 18:41 GMT+04:00 jean-frederic clere : >> Hi, >> >> Does someone know which upd ports are used by the tribes tests? >> I tried to allow 4000-4005 but that didn't help :-( >> > > From old e-mails in my mailbox I think so. (Some test error messages > mention port numbers). I have not looked into the code. > > Maybe try running org.apache.catalina.tribes.TesterMulticast ? > It is mentioned in BUILDING.txt Looking at souгce code and searching through log files of a full Tomcat8 tests run with NIO connector, I can say the following. 4000-4005 are TCP ports The only test that has UDP enabled is org.apache.catalina.tribes.group.TestGroupChannelStartStop It uses "udpPort = 45543". There are two other tests, org.apache.catalina.tribes.test.channel.TestMulticastPackages org.apache.catalina.tribes.test.channel.TestUdpPackages that use "setUdpPort(5)"; but those two tests are excluded by default in build.xml, with The rest of tests are not using UDP. (There are some that log UDP Port=-1, which is the default value for MemberImpl.udpPort, AbstractSender.udpPort, ReceiverBase.udpPort and means that UDP is disabled) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55943] Provide a way prevent looking at the System classloader before the webapp classloaders
https://issues.apache.org/bugzilla/show_bug.cgi?id=55943
Konstantin Kolinko changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #13 from Konstantin Kolinko ---
(In reply to Mark Thomas from comment #6)
The essential bit of r1559153 / r1559134 is the following change:
@@ -1186,9 +1200,9 @@ public class WebappClassLoader extends U
// (0.2) Try loading the class with the system class loader, to
prevent
// the webapp from overriding J2SE classes
String resourceName = binaryNameToPath(name, false);
-if (system.getResource(resourceName) != null) {
+if (j2seClassLoader.getResource(resourceName) != null) {
try {
-clazz = system.loadClass(name);
+clazz = j2seClassLoader.loadClass(name);
The old code used 'System' classloader - the JVM CLASSPATH.
The new code uses 'Bootstrap' classloader - the topmost non-null parent of
System class loader - the one that provides Java SE core classes.
As such, class-loader-howto,html has to be corrected.
The classes lookup order in 7.0.50 and earlier is:
* Bootstrap classes of your JVM
* System class loader classes (described above)
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* Common class loader classes (described above)
For 8.0.0 and 7.0.52 and later it now is
* Bootstrap classes of your JVM
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* System class loader classes (described above)
* Common class loader classes (described above)
I am REOPENING this issue to apply this documentation fix. It is worth noting
this in migration guide.
It may be worth to add that if one configures ,
the above order becomes
* Bootstrap classes of your JVM
* System class loader classes (described above)
* Common class loader classes (described above)
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
One use case when jar is added by Java to the system classloader is using
-javaagent option.
Documentation:
http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/package-summary.html#package_description
A thread:
http://tomcat.markmail.org/thread/trd7yj46qajqra2v
Of course, such jar files should not be in WEB-INF/lib directory.
--
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
