Tommy Griffith

Thank you, Tim, I tried to put javaee-api-8.0.jar into the app, redeployed, and still getting the same java.langNoClassDefFoundError: org/omg/CORBA/UserException

I'm beginning to wonder if it's even bundled in this jar. This is really frustrating.

I should qualify my statement. One of the apps I did find the source code and I had to revamp some of the classes to work with Oracle cursors (previously it integrated with SQL Server). The second app, I suspect, is closely related in source code but that was lost way back when a server died suddenly. So I could get the second going based on the first source code, I think.

Nevertheless, they are going to move these apps, just as likely non-Java, so I can't be funded to re-do these two apps at this stage. They aren't major, they integrate Oracle and Lotus Domino data.

I suspect there is a straight-forward way to move that API in to either TOmcat or the JRE.

I've tried putting javaee-api-8.0.jar ito Tomcat lib as well as bpoth the JDK/JRE 9 lib folders but it doesn't see anything.

Hi, Tim. Thank you. yes, these are two web apps which I am trying to keep running as the plan is to replace them. I inherited the project and recently upgraded from Tomcat 5 and JDK 5 to 9 and 8 respectively. I had to work through several configuration changes and issues but they are running. The other rub is I do not have the source code for these. So I need to keep them running at the highest levels of Tomcat/JDK possible until replacement.

So, if possible, I am hoping backward compatible these in Java 9.

Hi I found a javaee-api jar at...

https://mvnrepository.com/artifact/javax/javaee-api/8.0

dumped it into the Tomcat lib, restarted.

however, still receiving...

java.lang.noClassDefFoundError: org/omg/CORBA/UserException

So I'm kind of where this started. If anybody has any thoughs, I would appreciate them. Thank you.

I think I found something...two days and all i did was add "Central" to the search and it kind of just showed up...

https://mvnrepository.com/artifact/javax/javaee-api/8.0

So i'm going to try to dump the jar into the lib and see if that works.

Hello. The following is from Oracle explaining how to make existing apps backward compatible in Java 9. However, I am stuck on finding these standalone version of EE APIs. Are these JARs somewhere which could be dumped into the lib? It talks about Maven Central, I don't really know what that is. I can't find anything except the Java 8 SDK itself. Thank you so much for reading and your help.

================================================================

The migration options for libraries or applications that use these APIs are:

Use the --add-modules command-line option to ensure that the module with the API is resolved at startup. For example, specify --add-module java.xml.bind to ensure that the java.xml.bind module is resolved. This allows existing code that uses the JAXB API and implementation to work as it did in JDK 8.

This is a temporary workaround because eventually these modules will be removed from the JDK.

Using --add-modules java.se.ee or --add-modules ALL-SYSTEM as a workaround is not recommended. These options will resolve all Java EE modules, which is problematic in environments that are also using the standalone versions of APIs.

Deploy the standalone version of the API (and implementation if needed) on the class path. Each of the Java EE APIs are standalone technologies with projects published in Maven Central.

Deploy the standalone version of these modules on the upgrade module path. The standalone versions are provided by the Java EE project.

==================================================================

Yeah, Jeanne, I've spent three days wondering what was going on with this. I pulled this off the Tomcat site which tells me to avoid --add-module anyway. But it indicates standalone API. So I was assuming JARs which maybe could be dumped into lib? But I can't find anything...

================================================================

The migration options for libraries or applications that use these APIs are:

Use the --add-modules command-line option to ensure that the module with the API is resolved at startup. For example, specify --add-module java.xml.bind to ensure that the java.xml.bind module is resolved. This allows existing code that uses the JAXB API and implementation to work as it did in JDK 8.

This is a temporary workaround because eventually these modules will be removed from the JDK.

Using --add-modules java.se.ee or --add-modules ALL-SYSTEM as a workaround is not recommended. These options will resolve all Java EE modules, which is problematic in environments that are also using the standalone versions of APIs.

Deploy the standalone version of the API (and implementation if needed) on the class path. Each of the Java EE APIs are standalone technologies with projects published in Maven Central.

Deploy the standalone version of these modules on the upgrade module path. The standalone versions are provided by the Java EE project.

==================================================================

