does lucee run on openJDK 18.0.1.1 ?

nope, not 100% as per the release announcements, we have a few outstanding bugs https://luceeserver.atlassian.net/browse/LDEV-3807

The latest 2.0.0.85-RC for the S3 extension (using the aws java libs) is looking really good https://dev.lucee.org/t/s3-extension-2-0-0-71-beta-awslib/10014/5?u=zackster

I've just committed my patch to resolve issues with ehCache working in distributed mode in Lucee. If anyone is interested in testing the patch, you can find it here: https://github.com/dswitzer/extension-ehcache My pull request can be found: https://github.com/lucee/extension-ehcache/pull/1

just want to start by saying the Performance Analyzer is quite cool, is there any chance we can set it up so it doesn't log Lucee admin URLs ?

Can anyone let me know how to reset the ROOT web context in Lucee? In server admin I have three web contexts. For some reason the ROOT context at /opt/lucee/tomcat/webapps/ROOT/ has picked up a url that isn’t one of ours and I need to clear it our.

is there anyway to get the lucee rest servlet to load the application scope? i have been asked to provide a rest endpoint to verify the datasource connections in application.cfc but if I use the rest servlet they dont exist

@zackster Congrats on getting a new build out! Let me know if there's anything you need from me for my pull request regarding the ehCache Extension fixes.

will do!

Sweet, this sounds like the impetus I needed to finally release my Commandbox 5.5.2 release!

@bdw429s do you have any automated CacheBox tests that check to make sure ehCache is working via a distributed setup? If so, would you mind testing my ehCache extension to make sure the tests are passing?

@zackster we have a regression at snapshot 140. It is either the session management or cookies, we are currently trying to narrow it down. The bug is, a user needs to log in each time they browse to a new page. - more details to come as we get them. However, was there anything changed between .139 and .140 that may cause either session or cookie management issues ? It may help us narrow down the issue.

