http://coldfusion.com logo
Join Slack
Powered by
We’re running into the following issue with our ap...
# lucee
d
We’re running into the following issue with our application since attempting to upgrade from Lucee 5.3.10.120 to Lucee 5.4.3.2: 
cannot initialize ORM Engine [class:org.lucee.extension.orm.hibernate.HibernateORMEngine;name:hibernate.extension;version:3.5.5.61;], make sure you have added all the required jar files
Looking at https://luceeserver.atlassian.net/browse/LDEV-4609 we see hibernate extension has been removed from 5.4.1 onwards. We have tried to include the latest version of the ORM extension by setting environment variable(within our docker file): 
LUCEE_EXTENSIONS: "FAD1E8CB-4F45-4184-86359145767C29DE;name=Hibernate ORM Engine;version=3.5.5.89"
And also the specific version of the hibernate extension referred to in the error message: 
LUCEE_EXTENSIONS: "FAD1E8CB-4F45-4184-86359145767C29DE;name=Hibernate ORM Engine;version=3.5.5.61"
Neither of these make any difference to the error message displayed. Java Stack trace is as follows:
Copy code
lucee.runtime.exp.ApplicationException: cannot initialize ORM Engine [class:org.lucee.extension.orm.hibernate.HibernateORMEngine;name:hibernate.extension;version:3.5.5.61;], make sure you have added all the required jar files
  at lucee.runtime.config.ConfigImpl.getORMEngine(ConfigImpl.java:3171)
  at lucee.runtime.config.ConfigImpl.resetORMEngine(ConfigImpl.java:3142)
  at lucee.runtime.orm.ORMUtil.resetEngine(ORMUtil.java:74)
  at lucee.runtime.listener.ModernAppListener.initApplicationContext(ModernAppListener.java:474)
  at lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:118)
  at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:44)
  at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2493)
  at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2478)
  at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2449)
  at lucee.runtime.engine.Request.exe(Request.java:45)
  at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1216)
  at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1162)
  at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:97)
  at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
  at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
  at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
  at org.cfmlprojects.regexpathinfofilter.RegexPathInfoFilter.doFilter(RegexPathInfoFilter.java:47)
  at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:67)
  at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
  at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
  at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
  at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
  at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
  at runwar.undertow.SSLClientCertHeaderHandler.handleRequest(SSLClientCertHeaderHandler.java:144)
  at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
  at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:257)
  at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:182)
  at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:188)
  at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:136)
  at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:99)
  at org.cfmlprojects.regexpathinfofilter.RegexPathInfoFilter.doFilter(RegexPathInfoFilter.java:45)
  at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:67)
  at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
  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 com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:134)
  at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doNext(FusionReactorRequestHandler.java:772)
  at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doHttpServletRequest(FusionReactorRequestHandler.java:344)
  at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doFusionRequest(FusionReactorRequestHandler.java:207)
  at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.handle(FusionReactorRequestHandler.java:809)
  at com.intergral.fusionreactor.j2ee.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:36)
  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 com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:71)
  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 com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilter(FusionReactorStaticFilter.java:54)
  at com.intergral.fusionreactor.agent.pointcuts.NewFilterChainPointCut$1.invoke(NewFilterChainPointCut.java:42)
  at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java)
  at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
  at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
  at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
  at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
  at runwar.undertow.SSLClientCertHeaderHandler.handleRequest(SSLClientCertHeaderHandler.java:144)
  at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
  at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)
  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
  at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
  at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:275)
  at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:79)
  at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:134)
  at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:131)
  at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
  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.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
  at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:79)
  at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:100)
  at io.undertow.server.Connectors.executeRootHandler(Connectors.java:393)
  at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:852)
  at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
  at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2019)
  at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558)
  at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1449)
  at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1282)
  at java.base/java.lang.Thread.run(Unknown Source)
 Caused by: java.lang.NoClassDefFoundError: org/apache/xml/serializer/TreeWalker
  at org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:818)
  at org.lucee.xml.XMLUtility.writeTo(XMLUtility.java:544)
  at org.lucee.xml.XMLUtility.toString(XMLUtility.java:576)
  at org.lucee.extension.orm.hibernate.HibernateORMEngine.createMapping(HibernateORMEngine.java:336)
  at org.lucee.extension.orm.hibernate.HibernateORMEngine.getSessionFactoryData(HibernateORMEngine.java:145)
  at org.lucee.extension.orm.hibernate.HibernateORMEngine.init(HibernateORMEngine.java:67)
  at lucee.runtime.config.ConfigImpl.getORMEngine(ConfigImpl.java:3158)
  ... 92 more
 Caused by: java.lang.ClassNotFoundException: org.apache.xml.serializer.TreeWalker not found by org.lucee.xalan [67]
  at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1591)
  at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
  at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1976)
  at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
  ... 99 more
