After seeing the discussion @Adam Cameron iniciated about deprecation, it reminded me about isDefined() deprecation. Of course, I always use structKeyExists() everywhere. But the session scope doesn't seem to exist all the time. That"s when I help myself with isDefined(). How do I check if a scope exists without isDefined()? Is there a scopeExists() or similar?

Anyone from @rasia around? Just saw an ssl certificate expiration on rasia.ch and rasia.io

I feel I should know the answer to this... how do I determine how long the Lucee server has been up for? Having googled, I seem to be able to do this to get how long the whole JVM has been up for:

uptimeInMillis = createObject("java", "java.lang.management.ManagementFactory").getRuntimeMXBean().getUptime()

But: a) wondering if there's a more CFML- /Lucee -idiomatic way of doing it; b) that is not reset by a Lucee Server restart (via the admin), for obvious reasons. This is probably not an issue for what I need, but figured I'd mention it anyhow.

I keep running into issues with Lucee's handling of isNull() and it's handling of scope precedence. In a nutshell, if a local variable ends up being null and you use isNull() to check the variable, it will use scope precedence to check for another variable with the same name, which means parameters passed via the URL/FORM scope can change the behavior. Here's a simple example of the behavior: https://trycf.com/gist/926837625eb97f5cd4c79258cffc2ed7/lucee5?theme=monokai In Lucee 4.x and all versions of ACF, the dump returns

null

, but in Lucee 5 (and Railo) it returns

test

. Since the

modelId

is declared within the

local

scope, I would expect the

isNull(modelId)

to return true if

var modelId

exists in the function. However, you have to explicitly specify the

local

scope to get it to work (i.e.

isNull(local.modelId)

). I opened up a Lucee issue about this in May 2021, but there's been not traction: https://luceeserver.atlassian.net/browse/LDEV-3523 Am I wrong? Is this the behavior everyone else would expect? I see it as a real problem because any UDF in which you're using

isNull()

to check a local variable could end up returning drastically different results than what you're expected.

Trying to run some ColdBox test suites today and I'm getting this odd error

Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.

on Lucee 5.3.8.206 (stack in the thread). Has anyone ever seen this before?

So folks, who's tried out the 5.3.9 RC1? 5.3.9.88 has some additional fixes, feedback is very useful and appreciated

