http://coldfusion.com logo
Join Slack
Powered by
<@U071QGDLH> maybe one for you? I ran into an issu...
# docker-commandbox
d
@jclausen maybe one for you? I ran into an issue with the new commandbox docker builds, I'm using cfcompile.sh which seems to want TagLibraryInfo but since 3.12.0 it fails as the class isn't found. TagLibraryInfo was in runwar5.0.8.jar but looks like it has been removed in runwar5.1.1.jar - I assume this was intentional but any idea how I might work around that? Probably more of a commandbox question really thinking about it - @bdw429s?
j
Yeah, that’s probably a Brad question.
b
I've never heard of 
TagLibraryInfo
.
I didn't remove anything from the latest runwar, but it's possible it was a transient dependency dropped in one of our 3rd party library updates
You can see all our top level 3rd party libs we use here https://github.com/Ortus-Solutions/runwar/blob/develop/dependencies.gradle
You can use Git history to see what changed in there between Runwar 5.0.8 and 5.1.1
Is this the class in question?
Copy code
javax.servlet.jsp.tagext.TagLibraryInfo
it seems to be part of the actual servlet spec 🤔
j
If you give us the stack trace we might be able to pinpoint the issue.
b
That would come from this line
Copy code
compile group: 'jakarta.servlet.jsp', name: 'jakarta.servlet.jsp-api', version: '3.1.1'
If you're running Lucee 7, BoxLang, or ACF 2025, note that class is now in the jakarta namespace, so the old class name won't exist any longer
It would be 
jakarta.servlet.jsp.tagext.TagLibraryInfo
now, and you'd be using Runwar 6.x
I don't actually see any Git changes between the 5.0.8 commit and the 5.1.1 commit
Copy code
git diff eb13d48 0ed9713
in the 
dependencies.gradle
file
j
Yeah, if you look in the 
cfcompile.sh
script for ACF2025 you can see there is a commented out line for J2EE examples, and the log also echos out this:
Copy code
echo "Note: For EAR/WAR JEE deployments, you will need to modify cfcompile script to set the variable J2EEJAR to your application server's jar file paths (servlet/jsp/el api)."
echo "If you don't set, it you will get NoClassDefFoundError."
cfcompile.sh
cfcompile.sh
b
The OP didn't say anything about using cfcompile.sh, did he?
Or is there a side convo somewhere I missed?
j
I’m using cfcompile.sh which seems to want TagLibraryInfo but since 3.12.0 it fails as the class isn’t found
b
Oh, there it is lol
I'm blind
yeah, that makes sense if it's coming from there
I don't understand how this would have "worked" in older versions though and stopped working now
j
I’m not sure.
The earlier version only had one line that looked like this:
Copy code
J2EEJAR=$CFUSION_HOME/runtime/lib/servlet-api.jar:$CFUSION_HOME/runtime/lib/jsp-api.jar:$CFUSION_HOME/runtime/lib/el-api.jar
And none of those libraries were ever packaged in the war file.
b
Right, I'm not sure what $CFUSION_HOME even points to in that shell script, but I don't think that shell script would ever work out of the box on a WAR deployment
We'll wait for @dougcain to clarify exactly what he's doing, what worked before, and what's not working now.
d
I'm actually running cf2021 with a slightly modified cfcompile.sh to point to the appropriate jars in commandbox. The stacktrace I see is:
Copy code
java.lang.reflect.InvocationTargetException
        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 coldfusion.tools.CommandLineInvoker.main(CommandLineInvoker.java:112)
Caused by: java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagLibraryInfo
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
        at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.base/java.net.URLClassLoader.defineClass(Unknown Source)
        at java.base/java.net.URLClassLoader$1.run(Unknown Source)
        at java.base/java.net.URLClassLoader$1.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.net.URLClassLoader.findClass(Unknown Source)
        at coldfusion.bootstrap.BootstrapClassLoader.loadClass(BootstrapClassLoader.java:263)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at coldfusion.compiler.NeoTranslator.<init>(NeoTranslator.java:144)
        at coldfusion.tools.Compiler.main(Compiler.java:287)
        ... 5 more
Caused by: java.lang.ClassNotFoundException: javax.servlet.jsp.tagext.TagLibraryInfo
        at coldfusion.bootstrap.BootstrapClassLoader.loadClass(BootstrapClassLoader.java:303)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        ... 17 more
These paths worked with runwar5.0.8: CFUSION_HOME=/usr/local/lib/serverHome/WEB-INF/cfusion J2EEJAR=$CFUSION_HOME/lib/etc/servlet-api-3.1.jar:$CFUSION_HOME/../../../CommandBox/lib/runwar-5.0.8.jar
obviously changed it to runwar5.1.1.jar in the newer version which gives the stacktrace
j
If you point this to the runwar-jakarta jar, it should work for you:
Copy code
$CFUSION_HOME/../../../CommandBox/lib/runwar-5.0.8.jar
The default version of Runwar isn’t on Jakarta. that is going to be in 
$COMMANDBOX_HOME/cfml/modules/commandbox-boxlang/lib
Actually, if it’s looking for the 
javax
class, then you just need to point that line to the updated version of the 
runwar
jar in the 
lib
directory.
d
ahh finger trouble - I had missed the "legacy" from runwar-legacy-5.1.1.jar
works if I point it to something that exists 🙂 Thanks very much for looking into it guys.
🙂 1
Open in Slack
Previous
Powered by