Re: Persistent storage of sessions, why no Principal?

[Roland Turner (Apache)]

On Sun, 2006-02-19 at 23:33 -0800, Marc de Klerk wrote:

 I must be subscribed there by mistake... It would be great if I was 
 unsubscribed.

Fair enough. Instructions for doing so appear, as with most mailing list
email nowadays, at the bottom of each article. From your own reply:

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

(N.B. It is unlikely that the list administrator is actually subscribed
to the list, so there is little point posting requests for
unsubscription to the list itself.)

- Raz


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

AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

[Pelikan Stephan]

Hallo Mladen,

FlushPacket works, and the patch is invalid.
The service ws_flush is invoked from ajp_common.

My original problem is that I produce a big servlet-response. This 
servlet-response builds a progress-bar, so there are interruption (serversided 
sleeps to wait for the next 'progress-bar-event') between some pieces of 
html-parts. I want to send these chunks directly to the browser to update the 
progress-bar but this did not heapen (without mod_jk it works). I tried to turn 
off every buffer I found but it still did not work. Turning debug-level of the 
mod_jk-log on I saw, that these parts where transmitted to the apache and the 
apache does not transmit it to the browser. The patch was the only way to get 
it work. Perhaps you could tell me how to solve this correctly - without a 
patch?

In theory there can be problems if there is no
content_body packets, but the flushing is implied
after the handler by apache itself.

As I explained I need flushed within the response after each chunk transmitted 
from tomcat to apache not only at the end.

Regards,
Stephan

PS: My current configuration:

server.xml:
  !-- A AJP 1.3 Connector on port 8009 --
  Connector port=8009 address=${jboss.bind.address}
 emptySessionPath=true enableLookups=false redirectPort=8443
 protocol=AJP/1.3 socketBuffer=-1 bufferSize=-1 /

httpd.conf:
JkWorkersFile /appl/www/apache/etc/workers.config
JkOptions FlushPackets
JkLogFile /appl/www/apache/logs/mod_jk.log
JkLogLevel warn
JkMount /* jboss

workers.config:
worker.list=jboss
worker.jboss.type=ajp13
worker.jboss.host=dpa.aomwebappl01.apa.at
worker.jboss.port=8009
worker.jboss.cachesize=0



-Ursprüngliche Nachricht-
Von: Mladen Turk [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 17. Februar 2006 11:43
An: Tomcat Developers List
Betreff: Re: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

Pelikan Stephan wrote:
 Hello,
  
 I detected that the FlushPackets JkOption does not work. I could 
 solve the problem by the patch
  

FlushPacket works, and the patch is invalid.
The service ws_flush is invoked from ajp_common.

In theory there can be problems if there is no content_body packets, but the 
flushing is implied after the handler by apache itself.


Regards,
Mladen.

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

Re: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

[Peter Rossbach]

I thing you mus set
JkOptions +FlushPackets

regards
Peter


Am 20.02.2006 um 09:28 schrieb Pelikan Stephan:


JkOptions FlushPackets

can not build tests

[Amila Suriarachchi]

hi,
I downloaded the tomcat 5.5.15 source code. and made the build sucessfully.
then i saw an ant task in build/build.xml called test and try to run (saying
ant test) the task.
but there were some compilation errors.
are they obselete or else can someone explain me how to build and run the
tests.

thankx in advance.
amila.

DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716.
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=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:09 ---
I agree with Endre. 
It can be a problem to use the ThreadLocal in thread pool environment, as
explained. IMHO, if tomcat have the proposed feature, it would be good to
improve the stability of the applications.
Can you explain a bit more why it won't be 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]

RE: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

[Fenlason, Josh]

Are you sure that + is the default for the FlushPackets option?  I had a
similar issue where I was trying to stream data from a servlet.  Once I
added 'JkOptions +FlushPackets' to my mod_jk config, everything worked
as expected.
,
Josh.

 -Original Message-
 From: Mladen Turk [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 3:47 AM
 To: Tomcat Developers List
 Subject: Re: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug
 
 
 Peter Rossbach wrote:
  I thing you mus set
  JkOptions +FlushPackets
  
 
 No need. Default is +.
 
 Regards,
 Mladen.
 
 
 -
 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]

DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716.
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=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:47 ---
An alternative (which I don't seem to like) is to use time to live for threads.
Once a thread has lived for X amount of time or served Y requests - it will be
terminated. This could allow threadlocals go away, but an OOM could still
occur if the required amount of time/requests is not reached. 

This approach mirrors the apache process model where you can request processes
terminate after so many requests. (But comparing threads to processes is like
not the greatest analogy)

-- 
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]

Re: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

[Rainer Jung]

Hi Mladen,

are you sure? I have the impression default is

c-options = JK_OPT_FWDURIDEFAULT;

and

#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPAT
#define JK_OPT_FWDURICOMPAT 0x0001

but needed is

#define JK_OPT_FLUSHPACKETS 0x0020

It looks like JK_OPT_FLUSHPACKETS is only set when JkOption parsed.

Anything I missed?

Regards,

Rainer

Fenlason, Josh wrote:


Are you sure that + is the default for the FlushPackets option?  I had a
similar issue where I was trying to stream data from a servlet.  Once I
added 'JkOptions +FlushPackets' to my mod_jk config, everything worked
as expected.
,
Josh.



-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 20, 2006 3:47 AM

To: Tomcat Developers List
Subject: Re: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug


Peter Rossbach wrote:


I thing you mus set
JkOptions +FlushPackets



No need. Default is +.

Regards,
Mladen.


-
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: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug

[Mladen Turk]

Rainer Jung wrote:

Hi Mladen,

are you sure? I have the impression default is



I meant that the '+' is default:

if (action == '-') {
conf-options = ~opt;
}
else if (action == '+') {
conf-options |= opt;
}
else {  /* for now +Opt == Opt */
conf-options |= opt;
}

