Re: users Digest 1 Oct 2009 16:56:25 -0000 Issue 9131
From: Filip Hanik - Dev Lists devli...@hanik.com To: Tomcat Users List users@tomcat.apache.org Date: Thu, 01 Oct 2009 08:00:53 -0600 Subject: Re: Comet duplicate END events On 09/30/2009 11:36 PM, Dan D wrote: I have the exact situation as described thoroughly here: http://www.mail-archive.com/users@tomcat.apache.org/msg66793.html wanna send us a test case? otherwise, duplicate END events should not be a big deal, easy to handle Any thoughts? The previous question about this includes a test case: http://www.mail-archive.com/users@tomcat.apache.org/msg66793.html The other concern is that according to the API, after receiving an END event the request will get recycled. So the second END event may give you a recycled request/response that would be dangerous to close the event or touch the request/response. Are you suggesting ignoring the second END event? If so, what should I use to detect it's a duplicate? Using anything in the request/response wouldn't be safe if they had been recycled. I suppose I could use the identity of the CometEvent itself?
Comet duplicate END events
I have the exact situation as described thoroughly here: http://www.mail-archive.com/users@tomcat.apache.org/msg66793.html Any thoughts?
Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
This worked perfectly. Thank you very much for your patience and help. - Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, February 11, 2008 5:09 PM Subject: RE: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14 From: Dan D. [mailto:[EMAIL PROTECTED] Subject: Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14 Would it work to then change the appBase to /home/user/html/ROOT, or would it be better to have a secondary directory (/home/user/html/webapps) with a ROOT directory inside of it? The latter, since you must not ever have appBase == docBase. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
Chuck, I updated the server.xml for this user to be: Host name='www.domain.com' debug='0' appBase='/home/user/html' unpackWARs='true' autoDeploy='false' Aliasdomain.com/Alias Valve className='org.apache.catalina.authenticator.SingleSignOn' debug='0'/ Valve className='org.apache.catalina.valves.AccessLogValve' directory='/var/log/user' prefix='tomcat_access.' suffix='.log' pattern='common' resolveHosts='false'/ /Host I added a ROOT directory in /home/user/html, with a META-INF and WEB-INF directory in it. Added context.xml with the contents of: Context debug='0' reloadable='false'/ inside META-INF. Removed WEB-INF from /home/user/html. Removed all contents from the Tomcat work directory as well. When starting tomcat, however, the work directory is still full of directories that have nothing to do with the actual application. If I read your response correctly (there's a good chance I didn't), the steps I took should be the right ones. However, if that were the case, should all of the random directories still have a place in the Tomcat work directory? Thanks! Dan. - Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, February 07, 2008 6:09 PM Subject: RE: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14 From: Dan D. [mailto:[EMAIL PROTECTED] Subject: Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14 Host name='www.domain.com' appBase='/home/user/html' Context path='' docBase='' debug='0' reloadable='false'/ /Host Right there is the first problem: docBase and appBase must never be the same - lots of things go wrong internally when they both refer to the same directory. You need to remove the Context entry for the default webapp from server.xml and place the default webapp files under /home/user/html/ROOT. If you want to specify attributes for the default webapp, put the Context element in /home/user/html/ROOT/META-INF/context.xml, without the path or docBase attributes. This works on all levels from 5.0 on up. When that's straightened out, delete everything under the work directory before restarting Tomcat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
It is entirely possible that this environment isn't setup in a optimal way,
and also that I may be messing up some of the proper names.
To provide a real world example (names and paths have been changed, but all
information is the same), here is the Host entry for a domain (same in both
TC5 and 6 currently) that we are using, as well as the work directories for
each:
server.xml entry:
Host name='www.domain.com'
debug='0'
appBase='/home/user/html'
unpackWARs='true'
autoDeploy='false'
Aliasdomain.com/Alias
Context path='' docBase='' debug='0' reloadable='false'/
Valve className='org.apache.catalina.authenticator.SingleSignOn'
debug='0'/
Valve className='org.apache.catalina.valves.AccessLogValve'
directory='/var/log/user'
prefix='tomcat_access.'
suffix='.log'
pattern='common'
resolveHosts='false'/
/Host
Work directory under Tomcat 5:
[EMAIL PROTECTED] www.domain.com]# pwd; find .
/web/tomcat/work/hosting/www.domain.com
.
./_
./_/tldCache.ser
Work directory under Tomcat 6:
[EMAIL PROTECTED] www.domain.com]# pwd ; find .
/web/tomcat/work/hosting/www.domain.com
.
./_
./stats
./files
./includes
./misc
./modules
./profiles
./scripts
./sites
./themes
./forum
./lists
./members
./staging
As for why the WEB-INF is at the same level as a war file, it is a shared
hosting environment, and that is their document root. It allows the user to
have an application at http://domain.com as well as upload a war file for
additional applications they wish to run from say, http://domain.com/blog.
It sounds as though this should be done differently?
I'm more or less rebuilding the environment with the upgrade, so any
recommendations are very welcome.
Thanks,
Dan
- Original Message -
From: Caldarale, Charles R [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Thursday, February 07, 2008 2:46 PM
Subject: RE: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
From: Dan D. [mailto:[EMAIL PROTECTED]
Subject: Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
Customer has the following directory structure:
/home/user/html
\_ WEB-INF/
|\_ classes/
|\_ lib/
\_ images/
\_ movies/
\_ mp3s/
\_ blog/
\_ new_application.war
That looks very wrong. Why is there a .war file at the same level as
WEB-INF?
Now, in Tomcat 5, they would have a work directory structure of the
following:
/{tomcat.home}/work/{engine.name}/
\_ ./application_name
\_ _ (the directory name is simply _)
| \_ tldCache.ser
\_ new_application
\_ tldCache.ser
That also looks wrong; all tldCache.ser files should be at the same
level - immediately under the respective work/Catalina/[host]/[appname]
directories. Even if you're confusing application_name with the name
on a Host element, something seems very broken with your appBase
and/or docBase settings. Until that's straightened out, all bets are
off.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
Hello all,
I'm currently working on upgrading our systems from using Tomcat 5.0.27 to
6.0.14.
The upgrades are not being done in place (ie, we will have both systems out
there, and will be doing migrations to the new version). I have been able to
resolve most of the issues we have run into thus far, however, I am now
somewhat stuck, and am hoping someone here may be able to help.
About the environment:
Shared hosting, with approximately 300-600 users on a server, with an average
of ~1500 applications (many users have a few applications). Not all users are
utilizing any java at all, however. Apache 1.3.33 is running and configured to
serve static content.
The older servers with TC5 on them have ~6GB of available RAM, new servers for
TC6 have 8GB of RAM.
Customer content is stored on a remote NAS server.
While I understand that having the Host and Context declaration for all
users listed in server.xml, that is how we have it currently configured.
About the problem:
When tomcat is started and running on our existing 5.0.27 server, it uses
approximately 1GB of RAM, and successfully runs all applications without issue.
When starting tomcat on the 6.0.14 server with the _exact_ same content,
however, it runs out of heap space. This is the issue I'm running into right
now that I can't seem to find any answers about. Attempting to increase the
available heap results in an error allocating memory upon startup.
The output from jmap seems to show that the majority of the heap/memory is
being consumed by character arrays.
When viewing the {tomcat.home}/work/{engine}/{application} directory, it
appears there is a fair difference on how these are loaded into tomcat.
On Tomcat5, this directory consists of only directories that contain a WEB-INF
directory in them, and each of those have a tldCache.ser file.
On Tomcat6, this directory consists of all directories located inside a
directory that contains a WEB-INF directory.
For example:
Tomcat 6:
[EMAIL PROTECTED] ]# pwd ; find .
/web/tomcat/work/hosting/sitename.com
.
./_
./cgi
./stats
./php_uploads
./images
./ad
./Video
./Templates
./Flv
./Songs
./newwebsite
./old files
./manager
Tomcat5:
[EMAIL PROTECTED] ]# pwd; find .
/web/tomcat/work/hosting/sitename.com
.
./_
./_/tldCache.ser
And the contents of the actual home directory are:
[EMAIL PROTECTED] html]# find . -maxdepth 1 -type d
.
./cgi
./stats
./php_uploads
./WEB-INF
./images
./ad
./Video
./Templates
./Flv
./Songs
./newwebsite
./old files
I have read http://wiki.apache.org/tomcat/FAQ/Memory and attempted all the
suggestions there, to no avail.
Thus, it appears that on Tomcat6, it is attempting to load all of these paths
into memory, and eventually runs out. Tomcat5 did not load all of the paths to
directories without applications, and thus uses less of the heap.
Does it seem like I am on the right track here? Have others encountered this
in the past? Is there a way to prevent this behavior within Tomcat 6?
I thank you for any insight you can provide on this issue.
Sincerely,
Dan D.
Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14
Following is the exception that is thrown, along with a few surrounding lines from the catalina.out log file: [Full GC 1982271K-1982271K(1999424K), 7.5088700 secs] [Full GC 1982271K-1982269K(1999424K), 7.5053160 secs] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [Full GC 1982271K-1982271K(1999424K), 7.4678950 secs] [Full GC 1982271K-1982246K(1999424K), 9.5055930 secs] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at java.io.StringWriter.write(StringWriter.java:95) at java.io.PrintWriter.write(PrintWriter.java:412) at java.io.PrintWriter.write(PrintWriter.java:429) at java.io.PrintWriter.print(PrintWriter.java:559) at java.io.PrintWriter.println(PrintWriter.java:695) at java.lang.Throwable.printStackTrace(Throwable.java:512) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:72) at java.util.logging.StreamHandler.publish(StreamHandler.java:179) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88) at java.util.logging.Logger.log(Logger.java:472) at java.util.logging.Logger.doLog(Logger.java:494) at java.util.logging.Logger.logp(Logger.java:694) [Full GC 1982271K-1982271K(1999424K), 7.5629480 secs] [Full GC 1982271K-1982247K(1999424K), 7.4791920 secs] at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167) at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:929) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [Full GC 1982271K-1982271K(1999424K), 7.4982800 secs] [Full GC 1982271K-1982271K(1999424K), 7.4976100 secs] [Full GC 1982271K-1982244K(1999424K), 9.5026360 secs] [Full GC 1982272K-1982244K(1999424K), 7.4494750 secs] [Full GC 1982272K-1982272K(1999424K), 7.4763190 secs] [Full GC 1982272K-1982234K(1999424K), 9.3931880 secs] [Full GC[Unloading class com.atlassian.confluence.event.events.plugin.PluginDisableEvent] [Unloading class org.apache.log4j.spi.RepositorySelector] [Unloading class org.apache.xerces.xni.grammars.Grammar] [Unloading class org.apache.xerces.dom.DocumentTypeImpl] [Unloading class org.springframework.web.util.IntrospectorCleanupListener] [Unloading class org.apache.xerces.impl.io.UTF8Reader] [Unloading class org.apache.xerces.impl.dtd.XMLDTDDescription] snip (many more classes are unloaded here) [Unloading class org.springframework.web.context.ContextLoaderListener] [Unloading class com.atlassian.core.util.XMLUtils] [Unloading class org.springframework.beans.factory.support.ReplaceOverride] 1982271K-1982271K(1999424K), 7.4622510 secs] [Full GC 1982271K-1981801K(1999424K), 8.9731420 secs] And the Full GC's continue for a little while, and eventually the process just dies off. - Original Message - From: Filip Hanik - Dev Lists [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, February 04, 2008 5:22 PM Subject: Re: Out of Memory Errors when upgrading from 5.0.27 to 6.0.14 what's the message after java.lang.OutOfMemoryError as there can be many different types of errors. Filip Dan D. wrote: Hello all, I'm currently working on upgrading our systems from using
tld parsing error after upgrade to TC6
Hello everyone. I'm currently working on upgrading our environment to Tomcat 6.0.14 from 5.0.27. This is run on Apache 1.3.33 with mod_jk 1.2.25 (which is being upgraded from jk2). I'm able to get the basic sites working fine, however, there are a few applications that are still causing issues, and was hoping someone here could at least point me in the right direction on how to determine the exact cause of the issue. Running Tomcat with debug logging (java.security.debug=access,failure) enabled, I get the following output regarding the error. Now, based off this output, it sounds like the error is occurring when the taglib.tld file from the jspsql.jar file attempts to make a call to an external website. Also, this error only occurs when we have -security enabled on startup of Tomcat (which it needs to be for our environment). If anyone can offer some advice on what the cause and/or resolution of this may be, I would be most grateful. access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/classes/org/apache/xerces/util/XMLChar.class read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access denied (java.io.FilePermission /web/tomcat/lib/jsp-api.jar read) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:313) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.util.zip.ZipFile.init(ZipFile.java:109) at java.util.jar.JarFile.init(JarFile.java:133) at java.util.jar.JarFile.init(JarFile.java:70) at sun.net.www.protocol.jar.URLJarFile.init(URLJarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:53) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132) at java.net.URL.openStream(URL.java:1009) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:740) at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:700) at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:258) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:811) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:525) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1157) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562) at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:518) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:476) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4428) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4235) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:123) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:769) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at
Re: If xerces is in WEB-INF/lib this is used for deployment/web.xml parsing on tomcat6 (bug or feature?)
I'm wondering if anyone has any input regarding this? I am having a similar
problem.
We are currently working on upgrading from Tomcat 5 (5.0.27) to Tomcat 6
(6.0.13) to take advantage of the better resource utilization. We are also
going from mod_jk2 to mod_jk (1.2.23), as we have had issues with jk2.
This is in a shared environment, so I do not know ahead of time what our
users will be loading in their webapps, and we have too many users to be
able to go through all of their apps and be sure they work properly.
I do have a sampling of apps that I am using to attempt to get a rough
feeling of how the migration will go, however.
There are a couple issues I have run into thus far, the xerces issue is one
of them. What I'm wondering is if there is a way to override the
functionality of allowing the WEB-INF/lib/xercesImpl.jar and
WEB-INF/lib/xml-apis.jar (and potentially other system jar files) being used
for a given app? Since we are not using xerces as the xml parser (crimson
is still being used here), it causes the web-app to fail, as it can't find
the ${java.home}/jre/lib/xerces.properties file.
Any advice would be greatly apprecated.
Thanks,
Dan
- Original Message -
From: Michael Wyraz [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Friday, May 25, 2007 5:36 AM
Subject: If xerces is in WEB-INF/lib this is used for deployment/web.xml
parsing on tomcat6 (bug or feature?)
Hi,
today i played around with tomcat 6 (latest).
I have an old webapp wich used Xerces 2.0.0. The Webapp deploys fine and
runs without Problems until i try to reload the Context.
In this case i get a NullpointerException fro xerces when it tries to load
web.xml via JNDI.
I played around with it and found that:
- when xerces is not present in WEB-INF/web.xml, the jdk-builtin xml
parser is used (com.sun...)
- when xerces is present in WEB-INF/web.xml, it is used to parse web.xml
during deployment and during reload
- in the 2nd case reload fails because the old xerces cannot read from
JNDI
I'm not sure how to solve this. I could change the Xerces version of my
application but this is the first of many apps i want to migrate to tomcat
6. Maybe some of this apps will not work with newer xerces.
I think tomcat should _not_ use a parser which is within the webapp's lib
directory for tomcat-specific tasks.
What do you think?
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk along side mod_dir -- How to get PHP to be seen as a default page
Hello, First, my apologies for inadvertently hijacking a previous thread. Long time reader, first time poster. Won't happen again. Now, First the versions: Apache : 1.3.33 Tomcat: 6.0.13 mod_jk: 1.2.23 I am currently working on upgrading our environment to a newer version of Tomcat and mod_jk, and seem to be running into an issue with mod_jk and mod_dir. More specifically, the issue I am running into is the default file list. As I understand, it is intended behavior for the Apache DirectoryIndex directive to be more or less ignored, and instead the welcome-file-list / directive in web.xml is used to determine which files are loaded and in which order by default. Now, the issue I run into is that I do not know in advance what our customers will be loading on their site. There is a very real possibility that they may have an index.php file, which we want to have load first. This is something that I want to have Apache load, instead of Tomcat attempting to parse it, since we run php in a sandbox (suPHP). Everything I have attempted, ends up basically the same when attempting to view a site by the hostname only (ie., http://hostname.tld/) If I add welcome-fileindex.php/welcome-file to the welcome-file-list in my web.xml, it simply asks me to download the php file, instead of it being parsed by Apache. If it is not in the welcome-file-list, it simply goes to the next one that is (index.html) and is still parsed by Tomcat, not Apache. The related Apache Jk settings are as follows: In addition, after the mod_jk include, but prior to any Jk settings, I have the following: LoadModule dir_module libexec/mod_dir.so LoadModule jk_modulelibexec/mod_jk.so IfModule mod_dir.c DirectoryIndex default.html default.htm index.php index.shtml index.html index.htm home.html home.htm welcome.html index.jsp /IfModule Location / SetEnvIf REQUEST_URI ^/(.*)/*.php$ no-jk SetEnvIf REQUEST_URI ^/(.*)/*.html$ no-jk /Location JkWorkersFile /web/conf/workers.properties JkUnMount /*.php local JkMountFile /web/conf/uriworkermap.properties JkLogFile /web/logs/mod_jk.log JkLogLevel info JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat %w %V %U %T The contents of workers.properties are: worker.list=local,jkstatus # Set properties for worker1 (ajp13) worker.local.type=ajp13 worker.local.host=localhost worker.local.port=8009 worker.local.lbfactor=1 worker.jkstatus.type=status worker.local.mount=/ /* The contents of uriworkermap.properties are: #exclude extensions !*.html=local !*.php=local I understand that there are a few settings that are redundant, but I have tried every don't touch php, tomcat setting I can find, and it is still attempting to parse it. Also a thing to note. This only happens when attempting to view the default page. If I browse directly to http://hostname.tld/index.php, it works fine. So, my question is, how do I either prevent Tomcat from handling these requests, or tell it to pass them back to Apache if it doesn't know what to do with them? I thank you for your time and help in this matter, Dan D.
mod_jk along side mod_dir -- How to get PHP to be seen as a default page
Hello, First the versions: Apache : 1.3.33 Tomcat: 6.0.13 mod_jk: 1.2.23 I am currently working on upgrading our environment to a newer version of Tomcat and mod_jk, and seem to be running into an issue with mod_jk and mod_dir. More specifically, the issue I am running into is the default file list. As I understand, it is intended behavior for the Apache DirectoryIndex directive to be more or less ignored, and instead the welcome-file-list / directive in web.xml is used to determine which files are loaded and in which order by default. Now, the issue I run into is that I do not know in advance what our customers will be loading on their site. There is a very real possibility that they may have an index.php file, which we want to have load first. This is something that I want to have Apache load, instead of Tomcat attempting to parse it, since we run php in a sandbox (suPHP). Everything I have attempted, ends up basically the same when attempting to view a site by the hostname only (ie., http://hostname.tld/) If I add welcome-fileindex.php/welcome-file to the welcome-file-list in my web.xml, it simply asks me to download the php file, instead of it being parsed by Apache. If it is not in the welcome-file-list, it simply goes to the next one that is (index.html) and is still parsed by Tomcat, not Apache. The related Apache Jk settings are as follows: In addition, after the mod_jk include, but prior to any Jk settings, I have the following: LoadModule dir_module libexec/mod_dir.so LoadModule jk_modulelibexec/mod_jk.so IfModule mod_dir.c DirectoryIndex default.html default.htm index.php index.shtml index.html index.htm home.html home.htm welcome.html index.jsp /IfModule Location / SetEnvIf REQUEST_URI ^/(.*)/*.php$ no-jk SetEnvIf REQUEST_URI ^/(.*)/*.html$ no-jk /Location JkWorkersFile /web/conf/workers.properties JkUnMount /*.php local JkMountFile /web/conf/uriworkermap.properties JkLogFile /web/logs/mod_jk.log JkLogLevel info JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat %w %V %U %T The contents of workers.properties are: worker.list=local,jkstatus # Set properties for worker1 (ajp13) worker.local.type=ajp13 worker.local.host=localhost worker.local.port=8009 worker.local.lbfactor=1 worker.jkstatus.type=status worker.local.mount=/ /* The contents of uriworkermap.properties are: #exclude extensions !*.html=local !*.php=local I understand that there are a few settings that are redundant, but I have tried every don't touch php, tomcat setting I can find, and it is still attempting to parse it. Also a thing to note. This only happens when attempting to view the default page. If I browse directly to http://hostname.tld/index.php, it works fine. So, my question is, how do I either prevent Tomcat from handling these requests, or tell it to pass them back to Apache if it doesn't know what to do with them? I thank you for your time and help in this matter, Dan D. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
