Copied .CFConfig.json is being overwritten - Lucee 6

dev support
1

I’m using Packer to build a Docker container and I’m having an issue copying my .CFConfig.json settings over to /{lucee6}/tomcat/lucee-server/context/ folder. I can verify that the file is being copied, but when Lucee starts for the first time, it gets overwritten with a default one.

In my Packer setup.sh script, I copy a .CFConfig.json file that works locally (Windows 11) over to the /{lucee6}/tomcat/lucee-server/context/ folder the Docker Linux container and verify that it was copied correctly.

Then after I run the container and startup Lucee, I can verify that none of my settings are in the .CFConfig.json file. When I compare it with a copy of the original, I can see that they’re identical, so Lucee must be making a new one.

Is there a different way that I should be using to copy Lucee settings over to a Packer build?

Stack:

OS: ubuntu:20.04
Java Version: 21
Tomcat Version: 11
Lucee Version: 6.2.0.321

2

this is what we do for the update provider

COPY ./devops/.CFconfig-download.json5 /opt/lucee/server/lucee-server/context/.CFConfig.json

anything in the logs?

3

I had to run lucee after its installed, then shut Lucee down, then I can copy the .CFConfig.json file and it will persist. Not sure why Lucee would overwrite it on first run.

4

check your /{lucee6}/tomcat/lucee-server/context/logs/out.log ?

that’s the early log file for initial startup before log4j is even loaded

we have a lot of integration tests for CFconfig.json

5

Dropping your CFConfig.json in the deploy folder is my preferred approach these days

I’ve done some work to make the logging around the deploy folder much more informative

https://luceeserver.atlassian.net/browse/LDEV-5374

1 Like
6

This is what I was looking for… thank you.

What if I have a .jar file that needs to be loaded? I was planning to drop it in /lucee-server/context/lib/ but should I put it in the deploy folder instead?

7

the support for that /lib folder is broken in 6.2.0, but fixed in the 6.2.1 RC

the deploy folder doesn’t support jars

if the jar in on maven, it’s better to add a {javasettings:{[maven: [ .... ] }}} to your cfconfig (like for component) so Lucee will automatically download the jar itself into the lucee\tomcat\lucee-server\mvn folder

2 Likes
8

1. “deploy” and “lib” folders don’t exist after install, but it works!

Based on your suggestion, I decided to install Lucee 6.2.1.118-RC, and put my .CFConfig file in the /lucee-server/deploy folder and my .jar file in the /lucee-server/context/lib/ folder. Seems like this works, but neither the /lucee-server/deploy folder or the /lucee-server/context/lib folder exist after startup, so I create them first and then copy my files into them. Seems like if those directories should be created at install time.

2. How do I optimize Lucee startup?

After creating and then running my containers in Docker, it takes a long time for Lucee to startup (2-3 minutes) and then another couple minutes to start serving files in my app. Even after the first run, when restart the container, it still takes a few minutes to warm up.

It looks like I may be able to improve this by building a custom install and then warming up the install. However, the docs are lacking details. Do know where I can I find more info on these subjects?

I think I need to specify the extensions that my app requires in my .CFConfig.json file, but how? And then how would you warmup your installation? Do I just have add: export LUCEE_ENABLE_WARMUP=true before running the installer?

And will this improve startup times any time the container is run?

9

Given that the official docker images just work ™ and don’t have any of these issues, there must be some issue(s) how you are creating doing it?

Lucee has extensive logging, all the clues about your problems are to be found in the logs., I’ve done a lot of work on Lucee to improve the information in these logs to help debug such problems.

You need to be looking at the logs and sharing your findings, saying it takes 2-3 minutes isn’t really an actionable support request! What is taking 2-3 minutes??? what does your packer.sh script look like?

All the logs include timestamps so you should be able to see where the delay is occurring, the relevant logs are

  • Tomcat catalina.log
  • Lucee out.log which is the log file for initial start up & deployment, before the log4j sub system is initialized
  • Lucee deploy.log and Application.log

