Error opening Administrator with 4.3.0 or later — exception from setRhinoLanguageVersion #6132
Replies: 7 comments 1 reply
-
did you do a diff and merge on the mirth.properties file? |
Beta Was this translation helpful? Give feedback.
-
It sounds like the upgrade isn't replacing something correctly or is leaving an old version of the rhino JAR on the file system. The code signing certificate used to sign the JARs changed in 4.3.0. Check that |
Beta Was this translation helpful? Give feedback.
-
Actually, I was just poking around some more... I found an old file in the custom-lib folder named "tika-app-1.12.jar" which does have some org.mozilla classes inside, so I am wondering if it is creating a conflict (by not being signed with the same cert as other Mirth JARs). I'm going to see if I can just remove it without causing a problem, I don't think that we would be actually using it for anything. I will also check on the JARs that you mentioned @ab-mg-23, thank you. [Edit] |
Beta Was this translation helpful? Give feedback.
-
OK, I noticed that there are many duplicate libraries (with different version numbers) in the client-lib folder. This is from a 4.2.0 install. Should I clean this up? I guess I can do a "clean" 4.2.0 install and see what is "supposed" to be there.
|
Beta Was this translation helpful? Give feedback.
-
I'd probably backup up the mirth install dir (e.g. c:\program files\Mirth... and wherever appdata is), completely remove mirth (and then delete the mirth install dir), then re-install and merge a small subset as files as needed. e.g. stuff in the old appdata folder (e.g. configuration.propeties, keystore.jks and server.id), and mirth.properties. If there is currently stuff in custom-lib I would not restore that rather move it to Setting..Resorces being mindful of the far right columns. This all assumes your mirth database is NOT Derby. My intitial response was a concern over this line in mirth.properties |
Beta Was this translation helpful? Give feedback.
-
OK. Here's what I did. I did a new Mirth Connect 4.2.0 install on a different system. Then, on the "problem" system, I shut down the Mirth service and moved out the folders "client-lib", "extensions", and "server-lib". I replaced them with the same folders taken from the system where I did the new install (effectively cleaning out the duplicate/old libraries noted above). Then I fired up the Mirth service again and confirmed that everything was up and running normally. I then did a database backup and VM snapshot and attempted again the upgrade to 4.3.0. All good this time! I am thinking the upgrade to 4.5.0 will also be fine since I got hung up on the same error last time I tried that; I'll post back if that is not the case. No idea why the installer did not clean up these old libraries on its own, or even which version of the installer made the mess (seems like it must have been messed up already when I was on 3.10), but now I know what to check for if something like this happens again. I did not end up having to mess with anything in custom-lib. I will look into moving those to Resources as @pacmano1 suggested. Thanks to both of you for the feedback. |
Beta Was this translation helpful? Give feedback.
-
Also thanks to @pacmano1 for this snippet, right after upgrading to 4.5.0 I noticed that I have one stubborn SFTP server that I need to talk to that doesn't support anything "better" than ssh-rsa. |
Beta Was this translation helpful? Give feedback.
-
Trying to upgrade an ancient instance of Mirth Connect. It was running 3.10.0. I went straight to the latest 4.5.0. The server started up fine but I was unable to connect using the administrator tool, it gave me the error "There was an error connecting to the server at the specified address. Please verify that the server is up and running." (The server was up and running, and I could hit the web site on port 8080/8443 where you can download the admin tool.)
So, I backed up to 3.10.0, which involved a database restore as well to undo the schema upgrade.
I then went forward one version at a time to figure out where it breaks. I got up to 4.2.0 working, and 4.3.0 breaks.
Here's the details on the admin tool error:
The Mirth Connect Administrator tool tries to go through the login process after I enter my credentials. It gets up to "Loading extensions...", sits there for a few minutes, and then comes back to the credential entry screen with the error (above) that shows right below the username and password fields.
I opened the Java console and it shows a stack trace at the same time that the error appears.
(The stuff from SLF4J is irrelevant, I think; it shows up well before the error appears and it is even there on my "working" instances.)
I looked in the logs on the server side and there is no indication of trouble. Mirth Connect appears to start normally and channels seem to be working fine. I just can't get into the admin tool.
Any ideas? I can't find anywhere where someone is complaining about an exception involving "setRhinoLanguageVersion".
[Edit]
Just noticed the bit further down in the exception stack trace which seems to be the crux of the problem.
Caused by: java.lang.SecurityException: class "org.mozilla.javascript.NativeBoolean"'s signer information does not match signer information of other classes in the same package
Beta Was this translation helpful? Give feedback.
All reactions