Re: "Critical poller failure" when using tcnative

[Peter Rossbach]

Can you send me a simple testcase, then I can check it.

Cheers
Peter

Am 10.04.2006 um 23:14 schrieb Jean-frederic Clere:


Remy Maucherat wrote:


Mladen Turk wrote:

Right. I was hoping to have the native release by the end of the  
week

also. Since installer depends on outside natives, the native should
be out before the 5.5.17.



That's a good idea.


There are some small issues with some compile warnings for MacOSX,
but nothing critical.



Jean-Frédéric said it was a cast problem.


If sizeof(apr_os_thread_t) == sizeof(unsigned long) then no  
problem, if not there is a problem.
I don't have access to a MacOSX machine for the moment so I can't  
check it.


Cheers

Jean-Frédéric



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]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Critical poller failure" when using tcnative

[Peter Rossbach]

+1, good time to build a next release, some off my customers see the  
pooler message :-)


Peter

Am 10.04.2006 um 16:17 schrieb Yoav Shapira:


Hola,

I just looked at the changelog, and the EINTR status code fix was  
post
5.5.16 (it will be included in 5.5.17), so at least things are  
fairly
logical :) So you would need to either patch 5.5.16, or use  
tcnative HEAD.


Thanks Rémy & Mladen, that worked.


I'm ready to do a 5.5.17 later this week, if the other committers
think this is a decent time.

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]

svn commit: r393198 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java

[remm]

Author: remm
Date: Tue Apr 11 05:17:19 2006
New Revision: 393198

URL: http://svn.apache.org/viewcvs?rev=393198&view=rev
Log:
- Update version number.

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java?rev=393198&r1=393197&r2=393198&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
 Tue Apr 11 05:17:19 2006
@@ -52,7 +52,7 @@
 
 protected static final int REQUIRED_MAJOR = 1;
 protected static final int REQUIRED_MINOR = 1;
-protected static final int REQUIRED_PATCH = 2;
+protected static final int REQUIRED_PATCH = 3;
 
 
 // -- LifecycleListener Methods



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393199 - in /tomcat/build/tc5.5.x: build.properties.default tomcat.nsi

[remm]

Author: remm
Date: Tue Apr 11 05:17:55 2006
New Revision: 393199

URL: http://svn.apache.org/viewcvs?rev=393199&view=rev
Log:
- New tcnative version numbers and locations.

Modified:
tomcat/build/tc5.5.x/build.properties.default
tomcat/build/tc5.5.x/tomcat.nsi

Modified: tomcat/build/tc5.5.x/build.properties.default
URL: 
http://svn.apache.org/viewcvs/tomcat/build/tc5.5.x/build.properties.default?rev=393199&r1=393198&r2=393199&view=diff
==
--- tomcat/build/tc5.5.x/build.properties.default (original)
+++ tomcat/build/tc5.5.x/build.properties.default Tue Apr 11 05:17:55 2006
@@ -142,9 +142,9 @@
 
 
 # - Tomcat native library -
-tomcat-native.home=${base.path}/tomcat-native-1.1.2
+tomcat-native.home=${base.path}/tomcat-native-1.1.3
 tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
-tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.2.tar.gz
+tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.3.tar.gz
 
 
 # --

Modified: tomcat/build/tc5.5.x/tomcat.nsi
URL: 
http://svn.apache.org/viewcvs/tomcat/build/tc5.5.x/tomcat.nsi?rev=393199&r1=393198&r2=393199&view=diff
==
--- tomcat/build/tc5.5.x/tomcat.nsi (original)
+++ tomcat/build/tc5.5.x/tomcat.nsi Tue Apr 11 05:17:55 2006
@@ -203,11 +203,11 @@
 
   SectionIn 3
 
-  NSISdl::download /TIMEOUT=3 
http://tomcat.heanet.ie/native/1.1.2/binaries/win32/tcnative-1.dll 
$INSTDIR\bin\tcnative-1.dll
+  NSISdl::download /TIMEOUT=3 
http://tomcat.heanet.ie/native/1.1.3/binaries/win32/tcnative-1.dll 
$INSTDIR\bin\tcnative-1.dll
   Pop $0
   StrCmp $0 success success
 SetDetailsView show
