Version numbers of libraries underlying ColdFusion 2021
Note: This blog post is from 2021. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Are you wondering what updates have been made (in terms of version numbers) to the libraries underlying CF2021? For instance, what's the version of ehcache? What about Java, Tomcat, Hibernate, Quartz, jQuery, and so on?
In this post, I offer a rundown of what seem the most significant libraries and their versions, as deployed in the first release of ColdFusion (2021 Release).
[Update: I have started updating this post to identify the versions as of update 4, released in May 2022. Rather than wait until I have found ALL the new values, I will just update the list below, clarifying when I have noted the updated value.]
This is something I have been doing in my "hidden gems" talks for the past several releases. I also explain here how I find these version numbers, which isn't always obvious, in case that may help anyone (and also because some libraries may change with future updates to CF2021). I also offer some commentary on why this matter of library versions is important to some, as well as some counterpoints to the demands some have that every library should always be the absolute latest version (and why that's just not practicable).
If you just want the version numbers without the "waffle", look for the bulleted list of them below. :-)
Question - is there a recommended way for using newer versions of libraries with ColdFusion?
For example, if I'm running CF2021, but want to tap into the latest version of Antisamy (https://github.com/n... - 1.6.4), can I do that? If I drop the jars into my this.javasettings, am I still going to end up with the default versions? Any workarounds other than Mark Mandels Javaloader? (https://github.com/m...)
1) I don't have specific experience with changing the antisamy version within CF, but I will say that it's generally an "unknown" to try to change any library within CF that it (the CFML engine) uses. Such changes are generally undocumented, unsupported, and so I'd argue mostly unwise. Still, I appreciate that some will be desperate enough to "try anything".
2) To your question, yes, one can point to a new library (for the life of a request) using this.javasettings (without need to use javaloader, which the CF setting basically has obviated). Both of those are favored over the older approach of dropping a jar into CF's lib, which would instead affect ALL CF processing.
By the same token, in the case of something like anti-samy which IS called by CF internals (and not just your code), it's unclear what the impact will be when such a new version is loaded by either that setting or javaloader.
I'm not positive whether the internal calls CF makes to such libraries (that it relies on) would or would not find the one YOU point to. CF may use some internal specification for such things. That's why I say that changing such things is an unknown. It may "work", but just be careful.
3) Finally, I'd propose instead that anyone wanting CF to have a later version of something should open a ticket with Adobe (at tracker.adobe.com) making the case for the request. Sometimes they have updated libraries in a CF update, while other times they waited until the next major version. The question most likely comes down to whether updating such a library could have any negative impact, perhaps breaking existing code. (Consider again my concern of how trying to modify it on the fly in a request may seem to work in some cases but may prove to cause trouble later.)
Anyway, you have lots of options now. Let us know if you try something, and how it goes. :-) Or perhaps someone else will chime in with more specific experience.
Also, this is all just for reference; I'm not recommending anything here - just trying to understand.
I did some testing with CF 2021, and it appears that if I load the newer version of Antisamy using this.javasettings, I'm able to use it - that is, I get access to the updated library if I create instances of 'org.owasp.validator.html.AntiSamy'.
Furthermore, it appears that the Antisamy related functions, like GetSafeHTML are NOT impacted by the change. They appear to behave the same as before. Adobe must have some internal approach for separating the libraries.
We just installed CF2021 and our SOLR version was 7 out of the box. Does that seem right?
I was looking at the solr jar in CF--which I guess may be a "client" jar, for talking to the Solr that CF implements in the "add on service". But the Solr jar in that add on service (in my case, in cfusion\jetty\work\jetty-0_0_0_0-8993-solr_war-_solr-any-\webapp\WEB-INF\lib\) is indeed 7.2.1--both before and after the Sept update 2 which offered a new installer.
I have updated my bullet point about for Solr to clarify that.
Again, thanks for bringing this to my attention.