5.3.9.129 Release Candidate 4 (last before stable on Monday)

news release
1

This is the last 5.3.9 RC, before stable on Monday.

Amongst other things, it addresses the issue which affected commandbox, i.e. the log4j console warnings , hope this makes @Brad_Wood happy!

I’ll be update this post with the changelog soon, just preparing them, it does take a while

LDEV-3891 Lucee’s custom Log4j OSGI bundles are missing important metadata from the originals
LDEV-3940 REGRESSION - 5.3.9 is now spilling JSR-223 exceptions to the console
LDEV-3927 cookies set via cfheader are ignored
LDEV-3924 lucee.runtime.exp.DatabaseException: No operations allowed after statement closed.
LDEV-3923 start event gateway after startup
LDEV-3462 during shut down, stopped event gateways are restarted
LDEV-3922 Server Admin Settings - Logging page throws NPE for datasource appender
LDEV-3911 5.3.9 regression, cookie encoding/decoding problems
LDEV-3761 _internalRequest() doesn’t work with cfcontent
LDEV-3939 Application list in server admin dumps stack trace out to console each page load

Code changes

2 Likes
2
3

Getting a lot of this in the logs when I go to the admin:

[INFO ] runwar.context: ERROR: Failed to download the bundle for [lucee.image.extension] in version [1.0.0.42] from [http://release.lucee.org/rest/update/provider/download/lucee.image.extension/1.0.0.42/?webId=b6b7eb990de243ee24004b011d675ee4&webSecurityKey=e707d92a-f22d-4e25-851a-c0c4a1a192ae&serverId=9bb50b27bcb17bdec17bda7714ff3cb3&serverSecurityKey=fbf88532-a5e7-495b-8e29-37c613eae447&allowRedirect=true&jv=11.0.14], please download manually and copy to [/usr/local/lib/serverHome/WEB-INF/lucee-server/bundles]

We don’t have anything specifying that version of the image but the Lucee extension provider is saying that it exists. Not sure why Lucee is trying to grab it though as we are using the 1.1.0.6-SNAPSHOT that is newer.

4

The Lucee core manifest is requiring this version of the image extension Lucee/MANIFEST.MF at 5.3 · lucee/Lucee · GitHub Which shows up on the download page with a release date of today
Download Lucee
However, the error message specifically is for downloading the OSGI bundle, not the extension and I’m not clear where I can go to see what versions of bundles are available. I think those pull from Maven.
Of course, the fact that Lucee is trying to download anything at all is troublesome as Lucee is supposed to come with everything it needs baked in.

When I hit https://release.lucee.org/rest/update/provider/download/lucee.image.extension/latest I get version 1.1.0.3-SNAPSHOT of the OSGI jar.

It would seem that there are some wires crossed between the extension version and the OSGI bundle version that the extension uses. I can’t figure out how/where the extension specifies the bundle version for it’s main jar other than here extension-image/build.properties at master · lucee/extension-image · GitHub which is a completely different version number.

And to make things even more confusing, the lex file inside the Lucee jar contains a ./jars/lucee.image.extension-1.0.0.42.jar file (which came from who knows where) which was copied to by bundles folder when Lucee started. So I really don’t understand why Lucee would be trying to download it anyway.

5

I did a quick test with LUCEE_ENABLE_BUNDLE_DOWNLOAD set to false and I get the following errors in my console:

[INFO ] 22.04.2022 16:07:05,480 ERROR [server.application] OSGi->Lucee is missing the Bundle jar, org.lucee.commons.logging:1.2.0, and has been prevented from downloading it. If this jar is not a core jar, it will need to be manually downloaded and placed in the {{lucee-server}}/context/bundles directory.

[INFO ] 22.04.2022 16:07:05,507 ERROR [server.application] OSGi->The OSGi Bundle with name [org.lucee.commons.logging] is not available in version [1.2.0] locally (D:\.Command Box\server\5DFAEA950B8E8D28B92DB9FA2667057F-5.3.9-bundle-download-test\lucee-5.3.9.129-SNAPSHOT\WEB-INF\lucee-server\bundles) or from the update provider (http://release.lucee.org), the following versions are available locally [1.2.0.0000L, 1.2.0.0000L].

That second one is a real gem since it tells me 1.2.0 is not available locally, only to turn around and tell me 1.2.0 IS available locally, not once but twice! :laughing:

My deploy log is also chock full of errors like this. Why are these even errors, or being logged at all?

"ERROR","main","04/22/2022","16:07:07","Extension","the extension MySQL (id: 7E673D15-D87C-41A6-8B5F1956528C605F) in version 8.0.19 is already installed;lucee.runtime.exp.ApplicationException: the extension MySQL (id: 7E673D15-D87C-41A6-8B5F1956528C605F) in version 8.0.19 is already installed
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(XMLConfigAdmin.java:4699)
	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(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	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.LuceeServlet.init(LuceeServlet.java:42)
      ...

I also see a handful of these errors in my deploy log

"ERROR","main","04/22/2022","16:07:07","Extension","D:\.Command Box\server\5DFAEA950B8E8D28B92DB9FA2667057F-5.3.9-bundle-download-test\lucee-5.3.9.129-SNAPSHOT\WEB-INF\lucee-server\context\extensions\installed\1apdrbs8iaisw.lex (Access is denied);lucee.runtime.exp.NativeException: D:\.Command Box\server\5DFAEA950B8E8D28B92DB9FA2667057F-5.3.9-bundle-download-test\lucee-5.3.9.129-SNAPSHOT\WEB-INF\lucee-server\context\extensions\installed\1apdrbs8iaisw.lex (Access is denied)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(Unknown Source)
	at java.base/java.io.FileOutputStream.<init>(Unknown Source)
	at lucee.commons.io.res.type.file.FileResource.getOutputStream(FileResource.java:264)
	at lucee.commons.io.res.type.file.FileResource.copyTo(FileResource.java:116)
	at lucee.commons.io.IOUtil.copy(IOUtil.java:140)
	at lucee.commons.io.res.util.ResourceUtil.moveTo(ResourceUtil.java:1120)
	at lucee.runtime.extension.RHExtension.move(RHExtension.java:251)
	at lucee.runtime.extension.RHExtension.init(RHExtension.java:238)
	at lucee.runtime.extension.RHExtension.<init>(RHExtension.java:224)
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(XMLConfigAdmin.java:4684)
	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(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	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.LuceeServlet.init(LuceeServlet.java:42)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:309)
	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:588)
	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:559)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:601)
	at runwar.Server.createServletDeployment(Server.java:1314)
	at runwar.Server.startServer(Server.java:485)
	at runwar.Start.main(Start.java:50)