-DetailPrint "download failed from 
http://tomcat.heanet.ie/native/1.1.2/binaries/win32/tcnative-1.dll: $0"
+DetailPrint "download failed from 
http://tomcat.heanet.ie/native/1.1.3/binaries/win32/tcnative-1.dll: $0"
   success:
 
   ClearErrors



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml

[Remy Maucherat]

Costin Manolache wrote:

What about: keep them excluded in the build target for tomcat, but add a
separate target to build only javamail-dependent classes, and package them in
a separate jar.

That would keep 'core' tomcat clean, and would work for other kind of
modules that have external deps.

It would be even better if we could just move them in a separate
package - for example
org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
core build. Everything that will have external deps, and maybe things
that are not essential could go there.


This is a possibility, but maybe there are solutions in this particular 
case.


For example, I can either add my dummy classes, or a svn link could be 
created to 
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail

(and activation too)

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393216 - /tomcat/container/tc5.5.x/catalina/src/conf/server.xml

[pero]

Author: pero
Date: Tue Apr 11 06:43:09 2006
New Revision: 393216

URL: http://svn.apache.org/viewcvs?rev=393216&view=rev
Log:
Default is false, but pooled need true!

Modified:
tomcat/container/tc5.5.x/catalina/src/conf/server.xml

Modified: tomcat/container/tc5.5.x/catalina/src/conf/server.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/conf/server.xml?rev=393216&r1=393215&r2=393216&view=diff
==
--- tomcat/container/tc5.5.x/catalina/src/conf/server.xml (original)
+++ tomcat/container/tc5.5.x/catalina/src/conf/server.xml Tue Apr 11 06:43:09 
2006
@@ -303,7 +303,8 @@
 
+ackTimeout="15000"
+waitForAck="true"/>
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache Tomcat Bundle

[Robert Locklear]

Hello All,

 

I originally post this message on the users list and some one mentioned
this would be a better place.

 

I'm looking into writing a bundled application to manage Apache HTTP
with Tomcat. Basically just a management console and predefined
configuration structure that would allow non-technical users the ability
to easily add virtual servers, instances, SSL certs, etc. The system
would also be cluster aware in the sense of pushing configuration
changes to multiple nodes in a cluster mapping variables to each node
(IP address, etc). Before I proceed I just wanted to check if anyone
knows of a system similar to this so I don't have to rewrite what's been
done before.

 

I did some searching on sourceforge and google but couldn't really find
anything that does this.

 

Thanks,

Robert

 

DO NOT REPLY [Bug 39178] - FarmWarDeployer does not deploy "ROOT.war" correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39178


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 14:50 ---
OK, find it was fixed...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393219 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[pero]

Author: pero
Date: Tue Apr 11 06:52:04 2006
New Revision: 393219

URL: http://svn.apache.org/viewcvs?rev=393219&view=rev
Log:
Add cloesed bug report and change bug comment.

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=393219&r1=393218&r2=393219&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Apr 11 06:52:04 2006
@@ -83,7 +83,7 @@
 Fix that after every Keep Alive Socket close a log warning is 
generated TcpReplicationThread (pero)
   
   
-Fix ROOT.war deployment at FarmWarDeployer (pero)
+39178bug>Now ROOT.war deployment with FarmWarDeployer is 
possible (pero)
   
   
 ReplicationValve not set primarySession flag when all backup nodes 
gone (pero)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393220 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[pero]

Author: pero
Date: Tue Apr 11 06:53:13 2006
New Revision: 393220

URL: http://svn.apache.org/viewcvs?rev=393220&view=rev
Log:
Hups, fix typo.

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=393220&r1=393219&r2=393220&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Apr 11 06:53:13 2006
@@ -83,7 +83,7 @@
 Fix that after every Keep Alive Socket close a log warning is 
generated TcpReplicationThread (pero)
   
   
-39178bug>Now ROOT.war deployment with FarmWarDeployer is 
possible (pero)
+39178: Now ROOT.war deployment with FarmWarDeployer is 
possible (pero)
   
   
 ReplicationValve not set primarySession flag when all backup nodes 
