Re: svn commit: r1513919 - in /tomcat/trunk: java/org/apache/catalina/connector/CoyoteAdapter.java test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
HI Mark,
nice fix :-) Thanks!
Why the testcase at NBReadServlet must called the listener.onDataAvailable();?
I read the 3.1 spec and think the container must call onDataAvailable and
we do that at CoyoteAdapter.
§3.7 P 3.28
■ onDataAvailable(). The onDataAvailable method is invoked on the
ReadListener when data is available to read from the incoming request
stream. The container will invoke the method the first time when data is
available to read. The container will subsequently invoke the onDataAvailable
method if and only if isReady method on ServletInputStream, described
below, returns false.
But this simple POST example at
https://weblogs.java.net/blog/swchan2/archive/2013/04/16/non-blocking-io-servlet-31-example
don't work.
Another question is: At which time the container must call the
WriteListener.onWritePossible()?
After ReadListener.onDataAvailable is finished?
Currently we call onWritePossible before onDataAvailable is WriteListener set.
The example set
WriteListener at the ReadListener has read all data! But the problem seems that
no date available after POST request is dispatch.
After ReadListener set the method call result from ServletInputStream.isReady()
is true! Seems socket has read data.
Regards
Peter
Am 14.08.2013 um 17:02 schrieb ma...@apache.org:
Author: markt
Date: Wed Aug 14 15:02:59 2013
New Revision: 1513919
URL: http://svn.apache.org/r1513919
Log:
Fix non-blocking test failures on OSX.
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=1513919r1=1513918r2=1513919view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Wed
Aug 14 15:02:59 2013
@@ -363,6 +363,10 @@ public class CoyoteAdapter implements Ad
try {
Thread.currentThread().setContextClassLoader(newCL);
res.onWritePossible();
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+res.getWriteListener().onError(t);
+return false;
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
@@ -379,6 +383,10 @@ public class CoyoteAdapter implements Ad
if (request.isFinished()) {
req.getReadListener().onAllDataRead();
}
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+req.getReadListener().onError(t);
+return false;
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
Modified:
tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java?rev=1513919r1=1513918r2=1513919view=diff
==
--- tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
Wed Aug 14 15:02:59 2013
@@ -482,25 +482,20 @@ public class TestNonBlockingAPI extends
}
@Override
-public void onDataAvailable() {
-try {
-ServletInputStream in = ctx.getRequest().getInputStream();
-String s = ;
-byte[] b = new byte[8192];
-int read = 0;
-do {
-read = in.read(b);
-if (read == -1) {
-break;
-}
-s += new String(b, 0, read);
-} while (in.isReady());
-log.info(s);
-body.append(s);
-} catch (Exception x) {
-x.printStackTrace();
-ctx.complete();
-}
+public void onDataAvailable() throws IOException {
+ServletInputStream in = ctx.getRequest().getInputStream();
+String s = ;
+byte[] b = new byte[8192];
+int read = 0;
+do {
+read = in.read(b);
+if (read == -1) {
+break;
+}
+s += new String(b, 0, read);
+} while (in.isReady());
+
Re: svn commit: r1514228 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/coyote/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ test/org/apache/catalina/nonblo
Hi Mark, I test the current fix with my simple example at OSX (NIO) and now it works. Many thanks, Peter Am 15.08.2013 um 12:40 schrieb Mark Thomas ma...@apache.org: On 15/08/2013 11:32, ma...@apache.org wrote: Author: markt Date: Thu Aug 15 10:32:15 2013 New Revision: 1514228 URL: http://svn.apache.org/r1514228 Log: The container is responsible for the first call to each of onWritePossible() and onDataAvailable() once a listener has been set. Main component is the addition to the SocketWrapper of a list of dispatch types that need to be made. Dispatch type in this case meaning process the socket using the specified SocketStatus. This is used to register trigger the first call to each of onWritePossible() and onDataAvailable() for which the container is responsible. Fix some additional issues identified in the test case. This passes on Windows and Linux on BIO, NIO and APR and OSX on BIO and NIO but not OSX with the APR connector. BZ55381 isn't quite fixed yet. 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: [VOTE] Release Apache Tomcat 7.0.8
+1 Peter Am 04.02.2011 um 14:52 schrieb Mark Thomas: The proposed Apache Tomcat 7.0.8 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.8/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_8/ The proposed 7.0.8 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.8 Alpha [ ] Beta - go ahead and release as 7.0.8 Beta [x ] Stable - go ahead and release as 7.0.8 Stable Cheers, 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: [VOTE] Release build 6.0.32
+1 Peter Am 02.02.2011 um 20:37 schrieb jean-frederic clere: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.32/ According to the release process, the 6.0.32 build corresponding to the tag TOMCAT_6_0_32 is: [ ] Broken [ ] Alpha [ ] Beta [ x] Stable Cheers Jean-Frederic - 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: Tagging 7.0.7
+1 Peter Am 02.02.2011 um 16:26 schrieb Mark Thomas: All, I'd like to stick to my plan to release Tomcat 7 every month or so. The last release was ~ 3 weeks ago so that suggests next week. However, I have some commitments next week that would make tagging and rolling a release difficult so I intend to tag later today. There are plenty of fixes in the changelog, particularly for Comet, that I think makes this worthwhile. 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: [VOTE] Release Apache Tomcat 7.0.7
+1 Peter Am 03.02.2011 um 14:32 schrieb Mark Thomas: The proposed Apache Tomcat 7.0.7 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.7/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_7/ The proposed 7.0.7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.7 Alpha [ ] Beta - go ahead and release as 7.0.7 Beta [ x] Stable - go ahead and release as 7.0.7 Stable Cheers, 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: configtest
+1 for the feature
Peter
Am 04.11.2010 um 14:12 schrieb Tim Funk:
svn diff -x -w version uploaded. I always wondered how to ignore whitespace
in svn ignore. (It bugged me, but never enough to rtfm) Thanks for the tip!
-Tim
On 11/3/2010 6:46 PM, Konstantin Kolinko wrote:
Too many unneeded whitespace changes. It is hard to read. Try
svn diff -x -w
In essence, it is
+} else if (command.equals(configtest)) {
+daemon.load(args);
+if (null==daemon.getServer()) {
+System.exit(1);
+}
+System.exit(0);
where load(args) processes command line arguments, parses server.xml
and also calls getServer().init();
-
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: dead code in ClusterRuleSetFactory
Hi David,
it ist not a dead code. Locking art sandbox OACC project we have made
the tomcat 5.5 cluster
also available for tomcat 6.
http://svn.apache.org/repos/asf/tomcat/sandbox/tomcat-oacc/trunk/
The OACC module is very helpfull to migrations.
Peter
Am 23.03.2009 um 21:59 schrieb David Knox:
Hi,
I have a customer who was confused by a couple of debug log
messages coming from o.a.c.startup.ClusterRuleSetFactory. I found
the code refers to a package present in Tomcat 5 but does not exist
in Tomcat 6 - org.apache.catalina.cluster; which appears to be dead
code.
(http://svn.apache.org/repos/asf/tomcat/archive/tc5.0.x/trunk/
container/modules/cluster/)
Nevertheless,
In the interest of helping clean the code up a bit, I offer the
patch below. The only reason to keep it that I could imagine was
someone hijacking the package name (o.a.c.cluster) and their own
clustering implementation; which seems impractical and ambitious.
cheers,
-- dave
Index: ClusterRuleSetFactory.java
===
--- ClusterRuleSetFactory.java (revision 757534)
+++ ClusterRuleSetFactory.java (working copy)
@@ -33,22 +33,6 @@
public static RuleSetBase getClusterRuleSet(String prefix) {
-//OLD CLUSTER 1
-//first try the same classloader as this class server/lib
-try {
-return loadRuleSet
(prefix,org.apache.catalina.cluster.ClusterRuleSet,ClusterRuleSetFac
tory.class.getClassLoader());
-} catch ( Exception x ) {
-//display warning
-if ( log.isDebugEnabled() ) log.debug(Unable to load
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet),
falling back on context classloader);
-}
-//try to load it from the context class loader
-try {
-return loadRuleSet
(prefix,org.apache.catalina.cluster.ClusterRuleSet,Thread.currentThr
ead().getContextClassLoader());
-} catch ( Exception x ) {
-//display warning
-if ( log.isDebugEnabled() ) log.debug(Unable to load
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), will
try to load the HA cluster);
-}
-
//NEW CLUSTER 2
//first try the same classloader as this class server/lib
try {
David Knox
Information System Architect
+1 303-748-8906
http://pragmaticis.blogspot.com
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.28
Good job :-) Apache Tomcat Connectors 1.2.28 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Peter - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: mod_jk: getRemotePort returns -1 (issue 41263)
HI Michael, we have add some Imdicators at the coming mod_jk 1.2.28 release. === JkLocalNameIndicator Name of the Apache environment variable which can be used to overwrite the forwarded local name. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_LOCAL_NAME. This directive has been added in version 1.2.28 of mod_jk. JkLocalPortIndicator Name of the Apache environment variable which can be used to overwrite the forwarded local port. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_LOCAL_PORT. This directive has been added in version 1.2.28 of mod_jk. JkRemoteHostIndicator Name of the Apache environment variable which can be used to overwrite the forwarded remote (client) host name. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_REMOTE_HOST. This directive has been added in version 1.2.28 of mod_jk. JkRemoteAddrIndicator Name of the Apache environment variable which can be used to overwrite the forwarded remote (client) IP address. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_REMOTE_ADDR. This directive has been added in version 1.2.28 of mod_jk. JkRemoteUserIndicator Name of the Apache environment variable which can be used to overwrite the forwarded user name. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_REMOTE_USER. This directive has been added in version 1.2.28 of mod_jk. JkAuthTypeIndicator Name of the Apache environment variable which can be used to overwrite the forwarded authentication type. Use this only if you need to adjust the data (see the proxy documentation). The default value is JK_AUTH_TYPE. This directive has been added in version 1.2.28 of mod_jk. === Next step is to add a valve to tomcat base to set the indicator values to request object :-) Regards Peter Am 21.03.2009 um 00:10 schrieb Michael B Allen: Hi All, What is the status of this issue? https://issues.apache.org/bugzilla/show_bug.cgi?id=41263 I am interested in this because NTLMSSP authentication is basically not possible unless the remote port is accessible and I want people to be able to use my product through Apache if possible. The reason it is not possible is because the NTLMSSP protocol is a three message handshake so it requires storing state with the connection at least temporarily. If you store the state in the session using the same key, that state may be incorrectly read or overwritten if multiple requests from different connections with the same session ID are processed concurrently. The only solution that I am aware of is to store the state in the session but use a key that includes the remote port. Without the remote port is is basically impossible to correctly implement NTLMSSP authentication through mod_jk. Can anyone indicate as to how this issue might be resolved either by implementing getRemotePort via mod_jk or by using another method of discerning connections from one another? I write C just as well as I do Java so I'm willing to create a patch if someone can provide a pointer and any implementation hints they might have or snags they might know of. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ - 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: svn repo layout for modules
What we and user need, is a real plugin and tool contribution area. +1 to start the modules plugin system to create more value of the tomcat project regards, Peter Am 07.02.2009 um 01:18 schrieb Costin Manolache: On Fri, Feb 6, 2009 at 3:07 PM, Remy Maucherat r...@apache.org wrote: On Fri, 2009-02-06 at 14:59 -0700, Filip Hanik - Dev Lists wrote: that discussion does exist if you look back into the archives what has changed since then? The proposed module layout looks so-so to me, and apparently others feel the same, so a solution is to remove the modules. Can we just leave the modules as they are - it really doesn't matter that much. Tagging is possible ( just tag the whole tree ), release is possible. The question of scope remains - but I see no problem with having a tomcat-specific jdbc pool or other components ( like we have juli and many other things that could fit commons better ), it it is maintained ( which makes it quite simple - if code is maintained mostly by tomcat, why not leave it in tomcat ? ) I'm going to push the lite 'module' as well - modules dir seems a good middle ground. Costin
Re: systemprop.xml and spaces
Hi Mark, OK, but you can't copy-paste those items! Well and I am big fan of big monitor's :-) Thanks to explain that Peter Am 30.12.2008 um 11:13 schrieb Mark Thomas: Peter Rossbach wrote: Hi Mark, Why some attributes at systemprop.xml has spaces? property name=org.apache.jasper.compiler. Generator.VAR_EXPRESSIONFACTORY So they display on multiple lines rather than a single line. On a single line they are far too long and push the description off the right-hand side of the screen unless you have a very big monitor. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Arrays.copyOf support?
Thanks to new interceptor and fix :-) Works for me. Peter Am 30.12.2008 um 11:11 schrieb Mark Thomas: Filip Hanik - Dev Lists wrote: I will fix, Filip Peter - thanks for catching this. Filip - thanks for fixing it. 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
Arrays.copyOf support?
Hi Filip or Mark, the Arrays.copyOf method are only support at java 6. Please change the following implementation at tomcat 6 trunk: compile: [javac] Compiling 182 source files to xxx/tomcat6currenttrunk/ output/classes [javac] xxx/tomcat6currenttrunk/java/org/apache/catalina/tribes/ group/interceptors/SimpleCoordinator.java:89: cannot find symbol [javac] symbol : method copyOf(org.apache.catalina.tribes.Member [],int) [javac] location: class java.util.Arrays [javac] final Member[] view = Arrays.copyOf(members, members.length + 1); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 error Regards Peter
systemprop.xml and spaces
Hi Mark, Why some attributes at systemprop.xml has spaces? property name=org.apache.jasper.compiler. Generator.VAR_EXPRESSIONFACTORY Regards Peter
Re: DeltaManager initialization delay
Hi Jason,
patch looks good to me. Open a Bug report and we can test the patch
at trunk.
Many thanks
Peter
Am 25.11.2008 um 00:14 schrieb Jason:
Adds a threadsafe latch to the DeltaManager which is used to block
processing of cluster messages until local applications have
completed initialization.
Includes changes to the DeltaManager to create the latch based on
configuration, changes to Catalina to automatically open the latch
when initialization is complete, a constant used to as the
attribute key in the ServletContext and an modification to the
mbean-descriptor for the new DeltaManager attribute.
Also includes a handful of style cleanups interspersed (spelling,
removing compiler warnings about type checking, removing spaces
before semi colons and blank lines before and after braces)
throughout.
- Jason
That's the problem. He's a brilliant lunatic and you can't tell
which way he'll jump --
like his game he's impossible to analyse --
you can't dissect him, predict him --
which of course means he's not a lunatic at all.
Index: catalina/Globals.java
===
--- catalina/Globals.java(revision 719433)
+++ catalina/Globals.java(working copy)
@@ -36,6 +36,14 @@
org.apache.catalina.deploy.alt_dd;
/**
+ * The servlet context attribute under which we store the
concurrent latch
+ * used to block processing cluster messages until after local
application
+ * initialization
+ */
+public static final String CLUSTER_DELAY =
+org.apache.catalina.ha.delay;
+
+/**
* The request attribute under which we store the array of
X509Certificate
* objects representing the certificate chain presented by our
client,
* if any.
Index: catalina/ha/session/DeltaManager.java
===
--- catalina/ha/session/DeltaManager.java(revision 719433)
+++ catalina/ha/session/DeltaManager.java(working copy)
@@ -26,11 +26,15 @@
import java.util.ArrayList;
import java.util.Date;
import java.util.Iterator;
+import java.util.concurrent.CountDownLatch;
+
+import javax.servlet.ServletContext;
import org.apache.catalina.Cluster;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.Engine;
+import org.apache.catalina.Globals;
import org.apache.catalina.Host;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
@@ -38,13 +42,13 @@
import org.apache.catalina.Valve;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.ha.CatalinaCluster;
+import org.apache.catalina.ha.ClusterManager;
import org.apache.catalina.ha.ClusterMessage;
import org.apache.catalina.ha.tcp.ReplicationValve;
import org.apache.catalina.tribes.Member;
import org.apache.catalina.tribes.io.ReplicationStream;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
-import org.apache.catalina.ha.ClusterManager;
/**
* The DeltaManager manages replicated sessions by only
replicating the deltas
@@ -62,10 +66,11 @@
* @author Craig R. McClanahan
* @author Jean-Francois Arcand
* @author Peter Rossbach
+ * @author Jason Lunn
* @version $Revision$ $Date$
*/
-public class DeltaManager extends ClusterManagerBase{
+public class DeltaManager extends ClusterManagerBase {
//
Security Classes
public static org.apache.juli.logging.Log log =
org.apache.juli.logging.LogFactory.getLog(DeltaManager.class);
@@ -106,6 +111,18 @@
protected LifecycleSupport lifecycle = new LifecycleSupport
(this);
/**
+ * Flag indicating that messageReceived(ClusterMessage) should
block until
+ * all local applications have completed initialization
+ */
+protected boolean delay = false;
+
+/**
+ * Barrier used to receive notification from other threads
that it is okay
+ * to process incoming messages from the cluster
+ */
+private CountDownLatch gate = null;
+
+/**
* The maximum number of active Sessions allowed, or -1 for no
limit.
*/
private int maxActiveSessions = -1;
@@ -121,8 +138,8 @@
/**
* wait time between send session block (default 2 sec)
*/
-private int sendAllSessionsWaitTime = 2 * 1000 ;
-private ArrayList receivedMessageQueue = new ArrayList() ;
+private int sendAllSessionsWaitTime = 2 * 1000;
+private ArrayListSessionMessage receivedMessageQueue = new
ArrayListSessionMessage() ;
private boolean receiverQueue = false ;
private boolean stateTimestampDrop = true ;
private long stateTransferCreateSendTime;
@@ -175,6 +192,27 @@
public String getName() {
return name;
}
+
+/**
+ * Set the member that indicates processing messages should
wait for local
Re: svn commit: r719626 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Hi, a common connector code base is possible. A lot of duplication exists at current tomcat 6.x handlers implementations. We must also look at AjpProtocol and AjpAprProtocol classes. Why we don't use the internal executor at all handlers? Why internal executor as no JMX MBean representation? Why processor caches are can't shrinking ? The Connector/Handler/xx dynamic property binding is strange. Why ProtocolHandler, Executor and Endpoint are not subelements from connector tag at server.xml? I think the usage of a common base are a design shift and a good feature to start at tomcat 7:-). Regards Peter Am 23.11.2008 um 10:19 schrieb Mark Thomas: Filip Hanik - Dev Lists wrote: No, you're not missing anything. NIO can use a shared executor, and internal executor or the thread pool based on synchronized/wait/notify For the sake of consistency in configuration, is there any merit in deprecating the use of the internal executor or alternatively, adding an internal executor option to the other connectors? On a related topic reducing the duplication of code between the connectors is on my wish list for my current code clean up but I haven't looked at it yet. My initial thoughts are around the use of some common base classes. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r719626 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Happy Weekend, I like your current clean ups :-) many thanks Peter Am 22.11.2008 um 11:24 schrieb Mark Thomas: Peter Rossbach wrote: Hi Mark! The NioEndpoint can have its own executor without sharing and JMX stuff :-) See at start methods: Got it. Cheers. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DeltaManager initialization delay
Hi Jason, send us your implementation and let us review your stuff :-) You can also register a ContextListener at DeltaManager.setContainer () to control your latch. Are your sure that session sync message (GET ALL Session) is received before first request at second node is processed? I think your feature is an extension of the current reveivedQueue usage! Regards Peter Am 20.11.2008 um 22:54 schrieb Jason: This message is targeted at Filip Hanik, Craig R. McClanahan, Jean- Francois Arcand, Peter Rossbach or anyone with a direct interest in the DeltaManager implementation in Tomcat 6. A vendor (who will remain nameless) whose product I support for a client recently gave me an idea for a patch to DeltaManager to address what the vendor claims is a Tomcat specific issue related to session replication. I'm wondering if it would be of value to the community or if the problem it is trying to remedy is an intentional feature. The primary issue is that, according to vendor engineering support, the other application containers the vendor supports deploying their product on, including WebSphere, WebLogic, et al, wait until after local applications have been initialized before processing incoming messages from the cluster that could include deserializing remote sessions and the objects therein. I have not confirmed this by examining the other containers mind you, but am pretty confident that this is an accurate statement in so far that vendor's product works in those environments but does not work in a clustered tomcat environment. The reason it fails in tomcat is that some of the objects in the serialized session make calls at construction time to the vendor's (archaic) preferences API's static methods, which are not initialized properly until the web application itself is started. The result is that the first node in the cluster starts up fine, but the 2nd-Nth nodes die a horrible death trying to deserialize remote sessions populated by the first node. The workaround we've implemented locally is a simple one: we extend the DeltaManager with a custom class. Therein, we create a latch (java.util.concurrent.CountDownLatch, to be specific) and save it in the ServletContext. The only overridden method is messageDataReceived (), which uses the latch.await() method to block before calling the original implementation of the parent messageDataReceived() method. The vendor's application (or, more properly, the custom extensions we've built on their platform) looks at the ServletContext for a latch after the preferences have been initialized locally, and calls latch.countDown (), allowing any blocked calls to messageDataReceived() to start executing as normally. Without breaking the current sequence of initializing the session replication code before local applications that Tomcat developers may have come to expect, it seems like there is a potential solution here that might enable applications like the one I've got to support to choose to configure the session replication to wait to process incoming messages until after the application has started. I think it would be pretty trivial for me to offer a patch to DeltaManager that created a latch based on a configuration element. One could imagine an automatic mechanism for toggling the latch by the container after the application initialization, or deferring to the application to deactivate. The question is, does anybody want such functionality besides me? The corollary is, if being able to choose when session replication begins is a desirable feature, is this the right tactic to implement it? Sincerely, - Jason Lunn That's the problem. He's a brilliant lunatic and you can't tell which way he'll jump -- like his game he's impossible to analyse -- you can't dissect him, predict him -- which of course means he's not a lunatic at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r719626 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Hi Mark!
The NioEndpoint can have its own executor without sharing and JMX
stuff :-)
See at start methods:
L 805:
if (getUseExecutor()) {
if ( executor == null ) {
TaskQueue taskqueue = new TaskQueue();
TaskThreadFactory tf = new TaskThreadFactory
(getName() + -exec-);
executor = new ThreadPoolExecutor
(getMinSpareThreads(), getMaxThreads(), 60,
TimeUnit.SECONDS,taskqueue, tf);
taskqueue.setParent( (ThreadPoolExecutor)
executor, this);
}
regards
Peter
Am 21.11.2008 um 23:52 schrieb Mark Thomas:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Fri Nov 21 08:31:45 2008
New Revision: 719626
URL: http://svn.apache.org/viewvc?rev=719626view=rev
Log:
Fix dynamic thread resizing
I had assumed that if an executor was used, then the executor mbean
would
be used to resize the pool. Also, this is now inconsistent with the
configuration in that setting maxThreads for the connector in
server.xml at
startup will not have an affect but setting it via JMX at runtime
will.
This is also now inconsistent with the BIO and APT endpoints.
Am I missing something?
Mark
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/NioEndpoint.java?
rev=719626r1=719625r2=719626view=diff
=
=
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Fri Nov 21 08:31:45 2008
@@ -354,8 +354,14 @@
public void setMaxThreads(int maxThreads) {
this.maxThreads = maxThreads;
if (running) {
-synchronized(workers) {
-workers.resize(maxThreads);
+if (getUseExecutor() executor!=null) {
+if (executor instanceof ThreadPoolExecutor) {
+((ThreadPoolExecutor)
executor).setMaximumPoolSize(maxThreads);
+}
+}else if (workers!=null){
+synchronized(workers) {
+workers.resize(maxThreads);
+}
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Releasing Apache Tomcat Native 1.1.16
Hi Mladen, last weeks are conference time... Sorry are also test tcnative today. regards Peter Am 13.11.2008 um 20:47 schrieb Rainer Jung: Mladen Turk schrieb: Mladen Turk wrote: Hello to the Tomcat team, Native 1.1.16 has been available for testing for almost a week, so I would like to proceed with the release vote. So far only one binding vote has been recorded (Thanks Henri), and mine by presumption. So, Native 1.1.16 won't be released due to lack of developers interest :( If you are able to accept a late vote, I'll test later today ... Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r712278 - in /tomcat/trunk/java/org/apache/tomcat/util/net: NioEndpoint.java SocketProperties.java
Many thanks,
I will check at evening.
Peter
Am 11.11.2008 um 23:59 schrieb Filip Hanik - Dev Lists:
done
Filip
Peter Rossbach wrote:
Yes, please
Peter
Am 11.11.2008 um 20:18 schrieb Filip Hanik - Dev Lists:
hi Peter, the one line patch is in my email,
that is the patch that you should apply, instead of your patch
socketProperties.setProperties(serverSock.socket());
would you like me to do it?
Filip
Peter Rossbach wrote:
Hi Filip,
I don't see the one line patch. I also the problem, but I got a
lot of NPE without the patch.
need help,
Peter
Am 11.11.2008 um 18:06 schrieb Filip Hanik - Dev Lists:
-1
this was intentional, and yes, it accidentally broke the NIO
connector
the proper way to do this is to call
socketProperties.setProperties(serverSock.socket());
this way, your patch is only one line, and also doesn't add in
a bunch of -1 illegal values
Filip
[EMAIL PROTECTED] wrote:
Author: pero
Date: Fri Nov 7 13:40:37 2008
New Revision: 712278
URL: http://svn.apache.org/viewvc?rev=712278view=rev
Log:
Fix NPE to use Http11NioProtocol handler with default parameters!
# example:
Executor name=tomcatThreadPool namePrefix=catalina-
exec- maxThreads=150 minSpareThreads=4/
Connector executor=tomcatThreadPool
port=8080
protocol=org.apache.coyote.http11.Http11NioProtocol
connectionTimeout=2
redirectPort=8443 /
Used at MAC OS X with -Djava.net.preferIPv4Stack=true
I am not sure that default returns are correct!
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/NioEndpoint.java?
rev=712278r1=712277r2=712278view=diff
=
=
--- tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java Fri Nov 7 13:40:37 2008
@@ -735,7 +735,12 @@
return;
serverSock = ServerSocketChannel.open();
-serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
+int performanceConnectionTime =
socketProperties.getPerformanceConnectionTime();
+int performanceLatency=
socketProperties.getPerformanceLatency();
+int performanceBandwidth =
socketProperties.getPerformanceBandwidth();
+if (performanceConnectionTime != -1
performanceLatency != -1
+performanceBandwidth != -1)
+serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
socketProperties.getPerformanceLatency(),
socketProperties.getPerformanceBandwidth());
InetSocketAddress addr = (address!=null?new
InetSocketAddress(address,port):new InetSocketAddress(port));
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/SocketProperties.java?
rev=712278r1=712277r2=712278view=diff
=
=
--- tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java Fri Nov 7 13:40:37 2008
@@ -210,55 +210,82 @@
}
public boolean getOoBInline() {
-return ooBInline.booleanValue();
+if(ooBInline != null)
+return ooBInline.booleanValue();
+return false;
}
public int getPerformanceBandwidth() {
-return performanceBandwidth.intValue();
+if(performanceBandwidth != null)
+return performanceBandwidth.intValue();
+return -1;
}
public int getPerformanceConnectionTime() {
-return performanceConnectionTime.intValue();
+if(performanceConnectionTime!= null)
+return performanceConnectionTime.intValue();
+return -1;
+ }
public int getPerformanceLatency() {
-return performanceLatency.intValue();
+if(performanceLatency != null)
+return performanceLatency.intValue();
+return -1 ;
}
public int getRxBufSize() {
-return rxBufSize.intValue();
+if(rxBufSize != null)
+return rxBufSize.intValue();
+return -1;
}
public boolean getSoKeepAlive() {
-return soKeepAlive.booleanValue();
+if(soKeepAlive != null)
+return soKeepAlive.booleanValue();
+return false;
}
public boolean getSoLingerOn() {
-return soLingerOn.booleanValue();
+if(soLingerOn
Re: svn commit: r712278 - in /tomcat/trunk/java/org/apache/tomcat/util/net: NioEndpoint.java SocketProperties.java
Hi Filip,
I don't see the one line patch. I also the problem, but I got a lot
of NPE without the patch.
need help,
Peter
Am 11.11.2008 um 18:06 schrieb Filip Hanik - Dev Lists:
-1
this was intentional, and yes, it accidentally broke the NIO connector
the proper way to do this is to call
socketProperties.setProperties(serverSock.socket());
this way, your patch is only one line, and also doesn't add in a
bunch of -1 illegal values
Filip
[EMAIL PROTECTED] wrote:
Author: pero
Date: Fri Nov 7 13:40:37 2008
New Revision: 712278
URL: http://svn.apache.org/viewvc?rev=712278view=rev
Log:
Fix NPE to use Http11NioProtocol handler with default parameters!
# example:
Executor name=tomcatThreadPool namePrefix=catalina-
exec- maxThreads=150 minSpareThreads=4/
Connector executor=tomcatThreadPool
port=8080
protocol=org.apache.coyote.http11.Http11NioProtocol
connectionTimeout=2redirectPort=8443 /
Used at MAC OS X with -Djava.net.preferIPv4Stack=true
I am not sure that default returns are correct!
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/NioEndpoint.java?
rev=712278r1=712277r2=712278view=diff
=
=
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Fri Nov 7 13:40:37 2008
@@ -735,7 +735,12 @@
return;
serverSock = ServerSocketChannel.open();
-serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
+int performanceConnectionTime =
socketProperties.getPerformanceConnectionTime();
+int performanceLatency=
socketProperties.getPerformanceLatency();
+int performanceBandwidth =
socketProperties.getPerformanceBandwidth();
+if (performanceConnectionTime != -1
performanceLatency != -1
+performanceBandwidth != -1)
+serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
socketProperties.getPerformanceLatency(),
socketProperties.getPerformanceBandwidth());
InetSocketAddress addr = (address!=null?new
InetSocketAddress(address,port):new InetSocketAddress(port));
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/SocketProperties.java?
rev=712278r1=712277r2=712278view=diff
=
=
--- tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java Fri Nov 7 13:40:37 2008
@@ -210,55 +210,82 @@
}
public boolean getOoBInline() {
-return ooBInline.booleanValue();
+if(ooBInline != null)
+return ooBInline.booleanValue();
+return false;
}
public int getPerformanceBandwidth() {
-return performanceBandwidth.intValue();
+if(performanceBandwidth != null)
+return performanceBandwidth.intValue();
+return -1;
}
public int getPerformanceConnectionTime() {
-return performanceConnectionTime.intValue();
+if(performanceConnectionTime!= null)
+return performanceConnectionTime.intValue();
+return -1;
+ }
public int getPerformanceLatency() {
-return performanceLatency.intValue();
+if(performanceLatency != null)
+return performanceLatency.intValue();
+return -1 ;
}
public int getRxBufSize() {
-return rxBufSize.intValue();
+if(rxBufSize != null)
+return rxBufSize.intValue();
+return -1;
}
public boolean getSoKeepAlive() {
-return soKeepAlive.booleanValue();
+if(soKeepAlive != null)
+return soKeepAlive.booleanValue();
+return false;
}
public boolean getSoLingerOn() {
-return soLingerOn.booleanValue();
+if(soLingerOn != null)
+return soLingerOn.booleanValue();
+return false;
}
public int getSoLingerTime() {
-return soLingerTime.intValue();
+if(soLingerTime != null)
+return soLingerTime.intValue();
+return -1;
}
public boolean getSoReuseAddress() {
-return soReuseAddress.booleanValue();
+if(soReuseAddress != null)
+return soReuseAddress.booleanValue();
+
Re: svn commit: r712278 - in /tomcat/trunk/java/org/apache/tomcat/util/net: NioEndpoint.java SocketProperties.java
Yes, please
Peter
Am 11.11.2008 um 20:18 schrieb Filip Hanik - Dev Lists:
hi Peter, the one line patch is in my email,
that is the patch that you should apply, instead of your patch
socketProperties.setProperties(serverSock.socket());
would you like me to do it?
Filip
Peter Rossbach wrote:
Hi Filip,
I don't see the one line patch. I also the problem, but I got a
lot of NPE without the patch.
need help,
Peter
Am 11.11.2008 um 18:06 schrieb Filip Hanik - Dev Lists:
-1
this was intentional, and yes, it accidentally broke the NIO
connector
the proper way to do this is to call
socketProperties.setProperties(serverSock.socket());
this way, your patch is only one line, and also doesn't add in a
bunch of -1 illegal values
Filip
[EMAIL PROTECTED] wrote:
Author: pero
Date: Fri Nov 7 13:40:37 2008
New Revision: 712278
URL: http://svn.apache.org/viewvc?rev=712278view=rev
Log:
Fix NPE to use Http11NioProtocol handler with default parameters!
# example:
Executor name=tomcatThreadPool namePrefix=catalina-
exec- maxThreads=150 minSpareThreads=4/
Connector executor=tomcatThreadPool
port=8080
protocol=org.apache.coyote.http11.Http11NioProtocol
connectionTimeout=2redirectPort=8443 /
Used at MAC OS X with -Djava.net.preferIPv4Stack=true
I am not sure that default returns are correct!
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/NioEndpoint.java?
rev=712278r1=712277r2=712278view=diff
===
===
--- tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java Fri Nov 7 13:40:37 2008
@@ -735,7 +735,12 @@
return;
serverSock = ServerSocketChannel.open();
-serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
+int performanceConnectionTime =
socketProperties.getPerformanceConnectionTime();
+int performanceLatency=
socketProperties.getPerformanceLatency();
+int performanceBandwidth =
socketProperties.getPerformanceBandwidth();
+if (performanceConnectionTime != -1
performanceLatency != -1
+performanceBandwidth != -1)
+serverSock.socket().setPerformancePreferences
(socketProperties.getPerformanceConnectionTime(),
socketProperties.getPerformanceLatency(),
socketProperties.getPerformanceBandwidth());
InetSocketAddress addr = (address!=null?new
InetSocketAddress(address,port):new InetSocketAddress(port));
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/SocketProperties.java?
rev=712278r1=712277r2=712278view=diff
===
===
--- tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/
SocketProperties.java Fri Nov 7 13:40:37 2008
@@ -210,55 +210,82 @@
}
public boolean getOoBInline() {
-return ooBInline.booleanValue();
+if(ooBInline != null)
+return ooBInline.booleanValue();
+return false;
}
public int getPerformanceBandwidth() {
-return performanceBandwidth.intValue();
+if(performanceBandwidth != null)
+return performanceBandwidth.intValue();
+return -1;
}
public int getPerformanceConnectionTime() {
-return performanceConnectionTime.intValue();
+if(performanceConnectionTime!= null)
+return performanceConnectionTime.intValue();
+return -1;
+ }
public int getPerformanceLatency() {
-return performanceLatency.intValue();
+if(performanceLatency != null)
+return performanceLatency.intValue();
+return -1 ;
}
public int getRxBufSize() {
-return rxBufSize.intValue();
+if(rxBufSize != null)
+return rxBufSize.intValue();
+return -1;
}
public boolean getSoKeepAlive() {
-return soKeepAlive.booleanValue();
+if(soKeepAlive != null)
+return soKeepAlive.booleanValue();
+return false;
}
public boolean getSoLingerOn() {
-return soLingerOn.booleanValue();
+if(soLingerOn != null)
+return soLingerOn.booleanValue();
+return false;
}
public int getSoLingerTime() {
-return
Re: [VOTE] bayeux module
[ x] +1 yes move it to the modules directory Regards Peter PS: I am currently test the bayeux stuff. Currently StockTicker example don't work at Safari... Am 02.11.2008 um 14:22 schrieb Filip Hanik - Dev Lists: now that we do have a module directory, I'd like to propose to take the bayeux impl out of tomcat core, and put it into an individual module reasons 1. It's built on top of Tomcat, but its not core tomcat 2. We can release it more frequently to fix bugs 3. If there is a bug in Bayeux, we don't need a new tomcat release Please select one: [ ] +1 yes move it to the modules directory [ ] 0 I fine either way [ ] -1 Let's discuss before we make a move Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r705299 - /tomcat/connectors/trunk/jk/xdocs/reference/uriworkermap.xml
Hi Rainer, The comment from fail_on_status example is wrong (Copy/paste?). What is the meaning of -500? Am 16.10.2008 um 20:02 schrieb [EMAIL PROTECTED]: +The extension codefail_on_status/code can be used in any rule: +source + # Stop forwarding only for member1 of loadbalancer + /myapp=myworker;fail_on_status=-404,-500,503 +/source Peter
Re: Possibility of Making JSESSIONID Configurable
HI I see some impacts at cluster and SSO code with a per context configuration. But a option at global or engine level is easy to implement. Regards Peter Am 24.09.2008 um 17:36 schrieb Remy Maucherat: On Wed, 2008-09-24 at 16:23 +0100, Mark Thomas wrote: The draft is here: http://jcp.org/en/jsr/detail?id=315 I though you were on the Servlet EG or am I mistaken? I was not aware of that file for whatever reason. I now remember the language that was discussed, and I remember being in favor of it. It now tolerates proprietary configuration of the cookie name, but does not actually mandate or change anything. I think per context would be a big problem for proxies, so I am against it. There's no need for a patch to state that, I think. Certainly, if they were looking at the cookie to manage load- balancing or similar then different values per context would make that configuration more complex than it needs to be. I am -1 for per context configuration, +1 for global configuration (and I know JF has a custom patch to do that, which I think also does the URL parameter). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possibility of Making JSESSIONID Configurable
Works for me! +1 (Comment: Remove the JIoEndpoint log fix from JSESSIONID patch :-)) Thanks peter Am 25.09.2008 um 11:00 schrieb jean-frederic clere: Remy Maucherat wrote: On Wed, 2008-09-24 at 16:23 +0100, Mark Thomas wrote: The draft is here: http://jcp.org/en/jsr/detail?id=315 I though you were on the Servlet EG or am I mistaken? I was not aware of that file for whatever reason. I now remember the language that was discussed, and I remember being in favor of it. It now tolerates proprietary configuration of the cookie name, but does not actually mandate or change anything. I think per context would be a big problem for proxies, so I am against it. There's no need for a patch to state that, I think. Certainly, if they were looking at the cookie to manage load- balancing or similar then different values per context would make that configuration more complex than it needs to be. I am -1 for per context configuration, +1 for global configuration (and I know JF has a custom patch to do that, which I think also does the URL parameter). Against trunk: http://people.apache.org/~jfclere/patches/ jsessionid.patch. I need to check if that works against tc6.0.x Cheers Jean-frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release tc-native 1.1.15
Works for me :-) Test with MAX OS X 10.4.11 APR 1.3.3 Openssl 0.9.8h Am 08.09.2008 um 14:11 schrieb jean-frederic clere: The candidates binaries are available here: http://people.apache.org/~jfclere/tcnative/v1.1.15/ According to the release process, the 1.1.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [x ] Stable Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] bayeux inclusion
+1 ... :-) Peter Am 22.07.2008 um 19:17 schrieb Filip Hanik - Dev Lists: As promised, here is the vote for inclusion of the bayeux toolkit https://issues.apache.org/bugzilla/show_bug.cgi?id=45413 I think this toolkit should [x ] +1 include it as an independent component, I'm interested [ ] 0 sounds interesting [ ] -1 throw it away I plan to put it under svn.apache.org/repos/asf/tomcat/cometd/bayeux thinking that there may be more cometd components in the future Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback for Bayeux contribution
Hi Filip and Guy, great news +1 to commit the bayeux stuff. It was a big step to show the usage of async programming style. Peter Am 17.07.2008 um 03:47 schrieb Filip Hanik - Dev Lists: I'd like some feedback on the contribution, before I call for a vote for inclusion thanks Filip [EMAIL PROTECTED] wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=45413 Summary: Contribution of Bayeux implementation for Tomcat Product: Tomcat 6 Version: 6.0.16 Platform: All URL: http://svn.hanik.com/svn/repos/tomcat-bayeux OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Created an attachment (id=22267) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22267) Contribution of code The following bugzilla issue is a contribution of a codebase from Filip Hanik(asf:fhanik) and Guy Molinari(individual) Both have ICLAs on file with the ASF. Description: The contribution is two fold 1. The core implementation Core implementation of the Bayeux protocol using Comet and HTTP External dependencies: json.jar from json.org - Apache License 2.0 packages: - org.apache.cometd.bayeuxAPIs for web application developers derived from a proposed but incomplete API by Dojo Foundation - org.apache.tomcat.bayeux implementation of API classes 2. The sample applications External dependencies: Dojo Toolkit, license: http://trac.dojotoolkit.org/browser/dojo/trunk/LICENSE#L13 COPYRIGHT and LICENSE files included. The contribution is a full environment, to be able to download and build distributions. We don't expect everything to be merged in, instead we expect that the source code be integrated into tomcat/trunk and we can then modify the existing build scripts to fit into the Tomcat build/distribution scheme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r656124 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Hi Mark
Java 5 don't support new IOExceptin(String, Throwable)
compile:
[javac] Compiling 49 source files to /Users/peter/develop/
projects/tomcat/tomcat6currenttrunk/output/classes
[javac] /Users/peter/develop/projects/tomcat/tomcat6currenttrunk/
java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java:335:
cannot find symbol
[javac] symbol : constructor IOException
(java.lang.String,java.lang.Exception)
[javac] location: class java.io.IOException
[javac] throw new IOException(msg, ex);
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
==
-1 for this fix.
Regards
Peter
Am 14.05.2008 um 09:17 schrieb [EMAIL PROTECTED]:
Author: markt
Date: Wed May 14 00:17:46 2008
New Revision: 656124
URL: http://svn.apache.org/viewvc?rev=656124view=rev
Log:
Improve logging messages associated with previous commit in
response to Filip's veto
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/
JSSESocketFactory.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/jsse/
JSSESocketFactory.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
tomcat/util/net/jsse/JSSESocketFactory.java?
rev=656124r1=656123r2=656124view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/
JSSESocketFactory.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/
JSSESocketFactory.java Wed May 14 00:17:46 2008
@@ -322,17 +322,17 @@
ks.load(istream, pass.toCharArray());
} catch (FileNotFoundException fnfe) {
log.error(sm.getString(jsse.keystore_load_failed,
type, path,
-fnfe.getMessage()));
+fnfe.getMessage()), fnfe);
throw fnfe;
} catch (IOException ioe) {
log.error(sm.getString(jsse.keystore_load_failed,
type, path,
-ioe.getMessage()));
+ioe.getMessage()), ioe);
throw ioe;
} catch(Exception ex) {
String msg = sm.getString(jsse.keystore_load_failed,
type, path,
ex.getMessage());
-log.error(msg);
-throw new IOException(msg);
+log.error(msg, ex);
+throw new IOException(msg, ex);
} finally {
if (istream != null) {
try {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r643181 - /tomcat/trunk/webapps/docs/config/ajp.xml
HI Mark,
as you set request.secret=xxx you don't use request.useSecret=true.
With useSecret you generate a random requiredSecret,
Look at o.a.coyote.jk.common.HandlerRequest
LL 123
public void setSecret( String s ) {
requiredSecret=s;
}
public void setUseSecret( boolean b ) {
if(b) {
requiredSecret=Double.toString(Math.random());
}
}
Is request.shutdownEnabled is also true you can find
the file conf/ajp13.id with your AJP setup (s. generateAJp13Id()).
Regards
Peter
Am 01.04.2008 um 00:19 schrieb [EMAIL PROTECTED]:
Author: markt
Date: Mon Mar 31 15:19:20 2008
New Revision: 643181
URL: http://svn.apache.org/viewvc?rev=643181view=rev
Log:
Fix bug 44715. Document use of secret for AJP connector.
Modified:
tomcat/trunk/webapps/docs/config/ajp.xml
Modified: tomcat/trunk/webapps/docs/config/ajp.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/
ajp.xml?rev=643181r1=643180r2=643181view=diff
==
--- tomcat/trunk/webapps/docs/config/ajp.xml (original)
+++ tomcat/trunk/webapps/docs/config/ajp.xml Mon Mar 31 15:19:20 2008
@@ -274,6 +274,18 @@
to a particular port number on a particular IP address./p
/attribute
+attribute name=request.secret required=false
+ pOnly requests from workers with this secret keyword will
be accepted.
+ This attribute only has an effect if
coderequest.useSecret/code is
+ codetrue/code./p
+/attribute
+
+attribute name=request.useSecret required=false
+ pIf set to codetrue/code, then only requests from
workers with the
+ same secret keyword will be accepted. This is set to
codefalse/code
+ by default./p
+/attribute
+
attribute name=tcpNoDelay required=false
pIf set to codetrue/code, the TCP_NO_DELAY option will be
set on the server socket, which improves performance under most
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r642412 - /tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml
Hi Rainer, damit die junit test case funktionieren muss DU ein junit.jar in Deiner ant installation hinzufügen. Ich benutzte immer noch ein junit 3.8. Junit 4 nutzt Annotationen und damit konnte ich mich bisher überhaupt nicht anfreunden. Mit freundlichen Grüßen Peter Roßbach [EMAIL PROTECTED] Am 29.03.2008 um 12:19 schrieb Rainer Jung: Sehr gut! Schon mal das neue release target ausprobiert? Ich muss mir unbedingt mal die JUnit reports ansehen. Grüße sendet Rainer [EMAIL PROTECTED] schrieb: Author: pero Date: Fri Mar 28 15:31:20 2008 New Revision: 642412 URL: http://svn.apache.org/viewvc?rev=642412view=rev Log: add my last changes Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/ docs/changelog.xml?rev=642412r1=642411r2=642412view=diff = = --- tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml Fri Mar 28 15:31:20 2008 @@ -24,6 +24,7 @@ properties author email=[EMAIL PROTECTED]Rainer Jung/author +author email=[EMAIL PROTECTED]Peter Rossbach/author titleChangelog/title /properties @@ -32,6 +33,16 @@ subsection name=Cluster changelog add + New Membership service (org.apache.catalina.cluster.membership.McastService) + to better control tomcat cluster node start and stop (pero) + /add + fix +Porting the junit testcases (pero) + /fix + fix +ReplicationValve NPE as requested context is not available (pero) + /fix + add Initial port of org.apache.catalina.cluster from Tomcat 5.5 to Tomcat 6.0 (rjung) /add @@ -39,6 +50,15 @@ /subsection subsection name=Docs changelog + update +build.xml javadoc generation (pero) + /update + update +Update cluster etc/cluster-server.xml example (pero) + /update + add +Add cluster membership element docs to OACC (pero) + /add add Initial port of Tomcat 5.5 cluster docs to OACC (rjung) /add - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
Hi, I also see a lot of projects that are happy with a tomcat 5.5 cluster at tomcat 6 code base. The code change are very limited. I don't thing that we open a new long term implementation base. It is a fair migration path to tc6. New ideas must we add to the tomcat 6 ha and tribes modules. But currently the fastasyncqueue mode isn't really available at tc6. I missing also the MBean implementation to monitor the tc6 cluster activities. I very happy with the sandbox tomcat-oacc project. regards Peter Am 26.03.2008 um 17:57 schrieb Filip Hanik - Dev Lists: Rainer Jung wrote: Hi Jean-Frederic, jean-frederic clere wrote: Hi, What is the goal of tomcat-oacc exactly. 1 - Replace the actual tc-trunk cluster. No. 2 - Port the tc-5.5.x code and have an alternate cluster. Yes, reason for alternate see below. 3 - Just a try for the fun. That would be fine as well, but the goal is more than simply that. In the svn mkdir commit note I wrote: -- The sandbox provides a port of TC 5.5 cluster for Tomcat 6 in order to ease Tomcat 6 migration for webapps using Tomcat 5.5 cluster. Using OACC users can first switch to TC 6 with the same cluster configuration and later migrate to the very different HA/Tribes cluster. -- In my experience, cluster users which really have a critical app running, hesitate to switch to a completely different cluster implementation. On the other hand they might want to move on to Tomcat 6. I've not run into this scenario, customer's were actually happy to switch, as it provided them with much more flexibility. OACC provides an easy way of doing a two step migration. Go to Tomcat 6 (which in its core parts is not too different from 5.5) and then test the new HA/Tribes cluster. I'm right now in the process of adding the usual text files (release notes, running etc.) which should express this idea. Should be done in a few minutes. At the moment OACC is only a sandbox. If it looks good (functionality and stability) - which my first tests seem to indicate - then I would propose an optional extra download for TC 6 containing OACC. Filip's cluster has the bigger potential and should stay the default automatically contained in each download of TC 6, s.t. cluster newbies directly start with that one. But for users having a running TC 5.5 cluster I think it's nice - and necessary - to provide the OACC alternative. if this is for migration, why not provide a migration document instead. the only difference between 5.5 and 6.0 is the messaging and membership mechanism, which are fairly broken in 5.5. The actual session replication code is the same, but more bug fixes, in 6.0. if there is something lacking in 6.0 that you have in 5.5, then I would add that to 6 instead of doing this effort you're doing now. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: latest Tomcat and maven
Hi, I thing we must remove 6.0.16 and 5.5.26 from site. The 8 K Post Bug is a major issue and it must be fixed. But currently I don't understand the fix alternatives. Peter Am 09.03.2008 um 10:23 schrieb Henri Gomez: While looking at http://tomcat.apache.org/tomcat-6.0-doc/maven-jars.html I notice about that http://tomcat.apache.org/tomcat-6.0-doc/maven-jars.html still contains 6.0.14 jars. Will it be updated to 6.0.16 ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log warning after URL Querystring include
Hi Mark, I know that RFC 3986 is the successor from RFC 1738, but the query parameter definition (3.4 Page 23) isn't usefull. The HttpUtils.parseQueryString() definition is good, but not a complete BNF. The wikipedia definition http://en.wikipedia.org/wiki/Query_string is much better. OK, I also think that double is an uncorrect query part, but at my case, some site grabber's use those query strings to made trouble :-( Peter Am 29.02.2008 um 19:43 schrieb Mark Thomas: Peter Rossbach wrote: Hi, I see the following warning with following request http:// localhost:8080/snoopy/snoopy.jsp?hello=xxxworld=yyy Tomct 5.5.26 == 29.02.2008 13:49:29 org.apache.tomcat.util.http.Parameters processParameters WARNUNG: Parameters: Invalid chunk ignored. === Both parameter hello and world has the correct values, but every request logs a warning. At high traffic sites this anno user fault made admins really unhappy. At RFC 1738 only the following BNF are reference: That RFC is out of date. You want RFC 3986. Neither RFC actually defines how a parameter string should be formatted. I did quite a bit of googling but the best reference I found was the JavaDoc in the servlet spec for HttpUtils.parseQueryString() which suggests your URL above does indeed have a suspect query string because of the double . Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Log warning after URL Querystring include
Hi,
I see the following warning with following request http://localhost:
8080/snoopy/snoopy.jsp?hello=xxxworld=yyy
Tomct 5.5.26
==
29.02.2008 13:49:29 org.apache.tomcat.util.http.Parameters
processParameters
WARNUNG: Parameters: Invalid chunk ignored.
===
Both parameter hello and world has the correct values, but every
request logs a warning. At high
traffic sites this anno user fault made admins really unhappy.
At RFC 1738 only the following BNF are reference:
http://tools.ietf.org/html/rfc1738
---
; HTTP
httpurl= http://; hostport [ / hpath [ ? search ]]
hpath = hsegment *[ / hsegment ]
hsegment = *[ uchar | ; | : | @ | | = ]
search = *[ uchar | ; | : | @ | | = ]
search = *[ uchar | ; | : | @ | | = ]
-
The Wikipedia link ( http://en.wikipedia.org/wiki/Query_string)
is better, but not usefull as implementation reference note.
Why we report a warning ?
s. Parameters LL. 347
public void processParameters( byte bytes[], int start, int len,
String enc ) {
...
Ll 384
if( nameEnd=nameStart ) {
log.warn(Parameters: Invalid chunk ignored.);
continue;
// invalid chunk - it's better to ignore
}
Regards
Peter
Re: [PROPOSAL / POLL] Issue a de-support notice for Tomcat 4
+1 Peter On Feb 14, 2008, at 7:12 PM, Mark Thomas wrote: All, Tomcat 4 has been in maintenance mode for some time now with nearly all changes either updating libraries or fixing security bugs. I am happy to continue acting as release manager for as long as there are three +1s when there is a release. However, there will come a time when it makes sense to cease supporting Tomcat 4.1.x. Rather than just announce it, as we did for 5.0.x, I think we should try and give our users some notice to encourage them to move off 4.1.x and to give them time to plan the move. Therefore, my proposal is that we issue a de-support notice for Tomcat 4. The poll is what date we announce for the end of Tomcat 4 support. Around 12 months notice seems reasonable to me so I am going to suggest 30 June 2009. Do people think this is enough notice? Alternative suggestions welcome. The web pages would also need the appropriate updates. Thoughts?
Re: [PROPOSAL] Announce 3.x is no longer supported
+1 Peter On Feb 14, 2008, at 7:05 PM, Mark Thomas wrote: All, The last 3.x release was almost 4 years ago. Since then there has been one security patch made available in source form and that was more an application issue than a Tomcat one. There is still the odd support question on the users list but I think it is time to draw a line under 3.x. In practice, this would mean: - removing the download links for 3.x from tomcat.a.o - removing 3.x from dist (it would remain in the archives) - removing the 3.x docs from tomcat.a.o - closing any open 3.x bugs as WONTFIX Adding a note that 3.x is no longer supported / removing much of the 3.x info from: /index.html /security-3.html /whichversion.html /bugreport.html Thoughts?
Re: svn commit: r620848 - /tomcat/tc6.0.x/trunk/STATUS.txt
Hi Tim, +1 WebRuleSet LL 250 digester.addCallMethod(prefix + web-app/listener/listener- class, addApplicationListener, 0); digester.addRule(prefix + web-app/jsp-config, jspConfig); digester.addCallMethod(prefix + web-app/jsp-config/jsp- property-group/url-pattern, addJspMapping, 0); # Remove this... digester.addCallMethod(prefix + web-app/listener/listener- class, addApplicationListener, 0); We must also change this at tomcat 5.x.x code base (LL 240) Peter Am 12.02.2008 um 19:44 schrieb Tim Funk: Not sure if I understand the question, the problem is our use of digester. We had 2 listener rules being created and each called addListener. So when an a listener was found - it was being processed twice. (Or was I missing something?) -Tim jean-frederic clere wrote: [EMAIL PROTECTED] wrote: Author: funkman Date: Tue Feb 12 08:27:45 2008 New Revision: 620848 URL: http://svn.apache.org/viewvc?rev=620848view=rev Log: addition of dupl listener removal and a vote Won't it be possible to prevent the addition in the Digester instead? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Facing while running PHP in Tomcat Container
HI, has you setup your libs at shell env LD_LIBRARY_PATH variable? Put following definition at your $CATALINA_HOME/bin/setenv.sh #!/bin/sh PHP_HOME=xxx export LD_LIBRARY_PATH =$PHP_HOME/lib/libphp5servlet.so:$PHP_HOME/lib/ libphp5.so Peter Please, discuss those question at user list first! Am 05.02.2008 um 07:01 schrieb puneetjain: Hi, I am trying to integrate PHP with tomcat server i.e. trying to running PHP in servlet container. Environment: = Operating System: RedHat Enterprize Linux 3 Tomcat Version: 6 PHP version: 5.2.5 Java: 1.5 Steps Performed: 1. Install the tomcat. 2. Install the php 3. Create a web project. 4. Place the php5servlet.jar in the WEB_INF/lib directory. 5. Add the below entry in my web.xml. ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; version=2.3 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http:/java.sun.com/dtd/web-app_2_3.dtd servlet servlet-namephp/servlet-name servlet-classnet.php.servlet/servlet-class /servlet servlet servlet-namephp-formatter/servlet-name servlet-classnet.php.formatter/servlet-class /servlet servlet-mapping servlet-namephp/servlet-name url-pattern*.php/url-pattern /servlet-mapping servlet-mapping servlet-namephp-formatter/servlet-name url-pattern*.phps/url-pattern /servlet-mapping /web-app 6. Create a war file and deployed on the tomcat. Exception: === When I tried to deploy this war file it says that the libphp5servlet.so and libphp5.so libraries are missing. I have tried these steps on Windows XP and used php5servlet.dll. PHP is working on tomcat in windows. I am unable to find the procedure to create/get the libphp5servlet.so and libphp5.so library to run PHP in Tomcat container in Linux Environment. Please help me to resolve this problem. Thanks, Puneet -- View this message in context: http://www.nabble.com/Facing-while- running-PHP-in-Tomcat-Container-tp15283842p15283842.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up: Bayeux contribution
Hi Flilip and Guy, Greate job, nice to see you cometd implementation. Can you please active a dir tarball download at your viewvc or place a complete download release, otherwise? Regards Peter Am 05.02.2008 um 04:16 schrieb Filip Hanik - Dev Lists: Guy Molinari and myself have completed a Bayuex implementation. You can find it at: http://svn.hanik.com/viewvc/tomcat-bayeux/ user: tomcat password: tomcat We are now waiting for Guy's CLA to be registered and then we are ready to contribute it to the Tomcat code base. We did rework the dojox.cometd server side API, just cleaned it up and simplified it a lot. We have proposed the changes back to them, but if they don't accept it, I'd suggest we branch off and create our own API for the server side components. As long as it follows the spec, that should be fine, as the spec is only for the protocol. Feel free to test drive it and look over the code and provide any feedback/criticism you might have. note, the samples are not part of the contribution, only the server side Java code, instead we plan on creating new samples to demonstrate the different usages of the API. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up: Bayeux contribution
Many thanks for info! Peter Am 05.02.2008 um 15:02 schrieb Filip Hanik - Dev Lists: hi Peter, http://svn.hanik.com/viewvc/tomcat-bayeux/build/ user: tomcat pwd: tomcat cometd.war contains the code and examples tomcat-cometd.jar is only the core code to check out the repo svn co https://svn.hanik.com/repos/svn/tomcat-bayuex Filip Peter Rossbach wrote: Hi Flilip and Guy, Greate job, nice to see you cometd implementation. Can you please active a dir tarball download at your viewvc or place a complete download release, otherwise? Regards Peter Am 05.02.2008 um 04:16 schrieb Filip Hanik - Dev Lists: Guy Molinari and myself have completed a Bayuex implementation. You can find it at: http://svn.hanik.com/viewvc/tomcat-bayeux/ user: tomcat password: tomcat We are now waiting for Guy's CLA to be registered and then we are ready to contribute it to the Tomcat code base. We did rework the dojox.cometd server side API, just cleaned it up and simplified it a lot. We have proposed the changes back to them, but if they don't accept it, I'd suggest we branch off and create our own API for the server side components. As long as it follows the spec, that should be fine, as the spec is only for the protocol. Feel free to test drive it and look over the code and provide any feedback/criticism you might have. note, the samples are not part of the contribution, only the server side Java code, instead we plan on creating new samples to demonstrate the different usages of the API. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.20/1259 - Release Date: 2/4/2008 8:42 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heads up: Bayeux contribution
I thing the implementation is very small and a valuable new tomcat example. +1 to add cometd example to current tomcat 6 code base Peter Am 05.02.2008 um 15:06 schrieb jean-frederic clere: Yoav Shapira wrote: On Feb 5, 2008 3:26 AM, jean-frederic clere [EMAIL PROTECTED] wrote: The normal way is to go through the incubator process. Why? This is not a new project, Guy is not becoming a committer yet. This is a code contribution from a committer and a volunteer. It's not different in spirit than a small new feature enhancement posted to Bugzilla. All we need is the iCLA from the volunteer and the code the be posted to our public issue tracking system as a contribution. It is just I thing it is too big for that. Cheers Jean-Frederic Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 5.5.26
+1 tested with MAC os x 10.4.11. Am 31.01.2008 um 16:06 schrieb Filip Hanik - Dev Lists: According to the release process, the 5.5.26 tag is: [ ] Broken [ ] Alpha [ ] Beta [x] Stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.16
Am 30.01.2008 um 15:21 schrieb Remy Maucherat: According to the release process, the 6.0.16 tag is: [ ] Broken [ ] Alpha [ ] Beta [ x] Stable Peter
Re: svn commit: r616522 - in /tomcat/trunk/java/org/apache/tomcat/util/net/puretls: PureTLSImplementation.java PureTLSSocket.java PureTLSSocketFactory.java PureTLSSupport.java
+1,
I think the PureTLS support is not usefull anymore, but the proposed
API change looks well.
Peter
Am 30.01.2008 um 06:16 schrieb Bill Barker:
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Bill Barker wrote:
Mark Thomas [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: markt
Date: Tue Jan 29 13:18:25 2008
New Revision: 616522
URL: http://svn.apache.org/viewvc?rev=616522view=rev
Log:
Tab police. No function change
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/puretls/
PureTLSImplementation.java
tomcat/trunk/java/org/apache/tomcat/util/net/puretls/
PureTLSSocket.java
tomcat/trunk/java/org/apache/tomcat/util/net/puretls/
PureTLSSocketFactory.java
tomcat/trunk/java/org/apache/tomcat/util/net/puretls/
PureTLSSupport.java
Before I spend any more time looking at
http://issues.apache.org/bugzilla/show_bug.cgi?id=44318 am I
correct in
thinking that PureTLS has never been part of of the TC6 build
and that I
could just remove these four files instead?
If we do want to keep PureTLS support the main problem appears
to be
http://svn.apache.org/viewvc?view=revrevision=428884 which
added a JSSE
dependency into o.a.t.util.net.SSLImplementation
As far as I can tell, PureTLS doesn't support nio anyway so...
Thoughts?
I remember that there was talk of removing PureTLS support. The
PureTLS
library isn't actively developed anymore (some security fixes,
but not
much else), and it still depends on a hacked version of Cryptix.
But
nobody has stepped up to actually remove it.
That having been said, I'd prefer to remove the JSSE dependancy from
SSLImplementation, since it makes it nearly impossible to develop a
non-JSSE SSLImplementation (e.g. I there was talk of developing
one for
Mozilla's SSL stack, but nothing ever happened). Without having
thought
it out much, something like changing
abstract public SSLSupport getSSLSupport(SSLSession session);
to
abstract public SSLSupport getNioSSLSupport(Socket sock);
if we are gonna remove it, why remove it only for one connector.
The code
used is the same by both the BIO and the NIO connector
not sure we need the abstraction at all
I'm for removing support for PureTLS, since it is largely
unmaintained at
the moment. But the abstraction is usefull to be able to support SSL
providers (e.g. Mozilla meantioned above) that don't implement
JSSE. It
wasn't about getting removing it from the NIO Connecter, just
making the
signature not depend on JSSE. So for JSSE, something like:
public SSLSupport getNioSSLSupport(Socket sock) {
return factory.getSSLSupport(((SSLSocket)sock).getSession());
}
I just prefer to keep where we have plug-in structure such as
here, that we
don't just throw it away in favor of only supporting Sun's solution.
In the JSSE case, you can get the SSLSession from the Socket, so
it would
be a small change to the existing code.
same code can be reused for both connectors.
Filip
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r615896 - /tomcat/tc6.0.x/trunk/STATUS.txt
Nice checkin, but I miss the changelog entries Peter Am 28.01.2008 um 15:38 schrieb [EMAIL PROTECTED]: Author: jim Date: Mon Jan 28 06:37:56 2008 New Revision: 615896 URL: http://svn.apache.org/viewvc?rev=615896view=rev Log: Cast 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=615896r1=615895r2=615896view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan 28 06:37:56 2008 @@ -42,20 +42,20 @@ Add support for remaining truststore system property Not essential for 6.0.16. http://svn.apache.org/viewvc?rev=613266view=rev - +1: markt, pero, remm + +1: markt, pero, remm, jim -1: * Update JNDI docs to use server.xml less and Context more http://svn.apache.org/viewvc?rev=613689view=rev Not essential for 6.0.16. - +1: markt, pero, remm + +1: markt, pero, remm, jim -1: * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=44268 Log a warning when a duplicate listener is ignored. http://svn.apache.org/viewvc?rev=614012view=rev Not essential for 6.0.16 - +1: markt, remm, pero + +1: markt, remm, pero, jim -1: * Correct svn properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r614974 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/coyote/http11/Http11NioProcessor.java
Hi Filip,
can you remove the STATUS.txt entry, please?
Thanks
Peter
Am 24.01.2008 um 21:23 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Thu Jan 24 12:22:59 2008
New Revision: 614974
URL: http://svn.apache.org/viewvc?rev=614974view=rev
Log:
vote and implement
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProcessor.java
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?
rev=614974r1=614973r2=614974view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 24 12:22:59 2008
@@ -80,5 +80,5 @@
Otherwise it's only reachable in the HTMLManager.
http://people.apache.org/~rjung/patches/web_xml_expire.patch
(backport of r614933 from trunk)
- +1: rjung
+ +1: rjung, fhanik
-1:
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProcessor.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/
apache/coyote/http11/Http11NioProcessor.java?
rev=614974r1=614973r2=614974view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProcessor.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProcessor.java Thu Jan 24 12:22:59 2008
@@ -751,7 +751,10 @@
NioEndpoint.KeyAttachment attach =
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
if (attach != null) {
attach.setComet(comet);
-if (!comet) {
+if (comet) {
+Integer comettimeout = (Integer)
request.getAttribute(org.apache.tomcat.comet.timeout);
+if (comettimeout != null) attach.setTimeout
(comettimeout.longValue());
+} else {
//reset the timeout
attach.setTimeout
(endpoint.getSocketProperties().getSoTimeout());
}
@@ -889,6 +892,10 @@
NioEndpoint.KeyAttachment attach =
(NioEndpoint.KeyAttachment) key.attachment();
if (attach != null) {
attach.setComet(comet);
+if (comet) {
+Integer comettimeout = (Integer)
request.getAttribute(org.apache.tomcat.comet.timeout);
+if (comettimeout != null)
attach.setTimeout(comettimeout.longValue());
+}
}
}
} catch (InterruptedIOException e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DOS-Lineends in many files contained in distribution tar.gz
Hi Rainer,
+1..
Is it fix with followig patch?
===
Index: tomcat60/dist.xml
===
--- /tomcat60/dist.xml (Revision 613549)
+++ tomcat/tomcat60/dist.xml(Arbeitskopie)
@@ -561,6 +561,22 @@
target name=package-tgz
fixcrlf srcdir=${tomcat.dist}
includes=*.txt,LICENSE,NOTICE eol=lf/
fixcrlf srcdir=${tomcat.dist}/conf eol=lf/
+fixcrlf srcdir=${tomcat.dist}/webapps eol=lf
+include name=**/*.html /
+include name=**/*.java /
+include name=**/*.jsp /
+include name=**/*.txt /
+include name=**/*.properties /
+include name=**/*.tag /
+include name=**/*.tld /
+include name=**/*.jspf /
+include name=**/*.jspx /
+include name=**/*.svg /
+include name=**/*.xsd /
+include name=**/*.xml /
+include name=**/*.xsl /
+include name=**/*.mdl /
+/fixcrlf
tar longfile=gnu compression=gzip
tarfile=${tomcat.release}/v${version}/bin/$
{final.name}.tar.gz
tarfileset dir=${tomcat.dist} mode=755 prefix=$
{final.name}
==
Peter
Am 25.01.2008 um 01:47 schrieb Rainer Jung:
Hi,
I stumbled today over DOS line endings in the web.xml file of the
manager contained in TC 6.0.14 tar.gz download.
A little check reveals, that the following files have DOS line
endings, although the tar.gz is supposed to use Unix convention
were appropriate:
- RELEASE-NOTES
- bin/catalina-tasks.xml
and in webapps all files with suffixes:
Count Suffix
286 html
46 java
48 jsp
12 txt
11 xml
5 properties
4 tag
3 tld
2 jspf
2 jspx
2 svg
1 xsd
1 xsl
1 mdl
All of those suffixes under webapps always have DOS lineendings
(one file even has mixed ending: webapps/manager/sessionDetail.jsp
misses the ^M in the last line).
I don't know if dist.xml is actually used for packaging. It uses
fixcrlf for a couple of files (mainly *.sh, *.txt, conf/*, some [A-
Z]*) but it would be nice, if we would also transform the above
mentioned.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for tomcat 5.5.25 to actually close on Connection: close
Hi Remy, True, but today it exists a lot of applications/Service that want control the connection. At my Comet example I have also miss this simple feature. I feel that the patch looks good. Peter Am 25.01.2008 um 13:14 schrieb Remy Maucherat: On Thu, 2008-01-24 at 17:11 -0500, John Wehle wrote: Currently if a servlet uses: res.setHeader(Connection, close); tomcat just sets the header and sends the reponse to the client. It then waits for the client to close the connection. In some cases (i.e. buggy client) the client doesn't process the close which causes resources to be unduly tied up on the server until the connectionTimeout is reached which then closes the connection. This also causes the user to experience a browser delay corresponding to connectionTimeout. This patches causes tomcat to close a connection after sending a response which includes Connection: close. The rationale is that a servlet has no business dealing with the connection behavior: if the client has problems, you can add appropriate configuration in the connector. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r613796 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/startup/HostConfig.java webapps/docs/changelog.xml
Hi Remy, +1 to release next week! Am 21.01.2008 um 10:53 schrieb Remy Maucherat: On Mon, 2008-01-21 at 08:41 +, [EMAIL PROTECTED] wrote: Author: pero Date: Mon Jan 21 00:41:31 2008 New Revision: 613796 URL: http://svn.apache.org/viewvc?rev=613796view=rev Log: WatchedResource doesn't work if app is outside host appbase webapps The previous behavior has always been intentional, as I considered that webapps out of the auto deploy folder are not to be automagically managed by Tomcat. It's not a very important issue, but it seems you are committing this on a very fast track due to some customer need :( No customer need, but it seems a good extension as you have a public user folder installation. As usual, there's the last minute patch rush before the tag. As a result, I am delaying the new 6.0 tag by one week, to Monay 28th, in order to properly review every . Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r613273 - in /tomcat/tc6.0.x/trunk: STATUS.txt build.properties.default webapps/docs/changelog.xml
Hi Mark, Am 20.01.2008 um 17:52 schrieb Mark Thomas: Peter Rossbach wrote: Hi Mark, I have a problem with a fresh tomcat 55 trunk build. The admin build.xml missing the new digester 1.8. Yep - I broke it. I was a bit too enthusiastic with my clean-up. Your fix looks good. I'll revert that part of the fix. OK, small problem ;-) Also I can't find the new 1.1 jta.jar. At sun site we can only download a class bundle! You just have to rename the class bundle to jta.jar Which class need the JTA interface? o.a.c.core.NamingContextListener o.a.naming.TransactionRef We not need JTA classes at compile time. User need JTA only at runtime! Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r613273 - in /tomcat/tc6.0.x/trunk: STATUS.txt build.properties.default webapps/docs/changelog.xml
Hi Mark,
I have a problem with a fresh tomcat 55 trunk build. The admin
build.xml missing the new digester 1.8.
FIX:
Index: build/build.xml
===
--- build/build.xml (Revision 613520)
+++ build/build.xml (Arbeitskopie)
@@ -1898,8 +1898,13 @@
description=Download binary packages
mkdir dir=${base.path} /
-!-- Downdown any sub package or tools needed. --
+!-- Download any sub package or tools needed. --
antcall target=downloadgz
+ param name=sourcefile value=${commons-digester.loc}/
+ param name=destfile value=${commons-digester.jar}/
+/antcall
+
+antcall target=downloadgz
param name=sourcefile value=${commons-beanutils.loc}/
param name=destfile value=${commons-beanutils.jar}/
/antcall
Also I can't find the new 1.1 jta.jar. At sun site we can only
download a class bundle!
Which class need the JTA interface?
Regards
Peter
Am 18.01.2008 um 22:08 schrieb [EMAIL PROTECTED]:
Author: markt
Date: Fri Jan 18 13:08:42 2008
New Revision: 613273
URL: http://svn.apache.org/viewvc?rev=613273view=rev
Log:
Update libs
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/build.properties.default
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?
rev=613273r1=613272r2=613273view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Jan 18 13:08:42 2008
@@ -31,11 +31,6 @@
+1: jfclere
-1: fhanik - Can we add the 'package' directive to make the
package match the dir structure
-* Update: native to 1.1.12; commons-pool to 1.4; commons archive
locations.
- http://svn.apache.org/viewvc?rev=612950view=rev
- +1: markt, remm, fhanik
- -1:
-
* Add ManagerBase session getLastAccessedTimestamp and
getCreationTimestamp for better
remote JMX access.
http://svn.apache.org/viewvc?rev=612971view=rev
Modified: tomcat/tc6.0.x/trunk/build.properties.default
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/
build.properties.default?rev=613273r1=613272r2=613273view=diff
==
--- tomcat/tc6.0.x/trunk/build.properties.default (original)
+++ tomcat/tc6.0.x/trunk/build.properties.default Fri Jan 18
13:08:42 2008
@@ -43,12 +43,12 @@
compile.target=1.5
compile.debug=true
-base-jakarta.loc=http://archive.apache.org/dist/jakarta
+base-commons.loc=http://archive.apache.org/dist/commons
base-tomcat.loc=http://archive.apache.org/dist/tomcat
# - Commons Logging, version 1.1 or later -
commons-logging-version=1.1.1
-commons-logging-src.loc=${base-jakarta.loc}/commons/logging/source/
commons-logging-${commons-logging-version}-src.tar.gz
+commons-logging-src.loc=${base-commons.loc}/logging/source/commons-
logging-${commons-logging-version}-src.tar.gz
# - Webservices -
jaxrpc-src.loc=http://repo1.maven.org/maven2/geronimo-spec/
geronimo-spec-jaxrpc/1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar
@@ -61,25 +61,25 @@
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/
eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
# - Tomcat native library -
-tomcat-native.home=${base.path}/tomcat-native-1.1.10
+tomcat-native.home=${base.path}/tomcat-native-1.1.12
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
-tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/
tomcat-native-1.1.10-src.tar.gz
+tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/
tomcat-native-1.1.12-src.tar.gz
# - Commons DBCP, version 1.1 or later -
commons-dbcp.version=1.2.2
commons-dbcp.home=${base.path}/commons-dbcp-1.2.2-src
-commons-dbcp-src.loc=${base-jakarta.loc}/commons/dbcp/source/
commons-dbcp-1.2.2-src.tar.gz
+commons-dbcp-src.loc=${base-commons.loc}/dbcp/source/commons-
dbcp-1.2.2-src.tar.gz
# - Commons Pool, version 1.1 or later -
-commons-pool.home=${base.path}/commons-pool-1.3-src
-commons-pool-src.loc=${base-jakarta.loc}/commons/pool/source/
commons-pool-1.3-src.tar.gz
+commons-pool.home=${base.path}/commons-pool-1.4-src
+commons-pool-src.loc=${base-commons.loc}/pool/source/commons-
pool-1.4-src.tar.gz
# - Commons Collections, version 2.0 or later -
commons-collections.home=${base.path}/commons-collections-3.2-src
commons-collections.lib=${commons-collections.home}
commons-collections.jar=${commons-collections.lib}/commons-
collections-3.2.jar
commons-collections.loc=${base-jakarta.loc}/commons/collections/
binaries/commons-collections-3.2.tar.gz
-commons-collections-src.loc=${base-jakarta.loc}/commons/
collections/source/commons-collections-3.2-src.tar.gz
+commons-collections-src.loc=${base-commons.loc}/collections/source/
Re: svn commit: r613196 - /tomcat/tc6.0.x/trunk/STATUS.txt
HI Remy, the problem is the current getLastAccessedTime and getCreationTime methods has standard formated Date result. Good for humans, but bad for jmx scripts writers. You can't simply parse those standard format strings at a remote jmx client. The java.util.Date class has only a deprecated methods to parse it. Ok, I can use SimpleDateFormatter but as you must control a lot of session this is a time consuming task. The current fix made my JMX remote scripts a lot easier. Peter Am 18.01.2008 um 17:12 schrieb [EMAIL PROTECTED]: Author: remm Date: Fri Jan 18 08:12:34 2008 New Revision: 613196 URL: http://svn.apache.org/viewvc?rev=613196view=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=613196r1=613195r2=613196view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Jan 18 08:12:34 2008 @@ -38,7 +38,7 @@ * Update: native to 1.1.12; commons-pool to 1.4; commons archive locations. http://svn.apache.org/viewvc?rev=612950view=rev - +1: markt + +1: markt, remm -1: * Add ManagerBase session getLastAccessedTimestamp and getCreationTimestamp for better @@ -51,6 +51,6 @@ at production servers. http://svn.apache.org/viewvc?rev=612988view=rev +1: pero - -1: + -1: remm (the patch looks like a hack, and we don't know what exactly you are fixing) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] tcnative releases independent from tomcat
On Tue, 2008-01-15 at 16:19 +0100, jean-frederic clere wrote: [X] Make tcnative release independent from tomcat release and add the corresponding pages in http://tomcat.apache.org/connectors-doc/ [ ] Remove existing tcnative releases. (others are using them). Peter
Re: new year, new version? 6.0.16
+1 Peter Am 16.01.2008 um 23:26 schrieb Filip Hanik - Dev Lists: could we get a target date for this? I believe there is enough community interest to push out a new release Filip Filip Hanik - Dev Lists wrote: we have a lot of updates added in, I think it may be good to set a date for our next release and work towards that Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r612319 - /tomcat/current/tc5.5.x/STATUS.txt
Hi Filip and Mark, you can found the patch at: http://people.apache.org/~markt/patches/2008-01-15-tc5-lib-updates.patch Peter Am 16.01.2008 um 03:44 schrieb Filip Hanik - Dev Lists: I get a 404 on the URL Filip [EMAIL PROTECTED] wrote: Author: markt Date: Tue Jan 15 16:03:57 2008 New Revision: 612319 URL: http://svn.apache.org/viewvc?rev=612319view=rev Log: Propose a library update for TC5 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=612319r1=612318r2=612319view=diff = = --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Tue Jan 15 16:03:57 2008 @@ -54,3 +54,8 @@ +1: funkman, pero, markt -1: +* Update to latest versions of all libraries (assumes HttpClient patch) + Update Eclipse classpaths to new versions + http://people.apache.org/~markt/patches/2008-01-15-tc5-lib- update.patch + +1: markt + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611940 - /tomcat/trunk/RELEASE-NOTES
Hi Mark, it isn't true that we don't use commons-logging. Please check extra.xml ant build file! -1 Peter Am 14.01.2008 um 22:22 schrieb [EMAIL PROTECTED]: Author: markt Date: Mon Jan 14 13:22:09 2008 New Revision: 611940 URL: http://svn.apache.org/viewvc?rev=611940view=rev Log: Update to available libraries Modified: tomcat/trunk/RELEASE-NOTES Modified: tomcat/trunk/RELEASE-NOTES URL: http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES? rev=611940r1=611939r2=611940view=diff == --- tomcat/trunk/RELEASE-NOTES (original) +++ tomcat/trunk/RELEASE-NOTES Mon Jan 14 13:22:09 2008 @@ -85,11 +85,10 @@ * catalina-ant.jar (Tomcat Catalina Ant tasks) * catalina-ha.jar (High availability package) * catalina-tribes.jar (Group communication) -* commons-logging-api.jar (Commons Logging API 1.0.x) * el-api.jar (EL 2.1 API) * jasper.jar (Jasper 2 Compiler and Runtime) * jasper-el.jar (Jasper 2 EL implementation) -* jasper-jdt.jar (Eclipse JDT 3.2 Java compiler) +* jasper-jdt.jar (Eclipse JDT 3.3 Java compiler) * jsp-api.jar (JSP 2.1 API) * servlet-api.jar (Servlet 2.5 API) * tomcat-coyote.jar (Tomcat connectors and utility classes) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611696 - in /tomcat/connectors/trunk/jk: native/apache-1.3/ native/apache-2.0/ native/common/ xdocs/generic_howto/ xdocs/miscellaneous/ xdocs/reference/
Hi Rainer,
many thanks for that cool feature ;-)
Peter
Am 14.01.2008 um 03:28 schrieb [EMAIL PROTECTED]:
Author: rjung
Date: Sun Jan 13 18:28:27 2008
New Revision: 611696
URL: http://svn.apache.org/viewvc?rev=611696view=rev
Log:
Allow dynamic setting of reply timeout using the httpd environment
variable JK_REPLY_TIMEOUT.
Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/xdocs/generic_howto/timeouts.xml
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml
Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/
apache-1.3/mod_jk.c?rev=611696r1=611695r2=611696view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Sun Jan
13 18:28:27 2008
@@ -70,6 +70,7 @@
#define JK_ENV_SESSION (SSL_SESSION_ID)
#define JK_ENV_KEY_SIZE (SSL_CIPHER_USEKEYSIZE)
#define JK_ENV_CERTCHAIN_PREFIX (SSL_CLIENT_CERT_CHAIN_)
+#define JK_ENV_REPLY_TIMEOUT(JK_REPLY_TIMEOUT)
#define JK_ENV_WORKER_NAME (JK_WORKER_NAME)
#define JK_NOTE_WORKER_NAME (JK_WORKER_NAME)
#define JK_NOTE_WORKER_TYPE (JK_WORKER_TYPE)
@@ -610,6 +611,7 @@
int size;
request_rec *r = private_data-r;
char *ssl_temp = NULL;
+const char *reply_timeout = NULL;
/* Copy in function pointers (which are really methods) */
s-start_response = ws_start_response;
@@ -639,6 +641,10 @@
s-flush_packets = 1;
if (conf-options JK_OPT_FLUSHEADER)
s-flush_header = 1;
+
+reply_timeout = apr_table_get(r-subprocess_env,
JK_REPLY_TIMEOUT);
+if (reply_timeout)
+s-reply_timeout = atoi(reply_timeout);
if (conf-options JK_OPT_DISABLEREUSE)
s-disable_reuse = 1;
Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/
apache-2.0/mod_jk.c?rev=611696r1=611695r2=611696view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Sun Jan
13 18:28:27 2008
@@ -112,6 +112,7 @@
#define JK_ENV_SESSION (SSL_SESSION_ID)
#define JK_ENV_KEY_SIZE (SSL_CIPHER_USEKEYSIZE)
#define JK_ENV_CERTCHAIN_PREFIX (SSL_CLIENT_CERT_CHAIN_)
+#define JK_ENV_REPLY_TIMEOUT(JK_REPLY_TIMEOUT)
#define JK_ENV_WORKER_NAME (JK_WORKER_NAME)
#define JK_NOTE_WORKER_NAME (JK_WORKER_NAME)
#define JK_NOTE_WORKER_TYPE (JK_WORKER_TYPE)
@@ -621,10 +622,10 @@
static int init_ws_service(apache_private_data_t * private_data,
jk_ws_service_t *s, jk_server_conf_t *
conf)
{
+int size;
request_rec *r = private_data-r;
-
char *ssl_temp = NULL;
-int size;
+const char *reply_timeout = NULL;
/* Copy in function pointers (which are really methods) */
s-start_response = ws_start_response;
@@ -652,6 +653,10 @@
s-flush_packets = 1;
if (conf-options JK_OPT_FLUSHEADER)
s-flush_header = 1;
+
+reply_timeout = apr_table_get(r-subprocess_env,
JK_REPLY_TIMEOUT);
+if (reply_timeout)
+s-reply_timeout = atoi(reply_timeout);
if (conf-options JK_OPT_DISABLEREUSE)
s-disable_reuse = 1;
Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/
common/jk_ajp_common.c?rev=611696r1=611695r2=611696view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
(original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Sun
Jan 13 18:28:27 2008
@@ -1815,10 +1815,14 @@
/* Start read all reply message */
while (1) {
int rc = 0;
+/* Allow to overwrite reply_timeout on a per URL basis via
service struct */
+int reply_timeout = s-reply_timeout;
+if (reply_timeout 0)
+reply_timeout = p-worker-reply_timeout;
/* If we set a reply timeout, check if something is
available */
-if (p-worker-reply_timeout 0) {
-if (jk_is_input_event(p-sd, p-worker-reply_timeout,
l) ==
+if (reply_timeout 0) {
+if (jk_is_input_event(p-sd, reply_timeout, l) ==
JK_FALSE) {
p-last_errno = errno;
Re: backlog measurement
HI Andrew, good idea, but why you can contribute a code from Harish Prabandham ([EMAIL PROTECTED]). We can only accept contributions from orignal author and with Apache 2 license included! I seems that this only work with java 5 and the code is designed for JIO HTTP tomcat 5.5. Open a bug report, then we can discuss your contribution. Regards, Peter Am 10.01.2008 um 09:47 schrieb Andrew Skiba: Hello, I want to contribute a custom SocketFactory allowing to analyze the utilization of acceptConnection attribute of a Connector. In a properly configured production system, there should be rare situations where connections wait for a worker thread to be handled. Our client complained on high latency of web requests, but the measurement on servlet did not show high latency. So we wanted to know the number of connections which wait in socket backlog and were not accepted yet. I solved this problem by writing a custom SocketFactory, which accepts connections immediately and puts it in my queue until a call to accept() will take them. So the number of waiting connections can be monitored via JMX. To activate this factory, the declaration of the corresponding Connector in server.xml should be changed like in the following example. Connector port=8080 maxHttpHeaderSize=8192 maxThreads=10 minSpareThreads=5 maxSpareThreads=7 enableLookups=false redirectPort=8443 acceptCount=10 connectionTimeout=2000 disableUploadTimeout=true socketFactory=org.apache.tomcat.util.net.BacklogMeasuringServerSocket Factory/ No changes in existing classes are required. Please review the code in the attachment. Andrew Skiba. BacklogMeasuringServerSocketFactory.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.26
Good work! Apache Tomcat Connectors 1.2.26 is: [x ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Merry Christmas Peter Am 21.12.2007 um 19:41 schrieb Rainer Jung: Hello to all Tomcat project members, JK 1.2.26 has been available for testing for some days as a svn snapshot. Only one small bug has been found and fixed. So I would like to proceed with the release vote. If you want to take a look, the final source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/ The updated documentation can be found at http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/ Binaries might be available under http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/binaries/ Linux and Solaris binaries are there, feel free to provide further binaries. So here's the vote. Because of the holidays, the vote will be closed on Monday December 24, 11:00 a.m. GMT. Apache Tomcat Connectors 1.2.26 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Thank you and a Merry Christmas, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging TOMCAT_NATIVE_1_1_12
+1 to that before next tomcat release tagging Peter Am 19.12.2007 um 17:23 schrieb jean-frederic clere: Hi, I'll tag the tcnative to 1.1.12. The changes are the following between 1.1.12 and 1.1.11: +++ Improvement: Add support of J9VM based JVM. (jfclere) Improvement: Arrange licence in source files. (markt). Improvement: Add two new 'immediate' methods for sending the data. It is the responsibility of the Java callee to deal with the returned values and retry if the error was non-fatal. (mturk) Fix: Arrange the check of openssl version. It was failing on Linux. (jfclere) Fix: Prevent returning APR_SUCCESS when there is something wrong in ssl layer. Fix for PR: 44087 (jfclere) +++ It seems 1.1.10 was the latest release that has a tarball in http://archive.apache.org/dist/tomcat/tomcat-connectors/native/... Any comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 - Cluster error.
I think your Membership DropTime 4sec is very small. Some more Load
or a FULL GC can drop your member.
Nomally I use 30 sec.
Peter
Am 19.12.2007 um 11:40 schrieb Raúl García:
Hi,
We are using tomcat 6.0.14.
We use a cluster working at the same machine,
we start it and it seems to be ok, replication is working fine.
But within the next 12h from startup, we see this error at the
catalina.out
log file, of the first instance, the error repeats forever until we
stop
both
instances and restart them again.
The server is supporting a 0.5 hit per seccond aprox.
CATALINA.OUT
===
Dec 19, 2007 10:07:30 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
performBasicCheck
WARNING: Member added, even though we werent
notified:org.apache.catalina.tribes.membership.MemberImpl[tcp://
localhost:40
02,localhost,4002,
alive=165023279,id={-42 -48 112 17 -57 -2 73 -111 -109 113 -93 84 6
91 -72
102 }, payload={}, command={}, domain={}, ]
Dec 19, 2007 10:07:30 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://
localhost:4002,
localhost,4002, alive=165023279,id={-42 -48 112 17 -57
-2 73 -111 -109 113 -93 84 6 91 -72 102 }, payload={}, command={},
domain={}, ]
Dec 19, 2007 10:07:34 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl
[tcp://loc
alhost:4002,localhost,4002, alive=165028289,id={-42 -48 112 17 -57
-2 73 -111 -109 113 -93 84 6 91 -72 102 }, payload={}, command={},
domain={}, ]] message. Will verify.
Dec 19, 2007 10:07:34 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://
localhost:4002,
localhost,4002, alive=165028289,id={-42
-48 112 17 -57 -2 73 -111 -109 113 -93 84 6 91 -72 102 }, payload={},
command={}, domain={}, ]]
Dec 19, 2007 10:07:34 AM
org.apache.catalina.ha.tcp.SimpleTcpCluster send
SEVERE: Unable to send message through cluster sender.
org.apache.catalina.tribes.ChannelException: Operation has timed out
(3000
ms.).; Faulty members:tcp://localhost:4002;
at
org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage
(Paral
lelNioSender.java:97)
at
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMess
age(Po
oledParallelSender.java:53)
at
org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessag
e(Repl
icationTransmitter.java:80)
at
org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage
(ChannelCoord
inator.java:78)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelI
nterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.se
ndMess
age(ThroughputInterceptor.java:61)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelI
nterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.MessageDispatchIntercept
or.sen
dMessage(MessageDispatchInterceptor.java:73)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelI
nterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendM
essage
(TcpFailureDetector.java:87)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage
(ChannelI
nterceptorBase.java:75)
at
org.apache.catalina.tribes.group.GroupChannel.send
(GroupChannel.java:216)
at
org.apache.catalina.tribes.group.GroupChannel.send
(GroupChannel.java:175)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.send
(SimpleTcpCluster.java:835)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.sendClusterDomain
(SimpleTcpClust
er.java:814)
at
org.apache.catalina.ha.session.DeltaManager.send(DeltaManager.java:
586)
at
org.apache.catalina.ha.session.DeltaManager.sendCreateSession
(DeltaManager.j
ava:575)
at
org.apache.catalina.ha.session.DeltaManager.createSession
(DeltaManager.java:
551)
at
org.apache.catalina.ha.session.DeltaManager.createSession
(DeltaManager.java:
534)
at
org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at
org.apache.catalina.connector.Request.getSession(Request.java:2075)
at
org.apache.catalina.connector.RequestFacade.getSession
(RequestFacade.java:83
3)
at pad.kernel.Resolver.service(Resolver.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(Application
FilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterCh
ain.java:206)
at pad.kernel.EntryPointFilter.doFilter
Re: trunk development
Hi Filip, good news :-) I am happy to test this features :-) Regards Peter Am 14.12.2007 um 20:53 schrieb Filip Hanik - Dev Lists: In the near future, I plan to add the following to trunk 1. annotation dependency injection patch 2. cluster JMX configurations 3. any NIO improvements that haven't been ported I've also completed a non blocking comet write implementation in sandbox, and will write some demo/sample apps to demonstrate before I suggest moving forward with it. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r603074 - /tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
+1 for that...
Peter
Am 11.12.2007 um 01:53 schrieb Filip Hanik - Dev Lists:
if String objects are kept in a constants pool, then one would
synchronized (name) {
clazz = super.findClass(name);
}
to allow concurrent loading of different classes,
Filip
[EMAIL PROTECTED] wrote:
Author: markt
Date: Mon Dec 10 14:24:40 2007
New Revision: 603074
URL: http://svn.apache.org/viewvc?rev=603074view=rev
Log:
Fix bug 44041. A small sync is required to prevent attempts to
load the same class twice.
Modified:
tomcat/trunk/java/org/apache/catalina/loader/
WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/
WebappClassLoader.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/
catalina/loader/WebappClassLoader.java?
rev=603074r1=603073r2=603074view=diff
=
=
--- tomcat/trunk/java/org/apache/catalina/loader/
WebappClassLoader.java (original)
+++ tomcat/trunk/java/org/apache/catalina/loader/
WebappClassLoader.java Mon Dec 10 14:24:40 2007
@@ -167,6 +167,11 @@
*/
boolean antiJARLocking = false; +/**
+ * Lock to prevent attempts to load duplicate classes from
external
+ * repositories.
+ */
+private Object lock = new Object();
//
---
Constructors
@@ -883,7 +888,9 @@
}
if ((clazz == null) hasExternalRepositories) {
try {
-clazz = super.findClass(name);
+synchronized (lock) {
+clazz = super.findClass(name);
+}
} catch(AccessControlException ace) {
throw new ClassNotFoundException(name, ace);
} catch (RuntimeException e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Revert to commons-pool-1.2
+1 See you a chance the commons dbcp or pool team fix the bug and we can use a newer version? Regards Peter Am 01.12.2007 um 21:24 schrieb Mark Thomas: All, The update to commons-pool-1.3 has caused a memory leak[1]. Further, [2] suggests it may cause reload issues in some circumstances. The release note [3] for commons-pool-1.3 does indicate a large number of bugs have been fixed compared to commons-pool-1.2. That said, I do not believe we upgraded to 1.3 to fix a specific Tomcat bug. Therefore, I propose we revert to commons-pool-1.2 for the next release of each version. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=43552 [2] https://issues.apache.org/jira/browse/POOL-97 [3] http://commons.apache.org/pool/release-notes-1.3.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r599767 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
I think the change is very good. Older Connection are close first!
Peter
Am 30.11.2007 um 12:56 schrieb Mladen Turk:
[EMAIL PROTECTED] wrote:
Author: rjung
Date: Fri Nov 30 02:26:42 2007
New Revision: 599767
URL: http://svn.apache.org/viewvc?rev=599767view=rev
Log:
Complete half-baked r599743. Care about signedness
and apply reverse order to the relevant loop to.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/
native/common/jk_ajp_common.c?
rev=599767r1=599766r2=599767view=diff
=
=
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
(original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Fri
Nov 30 02:26:42 2007
@@ -2607,14 +2607,15 @@
}
JK_ENTER_CS(aw-cs, rc);
if (rc) {
-unsigned int i, n = 0, cnt = 0;
+unsigned int n = 0, cnt = 0;
+int i;
/* Count open slots */
-for (i = aw-ep_cache_sz - 1; i = 0; i--) {
+for (i = (int)aw-ep_cache_sz - 1; i = 0; i--) {
Cool, much better. It removes the endless loop after all
cause unsigned is always higher or equal to zero :)
However not sure it makes any difference, bit it's as closest
as we can get to the LIFO.
Cheers,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r599259 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/authenticator/FormAuthenticator.java webapps/docs/changelog.xml
Hi Bill,
can we fix this bug also at Tomcat 5.5?
regards
Peter
Am 29.11.2007 um 05:19 schrieb [EMAIL PROTECTED]:
Author: billbarker
Date: Wed Nov 28 20:19:46 2007
New Revision: 599259
URL: http://svn.apache.org/viewvc?rev=599259view=rev
Log:
Remove conditional headers on Form Auth replay, since the UA (esp.
FireFox) isn't expecting it.
Fix for bug #43687
Reported by: Przemyslaw Madzik
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/
FormAuthenticator.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?
rev=599259r1=599258r2=599259view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Nov 28 20:19:46 2007
@@ -31,11 +31,6 @@
+1: jfclere
-1: fhanik - Can we add the 'package' directive to make the
package match the dir structure
-* Remove conditional headers on Form Auth replay, since the UA
(esp. FireFox) isn't expecting it.
- http://issues.apache.org/bugzilla/show_bug.cgi?id=43687
- +1: billbarker, remm, jfclere, pero
- -1:
-
* Fix another license issue
http://svn.apache.org/viewvc?rev=598412view=rev
+1: markt, fhanik, pero, remm, billbarker
Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/
authenticator/FormAuthenticator.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/
apache/catalina/authenticator/FormAuthenticator.java?
rev=599259r1=599258r2=599259view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/
FormAuthenticator.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/
FormAuthenticator.java Wed Nov 28 20:19:46 2007
@@ -402,12 +402,20 @@
MimeHeaders rmh = request.getCoyoteRequest().getMimeHeaders
();
rmh.recycle();
+boolean cachable = GET.equalsIgnoreCase(saved.getMethod
()) ||
+ HEAD.equalsIgnoreCase(saved.getMethod
());
Iterator names = saved.getHeaderNames();
while (names.hasNext()) {
String name = (String) names.next();
-Iterator values = saved.getHeaderValues(name);
-while (values.hasNext()) {
-rmh.addValue(name).setString( (String)values.next
() );
+// The browser isn't expecting this conditional
response now.
+// Assuming that it can quietly recover from an
unexpected 412.
+// BZ 43687
+if(!(If-Modified-Since.equalsIgnoreCase(name) ||
+ (cachable If-None-Match.equalsIgnoreCase
(name {
+Iterator values = saved.getHeaderValues(name);
+while (values.hasNext()) {
+rmh.addValue(name).setString( (String)
values.next() );
+}
}
}
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/
changelog.xml?rev=599259r1=599258r2=599259view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Wed Nov 28
20:19:46 2007
@@ -72,6 +72,9 @@
Improve the webDAV Servlet Javadocs to make clear that the
WebDAV
Servlet can not be used as the default servlet. (markt)
/update
+ fixbug43687/bug Remove conditional headers on Form
Auth replay,
+ since the UA (esp. FireFox) isn't expecting it.
+ /fix
/changelog
/subsection
subsection name=Jasper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Life Cycle of Authenticator in Tomcat
Hi, you can find the current implemenation at package org.apache.catalina.authenticator. You can implement you own auth strategie as a context Valve. Context Valve className=xx.yyy.zzz / /Context Your class must be implement the o.a.c.Authenticator interface. Please, look at o.a.c.a.AuthenticatorBase base auth class. Regards Peter Am 21.11.2007 um 13:59 schrieb Carlo Politi: Good day, I'm doing a thesis about the creation of a new kind of authenticator for Tomcat. I'd like to know which is the life cycle of an authenticator, what happens when an authenticator returns true or false, what kind of module invokes an authenticator. I hope someone can helps me. Thanks ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Life Cycle of Authenticator in Tomcat
Hi Carlo, Look at BasicAuthenticator true means its OK false means something is wrong. Peter Am 21.11.2007 um 17:41 schrieb Carlo Politi: Hi Peter, I have implemented o.a.c.a.AuthenticatorBase but my question was related at knowing what happens when an authenticator exits and returns true and/or false... I suppose that if true means all ok and the user is authenticated but i wanted to be sure - Messaggio originale - Da: Peter Rossbach [EMAIL PROTECTED] A: Tomcat Developers List dev@tomcat.apache.org Inviato: Mercoledì 21 novembre 2007, 17:32:45 Oggetto: Re: Question about Life Cycle of Authenticator in Tomcat Hi, you can find the current implemenation at package org.apache.catalina.authenticator. You can implement you own auth strategie as a context Valve. Context Valve className=xx.yyy.zzz / /Context Your class must be implement the o.a.c.Authenticator interface. Please, look at o.a.c.a.AuthenticatorBase base auth class. Regards Peter Am 21.11.2007 um 13:59 schrieb Carlo Politi: Good day, I'm doing a thesis about the creation of a new kind of authenticator for Tomcat. I'd like to know which is the life cycle of an authenticator, what happens when an authenticator returns true or false, what kind of module invokes an authenticator. I hope someone can helps me. Thanks ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive http://it.messenger.yahoo.com
Re: svn commit: r595376 - /tomcat/current/tc5.5.x/STATUS
Strange, but with Revision 586865 I have test with the link and check in the JDT 3.3.1 change at 27.10.07 Peter Am 15.11.2007 um 20:04 schrieb Filip Hanik - Dev Lists: jean-frederic clere wrote: [EMAIL PROTECTED] wrote: Author: pero Date: Thu Nov 15 09:58:26 2007 New Revision: 595376 URL: http://svn.apache.org/viewvc?rev=595376view=rev Log: Add JDT Location change Modified: tomcat/current/tc5.5.x/STATUS Modified: tomcat/current/tc5.5.x/STATUS URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS? rev=595376r1=595375r2=595376view=diff == --- tomcat/current/tc5.5.x/STATUS (original) +++ tomcat/current/tc5.5.x/STATUS Thu Nov 15 09:58:26 2007 @@ -50,3 +50,10 @@ http://people.apache.org/~markt/patches/2007-10-28-cookies- tc5.patch +1: markt -1: + +* JDT location return 404 + http://people.apache.org/~fhanik/patches/jdt-loc.patch + Backport from Tomcat 6 + +1: pero + -1: + Well I don't see the need to change it there. The location is http://archive.eclipse.org/eclipse/downloads/drops/ R-3.1.2-200601181600/eclipse-JDT-3.1.2.zip and it is still valid. the question with TC 5.5 is simply whether we want to upgrade to a later version of the JDT compiler for the next release Filip Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Hi Test Comet NIO API, Cluster and NIO Connector. Also 6.015 work fine with mod:jk 1.2.25 via AJP. Peter Am 05.11.2007 um 15:17 schrieb Rémy Maucherat: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [x ] Stable Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are Sticky Sessions really necessary?
Hi, It is not only ineffizient and a risk, Read 7.7.2 at the spec: SRV.7.7.2 Distributed Environments Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine1 (“JVM”) at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately. regards Peter Am 02.11.2007 um 22:37 schrieb Len Popp: You can indeed use session replication without sticky sessions, and the session data will be copied to all the Tomcat servers. However it may be inefficient. You probably have to use synchronous replication to ensure the session data is consistent across the cluster, which adds latency to the requests. And there could be a lot of extra network traffic in the cluster if it's busy (which it is, otherwise you wouldn't be doing load balancing). (I haven't used session replication in a high-load situation. Maybe someone else can tell us how well it works.) -- Len On 11/2/07, Stephen Wick [EMAIL PROTECTED] wrote: The Tomcat 5.5 Clustering/Session Replication Guide says, Make sure that your loadbalancer is configured for sticky session mode. However, I don't see the term Sticky sessions anywhere in the Servlet 2.3 or 2.4 specifications. Are sticky sessions really required for clustering to function properly in Tomcat 5.5? I thought that session replication would eliminate any need to direct a client session to one node in a cluster. If not, can we adjust the documentation to indicate that Sticky sessions are optional, for the appropriate reason (I'm guessing the advent of session replication in tomcat.) I am asking this question because I am having trouble with Sticky sessions in my load balancer, and I need to know whether or not I should pursue fixing this feature. If tomcat doesn't really require sticky sessions, then I can leave my load balancer alone. If tomcat does need the feature to function properly, then I need to go to some additional expense to resolve the issue with my load balancing appliance. Thank you for your time and expertise. Stephen Wick Interactive Developer Nicholson Kovac, Inc. References http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn - Take 3
Good point +1 Peter Am 01.11.2007 um 09:51 schrieb jean-frederic clere: Mark Thomas wrote: Mark Thomas wrote: svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 https://svn.apache.org/repos/asf/tomcat/trunk Changes to .../trunk with be CTR Changes to .../6.1.x/trunk will be RTC As per the previously published plan, I will create tomcat/tc6.1.x/ trunk and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on Friday afternoon GMT. Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable? Cheers Jean-Frederic Any commits to 6.0.x/trunk between now and then I will apply using CTR to trunk. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag
Hi, I read the status and changelog reference and think the are not reflect the 6.0.15 status! Peter Am 01.11.2007 um 02:58 schrieb Rémy Maucherat: On Mon, 2007-10-29 at 23:26 +0100, Rémy Maucherat wrote: Hi, As the issue list seems relatively empty, I would like to tag 6.0.15 soon, probably late tomorrow. The binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag
Hi, Before we tag, can we add the missing author hints at changelog, please :-( Peter Am 30.10.2007 um 05:52 schrieb Peter Rossbach: +1 Am 29.10.2007 um 23:26 schrieb Rémy Maucherat: Hi, As the issue list seems relatively empty, I would like to tag 6.0.15 soon, probably late tomorrow. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag
+1 Am 29.10.2007 um 23:26 schrieb Rémy Maucherat: Hi, As the issue list seems relatively empty, I would like to tag 6.0.15 soon, probably late tomorrow. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] - Catalina Ant JMX?
Hi Paul, please open a bug! Peter Am 23.10.2007 um 15:46 schrieb Paul Shemansky: While browsing the project, I noticed that there is an unused separation of Catalina Ant JMX resources. If this was unintended, a possible cleanup patch is attached. tomcat-unused-property-patch.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What would you like to improve in Tomcat?
HI Lucas, look like a very great plan. I also think about better JMX support and management console to muliple tomcat instances. Please let us start the discussion, about your ideas. regards Peter Personal hint: Start with simple changes, first! I like your zero bug count idea... Am 21.10.2007 um 09:30 schrieb Lucas Galfaso: Hi all, I would like to know what are the main things you would like to improve in Tomcat. This is a small (and clearly incomplete) of some of the possible things to improve: - Improve JMX support. - Improve the admin console. - Have close-to-zero bugs in bugzilla. - Build a continuous build/test system (sorry if there is one that I am not aware of.) - Improve the documentation. - Implement the SIP servlet spec. - Compliance to spec XXX/RFC YYY, implement spec XXX/RFC YYY optional part ZZZ. - Improve the performance. - Use Java 5 coding style throwout Tomcat. Thanks, lg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Move Tomcat 5.0.x to the archive
+1 Great! peter Am 19.10.2007 um 01:34 schrieb Mark Thomas: All, I would like to propose that we have reached the time where Tomcat 5.0.x should be archived. What this means in practice is: - Sending an announcement out that no further work, including security patches will be performed on 5.0.x. Current 5.0.x users are encouraged to upgrade to 5.5.x or, ideally, 6.0.x - Removing the 5.0.x docs from the web site - Removing 5.0.x from the 5.5.x download pages (and hence the mirrors) - Adding a note to the 5.5.x download pages that 5.0.x can be obtained from the archives - Moving the relevant tags and branches in svn to /tomcat/archive/ tc5.0.x - Reviewing all 5.0.x bugs in bugzilla and closing them as WONTFIX or changing the version to 5.5.x Have I forgotten anything? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r586444 - /tomcat/tc6.0.x/trunk/STATUS
Hi Filip, can you please add your last changes also to the changelog.xml? Regards Peter Am 19.10.2007 um 15:35 schrieb [EMAIL PROTECTED]: Author: fhanik Date: Fri Oct 19 06:35:38 2007 New Revision: 586444 URL: http://svn.apache.org/viewvc?rev=586444view=rev Log: update status file Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=586444r1=586443r2=586444view=diff == --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Fri Oct 19 06:35:38 2007 @@ -63,11 +63,6 @@ This way the error exit stays the last case which seems more natural. -* Add a working ANT script that signs and publishes JARs to a maven repo - http://people.apache.org/~fhanik/patches/maven-publish.patch - +1: fhanik, yoavs, markt - -1: - * Final fixes to the Cookie handling. This makes sure that we unescape any value that has been quoted and ensures the unescaping is the exact reverse of the escaping. This patch also tidies up ServerCookie to make it clearer what - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS
Hi Remy, but is'nt /usr/lib/java the correct value to JRE_HOME ? Regards Peter Am 17.10.2007 um 13:10 schrieb Rémy Maucherat: On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote: Hi Remy, I think the patch is incomplete this line seem not correct: +else + JRE_HOME=/usr +fi better +else + JRE_HOME=/usr/bin/java +fi The path to the Java executable is $JRE_HOME/bin/java, so /usr is the correct value. However, on older distributions (just tested with my F7), it will also pick up gij if it is installed (it does not really work). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS
+1 for that env variable, but also autodetection must be implemented Peter Am 17.10.2007 um 13:28 schrieb Tim Funk: There was a request in bugzilla to pass in a new env variable called JAVA_EXE (or similar). Could that be an acceptable alternative? Then it would make the bug submitter happy since he can symlink my_program_that_i_can_see_in_ps to java. -Tim Rémy Maucherat wrote: On Wed, 2007-10-17 at 05:47 +0200, Peter Rossbach wrote: Hi Remy, I think the patch is incomplete this line seem not correct: +else + JRE_HOME=/usr +fi better +else + JRE_HOME=/usr/bin/java +fi The path to the Java executable is $JRE_HOME/bin/java, so /usr is the correct value. However, on older distributions (just tested with my F7), it will also pick up gij if it is installed (it does not really work). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?
Yes! I can't see that maven build is better choice. Peter Vote -1 for build with maven! Am 18.10.2007 um 00:45 schrieb Mark Thomas: Paul Shemansky wrote: Key features that may be useful to us are : - The Standard Directory Layout - Specifically, multi-module builds. This might make managing individual components easier for catalina, coyote, naming, jsp/servlet api/implementation, connector, etc. might isn't a compelling argument. - Model-Based builds - Automatic packaging for the individual modules. Our build script does this. - Dependency Management - Whether it is Apache or another third- party, dependencies can all easily be plugged in. There are only a few and they are easily managed with the current build process. - Distribution Management - Packaging and Deployment - Although Tomcat has a structured distribution model with Ant, Maven could make this easier with its assembly plugin. This also allows outside entities to easily embed specific Tomcat components or customize the server to suit their needs, (i.e. containers like Geronimo and JBoss, IDE plugins for Eclipse or Tomcat.) Easier how? - Project Site and Report Generation. - The Tomcat documentation site may benefit greatly, but the Maven reporting plugins seem to be the bigger win here. May isn't compelling. What reporting? What do we get that we want to get don't currently? As a new ASF / Tomcat contributor, I am hesitant to step on toes. But, I vote that we eat the dog food. This migration would certainly be something that I could dedicate myself to, and I believe I could make the transition seamless for all of us. I look forward to hearing from you. Whether you vote Yes or No, I am still happy to be working with you. :) Overall -1. I just don't see the point. The current process is nice and simple and works. If it ain't broke... Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS
Hi Remy, I think the patch is incomplete this line seem not correct: +else + JRE_HOME=/usr +fi better +else + JRE_HOME=/usr/bin/java +fi Peter Am 17.10.2007 um 03:11 schrieb [EMAIL PROTECTED]: Author: remm Date: Tue Oct 16 18:11:39 2007 New Revision: 585313 URL: http://svn.apache.org/viewvc?rev=585313view=rev Log: - Propose a shell script update. Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=585313r1=585312r2=585313view=diff == --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Tue Oct 16 18:11:39 2007 @@ -54,5 +54,32 @@ * Fix property setter for keystore type http://issues.apache.org/bugzilla/show_bug.cgi?id=43634 - +1: fhanik,funkman + +1: fhanik,funkman,remm + -1: + +* IcedTea support. Upcoming Linux distributions will package a (working) open source JRE, + available in /usr. As a result, it could now be possible to use a /usr/bin/java binary + if one is present and expect results. [tested on Fedora 8 test 3] + +--- bin/setclasspath.sh(revision 585189) bin/setclasspath.sh(working copy) +@@ -30,9 +30,13 @@ + if $darwin [ -d /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home ]; then + export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home + else +-echo Neither the JAVA_HOME nor the JRE_HOME environment variable is defined +-echo At least one of these environment variable is needed to run this program +-exit 1 ++if [ ! -x /usr/bin/java ]; then ++ echo Neither the JAVA_HOME nor the JRE_HOME environment variable is defined ++ echo At least one of these environment variable is needed to run this program ++ exit 1 ++else ++ JRE_HOME=/usr ++fi + fi + fi + if [ -z $JAVA_HOME -a $1 = debug ]; then + + +1: -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS
OK! How we can easier promote and discuss those patches? You are right, an email threads are not easy to reference at STATUS file. Arrg! I don't think that the apache developer home folder are the right place for those patches! Open a bug report for every possible change is also not a good solution. But other people can add there comments and ideas. Every hint to a standard procedure? Peter PS: Can we move the tomcat 5.5 STATUS file to the build project? Then it was easier for me to change the file at my eclipse. Am 08.10.2007 um 17:13 schrieb Filip Hanik - Dev Lists: I did, but folks shouldn't have to dig through the dev archives, should they :) Filip Peter Rossbach wrote: Hi Filip, has you seen my Call stopAwait at StandardServer.stop mail? Peter Am 07.10.2007 um 17:10 schrieb Filip Hanik - Dev Lists: don't forget to include a link to the diff file, so that it can be reviewed before committed, just in case someone misses the dev email Filip [EMAIL PROTECTED] wrote: Author: pero Date: Sun Oct 7 01:36:51 2007 New Revision: 582597 URL: http://svn.apache.org/viewvc?rev=582597view=rev Log: add change request: call StandardServer stopAwait Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=582597r1=582596r2=582597view=diff === === --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Sun Oct 7 01:36:51 2007 @@ -44,4 +44,7 @@ update to jdt.loc=http://sunsite.informatik.rwth-aachen.de/ eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip +1: pero -1: - \ No newline at end of file + +* Call StopAwait at StandardServer.stop as port==-1 + +1: pero + -1: --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Call stopAwait at StandardServer.stop
Hi,
I have reviewed Catalina and StandardServer Tomcat 6 implementation.
I can see that the old trick with Server port=-1 ... doesn´t work
correct. The main thread is not terminate after a stop signal was
received.
With port=-1 setting a user can start a tomcat without opening a
shutdown port. Ok, the only chance to stop a tomcat instance
is to send a signal to the jvm process, but the stopAwait flag at
StandardServer doesn't trigger.
Catalina.stop ...
// Shut down the server
if (server instanceof Lifecycle) {
try {
((Lifecycle) server).stop();
} catch (LifecycleException e) {
log.error(Catalina.stop, e);
}
}
calls only StandardServer stop, but stop doesn't trigger the
stopAwait flag
public void stop() throws LifecycleException {
// Validate and update our current component state
if (!started)
return;
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENT, null);
lifecycle.fireLifecycleEvent(STOP_EVENT, null);
started = false;
// Stop our defined Services
for (int i = 0; i services.length; i++) {
if (services[i] instanceof Lifecycle)
((Lifecycle) services[i]).stop();
}
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);
}
can we please fix it:
public void stop() throws LifecycleException {
// Validate and update our current component state
if (!started)
return;
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENT, null);
lifecycle.fireLifecycleEvent(STOP_EVENT, null);
started = false;
// Stop our defined Services
for (int i = 0; i services.length; i++) {
if (services[i] instanceof Lifecycle)
((Lifecycle) services[i]).stop();
}
// == FIX BEGIN
if(port == -1)
stopAwait() ;
// == END
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);
}
I think we can also backport it to Tomcat 5.5 trunk
regards
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commit policy for native Tomcat connectors
Hi Rainer, I think we need a clear policy for all tomcat parts. Currently this means that we must also change the commit policy for jk and tcnative. Peter Am 01.10.2007 um 15:46 schrieb Rainer Jung: Hi, since the main project agreed on trying a new policy for commits against stable branches, I think we should clarify our policy concerning the native parts of Tomcat connectors (JK and tcnative). Both have only one active branch, which at the moment is the stable branch as well as the development branch. The primary purpose of the commit policy is helping to interact the comitters in a way, that provides a good balance between innovation and stability. The group of committers for the two native projects has a different structure than the main Tomcat project. I think that until now we didn't have any incidents that indicate, that we should switch to a new policy for the native projects. It's possible, that this will be necessary, once development for JK3 really starts, in order to concentrate our efforts on the new branch. I would like to gather opinions from the group concerning the momentary situation: - do you also think we can stick to CTR for - JK native? - tcnative? I don't expect a lot of change for JK 1.2 (new features) and I think we'll switch over to JK3 for all major new features. But since we didn't have a problem with CTR on JK 1.2, I would prefer sticking to that (for simplicity). Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS
Hi Filip, has you seen my Call stopAwait at StandardServer.stop mail? Peter Am 07.10.2007 um 17:10 schrieb Filip Hanik - Dev Lists: don't forget to include a link to the diff file, so that it can be reviewed before committed, just in case someone misses the dev email Filip [EMAIL PROTECTED] wrote: Author: pero Date: Sun Oct 7 01:36:51 2007 New Revision: 582597 URL: http://svn.apache.org/viewvc?rev=582597view=rev Log: add change request: call StandardServer stopAwait Modified: tomcat/tc6.0.x/trunk/STATUS Modified: tomcat/tc6.0.x/trunk/STATUS URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? rev=582597r1=582596r2=582597view=diff = = --- tomcat/tc6.0.x/trunk/STATUS (original) +++ tomcat/tc6.0.x/trunk/STATUS Sun Oct 7 01:36:51 2007 @@ -44,4 +44,7 @@ update to jdt.loc=http://sunsite.informatik.rwth-aachen.de/ eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip +1: pero -1: - \ No newline at end of file + +* Call StopAwait at StandardServer.stop as port==-1 + +1: pero + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update build.properties.default for new JDT URL
OK, I add this to the tomcat 5.5 STATUS file :-) Peter Am 07.10.2007 um 19:42 schrieb William L. Thomson Jr.: On Sun, 2007-10-07 at 07:14 +0200, Peter Rossbach wrote: Thanks to report it, I hope we can fix it before 6.0.15 tag. FYI, this can likely be done for 5.5.x as well. On Gentoo we are presently shipping/compiling 5.5.25 with 3.3. 6.0.x is still using 3.2, but I will bump that next time I touch package or ebuild. -- William L. Thomson Jr. Gentoo/Java
Re: Time to organise svn
HI, what I miss is the bundle of the following include xsd:include schemaLocation=javaee_5.xsd / The file is reference at web-jsptaglibrary_2_1.xsd and web-app_2_5.xsd. Can it be that schemaResolver at o.a.c.startup.DigesterFactory must be also registered all included xml schemas for standalone resolving? Original schema files at http://java.sun.com/xml/ns/javaee has the CDDL lisence and we must bundle the glassfish/bootstrap/legal/LICENSE.txt and must be reference it at the NOTICE file. regards Peter Am 06.10.2007 um 22:08 schrieb Mark Thomas: Remy Maucherat wrote: Mark Thomas wrote: Next attempt. Taking account of the comments so far, a slightly modified proposal is below. svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk https://svn.apache.org/repos/asf/tomcat/trunk svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/ TOMCAT_6_0_14 https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk Instead, I would propose to tag a new 6.0.15 candidate first. Remy, Please can you fix the following files that are not currently AL2 licenced before the tag. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/javax/ servlet/jsp/resources/jsp_2_1.xsd http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/javax/ servlet/jsp/resources/web-jsptaglibrary_2_1.xsd These originated with this commit: http://svn.apache.org/viewvc?view=revrevision=481296 If the source was such that the Sun license can be removed and an AL2 one inserted, great. If not, we can use the CDDL ones. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update build.properties.default for new JDT URL
Thanks to report it, I hope we can fix it before 6.0.15 tag. Peter Am 06.10.2007 um 19:59 schrieb Jason Brittain: +jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/ drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
Re: Time to organise svn
++1 Am 05.10.2007 um 14:07 schrieb Remy Maucherat: Mark Thomas wrote: Next attempt. Taking account of the comments so far, a slightly modified proposal is below. svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk https://svn.apache.org/repos/asf/tomcat/trunk svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/ TOMCAT_6_0_14 https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk Instead, I would propose to tag a new 6.0.15 candidate first. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error while starting up the Tomcat server
It seems an Axis bug. Please, use the aixs oder tomcat user list for those reports. Regards Peter Am 04.10.2007 um 09:30 schrieb Nagasree: I am using Tomcat 5.0.28 and Axis 1.4. When I start the tomcat server I see the following error on the console. INFO: Server startup in 9844 ms - Failed to update soap:address location URL(s) in WSDL. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java: 448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at org.apache.axis.description.JavaServiceDesc.getSyncedOperationsForName (JavaServiceDesc.java:1095) at org.apache.axis.description.JavaServiceDesc.loadServiceDescByIntrospec tionRecursive(JavaServiceDesc.java:962) at org.apache.axis.description.JavaServiceDesc.loadServiceDescByIntrospec tion(JavaServiceDesc.java:896) at org.apache.axis.providers.java.JavaProvider.initServiceDesc (JavaProvider.java:477) at org.apache.axis.handlers.soap.SOAPService.getInitializedServiceDesc (SOAPService.java:286) at org.apache.axis.deployment.wsdd.WSDDService.makeNewInstance (WSDDService.java:500) at org.apache.axis.deployment.wsdd.WSDDDeployment.getDeployedServices (WSDDDeployment.java:503) at org.apache.axis.configuration.FileProvider.getDeployedServices (FileProvider.java:296) at org.apache.axis.transport.http.QSWSDLHandler.getDeployedServiceNames (QSWSDLHandler.java:218) at org.apache.axis.transport.http.QSWSDLHandler.updateSoapAddressLocation URLs(QSWSDLHandler.java:153) at org.apache.axis.transport.http.QSWSDLHandler.invoke (QSWSDLHandler.java:72) 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:324) at org.apache.axis.transport.http.AxisServlet.processQuery (AxisServlet.java:1226) at org.apache.axis.transport.http.AxisServlet.doGet(AxisServlet.java:249) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 689) at org.apache.axis.transport.http.AxisServletBase.service (AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java: 160) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) How do I fix this? -Nagasree -- View this message in context: http://www.nabble.com/Error-while- starting-up-the-Tomcat-server-tf4566282.html#a13034043 Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: mod_jk balancer and failure detection
Hi, Look at Java Service Wrapper project. I think you can extend there logging trigger filter API. http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html As you detect the OME then you can use the jkstatus mod_jk interface to deactivate the worker from list. http://tomcat.apache.org/connectors-doc/reference/status.html I don't see that a real jvm hook exists for OME's. Please, use the user list for those questions first. Thanks Peter Am 04.10.2007 um 09:45 schrieb Giampaolo Capelli: hi there everyone, I'm new to the list. I would like mod_jk to detect when the Tomcat JVM got into an OutOfMemoryException so that mod_jk avoid to forward request to that Tomcat. If I'm not wrong, it could happen that the mod_jk balancer forward a request to a JVM in such a state, since the mod_jk isn't able to recognize as crashed a Tomcat in OutOfMemory. I would like to write a patch for the mod_jk to add such feature, but I don't know the code at all, could someone get me introduced to it? Any suggestions? Mini how-to? Support? I would appreciate them so much and I promise to try any attempt to add this feature, if I can figure out how things work in the mod_jk core and in its load_balancer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Hi, I vote +1 :-) Peter Am 26.09.2007 um 16:22 schrieb Jim Jagielski: I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some grainy aspects better defined. In essence, some typical niceties are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. Looks like the 96 hours are up, and the tally is: +1: jim, yoav, tim, remy, costin, filip, mark, mladen, jean-frederic, rainer Not Sure: Peter followed up: I agree with Remy: We must find a process that really work normally quick and can handle conflicts fair. Henri +1'ed Peter's post. So I am not sure if Peter actually cast a vote or simply made a comment and I'm not sure if Henri +1'ed the proposal or Peter's comment or both. -1: null set As such, the vote passes!! We can now give ourselves a pat on the back for resolving this and start implementing the changes we approved... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
[X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: I agree with Remy: We must find a process that really work normally quick and can handle conflicts fair. Peter Am 23.09.2007 um 11:09 schrieb Remy Maucherat: Mark Thomas wrote: Jim Jagielski wrote: With the following caveats: - There is only one dev branch. I am -1 for creating separate dev branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much overhead for branches that are in maintenance mode where 99% of the patches will be ported from 6.x - Where a patch for 3, 4 or 5 is required that just doesn't make sense in the dev branch then the patch is applied using RTC. - We review this process in 3 months time to see if it is providing the expected benefits without excessive overheads. - We improve the Which version? web page to make clear which branches are supported and at what level. I'll start a wiki page as a draft of this. - The Get involved pages are updated to document this process Some points of my own: - I think my proposed process was more adapted to the Tomcat situation - The way Jim rushed his vote seems to shortcut any possibility of me to present a vote at the moment (which is fairly annoying as I spent weeks discussing details and integrating changes) - I am not aware of any ASF rule specifying that a project cannot define its own release process Since it does most of what I suggested and there was no this will not be changeable through further discussions and votes, I did vote in favor of it. I would be willing to revisit it later since I doubt it is well suited to the size of the Tomcat community and the way it works. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r575798 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProtocol.java tomcat/util/net/NioEndpoint.java
HI Filip,
can you please add your changes at changelog.xml (BUG 43356)
Peter
Am 14.09.2007 um 23:30 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Fri Sep 14 14:30:29 2007
New Revision: 575798
URL: http://svn.apache.org/viewvc?rev=575798view=rev
Log:
Backport from earlier fix
http://issues.apache.org/bugzilla/show_bug.cgi?id=43356
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProtocol.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/
apache/coyote/http11/Http11NioProtocol.java?
rev=575798r1=575797r2=575798view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProtocol.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/
Http11NioProtocol.java Fri Sep 14 14:30:29 2007
@@ -547,17 +547,25 @@
public String getAlgorithm() { return ep.getAlgorithm();}
public void setAlgorithm(String s ) { ep.setAlgorithm(s);}
-public boolean getClientAuth() { return ep.getClientAuth();}
-public void setClientAuth(boolean b ) { ep.setClientAuth(b);}
+public void setClientauth(String s) {setClientAuth(s);}
+public String getClientauth(){ return getClientAuth();}
+public String getClientAuth() { return ep.getClientAuth();}
+public void setClientAuth(String s ) { ep.setClientAuth(s);}
public String getKeystorePass() { return ep.getKeystorePass();}
public void setKeystorePass(String s ) { ep.setKeystorePass(s);}
public void setKeypass(String s) { setKeystorePass(s);}
public String getKeypass() { return getKeystorePass();}
-
-
public String getKeystoreType() { return ep.getKeystoreType();}
public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
+
+public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
+public String getTruststoreFile(){return ep.getTruststoreFile();}
+public void setTruststorePass(String p){ep.setTruststorePass(p);}
+public String getTruststorePass(){return ep.getTruststorePass();}
+public void setTruststoreType(String t){ep.setTruststoreType(t);}
+public String getTruststoreType(){ return ep.getTruststoreType
();}
+
public String getSslProtocol() { return ep.getSslProtocol();}
public void setSslProtocol(String s) { ep.setSslProtocol(s);}
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/
apache/tomcat/util/net/NioEndpoint.java?
rev=575798r1=575797r2=575798view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/
NioEndpoint.java Fri Sep 14 14:30:29 2007
@@ -527,20 +527,50 @@
}
+public String adjustRelativePath(String path, String
relativeTo) {
+File f = new File(path);
+if ( !f.isAbsolute()) {
+path = relativeTo + File.separator + path;
+f = new File(path);
+}
+if (!f.exists()) {
+log.warn(configured file:[+path+] does not exist.);
+}
+return path;
+}
+
+public String defaultIfNull(String val, String defaultValue) {
+if (val==null) return defaultValue;
+else return val;
+}
// SSL related properties
+protected String truststoreFile = System.getProperty
(javax.net.ssl.trustStore);
+public void setTruststoreFile(String s) {
+s = adjustRelativePath(s,System.getProperty
(catalina.base));
+this.truststoreFile = s;
+}
+public String getTruststoreFile() {return truststoreFile;}
+protected String truststorePass = System.getProperty
(javax.net.ssl.trustStorePassword);
+public void setTruststorePass(String truststorePass)
{this.truststorePass = truststorePass;}
+public String getTruststorePass() {return truststorePass;}
+protected String truststoreType = System.getProperty
(javax.net.ssl.trustStoreType);
+public void setTruststoreType(String truststoreType)
{this.truststoreType = truststoreType;}
+public String getTruststoreType() {return truststoreType;}
+
protected String keystoreFile = System.getProperty(user.home)
+/.keystore;
public String getKeystoreFile() { return keystoreFile;}
-public void setKeystoreFile(String s ) { this.keystoreFile = s; }
-public void setKeystore(String s ) { setKeystoreFile(s);}
-public String getKeystore() { return getKeystoreFile();}
+public void setKeystoreFile(String s ) {
+s = adjustRelativePath(s,System.getProperty
(catalina.base));
+this.keystoreFile = s;
+}
