DO NOT REPLY [Bug 34614] New: - Differentiate between global JAR files and those used by webapp config.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=34614

   Summary: Differentiate between global JAR files and those used by
webapp config.xml
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


To my understanding, any JAR file placed in common/lib becomes global and all
webapps automatically see them in their classpath. As well, it seems that a
webapp's configuration file (conf/.../*.xml) requires a specific JAR in its
classpath -- such as a DB driver -- then it must be located in the global JAR
repository as well.

I am asking that we differentiate between JARs referred to by configuration
files and those that are *meant* to be global across all webapps. The problem is
that all too often we are forced to place JAR files in common/lib because our
configuration files refer to them but then this causes conflicts between
applications. One application might require one version of the JAR while another
might require another -- or some application shouldn't see a certain JAR at all
on its classpath because then it might decide to use it when we don't want it 
to.

Anyway, I think you get my point. Is there a trivial workaround for this
problem? If not, any idea on how to solve it?

Thank you,
Gili

-- 
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: JK Releasing 1.2.11/1.2.12

[William A. Rowe, Jr.]

At 06:38 AM 4/25/2005, Mladen Turk wrote:
>Peter Rossbach wrote:
>>that is a very shot time period for testing.
>
>Well, some of the things are really critical, so that's the reason.

I think that 1.2.8/1.2.9 proved that haste creates this churn.

Once 1.2.11 is ready, isn't it sufficient to point users at that
test version for 2 - 4 weeks, until it truly settles out?  Nothing
but critical/proven bug fixes between .11 and .12?

If they couldn't get the code I'd agree with the fast turnaround,
but once 1.2.11 exists, the point is, they can.

We've burned the users with deprecating mod_jk2.  Generating churn 
in mod_jk (as opposed to solid, stable releases) will only continue
to lessen users' faith in jk as a production solution.

Bill



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

difference between tomcat 5.0 and tomcat 5.5

[Remo rahman]

can any one plz provide me with information regarding
diference between tomcat 5.0 and tomcat 5.5
some of the differences that i have noted are
1)no entry of context in server.xml-
so where this entry should be made
2)no logger component in server.xml

and also related to tomcat manager application
what should be the entry when we are Deploying directory or WAR file
located on server in
1)Context Path
2)XML Configuration file URL
i will be very thankful if any one can help me

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

DO NOT REPLY [Bug 34587] - JDTCompiler can not resolve package org.foo when class org.Foo exists

[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=34587





--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 07:22 ---
(In reply to comment #2)
> The Tomcat webapp classloader classloader is always case sensitive on all
> platforms. The URL classloader which is its parent might not be (it's the
> regular one from the JVM, and I don't really know how it works). You're going 
> to
> have to provide more details.
Blaming the classloader was maybe not such a good idea. After some debugging I
am not so sure that the isPackage method is the real source of this bug. Anyway,
I'm no expert in compilers and will refrain from further guessing.
What I do know is that this bug was found when running Tomcat 5.5.9 with Java
1.5 in Eclipse 3.0.1. What kind of details do you need to know?


-- 
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: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:
Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit to easy.
 Sticky session is the only way for the most applications to be consistens.
 Session replication is only a secondary feature when failure occured.
Why we can't add a flag that deactive a worker or change the semantic of 
disable?
Then all request goes to the other replication members in a cluster 
domain and restarting
is easy without risk and waiting time.

Are you sure this is absolute necessity?
I agree something like that might be usable on a development server,
but on a production server? I'm not sure if your users will be happy
with loosing sessions in a middle of a transaction or order.
Again, disable works as expected. It will preserve exiting sessions
until session times out. When all existing sessions are gone, then you
can do with that node what ever you wish.
If you do not wish to wait, then simply disable and kill that instance.
The existing sessions will be failovered to another node with loosing
session data.
I see no reason whatsoever for introducing another 'immediate disable'
flag to the worker.
Regards,
Mladeb.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

difference between tomcat 5.0 and tomcat 5.5

[Remo rahman]

can any one plz provide me with information regarding
diference between tomcat 5.0 and tomcat 5.5
some of the differences that i have noted are
1)no entry of context in server.xml-
so where this entry should be made
2)no logger component in server.xml

and also related to tomcat manager application
what should be the entry when we are Deploying directory or WAR file
located on server in
1)Context Path 
2)XML Configuration file URL
i will be very thankful if any one can help me

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

DO NOT REPLY [Bug 34611] New: - Logging in servlet/jsp not working via java.util.logging.Logger.global

[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=34611

   Summary: Logging in servlet/jsp not working via
java.util.logging.Logger.global
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


If you have a servlet/jsp which uses java.util.logging. Logger.global
and use the global logger, the output seems to go nowhere.

For example the following jsp page only logs "printed".

<%
  java.util.logging.Logger.global.severe("not printed");
  java.util.logging.Logger.getLogger("foo").severe("printed");
%>


FYI, this is with Tomcat 5.5.9 using the default settings.  As you can
imagine, this is a little disturbing!

-- 
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 34610] New: - the present is :ERROR ManagerBase:434 - IOException while loading persisted sessions when i started tomcat in jbuilder2005