Daft question (google ain't helping me) how is the

session.sessionid

value derived in Lucee? Looks to be something like...

[application_name]_[a GUID]_0

. Is there anything more I should know beyond that?

Just finished a meeting with @micha discussing the 5.3.9 sprint, it's looking good. https://luceeserver.atlassian.net/jira/software/c/projects/LDEV/boards/10?sprint=56 Full support Java 17 won't make this sprint, otherwise everything remaining on the board is on track for RC2

Here's a stupid one I came across today: https://trycf.com/gist/7634b8f9fa03a5069ad5ab713501ac29/lucee5?theme=monokai

a = [1,2,3]

a.each((cookie) => {
    writeDump(cookie)
})

I've used a dumb variable name there (in the actual code I was looking over cookie values, so it made more sense 😉), but still.. I would expect

1,2,3

(and that's what I get on CF), but on Lucee I get three dumps of the cookie scope. I think CF's behaviour is legit... my own variable should take precedence over inbuilt ones (even if they "hide" the inbuilt ones). It was an edge case though and easily solved. Still... it's a CF incompat so should probably be addressed?

Can't seem to get to the

Extension/Applications

page in the server admin in any SNAP after 5.3.9.83 - is it just me? Filed: https://luceeserver.atlassian.net/browse/LDEV-3890

I see here https://docs.lucee.org/reference/tags/cookie.html, Lucee list "samesite" attribute to use in cfcookie tag. I try to use that like

<cfcookie name="my_cookiesname" value="#mycookie_value#" expires="90" httponly="yes" secure="#application.x#" samesite="strict" />

But my Lucee said I don't know about samesite. Here is error screen shot. My Lucee version is Lucee 5.3.6.61 Can anybody help me why my Lucee is unable to idedidentify the samesite attribute?

slight

queryparam

change with lucee 5.3.9.91, since 5.2.6, it would automatically set

list=true

if it was an array, this automatic behavior has been disabled https://luceeserver.atlassian.net/browse/LDEV-3893

Does anyone know if upgrading from Lucee 5.2.9 to 5.3.8 will resolve the TLS issues with Microsoft SMTP?

Known issue, patch pending

<cfdump output="console>

appears to get swallowed tomcat 8.5.63 Lucee 5.3.8.206 it is not in Catalina.out or stdout/stderror or the application.log in the lucee context where should I look or what am I missing, it is a lucee light install and I havent changed any of the standard output or log settings

static initialization ordering, are there any guarantees?

import Foo.Bar; // does this trigger a classload of Foo.Bar, or just fixup mappings
component {
    function init() {
        var x = Bar::staticProp; // guaranteed to be init'd?
    }
}

I need a refresher on this. I moved a site from cf to lucee (5.3.8.206), and upon doing so, all my serializejson responses have original case instead of being forced to upper case (which is what I want). my code is straight-forward, I perform a query and serializejson the response. I verified the server language/compiler setting, "Convert to upper case" which is checked on.

I'm trying to figure out if our ancient application will run on Lucee but getting this error on one of our reports. File has about 3500 lines in it.

There is too much code inside the template [summary.cfm], Lucee was not able to break it into pieces, move parts of your code to an include or an external component/function

Is there a setting I can override in Lucee to temporarily work around this error? At this point I'm just trying to get as much of this working as I can and identify areas where we need to go back and fix issues and /or refactor without spending time actually refactoring :)

mm/dd/yyyy MessageDigest not available added a hash(now(),'mm/dd/yyyy') to this.Applicationname

Is Tomcat 10 officially supported with Lucee? From what I'm reading, it would appear not due to Tomcat's transition from Java EE to Jakarta EE. I know there's a tool that can translate on the fly, but I'd rather stick with Tomcat 9 if that's the case.

Is there a future plan for

isValid

to be allowed as a member function?

@zackster We're running into issues with Lucee 5.3.9 due to it's removal of Log4j v1. Since this is a minor version change, therefore shouldn't be breaking, is there a chance it could ship with the Log4j1 bridge configured: https://logging.apache.org/log4j/2.x/manual/migration.html That way any code relying on Log4j1 will still work, but it'll be using v2. (I'm trying to see if there's any way to distribute it as an extension, but it seems like 5.3.9 shouldn't break stuff)

Am wondering if someone can cast some light on Lucee's inner workings when it comes to creating Java objects. Here's a gist: https://trycf.com/gist/8b67cae6202d341ed8ade82c913a5250/lucee5?theme=monokai Relevant bit:

try {
    radix = 36
    result = CreateObject("java", "java.math.BigInteger").init("42", radix)
    writeDump([result, radix.getClass().getName()]) // 146, java.lang.Double
} catch (any e) {
    writeDump([e.message, e.detail])
}

What I'm wondering is... given

radix

is a Double, and BigInteger doesn't implement a constructor that takes a Double for the radix (see https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/math/BigInteger.html), how this code runs, rather than giving something along the lines of "no suitable constructor found for BigInteger(String,Double)"

I'm hoping someone can help me with this Lucee classloader issue I'm having, related to trying to get Log4j 1.2 running in Lucee 5.3.9.108-RC2. I've dropped the

log4j-1.2.17.jar

into a folder that is loaded by the JVM via the classpath. I can run

createObject("java", "org.apache.log4j.Logger")

and Lucee will load the JAR. Now I have another JAR (let's call it Example.jar) being loaded via

this.javaSettings

in the

Application.cfc

and I have the

loadColdFusionClassPath

property set to

true

. I can call

createObject()

to load classes in Example.jar and it an instance of a class is created. However, the Example.jar is not able to see the

log4j-1.2.17.jar

classes. Any attempts to initiate classes that rely on the Log4j v1 return a huge stacktrace, the root appears to be with a class loader issue:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 137 more

If I move Example.jar into the same folder as

log4j-1.2.17.jar

then everything works as expected. However, I'm trying to keep Example.jar in a path loaded by

this.javaSettings

because it's updated frequently and I want to be able to dynamically reload the JAR. Why would using Lucee's JavaLoader prevent the class from being found? Should this be working? Am I misunderstanding something?

Not sure if this is Lucee or Coldbox? Starting in 5.3.9.95 (up through 108), we are having trouble displaying PDFs in browser. It's tough to get a stacktrace, but getting a

java.lang.NullPointerException

in Coldbox here:

coldbox\system\core\conversion\DataMarshaller.cfc

This is in a simple handler that just does:

var theBinary = fileReadBinary( file );
event.renderData( data=theBinary, type="PDF" );

Has anyone else experienced same? Dropping back to 5.3.9.92 fixes.

thanks to everyone who has been testing RC2, we have 3 confirmed regressions so far, we'll aim for a RC3 on Friday https://luceeserver.atlassian.net/jira/software/c/projects/LDEV/boards/10?sprint=56

This feels like a Lucee compatibility bug to me: https://www.trycf.com/gist/f40c924b1651fd4ecb22d8837e48c568/acf2016?theme=monokai

<cfscript>
function test(){
    var local = {modified=""};
    
    return local.modified;
}

writeDump(test());
</cfscript>

When you run the above in any version of ACF, the

test()

function returns an empty string. However, in Lucee it throws a

key [MODIFIED] doesn't exist on line 3

exception. Should I file a bug for this?