Lucee 5.3.9.133 Stable Release

Make what an option ?
The addToken stuff ?
It’s already got a per-application setting, so I assume Lucee just changes the server default and you can turn it back on per-project

Does anyone know what version of the Redis Extension is good to go? I’ve tried the latest 2 versions but we’re having issues deploying the extension.

We’re running Lucee in Docker building against Tomcat. Dropping the Lucee-Lite jar in, then bringing the system up having dropped the extensions we use in the deploy folder.

The current extensions we’re using are:

compress-extension-1.0.0.7.lex
esapi-extension-2.2.4.5.lex
lucee.image.extension-1.0.0.42.lex
org.lucee.axis.extension-1.4.0.37-SNAPSHOT.lex
org.lucee.mssql-7.4.1.jre8.lex
pdf-extension-1.1.0.7.lex
redis.extension-3.0.0.39-BETA.lex
s3-extension-0.9.4.154.lex

When the image is finally running the Redis extension hasn’t deployed and the deploy log says:

"Severity","ThreadID","Date","Time","Application","Message"
"ERROR","main","04/29/2022","12:55:25","extract-extension","could not found [/extensions/.index] defined in the index in the lucee.jar"
"ERROR","main","04/29/2022","12:55:45","Extension","Unable to resolve redis.extension [59](R 59.0): missing requirement [redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L)) [caused by: Unable to resolve org.lucee.aws-core [68](R 68.0): missing requirement [org.lucee.aws-core [68](R 68.0)] osgi.wiring.package; (osgi.wiring.package=com.amazonaws.services.s3.internal)] Unresolved requirements: [[redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L))];lucee.runtime.exp.NativeException: Unable to resolve redis.extension [59](R 59.0): missing requirement [redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L)) [caused by: Unable to resolve org.lucee.aws-core [68](R 68.0): missing requirement [org.lucee.aws-core [68](R 68.0)] osgi.wiring.package; (osgi.wiring.package=com.amazonaws.services.s3.internal)] Unresolved requirements: [[redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L))]
	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:2281)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
	at lucee.loader.osgi.BundleUtil.start(BundleUtil.java:112)
	at lucee.loader.osgi.BundleUtil.start(BundleUtil.java:108)
	at lucee.runtime.osgi.OSGiUtil._start(OSGiUtil.java:1229)
	at lucee.runtime.osgi.OSGiUtil._startIfNecessary(OSGiUtil.java:1182)
	at lucee.runtime.osgi.OSGiUtil.startIfNecessary(OSGiUtil.java:1177)
	at lucee.runtime.osgi.OSGiUtil._loadBundle(OSGiUtil.java:553)
	at lucee.runtime.osgi.OSGiUtil.loadBundle(OSGiUtil.java:505)
	at lucee.commons.lang.ClassUtil.loadClassByBundle(ClassUtil.java:155)
	at lucee.transformer.library.ClassDefinitionImpl.getClazz(ClassDefinitionImpl.java:110)
	at lucee.runtime.config.XMLConfigAdmin.setClass(XMLConfigAdmin.java:6611)
	at lucee.runtime.config.XMLConfigAdmin._updateCache(XMLConfigAdmin.java:4244)
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(XMLConfigAdmin.java:4873)
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(XMLConfigAdmin.java:4692)
	at lucee.runtime.config.XMLConfigAdmin._updateRHExtension(XMLConfigAdmin.java:4674)
	at lucee.runtime.config.DeployHandler.deploy(DeployHandler.java:88)
	at lucee.runtime.engine.CFMLEngineImpl.<init>(CFMLEngineImpl.java:414)
	at lucee.runtime.engine.CFMLEngineImpl.getInstance(CFMLEngineImpl.java:746)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at lucee.loader.engine.CFMLEngineFactory.getEngine(CFMLEngineFactory.java:1451)
	at lucee.loader.engine.CFMLEngineFactory.initEngine(CFMLEngineFactory.java:384)
	at lucee.loader.engine.CFMLEngineFactory.initEngineIfNecessary(CFMLEngineFactory.java:262)
	at lucee.loader.engine.CFMLEngineFactory.getInstance(CFMLEngineFactory.java:168)
	at lucee.loader.engine.CFMLEngineFactory.getInstance(CFMLEngineFactory.java:202)
	at lucee.loader.servlet.CFMLServlet.init(CFMLServlet.java:42)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1134)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1089)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:983)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4902)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5211)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
	at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:843)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:434)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:342)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