[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=34610

   Summary: the present is :ERROR ManagerBase:434 - IOException
while loading persisted sessions when i started tomcat
in jbuilder2005
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P5
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm developing with jbuilder2005 which uses tomcat5.0.27 as it's app server.I 
create a project named MyProject and create a class named Token:

package mypackage;
public class Token{
  private String name;
  
  public String getName(){
 return name;
  }

  public void setName(String name){
 this.name=name;
  }
}
 
It presents "ERROR ManagerBase:434 - IOException while loading persisted 
sessions: mypackage.Token" at more time but not always at each time when i 
restart tomcat.

-- 
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 34609] New: - the present is :ERROR ManagerBase:434 - IOException while loading persisted sessions when i started tomcat in jbuilder2005

[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=34609

   Summary: the present is :ERROR ManagerBase:434 - IOException
while loading persisted sessions when i started tomcat
in jbuilder2005
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P5
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm developing with jbuilder2005 which uses tomcat5.0.27 as it's app server.I 
create a project named MyProject and create a class named Token:

package mypackage;
public class Token{
  private String name;
  
  public String getName(){
 return name;
  }

  public void setName(String name){
 this.name=name;
  }
}
 
It presents "ERROR ManagerBase:434 - IOException while loading persisted 
sessions: mypackage.Token" at more time but not always.

-- 
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 32604] - Some httpHeaders can be lost in response

[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=32604


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||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]

DO NOT REPLY [Bug 32604] - Some httpHeaders can be lost in response

[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=32604


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Response.java

[luehe]

luehe   2005/04/25 15:06:30

  Modified:catalina/src/share/org/apache/catalina/connector
Response.java
  Log:
  Fix for Bugzilla 32604 ("Some httpHeaders can be lost in response").
  
  Fix assumes that SRV.5.5, 2nd bullet, will be amended in the upcoming
  Servlet Maintenance release, as follows:
  
The amount of content specified in the setContentLength method of the
response [ADD: has been greater than zero] and has been written to the
response
  
  Revision  ChangesPath
  1.12  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java
  
  Index: Response.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Response.java 31 Mar 2005 10:31:53 -  1.11
  +++ Response.java 25 Apr 2005 22:06:30 -  1.12
  @@ -315,7 +315,7 @@
*/
   public boolean isAppCommitted() {
   return (this.appCommitted || isCommitted() || isSuspended()
  -|| ((getContentLength() != -1) 
  +|| ((getContentLength() > 0) 
   && (getContentCount() >= getContentLength(;
   }
   
  
  
  

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

ant installer target

[Gary Orser]

Not finding any clues in the archives or web...

I've been struggling with trying to get the ant "installer" target to
work.  (tried both 5.5.9 tarball and build.xml cvs checkout).  I've tried
this both with cygwin, and cmd.exe (ugh!).  Both produce similar results.

In debugging this I've discovered that the installer target should have a 
depends="prepare-release".  Additionally, the target doesn't copy many 
files that it needs from ./build and other places to ./dist.

Is this target supposed to work?

How is the .exe distribution being created that is on the tomcat website?  

Has nsis been deprecated?

Is there some reference/howto that describes this process better?

Am I missing something fundamental here?...

PS.  I had originally thought that this would be a cool way to have a
point and click installer for our webapp that needs to be installed as a
service.  Just include our app in webapps, change filenames,
descriptions,banners, and away we go...  I guess nothing is ever that
simple.

Cheers, Gary
--
Gary Orser 
Montana State University
Department of Cell Biology and Neuroscience
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717

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

Re: Tomcat and APR

[Jason Brittain]

Remy Maucherat wrote:
Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Yes.
I did:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# export 
CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar

and then started it again, and it still didn't find JMX (same message
in catalina.out).  If that's what you meant, it didn't work.
CLASSPATH is obviously ignored. This has been like that for years.
At first I thought that was the case, so I had a brief look in 5.5.9's
catalina.sh script and found this:
# Add on extra jar files to CLASSPATH
if [ -n "$JSSE_HOME" ]; then
  
CLASSPATH="$CLASSPATH":"$JSSE_HOME"/lib/jcert.jar:"$JSSE_HOME"/lib/jnet.jar:"$JSSE_HOME"/lib/jsse.jar
fi
CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar:"$CATALINA_HOME"/bin/commons-logging-api.jar
... which is used farther down like:
"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
  -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
...
It must not have the effect on the JVM that I thought it may.
So then to what classpath should I add jmx.jar?
--
Jason Brittain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and APR

[Remy Maucherat]

Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Yes.
I did:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# export 
CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar

and then started it again, and it still didn't find JMX (same message
in catalina.out).  If that's what you meant, it didn't work.
CLASSPATH is obviously ignored. This has been like that for years.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and APR

[Jason Brittain]

Remy Maucherat wrote:
Jason Brittain wrote:
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
Maybe there's a regression. It used to work long before 1.1.5 anyway, 
I'm curious to know which version of Tomcat ran like that.  I've tried
more than a few versions.
but it could be that the classpath generation using the manifest from 
JARs doesn't work (it does in gij, where you can do a -jar 
bin/boostrap.jar). So add jmx.jar and tomcat-juli.jar to the classpath 
to fix it.
Just so you know, I unjarred bootstrap.jar (from 5.5.9) and here's what
the manifest looks like:
[EMAIL PROTECTED] bootstrap]# cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.)
Main-Class: org.apache.catalina.startup.Bootstrap
Specification-Title: Catalina
Specification-Version: 1.0
Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar tomcat-
 juli.jar
Notice the "tomcat-\r juli.jar" in there!
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Yes.
I did:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# export 
CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar
and then started it again, and it still didn't find JMX (same message
in catalina.out).  If that's what you meant, it didn't work.
--
Jason Brittain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit to easy.
 Sticky session is the only way for the most applications to be consistens.
 Session replication is only a secondary feature when failure occured.
Why we can't add a flag that deactive a worker or change the semantic of 
disable?
Then all request goes to the other replication members in a cluster 
domain and restarting
is easy without risk and waiting time.

Peter
Mladen Turk schrieb:
Mladen Turk wrote:
Peter Rossbach wrote:
Hmm, that disabling feature not work at my configuration.
worker.node2.domain=A
You don't need a domain unless you have a session replication
Or you can just set jvmRoute="A" on each tomcat instance,
make session replication, and then your config will work instantly
when you disable one of the workers.
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]

