We Keep Coding

BouncyCastleProvider not found by JAR on Lucee

We are successfully using the AmazonPay API for Java (amazon-pay-api-sdk-java-2.2.2.jar) in Adobe ColdFusion. We recently introduced Lucee (on Jetty, also running on OpenJDK 8) and attempted to run the same code (relevant excerpt):
payConfig = createObject("java", "com.amazon.pay.api.PayConfiguration").init();
payConfig.setPrivateKey("...");
However, upon calling setPrivateKey, which will arrive at Security.addProvider(new BouncyCastleProvider()); through PayConfiguration, we receive a java.lang.ClassNotFoundException:
lucee.runtime.exp.NativeException: org.bouncycastle.jce.provider.BouncyCastleProvider
at com.amazon.pay.api.PayConfiguration.setPrivateKey(PayConfiguration.java:77)
[...]
at java.lang.Thread.run(Thread.java:823)
Caused by: java.lang.NoClassDefFoundError: org.bouncycastle.jce.provider.BouncyCastleProvider
... 57 more
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider not found by amazon.pay.api.sdk.java.2.2.2 [49]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:881)
... 57 more
We have placed all dependencies (bcprov-jdk15on-1.65.jar being BouncyCastle) in /lucee-server/context/lib. Creating BouncyCastleProvider within a .cfm/.cfc does work as expected:
createObject("java", "org.bouncycastle.jce.provider.BouncyCastleProvider").init()
I don't understand what Lucee's classloader is doing here. What am I missing?

I don't know what Lucee's classloader is doing either to be honest, but this kind of error seems to be quite common when loading certain more complex jars via the Lucee /lib path. It's likely there are "class clashes" going on somewhere.
Lucee is now OSGi based which means the best way of avoiding this is to load third-party java libraries as OSGi bundles. Some libraries are already packaged for OSGi and others can be converted fairly easily. More details here.
The Amazon library doesn't seem to be OSGi friendly, although it could probably be converted without too much effort.
For now, I would look at JavaLoader as the simplest way of getting it working. I don't have any valid Amazon keys to test fully with, but using JavaLoader I was able to at least call the payConfig.setPrivateKey() method without getting a ClassNotFoundException error.

SSHJ and the Maven shade plugin

Testing SSHJ in Eclipse and everything looks good. But When I use the Maven shade plugin to package SSHJ I get the following error:
Exception in thread "main" net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods
at net.schmizz.sshj.SSHClient.auth(SSHClient.java:217)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:316)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:365)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:295)
at no.f12.SshRepository.executeTaskOnHost(SshRepository.java:23)
at no.f12.SshService.serviceCommand(SshService.java:22)
at no.f12.App.main(App.java:29)
Adding
Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
changes the error message to:
Exception in thread "main" net.schmizz.sshj.transport.TransportException: Unable to reach a settlement: [] and [aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-gcm#openssh.com, aes256-gcm#openssh.com, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour, rijndael-cbc#lysator.liu.se]
at net.schmizz.sshj.transport.Proposal.firstMatch(Proposal.java:165)
at net.schmizz.sshj.transport.Proposal.negotiate(Proposal.java:147)
at net.schmizz.sshj.transport.KeyExchanger.gotKexInit(KeyExchanger.java:239)
at net.schmizz.sshj.transport.KeyExchanger.handle(KeyExchanger.java:364)
at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:478)
at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:127)
at net.schmizz.sshj.transport.Decoder.received(Decoder.java:195)
at net.schmizz.sshj.transport.Reader.run(Reader.java:72)
Any idea how to get around this?
A bit of background to why I want to use shade... I am trying to get to a point where usage of Java and distribution of small utils is dead simple. So I create a really executable jar using this: https://github.com/brianm/really-executable-jars-maven-plugin . That enables me to create one, executable file to distribute and add to the path of the user. A bit like how Go has one binary file with all dependencies.

I had this exact problem. I finally gave up on trying to put everything in a big "uberjar".
Instead I assembled all the jars using maven-assembly-plugin, and then extract and add them to the classpath in order to execute, e.g. 'java -cp all-needed-libs/* com.company.MainClass'.

Another approach that might work is to add bouncycastle to the JRE extension library.
E.g put 'bcprov-jdk15on-1.49.jar' in folder '$JAVA_HOME/jre/lib/ext/' on the host.

You have to sign jar, it's required by Javax.security. I got similar problem and there's stacktrace from my test:
Cannot init Cipher factory: blowfish-cbc
java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(Cipher.java:642)
at javax.crypto.Cipher.getInstance(Cipher.java:580)
at net.schmizz.sshj.common.SecurityUtils.getCipher(SecurityUtils.java:96)
at net.schmizz.sshj.transport.cipher.BaseCipher.init(BaseCipher.java:88)
....
Caused by: java.util.jar.JarException: file:/test-jar-with-dependencies.jar has unsigned entries - library.properties
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:462)
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322)
at javax.crypto.JarVerifier.verify(JarVerifier.java:250)
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:161)
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:187)
at javax.crypto.Cipher.getInstance(Cipher.java:638)
at javax.crypto.Cipher.getInstance(Cipher.java:580)
at net.schmizz.sshj.common.SecurityUtils.getCipher(SecurityUtils.java:96)
at net.schmizz.sshj.transport.cipher.BaseCipher.init(BaseCipher.java:88)
at net.schmizz.sshj.DefaultConfig.initCipherFactories(DefaultConfig.java:152)
at net.schmizz.sshj.DefaultConfig.<init>(DefaultConfig.java:107)

