@zackster We've been using v1.2.0.0-SNAPSHOT of the Image Extension in production, but that's no longer available from downloads.lucee.org and our provisioning scripts are now broken. There was never an official release of the v1.2.x branch. The v1.2 code has been stable and includes the Twelve Monkeys libraries, but v1.0.0.50 does not. How is the state of the 2.0 betas? Are any reliable enough to use in production or should I just downgrade our version?

@cfsimplicity I added a github action to build and test for your mariadb extension https://github.com/cfsimplicity/lucee-mariadb/pull/10

Does Lucee by any chance curl

/

every 15sec (or so) by any chance? I'm seeing requests being logged from

curl/7.68.0

about every 15sec. Or might it be something to do with Lucee servers strummed up by commandbox? This is in a docker container, but we don't have a healthcheck configured

Having an issue with ElastiCache Redis using Lucee 5.3.9.166 extension 3.0.0.46 Running the following

<cfquery name ="test" datasource="#mydsn#" tags="mytag" cachedwithin="#createTimespan(1,0,0,0)#">
    select * from myTable
</cfquery>
<cfscript>
    writedump(var=test, expand=false)
    cacheClear(filter=listToArray("mytag"),cachename= 'querycache')
</cfscript>

I get:

lucee.runtime.exp.NativeException: java.lang.NullPointerException 
at lucee.runtime.cache.util.QueryTagFilter.accept(QueryTagFilter.java:27) 
at lucee.extension.io.cache.redis.CacheSupport.remove(CacheSupport.java:88) 
at lucee.runtime.functions.cache.CacheClear._call(CacheClear.java:111) 
at lucee.runtime.functions.cache.CacheClear.call(CacheClear.java:69) 
at dean_cfm$cf$i.call(/dean.cfm:3)

It only seems to happen with ElastiCache, if I use a local docker container, with the same Redis version, I dont get the error and the cacheClear removes the correct query from the cache. Happy to do more testing if someone can tell me why its throwing a NullPointerException in the QueryTagFilter.

I just finally switched the lucee docs build from

commandbox

over to lucee/script-runner Now the docs build takes 2mins instead of 4mins https://luceeserver.atlassian.net/browse/LD-160

spent some of a lazy Sunday arvo improving the Lucee test coverage, managed to find one obscure bug https://github.com/lucee/Lucee/pull/1909

I know this is from earlier this year - but that auto tracing of cfhttp calls is sick. Saved me hours of instrumenting service calls - https://luceeserver.atlassian.net/browse/LDEV-3810 Thanks so much for building that. Btw - the code I am working on bypasses CFHTTP for some slower web services and uses java .. something like this instead -

local.conn = createObject("java", "java.net.URL").init(arguments.url).openConnection(); etc ...

Is that normal, or maybe something that used to be a thing and isn't anymore? Code could have been there from before it was switched to lucee. If so, then i might ditch it - or keep it for 1 / 2 dog slow SOAP calls. I tested ~100 calls over cfhttp and the java version and observed about an average 20% improvement in the java version, but TBH most of the calls are < 20ms so the saving is barely anything - and they of course miss out on stuff like LDEV-3810, plus seems easier to debug with tools like FusionReactor when you use CFHTTP.

Has anyone here actively used this library? I am looking for insights for the community that we all would not have to repeat individually. https://github.com/softwareCobbler/luceedebug

I hate typos https://github.com/lucee/Lucee/pull/1911

cflocation automatically encodes url before redirecting https://luceeserver.atlassian.net/browse/LDEV-2164 fixed in 6.0

it's kinda annoying that getDirectoryFromPath() • only works on files, you can't use it to get the parent from a directory (i.e. on itself, the returned value from getDirectoryFromPath()) • also doesn't have a depth https://docs.lucee.org/reference/functions/getdirectoryfrompath.html i.e.

GetDirectoryFromPath( GetDirectoryFromPath( getCurrentTemplatePath() ) ) ==  GetDirectoryFromPath (getCurrentTemplatePath() )

https://github.com/zspitzer/Lucee/blob/6.0/core/src/main/java/lucee/runtime/functions/system/GetDirectoryFromPath.java#L38