Re: Tomcat and APR

[Remy Maucherat]

Jason Brittain wrote:
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
Maybe there's a regression. It used to work long before 1.1.5 anyway, 
but it could be that the classpath generation using the manifest from 
JARs doesn't work (it does in gij, where you can do a -jar 
bin/boostrap.jar). So add jmx.jar and tomcat-juli.jar to the classpath 
to fix it.

"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34605] New: - Ignore https chain with the ant deployment tasks

[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=34605

   Summary: Ignore https chain with the ant deployment tasks
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Manager
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


It would be nice if the ant task could ignore the https validation chain when
deploying to a server. This can be easily done with the following code:

  SSLContext sc = SSLContext.getInstance("SSL");

  // Create empty HostnameVerifier
  HostnameVerifier hv = new HostnameVerifier() {
public boolean verify(String urlHostName, SSLSession session) {
  System.err.println("Warning: URL Host: " + urlHostName + " vs. "
  + session.getPeerHost());
  return true;
}

  };
  // Create a trust manager that does not validate certificate chains
  TrustManager[] trustAllCerts = new TrustManager[] { new 
X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
  return null;
}

public void checkClientTrusted(java.security.cert.X509Certificate[] 
certs,
String authType) {
}

public void checkServerTrusted(java.security.cert.X509Certificate[] 
certs,
String authType) {
}
  } };

  sc.init(null, trustAllCerts, new java.security.SecureRandom());
  SSLSocketFactory sslSocketFactory = sc.getSocketFactory();

  HttpsURLConnection.setDefaultSSLSocketFactory(sslSocketFactory);
  HttpsURLConnection.setDefaultHostnameVerifier(hv);

-- 
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: Tomcat and APR

[Jason Brittain]

Remy Maucherat wrote:
Jason Brittain wrote:
Nope:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start
Using CATALINA_BASE:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_HOME:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp
Using JRE_HOME:   /usr/local/kaffe
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# cd logs
[EMAIL PROTECTED] logs]# more catalina.out
WARNING: System property "java.util.logging.manager" should be the 
name of a subclass of java.util.logging.LogManager
If for some reason the java.util.logging impl isn't compatible with 
classpath, remove it (delete tomcat-juli.jar).
Okay.  I did that, and tried it again.  Now it doesn't give that warning, 
but
Tomcat still fails to run in the same way.
For the rest, install the compat package.
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
--
Jason Brittain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and APR

[Remy Maucherat]

Jason Brittain wrote:
Nope:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start
Using CATALINA_BASE:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_HOME:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp
Using JRE_HOME:   /usr/local/kaffe
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# cd logs
[EMAIL PROTECTED] logs]# more catalina.out
WARNING: System property "java.util.logging.manager" should be the name 
of a subclass of java.util.logging.LogManager
If for some reason the java.util.logging impl isn't compatible with 
classpath, remove it (delete tomcat-juli.jar).
For the rest, install the compat package.

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

Re: Tomcat and APR

[Jason Brittain]

