Error starting Tomcat 8 + Lucee 5.0.0.235-RC.war

[Ron Stewart]

I'm trying to set up a Lucee 5 deployment on Tomcat 8 on one of my development boxes (OS X 10.11.4, Java 1.8.0_77, Tomcat 8.0.33) by deploying the WAR (version noted in the subject line). I've used the same approach I've always used for deploying Lucee 4.5, Railo, and Adobe ColdFusion from WAR files. The WAR file seems to deploy fine, but when I attempt to start Tomcat and the Lucee 5 context, it fails to start. The following is from the catalina.out log file:

15-Apr-2016 10:20:57.694 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version:        Apache Tomcat/8.0.33

15-Apr-2016 10:20:57.705 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          Mar 18 2016 20:31:49 UTC

15-Apr-2016 10:20:57.705 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number:         8.0.33.0

15-Apr-2016 10:20:57.706 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Mac OS X

15-Apr-2016 10:20:57.706 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            10.11.4

15-Apr-2016 10:20:57.706 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          x86_64

15-Apr-2016 10:20:57.707 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:             /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre

15-Apr-2016 10:20:57.707 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version:           1.8.0_77-b03

15-Apr-2016 10:20:57.708 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:            Oracle Corporation

15-Apr-2016 10:20:57.708 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:         /Users/ron/opt/t8i/l5

15-Apr-2016 10:20:57.709 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:         /Users/ron/opt/t8

15-Apr-2016 10:20:57.713 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=./conf/logging.properties

15-Apr-2016 10:20:57.714 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

15-Apr-2016 10:20:57.714 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs=/Users/ron/opt/t8/endorsed

15-Apr-2016 10:20:57.714 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=.

15-Apr-2016 10:20:57.715 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/Users/ron/opt/t8

15-Apr-2016 10:20:57.715 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=./temp

15-Apr-2016 10:20:57.716 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /Users/ron/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.

15-Apr-2016 10:20:58.005 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]

15-Apr-2016 10:20:58.046 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

15-Apr-2016 10:20:58.064 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"]

15-Apr-2016 10:20:58.067 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

15-Apr-2016 10:20:58.073 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 1002 ms

15-Apr-2016 10:20:58.128 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Catalina

15-Apr-2016 10:20:58.129 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.0.33

15-Apr-2016 10:20:58.877 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error during ServletContainerInitializer processing

 javax.servlet.ServletException: java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [file:/Users/ron/opt/t8i/l5/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/charttag.tld] to a known, local entity.

at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:105)

at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5240)

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)

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)

Caused by: java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [file:/Users/ron/opt/t8i/l5/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/charttag.tld] to a known, local entity.

at org.apache.tomcat.util.descriptor.LocalResolver.resolveEntity(LocalResolver.java:155)

at com.sun.org.apache.xerces.internal.util.EntityResolver2Wrapper.resolveEntity(EntityResolver2Wrapper.java:177)

at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(XMLEntityManager.java:997)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1157)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1050)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:964)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)

at org.apache.tomcat.util.descriptor.tld.TldParser.parse(TldParser.java:76)

at org.apache.jasper.servlet.TldScanner.parseTld(TldScanner.java:279)

at org.apache.jasper.servlet.TldScanner.parseTld(TldScanner.java:271)

at org.apache.jasper.servlet.TldScanner.scanResourcePaths(TldScanner.java:241)

at org.apache.jasper.servlet.TldScanner.scanResourcePaths(TldScanner.java:232)

at org.apache.jasper.servlet.TldScanner.scanResourcePaths(TldScanner.java:232)

at org.apache.jasper.servlet.TldScanner.scanResourcePaths(TldScanner.java:232)

at org.apache.jasper.servlet.TldScanner.scanResourcePaths(TldScanner.java:232)

at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:105)

at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:103)

... 8 more

15-Apr-2016 10:20:58.935 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [] startup failed due to previous errors

15-Apr-2016 10:20:58.974 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]

15-Apr-2016 10:20:58.983 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"]

15-Apr-2016 10:20:58.984 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 910 ms

The failure seems to be related to being unable resolve an XML resource (dtd/web-cfmtaglibrary_1_0.dtd). I have verified that the noted file is not part of what was deployed from the WAR file.

Questions:

1. Has anyone successfully deployed the WAR for use?

2. Is the WAR missing one or more files needed to successfully deploy and use Lucee 5?

