Daniel Vanderhoof is out of the office.
I will be out of the office starting 02/14/2005 and will not return until 03/01/2005. I will not have access to e-mail while I am away from the office. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
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 35 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-24022005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-24022005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-24022005/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-24022005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-24022005/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 2824022005, brutus:brutus-public:2824022005 Gump E-mail Identifier (unique within run) #11. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
+1 for both Great to see them with us ;-) Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33727] New: - commented taglib goes wrong, while in tomcat 4 works fine
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=33727. 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=33727 Summary: commented taglib goes wrong, while in tomcat 4 works fine Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hello dear Apache, app:test/ when commented into !--app:test--/, works fine. app:test/app:test when commented into !--app:test/app:test--, is wrong in tomcat 5.0.28, while it works in tomcat 4.x Please help. Thanks before. -- 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: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
++1 welcome on board, we need help Thanks Peter Mladen Turk schrieb: I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and William A. Rowe ([EMAIL PROTECTED]) as commiters for the JTC connectors. Both of them are long time ASF members. Jim is even a director of Apache Software Foundation. They both are core apache httpd designers and developers for years now, and IMHO we should be proud tho have them on board :). I'm sure they will help us with the better apache httpd integration. So... [x] Yes, Jim is really a cool guy. [ ] No way. and.. [x] Sure, wellcome Bill. [ ] I think I know httpd better then him. The both have my ++1. 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: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
Costin Manolache wrote: Both +1, of course. I guess you meant 'commiters for jakarta tomcat project' :-) Yes, sure. I think that's implicit. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StandardSession activate()/passivate() are broken
It appears that the activate() and passivate() routines of StandardSession are not functioning properly. [I've only tested 5.0.30, but 5.5.x seem to have identical erroneous code.] These methods /are /called, but do not fire appropriate HttpSessionEvent events. A comparison of these routines to tellNew() and expire() is rather telling. I plan to rework this code along the lines of tellNew() and expire() to get proper functionality -- Jess Holle
DO NOT REPLY [Bug 33728] New: - Bad request url with Struts/Tiles
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=33728. 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=33728 Summary: Bad request url with Struts/Tiles Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I develop with Struts 1.2.4 and Tiles Struts action /Main.do maps to Tiles definition main.page Tiles main.page definition points on some jsp file: /jsp/Main.jsp In /jsp/Main.jsp, I'm displaying a link doing some table paging. Link is contructed from resquest's URI. Using Tomcat 5.0.28, link points on /Main.do and that's fine. Using Tomcat 5.5.7, link points on /jsp/Main.jsp which is a failure. This bug may affect other Tomcat 5.5.7 / Struts / Tiles projects. Best regards. -- 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 33728] - Bad request url with Struts/Tiles
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=33728. 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=33728 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-24 15:18 --- Please submit a ready to use war test case. -- 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 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 --- Additional Comments From [EMAIL PROTECTED] 2005-02-24 17:11 --- (In reply to comment #1 from Remy) You might want to look into the code a little bit more, and see that SSO should get an event for all sessions of a particular webapp when it is stopped. Remy, OK I'm confused... I've only just started to look at the internals of Tomcat, so its kind of hard to initially get my head around the codebase. However, I've been instrumenting a local copy of the 5.5.7 source with lots of extra logging to try to follow the logic. From what I can tell, the SingleSignOn is NOT notified in any way when an application is undeployed. The only mechanism I could see would be if it was told when the individual sessions were expired. So I had a look at session.StandardManager, which seems to deal with persisting and expiring all of the sessions when an application is STOPped. However, looking at StandardManager.doUnload(), the look that expires the sessions calls session.expire(false) - i.e. does not notify listeners, hence the SSO never gets told. Did I miss something obvious? (I am trying to look into the problem and help out here!) In the meantime, a colleague is still fighting with the loggers and class loaders, but I think we can accept that is a separate issue. Thanks, Kev -- 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 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 --- Additional Comments From [EMAIL PROTECTED] 2005-02-24 17:56 --- Yes, that's a very good point about the expire(false) when a webapp is stopped. I didn't think about that (to be honest, I don't know the SSO code that well either, but looking at the code I had the impression that this was working, and the problems would be caused by something else). I'll try to see if there is a way to do better cleanup, or to remove the need for holding references to sessions. -- 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: Changing the Tomcat5 WIN32 service runner
Mladen Turk wrote: @if %1 == install goto cmdInstall @if %1 == uninstall goto cmdUninstall @if %1 == start goto cmdStart @if %1 == stop goto cmdStop @if %1 == restart goto cmdRestart echo Usage goto cmdEnd I assume the '.bat' is the only option - i.e. could you use arbitrary 'executables' or other 'scripting languages' ? I.e. if you have cygwin or equivalent installed - could it execute a .sh ? Or if you have different scripting engine - could it run the .js or .py instead of .bat? And the most interesting - could you specify an executable .jar as the command ? It's just that .bat is one of the ugliest scripting languages... Having the unix-style service mechanism, i.e. a script with start/stop/etc is IMO a step forward and makes it much easier to deal with services. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Re: StandardSession activate()/passivate() are broken
Attached is a patch (against the latest 5.5.x source) that addresses
this issue.
--
Jess Holle
Jess Holle wrote:
It appears that the activate() and passivate() routines of
StandardSession are not functioning properly. [I've only tested
5.0.30, but 5.5.x seem to have identical erroneous code.]
These methods are called, but do not fire appropriate
HttpSessionEvent events. A comparison of these routines to tellNew()
and expire() is rather telling.
I plan to rework this code along the lines of tellNew() and expire() to
get proper functionality
--
Jess Holle
--- StandardSession.java-1.49 2005-02-24 10:58:20.184415700 -0600
+++ StandardSession.java2005-02-24 10:59:08.0 -0600
@@ -729,19 +729,20 @@
public void passivate() {
// Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
.sessionWillPassivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
-(sm.getString(standardSession.attributeEvent), t);
+(sm.getString(standardSession.sessionEvent), t);
}
}
}
@@ -756,19 +757,20 @@
public void activate() {
// Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
.sessionDidActivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
-(sm.getString(standardSession.attributeEvent), t);
+(sm.getString(standardSession.sessionEvent), t);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
[EMAIL PROTECTED] wrote: markt 2005/01/15 12:27:05 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java Log: Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns original url rather than new url as per SRV8.4. Uses same code as CoyoteRequest.getRequestURL() I think the bug report may actually be invalid, because: - getRequestURL is not a path element - the javadoc associated with the method is: Reconstructs the URL the client used to make the request. The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters. I don't know for sure, however. Any comments on that ? Rémy - 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 StandardContext.java
remm2005/02/24 09:11:06
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Don't call mkdirs if we're not going to save the configuration.
Revision ChangesPath
1.165 +4 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.164
retrieving revision 1.165
diff -u -r1.164 -r1.165
--- StandardContext.java 17 Feb 2005 18:25:51 - 1.164
+++ StandardContext.java 24 Feb 2005 17:11:06 - 1.165
@@ -4594,7 +4594,9 @@
if (host != null) {
configBase = new File(configBase, host.getName());
}
-configBase.mkdirs();
+if (saveConfig) {
+configBase.mkdirs();
+}
return configBase;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, February 24, 2005 9:04 AM Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java [EMAIL PROTECTED] wrote: markt 2005/01/15 12:27:05 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java Log: Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns original url rather than new url as per SRV8.4. Uses same code as CoyoteRequest.getRequestURL() I think the bug report may actually be invalid, because: - getRequestURL is not a path element - the javadoc associated with the method is: Reconstructs the URL the client used to make the request. The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters. I don't know for sure, however. Any comments on that ? I'd tend to go with Remy's interpretation, but it is a grey area in the spec. The javadocs for HttpServletRequest.getRequestURI (which is a path element) say to use the deprecated HttpUtils.getRequestURL to construct a URL, which suggests that HttpUtils.getRequestURL should use the path elements. However the javadocs for HttpUtils.getRequestURL are pretty much the same as for HttpServletRequest.getRequestURL, making the picture a bit grey. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug 33463: realy fixed?
Hi, I've just wrote a unit test to verify this bug has fixed (http://issues.apache.org/bugzilla/show_bug.cgi?id=33463). But looking at the code in StandardContext: 4276 // Stop our application listeners 4277 listenerStop(); 4278 4279 // Clear all application-originated servlet context attributes 4280 if (context != null) 4281 context.clearAttributes(); I doubt it will works since in listenerStop, we set all the listeners to null: 3711 setApplicationEventListeners(null); 3712 setApplicationLifecycleListeners(null); 3713 3714 return (ok); So when we call clearAttributes in ApplicationContext: 691 // Notify interested application event listeners 692 Object listeners[] = context.getApplicationEventListeners(); 693 if ((listeners == null) || (listeners.length == 0)) 694 return; 695 ServletContextAttributeEvent event = 696 new ServletContextAttributeEvent(context.getServletContext(), 697 name, value); The listeners[] are always null. Should the clearAttributes be called before? It was like that before but I don't understand why we moved the call after listenerStop(). Also, there is a couple of Catalina's private attributes available to the listener that should'nt be in StandardContext: 4072 // We put the resources into the servlet context 4073 if (ok) 4074 getServletContext().setAttribute 4075 (Globals.RESOURCES_ATTR, getResources()); Should we add: context.setAttributeReadOnly(Globals.RESOURCES_ATTR); so this way the listener doesn't get notified with those read only attribute? Thanks -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Re: StandardSession activate()/passivate() are broken
Also I notice that when PersistentManager is used that my sessionDestroyed() method is called multiple times (twice actually) whenever a session is being expired from store (i.e. upon removal of old passivated session data). I am patching (crudely) around this for now, but I thought I'd bring this to everyone else's attention. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug 33463: realy fixed?
Jean-Francois Arcand wrote: Hi, I've just wrote a unit test to verify this bug has fixed (http://issues.apache.org/bugzilla/show_bug.cgi?id=33463). But looking at the code in StandardContext: 4276 // Stop our application listeners 4277 listenerStop(); 4278 4279 // Clear all application-originated servlet context attributes 4280 if (context != null) 4281 context.clearAttributes(); I doubt it will works since in listenerStop, we set all the listeners to null: 3711 setApplicationEventListeners(null); 3712 setApplicationLifecycleListeners(null); 3713 3714 return (ok); So when we call clearAttributes in ApplicationContext: 691 // Notify interested application event listeners 692 Object listeners[] = context.getApplicationEventListeners(); 693 if ((listeners == null) || (listeners.length == 0)) 694 return; 695 ServletContextAttributeEvent event = 696 new ServletContextAttributeEvent(context.getServletContext(), 697 name, value); The listeners[] are always null. Should the clearAttributes be called before? It was like that before but I don't understand why we moved the call after listenerStop(). Yes, it is fixed. The bug is that the attributes were cleared before destroy was called. No attribute listner should to be called on stop, and the original bug was actually invalid. Also, there is a couple of Catalina's private attributes available to the listener that should'nt be in StandardContext: 4072 // We put the resources into the servlet context 4073 if (ok) 4074 getServletContext().setAttribute 4075 (Globals.RESOURCES_ATTR, getResources()); Should we add: context.setAttributeReadOnly(Globals.RESOURCES_ATTR); so this way the listener doesn't get notified with those read only attribute? I don't see the attribute replaced events as an issue, personally. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33739] New: - 5.5 Docs missing CATALINA_BASE info formerly in RUNNING.txt
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=33739. 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=33739 Summary: 5.5 Docs missing CATALINA_BASE info formerly in RUNNING.txt Product: Tomcat 5 Version: 5.5.7 Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/RUNNING.txt OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Section (4) Advanced Configuration - Multiple Tomcat 4 Instances in tomcat- 4.1-doc/RUNNING.txt is the *only* place that the use of the CATALINA_BASE directory and its subdirectories is discussed - and this info is missing entirely from the tomcat-5.5-doc tree. This is can cause unnecessary googling for users who (like me) have either not touched Tomcat in a while or are new to it and starting with 5.*. This info should be *somewhere*, perhaps tomcat-5.5- doc/setup.html. -- 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]