Remy Maucherat wrote:
Jason Brittain wrote:
Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance and reliability on free JVMs
This sounds as though you're implying that Tomcat already runs on one or
more free JVM.  Which ones?  And, any particular version?
gij-4.0 (so gcjing portions should work), 
I haven't tried this one yet.  It'll require some time to set up properly.
kaffe 1.1.5, 
Nope:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start
Using CATALINA_BASE:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_HOME:   /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp
Using JRE_HOME:   /usr/local/kaffe
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# cd logs
[EMAIL PROTECTED] logs]# more catalina.out
WARNING: System property "java.util.logging.manager" should be the name of a 
subclass of java.util.logging.LogManager
This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page.
[EMAIL PROTECTED] logs]# java -version
Kaffe Virtual Machine
Copyright (c) 1996-2004 Kaffe.org project contributors (please see
  the source code for a full list of contributors).  All rights reserved.
Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc.
The Kaffe virtual machine is free software, licensed under the terms of
the GNU General Public License.  Kaffe.org is a an independent, free software
community project, not directly affiliated with Transvirtual Technologies,
Inc.  Kaffe is a Trademark of Transvirtual Technologies, Inc.  Kaffe comes
with ABSOLUTELY NO WARRANTY.
Engine: Just-in-time v3   Version: 1.1.5   Java Version: 1.1
... And, this is *with* Tomcat's compat package installed properly.  This may
just be a bug in Tomcat's J2SE 5.0 detection code (bad expectations w.r.t. free
JVMs?).  Or, maybe kaffe just doesn't implement what we know we need?  Either
way, it doesn't work.
probably others.
I wish I knew.  None have worked so far for me.
[snip]
Well, if you try the only VM which doesn't work ;)
No, like I said, I tried several brands & versions.
--
Jason Brittain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Mladen Turk wrote:
Peter Rossbach wrote:
Hmm, that disabling feature not work at my configuration.
worker.node2.domain=A
You don't need a domain unless you have a session replication
Or you can just set jvmRoute="A" on each tomcat instance,
make session replication, and then your config will work instantly
when you disable one of the workers.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:
Hmm, that disabling feature not work at my configuration.
worker.node2.domain=A
You don't need a domain unless you have a session replication
What is wrong at my mod_jk configuration?
worker.xxx.sticky_session=false
All sticky sessions will need to timeout, and
then you can restart your tomcat, not before.
All new sessions will never go to the disabled host,
but the existing one will be preserved because of
sticky_session set to on by default.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hmm, that disabling feature not work at my configuration.
I have made a test with current Tomcat head and mod_jk 1.2.10.
===
worker.list=lb,status
worker.node1.port=9012
worker.node1.host=127.0.0.1
worker.node1.type=ajp13
worker.node1.cachesize=200
worker.node1.cache_timeout=60
worker.node1.disabled=false
worker.node1.domain=A
worker.node2.port=9022
worker.node2.host=127.0.0.1
worker.node2.type=ajp13
worker.node2.cachesize=200
worker.node2.cache_timeout=60
worker.node2.disabled=false
worker.node2.domain=A
worker.lb.balance_workers=node1,node2
worker.lb.type=lb
worker.status.type=status
===
Setup to tomcat behind Apache 2.0.53 ( Windows XP)
When I open browser send a request that open a session.
Verify that next request goes to the same tomcat.
disable tomcat/worker from which node request coming.
Request again the same request and see that request goes to the
same worker.
Next test with remove the domain feature,
and also test it with a fresh compile cvs head,
but also it not working.
What is wrong at my mod_jk configuration?
Peter

Mladen Turk schrieb:
Peter Rossbach wrote:
Hello Mladen ,
What I want is, that we can stop request sending from mod_jk side
at a single node. Why we can't stop all requests for a worker, when we
set a flag worker.node1.active=false ? Ok, then no application
on this node get request, but we can control the tomcat restart.
You have woker.node1.disabled=True directive.
It will disable the worker in case it's member of load balancer,
and no furher requests will took place on it unless referenced by
some other worker with 'redirect' and not in error state.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
J2EE Systemarchitekt und Tomcat Experte
http://objektpark.de/
http://tomcat.objektpark.org/
http://centaurus.sourceforge.net/
Am Josephsschacht 72, 44879 Bochum, Deutschland
Telefon:  (49) 234 9413228
Mobil:(49) 175 1660884
E-Mail:  [EMAIL PROTECTED]

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

Re: Tomcat and APR

[Remy Maucherat]

Jason Brittain wrote:
Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance and reliability on free JVMs
This sounds as though you're implying that Tomcat already runs on one or
more free JVM.  Which ones?  And, any particular version?
gij-4.0 (so gcjing portions should work), kaffe 1.1.5, probably others.
All of them that I have tried can't run Tomcat.  Before, it was just that
they each used the GNU Classpath core classes, which were (still are?) too
incomplete, and even though the required classes were found and loaded, 
they
were either incomplete (missing some methods for instance), or they were 
wrong
somehow and caused random fatal startup problems.  Most of the problems 
seemed
to have to do with either reflection or JMX or both.  Here's how my last 
attempt
went (SableVM Version 1.1.10):

[EMAIL PROTECTED] jakarta-tomcat-5.5.8-with-compat]# java-sablevm 
-Djava.endorsed.dirs=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/common/endorsed 
-classpath 
:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/bootstrap.jar:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/commons-logging-api.jar 
-Dcatalina.base=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat 
-Dcatalina.home=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat 
-Djava.io.tmpdir=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/temp 
org.apache.catalina.startup.Bootstrap start Created MBeanServer with ID: 
[UID: 8594076,1109751203829,-32768]:localhost.localdomain:1
java.lang.IllegalArgumentException: argument of incorrect type
   at java.lang.reflect.Method.invoke (Method.java:461)
   at org.apache.catalina.startup.Bootstrap.setAwait (Bootstrap.java:337)
   at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:407)
   at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
   at java.lang.VirtualMachine.main (VirtualMachine.java:108)

So, I'm still looking for even one free/OSS JVM that is capable of
running Tomcat.
Well, if you try the only VM which doesn't work ;)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and APR

[Jason Brittain]

Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance and reliability on free JVMs
This sounds as though you're implying that Tomcat already runs on one or
more free JVM.  Which ones?  And, any particular version?
All of them that I have tried can't run Tomcat.  Before, it was just that
they each used the GNU Classpath core classes, which were (still are?) too
incomplete, and even though the required classes were found and loaded, they
were either incomplete (missing some methods for instance), or they were wrong
somehow and caused random fatal startup problems.  Most of the problems seemed
to have to do with either reflection or JMX or both.  Here's how my last attempt
went (SableVM Version 1.1.10):
[EMAIL PROTECTED] jakarta-tomcat-5.5.8-with-compat]# java-sablevm 
-Djava.endorsed.dirs=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/common/endorsed
 -classpath 
:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/bootstrap.jar:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/commons-logging-api.jar
 -Dcatalina.base=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat 
-Dcatalina.home=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat 
-Djava.io.tmpdir=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/temp 
org.apache.catalina.startup.Bootstrap start Created MBeanServer with ID: [UID: 
8594076,1109751203829,-32768]:localhost.localdomain:1
java.lang.IllegalArgumentException: argument of incorrect type
   at java.lang.reflect.Method.invoke (Method.java:461)
   at org.apache.catalina.startup.Bootstrap.setAwait (Bootstrap.java:337)
   at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:407)
   at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
   at java.lang.VirtualMachine.main (VirtualMachine.java:108)
So, I'm still looking for even one free/OSS JVM that is capable of
running Tomcat.
--
Jason Brittain

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

Re: DO NOT REPLY [Bug 32604] - Some httpHeaders can be lost in response

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 18:07 ---
One (probably unintended) side effect of SRV.5.5, 2nd bullet, is that
even when response.setContentLength(0) is not called explicitly, but
the response's content length is set to 0 via
response.setHeader("Content-Length", "0"), as in the following code
snippet:
  response.setHeader("Host", "localhost");
  response.setHeader("Pragma", "nocache");
  response.setHeader("Content-Length", "0");
  response.setHeader("location", "http://www.apache.org";);
any subsequently setHeader() calls are ignored.
This is not intuitive, because HTTP response headers should be
settable in any order.
I suggest we amend SRV.5.5, 2nd bullet, in the upcoming Servlet Maintenance
release, as follows:
  The amount of content specified in the setContentLength method of the
  response [ADD: has been greater than zero] and has been written to the
  response
