Loader change in Lucee 6?

As you know you can update Lucee and it’s extension in your Lucee administrator without the need to restart the Servlet Engine.
For this to work Lucee comes in 2 parts, the loader and the core.

The loaders job is to load/unload/manage the core, extensions and provide interfaces for core external code like extensions or the Lucee loader to interact with the Lucee core.
The Lucee core on the other side contains all the working code. Every extension can define a minimal core and loader version it needs to work (but no maximal).

Of course we try to keep changes to the loader to an absolute minimum, so users can update in the Lucee admin or by adding the Lucee .lco file to the deploy folder and extension developer (us included) not to have to update their extension all the time to match the changing interface of the Lucee loader. If we do, we only do between major releases. Sure adding stuff is much less of a problem than modifying existing stuff, but still every change comes with a risk.

Long story short, we will soon release the first BETA of Lucee 6 and so far we have made no changes to the Lucee loader, because we could avoid it. But maybe YOU wanna see a change in the loader? If so, please let’s discuss and PLEASE create/point to a ticket that describes the change you wish/need.

Personally, I’m a hard no on changing the loader for 6.0

Let’s do it properly for 7.0 and not rush it into 6.0 and delay / further complicate everything

1 Like

I wanted to make changes to improve the Cache interface all the way back in Railo 4! I was told I’d need to wait until Railo/Lucee 5 to change the loader. Lucee 5 came and went without any changes and I was then told I’d need to wait until Lucee 6 to make these changes. Now, before Lucee 6 is even released, we’re saying let’s hold off until Lucee 7!! Lucee 7 is what-- 3 to 4 years away? I can even describe how frustrating this is. Let’s just get rid of the loader if this is how we’re going to treat it. It doesn’t even matter in CommandBox since we ship the loader with each CF engine anyway, yet I’ve waited 10 years for some of these changes to get made.

Things I’ve wanted to change over the years include:

  • Cache interfaces (Most of these discussions are probably sadly lost in the Railo ticket tracker which has now been deleted by JBoss)
  • Registering servlet context listeners via annotations
  • Modifying interfaces like Query to bring them inline with all the new methods in QueryImpl, which I ran into a lot when doing the QoQ changes.
  • At some point Lucee is also going to have to decide when and how to cut over to the new Jakarta EE package namespaces as well which used to be Java EE (the actual servlet spec) and I’m pretty certain this affects the load and core.

I’m sorry this ticket got lost but back then we informed that if you care about a ticket, you have to migrate it yourself. Let’s focus on what we can do now and not what did go wrong in the past, i can not change the past only the future.

Cache interface
We already added a new optional interface “lucee.commons.io.cache.CachePro” some time ago that implements “Cache” and comes with additional methods. The reason for this is backward compatibility. A Cache can implement just the Cache interface or the CachePro. I would like to keep that approach, so we add a new interface, but keep the old, that way we do not have to rewrite all the caches at once. Let’s start a ticket for this with the details.

Registering servlet context listeners via annotations
Also here can you create a ticket with more details, specially how that then get used and exposed to cfml and extensions.

Modifying interfaces like Query
Also here, can you make a ticket for every data type (Query,Array, Struct,…) and what methods exactly you wanna see exposed. To be honest i’m critical about that, i would like to see at least 30% of the methods of this interfaces marked as deprecated, but there are for sure some helpful methods we could make available.

Jakarta EE package
If you wanna do a ticket for this to keep it on the radar, that would be great.

I’m all for Lucee 7.0 updating the loader to support Jakarta EE package as Undertow v3 and Tomcat v10 use it [LDEV-3995] - Lucee

Honestly, I don’t think we can wait for Lucee 7. We’re about to get left behind very quickly by all the major servlet containers if we don’t convert. Either that, or we need to look into some of the tools out there that do bytecode manipulation to allow an older app to run on the new servlets. I spoke with an Eclipse rep at Devnexus about this, but I can guarantee none of those tools have been tested on CF engines. It’s on my list of things to play around with, but I honestly have no idea how I’ll make CommandBox work once the CF engines start cutting over since it seems you pretty much have to choose one or the other. It’s frankly quite a mess and all boils down to a stupid trademark issue for “Java EE” :confused:

I have added some possible ptocess in how we approach jakarta.ee update in the ticket
https://luceeserver.atlassian.net/browse/LDEV-3995
My solution even comes with the possibility that user not have to update the lucee.jar at all as long they do not use a newer servlet engine version, this is my perverted solution.

@Zackster @bdw429s could you please create tickets for interfaces you want to be modified.

1 Like

I have created a ticket [LDEV-4003] - Lucee for an extension of the Resource interface (virtual file system) to improve performance. This interface is optional and not necessarily has to be implemented by every virtual file system implementation.