portal entry

Hi, In cfcompile.bat, remove two entries of "--add-modules=java.xml.ws" and restart ColdFusion service. <strong>Note: Before making the change in cfcompile.bat file, make sure you take the backup of this file.</strong> Thanks, Priyank Shrivastava

Comment by Priyank Shrivastava

Priyank, if this ends up working, can you clarify what this is about? For instance, is it a known issue? On some CF versions or updates? Or with some Java versions or updates? And does the fact that removing those makes it "work" in some scenarios mean that some later change would make it now "not work" on the same server?

Comment by Charlie Arehart

Hi Charlie, I logged a bug for this and engineering is looking into this. I found this workaround while working with a user. I have not found any repercussion after removing this. Thanks, Priyank

Comment by Priyank Shrivastava

java.xml.ws was removed in Java 11

Comment by Colby Ackerfield_382

OK, thanks Colby. So to be clear, for others finding this in the future, this is about someone using the original installer for CF2018 (which ran on Java 10) who has updated it to use Java 11. Interesting. And note that there was a new CF2018 installer in Feb 2019 that DID already come with Java 11 already installed, and I assume it would already have this reference removed (as they would have found it in testing of that new installer). Time will tell if these conclusions prove accurate.

Comment by Charlie Arehart

I would suggest to add a test for compilation. The same issue is present in /opt/coldfusion/cfusion/bin/cfcompile.sh This is reproducible very quickly using eaps-docker-coldfusion.bintray.io/cf/coldfusion:2018.0.4 image. Thanks!

Comment by NicoTexas

Interesting comment, Nico. It seems to raise a few questions. <ol> <li>Could you elaborate a bit? What do you mean "add a test for compilation"?</li> <li>And when you refer to the same issue being present in cfcompile.sh, sure that would be so. It's of course just the linux form of the cfcompile.bat that Kam and Priyank were referring to. It would not be a surprise that the same problem was in the .sh.</li> <li>To that point, Priyank, you had mentioned having opened a ticket about this. Can you share the ticket number with us? or is it an internal-only one? Did you mention both the .bat and .sh in that? If so (and if it was public), that could also help others looking into this in the future, like Nico did here.</li> <li>Finally, Nico, you note that the problem is in the 2018.0.4 image. That's very interesting to hear, for a couple of reasons. I will elaborate below, for those interested.</li> </ol> I had said below that it seemed this problem (cfcompile needing removal of that --add-modules arg) should affect only those with the original CF2018 installer (which came out running on Java 10), not those running the installer that came out in Feb which ran on Java 11. Well, as I run that image, I can see that it is indeed showing that CF is running on Java 11. But if we look at the installer log for it (in the opt/coldfusion folder), we see it WAS originally installed with the installer that came with Java 10. We can further see (with a <em>docker image history</em> against the image) that there are clearly commands where they are updating the /opt/coldfusion/jre folder to replace it with Java 11 (in the images after .01). Very interesting. So it seems that whoever builds the CF images (at Adobe) is using the result of the original CF2018 installer. That is why we find this problem happening in the Docker images (post 2018.0.1). I hope someone from Adobe is seeing this and can get that addressed. And they may say "open a ticket", but I don't think the answer to this is that simple. This issue raises a rather nasty problem which has affected most releases of CF: sometimes Adobe DOES update ("refresh") the installer. And then as people share tips, tricks, traps, bugs, and fixes, they often have no idea of the variations in installers (of the same version of CF, like these two for CF2018), and how what someone says about the result of having run the OLDER installer may or may not apply to having run the LATER installer (or in this case, vice-versa). And that raises an interesting and ugly spectre about the docker images. Should they be built to model an ORIGINAL installer (and subsequent updates) or should they model the LATER installer (and subsequent updates). It really depends on what people are expecting--but in this case I suspect most don't even understand the ramifications above. But I'd think with appropriate tagging of the images, it could be made more clear. And this is getting far afield of the original issue, but since Nico raised it, and it's related, I though it worth putting out there, for initial thoughts from anyone interested. After hearing any from him, Adobe, or others, I would then create a separate blog post raising the more general issue (of what installers the CF images should be based on), for wider consideration.

Comment by Charlie Arehart