Thanks for any help you might offer.

-- 

/ron

[Juan Aguilar]

Ron,

Not much help here except to say I have a similar environment and was able to deploy the WAR successfully.

Good luck,

Juan

[Juan Aguilar]

Whoops. Spoke too soon.

Started up fine. Then stopped and added a new host to my server.xml (See https://groups.google.com/d/msg/lucee/ZGa10NY3iqA/RWrDOe1zBwAJ).

Now I can't restart and am getting the same error:

16-Apr-2016 07:44:26.188 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /usr/local/apache-tomcat-8.0.33/webapps/ROOT.war

16-Apr-2016 07:44:26.751 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error during ServletContainerInitializer processing

 javax.servlet.ServletException: java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [file:/usr/local/apache-tomcat-8.0.33/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/charttag.tld] to a known, local entity.
at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:105)at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:105)

I tried erasing the host and starting over but that didn't help.

So, I think LDEV-257 may still be an issue.

[Ron Stewart]

Thanks for the follow-up, Juan. Seems like you have encountered the same issue. Hopefully, one of the Lucee devs can shed more light on this.

[Juan Aguilar]

Yup. 

After a little more testing I found that:

1) If I delete webapps/ROOT and have Tomcat redeploy ROOT.war, the server will startup. BUT, if I shutdown and startup again, the java.io.FileNotFoundException occurs again.

2) If I delete webapps/ROOT, have Tomcat redeploy ROOT.war, and have a Host node in server.xml, Lucee does not deploy to the Host. AND, if I shutdown and startup again, the java.io.FileNotFoundException occurs again. 

Don't know if it's an OS X only issue.

[Ron Stewart]

I'm starting to think this may be a Tomcat 7- vs Tomcat 8-related issue. I also have Tomcat 7.0.68 on one of my other development boxes, and ran through a quick deployment of the same 5.0.0.235-RC.war file there. It deploys, but the difference is that the server will start and run there. The Tomcat catalina.out log file contains the following warnings, which seem to be very much related to the errors an identical deployment under Tomcat 8 throws:

Apr 16, 2016 3:26:42 PM org.apache.catalina.startup.TldConfig tldScanResourcePaths

WARNING: Failed to process TLD found at [/WEB-INF/lucee-server/context/library/tld/charttag.tld]

java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [null] to a known, local entity.

at org.apache.tomcat.util.descriptor.LocalResolver.resolveEntity(LocalResolver.java:154)

at com.sun.org.apache.xerces.internal.util.EntityResolver2Wrapper.resolveEntity(EntityResolver2Wrapper.java:177)

at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(XMLEntityManager.java:997)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1157)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1050)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:964)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)

at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:565)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:416)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:265)

at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:590)

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)

at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5472)

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)

at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1572)

at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1562)

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)

Apr 16, 2016 3:26:42 PM org.apache.catalina.startup.TldConfig tldScanResourcePaths

WARNING: Failed to process TLD found at [/WEB-INF/lucee-server/context/library/tld/pdftag.tld]

java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [null] to a known, local entity.

at org.apache.tomcat.util.descriptor.LocalResolver.resolveEntity(LocalResolver.java:154)

at com.sun.org.apache.xerces.internal.util.EntityResolver2Wrapper.resolveEntity(EntityResolver2Wrapper.java:177)

at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(XMLEntityManager.java:997)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1157)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1050)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:964)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)

at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:565)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:416)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig.java:431)

at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:265)

at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:590)

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)

at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5472)

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)

at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1572)

at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1562)

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)

Apr 16, 2016 3:26:42 PM org.apache.catalina.startup.TldConfig execute

INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.

Note that these are warnings, whereas Tomcat 8 seems to encounter these and then refuses to start.

Still hoping one of the Lucee devs will weigh in on this and shed some light on what's amiss.

[Ron Stewart]

Out of curiosity, this evening I tried deploying on my Linux system with Java 8, Tomcat 8, and the 5.0.0.235-RC.war file. The behavior there (successful expansion of the WAR file, failure to start) is identical to what I have shown above on OS X. It seems that this behavior is not specific to OS X.

If I get a chance tomorrow, I will try Tomcat 7 on that same Linux system.

[denstar]

Hi Ron,

I gave you a link for the 236-SNAPSHOT tomcat download, which you said
you tried, and got the same results from.

