The Wed, 02 Mar 2016 22:29:35, Mark Thomas wrote :

That was pretty much a perfect question. A clear problem statement. A
clear description of what you expected to happen vs. what actually
happened. A clear description of what you tried. If only all posts to
the users list were like this.

This is an easy fix. The problem is that with no docBase defined and a
path of "", tomcat is going to use a docBase of "ROOT". That means
Tomcat is going to look for these files in "work/example1/ROOT" not in
"work/example1".

Generally, I'd recommend a slightly different directory structure.
Something like:
webapps-example1/ROOT.war
which auto expands into
webapps-example1/ROOT

Mark

Thank you. I know how it is when someone stop at your desk for help, but not 
giving you any details on what the problem is :)



I followed your advices. I created separated webapps under our ${catalina.base} 
folder webapps-example1, webapps-example2 and so on, with a ROOT.war in each of 
them (what we usually do with single webapps deployment).

It work... partially. I'm getting random crash with the same error as when it 
couldn't find the libraries.

org.apache.jasper.JasperException: The absolute uri: 
<http://java.sun.com/jsp/jstl/core> http://java.sun.com/jsp/jstl/core cannot be 
resolved in either web.xml or the jar files deployed with this application

I first thought it was browser cache, but after testing a few time with wget on 
Tomcat itself and still getting the error, I have the feeling I'm hitting a 
cache inside tomcat. Why it's random, I have no clue.



Next I tried the docBase approach I totally forgot about that setting  after we 
removed them when they got a behaviour change midway in Tomcat 7 and it was 
recommended not to used them.

With webapps-example1 and webapps-example2, everything and a configured 
docBase, everything worked. Multiple refresh did not cause random class not 
found without the docBase.  However, since I have a dozen webapps, leaving 12 
extra webapps folders under ${catalina.base} fell  a bit cumbersome.


So I tried again with the following directory structure :
webapps/example1/ROOT
webapps/example2/ROOT


It worked like a charm too, but I noticed something that may be a priority 
order issues between ContextConfig and HostConfig.

With this configuration:

------
   <Host name="www.example1.com<http://www.example1.com>" appBase="webapps/example1" 
unpackWARs="true" autoDeploy="false">
         <Context path="" reloadable="false" workDir="work/sourcesuite" 
docBase="/home/tomcat/wars/example1.war">
             <JarScanner scanClassPath="false" scanBootstrapClassPath="false"/>
             <Resources>
                 <PreResources className="org.apache.catalina.webresources.DirResourceSet"  
readOnly="true" webAppMount="/"
                 base="/home/tomcat/CMS/example1.com" />
             </Resources>
         </Context>
   </Host>
------


if I create ${catalina.base}/webapps and none of it's host appBase, I get the 
following error:

------
Mar 03, 2016 11:19:07 AM org.apache.catalina.startup.ContextConfig beforeStart
SEVERE: Exception fixing docBase for context []
java.io.IOException: Unable to create the directory 
[/vol0/home/cda/servers/CDA1/webapps/mediagrif/ROOT]
       at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:115)
       at 
org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:617)
       at 
org.apache.catalina.startup.ContextConfig.beforeStart(ContextConfig.java:753)
       at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:307)
       at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
       at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
       at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:394)
       at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:144)
       at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1408)
       at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:745)


       // Create the new document base directory
       if(!docBase.mkdir() && !docBase.isDirectory()) {
           throw new IOException(sm.getString("expandWar.createFailed", 
docBase));
       }

------

The source reveal that ExpandWar try to do a mkdir but not a mkdirs  . Since 
the parent is absent, it fail and crash.

BUT, some moment later, the HostConfig class is creating those exact parents, 
recursively.

-----
       if (host.getCreateDirs()) {
           File[] dirs = new File[] 
{host.getAppBaseFile(),host.getConfigBaseFile()};
           for (int i=0; i<dirs.length; i++) {
               if (!dirs[i].mkdirs() && !dirs[i].isDirectory()) {
                   log.error(sm.getString("hostConfig.createDirs",dirs[i]));
               }
           }


       at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1528)
       at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:286)
       at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
       at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
       at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:394)
       - locked <0xa00e6120> (a org.apache.catalina.core.StandardHost)
       at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:339)
       - locked <0xa00e6120> (a org.apache.catalina.core.StandardHost)
       at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:933)
       - locked <0xa00e6120> (a org.apache.catalina.core.StandardHost)
       at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:871)
       - locked <0xa00e6120> (a org.apache.catalina.core.StandardHost)
       at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
       - locked <0xa00e6120> (a org.apache.catalina.core.StandardHost)
       at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1408)
       at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:745)

-----

Is it normal that the context is initialized BEFORE the host is started, while 
expecting the host to create the structure, but failing because the structure 
is not present?

Should the expand be executed after the host created the proper structure for 
the context to expand it wars?


Thanks
--

Philippe Busque
1111, rue St-Charles Ouest,
Tour Est, bureau 255
Longueuil (Québec) Canada J4K 5G4
Tél. : 450-449-0102 ext. 3017
Télec. : 450-449-8725






Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent 
expressément au(x) destinataire(s) et peuvent contenir des renseignements 
confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez 
en aviser immédiatement l’expéditeur par courrier électronique. Veuillez 
également ne pas en prendre connaissance et en supprimer toutes les copies 
immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales 
n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le 
message ou des conséquences de tout virus informatique qui pourrait être 
transmis avec ce message. Ce message fait également l’objet d’un copyright. Il 
est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit 
sans le consentement écrit du détenteur du copyright.

This email and any files transmitted with it are solely intended for the use of 
the addressee(s) and may contain information that is confidential and 
privileged. If you receive this email in error, please advise us by return 
email immediately. Please also disregard the contents of the email, delete it 
and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and 
its subsidiaries do not accept liability for the views expressed in the email 
or for the consequences of any computer viruses that may be transmitted with 
this email. This email is also subject to copyright. No part of it should be 
reproduced, adapted or transmitted without the written consent of the copyright 
owner.

Reply via email to