DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316

DataSourceRealm can not find JNDI name in context

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows NT/2K   |All
   Platform|PC  |All
Version|4.1.18  |4.1.24

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

DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316

DataSourceRealm can not find JNDI name in context





--- Additional Comments From [EMAIL PROTECTED]  2003-06-12 05:11 ---
I would like to second this last suggestion.  The bug became apparent to me when
I was using securityfilter to complete container-like managed security.  At
first I thought the bug was in securityfilter, but after breaking it back down
to container managed security, I still could not avoid an exception being thrown
due to the JNDI context not being available.  I could obtain a connection to the
datasource using the test case in the realm docs for Tomcat, but not when trying
to use container managed security.  After copying DataSourceRealm to my own
package, changing the lines recommended in the previous post and using the
result, I could authenticate my user.  This is clearly a huge bug rendering the
DataSource realm impossible to use in a specified context.

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

DO NOT REPLY [Bug 16297] - PureTLS failing to initialize

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16297

PureTLS failing to initialize

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-06-12 04:39 ---
Well, at least with TC 5, it does work-for-me (including using openssl certs).  
There haven't really been any changes since TC 4.1, so it should work there as 
well.  

Please re-try with PureTLS-0.9b4, and if you still have problems, try asking on 
tomcat-user for more help.

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls PureTLSSocketFactory.java

[billbarker]

billbarker2003/06/11 21:30:41

  Modified:util/java/org/apache/tomcat/util/net/puretls
PureTLSSocketFactory.java
  Log:
  Add some logging to help track down problems.
  
  The PureTLS/Cryptix error messages can be confusing.  This at least gives a stack 
trace.
  
  Revision  ChangesPath
  1.2   +4 -0  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java
  
  Index: PureTLSSocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PureTLSSocketFactory.java 4 Oct 2002 20:03:10 -   1.1
  +++ PureTLSSocketFactory.java 12 Jun 2003 04:30:41 -  1.2
  @@ -79,6 +79,8 @@
   public class PureTLSSocketFactory
   extends org.apache.tomcat.util.net.ServerSocketFactory
   {
  +static org.apache.commons.logging.Log logger =
  + org.apache.commons.logging.LogFactory.getLog(PureTLSSocketFactory.class);
   static String defaultProtocol = "TLS";
   static boolean defaultClientAuth = false;
   static String defaultKeyStoreFile = "server.pem";
  @@ -172,6 +174,7 @@
tmpContext.setPolicy(policy);
context=tmpContext;
} catch (Exception e){
  + logger.info("Error initializing SocketFactory",e);
throw new IOException(e.getMessage());
}
   }
  @@ -183,6 +186,7 @@
Socket sock=socket.accept();
return sock;
} catch (SSLException e){
  +logger.debug("SSL handshake error",e);
   throw new SocketException("SSL handshake error" + e.toString());
}
   }
  
  
  

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

Re: FAQ location

[Tim Funk]