Unless there are any objections, I am going to apply the following
patch:
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java,v
retrieving revision 1.11
diff -u -r1.11 Response.java
--- Response.java   31 Mar 2005 10:31:53 -  1.11
+++ Response.java   25 Apr 2005 16:03:48 -
@@ -315,7 +315,7 @@
  */
 public boolean isAppCommitted() {
 return (this.appCommitted || isCommitted() || isSuspended()
-|| ((getContentLength() != -1) 
+|| ((getContentLength() > 0) 
 && (getContentCount() >= getContentLength(;
 }
+1.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32604] - Some httpHeaders can be lost in response

[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=32604





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 18:07 ---
One (probably unintended) side effect of SRV.5.5, 2nd bullet, is that
even when response.setContentLength(0) is not called explicitly, but
the response's content length is set to 0 via
response.setHeader("Content-Length", "0"), as in the following code
snippet:

  response.setHeader("Host", "localhost");
  response.setHeader("Pragma", "nocache");
  response.setHeader("Content-Length", "0");
  response.setHeader("location", "http://www.apache.org";);

any subsequently setHeader() calls are ignored.

This is not intuitive, because HTTP response headers should be
settable in any order.

I suggest we amend SRV.5.5, 2nd bullet, in the upcoming Servlet Maintenance
release, as follows:

  The amount of content specified in the setContentLength method of the
  response [ADD: has been greater than zero] and has been written to the
  response

Unless there are any objections, I am going to apply the following
patch:

Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java,v
retrieving revision 1.11
diff -u -r1.11 Response.java
--- Response.java   31 Mar 2005 10:31:53 -  1.11
+++ Response.java   25 Apr 2005 16:03:48 -
@@ -315,7 +315,7 @@
  */
 public boolean isAppCommitted() {
 return (this.appCommitted || isCommitted() || isSuspended()
-|| ((getContentLength() != -1) 
+|| ((getContentLength() > 0) 
 && (getContentCount() >= getContentLength(;
 }

Please let me know.


Jan

-- 
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: DO NOT REPLY [Bug 34603] New: - Tomcat adding none .jar files to classp...

[Mbarn680]

Do not send me anymore email information.  Thank You

DO NOT REPLY [Bug 34603] New: - Tomcat adding none .jar files to classpath when compiling JSPs

[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=34603

   Summary: Tomcat adding none .jar files to classpath when
compiling JSPs
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a properties file for a third party extension in the directory
jre/lib/ext of my JDK distribution which is version 1.5. When I deploy a WAR
file and tomcat attempts to compile the JSPs which are associated with that WAR,
it includes the .properties file as part of the compile path to the java
compiler and as such fails. 


Apr 25, 2005 2:04:02 PM org.apache.jasper.compiler.Compiler generateClass
SEVERE: Env: Compile:
javaFileName=/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/work/Catalina/localhost/FilterDatabase//org/apache/jsp/astronomer/ManageBlank_jsp.java
   
classpath=/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/classes/:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/activation.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-beanutils.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-collections.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-dbcp-1.1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-el.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-fileupload-1.0-beta-1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-pool-1.1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabas
 
e/WEB-INF/lib/imap.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/jcommon-0.8.0.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/jfreechart-0.9.8.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/mail.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/mailapi.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/pop3.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/smtp.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/work/Catalina/localhost/FilterDatabase:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/classes/:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/activation.jar:/wht/ObservingSystemSupport
 
Packages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-beanutils.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-collections.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-dbcp-1.1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-el.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-fileupload-1.0-beta-1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/commons-pool-1.1.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/imap.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/jcommon-0.8.0.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/jfreechart-0.9.
 
8.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/mail.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/mailapi.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/pop3.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/webapps/FilterDatabase/WEB-INF/lib/smtp.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/shared/classes/:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/common/classes/:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16/common/endorsed/xercesImpl.jar:/wht/ObservingSystemSupportPackages/jakarta-tomcat-5.0.16

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

Ok :)

2005/4/25, Mladen Turk <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> >
> > Well HTTPD team didn't make this odd/even versioning :)
> >
> 
> Yes I know ;)
> >
> > So the CHANGES.txt and BUILDING will be generated by you at YOUR build
> > time and included in the final source archive ?
> >
> 
> Well, If I succeed to make an ant task that will generate formated .txt
> along with .html, then it would be generate by jkrelease.sh. If not,
> I'll just update those files.
> 
> 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]

RE:'Vhi=076-554'Re: JK Releasing 1.2.11/1.2.12

[Vhi Healthcare]

Thank you for your email enquiry. It is our aim to issue a reply within one 
working day.

If you wish to speak to one of our customer service advisors in the meantime 
you can do so by ringing our call save number – 1850 44 44 44.

Alternatively you may wish to access our website at  http://www.vhi.ie.

For any further contacts please quote 76554, which is the unique interaction 
I.D. associated with your email enquiry.

Kind Regards
Customer Service Department 



-Original Message-
From:   Henri Gomez  [EMAIL PROTECTED]
Sent:   Monday, Apr 25 2005 2:10PM
To: Tomcat Developers List [EMAIL PROTECTED]
Subject:Re: JK Releasing 1.2.11/1.2.12

2005/4/25, Mladen Turk <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > Just make a 1.2.11-dev available and if it works, release the 1.2.11
> >
> 
> Yes, I was trying to make a odd/even versioning, but seems it does not
> mater.

Well HTTPD team didn't make this odd/even versioning :)

> Also how about dropping the documentation build from the source
> distribution, as well as ant build files.

> I can made some automated CHANGES.txt from the changelog.xml,
> as well as BUILDING from install/apache1.xml, install/apache2.xml
> and install/iis.xml, as well as STATUS.txt from news/*.xml
> 
> This way we would have a small subset of textual docs while
> maintaining only XML documentation.

So the CHANGES.txt and BUILDING will be generated by you at YOUR build
time and included in the final source archive ?

No problem for me

-
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: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Henri Gomez wrote:
Well HTTPD team didn't make this odd/even versioning :)
Yes I know ;)
So the CHANGES.txt and BUILDING will be generated by you at YOUR build
time and included in the final source archive ?
Well, If I succeed to make an ant task that will generate formated .txt
along with .html, then it would be generate by jkrelease.sh. If not,
I'll just update those files.
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

2005/4/25, Mladen Turk <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > Just make a 1.2.11-dev available and if it works, release the 1.2.11
> >
> 
> Yes, I was trying to make a odd/even versioning, but seems it does not
> mater.

Well HTTPD team didn't make this odd/even versioning :)

> Also how about dropping the documentation build from the source
> distribution, as well as ant build files.

> I can made some automated CHANGES.txt from the changelog.xml,
> as well as BUILDING from install/apache1.xml, install/apache2.xml
> and install/iis.xml, as well as STATUS.txt from news/*.xml
> 
> This way we would have a small subset of textual docs while
> maintaining only XML documentation.

So the CHANGES.txt and BUILDING will be generated by you at YOUR build
time and included in the final source archive ?

No problem for me

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

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Henri Gomez wrote:
Just make a 1.2.11-dev available and if it works, release the 1.2.11 

Yes, I was trying to make a odd/even versioning, but seems it does not
mater.
Also how about dropping the documentation build from the source 
distribution, as well as ant build files.
I can made some automated CHANGES.txt from the changelog.xml,
as well as BUILDING from install/apache1.xml, install/apache2.xml
and install/iis.xml, as well as STATUS.txt from news/*.xml

This way we would have a small subset of textual docs while
maintaining only XML documentation.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Jakarta-site-2

[Mladen Turk]

Yoav Shapira wrote:
It's not your karma that's the issue ;)  Jakarta-site2 was moved to SVN a
while ago.  It now lives at https://svn.apache.org/repos/asf/jakarta/site.
He he. Cool.
It shows how much I'm committing to the documentation ;)
I've applied a slightly modified version of your patch to the
Thanks,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:
Hello Mladen ,
What I want is, that we can stop request sending from mod_jk side
at a single node. Why we can't stop all requests for a worker, when we
set a flag worker.node1.active=false ? Ok, then no application
on this node get request, but we can control the tomcat restart.
You have woker.node1.disabled=True directive.
It will disable the worker in case it's member of load balancer,
and no furher requests will took place on it unless referenced by
some other worker with 'redirect' and not in error state.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Peter Rossbach]

OK, I read the changes and I also want a next release :-)
Peter
PS: Start testing with the current code base at windows xp and suse 9.3
Mladen Turk schrieb:
Peter Rossbach wrote:
that is a very shot time period for testing.

Well, some of the things are really critical, so that's the reason.
I can start some test not before monday next week, but I setup a new 
server today a
start with testing with jk cvs head.

Well, It will be not be advertised as stable until enough votes
are collected. This of course does not prevent users from using
the new version that fixes the present bugs.
We can always release a version and if not voted as stable, just bump
to another one. The current head contains some significant bug fixes,
and if some others get found during the testing period
(this week basically), we can easily go to the next version.
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]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hello Mladen ,
yes Remy, we have currently no chance inside tomcat.  :-(
My szenario is really important when automatic alive monitoring
detect that inside an application or node is something wrong (Out Of 
Memory Exception,
all thread hang, detect a deadlock or other nice application relevant 
bugs/feature)

What I want is, that we can stop request sending from mod_jk side
at a single node. Why we can't stop all requests for a worker, when we
set a flag worker.node1.active=false ? Ok, then no application
on this node get request, but we can control the tomcat restart.
Peter
Remy Maucherat schrieb:
Mladen Turk wrote:
I think that this is the Tomcat responsibility.
If inside redeployment, it should hold the request until finished.
For mod_jk you can set the socket_timeout that will cause the
failover to another worker (if redeployment takes more then 60 seconds).

There is no way to hold a particular request.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

RE: [PATCH] Jakarta-site-2

[Yoav Shapira]

Hi,

> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 25, 2005 3:04 AM
> To: Tomcat Developers List
> Subject: [PATCH] Jakarta-site-2
> 
> Hi,
> Seems I'm missing the karma for jakarta-site-2.
> Here is the patch for sourceindex.xml
> 
> I would be pleased if someone can spare a moment an commit those :).

It's not your karma that's the issue ;)  Jakarta-site2 was moved to SVN a
while ago.  It now lives at https://svn.apache.org/repos/asf/jakarta/site.
Jakarta-site2 in CVS is locked off, and binindex/sourceindex, etc are no
longer live.

I've applied a slightly modified version of your patch to the
site/xdocs/downloads/downloads.xml file under the above SVN repository,
committed the patch, and updated the site on minotaur.  It might take a
little while to reflect in the live site.

Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
[EMAIL PROTECTED] / [EMAIL PROTECTED]


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

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

Just make a 1.2.11-dev available and if it works, release the 1.2.11 

2005/4/25, Mladen Turk <[EMAIL PROTECTED]>:
> Peter Rossbach wrote:
> > that is a very shot time period for testing.
> 
> Well, some of the things are really critical, so that's the reason.
> 
> > I can start some test not before monday next week, but I setup a new
> > server today a
> > start with testing with jk cvs head.
> >
> 
> Well, It will be not be advertised as stable until enough votes
> are collected. This of course does not prevent users from using
> the new version that fixes the present bugs.
> 
> We can always release a version and if not voted as stable, just bump
> to another one. The current head contains some significant bug fixes,
> and if some others get found during the testing period
> (this week basically), we can easily go to the next version.
> 
> 
> 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 28321] - Memory Leak

[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=28321


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Tomcat JK2 Connector Memory |Memory Leak
   |Leak|




-- 
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: mod_jk problem with domain clustering and restart node or application

[Remy Maucherat]

Mladen Turk wrote:
I think that this is the Tomcat responsibility.
If inside redeployment, it should hold the request until finished.
For mod_jk you can set the socket_timeout that will cause the
failover to another worker (if redeployment takes more then 60 seconds).
There is no way to hold a particular request.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:
Goal
- restart an application at single node
Wow.
Probleme
- How can configure that lb stop traffic for a spezial worker/node and 
for an single application?

I think that this is the Tomcat responsibility.
If inside redeployment, it should hold the request until finished.
For mod_jk you can set the socket_timeout that will cause the
failover to another worker (if redeployment takes more then 60 seconds).
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

One of my problems with clustering are:
Szenario:
- three domains of cluster with two or three tomcat nodes
- have more then one application at this cluster
- all nodes server the same application set
- sticky session on
Goal
- restart an application at single node
Probleme
- How can configure that lb stop traffic for a spezial worker/node and 
for an single application?

my idea: config via uriworkermap.properties
-/myapps/*=node1 or -/myapps/*=loadbalancer.node1
/myapps/*=loadbalancer
- Disable worker stop only the traffic for new session requests, but not 
for all requests.
 new worker config
 worker.node1.active=false
  ( The semantic of disable is a little bit strange for Sticky Session 
mode)

Peter

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

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Peter Rossbach wrote:
that is a very shot time period for testing.
Well, some of the things are really critical, so that's the reason.
I can start some test not before monday next week, but I setup a new 
server today a
start with testing with jk cvs head.

Well, It will be not be advertised as stable until enough votes
are collected. This of course does not prevent users from using
the new version that fixes the present bugs.
We can always release a version and if not voted as stable, just bump
to another one. The current head contains some significant bug fixes,
and if some others get found during the testing period
(this week basically), we can easily go to the next version.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Peter Rossbach]

Hey Mladen,
that is a very shot time period for testing.
I can start some test not before monday next week, but I setup a new 
server today a
start with testing with jk cvs head.

Thanks for write documentation of the status worker :-)
Sorry, but the current cluster implementation changes and testing 
consume a lot of my time.


Peter
Mladen Turk schrieb:
Hi,
There has been some major bug fixes against JK1.2.10.
Critical: 34357 and 34423.
Not so critical: 34358, 33843, 34558, 34577, and some not reported.
See:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
for details.
My plan is to release the 1.2.11 tomorrow as dev version,
and then after 3 days if no bugs found, make a 1.2.12 release,
and vote as stable.
Any objections?
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 34587] - JDTCompiler can not resolve package org.foo when class org.Foo exists

[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=34587


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|blocker |normal




--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 13:01 ---
The Tomcat webapp classloader classloader is always case sensitive on all
platforms. The URL classloader which is its parent might not be (it's the
regular one from the JVM, and I don't really know how it works). You're going to
have to provide more details.

Do you have any ideas for improving the isPackage method ? (otherwise, since I
don't, the bug will end up as wontfix)

-- 
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 34587] - JDTCompiler can not resolve package org.foo when class org.Foo exists

[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=34587





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 12:54 ---
On second thought, the real culprit might be the classLoader used (in
isPackage). Case-insentive on some platforms?

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

JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Hi,
There has been some major bug fixes against JK1.2.10.
Critical: 34357 and 34423.
Not so critical: 34358, 33843, 34558, 34577, and some not reported.
See:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
for details.
My plan is to release the 1.2.11 tomorrow as dev version,
and then after 3 days if no bugs found, make a 1.2.12 release,
and vote as stable.
Any objections?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) 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 jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 115 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-25042005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-25042005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-25042005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-25042005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-25042005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2125042005, brutus:brutus-public:2125042005
Gump E-mail Identifier (unique within run) #17.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

DO NOT REPLY [Bug 32424] - Redirecting directiories with missing trailing slash breaks web applications

[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=32424





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 11:03 ---
(In reply to comment #16)
> This is definitly a structural bug within Tomcat5, Redirection decisions 
> shouldn't be made by Tomcat but by our own application, otherwise we should 
> constrain our architecture to Tomcats own structure?? or be stuck with using 
> T4.1 or another container... this will surely be a recurent bug declaration. 
> I understand if this simplifies T5's structure but is it acceptable to 
> constraint this way? In my use case I call for url : /login an he sends me 
> to /login/ even though I don't even have a login folder and after login 
> instead 
> of redirect to /myurl he blocks me in that context being: /login/myurl which 
> ofcourse makes no sense. 
> Please reconcider this issue. 
> or atleast make it configurable as Roy requests it. 

Unfortunately, the basis for your rant is bad. There will be no redirection of
any sort unless you do have a "login" folder. Otherwise, how do you expect
Tomcat to be able to match a servlet mapped to, say "/test" ?

Indeed, if you do not like this behavior, you should at the moment consider
using another container, or change the code to your liking according to my
indications.

Also, please try to get spelling right. This helps raising credibility of the
person making the statement.


-- 
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 32424] - Redirecting directiories with missing trailing slash breaks web applications

[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=32424





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 10:52 ---
This is definitly a structural bug within Tomcat5, Redirection decisions 
shouldn't be made by Tomcat but by our own application, otherwise we should 
constrain our architecture to Tomcats own structure?? or be stuck with using 
T4.1 or another container... this will surely be a recurent bug declaration. 
I understand if this simplifies T5's structure but is it acceptable to 
constraint this way? In my use case I call for url : /login an he sends me 
to /login/ even though I don't even have a login folder and after login instead 
of redirect to /myurl he blocks me in that context being: /login/myurl which 
ofcourse makes no sense. 
Please reconcider this issue. 
or atleast make it configurable as Roy requests it. 

-- 
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 34577] - IIS 6.0 with isapi_redirect.dll (jk 1.2.10) filter does not log page requests

[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=34577





--- Additional Comments From [EMAIL PROTECTED]  2005-04-25 09:11 ---
(In reply to comment #2)
> Added SF_NOTIFY_LOG for logging original request instead
> logging isapi extension.

I appreciate the immediate response. I aggree with you, it is not a bug, I just
had the impression that this feature existed once upon a time. 
So, how can we get our hands on the new version? Sorry for the impatience, but
this issue has troubled us for a long time. 

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

[PATCH] Jakarta-site-2

[Mladen Turk]

Hi,
Seems I'm missing the karma for jakarta-site-2.
Here is the patch for sourceindex.xml
I would be pleased if someone can spare a moment an commit those :).
Regards,
Mladen
cvs diff -u -- sourceindex.xml (in directory 
C:\U\CVSUP\jakarta-site2\xdocs\site\)
Index: sourceindex.xml
===
RCS file: /home/cvs/jakarta-site2/xdocs/site/sourceindex.xml,v
retrieving revision 1.353
diff -u -r1.353 sourceindex.xml
--- sourceindex.xml 20 Jan 2005 14:49:04 -  1.353
+++ sourceindex.xml 25 Apr 2005 06:59:11 -
@@ -945,16 +945,16 @@
   JK 1.2
 
   
-JK
 1.2.6 Source Release tar.gz
-http://www.apache.org/dist/jakarta/tomcat-connectors/jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz.asc";>PGP
+JK
 1.2.10 Source Release tar.gz
+http://www.apache.org/dist/jakarta/tomcat-connectors/jk/jakarta-tomcat-connectors-current-src.tar.gz.asc";>PGP
   
   
-JK
 1.2.6 Source Release .zip
-http://www.apache.org/dist/jakarta/tomcat-connectors/jk/jakarta-tomcat-connectors-jk-1.2-src-current.zip.asc";>PGP
+JK
 1.2.10 Source Release .zip
+http://www.apache.org/dist/jakarta/tomcat-connectors/jk/jakarta-tomcat-connectors-current-src.zip.asc";>PGP
   
 
   
-  JK 2
+  JK 2 (deprecated)
 
   
 JK2
 2.0.4 Source Release tar.gz

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