Win a copy of Java by Comparison (eBook) this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

ClassnotFoundException in Tomcat after JDK 9 upgrade  RSS feed

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 21255
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
CORBA is is not part of the java.se module. you should add module java.se.ee, as that will add everything that's missing:

The Java flag to do this is --add-modules java.se.ee. You will need to tweak the Tomcat startup scripts to add it.
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author & internet detective
Marshal
Posts: 37895
594
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tommy,
Yes. This is "jigsaw". Java 9 is the first version of Java that isn't backward compatible with respect to classpaths and such. Which means teams are going to need to plan upgrades and not just switch over "and see what happens"
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

==================================================================
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 19178
85
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The telltale is in the package path: org.omg (Object Management Group).

Actually, you need to take a long look at the application architecture. CORBA was a "must-have" skill back in the 1990s, but it died pretty early in the 21st Century and most CORBA implementations haven't been maintained in years.

CORBA is a platform-independent equivalent to Java's own RMI. The most notable difference between the two is that a CORBA client doesn't have to be written in the same language (or in Java's case, even the same JVM version) as the server.

There were 2 fatal flaws in CORBA, however. First, people were trying to use it to implement remote libraries and network latency was killing performance. This isn't a CORBA-only problem and it's the reason why remote services are now preferred to remote subroutines/methods.

Secondly, CORBA didn't have fixed tcp/ip port assignments the way most other Internet protocols (such as HTTP and SMTP) do. This made firewalls a nightmare. Doubly so for the extra-paranoid shops where ports 80 and 443 might be basically the only ports allowed ingress.

SOAP attempted to remedy this by using HTTP(S) as the transport protocol (thus firewall-friendly), but SOAP is verbose, had growing pains regarding security, and when (as was common) it was used for remote library services, suffered the same latency issues as CORBA, RMI and the like. Plus there was the overhead of marshalling/unmarshalling HTML and envelope handling.

Which is how AJAX and Web Services came to be the pre-eminent remote service interfaces. They're also HTTP-based, you can do ReST for better scaling and less server overhead. And allow low-overhead data schemes such as JSON and YAML.

Which, in brief, is why if you have a CORBA app running in this millenium, you need to worry more about business strategy than you do about technical issues.

Going full circle, though, any package whose highest-level qualifier isn't "java" is not likely to be bundled with the JVM. For that matter, even expecting "java.sun" packages to be part of the JVM is risky.

Services such as CORBA were typically either bundled with the webapp server (and Tomcat never had built-in CORBA - Tomcat is not even full-stack J2EE), or had to be included as a WAR resource.

I did work on a Tomcat app using CORBA. About 10 years ago. And even then support was not good for it.
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Bartender
Posts: 19178
85
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't you just love this kind of thing?

Your company appears to have made 2 fatal mistakes.

First, and deadliest, was not having access to source code. The norm for most products these days is open-source or at least licensed source access. Back when such things were less common, the alternative was source-code escrow - a copy of the source in the hands of a neutral third party as insurance in case the original vendor went out of business or orphaned the product. Which is still recommended practice if you cannot get direct source access yourself. In the event that the app was written in house, of course, this is an indicator that someone saved too much money by not funding a responsible software archivist. Probably expected that to be just part of the 97 other once-distinct jobs that got rolled over onto one person in the name of efficiency.

Secondly, but almost equally fatal was the "If it ain't broke don't fix it" mentality that permitted such a horrendous software debt to accumulate. The idea that you pay for software once, then it's a free ride forever because bits don't rot.

Software rot is real, and as I've noted before, it's usually from the outside in. It isn't that the code is no longer executable, but that, given time, the environment that the code runs in won't be there anymore. Hardware changes, OS's change, business practices and laws change, drilling down and down until one day, the whole thing stops. Which is why periodic software inventory reviews are a good idea, and why budgeting to keep things up to date is essential.

What's really bad when you're talking things like CORBA is that the presence of a CORBA server implies that there are also one or more CORBA clients teetering on the edge of breakdown (assuming that the CORBA code isn't now just a dead part of a larger app that has since stopped actually needing it). So when the day comes when that final band-aid pops off instead of sticking and the whole thing explodes, that even more frantic work is going to be required to get going again. And, of course you know what Murphy's Law says about when that will happen....

I wish you much luck. You've either got some real job security* or a very good reason to send out lots of résumés.

* In theory. Companies that cheap out on their software maintenance often lay off the only people who know whats in those old crumbling packages without checking to see if the survivors can fill the gap. Been there.
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Tim Holloway
Bartender
Posts: 19178
85
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would not attempt to force-merge a CORBA library into either Tomcat or the JRE. It should be placed in the WEB-INF/lib directory of whatever WAR needs it.

As far as I am aware, the most up-to-date CORBA implementation for Java is VisiBroker, which was originally developed by Borland, but lived on. Last known update was in 2011, though.

If your CORBA clients are Oracle and Lotus, Oracle probably has something newer that they'll be happy to gouge you for. And conversely, probably no longer support whatever you've been using.

Lotus I'm less certain of, since it hasn't been a big name in so long I'm not sure IBM even sells it (and if they do, they probably renamed it "WebSphere Notes" or something like that  )

Funny, though. I always felt that the Lotus data storage mechanism looked a lot like today's MongoDB.
 
Tommy Griffith
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Bartender
Posts: 19178
85
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to a quick check, that jar has only javax. and resources. packages. No org.anything, including org. omg. Which is what I expected.

It is the reference library for Java EE and should NEVER be included by a user in a Tomcat system, since Tomcat contains excerpts from that library (the parts that specify servlets and JSPs), and can therefore cause classpath and version collisions.

Also, it's an API library, so even if it had included CORBA classes, they'd be likewise CORBA API only and not the implementation classes. For that you do need something like VisiBroker.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!