gone (pero)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37804] - Sleeping for "+memberwait+" secs should be milliseconds

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37804


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 14:56 ---
Thanks for that, I change comment!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38779] - Wrong class name in org/apache/catalina/cluster/tcp/mbeans-descriptors.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38779


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 15:07 ---
Thanks, that reporting this, fix at tomcat 5.5.17 release.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393223 - in /tomcat/container/tc5.5.x: modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml webapps/docs/changelog.xml

[pero]

Author: pero
Date: Tue Apr 11 07:07:47 2006
New Revision: 393223

URL: http://svn.apache.org/viewcvs?rev=393223&view=rev
Log:
Fix bug 38779

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml?rev=393223&r1=393222&r2=393223&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 Tue Apr 11 07:07:47 2006
@@ -66,7 +66,7 @@
returnType="void">
   
+ type="org.apache.catalina.cluster.ClusterMessage"/>
   

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=393223&r1=393222&r2=393223&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Apr 11 07:07:47 2006
@@ -79,6 +79,10 @@
   
   
 
+   
+   38779 Fix wrong jmx message arg at SimpleTcpCluster
+  at o.a.c.cluster.tcp.mbeans-descriptors.xml, submitted by Pawel 
Tucholski (pero)
+  
   
 Fix that after every Keep Alive Socket close a log warning is 
generated TcpReplicationThread (pero)
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug in TC class loading

[Rainer Jung]

I logged a bug a couple of days ago:

http://issues.apache.org/bugzilla/show_bug.cgi?id=39218

Since nobody gave any response, I wanted to ping the list.

The current implementation of the server, common and shared class 
loaders use the catalina.properties file to make the group of 
repositories which are searched for classes configurable.


Unfortunately the order of repositories in the entries is not respected. 
Instead they are rearranched into packed (jar files), unpacked (class 
directories) and a URL list. Then all unpacked are searched first, after 
that all jars and at the end all URLs.


A typical user would understand the configuration lines in 
catalina.properties as an analogy to the usual classpath of the system 
classloader. And I think that's intended. He would rely on the fact, 
that the order of entries is respected by the class loader. So he will 
order his patches etc. in the most obvious way. We throw away the order 
and rearrange via undocumented rules.


I attached a patch to bugzilla adding another signature to the creation 
of the classloader, allowing to pass in all repositories in the correct 
order. It's not a major redesign of the loading, because I want to keep 
the risk of breaking something minimal.


Any comments?

An example:

The tomcat product deployer might add a patch into 
CATALINA_HOME/server/classes (they don't want to overwrite the original 
jar files and adding them into server/lib is no way, since there is no 
way of knowing, in which order *.jar will be evaluated).


The application project team prepares an instance in CATALINA_BASE and 
deploys a newer version or a collection of patches as a jar file into 
CATALINA_HOME/server/lib.


They prepare a catalina.properties file with

server.loader=${catalina.base}/server/lib/*.jar,\
${catalina.home}/server/classes,\
${catalina.home}/server/lib/*.jar

Their version of the patch will not be loaded, because we regroup the 
entries and ${catalina.home}/server/classes will come first!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393243 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[remm]

Author: remm
Date: Tue Apr 11 08:16:34 2006
New Revision: 393243

URL: http://svn.apache.org/viewcvs?rev=393243&view=rev
Log:
- Changelog update.

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=393243&r1=393242&r2=393243&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Apr 11 08:16:34 2006
@@ -20,6 +20,9 @@
   
 Update to Xerces 2.8.0 (remm)
   
+  
+Update to tcnative 1.1.3 (remm)
+  
 
   
   
@@ -49,6 +52,16 @@
   
 Expand the semaphore valve (remm)
   
+  
+39021: Add back support for authentication only, submitted 
by Scott Stark (remm)
+  
+  
+Revert fix for 38113, which does not seem a legitimate 
problem, and causes
+regressions (remm)
+  
+  
+Correctly reset listeners when reloading a webapp (remm)
+  
 
   
   
@@ -67,6 +80,19 @@
 As exhibited in the ASF's JIRA installation, it seems EINTR is a 
status code that should
 be ignored as a result to a poll call (remm)
   
+  
+New APR connectors defaults (remm)
+  
+  
+Add multiple threads for APR pollers, to work around Windows 
limitations (performance degrades
+very rapidly if poller sizes over 1024 are allowed when compiling APR) 
(remm)
+  
+  
+New modes for firstReadTimeout (-1 being the new default) (remm)
+  
+  
+Replace java.util.Stack usage with a simple array in the APR endpoint 
(remm)
+  
 
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bug in TC class loading

[Remy Maucherat]

Rainer Jung wrote:

I logged a bug a couple of days ago:

http://issues.apache.org/bugzilla/show_bug.cgi?id=39218


I found this was a reasonable addition. If you commit something and I 
don't like it, I know how to complain.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393248 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina: core/NamingContextListener.java core/StandardContext.java util/AnnotationProcessor.java

[remm]

Author: remm
Date: Tue Apr 11 08:36:04 2006
New Revision: 393248

URL: http://svn.apache.org/viewcvs?rev=393248&view=rev
Log:
- Add a few naming related cleanups.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/NamingContextListener.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/NamingContextListener.java
URL: 
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/NamingContextListener.java?rev=393248&r1=393247&r2=393248&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/NamingContextListener.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/NamingContextListener.java 
Tue Apr 11 08:36:04 2006
@@ -147,9 +147,7 @@
  * Return the "name" property.
  */
 public String getName() {
-
 return (this.name);
-
 }
 
 
