January 14, 2019 at 8:47 pm #606865
I upgraded MyEclipse from 2017 to 2018 a few months back and now nothing I do can make our EAR deployment start on WAS 8.5.11 (tried every WAS upgrade too)
The web services EAR application is OK on WAS 7 but on WAS 8.5 I always get error ADMA0116W.
(I’m using Classic/Packaged options but have tried everything!)
Research I’ve done suggests it’s a java reflection class load problem of a different JAR version to what is expected.
The stack trace isn’t useful to determine the class.
The same application code works fine on the same WAS 8.5 server deploying from ME 2017.
The EAR application is a set of web services built under JAX-WS & JAX-WS.
It has a bit of Spring usage too but maybe not relevant.
I’ve set up both 2017 & 2018 with the same Maven & JVM configurations
Makes no difference what I try.
Note that the Jenkins built final artefact deployed manually to WAS 8.5 does start properly.
I want to move to Java 8 so will not have WAS 7 any more.
Looks like I’m staying on 2017 unless this problem has been solved.
Anyone have any ideas to try?
SteveJanuary 15, 2019 at 2:45 am #606872
Sorry that you are seeing this issue.
Can you please give us some more details to help us investigate further?
1. It is not clear what exactly you mean by the deployment does not start. Is the deployment itself failing or the deployed application does not run? Please clarify.
2. Are you seeing this problem only recently? Did this project ever work fine in MyEclipse 2018 post updating from MyEclipse 2017?
3. If you are seeing this problem only recently, then can you please let us know if there has been any changes to the MyEclipse IDE or the application or the WAS server (applied a fix patch,upgraded to latest version etc)
4. Is the WAS 8.5 configured to run with the IBM JDK? You can verify the same by double clicking on the WAS server entry in the Servers view to open the Overview page and then click on ‘Runtime Environment’ link and verify the configured JDK.
5. Please share with us the full stacktrace of the ADMA0116W error.
Apologies for inconvenience caused.
Genuitec SupportJanuary 15, 2019 at 2:45 pm #606909
There haven’t been changes to MyEclipse 2018 in the WAS deployment area, so seeing it fail in 2018 when it works in 2017 is surprising.
Just a couple of questions in addition to Swapna’s above:
Research I’ve done suggests it’s a java reflection class load problem of a different JAR version to what is expected
Can you share the name and version of the JAR involved?
7) MyEclipse 2018 runs with Java 10, while 2017 runs with Java 8. Of course, this should not matter much as your server should be starting with an IBM JDK (as Swapna asked in #4 above) but, being a major difference between 2018 and 2017, you might want to try running MyEclipse 2018 with a Java 8 JDK instead (you can use the VM from the
binaryfolder in your 2017 install) and see if that works. You need to change the
-vmargument in your
myeclipse.inifile to achieve this, please let us know if you need help.
8) brute-force idea is to export an EAR from MyEclipse 2017 and from 2018 using the File > Export > Java EE > EAR option, and then extract both EARs. If you do a file system diff over the extracted contents, it may be easy to spot a key difference, which will help us figure out what is going wrong.
Hope we’re able to get you deploying with 2018 in short order!January 16, 2019 at 12:02 am #606936
Clarification as requested:
1. The application deploys to WAS 8.5 successfully (classic/packaged options)
2. The application always fails to start under MyEclipse 2018 (never worked for 2018 but 2017 does)
3. MyEclipse 2018 deploys and starts the EAR OK on WAS 7
4. Building the EAR artefact outside of ME 2018 always results in a successful deployment & start on WAS 8.5
eg Manual installation of Jenkins build
5. See the attached the start-up error dump. It isn’t helpful to determine the jar causing the error (frameworks are wonderful!)
6. I tried running ME 2018 using the 2017 JVM but both javaw.exe and jvm.dll errored (but do run 2017)
7. I started ME 2018 using the WAS 8.5 JVM, it started but then gave me a security integrity alert and quit
Other 1.8 JVMs also fail
Attachments:You must be logged in to view attached files.January 16, 2019 at 4:36 am #606943
Thank you for the details. The error in the log points to a problem with default servlet mapping.
Caused by: com.ibm.ws.exception.RuntimeWarning: SRVE0303E: Servlet name for the servlet mapping /rest/* could not be found.
Similar issue is discussed here : https://stackoverflow.com/questions/43760975/was-8-5-5-9-cannot-start-webapplication-because-of-srve0303e
If you are still seeing the problem then please share with us the complete server log file, SystemOut.log which is located in your WAS server install directory :
WebSphere 8.5\profiles\profilename\logs\servername\SystemOut.log. You can change the extension on the file to .txt and attach it here to help us investigate further. Also please share with us your workspace log file which is located in your
Regarding the error when starting MyEclipse 2018 using 2017 JVM, it could be a result of trying to point to 32 bit JVM on a 64 bit version of MyEclipse 2018. Please point to a 64 bit version of Java 8 and check.
Genuitec SupportJanuary 17, 2019 at 12:26 am #606990
I downloaded Java 1.8 u201 x64 and now ME 2018 starts OK using that as VM.
No idea my the older x64 1.8 installation didn’t work.
Application now deploys and starts on WAS 8.5 so the java 10 does something incompatible but not for WAS 7.
The application code has 1.6 compliance set and uses the WAS 8.5 JVM in preferences.
I pulled both good/bad exported EARs off the WAS 8.5 server’s profile and had a play comparing files but it’s tedious unpacking all the different bits. (most bespoke top level jars are different)
Maven stuff seems to get rearranged so creates false differences, I haven’t delved too deeply as I ran out of time.
I also attached the two suggested log files.
Thanks for your suggestion on the JVM.
Attachments:You must be logged in to view attached files.January 17, 2019 at 3:38 am #607015
Glad that switching to Java 8 helps.
If you see any problems again with deployment, then please let us know.