Hi. I have problem with logging to Lucee under Commandbox. It can't log in to "Web" part while I reset context. After restart it is happening again. I recorded it https://dl.dropboxusercontent.com/s/hz6usnnp1numiun/mstsc_cLWCFOczLR.mp4 I have same problem on several instances and don't know how to fix it

Upgraded Lucee from 5.3.9 to 5.3.10 on a dev server and have noticed that the server takes much longer to start. We use the web.cfc to 'warm' the instance and an internal URL we call from the web.cfc throws

Bad Gateway (502)

. The Lucee admin is also not available for some minutes, but if I wait for that to become available, then I call our refresh URL, everything works fine. Instance is running under Commandbox 5.7 on Windows. More logging info in thread....

I'll happily take a nosedive into the source code, but does anyone know off the off to their head if the

cfhttp

tag, when used with the

file

attribute, writes the downloaded file out to disk as it receives it, as opposed to buffering the entire thing in memory first and then writing it. Imagine, downloading something like an 8 Gig file, etc. You'd want it to be flushed out to disk as it comes in.

According to "https://hub.docker.com/r/lucee/lucee" the latest Lucee release with Tomcat 9 and JDK 11 is "5.3.9.133-tomcat9.0-jdk11-openjdk". Unfortunately this release is from May 6, 2022. Not sure who is responsible, but is there a chance to update it to the latest stable release 5.3.10.97?

Working with a client looking to convert an old MachII site from Adobe over to Lucee. I haven't used MachII in quite some time-- is anyone aware of any immediate issues getting it to run on Lucee?

We’re working on improving our AWS setup with Docker and Lucee, and we want to use Cloudwatch for logs. Is it possible to have all Lucee logging being send to

stdout

and

stderr

? So that it becomes part of the Docker logs and picked up by Cloudwatch automatically.

Image ext 2.0.0.24-RC is out https://luceeserver.atlassian.net/browse/LDEV-4354

Hi Gang - I need some help with database connections, please. We use AWS RDS (MariaDB) I am using the MariaDB JDBC extension I am using 5.3.10.97, Lucee. RDS is set for MAX 250 connections. ALL the datasources have the same settings. "inf" connections 1 min idle timeout 5 min timeout. I have two symptoms that I need some help with and I have no idea, if they're even connected to each other. Doing some load testing, we managed to kill our application. 1. The log filling with errors about the connection being refused by the "datasource", "Too many connections". However RDS reports that we only ever open 150-ish. And with the max connections in the (lucee) datasource, being set to "infinity" - I just don't understand the error. 2. I run a jMeter test with 50 concurrent users (x 2 loops) (I tried 2 different types of tests - only one of these at a time) a. hit a REST API b. hit the login URL and submit the form with a valid username / password Further, I run this 3 times inside a minute. AWS monitoring shows that I have 300 connections open. (regardless of which jMeter test I am running API/Logjn) I wouldn't expect it to behave this way. When test run 1 completes - I would assume that the connections would now be idle. I would also assume that the second run of jMeter, would use the, now, idle connections that were created as part of the first run. But... it doesn't. It goes and creates another 100 connections. In fact I would have assumed that after the first loop of 50 - that the second iteration would have used the connections from the first iteration. My thinking being that they should now be idle at this point. Now even if I assume that jMeter is holding onto the connections - quitting jMeter doesn't clear the connections. This morning, I logged back into the staging server that we are doing this testing on and there were still 40 connections open. According to the AWS monitoring they have been "connected" since 2am - when I stopped trying to debug the issue. (it is now 930 am) After it fell to 40 connections - it remained there, flat. Even with 1 minute polling and 1 minute resolution in the monitoring - there wasn't a single change. So I guess what I am after is: How do "connections" work?

Hi everyone, already posted in the FR channel, but maybe it is a Lucee issue: I am having trouble with Fusionreactor in a Lucee Docker container. The Lucee image is:

FROM lucee/lucee:5.3.10.97-nginx-tomcat9.0-jdk11-openjdk