Rather surprised this lack of java integration (https://helpx.adobe.com/coldfusion/using/java-integration-coldfusion.html) has not been raised as an

acf-compat

issue for Lucee? Can't find one, anyhow. Raised it: https://luceeserver.atlassian.net/browse/LDEV-4001

I’ve found a regression in lucee starting at v5.3.9.133, also 5.3.9.141 & 5.3.10.10-SNAPSHOT. Basically some kind of unsafe variable access when I do a multithreaded queryEach() and then inside that function doing a

for( var col in qWhatever)

where col will jump or repeat a row. Seems it’s not keeping the var scoped safely between threads. I have widdled the code down into a reproducible cfscript. When I change it to use 1 thread it works or when I replace with a

for( var x = 1; x< qWhatever.recordCount; x+=1 ) var col = queryGetRow( qWhatever );

then col is safe and works. When I run on v5.3.8.206 all use cases work. What should be my next steps?

download.lucee.org seems to be down atm @zackster?

yeah, I'm looking into it

server is back up

I updated the JRE on my windows server to jre-11.0.15.10-hotspot and it update the PATH to the directory. Restarted the server and it still shows lucee using the previous version on the lucee overview page. Is there more to it than just setting the path to the JRE in environmental vars?

aside from recompiling with some special logic, is there a way to add a callback to lucee to be notified of access to some scope? e.g. "every time

application

is touched, run some callback"

Has anyone ever noticed the

queryColumnData()

function has a

closure

argument. I never had. The argument shows in cfdocs.org/querycolumndata, but with no explanation at all. The docs.lucee.org/reference/functions/querycolumndata.html#argument-closure page simply says

UDF/Closure that call with the values from column

which is a little vague. Some testing appears to show that this closure can be used map the array by returning a different value which overrides the value taken from the column. For instance, this would upper case all the values from this column in the final array

myQuery
  .columnData( 'name', (data)=>data.ucase() );

but I'm really wondering why this exists. CFML already has a construct called

arrayMap()

which seems sufficient if I want to massage all the values of an array

myQuery
  .columnData( 'name' )
  .map( (data)=>data.ucase() );

I'm just not clear why

queryColumnData()

needed this as there's certainly no precedent set that any BIF that returns an array also has an inbuilt closure argument for also mapping that array.

Hi are there accurate release notes in any one place for each release of Lucee. I have seen a suggestion via a google search to look @ https://dev.lucee.org/c/news/release/8, but the first two released versions wanted to check - 5.3.7.47 and 5.3.7.48 - are not listed there, so that source is not reliable IMO. We're needing to upgrade from 5.3.7.47 to 5.3.9.n, and have already had one bug (fix) cause us grief (entirely our... indeed my fault, that one!), so I feel I need to check everything else that has changed between those versions.

thanks mate, the Lucee teams always appreciate your constant dismissive tone about our efforts I put a lot of time into compiling the release notes and managing releases, don't know how that one slipped thru, anyway the ultimate point of truth is github commits, I put the effort in to tag every single snapshot, so you can always follow the example from all the recent releases notes and pull them up yourself https://github.com/lucee/Lucee/compare/5.3.7.43...5.3.7.48

5.3.7.47 was a security release, but was in the wrong category, I have moved it into releases https://dev.lucee.org/t/lucee-vulnerability-alert-november-2020-cve-2021-21307/7643

Does anyone have a working example of a manual Distributed ehCache they can share? I have it working via multicast (with my fixes), but a manual configuration does not seem to work. I believe the issue to be with the RMI URIs. I know in AFC I needed special paths to get it to work after the hostname/port definitions. I can't end up using multicasting because there are issues with our datacenter host and their cloud solution, so I have to use a manual configuration.

I think the implicit Variable Access in Lucee debugging is great, but why does it list cfquery and cflock as variables scope items ?

does anyone have any ideas on this exception? I have never seen it before - it start a few days ago; (I will post it to the Lucee forums- but thought I would ask here, too, in real time) Thanks;

"ERROR","http-nio-8080-exec-4","05/26/2022","13:33:24","","class org.hibernate.exception.GenericJDBCException cannot be cast to class java.lang.ThreadDeath (org.hibernate.exception.GenericJDBCException is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @2a332ff8; java.lang.ThreadDeath is in module java.base of loader 'bootstrap');class org.hibernate.exception.GenericJDBCException cannot be cast to class java.lang.ThreadDeath (org.hibernate.exception.GenericJDBCException is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @2a332ff8; java.lang.ThreadDeath is in module java.base of loader 'bootstrap');lucee.runtime.exp.NativeException: class org.hibernate.exception.GenericJDBCException cannot be cast to class java.lang.ThreadDeath (org.hibernate.exception.GenericJDBCException is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @2a332ff8; java.lang.ThreadDeath is in module java.base of loader 'bootstrap')
        at lucee.commons.lang.ExceptionUtil.rethrowIfNecessary(ExceptionUtil.java:200)
        at lucee.runtime.type.UDFImpl._call(UDFImpl.java:348)
        at lucee.runtime.type.UDFImpl.call(UDFImpl.java:217)
        at lucee.runtime.type.scope.UndefinedImpl.call(UndefinedImpl.java:785)
        at lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:787)
        at lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1747)
        at model.verbatimmodel_cfc$cf.udfCall2(/gsncfc/model/verbatimModel.cfc:226)
        at model.verbatimmodel_cfc$cf.udfCall(/gsncfc/model/verbatimModel.cfc)
        at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:106)
        at lucee.runtime.type.UDFImpl._call(UDFImpl.java:344)
        at lucee.runtime.type.UDFImpl.call(UDFImpl.java:217)
        at lucee.runtime.ComponentImpl._call(ComponentImpl.java:684)
        at lucee.runtime.ComponentImpl._call(ComponentImpl.java:572)
        at lucee.runtime.ComponentImpl.call(ComponentImpl.java:1911)
        at lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:787)
        at lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1747)
        at dbsetup.scripts.verbatimdataloadrt_cfm$cf$mv.call(/dbsetup/scripts/verbatimDataLoadRT.cfm:11)
        at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034)
        at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926)
        at lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:217)
        at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:44)
        at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2460)
        at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2450)
        at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2421)
        at lucee.runtime.engine.Request.exe(Request.java:45)
        at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1179)
        at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1125)
        at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:102)
        at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
        at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:679)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ClassCastException: class org.hibernate.exception.GenericJDBCException cannot be cast to class java.lang.ThreadDeath (org.hibernate.exception.GenericJDBCException is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @2a332ff8; java.lang.ThreadDeath is in module java.base of loader 'bootstrap')

it seems lucee is slower than CF when it comes to initialising objects and / or templates, even when they're pre-compiled, not a real complaint, though it does make me wonder if there is anything I can do to improve things, or if there is any work in this space in lucee 6 ?

I guess once the templates are cached or what ever, they're generally at least as fast as CF