portal entry

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.

Comment by Charlie Arehart

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. <blockquote>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)</blockquote> 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    

Comment by Benjamin Reid

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: "<em>As a workaround, copy tools.jar from jre > lib (1.8) to WEB_INF > cfusion > lib and restart the server.</em>". So I did that... and now I receive the first error again.

Comment by Benjamin Reid

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.

Comment by Charlie Arehart

Benjamin, be careful what you are doing there. That mention (in the release notes at <a href="https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html" rel="nofollow">https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html</a>) 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).

Comment by Charlie Arehart

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.

Comment by Charlie Arehart

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.

Comment by Benjamin Reid

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.

Comment by Charlie Arehart

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.

Comment by Benjamin Reid

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.

Comment by Benjamin Reid

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).

Comment by Charlie Arehart

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: <a href="https://blogs.oracle.com/java-platform-group/understanding-the-server-jre" rel="nofollow">https://blogs.oracle.com/java-platform-group/understanding-the-server-jre</a> 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.    

Comment by Benjamin Reid

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.

Comment by Charlie Arehart