Geez, sorry about my typos. I guess I was a little excited looking into this. I see now how the EE APIs have been removed from JDK 9.

I'm running Tomcat as a service so I'm trying to figure out the best way to add the java.se.ee modules. The service doesn't run through startup.bat and service.bat is just the installation.

Then I was reading stuff about how --add-modules will be gone in Java 10 and we should build a dependency. So I'm looking into that. Any input would be valuable but you really put me on the right track. Thank you.

Thank you very much. Is this something new with JDK 9? I didn't have to mess with anything on any prioer Tomcat/JDK combination. I've noticed weird things with the file structure in JDK 9, like hos the JRE is broken off in it's own directory (no longer a sub) and the absence of rt.jar (which I always thought contained CORBA).

What the situation is...wiht the same exact Jars in lib, same exact war deployment...

Tomcat 9/JDK 8 - things work fine.

Tomcat 9/JDK 9 - java.lang.ClassnotFoundException: org.omg.CORBA.UserException

It looks to me upon further inspection that org.omg.CORBA might be contained in an external NCSO.jar. I brought this in form Lotus Domino as the servlet integrates Oracle (via JDBC) and Lotus Domino.

NCSO.jar resides in the Tomcat lib in both scenarios so I can't figure out why it can't be found with Tomcat 9/JDK 9. Evenso, isn't org.omg.CORBA part of the JDK 9 which Tomcat points to anyway?

Thank you, Knute. In my opinion...

java.lang.ClassnotFoundException: org.omg.CORBA.UserException

isn't a Tomcat issue. I believe it's an issue between JDK/JRE 8 and JDK/JRE 9. As it comes under java.lang.Exception. i think it's going to be a JRE or classpath thing. Would you mind if I started a new thread for it in this forum?

Hi, Pete. just as a follow-up, I eventually recoded service.bat install for Tomcat 9  to look into the respective directories. Apparently I found where the Tomcat service.bat wasn't set up to use the new JDK 9 directory structure. So the service is running.

I was going to start a separate thread but now, when I run the same exact war (servlet), I am receiving the following error in Tomcat 9/JDK 9...

java.lang.ClassnotFoundException: org.omg.CORBA.UserException

The servlet running in Tomcat9/JDK 8 doesn't throw anything. I have the same exact jars in Tomcat lib. Do I need to add some jar with org.omg.CORBA?

It's weird that it's only with JDK 9 and not with JDK 8. The servlet code is unchanged. Thank you so much again for everything.

Hi, Pete. Thank you so much for that. I followed the logic and used setx to temporarily set the TMP user environment variable to the install directory. interestingly, The JDK install didn't care about the TEMP variable, it only looked for TMP. Anyway, the sequence was setx TMP = c:\Dummy, run the install, setx back to previous Temp path.

Now, my problem is the Tomcat 9 service.bat install is not reading JAVA_HOME when it's set to C:\Program Files\Java\jdk9.

I get JAVA_HOME not set properly, point to JDK, not JRE.

When I reset JAVA_HOME to Java 8....C:\Program Files\Java\jdk8...it works. Service is installed.

I noticed the jre9 directory is broken out into it's own directory from jdk9 after the 9 install.

In 8, there was a jre8 under jdk8.

Anyways, not sure what the problem is.

Pete, thanks you so much for your help. i finally was able to find logging behind Computer Management - Event View - Windows Logs - Application.

The problem is that the jdk install creates a Temp directory for my user account under C:\USERS..." where it apparently places the jdk install executable.

However, McAfee is preventing all programs from running files from the Temp Folder.

So i guess the question is, without having them temporarily drop McAfee while  I ran an install, is there a way to run the silent install but give it somewhere else other than the default directory to run it from?

Thanks for all of that, Pete. I did confirm no presence of JDK 9 java.exe nor javac.exe.

I did confirm this server is running 64 bit Windows.

Oracle doesn't offer 32-bit JDK for 9, only 64-bit.

So when I run the jdk.exe /s on server console, nothing happens. It just returns to the prompt. no errors, no confirmation. It takes just a second so I know something is bombing somewhere. If I don't have server admin rights, wouldn't that yell about that? i just have no logging or anything to go on. Thanks again.