@@ -159,14 +157,19 @@
  * @param name The new name
  */
 public void setName(String name) {
-
 this.name = name;
-if( log.isDebugEnabled() )
-log.debug( "setName " + name);
 }
 
 
 /**
+ * Return the comp context.
+ */
+public javax.naming.Context getCompContext() {
+return this.compCtx;
+}
+
+
+/**
  * Return the env context.
  */
 public javax.naming.Context getEnvContext() {
@@ -178,9 +181,7 @@
  * Return the associated naming context.
  */
 public NamingContext getNamingContext() {
-
 return (this.namingContext);
-
 }
 
 

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?rev=393248&r1=393247&r2=393248&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Tue 
Apr 11 08:36:04 2006
@@ -4842,6 +4842,14 @@
 
 
 /**
+ * Naming context listener setter.
+ */
+public void setNamingContextListener(NamingContextListener 
namingContextListener) {
+this.namingContextListener = namingContextListener;
+}
+
+
+/**
  * Return the request processing paused flag for this Context.
  */
 public boolean getPaused() {

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java?rev=393248&r1=393247&r2=393248&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java 
Tue Apr 11 08:36:04 2006
@@ -117,15 +117,15 @@
 lookupFieldResource(context, instance, fields[i], 
annotation.name());
 }
 /*
-if (f.isAnnotationPresent(EJB.class)) {
-EJB annotation = (EJB) f.getAnnotation(EJB.class);
-lookupOnFieldResource(f, annotation.name());
+if (fields[i].isAnnotationPresent(EJB.class)) {
+EJB annotation = (EJB) fields[i].getAnnotation(EJB.class);
+lookupOnFieldResource(context, instance, fields[i], 
annotation.name());
 }
 
-if (f.isAnnotationPresent(WebServiceRef.class)) {
-WebServiceRef annotation = (WebServiceRef) 
-f.getAnnotation(WebServiceRef.class);
-lookupOnFieldResource(f, annotation.name());
+if (fields[i].isAnnotationPresent(WebServiceRef.class)) {
+WebServiceRef annotation = 
+(WebServiceRef) 
fields[i].getAnnotation(WebServiceRef.class);
+lookupOnFieldResource(context, instance, fields[i], 
annotation.name());
 }
 */
 }