Did you just copy the war file, or did you try running the version of
Tomcat that came with that snapshot link?

I ask because I'm pretty sure that one of the setting that I change for
Tomcat when I do the build is to turn off classpath scanning, which
means it doesn't search for TLD and other things at startup, which makes
it faster.

I'm guessing the reason the issue is popping up after one successful run
is that there's a TLD file somewhere in an archive that gets expanded on
first run (like the web context) and thus when you try to run again (or
modify the server.xml file, as Juan was doing) it picks up the expanded
file.

Maybe try editing the catalina.properties and see if you have this line
in there:

tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*

If not, try adding it (or modifying the line containing it, which I
think defaults to a list of jars that come with Tomcat) and see if that
doesn't get you past the issue... just a guess tho.

-Den

> --
> Love Lucee? Become a supporter and be part of the Lucee project today! -
> http://lucee.org/supporters/become-a-supporter.html
> ---
> You received this message because you are subscribed to the Google
> Groups "Lucee" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lucee+un...@googlegroups.com
> <mailto:lucee+un...@googlegroups.com>.
> To post to this group, send email to lu...@googlegroups.com
> <mailto:lu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lucee/64126224-22d3-4ed2-91b4-dd2017904064%40googlegroups.com
> <https://groups.google.com/d/msgid/lucee/64126224-22d3-4ed2-91b4-dd2017904064%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Ron Stewart]

@Denny: Thanks for the follow-up here, as well. In trying the 236 snapshot you referenced, I did download and look through it but I did not use that custom build of Tomcat (I tried to deploy and run the 236 snapshot WAR from the Lucee site). Sorry if I was not clear on that in indicating that the 236 snapshot behaved the same. 

After encountering identical behavior on my Linux system yesterday evening, I had come to a general conclusion, given your indication of success, that it had to be something about either how I am deploying it or in the completely stock Tomcat configuration I am using (both on OS X and on Linux)... a conclusion headed in very much the same direction as yours below. I will investigate along those lines on both platforms and follow-up here and on Slack.

Thanks again for your help; I very much appreciate it.

[Ron Stewart]

@Denny: I've wrestled with this for a couple more hours this evening, and I am not much closer to figuring out what's going on, although I am sort of convinced it is not related to the OS, the version of Java, or the jar scanning configuration. More on that in a minute...

I did pull down one of the snapshot ZIP archives you noted, expanded it, and ran it with "lucee-ctl start", and it runs (i.e., I get the normal "welcome" page when I go to localhost:8888), stop it with "lucee-ctl stop", start it again, and it works. Given all of the moving pieces here, that at least would seem to tell me it is not specific to the OS or the Java version.

With my stock Tomcat 8.0.33 expanded in ~/opt/t8, I create a folder for a Tomcat instance and prep it for use with:

$ cd ~/opt/t8i

$ mkdir l5 # that's el-five for lucee5

$ cd l5

$ mkdir lib logs temp webapps work

$ cp ~/Downloads/5.0.0.235-RC.war webapps/

$ cp -R ~/opt/t8/conf ./conf

I edit conf/server.xml and replace the <Host> entry with one that is as stripped down as I can get:

      <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false">

<Context path="">

<Manager pathname="" />

</Context>

      </Host>

... then start Tomcat with that l5 directory as my current directory:

$ CATALINA_BASE=. ~/opt/t8/bin/startup.sh

Tomcat expands the WAR file, and Lucee starts fine (again, I get the expected "welcome" page at localhost:8080). As soon as I stop Tomcat...

$ CATALINA_BASE=. ~/opt/t8/bin/shutdown.sh

... and then restart it...

$ CATALINA_BASE=. ~/opt/t8/bin/startup.sh

... I get the error with the stacktrace noted in my original post on this thread.

