tracker issue : CF-4203133

select a category, or use search below
(searches all categories and all time range)
Title:

Webservice compilation error in WAR install

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): Bradley Wood / ()

Created: 07/24/2018

Components: Web Services

Versions: 2018

Failure Type: Crash

Found In Build/Fixed In Build: Final /

Priority/Frequency: Normal / All users will encounter

Locale/System: / Platforms All

Vote Count: 1

Problem Description:
When creating a webservice, there is an error related to a "jikes" binary not existing.  This appears to affect a WAR deploy.

Steps to Reproduce:
Start up a 2018 WAR and create a webservice.

Actual Result:
Cannot run program "jikes": error=2, No such file or directory
StackTrace    java.io.IOException: Cannot run program "jikes": error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at java.lang.Runtime.exec(Runtime.java:620) at java.lang.Runtime.exec(Runtime.java:528) at coldfusion.jsp.JavaCompiler.outProcessCompile(JavaCompiler.java:648) at coldfusion.jsp.JavaCompiler.compileClass(JavaCompiler.java:147) at coldfusion.xml.rpc.Axis1ServiceInfoGeneratorStrategy$2.run(Axis1ServiceInfoGeneratorStrategy.java:153) at java.security.AccessController.doPrivileged(Native Method) at coldfusion.xml.rpc.Axis1ServiceInfoGeneratorStrategy.generateServiceInfo(Axis1ServiceInfoGeneratorStrategy.java:129) at coldfusion.xml.rpc.XmlRpcServiceImpl.generateServiceInfo(XmlRpcServiceImpl.java:456) at coldfusion.xml.rpc.XmlRpcServiceImpl.registerWebService(XmlRpcServiceImpl.java:390) at coldfusion.xml.rpc.XmlRpcServiceImpl.getWebServiceProxy(XmlRpcServiceImpl.java:813) at coldfusion.xml.rpc.WebServiceProxyFactory.getProxy(WebServiceProxyFactory.java:22) at coldfusion.runtime.ProxyFactory.getProxy(ProxyFactory.java:69) at coldfusion.runtime.CFPage.createObjectProxy(CFPage.java:8300) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8099) at cfBuilder2ecfc1258239364$funcBUILDWEBSERVICE.runFunction(/Users/lmajano/Sites/cboxdev/coldbox/system/ioc/Builder.cfc:321) at 

Expected Result:
The webservice should be created

Any Workarounds:
Place tools.jar in your cfusion/lib folder.

Attachments:

Comments:

Hi Brad, You are seeing error related to 'jikes' because your j2ee deployment is pointing to jre version less than 9. Point the jre to 10 or 9 and before that remove tools.jar that you have placed lib inside lib directory as it might can create conflict. Jre 10/9 has modules file inside lib instead of tools.jar. This module file has tools .jar embedded inside it. we cannot support jre <9 because both tools.jar and modules file can create conflicts.I would suggest to point the Jre to 10, as latest.   Thanks Poonam
Comment by Poonam J.
29384 | July 24, 2018 08:04:21 AM GMT
Wow, so just ot be clear, you're saying that ColdFusion 2018 has dropped support for Java 8 and it is a requirement to use Java 9 or above now? Just curious, if that has been documented anywhere as I was not aware of that. In fact, that might create an issue for our Travis builds since we still run our tests against things like CF11 which don't yet support Java 9+. I did find this doc just now: https://helpx.adobe.com/pdf/coldfusion2018-support-matrix.pdf It actually only lists Java 10 but I'm unclear on if that's the only supported version of Java or just the maximum version.
Comment by Bradley W.
29390 | July 24, 2018 04:44:59 PM GMT
The supported version for ColdFusion 2018 is Java 10, which we have certify. With external java for e,g java 8 , the one you are using , you might face some issues. Like the one for web services. The workaround works fine. We will get his documented.I will be raising the ticket for the same and update you on thread.   -Poonam
Comment by Poonam J.
29396 | July 25, 2018 05:39:18 AM GMT
Documentation updated with the workaround. Here it is https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html
Comment by Poonam J.
29399 | July 25, 2018 09:00:08 AM GMT
Thank you for the documentation update. I'm still a little unclear. Can you specifically confirm, has Adobe officially dropped support for Java 8 in ColdFusion 2018? I'm getting some mixed signals on that. If Java 8 is officially dropped in terms of support then I think the workaround is fine. If java 8 is still supported, I would like to see a better workaround. The idea of manually copying files about isn't a very good solution when it comes to things like CommandBox servers which spin up completely automated and need to "just work" without user intervention. Especially true in a Docker environment where direct access to the file system of the contain is not easy and sometimes not even possible! We have to stop treating servers as pets :) The cfusion/lib dir isn't directly part of the WAR class path. Is there a way the bootstrap servlet can detect the Java version and copy the jar if necessary before the cfusion/lib folder is classloaded?
Comment by Bradley W.
29403 | July 25, 2018 09:19:49 PM GMT
We have not dropped support for java 8. ColdFusion works fine with java 8. But in few scenarios like web services we cannot resolve dependency for java 8 as it might can create conflicts between libraries. A per the support matrix we have certify java 10 resolving all the dependencies.   Closing the bug as AsDesigned,
Comment by Poonam J.
29407 | July 27, 2018 03:50:07 AM GMT
Hi Poonam, will you re-open this ticket and consider improving your support for Java 8? Did you see my suggestion of putting in a check to copy the jar over for Java 8 before the cfusion libs are classloaded? You did not address that. Your Java 8 workaround simply won't work for me. ColdFusion 2018 is failing in our ColdBox Travis CI build, which is run via CommandBox on the cloud in a private container that I have no access to, I can't even SSH into it. It's a 100% automated deployment, start server, run tests, stop server, destroy the container. I cannot do any sort of manual copying of jars. If Adobe is supporting Java 8, it needs to support it better than this. Workarounds that involve manual interaction with the deployment process are not acceptable.
Comment by Bradley W.
29411 | July 28, 2018 04:45:11 PM GMT