[Robert Varga]

I am not able to connect to a Tomcat 8.5 or a Wildfly 15 running on non-privileged localhost ports with a browser via HTTPS when starting it with ME2018 (the below installation config).

It works fine when I start the same Tomcat 8.5 (same directory, same configuration, same JDK, same JRE params and settings) from ME2017 or from command line (connecting to both Tomcat 8.5 and Wildfly 15 works when starting them from command line). It is only ME2018 which refuses to work. I haven’t tested other server types, but 2 out of 2 not working is probably a sign of it not working with any types.

I get the following error in Firefox:

Secure Connection Failed

An error occurred during a connection to localhost:17443. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

I get the following error in Chrome:

This site can’t provide a secure connection localhost uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don’t support a common SSL protocol version or cipher suite.

I use a self-signed certificate which had been added to the browser as an exception so it accepts it without an issue when the server is not running from ME2018.

I am running both Tomcat 8.5 and Wildfly 15 with JDK 64-bit 8u181 on Windows 10 Pro.

I am running ME2018 with its default installation JVM which is Java 10, whereas ME2017 is running with its own default installation JVM which is Java 8, the issue may lie somewhere here…

Installation details attached.

This seems to be a quite serious issue to me, and I can’t really find the cause.

Attachments:

You must be logged in to view attached files.

[support-tony]

Robert,

I’ve been unable to replicate the problem in Tomcat (tried 8.5 and 9.0), so I’m wondering if your connectors are set up the same way in MyEclipse 2017 and MyEclipse 2018. I’m not sure what set up might cause the specific errors you see but any differences might give us a clue. If you can export the connectors from each MyEclipse installation (File>Export>Java EE>MyEclipse Servers and follow the wizard) and attach them here, we could try to replicate with your settings. The relevant SSL connector configuration in your server.xml file (for Tomcat), might also help.

Could you also check the launch configuration of the server in each installation of MyEclipse (double click on the server in the Servers view then click the Open launch configuration link in the configuration editor), in case you have made changes there?

If you’re running the server with the same JDK, then the JDK used to run MyEclipse would not affect this.

We look forward to getting the server exported configuration, the connect configuration, and any further information you feel might help us investigate this further

[Robert Varga]

Hi Tony,

thanks for the quick answer. I think I found the actual culprit.

First, I compared the server configuration exports and all differences were non-relevant, because when I made the difference go away (CodeLive was not disabled in 2018), the problem still remained. So that was not it and now the configuration is same between ME2017, ME2018 (and STS 4.1.1 for that matter).

However, I noticed earlier that curiously, the startup log of Tomcat when running in ME2018 contains an entry, which is not contained when running that Tomcat either from ME2017 or from STS nor when running it from command line.

Feb 04, 2019 11:30:27 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: -Xbootclasspath:C:\Java\jdk8u181_64\jre\lib\resources.jar;C:\Java\jdk8u181_64\jre\lib\rt.jar;C:\Java\jdk8u181_64\jre\lib\jsse.jar;C:\Java\jdk8u181_64\jre\lib\jce.jar;C:\Java\jdk8u181_64\jre\lib\charsets.jar;C:\Java\jdk8u181_64\jre\lib\jfr.jar;C:\Java\jdk8u181_64\jre\lib\ext\access-bridge-64.jar;C:\Java\jdk8u181_64\jre\lib\ext\cldrdata.jar;C:\Java\jdk8u181_64\jre\lib\ext\dnsns.jar;C:\Java\jdk8u181_64\jre\lib\ext\jaccess.jar;C:\Java\jdk8u181_64\jre\lib\ext\jfxrt.jar;C:\Java\jdk8u181_64\jre\lib\ext\localedata.jar;C:\Java\jdk8u181_64\jre\lib\ext\nashorn.jar;C:\Java\jdk8u181_64\jre\lib\ext\sunec.jar;C:\Java\jdk8u181_64\jre\lib\ext\sunjce_provider.jar;C:\Java\jdk8u181_64\jre\lib\ext\sunmscapi.jar;C:\Java\jdk8u181_64\jre\lib\ext\sunpkcs11.jar;C:\Java\jdk8u181_64\jre\lib\ext\zipfs.jar

Note, that the earlier logged out line for my Java home from the same startup log is:

Feb 04, 2019 11:30:27 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Java Home: C:\Java\jdk8_64\jre