@@ -138,14 +138,14 @@
 lookupMethodResource(context, instance, methods[i], 
annotation.name());
 }
 /*
-if (m.isAnnotationPresent(EJB.class)) {
-EJB annotation = (EJB) m.getAnnotation(EJB.class);
-lookupOnMethodResource(m, annotation.name());
+if (methods[i].isAnnotationPresent(EJB.class)) {
+EJB annotation = (EJB) methods[i].getAnnotation(EJB.class);
+lookupOnMethodResource(context, instance, methods[i], 
annotation.name());
 }
-if (m.isAnnotationPresent(WebServiceRef.class)) {
-WebServiceRef annotation = (WebServiceRef) 
-m.ge

Re: Bug in TC class loading

[Rainer Jung]

svn: Commit failed
...
403 Forbidden (http://svn.apache.org)

Seriously: I would like to, but I'm only a contributor  :)

Remy Maucherat wrote:

Rainer Jung wrote:


I logged a bug a couple of days ago:

http://issues.apache.org/bugzilla/show_bug.cgi?id=39218



I found this was a reasonable addition. If you commit something and I 
don't like it, I know how to complain.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Changing failover session's jvmRoute if cookies are disabled

[Peter Rossbach]

Hi, Brian,

I think you are right! It exist no reason why we only change the  
session id at cookie session id case!
Hmm,  I thing my test env and customer app are cookie based :-( Then  
I later not made it ready to support also request session ids.
I find a easy fix to getting it work. The enhancement include at  
tomat 5.5.17 release.


Many thanks to reporting it,
Peter


Am 27.03.2006 um 22:07 schrieb Brian Stansberry:


Hi,

I noticed that in o.a.c.cluster.session.JvmRouteBinderValve there is a
block of code
that basically prevents changing a session's jvmRoute if URL  
rewriting is used:


if (request.isRequestedSessionIdFromURL

()) {
  if (log.isDebugEnabled())
  log.debug(sm.getString("jvmRoute.skipURLSessionIDs"));
} else {
  handleJvmRoute( request, response,session.getIdInternal(),  
jvmRoute);

}



This basically means that if cookies are disabled and a session  
fails over, the

jvmRoute portion of the session id won't be changed. AIUI, if this
isn't changed,
thereafter mod_jk will not pin the session to any server. That's a  
pretty big



limitation to distributed sessions.

In JBoss clustering we have a similar valve that has pretty much the
same limitation.

Does anyone know any reason for this limitation? If cookies are  
disabled, we



of course shouldn't emit a cookie, but why not change the id of the
session object?
Looking at how Response.encodeURL works, it uses the session object's
id when encoding,
so if we change this field, any subsequently emitted URLs should have
the proper id


with the new jvmRoute. This valve is invoked before the request enters
the webapp, so
the id change will take place before the webapp writes any URLs.

Thanks!

Brian Stansberry
Lead, AS Clustering


JBoss, Inc.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r393256 - in /tomcat/container/tc5.5.x: modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java webapps/docs/changelog.xml webapps/docs/cluster-howto.xml

[pero]

Author: pero
Date: Tue Apr 11 09:20:28 2006
New Revision: 393256

URL: http://svn.apache.org/viewcvs?rev=393256&view=rev
Log:
JvmRouteBinderValve now support also sessionid rewriting from request parameter 
jsessionid,
Add documentation for this valve to cluster-howto.xml. :-)

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java?rev=393256&r1=393255&r2=393256&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java
 Tue Apr 11 09:20:28 2006
@@ -45,12 +45,13 @@
  * Valve to handle Tomcat jvmRoute takeover using mod_jk module after node
  * failure. After a node crashed the next request going to other cluster node.
  * Now the answering from apache is slower ( make some error handshaking. Very
- * bad with apache at my windows.). We rewrite now the cookie jsessionid
+ * bad with apache at my windows.). We rewrite now the jsessionid
  * information to the backup cluster node. After the next response all client
  * request goes direct to the backup node. The change sessionid send also to 
all
  * other cluster nodes. Well, now the session stickyness work directly to the
  * backup node and traffic don't go back too restarted cluster nodes!
- * 
+ * As jsessionid was created by cookie, the change JSESSIONID cookie resend 
with next response.
+ *  
  * At all cluster node you must configure the as ClusterListener since 5.5.10
  * [EMAIL PROTECTED] 
org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener 
JvmRouteSessionIDBinderListener}
  * or before with
@@ -90,7 +91,7 @@
 /**
  * The descriptive information about this implementation.
  */
-protected static final String info = 
"org.apache.catalina.cluster.session.JvmRouteBinderValve/1.2";
+protected static final String info = 
"org.apache.catalina.cluster.session.JvmRouteBinderValve/1.3";
 
 /*--Instance Variables--*/
 
@@ -225,12 +226,7 @@
 
log.warn(sm.getString("jvmRoute.missingJvmRouteAttribute"));
 return;
 }