TCLBLEND FAILURE - Centos 6.4

I have been trying to use a home grown test tool and after doing an update to Centos 6.4, I am no longer able to run the tcl based tool. I am getting the following error and I have no internet access on this server. Kindly advise how do I solve this problem?
Thanks
"XpUtils::iload -d /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1 tclblend" failed:
couldn't load file "/usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1/libtclblend.so": libjava.so: cannot open shared object file: No such file or directory
while executing
"error "\"XpUtils::iload -d $dir tclblend\" failed:\n $errMsg""
(procedure "loadtclblend" line 168)
invoked from within
"loadtclblend /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1"
("package ifneeded java 1.4.1" script)
invoked from within
"package require java"
("eval" body line 1)
invoked from within
"eval package require $pkg"
("foreach" body line 2)
invoked from within
"foreach pkg $pkgList {
set ::${pkg}Version [eval package require $pkg]
}"
(file "/usr/local/testtool/testtool" line 165)

If you read the error message trace, you'll see that it says that this is all caused by:
libjava.so: cannot open shared object file: No such file or directory
The first steps would then be to ensure that you've got a version of Java actually installed, to check that it includes the file libjava.so, and that the file has been indexed by the system shared library catalog.
It might also be worth checking that all its dependencies are also present and that you've got the architecture for the Tcl library and the Java library matched (e.g., both 32-bit) as those can cause odd failures when they go wrong.

Java Attach API: UnsatisfiedLinkError

When using the Java Attach API, I'm getting the following link error on Linux (tried it on different machines) only:
Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.tools.attach.WindowsAttachProvider.tempPath()Ljava/lang/String;
at sun.tools.attach.WindowsAttachProvider.tempPath(Native Method)
at sun.tools.attach.WindowsAttachProvider.isTempPathSecure(WindowsAttachProvider.java:74)
at sun.tools.attach.WindowsAttachProvider.listVirtualMachines(WindowsAttachProvider.java:58)
at com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:134)
at sun.tools.jconsole.LocalVirtualMachine.getAttachableVMs(LocalVirtualMachine.java:151)
at sun.tools.jconsole.LocalVirtualMachine.getAllVirtualMachines(LocalVirtualMachine.java:110)
...
Interestingly, on Solaris and Windows it's working out of the box.
I tried out several combinations of specifying java.library.path to point to the directory which contains the libattach.so but with no luck.
What's wrong here?
And as a bonus question: Is there a way to see which native library is actually bound to a java class?

Different AttachProvider are used on different platforms. On Linux, it shouldn't use sun.tools.attach.WindowsAttachProvider. It is for Windows.
[solaris] sun.tools.attach.SolarisAttachProvider
[windows] sun.tools.attach.WindowsAttachProvider
[linux] sun.tools.attach.LinuxAttachProvider
This is configured in a resource file META-INF\services\com.sun.tools.attach.spi.AttachProvider (typically this file exists in tools.jar). It will search CLASSPATH to get first occurrence of this resource file and read the AttachProvider implementation class from it.
So you can probably resolve this problem by search sun.tools.attach.WindowsAttachProvider in your CLASSPATH. Possibly you have included a tools.jar from Windows.

Using Java Within PHP - Class Not Found

I'm using Tomcat and PHP5 with JavaBridge. I have bridged PHP and Java so I can screencap web pages within PHP. This was working on another server but after moving to a new server I can not get it working, so I'm reaching for straws here.
require_once("http://localhost:8080/JavaBridge/java/Java.inc");
java_autoload("/web/sites/madfrog/domain.com/cron/bin/html2image.jar");
$JavaHTML2Image = new Java("com.elance.proposal.html2image.client.MainBridge");
It should have loaded all of the project html2image.jar when the script _autoloaded it, however when you create the new Java object I get the error
Class Not Found: Fatal error: Uncaught [[o:Exception]:"java.lang.Exception: CreateInstance failed: new com.elance.proposal.html2image.client.MainBridge. Cause: java.lang.ClassNotFoundException: com.elance.proposal.html2image.client.MainBridge
I asked the guys over in Java and they said I needed to put the jar file in the lib so Java could find it, so I dumped it into Tomcat's webapps folder an into /usr/share/java. But that did nothing. With that said the PHP has a direct reference to it, so it should be loaded.
I'm at a lost after two days. any help is appreciated!

Which version of Tomcat do you use?
For Tomcat 6 or Tomcat 7 put the jar either in ${tomcat.home}/lib or in ${tomcat.home}/webapps/${your.war}/lib
While tomcat.home is your tomcat installation directory. And your.war is the name of your war file.