I am in the process of migrating a Lucee 4 setup, which is managed by Puppet, to Lucee 5. This is using the JARs distribution. There are a few things that don’t quite make sense so I am hoping that someone can shed some light…
On first boot with no existing files whatsoever, Lucee unpacks itself from lucee.jar and installs the default set of extensions. It seems to update lucee-server.xml to reflect the set of extensions that were installed. So far so good.
In order to deploy additional extensions in a predictable fashion (i.e. with no unpredictable delays due to directory watching), I am trying to make use of the lucee-extensions system property. This seemed to be working well, but in the situation where I had to upgrade an existing extension, I noticed something… It seems that Lucee will start up any existing web application contexts and then react to a version change in the lucee-extensions system property. That means that the newly started runtime environment is still using the previous version of the extension. This requires a) awareness of this issue and b) an additional server restart to fully effect the extension upgrade.
Given an existing lucee-server.xml but no other files, lucee.jar seems to unpack most things as expected. However, when it tries to install the default set of extensions, it seems to forget that they are provided in lucee.jar and instead tries to download them all over the Internet. Is this expected behaviour? I am considering preemptively unzipping the default extensions to lucee-server/context/extensions/available/ as a work-around.
A couple of unnecessary resource declarations in our customised lucee-server.xml were triggering a chain of OSGI dependency downloads. Removing those has fixed it.
Point 2) is still an issue and in fact worse than I thought. A newly installed extension (no previous existing version) won’t be loaded until the server has been restarted for a second time. It seems that the lucee-extensions system property is only copying the extension files into place and updating lucee-server.xml There is nothing to cause the server to actually load the extension.
In order to deploy additional extensions in a predictable fashion (i.e. with no unpredictable delays due to directory watching), I am trying to make use of the lucee-extensions system property. This seemed to be working well, but in the situation where I had to upgrade an existing extension, I noticed something… It seems that Lucee will start up any existing web application contexts and then react to a version change in the lucee-extensions system property. That means that the newly started runtime environment is still using the previous version of the extension. This requires a) awareness of this issue and b) an additional server restart to fully effect the extension upgrade.
I’m trying to upgrade the version via system property, After restart lucee server once, I’m seeing upgrade version on all my web context. There is no need to restart web context or lucee once again.
Point 2) is still an issue and in fact worse than I thought. A newly installed extension (no previous existing version) won’t be loaded until the server has been restarted for a second time. It seems that the lucee-extensions system property is only copying the extension files into place and updating lucee-server.xml There is nothing to cause the server to actually load the extension.
I’ve checked with new extension (not installed yet) in the system property, It’s load properly once you restart lucee server at once.
NOTE: I’ve checked in lucee 5.2.1.9 installed version
Can you provide following details
In which extension you facing this issue?
In which lucee version you found the issue?
To be clear, I am not saying that extension upgrades via the system property are ignored entirely. On the first restart after a system property change, the Lucee configuration .xml is updated to reference the new extension version. However, this doesn’t mean that the runtime environment is using the new version. I’m finding that I have to restart a second time to cause the newly modified .xml to be read and the new extension version to be loaded.
Add the system property for extension and restart server, server loads the extension & It’s working fine at all web context. If we update the extension mannualy, Update version added into lucee-server.xml & updated version working on all web context. If we restart server again, it couldn’t able to load the update extension, server loads older version of extension which is in the system property.
@mark.summers, Can you confirmed that this the issue?
Configure the lucee-extensions system property to include an extension. Ensure that the .lex file is present in extensions/available. Ensure that the extension is removed from extensions/installed and that the .jar files for the extension are not present in bundles.
Start Lucee and lucee-server.xml is updated to include the new extension. The extension appears in extensions/installed (albeit renamed) and the .jar files are unpacked into bundles. The server appears to start correctly. Emphasis on “appears” here.
At this point, I am able to prove that the extension is not really being started, even when some page requests were received, because certain log messages are absent from catalina.out
Restart Tomcat
Now, the server behaves as expected, with log messages from the extension present in catalina.out
I think that the problem with upgrading extensions is simply a different manifestation of the issue already described: The new version is being installed but not loaded until the second restart.
I have seen that MS SQL JDBC was not upgraded to the version specified in the system property on the first restart. However, to be absolutely convinced of the issue (via log messages) you would require a custom caching extension and supporting infrastructure (an Apache Ignite cluster).
Extension working after the second restart?
Yes, because the lucee-server.xml modified during the previous startup is now seen.
I am unable to reproduce the issue with MS SQL JDBC but the caching issue is still present. I would like to focus on that…
In lucee-server.xml define a cache requiring an extension
Make the cache in 1) the default for e.g. object caching
Ensure that the required cache extension is NOT installed (but should be available)
Include the required cache extension and version in the extensions system property
Start Lucee
lucee-server.xml is updated to reflect the installation of the cache extension. However, the custom cache is not started. Instead, Lucee continues to use the default in-memory caching.
Restart Lucee
Now, the custom cache is started and used.
NB: I suspect that this test will only work with cache extensions not included in the Lucee JARs distribution.
The issue is reproducible with Lucee 5.2.2.71 My cache extension is being installed but Lucee continues to use in-memory caching until the next restart.
Also, I think there is something wrong with the order of events during startup. Lucee tries to download all extensions from release.lucee.org, even if they are mentioned in the system property…
2017-08-18 10:24:16.820 extensions to install defined in env variable or system property:99A4EF8D-F2FD-40C8-8FB8C2E67A4EEEB6;version=6.2.0,16FF9B13-C595-4FA7-B87DED467B7E61A0;version=2.0.0.1
I’ve not dug into it to the same extent, but I’ve seen some similar issues where even “core” extensions fail to work on a brand new installation/first start without a restart in place. I could reproduce this very well in the ColdBox Travis CI build. When the server very first starts up (via CommandBox) Hibernate is not correctly loaded and there are errors. If you stop and start again, the tests all pass fine. I have a feeling this may be related to some of the issues Mark has experienced.
That doesn’t really apply here. That URL var was specific to the web admin for Lucee and caused admin plugins to reload. In this case, we’re (or at least I’m) talking about an extension being loaded to the point where just regular CFML code can use it from inside your app.