OS: Windows 10 Pro - 64bit
Java Version: Java 11.0.9 ( Eclipse OpenJ9 VM )
Servlet Version: Jetty 10.0.2
Lucee Version: see below
Bouncy Castle: 1.68
I was using Lucee version 5.3.7.48 and decided to upgrade to 5.3.8.206. My application depends on a newer version of Bouncy Castle then the one shipped with Lucee.
On 5.3.7.48 I could do the follow to set the Provider to the new version of BouncyCastle.
var oBouncy = createObject(java,org.bouncycastle.jce.provider.BouncyCastleProvider);
var oSecurity = createObject(java,java.security.Security).addProvider( oBouncy );
On 5.3.8.206 this no longer works. I am experiencing this on Window 10 Pro and Arch Linux. On 5.3.8.206 when the code above runs I get the 1.38 version of BouncyCastle that ships with Lucee.
What do you mean with “no longer works”?. What are you experiencing on your Window 10 Pro and Arch Linux differently? Any stack traces or errors to show?
A possible solution could be to load an OSGI compliant bundle of 1.38 with @Julian_Halliwell OsgiLoader. Still didn’t try it with bounty castle, but this is the approach I’d go for in such a case. That should allow to load and use different libary versions of a libary and target a specific version in your application without having any version clashes.
1 Like
BouncyCastle jars are OSGi ready so it’s pretty easy to do as Andreas suggests. Here osgiLoader.cfc and the BC jar are in the same directory as the calling script:
loader = New osgiLoader();
oBouncy = loader.loadClass( "org.bouncycastle.jce.provider.BouncyCastleProvider", ExpandPath( "bcprov-jdk15on-1.68.jar" ), "bcprov", "1.68" );
dump( oBouncy[ "Provider.id version" ] );
Outputs: string 1.68
1 Like
reckon this need to be added to lucee…
1 Like
Thanks to everyone who replied. I will try osgiLoader. @andreas Here is a little more detail.
I have a complete setup of Lucee running on Jetty. I used the jar file to do the initial setup. That goes into the Jetty.base folder lib/ext. Most external, to Jetty, jar files go in this location. Normally I would upgrade Lucee via the admin but I heard there was a new class loader. So I replaced lucee-5.3.7.48 in lib.ext with lucee-5.3.8.206.jar. I restart Jetty and the new version of Lucee is deployed. Once I start up my application on Lucee 5.3.8.206 all of the functions that depend on Bouncy Castle stopped working. This is because I require a newer version of Bouncy Castle. I wrote a test case to return the version of packages like Bouncy Castle. So I know which version of Bouncy Castle I am seeing.
I then reversed the configuration returning to Lucee 5.3.7.48 and everything returned to normal. I tried this multiple times since I have it down to just swapping the jar files. My next test was to see if using just the lco file made any difference.
Andrew
I try updating via the admin which uses the lco file. I experienced the same issue with Bouncy Castle. I am off to look into my OSGI options.
I moved the new BouncyCastle jars to Lucee Server / bundles and used this format for CreateObject
createObject("java","org.bouncycastle.jce.provider.BouncyCastleProvider","bcprov","1.68");
That worked without the need to use osgiLoader. Though I did read about osgiLoader and that help greatly.
Thanks to everyone.
1 Like
Yes you can absolutely do that. What osgiLoader adds is the ability to deploy the jar to Lucee’s bundles directory automatically/dynamically when you call the class.