Note that the two JDK paths there are different. The explanation on how you can have a different path there is that the C:\Java\jdk8_64 is a directory junction pointing to C:\Java\jdk8u181_64, so the two directories are in fact the same, but I guess C:\Java\jdk8u181_64 is the canonical form.

Also C:\Java\jdk8_64 is specified as the installation directory for the installed JRE entry selected for running this Tomcat in the Tomcat configuration in Eclipse. The reason for this is that when I update the JDK, I just point the directory junction to the new JDK version, and I don’t have to change anything else in my system. Or did not up to now, as ME2018 acts erroneously when using it.

This may be the issue in two ways:

One is that the entry itself is not present in situations running it correctly, and its presence in general may be the cause of the problem.

The other is that all other references to the home directory of the JDK appears as C:\Java\jdk8_64 which is a directory junction pointing to C:\Java\jdk8u181_64 which is the way the same directory appears in the log only in this place. Now that may or may not make the JDK believe we are actually specifying a different set of boot classpath libraries which it may or may not like.

When I changed the C:\Java\jdk8_64 to C:\Java\jdk8u181_64 at the installed JRE configuration for this JRE entry (so not in the Tomcat configuration), and started Tomcat again, everything in the log then contained the canonical C:\Java\jdk8u181_64 path and both the surplus log entry disappeared, and the problem got fixed, too.

Note, that this behaviour is unique only to ME2018 as far as I tested, although I am not sure about other versions of ME2017 as I use a somewhat old version of it, so I can’t be sure when this behaviour was introduced, but it definitely is the culprit. ME2017 and STS definitely doesn’t seem to suffer from this and works fine with specifying just a directory junction to the installation directory of the JRE installation referenced from the Tomcat config.

So how I see, the situation probably is that somewhere along the line between 2017 Stable 2.0 15.0.1-20171220 and ME CI 2018.12.0 16.0.0-20181217 ME introduced a feature which on its own decides that it wants to add a -Xbootclasspath VM argument on its own despite configuration doesn’t contain it when certain conditions are met, and the condition evaluation most likely is that you look at the absolute path of something derived from the installation directory of the JRE entry selected in the Tomcat config and compare it to the canonical path of something else whether it points to the same place, but since the path in one side was just an absolute path which wasn’t canonicalized, therefore in case of it being a directory junction it ends up mismatching even though pointing to the same thing. Alternatively Eclipse Java EE Developer Tools feature introduced it and STS 4.11 and ME CI 2018.12.0 use a different version where the bug is present in ME’s patched 3.9.2.me201812180458 version and absent (or fixed) in Spring’s probably unpatched 3.9.200.v201808172107 version of Eclipse Java EE Developer Tools which I guess would be the component responsible for the Tomcat connector.

In any case, the addition of the -Xbootclasspath entry causes the issue, whether by the simply existing or by referencing the same JRE artifacts by a different absolute path instead of what was used earlier in JAVA_HOME, I can’t tell, because I was not able to produce the case of the -Xbootclasspath entry being there and using the same absolute path.

So could you please investigate how adding that additional entry got introduced into ME, because this clearly seems to be a regression, and I do want to use the directory junction as my Java installation directory in installed JREs, and I would expect you may get into a similar situation with symlinks in Linux, potentially even more easily considering the Java alternatives mechanism used at least by Debian-based systems uses at least one symlink along the path to the Java artifacts.

This change in ME2018 also fixed the same issue with Wildfly 15.

Thanks and best regards,

Robert

• This reply was modified 5 years, 9 months ago by Robert Varga.
• This reply was modified 5 years, 9 months ago by Robert Varga.
• This reply was modified 5 years, 9 months ago by Robert Varga.

[support-tony]

Robert,

Thanks for the detailed reply and I’m glad you at least have a workaround for the issue, even if it isn’t ideal.

Whilst we investigate why the -Xbootclasspath argument was added, can I ask for a sanity check, since it’s difficult to understand how the server connector would know where the real JDK folder is, when using a junction (the use of a junction should not be visible)? Have you added a default VM argument to the definition of the JRE (at C:\Java\jdk8_64)? This can be checked by going to the JRE preferences page, selecting that JRE and clicking the Edit button. This may seem unlikely but using that field would cause exactly the difference in the arguments between the use of the two JRE definitions, so it would be good to eliminate that possibility. Having said that, it is still not clear how that would cause the problem you had with HTTPS.