Caused by: java.io.FileNotFoundException: D:\.Command Box\server\5DFAEA950B8E8D28B92DB9FA2667057F-5.3.9-bundle-download-test\lucee-5.3.9.129-SNAPSHOT\WEB-INF\lucee-server\context\extensions\installed\1apdrbs8iaisw.lex (Access is denied)
	... 37 more

This was just a default server started up on CommandBox in Windows. I’ve made no changes or installed anything custom into it yet.

6

Could we get a Dockerized build ? It looks like there haven’t been any since 3 months ago.
This would let us plug the RC straight into our testing systems, as we’re using Docker all the way through the stages to live, and we are based off the official Lucee images.

I also echo what @bdw429s says - Lucee should work without doing any downloads beyond the initial install/image; we deploy Lucee in regulated environments, sometimes with no Internet access.

7

I believe @modius or @justincarter normally help kick off the Lucee docker images for snapshots. I’ll note if you’re using the Ortus CommandBox-based docker image you always have access to 100% of all Lucee versions ever produced as every snapshot is automatically published to ForgeBox within the day.

8

@bdw429s Version 1.2.0 and 1.2.0.0000L is NOT the same version.

9

According to how every other software I’ve ever used treats semantic versions, yes that should match. If 1.2.0 is treated correctly as a sem ver “range”, then it will de-sugar to 1.2.0.x where the x can match anything. This is how/why other package managers like npm or ForgeBox, let you do:

install coldbox@6
install coldbox@6.7
install coldbox@6.7.1
install coldbox@6.7.1+2

and all of those commands will match and install the version 6.7.1+2. This is how the world does versioning. So, 1.2.0 should in fact match 1.2.0.0000L in my opinion.

