Which files replace tools.jar in JDK 9/10/11?
I am having a problem consuming web services on ColdFusion 2018 under JRE 10.
When using Web Services in ColdFusion 7/8/9/10/11/2016 we previously had to copy the tools.jar file from the JDK into the cfusion/lib directory to make it all work correctly.
As of Java 9, tools.jar has apparently been removed from the JDK and replaced with a more structured set of utilities.
ColdFusion 2018 uses Java 10 and JDK 10 also does not contain tools.jar.
Using JRE 10.0.2, when instantiating our CFC (on a remote server) as a web service with CreateObject("webservice", url, {wsversion="1"}) – I get the following error:
“Connection Failed: coldfusion.jsp.CompilationFailedException: Errors reported by Java compiler: An exception has occurred in the compiler (1.8.0_191). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at com.sun.tools.javac.file.Locations.getPathEntries(Locations.java:149) at com.sun.tools.javac.file.Locations.getPathEntries(Locations.java:134) at com.sun.tools.javac.file.Locations.access$000(Locations.java:71) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.computePath(Locations.java:617) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.lazy(Locations.java:643) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.getLocation(Locations.java:577) at com.sun.tools.javac.file.Locations.getLocation(Locations.java:678) at com.sun.tools.javac.file.JavacFileManager.getLocation(JavacFileManager.java:803) at com.su….”
Using JDK 10.0.2, when instantiating the same it all works with no errors.
So clearly the required files are present in the JDK, but not the JRE.
I am presuming that, as it was previously, it will be possible to copy the necessary files from the JDK into ColdFusion and everything will work.
What I need to know is which files specifically are required… i.e. which files specifically do I copy from the JDK 10 into cfusion/lib?
Also, will this be the same for Java 11 LTS?
My best guess so far is: {jdk}/jmods/java.xml.jmod and {jdk}/jmods/java.xml.ws.jmod – but there could be more/other files required.
Newbie
1 posts
SOLVED – use the “Server JRE” instead of the JRE or JDK to update the ColdFusion JVM.
It is important from a security perspective to keep the ColdFusion JVM up-to-date. However, I had traditionally been downloading, installing and using the Java SE Runtime Environment JRE installer, as opposed to the Server JRE; and I specifically was not using the JDK installer because it contains development tools that are not intended for deployment on a production server (which would also be picked up as a vulnerability by any good security penetration test).
I had been liaising with CF Support for assistance with this and had not really come to an effective solution for my issue. After some further offline discussions with Charlie Arehart, he suggested that there may have been a misunderstanding on my behalf, relating to exactly which Java download I should be using and installing.
Charlie suggested that the “Server JRE” should give me exactly what I want, because it includes the necessary server files needed (to do things like compile webservices), but does not include the unwanted JDK files (like debugging and other development tools), nor does it include other unwanted desktop JRE files (like the Java Plugin for web browsers and auto update agent).
He also pointed me to an Oracle article that explains how the Server JRE fits in amongst the options on the Java Downloads page, including: the Java Runtime Environment (JRE), the Server JRE, and the Java Development Kit (JDK).
Understanding the Server JRE:
https://blogs.oracle.com/java-platform-group/understanding-the-server-jre
Charlie Arehart to the rescue again! Thanks Charlie.
I confirmed this understanding with CF Support and they concurred that the Server JRE should work fine with the ColdFusion JVM.
It is also worth noting that the Server JRE does not have an installer, you just extract it. When you download and extract the Server JRE g-zipped tarball file, it actually creates a directory called jdk-10.0.2 (as opposed to jre-10.0.2). As the above mentioned article states: the Server JRE was designed for server-side applications by including just the commonly required features from the JRE and JDK.
Throughout this process, it has made me reflect on just how confusing the terminology can be, even when you know what they all mean: JVM, JDK, JRE, Server JRE all sound very similar, but have such subtle, yet important differences.
Charlie also pointed out to me that the official Adobe documentation and resources such as the System Support Matrix, amongst others all refer to using/updating the ColdFusion JVM with the latest Java JDK – that is, it doesn’t mention the JRE nor the Server JRE.
Given that you would not actually want to install the full JDK on a production server, I think that the Adobe resources and documentation should be updated to reflect this, and specifically mention that either the JDK or the Server JRE can be used, but the Server JRE is the most appropriate option for production servers.
So, finally referring back to the original problem, the reason I was getting an error trying to run a ColdFusion webservice (WSDL URL referring to an access=remote CFC function) was because I had updated the ColdFusion JVM to use the desktop JRE which was missing the server-side components included with the Server JRE and JDK. To resolve the issue, I updated the ColdFusion JVM to use the Server JRE, and no additional tools.jar or jmod addons were required.
Great to see the conclusion to the saga, and thanks of course for the kind regards.
Actually, I will add that I’d only very recently learned about the concern some have regarding the JDK.
And I’d just accepted the Adobe recommendation to use (and led people to install) the JDK rather than the Server JRE. I knew of it, but I’d always wondered if there was a chance that somehow the Server JRE might NOT have something the JDK had, which CF would need.
But when I saw the back and forth with Ben in an email with Adobe (that he shared with me), I realized he shared there a bit more info than was in this portal post, and that is what led me to propose the Server JRE (especially for Java 10 on 2018, as he was using), and I’m glad it worked out for him.
So yes, if Adobe affirms that the Server JRE is ok for CF2018 (as well as 2016 and 11), that would be helpful to know and point out to folks.
Bear in mind, that this was a brand new install of ColdFusion 2018.
The issue happens on JRE 10.0.1 (the one that ships with CF2018) and JRE 10.0.2 (the most recent update as of writing this) but does not happen when using JDK 10.0.2 (or JDK 10.0.1 for that matter). So it is the difference between the Java Runtime Environment and the Java Development Kit that I am focused on.
Perhaps I have worded my question badly, because you seem to have completely missed the point:
Oracle have stated that as of Java 9, tools.jar is removed, and replaced with a set of more structured jmod files (Java 9 modularity). Given that we are now running Java 10 I need to know which exact files replace tools.jar?
It is possible I suppose that it may be necessary to use the old Java 8 tools.jar, like the Release Notes page says (admittedly not in the exact context I experienced the issue, as you pointed out), but that seems unlikely to me – why would you use a Java 8 JDK file under Java 10.x.x?
But yes, my core issue is how to move forward from here. I would like to deploy CF2018 in production, but this issue is currently preventing me from doing so because we require the ability to access remote CF web services in the manner I have described (which have previously required tools.jar).
I have also now logged this request with CFsup@adobe.com and Vikram Kumar on the ColdFusion Support team is investigating it further.
So you’re saying you think that anyone running cf2018 would be unable to call web services Really? If so, then yes, I missed that point. And I don’t expect it’s what you surmise.
Surely others would have raised that since release in july, if not the months of prerelease before.
I get it. You just want it to work. I’ll demonstrate if it does, and again if so, then this would seem an issue unique to you.
Are there ANY other aspects of the install you did that vary from norm? I’ll assume you’d say no.
I am not saying anyone running cf2018 would encounter this issue.I am experiencing it though.I really just wanted some help to figure out my issue.I have applied a lockdown, in accordance with the official 2018 lockdown guide from Pete Freitag, although I am not expecting that to be an issue as it is not throwing a security exception.If it helps with the investigation at your end, I call the CFC using the WSDL url and then make a call on an access=remote function within the CFC.If you want to connect to my environment and have a look, you are most welcome to – I would welcome the help.
Ben, any news? You say Adobe support was going to help. I figured they’d do that screenshare that you offered. (I do those also, as part of my consulting services. If that interests you, see more at carehart.org/consulting. I may well see the solution in minutes, so it’s your call as to the urgency/importance/value.)
As for you saying you applied lockdown, well, do you mean that you ran the CF2018 autolockdown tool (which the 2018 version of the lockdown guide now has you do)? If so, that may well be the cause of your issue (and why others may not be seeing it). That lockdown tool does indeed change a lot.
Did you check its logs to confirm all was well (per section 2.6.12 of the guide)? Perhaps there was an issue tracked there.
And on a related note, you don’t mention if you applied CF2018’s update 1. If you did, the technote for that update clarifies that those who have applied the autolockdown tool need to take extra steps before applying the update. And along those lines, did you check the update log for that update, to make sure there were no problems in that? I have a blog post with more on that. See carehart.org/top.cfm.
Hope that may get you going, or Adobe may, or if you’re interested that I may in an online consulting session together. Really hope to see the problem solved for you, especially if it may affect others (though for now, I’ve not heard of it).
OK, so following up on two of my previous replies here (replies to Ben’s comments, and so buried under the “reply” button and perhaps easily missed by casual readers), I wanted to take a step back.
So Benjamin is saying that all this happened when he moved from Java 10.0.1 (which CF2018 comes with, including even its update 1). More than that, he is saying it only happens if he uses the 10.0.2 JRE rather than the 10.0.2 JDK. That is indeed interesting.
FWIW, I will say that the Java 10.0.2 release notes make no mention of any change regarding web services.
So some folks would say “just go back to the old JRE, or forward to the new JDK”.
But I realize you are perhaps simply wanting to get someone from Adobe to acknowledge the issue and/or explain if what you are seeing is what they would expect, and if not what would they do about it (or how are you to resolve it until then).
It will help for someone else to prove that this happens for them. I will make note to try it tonight or tomorrow, to see if I can confirm. (And some would propose that you could file this as a bug report at tracker.adobe.com, but by posting the concern here first it would likely get more discussion than in the bug tracker.)
If it ends up that I have no problem running a call like you list at the outset here, then we will have to wonder if there is simply some config issue on your end.
But maybe someone else will chime in with more, either way.
Hi Charlie,
I cleared the stubs directory as suggested, and I now get a different error (see below). I had tried copying the tools.jar from Java 8 JDK into cfusion\lib, so I expect that was a hangover from that attempt. I don’t know what this “jikes” thing is… but I think my basic question still stands – the question is less about ColdFusion, or the error itself, but more about which files replace tools.jar in the JDK 10; because as I said, when using JDK 10 it all works correctly, and we have previously always had to include tools.jar from JDK 8.
java.io.IOException: Cannot run program “jikes”: CreateProcess error=2, The system cannot find the file specified
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
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.base/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:8350)
at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8149)
at cfsyndicate2ecfc264017$funcREMOTECONNECT.runFunction({path_to_cfc}:210)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:552)
at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:446)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:397)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:370)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:597)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:823)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:629)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:3302)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:3277)
at cfsyndication_detail2ecfm1015563438._factor0({path_to_cfm}:32)
at cfsyndication_detail2ecfm1015563438._factor1({path_to_cfm}:11)
at cfsyndication_detail2ecfm1015563438.runPage({path_to_cfm}:1)
at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:262)
at coldfusion.tagext.lang.IncludeTag.handlePageInvoke(IncludeTag.java:729)
at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:565)
at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)
at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:504)
at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:162)
at coldfusion.filter.IpFilter.invoke(IpFilter.java:45)
at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:30)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:96)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:60)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
at coldfusion.CfmServlet.service(CfmServlet.java:226)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:311)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:46)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at coldfusion.inspect.weinre.MobileDeviceDomInspectionFilter.doFilter(MobileDeviceDomInspectionFilter.java:121)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:422)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:764)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1388)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Unknown Source)
Further clarification as requested:
I changed the JVM using the ColdFusion 2018 Administrator – Server Settings/Java and JVM page – just like you normally would;
The path I used for JRE 10 was: C:/Program Files/Java/jre-10.0.2
The path I used for JDK 10 was: C:/Program Files/Java/jdk-10.0.2
I did notice the reference to 1.8.0_191, but I actually didn’t trigger on that (other than thinking that 191 was the latest release for Java 8); and I don’t actually have Java 8 installed at all.
If I type java -version from command prompt, I get: java version “10.0.2” 2018-07-17
So Benjamin, the tools.jar update was never “needed” to be done except when folks moved from one major version to another (this is mentioned in the various Adobe blog posts when a new JVM version would come out and they would explain it, and it’s also mentioned in this post:
https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html
Again, since you are moving from 10.0.1 to .2, this really should NOT be an issue. But since there’s that reference to 1.8 in that earlier error, that is odd, again.
I see your later comment and I will add more there.
Benjamin, before we presume this is a problem inherent in cf2018 can you clsirify:
How did you change which jvm cf uses?
Can you show the paths you used for the 10.0.2 jre vs jdk?
Did you notice that the error refers to 1.8.0_191. Are you sure cf isn’t somehow not finding your jdk and therefore reverting to your public jre, if it’s 1.8.0_191?
Is that version what you see if you run “jave -version” from the command line (in any folder that does NOT have the Java binary)?
Finally, if somehow all proves correct in your config, I wonder if it would help for you to delete the stubs folder for the web svc (in cfusion/stubs). Normally that’s only needed when switching between major jvm versions, but perhaps something changed between 10.0.1 and 10.0.2 related to this But the reference in the error to 1.8.0_191 does seem most curious.
Let us know what you find.
Ok a few more things…
Jikes is an open-source high performance java compiler to convert java source code into bytecode – found that on Wikipedia.
I also found the exact error message on the ColdFusion 2018 Release Notes page as a documented Known Issue.
It offered a work-around saying: “As a workaround, copy tools.jar from jre > lib (1.8) to WEB_INF > cfusion > lib and restart the server.“.
So I did that… and now I receive the first error again.
Benjamin, be careful what you are doing there. That mention (in the release notes at https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html) is not something EVERYONE using CF should do.
The step you quote was prefaced by a point that “after starting a WAR and trying to invoke a web service” and it showed the error about jikes. I suppose that is how you found this page, given your jikes error.
But the reference to “starting a WAR” means that this step APPLIES ONLY to those running CF on a JEE server (like websphere or Tomcat–but not the tomcat that comes bundled WITH CF, one you would install yourself and then deploy CF as a WAR). Did you do that, deploying CF as a war? If you did not, then this step does NOT seem to apply to you.
I’ll have more to say in another comment in a moment, which I will post at the top level rather than as a reply here (as these can be missed by casual readers of the discussion).
No, I did not deploy as a WAR. I just thought I would try the listed work-around given that I was getting the same error.
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
