DO NOT REPLY [Bug 47893] New: Use StringBuilder instead of StringBuffer
https://issues.apache.org/bugzilla/show_bug.cgi?id=47893 Summary: Use StringBuilder instead of StringBuffer Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: mguille...@yahoo.fr Created an attachment (id=24305) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24305) Patch replacing usage of StringBuffer by StringBuilder for local variables Tomcat code base uses a lot of StringBuffer where it should use StringBuilder for performance reasons. StringBuilder's JavaDoc is quite explicit: "This class is designed for use as a drop-in replacement for StringBuffer in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations. " The provided patch replaces all usage of StringBuffer by StringBuilder for local variables. It doesn't change any public or protected API even if it would probably make sense (for instance in AccessLogValve.AccessLogElement#addElement) and it doesn't change class fields. Note that the patch just change StringBuffer to StringBuilder even in places where the java compiler would automatically use a StringBuilder when normal string concatenation is used. -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47467] Deployment of the war file by URL when contextpath is not specified in Manager Application.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47467 Uwe Günther changed: What|Removed |Added Platform|PC |All OS/Version|Windows XP |All --- Comment #1 from Uwe Günther 2009-09-23 02:55:30 PDT --- I just investigated a bit in this one and IMHO this bug is realy odd because the documentation in html-manager-howto.xml and o.a.catalina.manager.ManagerServlet is not in sync with what the code does or is designed for. Let me point that out in detail: 1. The docs are talking about JarURLConnection like syntax for the 'WAR or Directory URL' field in the 'Deploy' section of HTMLManagerServlet* (aka known as war parameter there): jar:file:/c:/myWebapp.war!/ ** If you look in the code - you will find out - it can only handle java.io.File like file names (with an optional 'file:' prefix): file:C:/myWebapp.war file://C:/myWebapp.war file:///C:/myWebapp.war file:C:/myWebapp.war file:/C:/myWebapp.war file://C:/myWebapp.war file:C:/myWebapp file://C:/myWebapp file:///C:/myWebapp file:C:/myWebapp file:/C:/myWebapp file://C:/myWebapp C:/myWebapp.war C:\myWebapp.war C:/myWebapp C:\myWebapp Every other filename not ending with '.war' is handled by the code as already exploded directory and gets deployed as such! Back to the point: The existing code in HTMLManagerServlet and ManagerServlet is unable to handle JarURLConnection like syntax like following one mentioned above: jar:file:/c:/myWebapp.war!/ To make it crystal clear here, the only type of URL they can handle are 'file:' URLs based on java.io.File(String) at all. * Note: HTMLManagerServlet is a sub class of ManagerServlet which gets used by the Ant DeployTask as well. So there are common implications. 2.) On the one hand if you deploy a war file remote via the 'Select WAR file to upload' field in the 'Deploy' section of HTMLManagerServlet the 'Context Path' gets derived from the war file name. So you don't need a 'Context Path' to deploy a *.war file. For example if your war file is callled 'myWebapp.war', your 'Context Path' will be '/myWebapp'. On the other hand if you try to deploy a webapp as a *.war or a directory locally via 'WAR or Directory URL' you have to provide a 'Context Path', but it would be possible to derive the 'Context Path' as well from the 'WAR or Directory URL' name like it is done for remote deployments. Proposed Solution: - Fix the documentaion and the HTMLManagerServlet UI to get number 1.) fixed. Especially remove the word 'URL' from the HTMLManagerServlet UI field descriptors and the jar:file: Urls from the javadoc and the html-manager-howto.xml - Enhance ManagerServlet to derive the 'Context Path' (aka 'path' parameter) from an already given 'WAR or Directory' (aka 'war' parameter). For example if you have no 'Context Path' and the 'WAR or Directory' filed contains 'C:\myWebapp' or 'C:\myWebapp.war' the 'Context Path' will be '/myWebapp'. I start to work on this from now on in the trunk and will append the patch as soon as I am finished (probably this week) to this bug, so it can merged in by one of the commiter. Would be nice to get some feedback if the probosed solution fits or not. -- Kind Regards Uwe Günther -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47796] StandardContext's annotationProcessor field gets cached between webapp start/stop cycles
https://issues.apache.org/bugzilla/show_bug.cgi?id=47796 Uwe Günther changed: What|Removed |Added CC||u...@cscc.de -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47467] Deployment of the war file by URL when contextpath is not specified in Manager Application.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47467 Uwe Günther changed: What|Removed |Added CC||u...@cscc.de -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47796] StandardContext's annotationProcessor field gets cached between webapp start/stop cycles
https://issues.apache.org/bugzilla/show_bug.cgi?id=47796 Uwe Günther changed: What|Removed |Added CC|u...@cscc.de | -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r818040 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Wed Sep 23 10:28:29 2009 New Revision: 818040 URL: http://svn.apache.org/viewvc?rev=818040&view=rev Log: Vote and comment. 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=818040&r1=818039&r2=818040&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Sep 23 10:28:29 2009 @@ -291,8 +291,11 @@ * Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=47161 Correctly report thread counts when using executors https://issues.apache.org/bugzilla/attachment.cgi?id=24272 - +1: markt + +1: markt, rjung -1: + rjung: Maybe we should add a few getters to org.apache.catalina.Executor + for TC 7, so we can assume everyone providing an implementation + allows us to query? If they don't use threads, they can return -1 or whatever. * Align native and Java method names. Port/backport from trunk, TC5.5.x, tc4.1.x and tcnative (trunk and 1.1.x) @@ -311,21 +314,28 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47225 Buffer length should be end-offset http://svn.apache.org/viewvc?rev=815972&view=rev - +1: markt, jim + +1: markt, jim, rjung -1: * Fix copyright year on manager app http://svn.apache.org/viewvc?rev=817442&view=rev - +1: markt + +1: markt, rjung -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47267 http://svn.apache.org/viewvc?rev=817822&view=rev +1: markt -1: + rjung: Our dreaded multi platform build system is a bit fragile + w.r.t. fixcrlf. If you change the file to crlf in the installer + target, then all unix packages (which are build after installer) + will also contain it in crlf format. Not to bad for especially + that file (because part of a webapp), but maybe it would + be cleaner to do this for the installer target only, e.g. + saving the file, fixcrlf, run nsi, restoring file. * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47499 Don't swallow BindException https://issues.apache.org/bugzilla/attachment.cgi?id=24302 - +1: markt + +1: markt, rjung -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r818041 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Wed Sep 23 10:30:34 2009 New Revision: 818041 URL: http://svn.apache.org/viewvc?rev=818041&view=rev Log: Add comment. 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=818041&r1=818040&r2=818041&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Sep 23 10:30:34 2009 @@ -247,6 +247,7 @@ rjung: Since the above patches now prepare for using juli optionally out of CATALINA_BASE, shouldn't we also add that location as a codeBase? markt: Maybe add a comment but not an explicit permission? + rjung: Comment sounds good. * Additional fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=45785 for extension validator - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r818043 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: rjung Date: Wed Sep 23 10:34:09 2009 New Revision: 818043 URL: http://svn.apache.org/viewvc?rev=818043&view=rev Log: Vote. Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=818043&r1=818042&r2=818043&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Sep 23 10:34:09 2009 @@ -150,7 +150,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47225 Buffer length should be end-offset http://svn.apache.org/viewvc?rev=815972&view=rev - +1: markt + +1: markt, rjung -1: * Remove native test and examples classes from TC 5.5 @@ -179,6 +179,6 @@ * Fix copyright year on manager app http://svn.apache.org/viewvc?rev=817442&view=rev - +1: markt + +1: markt, rjung -1: - \ No newline at end of file + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r818040 - /tomcat/tc6.0.x/trunk/STATUS.txt
rj...@apache.org wrote: > * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47267 >http://svn.apache.org/viewvc?rev=817822&view=rev >+1: markt >-1: > + rjung: Our dreaded multi platform build system is a bit fragile > + w.r.t. fixcrlf. If you change the file to crlf in the installer > + target, then all unix packages (which are build after installer) > + will also contain it in crlf format. Not to bad for especially > + that file (because part of a webapp), but maybe it would > + be cleaner to do this for the installer target only, e.g. > + saving the file, fixcrlf, run nsi, restoring file. Are you sure? There looks to be a fixcrlf at the beginning of each of the zip and tar.gz packaging targets which should fix that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r818040 - /tomcat/tc6.0.x/trunk/STATUS.txt
On 23.09.2009 13:12, Mark Thomas wrote: > rj...@apache.org wrote: >> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47267 >>http://svn.apache.org/viewvc?rev=817822&view=rev >>+1: markt >>-1: >> + rjung: Our dreaded multi platform build system is a bit fragile >> + w.r.t. fixcrlf. If you change the file to crlf in the installer >> + target, then all unix packages (which are build after installer) >> + will also contain it in crlf format. Not to bad for especially >> + that file (because part of a webapp), but maybe it would >> + be cleaner to do this for the installer target only, e.g. >> + saving the file, fixcrlf, run nsi, restoring file. > > Are you sure? There looks to be a fixcrlf at the beginning of each of > the zip and tar.gz packaging targets which should fix that. I thought so to, but I tested it :) I guess, the *.txt pattern in those fixcrlf applies only to top level, no **/ there. But somehow I think it would be safer to let the installer fixcrlf not have a side effect one needs to clean up in other places. Well ... regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r818061 - in /tomcat/tc5.5.x/trunk: ./ container/modules/cluster/src/share/org/apache/catalina/cluster/session/ container/webapps/docs/
Author: rjung
Date: Wed Sep 23 11:24:22 2009
New Revision: 818061
URL: http://svn.apache.org/viewvc?rev=818061&view=rev
Log:
DeltaManager needs to replicate changed attributes even if session
gets invalidated. Otherwise session listeners will not see the right
data on the secondary nodes.
Ported from r812427 of OACC.
Modified:
tomcat/tc5.5.x/trunk/STATUS.txt
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Modified: tomcat/tc5.5.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=818061&r1=818060&r2=818061&view=diff
==
--- tomcat/tc5.5.x/trunk/STATUS.txt (original)
+++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Sep 23 11:24:22 2009
@@ -94,15 +94,6 @@
+1: markt
-1:
-* Fix cluster replication problem: session expiration uses a replication
- shortcut, so that attributes changed immediately before invalidation do
- not get replicated before the expiration replication message.
- That's a problem in case a session listener needs the changed attribute.
- Patch:
http://people.apache.org/~rjung/patches/TC5.5-cluster-replicate-before-expire.patch
- This has already been applied to OACC:
http://svn.apache.org/viewvc?rev=812427&view=rev
- +1: rjung, pero, markt
- -1:
-
* Port r795052 from modules/ha to modules/cluster
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=40551
Enable the JvmRouteBinderValve to work with PersistentManagers as well as
clusters
Modified:
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java?rev=818061&r1=818060&r2=818061&view=diff
==
---
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
(original)
+++
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Wed Sep 23 11:24:22 2009
@@ -1308,6 +1308,25 @@
* @return a SessionMessage to be sent,
*/
public ClusterMessage requestCompleted(String sessionId) {
+return requestCompleted(sessionId, false);
+}
+
+/**
+ * When the request has been completed, the replication valve will notify
+ * the manager, and the manager will decide whether any replication is
+ * needed or not. If there is a need for replication, the manager will
+ * create a session message and that will be replicated. The cluster
+ * determines where it gets sent.
+ *
+ * Session expiration also calls this method, but with expires == true.
+ *
+ * @param sessionId -
+ *the sessionId that just completed.
+ * @param expires -
+ *whether this method has been called during session expiration
+ * @return a SessionMessage to be sent,
+ */
+public ClusterMessage requestCompleted(String sessionId, boolean expires) {
try {
DeltaSession session = (DeltaSession) findSession(sessionId);
DeltaRequest deltaRequest = session.getDeltaRequest();
@@ -1325,7 +1344,7 @@
}
}
if(!isDeltaRequest) {
-if(!session.isPrimarySession()) {
+if(!expires && !session.isPrimarySession()) {
counterSend_EVT_SESSION_ACCESSED++;
msg = new SessionMessageImpl(getName(),
SessionMessage.EVT_SESSION_ACCESSED, null,
sessionId,
@@ -1343,9 +1362,10 @@
getName(), sessionId));
}
}
-session.setPrimarySession(true);
+if (!expires)
+session.setPrimarySession(true);
//check to see if we need to send out an access message
-if ((msg == null)) {
+if (!expires && (msg == null)) {
long replDelta = System.currentTimeMillis()
- session.getLastTimeReplicated();
if (replDelta >= updateActiveInterval*1000 ||
Modified:
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java?rev=818061&r1=818060&r2=818061&view=diff
==
---
tomcat/tc5.5.x/trunk/container/modules/cluster/src/share/org/apache/catal
svn commit: r818062 - in /tomcat/trunk/java/org/apache/catalina/ha/session: DeltaManager.java DeltaSession.java
Author: rjung
Date: Wed Sep 23 11:28:14 2009
New Revision: 818062
URL: http://svn.apache.org/viewvc?rev=818062&view=rev
Log:
DeltaManager needs to replicate changed attributes even if session
gets invalidated. Otherwise session listeners will not see the right
data on the secondary nodes.
Port of r818061 from TC 5.5.x.
Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?rev=818062&r1=818061&r2=818062&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java Wed Sep
23 11:28:14 2009
@@ -1108,6 +1108,25 @@
* @return a SessionMessage to be sent,
*/
public ClusterMessage requestCompleted(String sessionId) {
+ return requestCompleted(sessionId, false);
+ }
+
+ /**
+ * When the request has been completed, the replication valve will notify
+ * the manager, and the manager will decide whether any replication is
+ * needed or not. If there is a need for replication, the manager will
+ * create a session message and that will be replicated. The cluster
+ * determines where it gets sent.
+ *
+ * Session expiration also calls this method, but with expires == true.
+ *
+ * @param sessionId -
+ *the sessionId that just completed.
+ * @param expires -
+ *whether this method has been called during session
expiration
+ * @return a SessionMessage to be sent,
+ */
+ public ClusterMessage requestCompleted(String sessionId, boolean expires)
{
DeltaSession session = null;
try {
session = (DeltaSession) findSession(sessionId);
@@ -1129,7 +1148,7 @@
}
}
if(!isDeltaRequest) {
-if(!session.isPrimarySession()) {
+if(!expires && !session.isPrimarySession()) {
counterSend_EVT_SESSION_ACCESSED++;
msg = new SessionMessageImpl(getName(),
SessionMessage.EVT_SESSION_ACCESSED,
@@ -1145,9 +1164,10 @@
log.debug(sm.getString("deltaManager.createMessage.delta",getName(),
sessionId));
}
}
-session.setPrimarySession(true);
+if (!expires)
+session.setPrimarySession(true);
//check to see if we need to send out an access message
-if ((msg == null)) {
+if (!expires && (msg == null)) {
long replDelta = System.currentTimeMillis() -
session.getLastTimeReplicated();
if (replDelta > (getMaxInactiveInterval() * 1000)) {
counterSend_EVT_SESSION_ACCESSED++;
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=818062&r1=818061&r2=818062&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Wed Sep
23 11:28:14 2009
@@ -38,7 +38,9 @@
import org.apache.catalina.Manager;
import org.apache.catalina.SessionListener;
import org.apache.catalina.ha.ClusterManager;
+import org.apache.catalina.ha.CatalinaCluster;
import org.apache.catalina.ha.ClusterSession;
+import org.apache.catalina.ha.ClusterMessage;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.session.StandardSession;
import org.apache.catalina.tribes.io.ReplicationStream;
@@ -373,7 +375,24 @@
}
public void expire(boolean notify, boolean notifyCluster) {
+if (expiring)
+return;
String expiredId = getIdInternal();
+
+if(expiredId != null && manager != null &&
+ manager instanceof DeltaManager) {
+DeltaManager dmanager = (DeltaManager)manager;
+CatalinaCluster cluster = dmanager.getCluster();
+ClusterMessage msg = dmanager.requestCompleted(expiredId, true);
+if (msg != null) {
+if(dmanager.doDomainReplication()) {
+cluster.sendClusterDomain(msg);
+} else {
+cluster.send(msg);
+}
+}
+}
+
super.expire(notify);
if (notifyCluster) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomca
svn commit: r818068 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Wed Sep 23 12:00:46 2009 New Revision: 818068 URL: http://svn.apache.org/viewvc?rev=818068&view=rev Log: 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=818068&r1=818067&r2=818068&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Sep 23 12:00:46 2009 @@ -340,3 +340,12 @@ https://issues.apache.org/bugzilla/attachment.cgi?id=24302 +1: markt, rjung -1: + +* Fix cluster replication problem: session expiration uses a replication + shortcut, so that attributes changed immediately before invalidation do + not get replicated before the expiration replication message. + That's a problem in case a session listener needs the changed attribute. + Has already been fixed in trunk, OACC and tc5.5.x. + http://svn.apache.org/viewvc?rev=818062&view=rev (trunk) + +1: rjung + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Port r818062 to BackupManager?
Hi Filip,
I think the below needs some kind of port to the BackupManager.
Ideas?
Regards,
Rainer
On 23.09.2009 13:28, rj...@apache.org wrote:
> Author: rjung
> Date: Wed Sep 23 11:28:14 2009
> New Revision: 818062
>
> URL: http://svn.apache.org/viewvc?rev=818062&view=rev
> Log:
> DeltaManager needs to replicate changed attributes even if session
> gets invalidated. Otherwise session listeners will not see the right
> data on the secondary nodes.
>
> Port of r818061 from TC 5.5.x.
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
> tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
>
> Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?rev=818062&r1=818061&r2=818062&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java Wed
> Sep 23 11:28:14 2009
> @@ -1108,6 +1108,25 @@
> * @return a SessionMessage to be sent,
> */
> public ClusterMessage requestCompleted(String sessionId) {
> + return requestCompleted(sessionId, false);
> + }
> +
> + /**
> + * When the request has been completed, the replication valve will
> notify
> + * the manager, and the manager will decide whether any replication is
> + * needed or not. If there is a need for replication, the manager will
> + * create a session message and that will be replicated. The cluster
> + * determines where it gets sent.
> + *
> + * Session expiration also calls this method, but with expires == true.
> + *
> + * @param sessionId -
> + *the sessionId that just completed.
> + * @param expires -
> + *whether this method has been called during session
> expiration
> + * @return a SessionMessage to be sent,
> + */
> + public ClusterMessage requestCompleted(String sessionId, boolean
> expires) {
> DeltaSession session = null;
> try {
> session = (DeltaSession) findSession(sessionId);
> @@ -1129,7 +1148,7 @@
> }
> }
> if(!isDeltaRequest) {
> -if(!session.isPrimarySession()) {
> +if(!expires && !session.isPrimarySession()) {
> counterSend_EVT_SESSION_ACCESSED++;
> msg = new SessionMessageImpl(getName(),
>
> SessionMessage.EVT_SESSION_ACCESSED,
> @@ -1145,9 +1164,10 @@
>
> log.debug(sm.getString("deltaManager.createMessage.delta",getName(),
> sessionId));
> }
> }
> -session.setPrimarySession(true);
> +if (!expires)
> +session.setPrimarySession(true);
> //check to see if we need to send out an access message
> -if ((msg == null)) {
> +if (!expires && (msg == null)) {
> long replDelta = System.currentTimeMillis() -
> session.getLastTimeReplicated();
> if (replDelta > (getMaxInactiveInterval() * 1000)) {
> counterSend_EVT_SESSION_ACCESSED++;
>
> Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=818062&r1=818061&r2=818062&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Wed
> Sep 23 11:28:14 2009
> @@ -38,7 +38,9 @@
> import org.apache.catalina.Manager;
> import org.apache.catalina.SessionListener;
> import org.apache.catalina.ha.ClusterManager;
> +import org.apache.catalina.ha.CatalinaCluster;
> import org.apache.catalina.ha.ClusterSession;
> +import org.apache.catalina.ha.ClusterMessage;
> import org.apache.catalina.realm.GenericPrincipal;
> import org.apache.catalina.session.StandardSession;
> import org.apache.catalina.tribes.io.ReplicationStream;
> @@ -373,7 +375,24 @@
> }
>
> public void expire(boolean notify, boolean notifyCluster) {
> +if (expiring)
> +return;
> String expiredId = getIdInternal();
> +
> +if(expiredId != null && manager != null &&
> + manager instanceof DeltaManager) {
> +DeltaManager dmanager = (DeltaManager)manager;
> +CatalinaCluster cluster = dmanager.getCluster();
> +ClusterMessage msg = dmanager.requestCompleted(expiredId, true);
> +if (msg != null) {
> +if(dmanage
svn commit: r818074 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: rjung Date: Wed Sep 23 12:23:51 2009 New Revision: 818074 URL: http://svn.apache.org/viewvc?rev=818074&view=rev Log: Add proposal. Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=818074&r1=818073&r2=818074&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Sep 23 12:23:51 2009 @@ -172,4 +172,13 @@ http://svn.apache.org/viewvc?rev=817442&view=rev +1: markt, rjung -1: - + +* Fix cluster replication problem for o.a.c.ha: session expiration + uses a replication shortcut, so that attributes changed immediately + before invalidation do not get replicated before the expiration + replication message. That's a problem in case a session listener + needs the changed attribute. + Has already been fixed in trunk, OACC and tc5.5.x (only in o.a.c.cluster). + http://svn.apache.org/viewvc?rev=818062&view=rev (trunk) + +1: rjung + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r818040 - /tomcat/tc6.0.x/trunk/STATUS.txt
Rainer Jung wrote: > On 23.09.2009 13:12, Mark Thomas wrote: >> rj...@apache.org wrote: >>> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47267 >>>http://svn.apache.org/viewvc?rev=817822&view=rev >>>+1: markt >>>-1: >>> + rjung: Our dreaded multi platform build system is a bit fragile >>> + w.r.t. fixcrlf. If you change the file to crlf in the installer >>> + target, then all unix packages (which are build after installer) >>> + will also contain it in crlf format. Not to bad for especially >>> + that file (because part of a webapp), but maybe it would >>> + be cleaner to do this for the installer target only, e.g. >>> + saving the file, fixcrlf, run nsi, restoring file. >> Are you sure? There looks to be a fixcrlf at the beginning of each of >> the zip and tar.gz packaging targets which should fix that. > > I thought so to, but I tested it :) That always helps :) It doesn't really matter for webapps and we do just leave the files with whatever line ending they had when the files were built. I'll look at completely re-doign this for Tomcat 7. I think Sebb proposed a patch somewhere that will probably help. > I guess, the *.txt pattern in those fixcrlf applies only to top level, > no **/ there. But somehow I think it would be safer to let the installer > fixcrlf not have a side effect one needs to clean up in other places. > > Well ... I see where you are coming from. I'll take a lok at Tomcat 7 and then we can figure out what to port back, if anything. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r818040 - /tomcat/tc6.0.x/trunk/STATUS.txt
On 23/09/2009, Mark Thomas wrote: > Rainer Jung wrote: > > On 23.09.2009 13:12, Mark Thomas wrote: > >> rj...@apache.org wrote: > >>> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47267 > >>>http://svn.apache.org/viewvc?rev=817822&view=rev > >>>+1: markt > >>>-1: > >>> + rjung: Our dreaded multi platform build system is a bit fragile > >>> + w.r.t. fixcrlf. If you change the file to crlf in the installer > >>> + target, then all unix packages (which are build after installer) > >>> + will also contain it in crlf format. Not to bad for especially > >>> + that file (because part of a webapp), but maybe it would > >>> + be cleaner to do this for the installer target only, e.g. > >>> + saving the file, fixcrlf, run nsi, restoring file. > >> Are you sure? There looks to be a fixcrlf at the beginning of each of > >> the zip and tar.gz packaging targets which should fix that. > > > > I thought so to, but I tested it :) > > > That always helps :) > > It doesn't really matter for webapps and we do just leave the files with > whatever line ending they had when the files were built. I'll look at > completely re-doign this for Tomcat 7. I think Sebb proposed a patch > somewhere that will probably help. https://issues.apache.org/bugzilla/show_bug.cgi?id=47609 > > I guess, the *.txt pattern in those fixcrlf applies only to top level, > > no **/ there. But somehow I think it would be safer to let the installer > > fixcrlf not have a side effect one needs to clean up in other places. > > > > Well ... > > > I see where you are coming from. I'll take a lok at Tomcat 7 and then we > can figure out what to port back, if anything. > > > Mark > > > > > > - > 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
Re: Port r818062 to BackupManager?
hi Rainer,
DeltaManager needs to replicate changed attributes even if session
gets invalidated. Otherwise session listeners will not see the right
data on the secondary nodes.
This is an interesting use case indeed. The fact that we would replicate
changes on an invalidated session sounds awkward.
I will have to take a look when I have some more brain capacity
Filip
On 09/23/2009 06:18 AM, Rainer Jung wrote:
Hi Filip,
I think the below needs some kind of port to the BackupManager.
Ideas?
Regards,
Rainer
On 23.09.2009 13:28, rj...@apache.org wrote:
Author: rjung
Date: Wed Sep 23 11:28:14 2009
New Revision: 818062
URL: http://svn.apache.org/viewvc?rev=818062&view=rev
Log:
DeltaManager needs to replicate changed attributes even if session
gets invalidated. Otherwise session listeners will not see the right
data on the secondary nodes.
Port of r818061 from TC 5.5.x.
Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?rev=818062&r1=818061&r2=818062&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java Wed Sep
23 11:28:14 2009
@@ -1108,6 +1108,25 @@
* @return a SessionMessage to be sent,
*/
public ClusterMessage requestCompleted(String sessionId) {
+ return requestCompleted(sessionId, false);
+ }
+
+ /**
+ * When the request has been completed, the replication valve will notify
+ * the manager, and the manager will decide whether any replication is
+ * needed or not. If there is a need for replication, the manager will
+ * create a session message and that will be replicated. The cluster
+ * determines where it gets sent.
+ *
+ * Session expiration also calls this method, but with expires == true.
+ *
+ * @param sessionId -
+ *the sessionId that just completed.
+ * @param expires -
+ *whether this method has been called during session
expiration
+ * @return a SessionMessage to be sent,
+ */
+ public ClusterMessage requestCompleted(String sessionId, boolean expires)
{
DeltaSession session = null;
try {
session = (DeltaSession) findSession(sessionId);
@@ -1129,7 +1148,7 @@
}
}
if(!isDeltaRequest) {
-if(!session.isPrimarySession()) {
+if(!expires&& !session.isPrimarySession()) {
counterSend_EVT_SESSION_ACCESSED++;
msg = new SessionMessageImpl(getName(),
SessionMessage.EVT_SESSION_ACCESSED,
@@ -1145,9 +1164,10 @@
log.debug(sm.getString("deltaManager.createMessage.delta",getName(),
sessionId));
}
}
-session.setPrimarySession(true);
+if (!expires)
+session.setPrimarySession(true);
//check to see if we need to send out an access message
-if ((msg == null)) {
+if (!expires&& (msg == null)) {
long replDelta = System.currentTimeMillis() -
session.getLastTimeReplicated();
if (replDelta> (getMaxInactiveInterval() * 1000)) {
counterSend_EVT_SESSION_ACCESSED++;
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=818062&r1=818061&r2=818062&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Wed Sep
23 11:28:14 2009
@@ -38,7 +38,9 @@
import org.apache.catalina.Manager;
import org.apache.catalina.SessionListener;
import org.apache.catalina.ha.ClusterManager;
+import org.apache.catalina.ha.CatalinaCluster;
import org.apache.catalina.ha.ClusterSession;
+import org.apache.catalina.ha.ClusterMessage;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.session.StandardSession;
import org.apache.catalina.tribes.io.ReplicationStream;
@@ -373,7 +375,24 @@
}
public void expire(boolean notify, boolean notifyCluster) {
+if (expiring)
+return;
String expiredId = getIdInternal();
+
+if(expiredId != null&& manager != null&&
+ manager instanceof DeltaManager) {
+DeltaManager dmanager = (DeltaManage
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #16 from Rejeev Divakaran 2009-09-23 09:47:24 PDT --- I think we have mis-understood Session fixation. disabling URL re-write will not solve session fixation. Please refer to http://www.owasp.org/index.php/Session_Fixation and http://rejeev.blogspot.com/2009/09/session-fixation_08.html The correct solution for Session fixation is to create new Session cookie each time an authentication happens (discard old cookie and send new cookie to client after authentication). -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 Rejeev Divakaran changed: What|Removed |Added CC||rej...@gmail.com -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #17 from Mark Thomas 2009-09-23 18:20:36 BST --- Actually, preventing the use of the session ID in the URL goes a long way to preventing session fixation as it blocks the most easily exploited attack vectors. There would remain an issue with cookies but that should be limited to 3rd party cookies which may not be an issue for many situations. You are correct that changing the session ID on authentication will resolve all session fixation attacks. However, changing the session ID may also cause application breakage. It may also cause internal breakage for things like session replication. There would need to be some very careful testing. Whilst each of these techniques can be achieved by web applications (some more easily than others), there is clearly some scope for adding options to Tomcat so the container handles this transparently. -- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Port r818062 to BackupManager?
On 23.09.2009 16:17, Filip Hanik - Dev Lists wrote: > hi Rainer, > >> DeltaManager needs to replicate changed attributes even if session >> gets invalidated. Otherwise session listeners will not see the right >> data on the secondary nodes. > > This is an interesting use case indeed. The fact that we would replicate > changes on an invalidated session sounds awkward. > I will have to take a look when I have some more brain capacity Yeah the change happens immediately before invalidation, but a session listener needs the changed attribute. Sure it's a rare case, but it should work. session.expire() without requestCompleted() was a nice shortcut, but seems slightly incorrect. Concerning brains: http://www.flickr.com/photos/untergeek/8454334/ and while I was looking for it I also stumbled over a cartoon Gary Larson did about Apache: http://z.hubpages.com/u/209660_f520.jpg Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bypassing tomcat basic authentication
Is there a way to by pass tomcat authentication. We have an application that has BASIC authentication. But if the incoming URL has parameter say 'apikey' then we do not want tomcat to authenticate and instead perform our own authenticatin. Thanks. -- View this message in context: http://www.nabble.com/Bypassing-tomcat-basic-authentication-tp25531300p25531300.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PoweredBy" by jasonzou
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by jasonzou:
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=198&rev2=199
{{http://nexcess.net/banners/nexcess_468x60_1.gif}}
[[http://www.nexcess.net|NEXCESS.NET]] is now supporting JSP/Servlets using
Tomcat.
+ = OfferMe.com.au =
+ {{http://www.offerme.com.au/images/layout/logo_home.gif}}
+ [[http://www.offerme.com.au|www.offerme.com.au]] - OfferMe.com.au is an all
new B2C trading platform in Australia using the Web2.0 concept.
+
= OrangePics =
[[http://www.orangepics.com|www.orangepics.com]] - Simple, Safe Photo Sharing
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bypassing tomcat basic authentication
cuccigucci wrote: > Is there a way to by pass tomcat authentication. > We have an application that has BASIC authentication. > But if the incoming URL has parameter say 'apikey' then we do not want > tomcat to authenticate and instead perform our own authenticatin. That would be a question for the users list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