In the Dockerfile I am copying the FR files into a folder fusionreactor.jar libfrjvmti_x64.so

COPY ./cms/fusionreactor /custom-libs/fusionreactor

And in setenv.sh I am setting the FR opts:

setenv.sh
# FusionReactor opts
FR_OPTS="$FR_OPTS-javaagent:/custom-libs/fusionreactor/fusionreactor.jar=name=cms,address=8088 -agentpath:/custom-libs/fusionreactor/libfrjvmti_x64.so -Dfrlicense=$FR_LICENSE -Dfrshutdownaction=remove -Dfrlicenseservice.leasetime.hint=10 -Dfrregisterhostname=$FR_SERVERNAME -Dfr.cloud.group=cms"

But when I access FR in my browser I get the message: Fusion Reactor Fusion Reactor is not ready please try again in a few seconds. Already waited more the 10 minutes, the message doesn't change. Any hint would be appreciated!

So I've stumbled on a weird behavior, which seems like a bug to me (it certainly does not match ACF behavior): https://www.trycf.com/gist/5c8ab610df9eba0a32fbf72951d67c68/lucee5?theme=monokai When a

param

uses a string value of

NULL

for the

default

attribute, Lucee seems to be treated this as saying "Make this parameter null", which generates an error:

<cfscript>
param name="form.thisShouldDefaultToAString" default="NULL";

writeDump(form);
</cfscript>

If you change the string from

NULL

to

null

then it works as expected. If you add a

type

attribute of

string

, then it generates an empty string:

<cfscript>
param name="form.thisShouldDefaultToAString" type="string" default="NULL";

writeDump(form);
</cfscript>

This seems wrong to me and is certainly misleading. Is this a documented behavior?

In Lucee, I am loading a jar file from a path that is defined in Application.cfc (this.javaSettings.loadPaths = ['../build/lib'];)... but that jar file has a dependency (also in the ..build/lib directory) that is a higher version of what's bundled w/Lucee. (Specifically, hslqdb 1.8 is bundled with Lucee and the jar I'm loading requires hsqldb 2.4.1.) I'm trying to understand if going the OSGi route helps this scenario since I wouldn't be loading the jar directly - it's referenced by the jar I am loading.

In Lucee, I am loading a jar file from a path that is defined in Application.cfc (this.javaSettings.loadPaths = ['../build/lib'];)... but that jar file has a dependency (also in the ..build/lib directory) that is a higher version of what's bundled w/Lucee. (Specifically, hslqdb 1.8 is bundled with Lucee and the jar I'm loading requires hsqldb 2.4.1.) I end up getting an error due to the one bundled with Lucee getting referenced, I believe. I'm trying to understand if going the OSGi route helps this scenario since I wouldn't be loading the jar directly - it's referenced by the jar I am loading. Or should I explore JavaLoader?

Hi There, Does anyone have any experience with creating a WAR for a Lucee App? I have searched through the Lucee forums and Mr Google - without much luck. I found this; Blog post for AWS Elastic Beanstalk but I don't need anything AWS-ish. Unfortunately, I am not a Java Dev - so really have no idea. (I know it is just a zip - renamed) Ultimately I am hoping someone might have something like; • Unzip WAR • Copy source code <here> • Copy Lucee's <config file X> here • Copy Lucee's <config file Y> here • Copy existing web.xml from XXX to WWW ◦ Make these manual edits • rezip • rename to war. As always thanks.

Hi everyone Can someone explain why Lucee enforces the use of a password to use certain cache functions, like:

CacheRegionNew()

ACF does not enforce this. The consequences are enormous for migration projects. I am now facing this exact issue. We are migrating from ACF to Lucee, and from what I can see, unless we expose the plain text:

this.webAdminPassword

In the:

Application.cfc

We would need to build a form, before the main application loads and ask the user to submit the Administrator password, before proceeding. As I understand, the Administrator password is an encrypted hash, which means it cannot be reversed. So, I would need expose the clear text version of the password? I mean I understand that it is a security issue, but why does ACF feel that it is unnecessary to enforce this methodology? 🤔