Re: Free porn
My favourite page. +++ Attachment: No Virus found +++ Bitdefender AntiVirus - www.bitdefender.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector CoyoteAdapter.java
Bill Barker wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
luehe 2004/10/27 15:58:17
+
+private Method[] getAllDeclaredMethods(Class c) {
+
+if (c.equals(javax.servlet.http.HttpServlet.class)) {
+return null;
+}
+
+Method[] parentMethods =
getAllDeclaredMethods(c.getSuperclass());
If the servlet isn't a HttpServlet (e.g. it's a JSP page) then this will
recurse down to j.l.Object, when c.getSuperClass will return 'null', and you
will get an NPE from the 'c.equals' line.
IMHO, this patch is an overly complex way to try and determine something
that isn't determinable under the servlet spec (again, think JSP page :).
You might as well just set the Allow header to any old constant set of
methods.
I agree being lazy has its good points:
Allow: GET, HEAD, POST would be good enough for me :)
I don't like cut pasting so much code :(
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protected Mail System
Protected message is available. +++ Attachment: No Virus found +++ Panda AntiVirus - www.pandasoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protected Mail Request
First part of the secure mail is available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Two modest proposals about common\lib
Based on all the recent traffic from people tying themselves into pretzels with global resources, I have two concrete ideas. I would try to concoct patches (at least for the first) if there was tentative acceptance for either. 1) Configure the 'common' classpath in an editable location. By default, this path would be the current set of common directories. However, an admin could add additional directories shaped like common. This would be an improvement in administration. As things are, if I want to distribute/deploy common resources, I have to mix my stuff in with the standard stuff. A new release of Tomcat requires me sort it all out over and over. It would cleaner if I could keep 'my' stuff off in separate directories, and just configure it into Tomcat. If I had multiple packages from multiple sources that needed to go into common, I could keep them separate. 2) Some sort of optional classpath conflict checker. Many people seem to get into deep trouble by ending up with copies of 'the same thing' in both a webapp class path and the common class path. I'm thinking of an off-to-one-side tool that would inventory the contents of a webapp, and check for conflicts with common, and report them. Perhaps this would be a candidate for merely 'contrib' status if someone coded it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two modest proposals about common\lib
i normally resolve this with symlinks. Means I can have 'my' common stuff like database drivers in any place I like. (ie in a versioned directory like dbdrivers/database/version/jar Kind regards David Cassidy Benson Margulies To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: h.com Subject: Two modest proposals about common\lib 28/10/2004 14:22 Please respond to Tomcat Developers List Based on all the recent traffic from people tying themselves into pretzels with global resources, I have two concrete ideas. I would try to concoct patches (at least for the first) if there was tentative acceptance for either. 1) Configure the 'common' classpath in an editable location. By default, this path would be the current set of common directories. However, an admin could add additional directories shaped like common. This would be an improvement in administration. As things are, if I want to distribute/deploy common resources, I have to mix my stuff in with the standard stuff. A new release of Tomcat requires me sort it all out over and over. It would cleaner if I could keep 'my' stuff off in separate directories, and just configure it into Tomcat. If I had multiple packages from multiple sources that needed to go into common, I could keep them separate. 2) Some sort of optional classpath conflict checker. Many people seem to get into deep trouble by ending up with copies of 'the same thing' in both a webapp class path and the common class path. I'm thinking of an off-to-one-side tool that would inventory the contents of a webapp, and check for conflicts with common, and report them. Perhaps this would be a candidate for merely 'contrib' status if someone coded it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two modest proposals about common\lib
I've been pondering something similar. (I just never got around to vocalizing it) My preference is to introduce common/usr_lib (and server/usr_lib)(This name is horrible, but you get the idea) The usr_lib dirs would be in the same classloader as common/lib (or server/lib) and would contain user specific jars. This way users would not have to add/change jar files in common/lib when upgrades occur. -Tim Benson Margulies wrote: Based on all the recent traffic from people tying themselves into pretzels with global resources, I have two concrete ideas. I would try to concoct patches (at least for the first) if there was tentative acceptance for either. 1) Configure the 'common' classpath in an editable location. By default, this path would be the current set of common directories. However, an admin could add additional directories shaped like common. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two modest proposals about common\lib
Tim Funk wrote: I've been pondering something similar. (I just never got around to vocalizing it) My preference is to introduce common/usr_lib (and server/usr_lib)(This name is horrible, but you get the idea) The usr_lib dirs would be in the same classloader as common/lib (or server/lib) and would contain user specific jars. This way users would not have to add/change jar files in common/lib when upgrades occur. More problems, more confusion. Bad idea. People can use the properties file to tweak the classloaders if they need it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two modest proposals about common\lib
Remy, Can you send me a doc reference to the relevant properties? Maybe a howto is in order here. If there's already a capability to append lib/class/endorsed dirs in a prop file, then there's surely no reason to add some other place to configure the same thing. --benson -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 9:45 AM To: Tomcat Developers List Subject: Re: Two modest proposals about common\lib Tim Funk wrote: I've been pondering something similar. (I just never got around to vocalizing it) My preference is to introduce common/usr_lib (and server/usr_lib)(This name is horrible, but you get the idea) The usr_lib dirs would be in the same classloader as common/lib (or server/lib) and would contain user specific jars. This way users would not have to add/change jar files in common/lib when upgrades occur. More problems, more confusion. Bad idea. People can use the properties file to tweak the classloaders if they need it. 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]
DO NOT REPLY [Bug 31938] New: - Apache2 + mod_jk2 on FreeBSD - default socket timeout
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31938. 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=31938 Apache2 + mod_jk2 on FreeBSD - default socket timeout Summary: Apache2 + mod_jk2 on FreeBSD - default socket timeout Product: Tomcat 5 Version: 5.0.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: Major Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've got a problem with mod_jk2 and Apache2 under FreeBSD 5.x. I configured mod_jk2 for two Tomcat 5.0 servers. If one of these machines is down (unplugging the network cable), mod_jk2 should send all requests to the server that kept running. That is working 80 percent of the time, but sometimes forwarding the request takes about 75 seconds. I found out that this is the default socket timeout of FreeBSD. The problem is that I configured mod-jk2 the way, that it has its own timeout for connecting (see attached workers2.properties). But this value is not recognized. If I decrease the default connect timeout for FreeBSD (by /etc/sysctl.conf), mod_jk2 will use this value and everything is fine. But I don't want to decrease that value, it could cause other problems. So I think it is a bug, that mod_jk2 is not using the timeout values from its workers2.properties in FreeBSD. Btw exactly the same setup for Apache2 and mod_jk2 works fine on Linux. -- [logger] level=DEBUG [shm] file=/tmp/shmFile # Defines a load balancer named lb. [lb:lb] [workerEnv:] info=Global server options timing=1 # Example socket channel, override port and host. [channel.socket:192.168.1.124:8009] tomcatId=camenzind timeout=1 # Example socket channel, override port and host. [channel.socket:192.168.1.123:8009] tomcatId=haller timeout=1 # define the worker 1 [ajp13:192.168.1.124:8009] channel=channel.socket:192.168.1.124:8009 # define the worker 2 [ajp13:192.168.1.123:8009] channel=channel.socket:192.168.1.123:8009 # Mapping my URI to Tomcats [uri:/myURI*] group=lb [status:] info=Status worker, displays runtime information [uri:/jkstatus/*] info=The Tomcat /jkstatus handler group=status: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two modest proposals about common\lib
look at common.loader, server.loader and shared.loader in catalina.properties. That's what we use for the described purpose. Benson Margulies wrote: Remy, Can you send me a doc reference to the relevant properties? Maybe a howto is in order here. If there's already a capability to append lib/class/endorsed dirs in a prop file, then there's surely no reason to add some other place to configure the same thing. --benson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two modest proposals about common\lib
Sure enough, just what the doctor ordered. Time to play tech writer again. -Original Message- From: Robert Krüger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 10:23 AM To: Tomcat Developers List Subject: Re: Two modest proposals about common\lib look at common.loader, server.loader and shared.loader in catalina.properties. That's what we use for the described purpose. Benson Margulies wrote: Remy, Can you send me a doc reference to the relevant properties? Maybe a howto is in order here. If there's already a capability to append lib/class/endorsed dirs in a prop file, then there's surely no reason to add some other place to configure the same thing. --benson - 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: Two modest proposals about common\lib
Hi, I agree with Remy. These proposed solutions are actually more problems. If it were up to me there'd be two classloaders repositories: one for Tomcat (server/lib), and one for each webapp (WEB-INF/lib). No shared, no common, no WEB-INF/classes. But then again, it's not just up to me ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 9:45 AM To: Tomcat Developers List Subject: Re: Two modest proposals about common\lib Tim Funk wrote: I've been pondering something similar. (I just never got around to vocalizing it) My preference is to introduce common/usr_lib (and server/usr_lib)(This name is horrible, but you get the idea) The usr_lib dirs would be in the same classloader as common/lib (or server/lib) and would contain user specific jars. This way users would not have to add/change jar files in common/lib when upgrades occur. More problems, more confusion. Bad idea. People can use the properties file to tweak the classloaders if they need it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31940] New: - Setting the context as reloadable='true' doesn't fire a sessionCreated event
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31940. 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=31940 Setting the context as reloadable='true' doesn't fire a sessionCreated event Summary: Setting the context as reloadable='true' doesn't fire a sessionCreated event Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As per subject. The problem is that I'm trying to track sessions (Italian privacy laws) and while developing I have the context where I deploy my application set as reloadable='true'. So far so good. The problem is that when the context is reloaded, sessions are kept but no sessionCreated event is fired (and no attributeAdded event either) while contextInitialized events are fired. I believe this is a bug in Tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31940] - Setting the context as reloadable='true' doesn't fire a sessionCreated event
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31940. 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=31940 Setting the context as reloadable='true' doesn't fire a sessionCreated event [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 16:04 --- Not a bug: the sessions are passivated and activate when a webapp is reloaded. They're not destroyed and created. So you need to listen to both types of events. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31267] - RequestUtil.parseCookieHeader not fully RFC 2109 compliant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31267. 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=31267 RequestUtil.parseCookieHeader not fully RFC 2109 compliant --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 16:04 --- More than a month has passed: any updates? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
luehe 2004/10/28 09:42:37
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
Prevent NPE when servlet class is not an instance of HttpServlet.
Return hardcoded set of methods in this case.
Revision ChangesPath
1.55 +13 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- StandardWrapper.java 27 Oct 2004 22:58:17 - 1.54
+++ StandardWrapper.java 28 Oct 2004 16:42:37 - 1.55
@@ -73,6 +73,10 @@
private static org.apache.commons.logging.Log log=
org.apache.commons.logging.LogFactory.getLog( StandardWrapper.class );
+
+private static final String[] DEFAULT_SERVLET_METHODS = new String[] {
+GET, HEAD, POST };
+
// --- Constructors
@@ -563,12 +567,18 @@
* servlet
*/
public String[] getServletMethods() throws ServletException {
-
+
+Class servletClazz = loadServlet().getClass();
+if (!javax.servlet.http.HttpServlet.class.isAssignableFrom(
+servletClazz)) {
+return DEFAULT_SERVLET_METHODS;
+}
+
HashSet allow = new HashSet();
allow.add(TRACE);
allow.add(OPTIONS);
-Method[] methods = getAllDeclaredMethods(loadServlet().getClass());
+Method[] methods = getAllDeclaredMethods(servletClazz);
for (int i=0; methods != null imethods.length; i++) {
Method m = methods[i];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector CoyoteAdapter.java
Bill,
Bill Barker wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
luehe 2004/10/27 15:58:17
+
+private Method[] getAllDeclaredMethods(Class c) {
+
+if (c.equals(javax.servlet.http.HttpServlet.class)) {
+return null;
+}
+
+Method[] parentMethods =
getAllDeclaredMethods(c.getSuperclass());
If the servlet isn't a HttpServlet (e.g. it's a JSP page) then this will
recurse down to j.l.Object, when c.getSuperClass will return 'null', and you
will get an NPE from the 'c.equals' line.
Actually, in the case of a JSP, we're dealing w/ JspServlet, which is an
instance of HttpServlet.
I've changed the code to return a constant set of methods if the servlet
is not an instance of HttpServlet, avoiding the NPE. :)
Thanks,
Jan
IMHO, this patch is an overly complex way to try and determine something
that isn't determinable under the servlet spec (again, think JSP page :).
You might as well just set the Allow header to any old constant set of
methods.
-
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 31914] - Memory leak when using Jsp tags (JspWriter)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31914. 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=31914 Memory leak when using Jsp tags (JspWriter) --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 18:30 --- We found the lead in our production system under unix/solaris after migrating vom tomcat 3 to tomcat 4. Its also reproducing unter diff. windows systems. We are using JAVA V. 1.4.2_04 and planning to migrate to 1.4.2_06. We are analysing the problem with JProfiler which give us the hint that it comes from the handling of the BodyContent/JspWriter. The JspWriter.println() holds the data. We are writting very big data for big reports! With the given examples its easy to reproduce ! The memory is freed if we change the coding from pageContext.getOut() into pageContext.getResponse().getWriter(), but this changes the order of the response html (because the BodyContent is written immedately) and we use sub tags. Hopefully this helps. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31945] New: - Server Configuration Reference: connector element not linked to its pages when mentioned in other SCR pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31945. 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=31945 Server Configuration Reference: connector element not linked to its pages when mentioned in other SCR pages Summary: Server Configuration Reference: connector element not linked to its pages when mentioned in other SCR pages Product: Tomcat 5 Version: 5.0.28 Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-5.0- doc/config/service.html OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Links are provided to the page for each of the server, service, context, engine, and host elements, whererever those term appear in the body of a doc in the reference. However there are no links at all when the connector element is mentioned. At first I thought that there *was* no connector page, then I realised that in fact there are two, but you have to click in the left margin. Suggestions: 1. add a connector page to the reference, which explains that there are more than one type, with a link to each. 2. as with other server config elements, link each mention of connector within the reference to the new page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector CoyoteAdapter.java
- Original Message -
From: Jan Luehe [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 9:45 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector
CoyoteAdapter.java
Bill,
Bill Barker wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
luehe 2004/10/27 15:58:17
+
+private Method[] getAllDeclaredMethods(Class c) {
+
+if (c.equals(javax.servlet.http.HttpServlet.class)) {
+return null;
+}
+
+Method[] parentMethods =
getAllDeclaredMethods(c.getSuperclass());
If the servlet isn't a HttpServlet (e.g. it's a JSP page) then this will
recurse down to j.l.Object, when c.getSuperClass will return 'null', and
you
will get an NPE from the 'c.equals' line.
Actually, in the case of a JSP, we're dealing w/ JspServlet, which is an
instance of HttpServlet.
I've changed the code to return a constant set of methods if the servlet
is not an instance of HttpServlet, avoiding the NPE. :)
My bad. I should pay more attention to Jasper :).
However, a JSP page still will return 'Allow: OPTIONS' after all of this
work :).
Thanks,
Jan
IMHO, this patch is an overly complex way to try and determine something
that isn't determinable under the servlet spec (again, think JSP page
:).
You might as well just set the Allow header to any old constant set of
methods.
-
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]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.4 tomorrow (Friday) instead of Saturday?
Hi, Would everyone be OK with cutting the 5.5.4 release tomorrow (Friday, October 29th) instead of Saturday (October 30th) as we originally agreed? It'd be more convenient for me, that's the only reason. If it can't be done on Friday, it'll likely have to be Monday afternoon instead, but Saturday I can't do. As for the release time of day, it'll be the same whether Friday or Monday: 1900h GMT which is 1400h my time (US Eastern time zone). Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector CoyoteAdapter.java
Actually, in the case of a JSP, we're dealing w/ JspServlet, which is an instance of HttpServlet. I've changed the code to return a constant set of methods if the servlet is not an instance of HttpServlet, avoiding the NPE. :) My bad. I should pay more attention to Jasper :). However, a JSP page still will return 'Allow: OPTIONS' after all of this work :). Yes, but you'll get a more useful reply for any custom HttpServlets. ;-) Notice that what the patch does is return the same methods that OPTIONS would have returned in the Allow response header, minus the disabled TRACE. Since the HTTP spec requires that the Allow header should reflect the capabilities of the requested resource, I think it is a good idea to follow it as much as we can. It's not like we're adding tons of code in order to achieve this. :) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two modest proposals about common\lib
Yoav, Just out of curiosity, what would you say to us poor JNI addicts? --benson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday?
fine by me. Filip -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 2:16 PM To: Tomcat Developers List Subject: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday? Hi, Would everyone be OK with cutting the 5.5.4 release tomorrow (Friday, October 29th) instead of Saturday (October 30th) as we originally agreed? It'd be more convenient for me, that's the only reason. If it can't be done on Friday, it'll likely have to be Monday afternoon instead, but Saturday I can't do. As for the release time of day, it'll be the same whether Friday or Monday: 1900h GMT which is 1400h my time (US Eastern time zone). Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin/contrib - New directory
yoavs 2004/10/28 12:33:45 jakarta-tomcat-catalina/catalina/src/bin/contrib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin/contrib/openVMS-alpha - New directory
yoavs 2004/10/28 12:36:27 jakarta-tomcat-catalina/catalina/src/bin/contrib/openVMS-alpha - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin/contrib/GNU-Linux - New directory
yoavs 2004/10/28 12:36:48 jakarta-tomcat-catalina/catalina/src/bin/contrib/GNU-Linux - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
META-INF/server.xml
Possibilities: 1) the thing that explodes .war files in the webapp directory notices META-INF/server.xml. 2) when an exploded directory is deposited into the webapp directory, and it has a META-INF/server.xml, and there is no corresponding file in conf/Catalina/host, the META-INF file is respected. It is my (possibly confused impression) that neither of these two exist in the current implementation. Various posters on find the different behaviors of manager deployment and these cases to be a confusing inconsistency. Do the experts want to continue this distinction? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two modest proposals about common\lib
Hi, Like any other addiction, it's not good for you, and you should seek a cure. And like any other addiction, I don't mind it as long as it doesn't impact me directly. But when I have to jump through all sorts of hoops for someone else's addiction, then it impacts me directly, and that's when conflicts and -1's (binding vetoes on proposed code changes) arise. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 3:32 PM To: Tomcat Developers List Subject: RE: Two modest proposals about common\lib Yoav, Just out of curiosity, what would you say to us poor JNI addicts? --benson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/10/28 12:59:42
Modified:.Tag: TOMCAT_5_0 build.xml
webapps/docs Tag: TOMCAT_5_0 changelog.xml
Added: catalina/src/bin/contrib Tag: TOMCAT_5_0 README.txt
catalina/src/bin/contrib/GNU-Linux Tag: TOMCAT_5_0
catalina.sh
catalina/src/bin/contrib/openVMS-alpha Tag: TOMCAT_5_0
TOMCAT_Setup_Java.com
Log:
Bugzilla 31447 and 31499: added bin/contrib directory with contributed scripts for
other operating systems.
Revision ChangesPath
No revision
No revision
1.188.2.1 +6 -6 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.188
retrieving revision 1.188.2.1
diff -u -r1.188 -r1.188.2.1
--- build.xml 16 Jun 2004 18:04:47 - 1.188
+++ build.xml 28 Oct 2004 19:59:41 - 1.188.2.1
@@ -453,9 +453,9 @@
antcall target=build-jasper/
!-- Correct permissions and line endings on bin scripts --
-fixcrlf srcdir=${tomcat.build}/bin includes=*.sh eol=lf/
-fixcrlf srcdir=${tomcat.build}/bin includes=*.bat eol=crlf/
-chmod dir=${tomcat.build}/bin includes=*.sh perm=+x/
+fixcrlf srcdir=${tomcat.build}/bin includes=**/*.sh eol=lf/
+fixcrlf srcdir=${tomcat.build}/bin includes=**/*.bat eol=crlf/
+chmod dir=${tomcat.build}/bin includes=**/*.sh perm=+x/
/target
@@ -831,9 +831,9 @@
antcall target=build-jasper/
!-- Correct permissions and line endings on bin scripts --
-fixcrlf srcdir=${tomcat.build}/bin includes=*.sh eol=lf/
-fixcrlf srcdir=${tomcat.build}/bin includes=*.bat eol=crlf/
-chmod dir=${tomcat.build}/bin includes=*.sh perm=+x/
+fixcrlf srcdir=${tomcat.build}/bin includes=**/*.sh eol=lf/
+fixcrlf srcdir=${tomcat.build}/bin includes=**/*.bat eol=crlf/
+chmod dir=${tomcat.build}/bin includes=**/*.sh perm=+x/
antcall target=fix-webapps/
No revision
No revision
1.1.2.1 +1 -0
jakarta-tomcat-catalina/catalina/src/bin/contrib/Attic/README.txt
No revision
No revision
1.1.2.1 +87 -0
jakarta-tomcat-catalina/catalina/src/bin/contrib/GNU-Linux/Attic/catalina.sh
No revision
No revision
1.1.2.1 +202 -0
jakarta-tomcat-catalina/catalina/src/bin/contrib/openVMS-alpha/Attic/TOMCAT_Setup_Java.com
No revision
No revision
1.70.2.60 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.70.2.59
retrieving revision 1.70.2.60
diff -u -r1.70.2.59 -r1.70.2.60
--- changelog.xml 27 Oct 2004 18:36:11 - 1.70.2.59
+++ changelog.xml 28 Oct 2004 19:59:42 - 1.70.2.60
@@ -20,6 +20,9 @@
update
Update web.xml files to 2.4 schema (from 2.3 DTD) where applicable. (yoavs)
/update
+ update
+Added contrib directory to hold 3rd party scripts: bug31499/bug,
bug31447/bug. (yoavs)
+ /update
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31447] - Contribution: system daemon script for GNU/Linux
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31447. 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=31447 Contribution: system daemon script for GNU/Linux [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:02 --- OK, added for Tomcat 5.0.30. See bin/contrib directory. Thanks for submitting this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31499] - Contributing catalina launcher for OpenVMS Alpha
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31499. 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=31499 Contributing catalina launcher for OpenVMS Alpha [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:02 --- OK, done for Tomcat 5.0.30. See bin/contrib directory. Thanks for submitting these. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two modest proposals about common\lib
I am adequately discouraged from trying to sell you additions to facilitate JNI usage. I trust that you are in no hurry to demolish common. I could send along a convincing sob story as to why I really don't have a practical alternative to JNI, but I doubt that anyone would find it terribly sympathetic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31499] - Contributing catalina launcher for OpenVMS Alpha
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31499. 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=31499 Contributing catalina launcher for OpenVMS Alpha --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:03 --- Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OS/2 Launchers in 5.0.29?
Hi, OK, done in time for 5.0.30. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 2:07 AM To: Tomcat Developers List Subject: Re: OS/2 Launchers in 5.0.29? Thanks for your quick reply! Let see. Cant we create a contrib directory under bin (or under the catalina root itself) it would contain some readme which says these stuff are officially not supported. Then comes some subdirectories per OS and place the launchers there. For a normal user the name of contrib is enough to mark those stuff AS IS without official support. Leslie Kishalmi Shapira, Yoav wrote: Hi, We've seen your enhancement submission -- thank you for that. We have several others along the same lines, for different operating systems. The question is where to put them such that it's clear to everyone we don't support them. I don't know the answer to that question, so I've asked on this list, and apparently no one else knows or cares that much. So we're at a standstill. Don't hold your breath ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 12:21 PM To: [EMAIL PROTECTED] Subject: OS/2 Launchers in 5.0.29? Dear all, I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 , asking for adding OS/2 launchers to the tomcat distribution nearly a month ago. I've also prepared the full set of launchers. I've seen that 5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that OS/2 is not officially supported by the TomCat team, but I would. It also would help to support NetBeans Web Development on OS/2. I also think those launchers won't break anything. Thanks, Laszlo Kishalmi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config engine.xml logger.xml project.xml service.xml
yoavs 2004/10/28 13:30:53 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml class-loader-howto.xml developers.xml project.xml proxy-howto.xml ssl-howto.xml status.xml webapps/docs/config Tag: TOMCAT_5_0 engine.xml logger.xml project.xml service.xml Log: Bugzilla 31945: enhanced connector doc links. I probably added a broken link or two, will need to check when publishing. Revision ChangesPath No revision No revision 1.70.2.61 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.60 retrieving revision 1.70.2.61 diff -u -r1.70.2.60 -r1.70.2.61 --- changelog.xml 28 Oct 2004 19:59:42 - 1.70.2.60 +++ changelog.xml 28 Oct 2004 20:30:52 - 1.70.2.61 @@ -37,6 +37,9 @@ fix bug31592/bug: Allow specification of digest encoding for realms. (yoavs) /fix + update +Added and updated Connector documentation: bug31945/bug. (yoavs) + /update /changelog /subsection 1.11.2.2 +2 -2 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml,v retrieving revision 1.11.2.1 retrieving revision 1.11.2.2 diff -u -r1.11.2.1 -r1.11.2.2 --- class-loader-howto.xml3 Sep 2004 21:58:39 - 1.11.2.1 +++ class-loader-howto.xml28 Oct 2004 20:30:52 - 1.11.2.2 @@ -159,9 +159,9 @@ These are separated so that they can be completely removed if the corresponding service is not required, or they can be subject to specialized security manager permissions./li -liemtomcat-coyote.jar/em - Coyote connector for Tomcat 5./li +liemtomcat-coyote.jar/em - Coyote a href=config/connector.htmlconnector/a for Tomcat 5./li liemtomcat-http11.jar/em - Standalone Java HTTP/1.1 -connector./li +a href=config/connector.htmlconnector./a/li liemtomcat-jk2.jar/em - Classes for the Java portion of the codeJK 2/code web server connector, which allows Tomcat to run behind web servers such as Apache and iPlanet iAS and iWS./li 1.5.2.1 +3 -3 jakarta-tomcat-catalina/webapps/docs/developers.xml Index: developers.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/developers.xml,v retrieving revision 1.5 retrieving revision 1.5.2.1 diff -u -r1.5 -r1.5.2.1 --- developers.xml10 Jun 2004 01:04:06 - 1.5 +++ developers.xml28 Oct 2004 20:30:52 - 1.5.2.1 @@ -49,9 +49,9 @@ /section section name=Retired Developers - - - +ul + liCraig McClanahan (craigmcc): Everything :)/li +/ul /section /body 1.21.2.2 +1 -0 jakarta-tomcat-catalina/webapps/docs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/project.xml,v retrieving revision 1.21.2.1 retrieving revision 1.21.2.2 diff -u -r1.21.2.1 -r1.21.2.2 --- project.xml 21 Aug 2004 15:50:07 - 1.21.2.1 +++ project.xml 28 Oct 2004 20:30:52 - 1.21.2.2 @@ -13,6 +13,7 @@ menu name=Links item name=Docs Home href=index.html/ +item name=FAQ href=../faq / /menu menu name=User Guide 1.6.2.1 +6 -6 jakarta-tomcat-catalina/webapps/docs/proxy-howto.xml Index: proxy-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/proxy-howto.xml,v retrieving revision 1.6 retrieving revision 1.6.2.1 diff -u -r1.6 -r1.6.2.1 --- proxy-howto.xml 8 Jan 2004 14:55:57 - 1.6 +++ proxy-howto.xml 28 Oct 2004 20:30:52 - 1.6.2.1 @@ -21,7 +21,7 @@ processing. When Tomcat is running standalone with the a href=config/coyote.htmlCoyote HTTP/1.1 Connector/a, it will generally report the server name specified in the request, and the port number on -which the strongConnector/strong is listening. The two servlet API +which the stronga href=config/connector.htmlConnector/a/strong is listening. The two servlet API calls of interest, for this purpose, are:/p ul licodeServletRequest.getServerName()/code/li @@ -32,9 +32,9 @@ configured to behave like a proxy server), you will sometimes
DO NOT REPLY [Bug 31945] - Server Configuration Reference: connector element not linked to its pages when mentioned in other SCR pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31945. 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=31945 Server Configuration Reference: connector element not linked to its pages when mentioned in other SCR pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:33 --- OK, done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config ajp.xml
yoavs 2004/10/28 13:44:35 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml realm-howto.xml webapps/docs/config Tag: TOMCAT_5_0 ajp.xml Log: Bugzilla 31739: minor doc patches. Revision ChangesPath No revision No revision 1.70.2.62 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.61 retrieving revision 1.70.2.62 diff -u -r1.70.2.61 -r1.70.2.62 --- changelog.xml 28 Oct 2004 20:30:52 - 1.70.2.61 +++ changelog.xml 28 Oct 2004 20:44:35 - 1.70.2.62 @@ -40,6 +40,9 @@ update Added and updated Connector documentation: bug31945/bug. (yoavs) /update + update +bug31739/bug: Minor documentation corrections for realm-howto and AJP docs. (yoavs) + /update /changelog /subsection 1.14.2.3 +21 -4 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.14.2.2 retrieving revision 1.14.2.3 diff -u -r1.14.2.2 -r1.14.2.3 --- realm-howto.xml 3 Sep 2004 21:58:39 - 1.14.2.2 +++ realm-howto.xml 28 Oct 2004 20:44:35 - 1.14.2.3 @@ -8,6 +8,7 @@ properties author email=[EMAIL PROTECTED]Craig R. McClanahan/author +author email=[EMAIL PROTECTED]Andrew R. Jaquith/author titleRealm Configuration HOW-TO/title /properties @@ -1221,12 +1222,15 @@ JAAS Authentication Tutorial/a and a href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/JAASLMDevGuide.html;the JAAS Login Module Developer's Guide/a) to be managed by the JAAS Login -Context (codejavax.security.auth.login.LoginContext/code) +Context (codejavax.security.auth.login.LoginContext/code). +When developing your LoginModule, note that JAASRealm's built-in codeCallbackHandler/code +only recognizes the codeNameCallback/code and codePasswordCallback/code at present. /li liAlthough not specified in JAAS, you should create seperate classes to distinguish between users and roles, extending codejavax.security.Principal/code, so that Tomcat can tell which Principals returned from your login module are users and which are roles (see codeorg.apache.catalina.realm.JAASRealm/code). +Regardless, the first Principal returned is emalways/em treated as the user Principal. /li liPlace the compiled classes on Tomcat's classpath /li @@ -1234,7 +1238,8 @@ href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/tutorials/LoginConfigFile.html;JAAS LoginConfig file/a) and tell Tomcat where to find it by specifying its location to the JVM, for instance by setting the environment -variable: JAVA_OPTS=-DcodeJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config/code/li +variable: codeJAVA_OPTS=-DJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config/code/li + liConfigure your security-constraints in your web.xml for the resources you want to protect/li liConfigure the JAASRealm module in your server.xml /li @@ -1263,7 +1268,7 @@ /attribute attribute name=appName required=true -pThe name of the realm as configured in your login configuration file +pThe name of the application as configured in your login configuration file (a href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/tutorials/LoginConfigFile.html;JAAS LoginConfig/a)./p /attribute @@ -1277,6 +1282,14 @@ for your role codePrincipals/code./p /attribute + attribute name=useContextClassLoader required=false +pInstructs JAASRealm to use the context class loader for loading the user-specified +codeLoginModule/code class and associated codePrincipal/code classes. The +default value is codetrue/code, which is backwards-compatible with the way +Tomcat 4 works. To load classes using the container's classloader, specify +codetrue/code./p + /attribute + /attributes h3Example/h3 @@ -1325,8 +1338,12 @@ liDebugging and exception messages logged by this codeRealm/code will be recorded by the codeLogger/code that is associated with our surrounding codeContext/code, codeHost/code, or codeEngine/code. -By default, the corresponding Logger will create a log file in the code$CATALINA_HOME/logs/code +By default, the corresponding Logger will create a log file in the code$CATALINA_HOME/logs/code directory./li +
DO NOT REPLY [Bug 31739] - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. 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=31739 Minor documentation additions for realm-howto and AJP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:47 --- Done for Tomcat 5.0, doing 5.5 next. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config ajp.xml
yoavs 2004/10/28 13:54:49 Modified:webapps/docs changelog.xml realm-howto.xml webapps/docs/config ajp.xml Log: Bugzilla 31739: minor doc updates. Revision ChangesPath 1.157 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.156 retrieving revision 1.157 diff -u -r1.156 -r1.157 --- changelog.xml 27 Oct 2004 15:56:57 - 1.156 +++ changelog.xml 28 Oct 2004 20:54:49 - 1.157 @@ -99,6 +99,9 @@ fix bug31592/bug: Support other encodings for digests. (yoavs) /fix + update +bug31739/bug: Minor realm-howto and AJP connector doc updates. (yoavs) + /update /changelog /subsection 1.18 +19 -2 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- realm-howto.xml 27 Sep 2004 16:00:31 - 1.17 +++ realm-howto.xml 28 Oct 2004 20:54:49 - 1.18 @@ -8,6 +8,7 @@ properties author email=[EMAIL PROTECTED]Craig R. McClanahan/author +author email=[EMAIL PROTECTED]Andrew R. Jaquith/author titleRealm Configuration HOW-TO/title /properties @@ -1270,11 +1271,14 @@ a href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/JAASLMDevGuide.html;the JAAS Login Module Developer's Guide/a) to be managed by the JAAS Login Context (codejavax.security.auth.login.LoginContext/code) +When developing your LoginModule, note that JAASRealm's built-in codeCallbackHandler/code ++only recognizes the codeNameCallback/code and codePasswordCallback/code at present. /li liAlthough not specified in JAAS, you should create seperate classes to distinguish between users and roles, extending codejavax.security.Principal/code, so that Tomcat can tell which Principals returned from your login module are users and which are roles (see codeorg.apache.catalina.realm.JAASRealm/code). +Regardless, the first Principal returned is emalways/em treated as the user Principal. /li liPlace the compiled classes on Tomcat's classpath /li @@ -1282,7 +1286,8 @@ href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/tutorials/LoginConfigFile.html;JAAS LoginConfig file/a) and tell Tomcat where to find it by specifying its location to the JVM, for instance by setting the environment -variable: JAVA_OPTS=-DcodeJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config/code/li +variable: codeJAVA_OPTS=-DJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config/code/li + liConfigure your security-constraints in your web.xml for the resources you want to protect/li liConfigure the JAASRealm module in your server.xml /li @@ -1304,7 +1309,7 @@ /attribute attribute name=appName required=true -pThe name of the realm as configured in your login configuration file +pThe name of the application as configured in your login configuration file (a href=http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/tutorials/LoginConfigFile.html;JAAS LoginConfig/a)./p /attribute @@ -1318,6 +1323,14 @@ for your role codePrincipals/code./p /attribute + attribute name=useContextClassLoader required=false +pInstructs JAASRealm to use the context class loader for loading the user-specified +codeLoginModule/code class and associated codePrincipal/code classes. The +default value is codetrue/code, which is backwards-compatible with the way +Tomcat 4 works. To load classes using the container's classloader, specify +codetrue/code./p + /attribute + /attributes h3Example/h3 @@ -1362,6 +1375,10 @@ that means until the user closes their browser. Any changes to the security information for an already authenticated user will strongnot/strong be reflected until the next time that user logs on again./li + liAs with other codeRealm/code implementations, digested passwords + are supported if the codelt;Realmgt;/code element in codeserver.xml/code + contains a codedigest/code attribute; JAASRealm's codeCallbackHandler/code + will digest the password prior to passing it back to the codeLoginModule/code/li /ul /subsection 1.11 +23 -1
DO NOT REPLY [Bug 31739] - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. 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=31739 Minor documentation additions for realm-howto and AJP [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 20:57 --- OK, done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config ajp.xml
[EMAIL PROTECTED] wrote: + +attribute name=minProcessors required=false + strongdeprecated/strong + pThe minimum number of processors to start at initialization time. + If not specified, this atttribute is set to 5./p +/attribute + +attribute name=maxProcessors required=false + strongdeprecated/strong + pThe maximum number of processors allowed. This should be + set to a value that is greater than or equal to the maximum number + of concurrent connections the remote web server can open to Tomcat + simultaneously. For example, if the web server is Apache 1.x or 2.x + Tomcat's codemaxProcessors/code should be set to the + value of Apache's codemaxClients/code directive./p + pA codemaxProcessors/code value of zero (0) signifies that + the number of processors is unlimited. If not specified, this + atttribute defaults to 20./p + /attribute These two are the same as minSpareTheads and maxThreads, so they shouldn't be documented (they're the old names). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday?
Shapira, Yoav wrote: Hi, Would everyone be OK with cutting the 5.5.4 release tomorrow (Friday, October 29th) instead of Saturday (October 30th) as we originally agreed? It'd be more convenient for me, that's the only reason. If it can't be done on Friday, it'll likely have to be Monday afternoon instead, but Saturday I can't do. As for the release time of day, it'll be the same whether Friday or Monday: 1900h GMT which is 1400h my time (US Eastern time zone). I'm obviously ok for friday. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31914] - Memory leak when using Jsp tags (JspWriter)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31914. 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=31914 Memory leak when using Jsp tags (JspWriter) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 21:41 --- I think all these components will be reused, so there's no actual leak (memory gets allocated, and that's it). As you may not have noticed, your usage of tags is quite evil. If you want this behavior to be modified, please provide a tested patch implementing the behavior you would want (and which complies with the specification), and we'll look at it. I'll have to preserve reuse, though. WONTFIX for the time being. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Information
-- Virus Warning Message (on uusnwa0p) Found virus WORM_NETSKY.Z in file Bill.txt .exe (in Bill.zip) The file is deleted. - Important bill! -- Virus Warning Message (on uusnwa0p) Bill.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cecile Barayre/GVA/UNCTAD is out of the office.
I will be out of the office starting 21.10.2004 and will not return until 19.11.2004. I will be on leave from 21 October to 12 November, and on mission from 15 to 19 November. I will respond to your message when I return. For any urgent matters, please contact Ms. Borque at 022 907 59 12. Best Regards, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
