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.
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.
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”
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.
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.
YES, let’s focus on changing the future, i.e. the Lucee loader coming in Lucee 6.
Honestly, I can’t believe we’re arguing that Lucee 6, Lucee’s only major release in almost a decade AND a release containing breaking changes, should NOT contain changes to the loader. This is the PERFECT time to make changes to the Lucee loader. Since Lucee 6 already contains breaking changes, there will be no one-click upgrade anyway.
Perfect - sounds like a good time to update it, then!
As far as tickets, or what I’d like to see change in the loader:
I count 10 // FUTURE comments in the Hibernate extension alone, which means 10 places we’re using Java reflection instead of the proper interface. But especially, see Lucee’s DatasourceManagerImpl.savepoint( String savepointname ) method, which is not defined in the interface and thus cannot be used from the Hibernate extension.
Also, don’t act like we have to create a ticket when there’s already 1) known issues with the loader, and 2) a known method of marking them as to-be-implemented. i.e., if you NEEDED a ticket for each loader change, you would have made those tickets instead of scattering // FUTURE comments about the codebase.
I think we need to draw a line under Lucee 6 changes and get what we have fully baked and out. The issue is there is always going to be more stuff to put into 6 but then we also have 5.3.x and 5.4.x. I for one would love to see this out and in the wild well in advance of CFCAMP. We can’t on the one hand point at the time taken and then ask for more changes.
If we can get 6 out, making it so its not a massive deal for people to move from 5.x based and prior versions . Stop worrying about 5.x based changes ongoing and then focus on a 7 release that would be infinitely preferable imho
There is a very small subset of people I would suggest that care about this loader related issues, thats not to trivialise the importance of it but we at some point should be catering to the 90% not the 10%