I just committed the FAQ to jakarta-tomcat-site. Because of the volume of 
data, I got the "ezmlm-reject: fatal: Sorry, I don't accept messages larger 
than 10 bytes (#5.2.3)" message."

-Tim

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

Re: Sessions - bug in Tomcat 4.1.24

[Bill Barker]

- Original Message - 
From: "deacon Marcus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 11, 2003 4:13 PM
Subject: Sessions - bug in Tomcat 4.1.24


> Hello,
> It seems in Tomcat 4.1.24 HttpSession is already invalid when passed to
> HttpSessionListener.sessionDestroyed(), which just does not make sense.
> API Docs say: "public void sessionDestroyed(HttpSessionEvent se)
> Notification that a session is about to be invalidated.", in my opinion
> "about to be" means that the Session should be valid when this method is
> called until it returns.

In my copy of the 2.3 Servlet Spec, section 15.1.14.1 says:
"Notification that a session was invalidated."
I read that as saying that Tomcat's behavior is corrent.

> 
> I think the problem lies within StandardSession.expire method:
> 
> It is:
> 
> public void expire(boolean notify) {
> 
> // Mark this session as "being expired" if needed
> if (expiring)
> return;
> expiring = true;
> setValid(false); // <
> 
> // Remove this session from our manager's active sessions
> [...]
> }
> 
> While I believe (I'm about to test it in next few hours) it should be:
> 
> public void expire(boolean notify) {
> 
> // Mark this session as "being expired" if needed
> if (expiring)
> return;
> expiring = true;
> 
> // Remove this session from our manager's active sessions
> [...]
> // We have completed expire of this session
> setValid(false);   // <<
> expiring = false;
> if ((manager != null) && (manager instanceof ManagerBase)) {
> recycle();
> }
> 
> }
> 
> 
> Greetings, deacon Marcus
> 
> 
> -
> 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]

Sessions - bug in Tomcat 4.1.24

[deacon Marcus]

Hello,
It seems in Tomcat 4.1.24 HttpSession is already invalid when passed to
HttpSessionListener.sessionDestroyed(), which just does not make sense.
API Docs say: "public void sessionDestroyed(HttpSessionEvent se)
Notification that a session is about to be invalidated.", in my opinion
"about to be" means that the Session should be valid when this method is
called until it returns.

I think the problem lies within StandardSession.expire method:

It is:

public void expire(boolean notify) {

// Mark this session as "being expired" if needed
if (expiring)
return;
expiring = true;
setValid(false); // <

// Remove this session from our manager's active sessions
[...]
}

While I believe (I'm about to test it in next few hours) it should be:

public void expire(boolean notify) {

// Mark this session as "being expired" if needed
if (expiring)
return;
expiring = true;

// Remove this session from our manager's active sessions
[...]
// We have completed expire of this session
setValid(false);   // <<
expiring = false;
if ((manager != null) && (manager instanceof ManagerBase)) {
recycle();
}

}


Greetings, deacon Marcus


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

DO NOT REPLY [Bug 5143] - Please allow to specify the cipher set for HTTPS connectors

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5143

Please allow to specify the cipher set for HTTPS connectors





--- Additional Comments From [EMAIL PROTECTED]  2003-06-11 20:48 ---
The patch above is a for 4.1.24

A project I have been working on had a requirement to configure the cipher 
suites used by Tomcat.

A quick search of bugzilla identified this enhancement request so I amended my 
quick and dirty fix to include support for configuring the cipher suites 
through server.xml

Any feedback gratefully received.

Providing the patch is considered appropriate, please could this be committed 
to CVS.

Thanks,

Mark

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

DO NOT REPLY [Bug 5143] - Please allow to specify the cipher set for HTTPS connectors

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5143

Please allow to specify the cipher set for HTTPS connectors





--- Additional Comments From [EMAIL PROTECTED]  2003-06-11 20:40 ---
Created an attachment (id=6770)
PATCH to enable configuration of JSSE cipher suites from server.xml

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

DO NOT REPLY [Bug 20691] New: - Fails to work when new host is added in server.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20691

Fails to work when new host is added in server.xml

   Summary: Fails to work when new host is added in server.xml
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Old Perfect Version : I have been using Tomcat 4.0.3 as multi host web server 
(Web Server with many virtual hosts), on single machine it used to run many 
websites namely www.neurospeech.com , www.iespeaker.com etc as different hosts 
configured in Server.xml

I found new web based admin in Tomcat 4.1.18 onwards so I installed from 
website. Although it did run perfectly for the default WebApps and it runs 
perfectly for any subdirectories inside webapps. But when I add a new host say 
for example www.neurospeech.com and I map it to "d:\NS" folder , this folder 
has ROOT folder and which has index.htm, when typing 
http://www.neurospeech.com:8080, the homepage comes normally. But when we try 
to access files in folder below ROOT it starts giving problems as shown below

1) Trying to access URL
http://www.neurospeech.com:8080/jsp/customers/List.jsp

2) HTTP Information
Host is www.neurospeech.com
path is /jsp/customers/List.jsp

3) Bug in Work Directory Content
Work Directory Content is 
Work/Standalone/www.neurospeech.com/_/sp/customers/List_jsp.class

Carefully note in above path after _ , there is only "sp" instead of "jsp" , I 
noted that in every folder below ROOT , it does not take initial alphabet, I 
had other directory called "admin" , in work directory it showed only "dmin"

Work Directory Content Should Be
Work/Standalone/www.neurospeech.com/_/jsp/customers/List_jsp.class