As you are using 6.2 you can easily redirect all the logs to the docker console using

https://luceeserver.atlassian.net/browse/LDEV-3420

As you are rolling your own, I’d also suggest comparing the logs from the working example of the official Lucee docker image to your own?

10

Thanks @Zackster, I am not implying there is a problem… just asking if it’s common that this kind of time to startup is normal. I’m not seeing any problems in the log files now that I’ve got my app running, though I haven’t yet tried optimizing the startup time yet.

My iteration cycle is fairly long between building the image and then running it, but I will investigate today.

I’m fairly new to Packer and building containers. Where I’m trying to get to is building CI/CD pipeline for automated testing and using terraform to deploy directly to AWS. Why would I use an official Lucee docker image if this is my plan?

11

the initial building of an image is always slow, the build of our official images takes 45 odd minutes, there are quite a few variations, jre, jdk, with ngnix and without… mostly it’s apt-get updating the base images

as for for why you wouldn’t just use the official images, that’s for you to answer.

You’re just deploying a docker image to terrorform? what’s different about your custom one vs the official ones?

12

No issues with the build time, just wondering about the startup time after the build.

I’ve got some jars to include as well as my app and I’m thinking of my containers as immutable, which is why I didn’t consider any official docker builds.

13

by startup time, does that include pulling all the base layers each time?

why do you not consider the lucee images not to be immutable?

you could just publish your own images built off the offical images to a private docker repo and achieve the same

14

I’m not saying they aren’t, but I am considering the entire container including my source code as the immutable container. So when I deploy a release to aws, a new image will be created, new ec2 instances will be created, and existing ec2 instances will be deleted.

I’m new to this so maybe there’s a way I would leverage an official Lucee container as part of the deployment plan?? Currently, I’m at the stage where I’m successfully deploying to docker in a local development environment and I’m thinking this is how I will setup dev machines.

Alternatively I could use commandbox to run local dev instances, but I’m not sure how that works with CI/CD and I’m trying to consolidate my efforts.

15

@Zackster - Based on my work today, it seems like using an official Lucee docker image will be a good way to go, but I’m not sure how to add my .jar files. The way I’m trying to do it is to mount a jar folder like this:

In docker-compose.yml:

- ./jars/:/opt/lucee/server/lucee-server/context/lib/

This doesn’t work and I suspect it’s because /opt/lucee/server/lucee-server/context/lib/ doesn’t exist until Lucee runs. When I look in this folder in the running docker container, there’s nothing in it, but I can verify that the local folder (outside of docker) does contain the jars.

Is there a recommended way to pull in jars from Maven along with dependencies? Or if I need to copy my own jars, how should I do that?

16

As I said…

and

as per the links in my initial reply

1 Like
17

Does Lucee also download all the dependencies for a Maven jar file specified in .CFConfig.json?

I ask because the .jar file I need to add is an SDK fat jar that I had to build, otherwise calls I made into the SDK would fail due to dependent classes not being found.

BTW, I’m running 6.2.1.118-RC which I think fixes the /lib folder issue. It worked in the docker image I created using the lucee 6 installer. But things are obviously different when I use the official lucee docker build.

18

Sure does, I have improved the language here to make that clearer

image
image1503×287 24.1 KB

Lucee 6.2 really makes working with java a lot simpler, the new support for import statements for Java classes rock, more new and less createObject().

If you are accessing static functions, remember to use the static Constructor var obj = className::staticMethod(), not new

The upcoming Lucee 7.0 release include further improvements for Java support

1 Like
19

OK sounds good… might want to update this doc to include that maven information:

20

Wanna become a Lucee contributor?

There’s a GitHub icon on each page on docs.

Any time you see something which could be clarified, improved, etc, it’s really easy to file a PR, click the icon, use the GitHub web editor…

1 Like