-if (request.isRequestedSessionIdFromURL()) {
-if (log.isDebugEnabled())
-log.debug(sm.getString("jvmRoute.skipURLSessionIDs"));
-} else {
-handleJvmRoute( request, response,session.getIdInternal(), 
jvmRoute);
-}
+handleJvmRoute( request, response,session.getIdInternal(), 
jvmRoute);
 if (log.isDebugEnabled()) {
 long t2 = System.currentTimeMillis();
 long time = t2 - t1;
@@ -352,7 +348,8 @@
 catalinaSession.setId(newSessionID);
 if (catalinaSession instanceof DeltaSession)
 ((DeltaSession) catalinaSession).resetDeltaRequest();
-setNewSessionCookie(request, response,newSessionID);
+if(request.isRequestedSessionIdFromCookie())
+setNewSessionCookie(request, response,newSessionID);
 // set orginal sessionid at request, to allow application detect the
 // change
 if (sessionIdAttribute != null && !"".equals(sessionIdAttribute)) {

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=393256&r1=393255&r2=393256&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Apr 11 09:20:28 2006
@@ -105,12 +105,19 @@
   
   
 
+   
+Add JvmRouteBinderValve documentation at cluster-howto.xml. (pero)
+   
+   
+JvmRouteBinderValve now supports now sessionid's from request and 
cookies.
+Thanks to Brian Stansberry for reporting it. (pero)
+   

38779 Fix wrong jmx message arg at SimpleTcpCluster
   at o.a.c.cluster.tcp.mbeans-descriptors.xml, submitted by Pawel 
Tucholski (pero)
   
   
-Fix that after every Keep Alive Socket close a log warning is 
generated TcpReplicationThread (pero)
+Fix that not after every "Keep Alive Socket close" a log warning is 
generated at TcpReplicationThread (pero)
   
   
 39178: Now ROOT.war deployment with F

Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml

[Costin Manolache]

On 4/11/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > What about: keep them excluded in the build target for tomcat, but add a
> > separate target to build only javamail-dependent classes, and package them 
> > in
> > a separate jar.
> >
> > That would keep 'core' tomcat clean, and would work for other kind of
> > modules that have external deps.
> >
> > It would be even better if we could just move them in a separate
> > package - for example
> > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > core build. Everything that will have external deps, and maybe things
> > that are not essential could go there.
>
> This is a possibility, but maybe there are solutions in this particular
> case.

The solution depends on how you define the problem :-)

If you think the problem is to compile javamail dependent code - you
are right, dummy or
link would work. Next problem would be how people could use it - even
if it is in tomcat,
they'll need to download additional jars, etc.

I define the problem as "this should be an optional component, not
really required by
the spec or used by majority of users". The people who use it are
likely to be in a J2EE
environment where they have javamail, and could easily have the
additional tomcat module.


Costin


>
> For example, I can either add my dummy classes, or a svn link could be
> created to
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail
> (and activation too)
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml

[Bill Barker]

 

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 11, 2006 9:36 AM
> To: Tomcat Developers List
> Subject: Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
> 
> On 4/11/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> > Costin Manolache wrote:
> > > What about: keep them excluded in the build target for 
> tomcat, but add a
> > > separate target to build only javamail-dependent classes, 
> and package them in
> > > a separate jar.
> > >
> > > That would keep 'core' tomcat clean, and would work for 
> other kind of
> > > modules that have external deps.
> > >
> > > It would be even better if we could just move them in a separate
> > > package - for example
> > > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > > core build. Everything that will have external deps, and 
> maybe things
> > > that are not essential could go there.
> >
> > This is a possibility, but maybe there are solutions in 
> this particular
> > case.
> 
> The solution depends on how you define the problem :-)
> 
> If you think the problem is to compile javamail dependent code - you
> are right, dummy or
> link would work. Next problem would be how people could use it - even
> if it is in tomcat,
> they'll need to download additional jars, etc.
> 

Well, if we use the Geronimo jars, then it would be possible to ship them
with the binary distro, since they are ASF licensed :).  


> I define the problem as "this should be an optional component, not
> really required by
> the spec or used by majority of users". The people who use it are
> likely to be in a J2EE
> environment where they have javamail, and could easily have the
> additional tomcat module.
> 