Details of Error Printed on Browser is as below
HTTP Status 500 - 



type Exception report

message 

description The server encountered an internal error () that prevented it from 
fulfilling this request.

exception 

org.apache.jasper.JasperException: Unable to compile class for JSP
at org.apache.jasper.JspCompilationContext.compile
(JspCompilationContext.java:479)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:184)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(

DO NOT REPLY [Bug 20690] New: - Custom TrustManager for SSL not being used in Tomcat

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20690

Custom TrustManager for SSL not being used in Tomcat

   Summary: Custom TrustManager for SSL not being used in Tomcat
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have coded a custom TrustManger and HostnameVerifier for SSL (actually TLS)
connections from my servlet code to another server.

The code calls the correct methods to setup the Default TrustManager and
HostNameVerifier for an HttpsUrlConnection.

I then use the URL.openConnection() method to instansiate the connection.

Running standalone, this code works perfectly, however running under Tomcat on
the same machine the HttpConnection does not use the custom TustManager that I
coded.

Code to set up default Trust Manager, etc.:

private static void initSSL()
{
  try
  {
TrustManager[] myTM = new TrustManager [] { new ProxyTrustManager() };
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, myTM, null);
SSLSocketFactory sslFactory = ctx.getSocketFactory();
HttpsURLConnection.setDefaultSSLSocketFactory(sslFactory);
HttpsURLConnection.setDefaultHostnameVerifier(new ProxyHostNameVerifier());
  }
  catch (Exception ex)
  {
ex.printStackTrace();
  }
}


Machine Specs.:
Red-Hat Linux 7.1
J2SDK SE 1.4.1_02

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

DO NOT REPLY [Bug 20689] New: - mod_jk2, the /jkstatus page, and apache::worker

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20689

mod_jk2, the /jkstatus page, and apache::worker

   Summary: mod_jk2, the /jkstatus page, and apache::worker
   Product: Tomcat 4
   Version: 4.1.24
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using mod_jk2 with apache in "worker" mode, meaning that there are several 
different httpd processes that stay alive (instead of forking) and are delegated 
requests.  I noticed that when setting a jk2 channel to graceful by updating 
workers2.properties and hitting the /jkstatus page, only one of the "worker" httpd's 
would pick up the change.  Other httpd+mod_jk2 processes would continue to forward 
new sessions to the "graceful" channel.  The solution was to access the /jkstatus page 
repeatedly until every httpd process had served /jkstatus and picked up the changed 
attributes. 
 
If possible, it would be more convenient if accessing /jkstatus a single time would 
cause 
all the httpd workers to check workers2.properties for updates. 
 
Thanks!

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

DO NOT REPLY [Bug 20688] New: - Documentation is misleading for "ver" attribute in workers2.properties

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20688

Documentation is misleading for "ver" attribute in workers2.properties

   Summary: Documentation is misleading for "ver" attribute in
workers2.properties
   Product: Tomcat 4
   Version: 4.1.24
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the documentation for JK2, it suggests that in order for changes in the 
workers2.properties file to be recognized by mod_jk2, the value of the "ver" attribute 
for 
the appropriate section must be changed. 
 
"Every time the config file is read, jk will check the version number in the 
component, 
and reconfigure if it is different." 
 
This suggests that the value doesn't need to be incremented, it merely needs to change 
ala BIND.  In fact, I remember some documention that said this more explicity.   The 
truth is that the value must actually be incremented, not just changed.  The code is 
in 
jk_config.c ~line 428 
 
It seems trivial, but my assumptions based on the documentation caused me a little 
headache yesterday until I realized my mistake.  If the documentation was a little 
more 
explicit ( "increment"), maybe another user won't make the same mistake. 
 
Thanks!

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

[5.0] JARs handling, and other 5.0.3 changes

[Remy Maucherat]

Hi,