[Robert Varga]

Hi Tony,

as for how it would know where the real JDK folder is, it is very easy:

new File(junctionFilePath).toPath().toRealPath() tells you where it really is… I expected getCanonicalPath() would, too, but that doesn’t.

java.io.File file = new java.io.File("C:\\Java\\jdk8_64");
System.out.println("File: "+file);
System.out.println("Absolute path: "+file.getAbsolutePath());
System.out.println("Canonical path: "+file.getCanonicalPath());
System.out.println("Real path: "+ file.toPath().toRealPath());

The output is:

File: C:\Java\jdk8_64
Absolute path: C:\Java\jdk8_64
Canonical path: C:\Java\jdk8_64
Real path: C:\Java\jdk8u181_64

As for the default VM argument, yes, at the end of the attachment in the first post it was listed, that the JRE entry has the following default VM arguments:

-XX:+UseCompressedOops -Djava.net.preferIPv4Stack=true -Xmx512m

I don’t see how that makes a difference but it was there. As I mentioned earlier, Path.toRealPath(LinkOption…) without any link options returned the real place for me.

Thanks and best regards,

Robert

[support-tony]

Thanks for those thoughts, Robert, and sorry for missing those VM arguments right at the end of the file you attached to the opening post.

You’re right that it’s possible to find the actual file; I was thinking more that the connector shouldn’t need to even consider that it’s a junction.

I did try adding that Xbootstrap argument manually to the JRE definition and it does get used but I still don’t see a problem with HTTPS. However, we will continue to investigate how it gets added in your case and will ask if we need more information, though you’ve supplied a lot.

[support-tony]

Robert,

After checking through the code, we can’t find anywhere that sets the Xbootclasspath argument but for further investigation, could you let us have the exported server configurations that you’re using, as I asked in a previous reply?

you can export the connectors from each MyEclipse installation (File>Export>Java EE>MyEclipse Servers and follow the wizard) and attach them here

Thanks.

[support-tony]

Robert,

Sorry to hurl a barrage of replies at you but we’ve thought of another couple of files that would help us replicate the problem. Apart from the server connector configurations mentioned, the server’s server.xml file and the server’s launch configuration would also be useful. The launch configuration can be exported by going to File>Export>Run/Debug>Launch Configurations, click Next then select the appropriate server under MyEclipse Servers, enter a folder path to export to in Location and click Finish.

Thanks.

[Robert Varga]

Hi Tony,

sorry for taking a bit long to get back to you about this. I was looking at the JRE installations dialog, and noticed at some point, that the JRE installation “JRE system libraries” list of jars were at a point out-of-sync with the JRE home setting of the installation. I pressed refresh defaults and that replaced the out-of-sync list of the libraries with the list of the same jars with the correct path and that caused the problem to go away. However the usual behaviour of the JRE installation dialog is that the list libraries follows the JRE home field, so I wasn’t able to get back to my original configuration.

However, I wasn’t able to figure out when and why, but sometimes the list decides not to follow the change in the JRE home field, but sometimes it just doesn’t, and it took this long to finally manage to recreate the exact original configuration (attached) causing the SSL issue in the first place. The closest I could determine the circumstances is that freshly opening the dialog seem to make it more likely that the library list doesn’t follow typing in the JRE home field. And whenever the JRE home and the JRE library list do not match, , the boot -Xbootclasspath VM argument is added and it causes the SSL issue.

So I guess the issue is not a ME issue, rather an Eclipse configuration issue after all, and can be remedied by pressing the Restore defaults button after specifying the intended JRE home which can be junction, too, so it is just a minor one.

Thanks for your patience and best regards,

Robert

• This reply was modified 5 years, 9 months ago by Robert Varga.

Attachments:

You must be logged in to view attached files.

[support-tony]

Robert,

Thanks for getting back to us with your findings and I’m glad you managed to track down the issue. It is really strange and the only way I can think of replicating it is to manually delete all of the libraries in the JRE definition and then select the ones from the actual folder. In that situation, I also see the -Xbootclasspath argument added. However, I still didn’t see a problem with accessing pages through HTTPS, so I’m not sure what the difference from your set up is.

Still, the main thing is that you’re able to work now. Thanks again for persevering with your investigations.

[Author]

Posts