Is anyone able to advise why setting the 
LUCEE_EXTENSIONS
env var as per the above did not cause the extension to be installed on startup (or if it did, why we are still getting the error)? We have no specific references to hibernate, or to a particular version of hibernate anywhere within our application or configuration - although our application does use ORM. Can anyone advise where the specific (and quite old) version of the hibernate is being referred to in the error message. Is there any way of locating where within our CFML code this exception is being triggered? We only see the java stack trace, and no reference to any CFML triggering code. Java stack trace is also truncated (potentially why we can’t see CF triggering location) - is there any way of getting the full stack track rather than the truncated version?
b
Java stack trace is also truncated (potentially why we can’t see CF triggering location) - is there any way of getting the full stack track rather than the truncated version?
This isn't actually true. The removed portions of the stack are redundant (overlap) with the outermost cause
Have you tried the Ortus ORM extension?
The root cause is
Copy code
ClassNotFoundException: org.apache.xml.serializer.TreeWalker not found by org.lucee.xalan
which would seem a bundle is missing-- perhaps not available any longer in the latest version of Lucee? Not sure.
Note, the Ortus ORM extension is also an upgrade to a much newer version of Hibernate so it requires its own testing for compat there.
d
This isn’t actually true. The removed portions of the stack are redundant (overlap) with the outermost cause
Ah ok - although that still does not allow us to see fully where in our application this is being triggered from (we have 2 different installations of the same software stack, and one (the simpler one) does not generate this error following updating Lucee - and the 2nd, does… Knowing what is triggering would potentially allow us to mitigate the issue.
b
I'm not sure what information you're looking for, but it's not going to be in any stack trace 🙂
The full stack is available to you starting with 
Thread.run()
If you're wanting other ancillary information such as, what site was being hit-- you'd need to get that elsewhere.
But the stack trace isn't withholding any info from you at this point
If you're asking what the server was doing-- it was starting the application, and initializing ORM. It hadn't made it to any CF code yet.
d
gotcha
b
Copy code
at lucee.runtime.orm.ORMUtil.resetEngine(ORMUtil.java:74)
  at lucee.runtime.listener.ModernAppListener.initApplicationContext(ModernAppListener.java:474)
d
Be handy for us to understand - why, in 2 very similar applications, one is erroring, and the other isn’t. Both apps using same versions of Java / Lucee Both apps with same core software stack pulled in build from same repo As such, must be something App specific which we are doing which is causing ORM to be initialised in one and not the other app… Anyway - that’s probably not the right way of going about it anyway… more just trying to get an understanding of what on earth is going on
b
There's a lot of things I'd like to understand, like the chronology protection conjecture in quantum physics, and why toast always lands butter side down. I'm probably as close to understanding those as anyone is figuring out why Lucee OSGI does wierd things 🤷
☝️ 1
😂 2
d
I’m also confused as to if Hibernate is still bundled with Lucee. From the linked Jira ticket, it looked as if hibernate had been removed from standard package from 5.4.1 - and yet, as you pointed out, error is triggered from within Hibernate extension due to what appears to be a missing dependency - and not as I erroneously thought it was saying, not being able to find the hibernate extension itself Not understanding how ORM is being referenced, makes it hard for me to understand how to tell the application to use a different version of the extension. Me specifying latest version of same extension (3.5.5.89) did not change the error message at all (still referring to 3.5.5.61 from eons ago) Happy to look at the Ortus extension… although with my current depth of non-understanding I’ve no confidence that somehow automagically this will be referenced, rather than the prehistoric version of the extension which I thought had been removed but somehow still seems to be there… Is this completely code compatible with “standard” ORM, or would this potentially require changes to application code…?
b
I'm not quite sure what you're asking
In Lucee 5.4, the hibernate extension is no longer bundled
That said, Lucee "knows" about ORM to the point where if you call 
entityLoad()
, it won't say "I've never heard of such a function with that name", it will say, "Hey you're trying to use ORM, but there isn't an ORM extension installed"
As far as what exact steps you've taken and what exact errors you received along the way, I have no earthly idea 🙂
In theory, you should be able to install the LAS ORM extension into Lucee 5.4 and it SHOULD work. That said, I have no idea how well they tested that so any number of issues may exist there, especially with all the library updates and removals that happened in Lucee 5.4 as well
It's entirely possible that an OSGI bundle that the hibernate extension requires is no longer in LUcee. Maybe the server that works was updated from an older version of Lucee so it has it. Perhaps Lucee magic auto-download of OSGI bundles worked on day but not the next.
I can think of many theories as to why it might not work, but none of the have a great way to test them
The Ortus ORM extension is a fork of Lucee's own updated Hibernate extension that they never really released.
I'd say 99% of it "just works", but @mborn can help answer any specific questions you may have about it. I largely suggested it because • it's the only LUcee ORM extension still under development • if there ARE issues with Lucee 5.4 using their own ORM extension, it's possible the Ortus one works. Just a total guess though
👍 1
d
…it will say, “Hey you’re trying to use ORM, but there isn’t an ORM extension installed”
But yet… prior to me adding the environment variables to reference the Hibernate extension… there was no reference to hibernate within our build. This is not an upgrade to an existing server. It’s a config based build… Using docker and commandbox… Actually.. hmmm…. The version of CB we are testing this on was one prior to CB releasing new version containing Lucee 5.4.3.2… 
FROM ortussolutions/commandbox:3.7.11
I am specifying 
ENV BOX_SERVER_APP_CFENGINE lucee@5.4.3+2
Before first load (before warmup-server is called) Is it possible that it’s somehow finding the version of the hibernate extension that shipped with the version of Lucee which shipped with that version of CB??? 🤔
b
Another thing at play here is when I upgraded the last version of CommandBox 5.9.1, which updated to Lucee 5.4.3.2, I manually installed the Ortus ORM extension into the CLI to prevent backwards compat issues with CommandBox users who may be hitting ORM and didn't want to break stuff in a patch update of CommandBox.
So it's POSSIBLE, your server start, if it matches the exact version of Lucee in the CLI is not downloading the CF engine, but borrowing the Lucee install from the CLI, which has Ortus ORM installed
You'd need to take a look to see if this is the case
Just a quick peek at the Lucee admin should answer that question
d
I can’t work out how to get into the lucee admin in 5.4 http://127.0.0.10:8888/lucee/admin/server.cfm gives ‘Not Found Error’
b
I assume you have CommandBox in secure profile
Look in the console output when the container starts and it will tell you 🙂
If will even say if the admin is locked down
d
yup
that is the case
Copy code
cnt-sb-cms-default.sb.local-1  |    |   |----------------------------------------------------------
cnt-sb-cms-default.sb.local-1  |    | √ | Setting Server Profile to [production]
cnt-sb-cms-default.sb.local-1  |    |   |-----------------------------------------------------
cnt-sb-cms-default.sb.local-1  |    |   | Profile set from secure by default
cnt-sb-cms-default.sb.local-1  |    |   | Block CF Admin external
cnt-sb-cms-default.sb.local-1  |    |   | Block Sensitive Paths enabled
cnt-sb-cms-default.sb.local-1  |    |   | Block Flash Remoting enabled
cnt-sb-cms-default.sb.local-1  |    |   | Directory Browsing disabled
cnt-sb-cms-default.sb.local-1  |    |   | File Caching enabled
Nice - hadn’t realised that was the case (we’ve had nginx proxy in front blocking any requests to admin by default for ages - before using CB even)
b
You can either turn off secure profile in Commandbox
Copy code
server set profile=development
or just enable the admin
Copy code
server web web.blockCFAdmin=false
d
• external - Only block access not coming from localhost. Technically, I am coming from localhost (accessing http://127.0.0.10) - but I presume docker may confuse matters somewhat here…
b
Yeah, if you're hitting it through docker, it's seen as an external request because it comes from outside the container
That 127.0.0.10 IP is presumably from your host OS and has nothing to do with what is happening inside the container
d
yup, thought as much
b
For all the container knows, all the requests coming into the container may as well be coming from China
The idea that the container itself is "local" to your machine is outside its purview
d
Yes - would be dangerous to assume otherwise
Hmm - well… hibernate extension is NOT (at least according to Lucee admin) installed…
which makes it somewhat strange that the non existant extension is raising an error…
b
Insert "I see dead people" meme from Sixth Sense...
d
🤣
Right… well.. I’m gonna start with updating my base base base image (don’t ask) to latest CB docker build 
ortussolutions/commandbox:3.7.12
which is using 
COMMANDBOX_VERSION=5.9.0
 and if my recollection late night scanning of twitter notifications is correct, Lucee 5.4.3.2…. Can’t hurt, and might help… And at least now I know how to get into Lucee admin, I can see what if any extensions are installed, and attempt to manually install either Ortus ORM plugin, or latest Lucee ORM plugin to see if we get any different behaviour…
actually - 5.9.0 is same as under 
ortussolutions/commandbox:3.7.11
m
@danlance A few clarifying things: • The extension is not installed because installation failed. • The installation failed because a dependency could not be found, like Brad mentioned. From your stack trace: 
org.apache.xml.serializer.TreeWalker not found by org.lucee.xalan [67]
• I can't think of any difference you would see between a manual install from the server admin, and an install via the env var. Except, of course, for the full stack trace error message you get in the server admin.
I would def. recommend switching to the Ortus ORM extension: • You should see significant improvements in the ORM startup and reload time, especially if you have a lot of entities. • You'll need to bump to 
5.4.29.28
at a minimum, since there is no 
3.5
version of the Ortus fork. • As far as required code changes, all your 
entityNew()
...
ormFlush()
, etc. should behave exactly the same... • but there is a ton of changes in Hibernate between Hibernate 3.5 and 5.4, so I wouldn't be too surprised if you need to tweak something somewhere. • Let us know if you run into any specific issues upgrading to the Ortus fork. We like bug trackers. 🙂
👍 2
And lastly, I wouldn't under any circumstance recommend the Lucee 5.4 beta extension. There were enough significant bugs in place to trigger us into forking the extension just to resolve them. 🙂
👍 2
b
which is using 
COMMANDBOX_VERSION=5.9.0
 and if my recollection late night scanning of twitter notifications is correct, Lucee 5.4.3.2….
@danlance No, like I said above in this thread, I didn't update to Lucee 5.4 until CommandBox 5.9.1 https://www.ortussolutions.com/blog/commandbox-591-released
CommandBox 5.9.0 was still on Lucee 5.3.10
d
@mborn
The extension is not installed because installation failed
That makes sense… but… what does not make sense is what is triggering the installation, if it’s not contained within Lucee standard package any more… and when we have not specific configuration requesting that the hibernate extension be installed (at least prior to my testing using env vars..)
m
Well, you have CFML code trying to do ORM-y stuff, right?
I believe Lucee will try to install an ORM engine on the fly if none is found. And there is still a hardcoded reference to the Lucee extension class name. So that would likely cause it... if I'm recalling correctly.
Oh, yes you probably have 
this.ormEnabled = true
in your 
Application.cfc
?
d
@bdw429s
CommandBox 5.9.0 was still on Lucee 5.3.10
Yep - I realise that… What I mistakenly assumed, was that when there was a bump in the 
ortussolutions/commandbox
version within a similar time frame to your announcement, that it would include CB 5.9.1 …which was a mistaken assumption on my part…
b
Well, Jon did make new container builds just a day or two after I released 5.9.1
So whatever the latest tags are, should all be on the latest CommandBox
We coordinate our releases
d
@mborn
Oh, yes you probably have 
this.ormEnabled = true
in your 
Application.cfc
?
Yes, that would be the case (although it is also the case in another build on same stack which is not erroring… go figure) Why they would have a hard coded reference to such an old version…makes little sense to me…
b
@jclausen?
j
v3.8.0 is the newest release, which is on CommandBox v5.9.1
🤦 1
👍 1
The changelog for that is here.
d
Sorry guys… being dopey there… saw 3.7.12 and assumed that was latest
j
No worries! 🙂
d
@bdw429s, @mborn Right - thanks both for all your advice - and thanks Brad for being my sounding board (again!) I’ve successfully managed to install Ortus ORM extension - and I am now not getting the error from the non existent legacy hibernate extension… I am getting a completely different error - but that’s from vendor code with a usable CFML stack trace… no Idea why when using same version of code in another context and it’s functionality which from my perspective should not being accessed at all… But heh - it’s progress, and gives me somewhere to start tomorrow (together with updating to latest CB) Going to call it there for tonight - getting late here in the UK. Thanks for all your help 👋
👍 2
2 Views
Open in Slack
PreviousNext
Powered by