I plan to try to get rid (as much as I can) of JAR URLs inside the 
Catalina (and Jasper) processing, because of the issues which (still, 
unfortunately :-( ) plague them in the JDK. I will use the fact that all 
the JAR URLs returned by the classloader are actually file based. I hope 
that way I'll be able to get rid of the file locking issues on Windows.

Similarly:
- the servlet context will be modified to return file URLs for JARs (but 
only for JARs) inside /WEB-INF/lib in response to getResource.
- /WEB-INF/classes/** and /WEB-INF/lib/** will be made non cacheable (as 
caching classes is useless by definition).

All that as part of an effort to reduce Tomcat memory footprint (to make 
it more suitable for large scale deployments), and reduce the amount of 
heavyweight objects used (such as file descriptors and threads, the 
latter having been taken care of).

For all those who are at J1, have a good J1 :)

Remy

Note: My deployer tweaks are almost done (without much testing), with 
the exception of moving the context descriptors to conf (thanks to Glenn 
for that idea, which will make the feature safer to use in TC 5).

Note 2: I intend to try to resurrect the "tester" suite when that is done.

Note 3: I plan to fix bug 4690 (finally). I have the algorithm on a 
piece of paper (as I didn't like the provided patch behavior).

Note 4: When all that is done, it'll be time for 5.0.3 IMO. As far as I 
am concerned, it will be mostly feature complete. Given the amount of 
stuff I still have to do, I'd give it a two weeks ETA.

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

Re: [book] How Tomcat Works

[Remy Maucherat]

budi wrote:
Dear Tomcat Developers,
I've been using Tomcat for years. It interested me so much that last year I spent 
three months reading the source code. I learned a lot, not only about how the servlet 
container works but also how to design Java applications in general. I particularly 
liked the idea of valves and pipelines, as well as the hierarchical containers. 
Knowing how Tomcat works enables one to write better servlets too, IMO.
I decided to share what I have learned in a book titled "How Tomcat Works".
Sounds great :)

I'll obviously add a link to your book on the resources page, and I'll 
look at it when I have some time.

Remy

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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c

[mturk]

mturk   2003/06/11 09:53:07

  Modified:jk/native/apache-1.3 mod_jk.c
  Log:
  Remove the unreferenced declarations to suppress compiler warnings.
  
  Revision  ChangesPath
  1.38  +1 -3  jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- mod_jk.c  8 May 2003 13:29:47 -   1.37
  +++ mod_jk.c  11 Jun 2003 16:53:06 -  1.38
  @@ -1128,7 +1128,6 @@
   const char **sa)
   {
   const char *s = *sa;
  -int i;
   struct log_item_list *l;
   
   if (*s != '%') {
  @@ -1543,7 +1542,6 @@
   jk_worker_t *worker = wc_get_worker_for_name(worker_name, l);
   
   if(worker) {
  -struct timeval tv_begin,tv_end;
   int rc = JK_FALSE;
   apache_private_data_t private_data;
   jk_ws_service_t s;
  
  
  

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

DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20376

Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP





--- Additional Comments From [EMAIL PROTECTED]  2003-06-11 15:52 ---
I think there were an IE problem that was fixed by the Feburary 2003 update, 
the issue seems to be related to this bug 
329802 BUG: Proxy Authentication Through IAuthenticate May Fail on Secure URL 
http://support.microsoft.com/default.aspx?scid=kb;EN-US;329802


The only thing is I can't see how they are related, the symptoms are the same 
and the fix for the problem described fixes that problem that I had with my IE. 
But the only explanation is that mod_jk acts as a proxy or even IIS acts as a 
proxy. The problem described is an issue only if the application is using 
IAuthenticate interface. Neither the jsp pages or isapi deal with that if I am 
correct. 
 So now the question is why MSIE thinks of mod_jk or IIS as a proxy, and if 
there is any work arounds. 
This is a significant problem with IIS and MSIE 6 SP 1 which was published by 
MS on all XP machines sold in the past year or so. Imagine if you are doing a 
purchase you are paying for your items with a credit card and all of a sudden 
IE shows dns error.
Any work around would be appreciated.

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

[book] How Tomcat Works

[budi]

Dear Tomcat Developers,
I've been using Tomcat for years. It interested me so much that last year I spent 
three months reading the source code. I learned a lot, not only about how the servlet 
container works but also how to design Java applications in general. I particularly 
liked the idea of valves and pipelines, as well as the hierarchical containers. 
Knowing how Tomcat works enables one to write better servlets too, IMO.

I decided to share what I have learned in a book titled "How Tomcat Works". This is 
supposed to be a tutorial, teaching the reader how the servlet container works and how 
to build it. It is a big system and at first I had problems explaining it, considering 
some readers might not have a clue as to how Tomcat ticks. Finally, I decided to build 
simple implementations of some interfaces and explain the simplified components. In 
fact, I started by explaining how the java.net.Socket class works in a simple Web 
server (Chapter 1), followed by a simple servlet container that can't do anything 
other than run a basic servlet (Chapter 2). Each chapter comes with an application and 
each chapter's application is built upon the previous chapter's application. From 
Chapter 1, the application evolves into the full-fledged Catalina 4.1.12. This book 
will be around 500 pages thick and has 18 chapters. 

Having said that, I realize I'm no expert. I wish I knew how Tomcat works better. The 
reason for writing to this mailing list is to ask for favor from you all, the very 
people who really understand how Tomcat works. I hope you could take some time to read 
the chapters that I made available for download from my web site 
www.brainysoftware.com. I'm sure with your feedback and comments this book will be 
much better than the current form, and in the end could benefit Tomcat users and 
anyone who has interest in Tomcat.

Millions of thanks, 

Budi Kurniawan

[GUMP] Build Failure - tomcat-catalina

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

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=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] 

DO NOT REPLY [Bug 20675] New: - Tomcat is not compliant with the JSP 1.2 specification.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20675

Tomcat is not compliant with the JSP 1.2 specification.

   Summary: Tomcat is not compliant with the JSP 1.2 specification.
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
   URL: http://none.right.now
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,

As:
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1210.html#15653
says:
The page directive applies to an entire JSP page and any of its static include 
files, which together are called a translation unit. A static include file is a 
file whose content becomes part of the calling JSP page. The page directive does 
not apply to any dynamic resources; see  for more information. 

Yet, if we have page a.jsp and page b.jsp, a.jsp being:
- begin a.jsp
<%@ page pageEncoding="ISO-8859-2" contentType="text/html;charset=ISO-8859-2"%>
<%@ include file="b.jsp"  %>

 end a.jsp

and b.jsp being:
 begin b.jsp

 end b.jsp

The native chars in b.jsp ARE NOT displayed correctly (only the ones in a.jsp 
are displayed correctly).

I hope this is fixed once and for all in an upcoming tomcat release, please 
notify me of the fix.

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

DO NOT REPLY [Bug 20674] New: - Tomcat is not compliant with the JSP 1.2 specification.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20674

Tomcat is not compliant with the JSP 1.2 specification.

   Summary: Tomcat is not compliant with the JSP 1.2 specification.
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
   URL: http://none.right.now
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,

As:
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1210.html#15653
says:
The page directive applies to an entire JSP page and any of its static include 
files, which together are called a translation unit. A static include file is a 
file whose content becomes part of the calling JSP page. The page directive does 
not apply to any dynamic resources; see  for more information. 

Yet, if we have page a.jsp and page b.jsp, a.jsp being:
- begin a.jsp
<%@ page pageEncoding="ISO-8859-2" contentType="text/html;charset=ISO-8859-2"%>
<%@ include file="b.jsp"  %>

 end a.jsp

and b.jsp being:
 begin b.jsp

 end b.jsp

The native chars in b.jsp ARE NOT displayed correctly (only the ones in a.jsp 
are displayed correctly).

I hope this is fixed once and for all in an upcoming tomcat release, please 
notify me of the fix.

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

DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20376

Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP





--- Additional Comments From [EMAIL PROTECTED]  2003-06-11 07:26 ---
Ok, I'm not a Windows developer, so I have no clue about the IIS version of 
mod_jk.  However, your tests are flawed if you want someone that could 
understand the issues to look at this.  

Firstly, you should test with including a protocol:
  GET /jsp/calendar/calendar.jsp HTTP/1.0

Even better if you can test with HTTP/1.1 and include a Host header.

Most of the differences you've documented are due to Tomcat thinking that your 
client doesn't even speak the HTTP/1.0 protocol, and so is trying to talk down 
to you.

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

DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20376

Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP





--- Additional Comments From [EMAIL PROTECTED]  2003-06-11 07:03 ---
That's explicitly NOT the job of the web developer but one of the servlet
container. I reckon there must be some problem with either the ISAPI plugin or
with that specific version of Tomcat. 

As said before this will have to be looked into by one of the Tomcat developers.

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