So it shouldn't make any difference between:
JkOptions +FlushPackets
and
JkOptions FlushPackets


Regards,
Mladen.

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

svn commit: r379183 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina: core/StandardContext.java startup/ContextConfig.java

[remm]

Author: remm
Date: Mon Feb 20 09:45:48 2006
New Revision: 379183

URL: http://svn.apache.org/viewcvs?rev=379183view=rev
Log:
- Slightly modify the timing of the manager start (unfortunately, setManager in 
ContextConfig.java 
  causes and immediate start of the manager).

Modified:

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

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java?rev=379183r1=379182r2=379183view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
 Mon Feb 20 09:45:48 2006
@@ -81,6 +81,7 @@
 import org.apache.catalina.deploy.SecurityCollection;
 import org.apache.catalina.deploy.SecurityConstraint;
 import org.apache.catalina.loader.WebappLoader;
+import org.apache.catalina.session.StandardManager;
 import org.apache.catalina.startup.ContextConfig;
 import org.apache.catalina.startup.TldConfig;
 import org.apache.catalina.util.CharsetMapper;
@@ -4116,6 +4117,20 @@
 // Notify our interested LifecycleListeners
 lifecycle.fireLifecycleEvent(START_EVENT, null);
 
+// Configure default manager if none was specified
+if (manager == null) {
+if ((cluster != null)  distributable) {
+try {
+setManager(cluster.createManager(getName()));
+} catch (Exception ex) {
+log.error(standardContext.clusterFail, ex);
+ok = false;
+}
+} else {
+setManager(new StandardManager());
+}
+}
+
 // Start manager
 if ((manager != null)  (manager instanceof Lifecycle)) {
 ((Lifecycle) getManager()).start();

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java?rev=379183r1=379182r2=379183view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
 Mon Feb 20 09:45:48 2006
@@ -388,28 +388,6 @@
 
 
 /**
- * Set up a manager.
- */
-protected synchronized void managerConfig() {
-
-if (context.getManager() == null) {
-if ((context.getCluster() != null)  context.getDistributable()) {
-try {
-context.setManager(context.getCluster().createManager
-   (context.getName()));
-} catch (Exception ex) {
-log.error(contextConfig.clusteringInit, ex);
-ok = false;
-}
-} else {
-context.setManager(new StandardManager());
-}
-}
-
-}
-
-
-/**
  * Set up an Authenticator automatically if required, and one has not
  * already been configured.
  */
@@ -1062,10 +1040,6 @@
 // Configure an authenticator if we need one
 if (ok)
 authenticatorConfig();
-
-// Configure a manager
-if (ok)
-managerConfig();
 
 // Dump the contents of this pipeline if requested
 if ((log.isDebugEnabled())  (context instanceof ContainerBase)) {



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

svn commit: r379187 - in /tomcat/container/branches/tc4.1.x: catalina/src/share/org/apache/catalina/core/ catalina/src/share/org/apache/catalina/servlets/ webapps/examples/WEB-INF/classes/

[markt]

Author: markt
Date: Mon Feb 20 10:02:51 2006
New Revision: 379187

URL: http://svn.apache.org/viewcvs?rev=379187view=rev
Log:
enum - enumeration to allow building on Java 5.0 generally and Gump in 
particular without having to set source compatibility to 1.4 or lower.

Modified:

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/NamingContextListener.java

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java

tomcat/container/branches/tc4.1.x/webapps/examples/WEB-INF/classes/JndiServlet.java

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/NamingContextListener.java?rev=379187r1=379186r2=379187view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
 Mon Feb 20 10:02:51 2006
@@ -1014,9 +1014,9 @@
 if (resourceParameters == null)
 return;
 Hashtable params = resourceParameters.getParameters();
-Enumeration enum = params.keys();
-while (enum.hasMoreElements()) {
-String paramName = (String) enum.nextElement();
+Enumeration enumeration = params.keys();
+while (enumeration.hasMoreElements()) {
+String paramName = (String) enumeration.nextElement();
 String paramValue = (String) params.get(paramName);
 StringRefAddr refAddr = new StringRefAddr(paramName, paramValue);
 ref.add(refAddr);

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java?rev=379187r1=379186r2=379187view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
 Mon Feb 20 10:02:51 2006
@@ -1431,12 +1431,13 @@
 
 // Render the directory entries within this directory
 DirContext directory = resourceInfo.directory;
-NamingEnumeration enum =
+NamingEnumeration enumeration =
 resourceInfo.resources.list(resourceInfo.path);
 boolean shade = false;
-while (enum.hasMoreElements()) {
+while (enumeration.hasMoreElements()) {
 
-NameClassPair ncPair = (NameClassPair) enum.nextElement();
+NameClassPair ncPair =
+(NameClassPair) enumeration.nextElement();
 String resourceName = ncPair.getName();
 ResourceInfo childResourceInfo =
 new ResourceInfo(resourceName, directory);

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java?rev=379187r1=379186r2=379187view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
 Mon Feb 20 10:02:51 2006
@@ -521,10 +521,11 @@
 if ((object instanceof DirContext)  (depth  0)) {
 
 try {
-NamingEnumeration enum = resources.list(currentPath);
-while (enum.hasMoreElements()) {
+NamingEnumeration enumeration =
+resources.list(currentPath);
+while (enumeration.hasMoreElements()) {
 NameClassPair ncPair =
-(NameClassPair) enum.nextElement();
+(NameClassPair) enumeration.nextElement();
 String newPath = currentPath;
 if (!(newPath.endsWith(/)))
 newPath += /;
@@ -1643,9 +1644,10 @@
 }
 
 try {
-NamingEnumeration enum = resources.list(source);
-while (enum.hasMoreElements()) {
-NameClassPair 

svn commit: r379188 - in /tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper: EmbededServletOptions.java compiler/Validator.java

[markt]

Author: markt
Date: Mon Feb 20 10:03:47 2006
New Revision: 379188

URL: http://svn.apache.org/viewcvs?rev=379188view=rev
Log:
enum - enumeration to allow building on Java 5.0 generally and Gump in 
particular without having to set source compatibility to 1.4 or lower.

Modified:

tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/EmbededServletOptions.java

tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/Validator.java

Modified: 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/EmbededServletOptions.java
URL: 
http://svn.apache.org/viewcvs/tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/EmbededServletOptions.java?rev=379188r1=379187r2=379188view=diff
==
--- 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/EmbededServletOptions.java
 (original)
+++ 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/EmbededServletOptions.java
 Mon Feb 20 10:03:47 2006
@@ -237,9 +237,9 @@
 public EmbededServletOptions(ServletConfig config,
  ServletContext context) {
 
-Enumeration enum=config.getInitParameterNames();
-while( enum.hasMoreElements() ) {
-String k=(String)enum.nextElement();
+Enumeration enumeration=config.getInitParameterNames();
+while( enumeration.hasMoreElements() ) {
+String k=(String)enumeration.nextElement();
 String v=config.getInitParameter( k );
 
 setProperty( k, v);

Modified: 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/Validator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/Validator.java?rev=379188r1=379187r2=379188view=diff
==
--- 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/Validator.java
 (original)
+++ 
tomcat/jasper/branches/tc4.1.x/src/share/org/apache/jasper/compiler/Validator.java
 Mon Feb 20 10:03:47 2006
@@ -589,9 +589,10 @@
 StringBuffer errMsg = null;
 ErrorDispatcher errDisp = compiler.getErrorDispatcher();
 
-Enumeration enum = compiler.getPageInfo().getTagLibraries().elements();
-while (enum.hasMoreElements()) {
-TagLibraryInfo tli = (TagLibraryInfo) enum.nextElement();
+Enumeration enumeration =
+compiler.getPageInfo().getTagLibraries().elements();
+while (enumeration.hasMoreElements()) {
+TagLibraryInfo tli = (TagLibraryInfo) enumeration.nextElement();
 ValidationMessage[] errors
 = ((TagLibraryInfoImpl) tli).validate(xmlView);
 if ((errors != null)  (errors.length != 0)) {



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

never say never...

[Reinhard Moosauer]

Hi List,

please somebody explain:

every few days, a strange procedure can be seen on this list.
Somebody asks for improvement, suggests a fix or simply wants to discuss a new 
feature. 
Few minutes later, there is an answer from somebody, which tells us to ignore 
this subject, because it is not relevant.

Is this necessary? Ok, sometimes we are too simple-hearted to understand all 
consequences of our suggestions.
But IMHO, a one-line-answer is not going to help.

Please, replace your go away, with I vote against it. 
(Even better would be some keywords for the green, so we can find some more 
wisdom.)

R.

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

[EMAIL PROTECTED]: Project tomcat-jasper_tc6 (in module tomcat-jasper_tc6) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-jasper_tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
For reference only, the following projects are affected by this:
- tomcat-jasper_tc6 :  Java Server Pages JSP 2.1 implementation (for Tomcat 
6.x)


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-jasper_tc6/tomcat-jasper_tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason missing build outputs
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/el-api.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-runtime.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-compiler.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-el.jar
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-jasper_tc6/tomcat-jasper_tc6/gump_work/build_tomcat-jasper_tc6_tomcat-jasper_tc6.html
Work Name: build_tomcat-jasper_tc6_tomcat-jasper_tc6 (Type: Build)
Work ended in a state of : Success
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
[Working Directory: /usr/local/gump/public/workspace/tomcat-jasper_tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jface_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.swt.motif_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.core.boot_3.0.0/boot.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.core.runtime_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20022006.jar:/usr/local/gump/public/workspace/jakarta-commons/el/dist/commons-el.jar:/usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar
-
Buildfile: build.xml

build-prepare:
[mkdir] Created dir: /x1/gump/public/workspace/tomcat-jasper_tc6/build
[mkdir] Created dir: /x1/gump/public/workspace/tomcat-jasper_tc6/build/bin
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/common/classes
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/common/lib
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/classes
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/lib

build-only:
[javac] Compiling 180 source files to 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/classes
[javac] 
/x1/gump/public/workspace/tomcat-jasper_tc6/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java:607:
 warning: non-varargs call of varargs method with inexact argument type for 
last parameter;

[EMAIL PROTECTED]: Project tomcat-jasper_tc6 (in module tomcat-jasper_tc6) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-jasper_tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
For reference only, the following projects are affected by this:
- tomcat-jasper_tc6 :  Java Server Pages JSP 2.1 implementation (for Tomcat 
6.x)


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-jasper_tc6/tomcat-jasper_tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason missing build outputs
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/el-api.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-runtime.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-compiler.jar
 -ERROR- Missing Output: 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib/jasper-el.jar
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -ERROR- No such directory (where output is expected) : 
/usr/local/gump/public/workspace/tomcat-jasper_tc6/shared/lib
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-jasper_tc6/tomcat-jasper_tc6/gump_work/build_tomcat-jasper_tc6_tomcat-jasper_tc6.html
Work Name: build_tomcat-jasper_tc6_tomcat-jasper_tc6 (Type: Build)
Work ended in a state of : Success
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
[Working Directory: /usr/local/gump/public/workspace/tomcat-jasper_tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jface_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.swt.motif_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.core.boot_3.0.0/boot.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.core.runtime_3.1.0.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20022006.jar:/usr/local/gump/public/workspace/jakarta-commons/el/dist/commons-el.jar:/usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar
-
Buildfile: build.xml

build-prepare:
[mkdir] Created dir: /x1/gump/public/workspace/tomcat-jasper_tc6/build
[mkdir] Created dir: /x1/gump/public/workspace/tomcat-jasper_tc6/build/bin
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/common/classes
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/common/lib
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/classes
[mkdir] Created dir: 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/lib

build-only:
[javac] Compiling 180 source files to 
/x1/gump/public/workspace/tomcat-jasper_tc6/build/shared/classes
[javac] 
/x1/gump/public/workspace/tomcat-jasper_tc6/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java:607:
 warning: non-varargs call of varargs method with inexact argument type for 
last parameter;

Re: never say never...

[Filip Hanik - Dev Lists]

+1

=)

Reinhard Moosauer wrote:

Hi List,

please somebody explain:

every few days, a strange procedure can be seen on this list.
Somebody asks for improvement, suggests a fix or simply wants to discuss a new 
feature. 
Few minutes later, there is an answer from somebody, which tells us to ignore 
this subject, because it is not relevant.


Is this necessary? Ok, sometimes we are too simple-hearted to understand all 
consequences of our suggestions.

But IMHO, a one-line-answer is not going to help.

Please, replace your go away, with I vote against it. 
(Even better would be some keywords for the green, so we can find some more 
wisdom.)


R.

-
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: never say never...

[George Sexton]

RESOLVED | INVALID

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

 -Original Message-
 From: Reinhard Moosauer [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 11:09 AM
 To: tomcat-dev@jakarta.apache.org
 Subject: never say never...
 
 Hi List,
 
 please somebody explain:
 
 every few days, a strange procedure can be seen on this list.
 Somebody asks for improvement, suggests a fix or simply wants 
 to discuss a new 
 feature. 
 Few minutes later, there is an answer from somebody, which 
 tells us to ignore 
 this subject, because it is not relevant.
 
 Is this necessary? Ok, sometimes we are too simple-hearted to 
 understand all 
 consequences of our suggestions.
 But IMHO, a one-line-answer is not going to help.
 
 Please, replace your go away, with I vote against it. 
 (Even better would be some keywords for the green, so we can 
 find some more 
 wisdom.)
 
 R.
 
 -
 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]

DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716.
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=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 21:40 ---
I would have to disagree with the abrasive answer. Tomcat already shrinks and
grows thread pools dynamically. When an app reload happens, it could mark
threads to expire after serving the next request or when the connection closes,
and serve new requests on new threads that will be fresh.

not sure what is so bad about that idea?

-- 
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]

Re: never say never...

[Filip Hanik - Dev Lists]

I really try to avoid these threads cause I'm not interested in debates 
nor the political aspects of open source projects and how they work,
but the user brings up a good point, with a probable solution, and I 
don't see how a non committer response like the one below is even justified.
I'm not intending to start a flame war here, just asking for a little 
bit more courtesy.

Think about it, what would the tomcat project be without its users?

Filip

George Sexton wrote:

RESOLVED | INVALID

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

  

-Original Message-
From: Reinhard Moosauer [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 20, 2006 11:09 AM

To: tomcat-dev@jakarta.apache.org
Subject: never say never...

Hi List,

please somebody explain:

every few days, a strange procedure can be seen on this list.
Somebody asks for improvement, suggests a fix or simply wants 
to discuss a new 
feature. 
Few minutes later, there is an answer from somebody, which 
tells us to ignore 
this subject, because it is not relevant.


Is this necessary? Ok, sometimes we are too simple-hearted to 
understand all 
consequences of our suggestions.

But IMHO, a one-line-answer is not going to help.

Please, replace your go away, with I vote against it. 
(Even better would be some keywords for the green, so we can 
find some more 
wisdom.)


R.

-
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: never say never...

[George Sexton]

 -Original Message-
 From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 1:52 PM
 To: Tomcat Developers List
 Subject: Re: never say never...
 
 nor the political aspects of open source projects and how they work,

This is a topic in which you should actually have a great deal of interest.
Tomcat is a brilliant example of a project that has a totally dysfunctional
leadership environment. On paper it is a meritocracy. This is great. The
trouble is that the committers have power, without any real responsibility.
For example, the responsibility to not be abusive towards others. So,
committers can pretty much do anything without consequence.

Just as a little example, several months ago I submitted a patch. One
committer commented that he would -1 it for the com.sun imports. There
weren't any com.sun imports, and when called on it the committer just gaffed
me off. So, this committer just flat out lied (or was mistaken and when
corrected denied the original error) about a reason for rejecting something.
To be fair, the patch did have other problems that were legitimate issues.
However, they should have been presented rather than a fairy tale invention.

As far as how to structurally fix the tomcat group, my only feeble
suggestion would be to permit TOMCAT USERS to recall or fire committers.
Perhaps then some of the more egregious abuses would cease.

 but the user brings up a good point, with a probable solution, and I 
 don't see how a non committer response like the one below is 
 even justified.

I was being ironic or sarcastic. I'm really not sure which.

As for the part about non-committer, I just parroted back the #1 committer
response to new bugs or requests entered into BugZilla. Often, when a users
re-opens these events and asks why, they're re-closed with only RESOLVED |
INVALID. If you don't like it (as I don't), go to the committers that do
this. It seems to me that perhaps someone could do a little analysis and
address the worst offenders.

 I'm not intending to start a flame war here, just asking for a little 
 bit more courtesy.

There won't be courtesy until those people who are the worst offenders are
punished in some manner, or have their status as committers revoked. After
all, why should they behave when there is no consequence?

 Think about it, what would the tomcat project be without its users?

It would evidently be living in a state of open source purity where quality
application design doesn't conflict with stupid people who want to use the
software to solve business problems.

The developers of the application who already live on a higher plane than
the lowly users, without this interference achieve a higher state of
consciousness. Perhaps they would even reach Nerdvana

 
 Filip
 
 George Sexton wrote:
  RESOLVED | INVALID
 
  George Sexton
  MH Software, Inc.
  http://www.mhsoftware.com/
  Voice: 303 438 9585



George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


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

DO NOT REPLY [Bug 38726] New: - GlobalRequestProcessor attributes are always 0

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38726.
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=38726

   Summary: GlobalRequestProcessor attributes are always 0
   Product: Tomcat 5
   Version: 5.5.14
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:HTTP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Guys,

It appears that all attributes of
OName(Catalina:type=GlobalRequestProcessor,name=http-8080) are always 0. This
is the case for Tomcat 5.5.12, 5.5.14 and 5.5.15. It is always reproducible via
Manager webapp. Tomcat 5.0.30 does not have this problem.

Best regards,
Vlad
(www.tomcatprobe.org)

-- 
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]

Re: never say never...

[Mark Thomas]

George Sexton wrote:
Whilst I agree with the general thrust of the arguments made so far in
this thread I do take serious issue with one of your statements.

 Just as a little example, several months ago I submitted a patch. One
 committer commented that he would -1 it for the com.sun imports. There
 weren't any com.sun imports, and when called on it the committer just gaffed
 me off.
This is not an accurate representation of the facts. The thread can be
read here:
http://marc.theaimsgroup.com/?l=tomcat-devr=1s=allowedAliasMatchesq=bw=4

The commit Bill was referring to is this one:
http://marc.theaimsgroup.com/?l=tomcat-devm=111788844800136w=4
that includes
+import com.sun.org.apache.bcel.internal.generic.ALOAD;

Bill did not gaff you off. He pointed out he was -1 for the commit
on the basis of the import. He also expanded on other areas he had
concerns over.

 So, this committer just flat out lied (or was mistaken and when
 corrected denied the original error)
Accusing someone of lying is a serious allegation and on the basis of
the dev archive clearly not true in this case. I would urge you to
retract your comment.

 Often, when a users
 re-opens these events and asks why, they're re-closed with only RESOLVED |
 INVALID. If you don't like it (as I don't), go to the committers that do
 this. It seems to me that perhaps someone could do a little analysis and
 address the worst offenders.
I agree that closing bug reports without an explanation is rarely, if
ever helpful. A few lines explaining why the bug is invalid / won't be
fixed would help enormously.

That being said, having spent that last couple of years fixing bugs it
is immensely frustrating when having closed a bug report as invalid
(with an explanation and where appropriate a reference to the spec) it
is re-opened with a comment that clearly indicates that the person
re-opening the bug report hasn't bothered to read the previous
comments or the spec.

There is an argument that goes along the lines of If the person
creating the bug report can't be bothered to read the spec / do some
basic fault finding / provide enough information to reproduce the
fault / read http://tomcat.apache.org/bugreport.html etc why should I
be bothered to explain things to them?. Whilst I do not agree with
this view personally, I can see how people have reached this point and
I do understand the frustration they feel.

To some extent, the old maxim Garbage in, garbage out applies. The
community nature of open source is such that the quality of response
you receive is generally directly proportional to the effort you are
prepared to put in. There are always exceptions but in my experience
this rule of thumb applies far more often than it doesn't.

 There won't be courtesy until those people who are the worst offenders are
 punished in some manner, or have their status as committers revoked. After
 all, why should they behave when there is no consequence?
I don't think that punishment is the answer. If you feel someone is
discourteous point it out (privately or publicly - your choice) and
ask them to modify their behaviour. Above all, don't descend to their
level.

Think about it, what would the tomcat project be without its users?
Indeed.

Mark


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

DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716.
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=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 00:07 ---
(In reply to comment #9)
 Tomcat already shrinks and grows thread pools dynamically.

Tomcat hasn't been doing that for a long time. Shrinking thread pools may also
be a source of leaks, BTW.

 Not sure what is so bad about that idea?

It's a bit obvious: it is impractical. The only solution is to shut down the
whole thread pool, and start over. As a result, it's completely useless except
in very specific cases, and for these cases, specific solutions should be used
since they would perform much better (filters, listeners, fixes to the libs, 
etc).


-- 
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]

RE: never say never...

[George Sexton]

 -Original Message-
 From: Mark Thomas [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 4:02 PM
 To: Tomcat Developers List
 Subject: Re: never say never...
 
 George Sexton wrote:
 Whilst I agree with the general thrust of the arguments made so far in
 this thread I do take serious issue with one of your statements.
 
  Just as a little example, several months ago I submitted a 
 patch. One
  committer commented that he would -1 it for the com.sun 
 imports. There
  weren't any com.sun imports, and when called on it the 
 committer just gaffed
  me off.
 This is not an accurate representation of the facts. The thread can be
 read here:
 http://marc.theaimsgroup.com/?l=tomcat-devr=1s=allowedAliasM
 atchesq=bw=4
 
 The commit Bill was referring to is this one:
 http://marc.theaimsgroup.com/?l=tomcat-devm=111788844800136w=4
 that includes
 +import com.sun.org.apache.bcel.internal.generic.ALOAD;
 
 Bill did not gaff you off. He pointed out he was -1 for the commit
 on the basis of the import. He also expanded on other areas he had
 concerns over.
 
  So, this committer just flat out lied (or was mistaken and when
  corrected denied the original error)
 Accusing someone of lying is a serious allegation and on the basis of
 the dev archive clearly not true in this case. I would urge you to
 retract your comment.

I stand corrected. The referenced import must have been added by Peter
Rossbach when he committed it. My submitted code did not have the com.sun
import. This is why I didn't think it was there. When the comment was made,
I reviewed my submission and didn't see it.

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


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

DO NOT REPLY [Bug 38726] - GlobalRequestProcessor attributes are always 0

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38726.
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=38726





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 00:25 ---
I go to: http://127.0.0.1:8080/manager/jmxproxy

And I have:
Name: Catalina:type=GlobalRequestProcessor,name=http-8080
modelerType: org.apache.coyote.RequestGroupInfo
requestCount: 15
maxTime: 311
bytesSent: 67419
processingTime: 1431
bytesReceived: 0
errorCount: 1

The status page also uses that MBean, and works fine. Please explain how to
reproduce the problem.

BTW, for the display name of your (nice) webapp, I think you should stick to
Tomcat Probe, and forget the (bye-bye Manager) part.

-- 
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]

RE: never say never...

[George Sexton]

 -Original Message-
 From: Mark Thomas [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 4:02 PM
 To: Tomcat Developers List
 Subject: Re: never say never...
 


 I agree that closing bug reports without an explanation is rarely, if
 ever helpful. A few lines explaining why the bug is invalid / won't be
 fixed would help enormously.

I think everyone is in agreement here.

 
 That being said, having spent that last couple of years fixing bugs it
 is immensely frustrating when having closed a bug report as invalid
 (with an explanation and where appropriate a reference to the spec) it
 is re-opened with a comment that clearly indicates that the person
 re-opening the bug report hasn't bothered to read the previous
 comments or the spec.
 
 There is an argument that goes along the lines of If the person
 creating the bug report can't be bothered to read the spec / do some
 basic fault finding / provide enough information to reproduce the
 fault / read http://tomcat.apache.org/bugreport.html etc why should I
 be bothered to explain things to them?. Whilst I do not agree with
 this view personally, I can see how people have reached this point and
 I do understand the frustration they feel.

Having a cycle of 4-8 iterations where a person asks why its resolved
invalid, and a committer re-marks it resolved invalid without comment
doesn't seem like it would reduce frustration on the part of the committer.
It seems to me they would just get angrier on each iteration.

Don't misunderstand me. I'm certainly not saying a committer shouldn't say
This is non-compliant and will not be addresed or We comply with the
spec, and we will not be expanding the application to meet your specific
need. These are legitimate responses.  When the specification is involved,
it would be nice to reference the relevant part of the specification. When
committers use emotionally charged terms with no technical basis, or just
reject things out of hand without explanation its not fair.

  There won't be courtesy until those people who are the 
 worst offenders are
  punished in some manner, or have their status as committers 
 revoked. After
  all, why should they behave when there is no consequence?
 I don't think that punishment is the answer. If you feel someone is
 discourteous point it out (privately or publicly - your choice) and
 ask them to modify their behaviour. Above all, don't descend to their
 level.

This is how things should be done there is just one small flaw. Those people
who are the worst offenders in this matter are pretty much unaffected by
this approach. If people consistently don't respond to that approach (which
should be first), then there needs to be some recourse. For example, a
popular book recommends this approach to conflict resolution:

1)  Approach the person directly. If that doesn't work.
2)  Approach the person with others as witnesses to verify what is said.
If the person still doesn't respond:
3)  Take the person before the community. If the person still doesn't
respond.
4)  Eject the person from your community and have nothing further to do
with them.

While your recommendation is sound, and is indeed step 1 as outlined above,
by itself it is not enough. There need to be steps to take if the person
doesn't respond.


George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


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

Re: never say never...

[Mark Thomas]

George Sexton wrote:
 Don't misunderstand me. I'm certainly not saying a committer shouldn't say
 This is non-compliant and will not be addresed or We comply with the
 spec, and we will not be expanding the application to meet your specific
 need. These are legitimate responses.
Agreed.

 When the specification is involved,
 it would be nice to reference the relevant part of the specification.
Also agreed.

 When
 committers use emotionally charged terms with no technical basis, or just
 reject things out of hand without explanation its not fair.
To be fair, there is a technical basis 99.9% of the time but in the
past it often hasn't been explained. As stated elsewhere in this
thread, adding the explanation helps a lot.

On the subject of fairness, is it fair that someone who is too lazy to
read the spec / read the docs / etc should take up any more of the
community's time than the absolute minimum required to, for example,
mark the bug as INVALID? This isn't a view I advocate but it is one I
understand.

 This is how things should be done there is just one small flaw. Those people
 who are the worst offenders in this matter are pretty much unaffected by
 this approach. If people consistently don't respond to that approach (which
 should be first), then there needs to be some recourse. For example, a
 popular book recommends this approach to conflict resolution:
I can see the sense in this approach but ejecting someone is pretty
much impossible in an open source community. Anyone who is 'banned'
can easily get a new e-mail address and re-join. The best you could
achieve would be ignoring them. You can always set an e-mail filter ;)

You might also be interested in this thread. It was a discussion about
how to handle misbehaving members of another part of the Apache community:
http://www.mail-archive.com/community%40apache.org/index.html#04172


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

DO NOT REPLY [Bug 38726] - GlobalRequestProcessor attributes are always 0

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38726.
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=38726





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 02:07 ---
Created an attachment (id=17754)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17754action=view)
GlobalRequestProcessor with zeroed attributes


-- 
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]

RE: never say never...

[George Sexton]

 -Original Message-
 From: Mark Thomas [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 5:33 PM
 To: Tomcat Developers List
 Subject: Re: never say never...
 
 On the subject of fairness, is it fair that someone who is too lazy to
 read the spec / read the docs / etc should take up any more of the
 community's time than the absolute minimum required to, for example,
 mark the bug as INVALID? This isn't a view I advocate but it is one I
 understand.
 

OK, let's throw out the whole fairness thing. How can the Tomcat committers
most efficiently, and with the least amount of anger, hate, and discontent
handle people who do not put in a reasonable effort to understand things or
submit reasonable defect reports.

Candidates are:

1)  Committer marks it resolved | invalid. Submitter demands to know
why. Committer re-marks it RESOLVED | INVALID, ad infinitum until some other
committer decides to break the cycle. Nobody's really happy with this.

2)  The committer puts in a minimal reason referencing the spec. To make
most people happy, a reference to the specific portion of the spec would
have to be researched. The user learns nothing, and the committer is
answering questions instead of fixing code.

3)  The committer marks it resolved | invalid, and sends the user to the
ESR paper on How to ask questions the smart way. Since the committer could
save this snippet of text and copy and paste the text, it seems like it
wouldn't be hard. This would hopefully educate the user and result in higher
quality submissions in the future.



If I've missed any solutions I'd be interested in them.


George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


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

Re: never say never...

[Preston L. Bannister]

A disclaimer here - I used to have committer status (and might still).

On 2/20/06, George Sexton [EMAIL PROTECTED] wrote:

 As far as how to structurally fix the tomcat group, my only feeble
 suggestion would be to permit TOMCAT USERS to recall or fire committers.
 Perhaps then some of the more egregious abuses would cease.


This assumes that committers are an practically unlimited resource, and they
are not.  The answer is very simple.  If you want a better job done, become
a committer, and do the better job you want to see done.  If your answer is
that you do not have time - then lack of time is also the answer to your
question.  Time is a limited resource, and this is a all-volunteer effort.
You cannot write a check against someone else's time.

Allowing non-contributors to fire contributors is unlikely to be
constructive.  To be constructive you need to contribute.

On the other hand, I don't want to hit this one too hard.  Clearly you made
an attempt to contribute - and that's great!  You also recognized that there
were issues with your contribution - that also is a good thing.  If the
answer you got seemed a bit too aburpt (and perhaps it was), then do try to
understand that the other guy may not have the abundance of time to be
optimally diplomatic.

In other words, please keep trying...

RE: never say never...

[George Sexton]

 -Original Message-
 From: Preston L. Bannister [mailto:[EMAIL PROTECTED] 
 Sent: Monday, February 20, 2006 6:22 PM
 To: Tomcat Developers List
 Subject: Re: never say never...
 
 A disclaimer here - I used to have committer status (and might still).
 
 On 2/20/06, George Sexton [EMAIL PROTECTED] wrote:
 
  As far as how to structurally fix the tomcat group, my only feeble
  suggestion would be to permit TOMCAT USERS to recall or 
 fire committers.
  Perhaps then some of the more egregious abuses would cease.
 
 
 This assumes that committers are an practically unlimited 
 resource, and they

Actually I don't make that assumption and I also don't assume that users
will randomly fire all committers. I don't think my proposal would induce a
shortage.


 were issues with your contribution - that also is a good 
 thing.  If the
 answer you got seemed a bit too aburpt (and perhaps it was), 
 then do try to
 understand that the other guy may not have the abundance of time to be
 optimally diplomatic.
 
 In other words, please keep trying...
 

Actually, I've got two other submissions that are not in critical portions
of the code:

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

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

Perhaps they will get picked up.

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


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

Re: [EMAIL PROTECTED]: Project tomcat-catalina (in module jakarta-tomcat-4.0) failed

[Bill Barker]

Mark Thomas [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Stefan Bodewig wrote:
 Project tomcat-catalina has an issue affecting its community integration.
 This issue affects 9 projects.
 The current state of this project is 'Failed', with reason 'Build 
 Failed'.

 Should be fixed now.


Yes, it is: 
http://vmgump.apache.org/gump/public/jakarta-tomcat-4.0/tomcat-catalina/index.html.

Thanks much!  (and to think I wimped out on TC 3.3 and just changed 
the -source :).

 Mark 




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

[EMAIL PROTECTED]: Project jakarta-tomcat-4.0 (in module jakarta-tomcat-4.0) failed

[Stefan Bodewig]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-4.0 has an issue affecting its community integration.
This issue affects 7 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cargo :  Cargo provides a Java API to manipulate Java Containers
- jakarta-cactus-documentation :  Cactus Documentation
- jakarta-cactus-release-12 :  Unit test framework for server-side java code
- jakarta-cactus-release-13 :  Unit test framework for server-side java code
- jakarta-cactus-sample-jetty-13 :  Cactus Jetty Sample (J2EE 1.3)
- jakarta-cactus-sample-servlet-13 :  Cactus Servlet Sample (J2EE 1.3)
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-tomcat-4.0/jakarta-tomcat-4.0/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [naming-resources.jar] identifier set to output basename: 
[naming-resources]
 -DEBUG- Output [servlets-default.jar] identifier set to output basename: 
[servlets-default]
 -DEBUG- Output [naming-common.jar] identifier set to output basename: 
[naming-common]
 -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina]
 -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap]
 -DEBUG- Output [servlets-common.jar] identifier set to output basename: 
[servlets-common]
 -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: 
[servlets-invoker]
 -DEBUG- Dependency on javamail exists, no need to add for property mail.jar.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.jar.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar.
 -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property 
servlet.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
xerces.jar.
 -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 -DEBUG- Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property 
servlet.home.
 -DEBUG- Dependency on jsse exists, no need to add for property jsse.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar.
 -DEBUG- Dependency on jndi exists, no need to add for property jndi.home.
 -DEBUG- Dependency on javamail exists, no need to add for property mail.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property 
regexp.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property 
regexp.jar.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-tomcat-4.0/jakarta-tomcat-4.0/gump_work/build_jakarta-tomcat-4.0_jakarta-tomcat-4.0.html
Work Name: build_jakarta-tomcat-4.0_jakarta-tomcat-4.0 (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Djmx.license=/usr/local/gump/public/workspace/jakarta-tomcat-4.0/RUNNING.txt 
-Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar 
-Djmx.jar=/usr/local/gump/packages/jmx-1_2_1-bin/lib/jmxri.jar 
-Djmx.home=/usr/local/gump/packages/jmx-1_2_1-bin 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20022006.jar
 -Dmail.home=/usr/local/gump/packages/javamail-1.3.2 
-Dant.home=/usr/local/gump/public/workspace/ant/dist 
-Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar
 -Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20022006.jar
 -Dldap.jar=/usr/local/gump/packages/ldap-1_2_4/lib/ldap.jar 

Re: can not build tests

[Amila Suriarachchi]

 hi,
following is the error I got
Buildfile: build.xml

test:
 [echo] Target: Catalina - Test ...

test:
 [echo] Target: Catalina - Test ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=${build.sysclasspath}
 [echo] compile.debug=on
 [echo] compile.deprecation=off
 [echo] compile.optimize=off
 [echo] --- Ant Flags ---
 [echo] style task available (required)=true
 [echo] --- JDK ---
 [echo] jdk.1.2.present=true
 [echo] jdk.1.3.present=true
 [echo] jdk.1.4.present=true
 [echo] --- Source Dependencies ---
 [echo] jtc.home.present=true
 [echo] --- Required Libraries ---
 [echo] beanutils.present=true
 [echo] collections.present=true
 [echo] digester.present=true
 [echo] jaxp.present=true
 [echo] jndi.present=true
 [echo] logging.present=true
 [echo] regexp.present=${regexp.present}
 [echo] --- Optional Libraries ---
 [echo] dbcp.present=true
 [echo] fileupload.present=true
 [echo] jaas.present=true
 [echo] javamail.present=${javamail.present}
 [echo] jmx.present=true
 [echo] jsse.present=true
 [echo] jta.present=${jta.present}
 [echo] junit.present=true
 [echo] lang.present=${lang.present}
 [echo] launcher.present=true
 [echo] launcher.bootstrap.present=true
 [echo] ldap.present=true
 [echo] modeler.present=true
 [echo] pool.present=true
 [echo] --- Required JARs ---
 [echo] jndi.jar.present(except JDK 1.3+)=${jndi.jar.present}
 [echo] regexp.jar.present=${regexp.jar.present}
 [echo] servlet-api.jar.present=true
 [echo] xerces2.jars.present(except JDK 1.4+)=true
 [echo] --- Optional JARs ---
 [echo] dbcp.jar.present=true
 [echo] fileupload.jar.present=true
 [echo] jaas.jar.present=${jaas.jar.present}
 [echo] javamail.jar.present=${javamail.jar.present}
 [echo] jmx.jar.present=true
 [echo] jta.jar.present=${jta.jar.present}
 [echo] junit.jar.present=true
 [echo] modeler.jar.present=true
 [echo] pool.jar.present=true
 [echo] --- Conditional compilation flags ---
 [echo] compile.dbcp=true
 [echo] compile.jaas=true
 [echo] compile.javamail=${compile.javamail}
 [echo] compile.jmx=true
 [echo] compile.jndi=true
 [echo] compile.jsse=true
 [echo] compile.jta=${compile.jta}
 [echo] compile.junit=true
 [echo] compile.ldap=true
 [echo] compile.ssi=true
 [echo] --- Distribution flags ---
 [echo] copy.dbcp.jar=true
 [echo] copy.jmx.jar=true
 [echo] copy.launcher.jars=true
 [echo] copy.logging.jar=true
 [echo] copy.modeler.jar=true
 [echo] copy.pool.jar=true

build-prepare:

copy-fileupload.jar:

copy-launcher.jars:

copy-modeler.jar:

build-static:
 [echo]  ==building-static contents ==

build-tomcat-util:
 [echo]  --tomcat-util.home /home/amila/projects/apache-
tomcat-5.5.15-src/build/../connectors/util
 [echo]  tomcat-util.build
/home/amila/projects/apache-tomcat-5.5.15-src/build/build


detect:

build-prepare:

tomcat-util.jar:
 [echo] - Java-utils -
 [echo] -- puretls.present = ${puretls.present}
 [echo] -- jsse.present = true /home/amila/share/java/jsse-1.0.3
/lib/jsse.jar
 [echo] -- commons-logging = true
 [echo] -- jmx = true /home/amila/share/java/mx4j-3.0.1/lib/mx4j.jar
 [echo] -- modeler = true /home/amila/share/java/commons-modeler-1.1
/commons-modeler.jar
 [echo] -- skip.digester = ${skip.digester}
 [echo] -- JDK14 = true
 [echo] -- JDK15 = true
 [echo] -- tomcat-jini-jar = /home/amila/projects/apache-
tomcat-5.5.15-src/build/../connectors/jk/build/lib/tomcat-jni.jar
[javac] Compiling 94 source files to /home/amila/projects/apache-
tomcat-5.5.15-src/connectors/util/build/classes
[javac] 
/home/amila/projects/apache-tomcat-5.5.15-src/connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java:26:
package org.apache.tomcat.jni does not exist
[javac] import org.apache.tomcat.jni.OS;
[javac]  ^
[javac] 
/home/amila/projects/apache-tomcat-5.5.15-src/connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java:27:
package org.apache.tomcat.jni does not exist
[javac] import org.apache.tomcat.jni.Address;
[javac]  ^
[javac] 
/home/amila/projects/apache-tomcat-5.5.15-src/connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java:28:
package org.apache.tomcat.jni does not exist
[javac] import org.apache.tomcat.jni.Error;
[javac]  ^
[javac] 
/home/amila/projects/apache-tomcat-5.5.15-src/connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java:29:
package org.apache.tomcat.jni does not exist

then I put the following two