[stevebradford]

After the ME 2020 update I could no longer use Classic server deployment in Packaged mode on my WebSphere 8.5.5.4 (or when upgraded to 8.5.5.17)

It was possible to coax ME to use In-workspace/Exploded deployment but that could lock up the server on deployment at times.
I could also manually export the EAR and install it to WAS but if I just manually restarted WAS after ME did the packaged deploy it failed in the same manner (so is a deployment issue that shows up when starting the EAR).

I reverted to starting ME 2020 with the -VM command line start option pointing to ME 2019’s java 13 javaw.exe (2020 is java 14).
It also works using a java 8 JDK.

While I have a solution this issue should be addressed.
Here is the fragment of the application start up failure shown on the ME console:

Deployment/Restart Error:
=========================
…
[12/10/20 17:02:32:420 AEDT] 000000ec InstallSchedu I ADMA5013I: Application DHS CMDM Services Suite installed successfully.
[12/10/20 17:02:32:461 AEDT] 00000040 AdminHelper A ADMN1009I: An attempt is made to start the DHS CMDM Services Suite application.
[12/10/20 17:02:32:711 AEDT] 00000040 CompositionUn A WSVR0190I: Starting composition unit WebSphere:cuname=DHS CMDM Services Suite in BLA WebSphere:blaname=DHS CMDM Services Suite.
[12/10/20 17:02:32:899 AEDT] 00000040 ApplicationMg A WSVR0200I: Starting application: DHS CMDM Services Suite
[12/10/20 17:02:32:900 AEDT] 00000040 ApplicationMg A WSVR0204I: Application: DHS CMDM Services Suite Application build level: Unknown
[12/10/20 17:02:37:214 AEDT] 00000040 webapp E com.ibm.ws.wswebcontainer.webapp.WebAppConfigurationHelper constructServletMappings SRVE0303E: Servlet name for the servlet mapping /rest/* could not be found.
[12/10/20 17:02:37:216 AEDT] 00000040 DeployedAppli W WSVR0206E: Module, cmdm-services.war, of application, DHS CMDM Services Suite.ear/deployments/DHS CMDM Services Suite, failed to start
[12/10/20 17:02:37:217 AEDT] 00000040 ApplicationMg W WSVR0101W: An error occurred starting, DHS CMDM Services Suite
[12/10/20 17:02:37:217 AEDT] 00000040 ApplicationMg A WSVR0217I: Stopping application: DHS CMDM Services Suite
[12/10/20 17:02:37:222 AEDT] 00000040 ApplicationMg A WSVR0220I: Application stopped: DHS CMDM Services Suite
[12/10/20 17:02:37:223 AEDT] 00000040 CompositionUn E WSVR0194E: Composition unit WebSphere:cuname=DHS CMDM Services Suite in BLA WebSphere:blaname=DHS CMDM Services Suite failed to start.
[12/10/20 17:02:37:232 AEDT] 00000040 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\ffdc\server1_b61b1d43_20.10.12_17.02.37.224593770651134666644.txt com.ibm.ws.runtime.component.CompositionUnitMgrImpl 679
[12/10/20 17:02:37:254 AEDT] 00000040 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\ffdc\server1_b61b1d43_20.10.12_17.02.37.2351046664870816446531.txt com.ibm.ws.management.AdminServiceImpl.invoke 679
[12/10/20 17:02:37:260 AEDT] 00000040 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\ffdc\server1_b61b1d43_20.10.12_17.02.37.2568949601560805658852.txt com.ibm.ws.management.application.AppManagementImpl.startApplication 1501
[12/10/20 17:02:37:261 AEDT] 00000040 AppManagement W ADMA0116W: Unable to start: DHS CMDM Services Suite using: WebSphere:name=ApplicationManager,process=server1,platform=proxy,node=vm215176fcNode01,version=8.5.5.17,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=vm215176fcNode01Cell,spec=1.0 exception is: javax.management.MBeanException: Exception thrown in RequiredModelMBean while trying to invoke operation startApplication
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1306)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:1096)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1350)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1243)
at com.ibm.ws.management.application.AppManagementImpl._startApplication(AppManagementImpl.java:1483)
at com.ibm.ws.management.application.AppManagementImpl.startApplication(AppManagementImpl.java:1372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)

[Brian Fernandes]

Steve,

Thank you for the details, this worked just fine in our tests, but our team is testing further. Have a few questions so far:

1) Does classic deployment fail all the time or just sometimes?
2) Is the server correctly configured to start with the corresponding IBM JDK?
3) What compilation settings do you have in your project? Is it using the default workspace JRE (which could change if you change the VM used to start ME) or is it set to a specific JRE and Java version. If not using specific settings, could you specify the right Java version and see if that makes a difference?

[stevebradford]

Brian,
Here is the history of my issues, hopefully I haven’t muddled things too much as I tried so many fixes along the way!

When my IDE updated to ME 2020/Java14 I was running WebSphere 8.5.5.4 (java 6 embedded VM) for our services suite (Our product EAR has multiple JAX-WS and JAX-RS services as a java 6 build).

After the ME upgrade I could not deploy/start the EAR to the local server (Classic/Packaged).
Manual EAR export/deployment was OK but manually starting the EAR after ME deployment was not (see log failure fragment on ME’s console above).

I started ME with the –VM using jdk1.8.0_261 (not ME’s java 14) and deployment worked again.
Also works using ME 2019’s java 13.

As we were moving to update the EAR’s code base to java 8 I upgraded WAS to 8.5.5.14 (java 8 VM).
ME couldn’t now start the VM server but running a WAS java 7 VM was OK.

Reinstalled WAS to 8.5.5.17 (java 8 VM) no different.
I found the workaround for the server start issue here.

So running ME under <= java 13 was OK for java 8 WAS deployments but the 2020 java 14 issue remained so I registered this post.

Running ME 2020 Under Java 14: (ie clean ME 2020 install)
===========================
I’ve attached some logs from when ME fails to deploy/start, SystemOut.log seems to be complaining about our primary REST context not being defined suggesting something wrong with JAX-RS deployment.

In answer to your questions:
1. Classic/Packaged deployments won’t start (REST error), Classic/Exploded deployments may start but only after the ME’s deploy/restart hangs and you have to restart the server.
(But In-workspace/Exploded deployments do work!)

2. The WAS 8.5.5.17 server is running its standard embedded java 8 for the server VM.

3. ME java compilation (ME JRE and Maven) is using jdk1.8.0_261 but it makes no difference if I use other java installations. Java compilation level is 1.8 (but application start fails on 1.6/1.7 too)
WAS 8.5.5.17 has been clean installed with defaults (see native_stdout.log).

Attachments:

You must be logged in to view attached files.

[Brian Fernandes]

Steve,

Thank you for sending in extensive details. We’ve been trying to replicate this locally but have not been able to do so – deployment just went through smoothly, always. Of course, I realize there are many more variables at work here though.

1)

I’ve attached some logs from when ME fails to deploy/start, SystemOut.log seems to be complaining about our primary REST context not being defined suggesting something wrong with JAX-RS deployment.

Is this always the failure for you when classic fails? i.e. the same problem you had the last time?

2) When you deploy, can you look at the target of the deployment (the server location the files are copied to) to see if something is awry? Could any classes be missing? Do check the Deployment Assembly of the project as well. (look for this page under Project Properties)

3) Can you try deploying to a new profile?

4) Would you be able to create a smaller version of the project in which the problem can be replicated and send that to us? If not, can you share with us your project’s Java EE metadata? (web.xml, application.xml, etc.) as well as the files in the .settings folder, and the .project file? We can use that to try and replicate as closely as possible.

[Author]

Posts