Caused by: org.osgi.framework.BundleException: Unable to resolve redis.extension [59](R 59.0): missing requirement [redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L)) [caused by: Unable to resolve org.lucee.aws-core [68](R 68.0): missing requirement [org.lucee.aws-core [68](R 68.0)] osgi.wiring.package; (osgi.wiring.package=com.amazonaws.services.s3.internal)] Unresolved requirements: [[redis.extension [59](R 59.0)] osgi.wiring.bundle; (&(osgi.wiring.bundle=org.lucee.aws-core)(bundle-version>=1.11.877.0001L))]
	... 64 more
"

We sometimes have this same issue installing via the UI… but sometimes it does work, then upgrading/downgrading the latest versions work…

My initial thoughts (which I’m about to test) is that we deploy the current extensions, then bring down, bring up and deploy just the redis hoping that S3 has deployed properly hoping it fixes what looks like the issue…

[org.lucee.aws-core [68](R 68.0)] osgi.wiring.package; (osgi.wiring.package=com.amazonaws.services.s3.internal)] Unresolved requirement

Update: Nope, the double deploy didn’t seem to work, so we’ve rolled back to redis.extension-2.9.0.4-BETA for the time being

Docker builds are up!

https://hub.docker.com/r/lucee/lucee/tags

3 Likes

I always tried to understand what the Lucee development team was working on.
I’m happy that this sprint is public.

Were the others in the past too?

Thanks for your work guys! :sparkling_heart:

1 Like

We’ve been improving our processes!

Sprints are the way we run these days

Feedback or suggestions on sprints always welcome

2 Likes

5 posts were split to a new topic: Errors upgrading to 5.3.9

Currently, we have one outstanding regression for 5.3.9

https://luceeserver.atlassian.net/issues/?jql=labels%20%3D%20"reg539"

Please try out the latest snapshot 5.3.9.140 and let us know if there are any others we’ve missed

1 Like

Now up to four, including logs going missing, again :frowning:

nah, there’s only one outstanding, the two are in QA, one is already marked deployed and the last one is currently being solved, aka in development

1 Like

RE: Logs - I believe that fix was applied to 5.3.9.137-SNAPSHOT … we’re deploying 5.3.9.140-SNAPSHOT to our dev/test environments today to shake any other issues loose. :crossed_fingers: nothing comes up.

1 Like

the 5.3.9.140-SNAPSHOT is up on docker hub for testing too

https://hub.docker.com/r/lucee/lucee/tags

I think I’ve solved the the last step with automating this whole triggering docker builds process, so hopefully we will have docker images for every SNAPSHOT for now on

5 Likes

If Lucee starts pushing it’s Docker images in automated fashion, that means we can too, at least for our Desktop day-to-day images.

Currently feeling like I just bought a $3K paper-weight (Apple M1 MBP). Feeling so out-of-my-depth since I know very little about architectures and platforms. When you say that this version is M1 compatible, does that mean that the nginx and JDK that come in some of the builds are also M1 compatible? I’m hoping that upgrading locally - even if I’m running an older version in prod - would at least make local-development possible.

you mean the docker builds? pretty sure they are all intel ATM

Ah, ok :confused: I saw an older post about running the build locally in order to create a ARM version for Apple M1. When I have some more time (and confidence), I’ll take a look at that.

Apparently it should Just Work to run Intel Docker images on an ARM Mac : Run x86 (Intel) and ARM based images on Apple Silicon (M1) Macs? - Docker Desktop for Mac - Docker Community Forums

We never got Tomcat to start correctly though. We don’t have any ARM Macs anymore. It’ll be an issue at some point in future though.

Yeah, I used the platform flag to get MySQL to run. Then, I had to locally-build images for some Liquibase / Exodus services (database migrations) to run. I tried building my ColdFusion image (based on Lucee), which takes like 20-minutes :scream: , but it’s very spotty and much of the time won’t even start up. Maybe I’ll try using the platform flag and then using the old image.

A little late for all that :laughing: but also :sob:

Bah…

*NIX, a Hypervisor of your choice… then run what you like.

Ben, I have been building my own images (and you can too!) , if they are built on your machine as long as all the supporting software is arm compatible (such as the JVM) you are good to go.
I have an upcoming blog post about this as we went through the multi platform image issues at work too.

(and for the haters, I love my M1s, work a treat and have great power/battery life for my uses)

3 Likes