On ColdFusion, Railo and Lucee 4.5, one had a WEB-INF/classes dir, into which one could put individual Java class files which the CFML engine would then pick up for `createObject("java")` calls.
This appears to be missing on Lucee 5.
According to some Tomcat docs I read, I should simply be able to create the dir and use it as per usual (ie: Lucee should know to look there if the dir exists), but this does not work either.
I also looked to see if it was a matter of adjusting Lucee's classpath to also include that dir now that I had created it, but could not see where to do that via the admin UI. I also checked startup.bat (I'm just using the express install), but could see no suitable classpath option there. I will admit to being a bit of a dunderhead when it comes to this level of config, and in lieu of there not being any docs for it, I get lost / frustrated quickly.
Things might work differently in Lucee 5, but if so: you need to document it accordingly (could not find said docs, if they exist, I only googled).
Just in case anyone else stumbles in here.
If you put your class files in the root lib folder tomcat/catalina will pick em up. Weird that a .class file in the jar folder works, but I think thats just how classpath works. Not a great place for them, but it does the trick. If you get Lucee express that will be besides catalina.jar and where the ext folder that has lucee.jar. I didn't try but I suspect you could modify setclasspath.sh to append on a custom path to the global tomcat path. A JAR file is still probably the best approach, but we are in situation where we don't control the .java as silly as that is. I'd also recommend using a java classloader anyways so you can source control this stuff and not put it on the devops side of things. Of course I'm not doing that for everything, but I do say load my POI.jar files that way. I think Lucee's even supports this directly in the createobject call now a days.
I have just been bitten by this. Code that used to work in lucee 4x now fails in 5x. The workaround above has helped but we had code such as:
Which is basically instantiating /lib/BCrypt.class and how we have had to remove that from the source controlled folder and tie it to the server instance, update our build files, ask dev-ops to change their procedure and then deploy that.
Whether that is a bug or not, it has been supported in previous versions as well as other engines and sudden deprecations should be tested for. I suggest https://luceeserver.atlassian.net/browse/LDEV-290 be updated with .class tests.
OK, looking into this more, this is supported and documented when doing getFunctionData("createObject") in Lucee 4.5.5+006
java: classpath used to load the defined class, this can be a list of multiple paths (directories containing class files or jar files)
in Lucee 5.2.2+71 it expressly says it supports it, ergo this is a bug:
java: "classpath" or "bundleName" used to load the defined class, this can be a list of multiple paths (directories containing class files or jar files) as string list or array or a name of an OSGi bundle (Lucee can download OSGi bundles automatically if necessary)
Right, so looking forward to the next lot of 'splaining now, . Don't let us down...
Since the issue I discovered isn't actually this issue (WEB-INF/classes folder) I have created a new ticket