I mostly favor keeping the JavaMail support, since removing it (or even
making it a separate download) is likely to generate a flood of BZ reports
from people that can't be bothered to read the docs :).  It has been there
since TC 4.0.0, so a lot of people are going to expect to just drop their
old war into TC 6 and have it work.



> 
> Costin
> 
> 
> >
> > For example, I can either add my dummy classes, or a svn 
> link could be
> > created to
> > 
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo
> -spec-javamail/src/main/java/javax/mail
> > (and activation too)
> >
> > Rémy
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Critical poller failure" when using tcnative

[William A. Rowe, Jr.]

Jean-frederic Clere wrote:

Remy Maucherat wrote:


Mladen Turk wrote:


Right. I was hoping to have the native release by the end of the week
also. Since installer depends on outside natives, the native should
be out before the 5.5.17.


FWIW apr is on the cusp of that next release; tarballs being voted on for
release on the [EMAIL PROTECTED] channel are available for test @ 
apr.apache.org/dev/dist/.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml

[Costin Manolache]

On 4/11/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 11, 2006 9:36 AM
> > To: Tomcat Developers List
> > Subject: Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
> >
> > On 4/11/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> > > Costin Manolache wrote:
> > > > What about: keep them excluded in the build target for
> > tomcat, but add a
> > > > separate target to build only javamail-dependent classes,
> > and package them in
> > > > a separate jar.
> > > >
> > > > That would keep 'core' tomcat clean, and would work for
> > other kind of
> > > > modules that have external deps.
> > > >
> > > > It would be even better if we could just move them in a separate
> > > > package - for example
> > > > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > > > core build. Everything that will have external deps, and
> > maybe things
> > > > that are not essential could go there.
> > >
> > > This is a possibility, but maybe there are solutions in
> > this particular
> > > case.
> >
> > The solution depends on how you define the problem :-)
> >
> > If you think the problem is to compile javamail dependent code - you
> > are right, dummy or
> > link would work. Next problem would be how people could use it - even
> > if it is in tomcat,
> > they'll need to download additional jars, etc.
> >
>
> Well, if we use the Geronimo jars, then it would be possible to ship them
> with the binary distro, since they are ASF licensed :).

Yes, that's a good option if we want to keep this feature as part of
the core and not
modularize it.




>
>
> > I define the problem as "this should be an optional component, not
> > really required by
> > the spec or used by majority of users". The people who use it are
> > likely to be in a J2EE
> > environment where they have javamail, and could easily have the
> > additional tomcat module.
> >
>
> I mostly favor keeping the JavaMail support, since removing it (or even
> making it a separate download) is likely to generate a flood of BZ reports
> from people that can't be bothered to read the docs :).  It has been there
> since TC 4.0.0, so a lot of people are going to expect to just drop their
> old war into TC 6 and have it work.

What about having 2 distros of tomcat - a minimal container, and a
bloated one with
all the features bundled. Lazy people can get the large one, and not
have to download
anything.

Costin


>
>
>
> >
> > Costin
> >
> >
> > >
> > > For example, I can either add my dummy classes, or a svn
> > link could be
> > > created to
> > >
> > https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo
> > -spec-javamail/src/main/java/javax/mail
> > > (and activation too)
> > >
> > > Rémy
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml

[Remy Maucherat]

Costin Manolache wrote:

Yes, that's a good option if we want to keep this feature as part of
the core and not
modularize it.


I don't see any reason to ship javamail binaries.


What about having 2 distros of tomcat - a minimal container, and a
bloated one with
all the features bundled. Lazy people can get the large one, and not
have to download
anything.


I would like to keep things equivalent to 5.5: a reasonable feature set.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39278] New: - getRequestURI returns decoded URI contrary to spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39278

   Summary: getRequestURI returns decoded URI contrary to spec
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The documentation states that the string returned by getRequestURI() is not
decoded by the container. However in Tomcat 5.5.9 it returns a partially decoded
URI, i.e, %xx is decoded but '+'=>' ' is not. IIRC this used to work in Tomcat
4. I'm expecting an encoded URI and when I decode the partially decoded one of
course I mangle any real '+' characters.

getRequestURL seems to return the unmangled string so I have a workaround but
this behavior is inconsistent with the documentation and at least the Servlet
2.3 spec.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]