I have changed conf/catalina.properties to set tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* as you suggested (no difference), added the <JarScanner /> element to the <Context > so that it matches the corresponding directive in your build (no difference), tried it with and without the tldValidation="false" attribute on the <Context > (again, no difference). (Hence my comment above that this doesn't seem -- to me -- to be related to JAR scanning).

About all that's clear to me is that Tomcat is finding what it needs on first run when it expands the WAR and deploys/starts the app the first time but not on subsequent starts (which causes it to fail), and that there is still something different between your ZIP'd build-and-configuration than with a stock Tomcat and this approach to deployment (the basics of which I've used without problems with CF, Railo, and Lucee 4.5, enabling me to have multiple Tomcat instances without any problem to date). I just have not been able to figure out what the difference is that is causing the breakage...

[denstar]

Interesting! Well, since you got the same error when you used just the
war from that snapshot build, the problem must be with Tomcat.

For the snapshot build I linked to, I just grab Tomcat from maven
central and then tweak the configs to be the way we like them... but it
/should/ just deploy with a vanilla install too-- just less optimized.

I can run a diff against the stock tomcat artifact and see what exactly
gets modified, but like I said, it's not much, and it sounds like you've
tried all the changed settings. For curiosity's sake, I'll also try
just plunking the war down in tomcat, and see if I get the same error.

FWIW, @micha, there are a few TLD files (in extensions, etc.) that still
use the Railo DTD... looks like we add that in the constants (probably
to make upgrading from Railo possible?), so it shouldn't matter, really,
but we might wanna update 'em at some point...

-den

On 04/18/2016 11:03 PM, Ron Stewart wrote:
> @Denny: I've wrestled with this for a couple more hours this evening,
> and I am not much closer to figuring out what's going on, although I am
> sort of convinced it is not related to the OS, the version of Java, or
> the jar scanning configuration. More on that in a minute...
>
> I did pull down one of the snapshot ZIP archives you noted, expanded it,
> and ran it with "lucee-ctl start", and it runs (i.e., I get the normal
> "welcome" page when I go to localhost:8888), stop it with "lucee-ctl
> stop", start it again, and it works. Given all of the moving pieces
> here, that at least would seem to tell me it is not specific to the OS
> or the Java version.

...

[mark]

Hey Denny, any chance you can take a look at getting Lucee 5.0.0.235-RC.war to work with Jetty?

Iv'e tried a couple times and all seems good until the server gets shutdown and it won't restart.

[denstar]

Probably the same error for both... seems, at first glance that the
problem is the external xml entities... for tomcat, adding this to the
context.xml:

xmlBlockExternal="true"

might fix it. Haven't tested yet. I did grab jetty, got the same
error, so it's probably maybe the same thing.

IIRC, there was a big fuss not too long ago when folks realized that
including external entities was a gaping security hole, dollars to
donuts this is part of that, but I'm only guessing.

-den

> --
> Love Lucee? Become a supporter and be part of the Lucee project today! -
> http://lucee.org/supporters/become-a-supporter.html
> ---
> You received this message because you are subscribed to the Google
> Groups "Lucee" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lucee+un...@googlegroups.com
> <mailto:lucee+un...@googlegroups.com>.
> To post to this group, send email to lu...@googlegroups.com
> <mailto:lu...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lucee/006dea2c-a314-40c6-829c-abe02736fc24%40googlegroups.com
> <https://groups.google.com/d/msgid/lucee/006dea2c-a314-40c6-829c-abe02736fc24%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ron Stewart]

I just tried with xmlBlockExternal set to true and then set to false on the Context, with no change in either case.

[Juan Aguilar]

I noticed a difference when using xmlBlockExternal="false" in context.xml:

Context.xml no xmlBlockExternal attribute

19-Apr-2016 10:59:28.199 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error during ServletContainerInitializer processing

 javax.servlet.ServletException: java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [file:/usr/local/apache-tomcat-8.0.33/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/charttag.tld] to a known, local entity.

Context.xml with xmlBlockExternal="true" (this is anticipated since xmlBlockExternal="true" is the default value)

19-Apr-2016 11:04:59.018 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error during ServletContainerInitializer processing

 javax.servlet.ServletException: java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [-//Railo//DTD CFML Tag Library 1.0//EN], system ID [dtd/web-cfmtaglibrary_1_0.dtd] and base URI [file:/usr/local/apache-tomcat-8.0.33/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/charttag.tld] to a known, local entity.

Context.xml with xmlBlockExternal="false"

19-Apr-2016 11:00:37.979 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error during ServletContainerInitializer processing

 javax.servlet.ServletException: java.io.FileNotFoundException: /usr/local/apache-tomcat-8.0.33/webapps/ROOT/WEB-INF/lucee-server/context/library/tld/dtd/web-cfmtaglibrary_1_0.dtd (No such file or directory)

at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:105)

That last aspect is different. If I look, that dtd folder definitely does not exist.

[Ron Stewart]

Sorry, yes. I should have been more specific: no change in terms of whether it works but the nature of the error itself is different as Juan noted.

[Allen Weng]

is it true after you deploy the WAR, you see the following 3 folders all in the webapps\ROOT\WEB-INF\ directory?

lib (only a lucee.jar there)

lucee-server

lucee

I have the same problem, the way I resolve it for now is to stop Tomcat 8, then manually move both lib and lucee-server folders to be next to the webapps directory, then restart Tomcat 8

now it works....

Allen

[Juan Aguilar]

Thanks, Allen. This does seem to be a workaround.

After the first startup, I can:

• Stop Tomcat 8
  
• Delete webapps/ROOT.war, webapps/ROOT/WEB-INF/lib, and webapps/ROOT/WEB-INF/lucee-server
• Restart Tomcat 8

This creates a lucee-server directory in my ./tomcat home directory.

With the first start my server Configuration File is /usr/local/apache-tomcat-8.0.33/webapps/ROOT/WEB-INF/lucee-server/context/lucee-server.xml but with the second restart, my server Configuration File is /usr/local/apache-tomcat-8.0.33/lucee-server/context/lucee-server.xml so and I should set the server context administrator password after the second restart.

So, progress...

On Tuesday, April 19, 2016 at 2:28:04 PM UTC-4, Allen Weng wrote:

is it true after you deploy the WAR, you see the following 3 folders all in the webapps\ROOT\WEB-INF\ directory?

lib (only a lucee.jar there)

lucee-server

lucee

I have the same problem, the way I resolve it for now is to stop Tomcat 8, then manually move both lib and lucee-server folders to be next to the webapps directory, then restart Tomcat 8

now it works....

Allen

[Allen Weng]

Hi, Juan

are you sure you can 

• Delete webapps/ROOT.war, webapps/ROOT/WEB-INF/lib, and webapps/ROOT/WEB-INF/lucee-server

then it will still work?

I just tried my instance and it does not work... (it is running on Windows)

What I did was

• Stop Tomcat 8
  
• Delete webapps/ROOT.war, 

• MOVE webapps/ROOT/WEB-INF/lib, and webapps/ROOT/WEB-INF/lucee-server
• Restart Tomcat 8

in this case you don't need to reset your password with the 2nd restart and all your configuration should still be there.

Hope this helps, thanks!

Allen

[denstar]

On 04/19/2016 05:33 AM, Ron Stewart wrote:
> I just tried with xmlBlockExternal set to true and then set to false on
> the Context, with no change in either case.

Yeah, I should have said false, vs. true, but as you've found out, it
only gets you past one error to another.

You can copy the DTD files from the sources (not sure why they're not
deployed) on github into the directory it's looking for, as well as
having that xmlBlockExternal="false", and you'll get past the error.

Another solution is to set the server and web context locations to
somewhere outside the default location inside WEB-INF, I believe, which
might be a better/more maintainable solution.

DeN

[Ron Stewart]

Finally got back to poking at this a bit this afternoon... and I can confirm that creating folder webapps/ROOT/WEB-INF/lucee-server/context/library/tld/dtd and dropping the four .dtd files from the github source there, in combination with xmlBlockExternal="false" on the context appears to give me a functional deployment that will stop and start multiple times. I've made no other changes to the files and directory structure that gets expanded from the WAR file (e.g, moving around the lucee.jar and the lucee-server folder, per some of the other posts on this thread). I've not done any testing beyond just making sure it will start/stop multiple times and gives me the server and web admin sign-in pages when requested.

This (the missing files and having to add the xmlBlockExternal="false" on the context) feels to me like an issue with the WAR; am I wrong on that?

[denstar]

On 04/24/2016 04:28 PM, Ron Stewart wrote:
...

> This (the missing files and having to add the xmlBlockExternal="false"
> on the context) feels to me like an issue with the WAR; am I wrong on that?

The xmlBlockExternal isn't a /problem/ per se, with the WAR, and could
be addressed by adding a META-INF/context.xml file containing that
setting (I'd rather not have to do that at all of course, just not sure
if there's a way around it), but the missing DTDs *are* a problem,
worthy of a ticket, if you get a chance.

DeN

[Juan Aguilar]

Don't know if I did this right but I gave it the old college try:

5.0.0.235-RC WAR file is missing DTD files from Source: https://luceeserver.atlassian.net/browse/LDEV-828

[Ron Stewart]

Thanks, Juan. Beat me to it.