10

@bdw429s

In OSGi version number do not left room for interpretation, this version number are not the same and not even by accident, the “L” at the end stands for “Lucee”. For the Lucee team this is clear cut, we have version “1.2.0” of the axis lib with correction “0000L” of the Lucee team when we did convert it to a OSGi bundle.
For Felix (OSGi engine used by Lucee), this numbers are never the same and Felix would never load 1.2.0 when 1.2.0.0000L is defined (visa versa).

In this example you see an exception from the Lucee core, because Lucee is trying to resolve the issue, Felix did complain about. Felix cannot resolve and for example download missing jars, Felix need to be spoon feeded with bundles by Lucee.

But a good example is when Felix complains about “Uses constraint violation”, we saw for example with the S3 extension recently with exactly this bundles! one chain in the S3 extension jar did use “1.2.0.0000L” and the other “1.2.0” what caused OSGi to throw a “Uses constraint violation” exception.

I think your confusion comes from the possibility to define a version range, instead of a specific version.
Of course that is also possible in OSGi but that is a different syntax.
https://www.ibm.com/docs/en/rational-soft-arch/9.6.1?topic=SS8PJ7_9.6.1/com.ibm.aries.osgi.doc/topics/tversionsyntax.html
but that is a different story.

In this case the issue is with the axis jar that defines “org.lucee.commons.logging;bundle-version=1.2.0”, what then forces Felix to load this version, it cannot and that triggers Lucee to resolve that version what fails.

BTW also Maven contradict you, otherwise this would not be possible https://mvnrepository.com/artifact/org.lucee/axis

“According to how every other software I’ve ever used treats semantic versions, yes that should match.”
i saw my first Black Swan when i was 30 :wink:

11

If Lucee wants to have its own version of a bundle, shouldn’t it be using a separate bundle name? And if Lucee is using a separate bundle name, what is the utility of a custom “L” in the version when the bundle is already unique?

Umm, maven seems to be contradicting itself :wink:

image

12

I’m not really sure what you are saying, i think you confuse Maven and OSGi a little bit.
The original Maven groupid is “axis” and the artifactid is also “axis”. Our group id is “org.lucee” and the artifact we use is “axis”, so that of course differ, i cannot create versions for the group “axis” only the owner of this group can. See the maven groupid like a domain and the artifactid like a subdomain.

We do the bundle name “org.lucee.axis”, that way we have not to define a maven->osgi mapping.

Normally we use the original version number one to one with no appendix, but in that case we had to do some changes in the OSGi conversions process, like for example updating a required bundle or any other relation. otherwise that extension would use a different version of apache.commons.logging as for example S3 does, that works fine but of course is a waste of resources. Sure we could define a range in that case, but that has the risk that a never version no longer is compatible with axis. Axis for example uses a older version of the apache.httpcomponents than other extensions do.

That the “L” is once in the beginning and once in the end, is simply because we (Lucee) changed the pattern over time. That has nothing to do with Maven itself, Maven simply takes the version numbers as they are given, BUT maven never allows to update versions (only for SNAPSHOT that are of course not released), that clearly shows that this are also different version for Maven, another black swan :wink:

13

5.3.9.131-SNASHOT fixed these problems, stable release tomorrow

In the meantime, if anyone wants to try out the preview installers, that would be great!

see Preview 5.3.9.131-SNAPSHOT installers

2 Likes
14

Thanks for everyone’s hard work getting out this release! Please update the docker images when you get a chance as that’s the only way my workflow is setup to test and deploy.

2 Likes
15

Can we expect a release today (Apr 27, 2022)?

16

YES! Today we will release 5.3.9 stable

17

As just the installer ? Or with Docker and .jar versions as well ?

18

nah, just a screenshot of it running on my machine!

1 Like
19

actually, just dived into lucee docker land, it’s still done via travis and we have run out of credits since they got taken over by VCs, so we need to migrate the build process to github actions

@justincarter looks after this side of things and it’s after midnight down under, so the docker builds will take a bit longer, but they will happen (also snapshots)

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

20

Justin has only been here for 10mins in the last 2 months, unless the forum hover text is wrong, so hopefully he reads the ping from Jira :slight_smile: