Gen EJB Web Service runtimes as WebSphere shared library
Article ID: 205270
Updated On:
Products
Issue/Introduction
When running the Assemble step for either just a default EJB Web Service or combined EJB Web Service and Custom Web Service, the option "Package runtime in EAR" which includes the Gen runtime .jar file in the resulting .ear file should normally be selected to avoid potential install/deployment and execution problems. However, if it is required to deploy a single (maybe customised) version of the Gen runtime .jar file for all applications and not include it in the .ear file, then a workaround is possible per details below.
Environment
Release: Gen 8.5, 8.6
Component: Gen EJB Web Services
Application Server: WebSphere Application Server (WAS) 9.0.
Resolution
Background:
The Custom Web Service is dependent on the default EJB Web Service and will not function without it. That requirement is enforced during the Assemble step where the Custom Web Service can only be assembled if the default EJB Web Service is also selected with it. So the only 2 options are are to install the EJB Web Service on its own or install both the EJB Web Service with the Custom Web Service i.e. the Custom Web Service cannot be installed on its own.
Package runtime in EAR
If "Package runtime in EAR" is not selected then the Gen runtime .jar file (genrt.jar for Gen 8.6 or genrt.85.jar for Gen 8.5) will not be included in the resulting .ear file and this will cause problems when that file is installed on WAS because the runtime classes are needed to create the WSDL.
Symptoms observed
a. When running the Assemble step for just the default EJB Web Service the application will appear to install/deploy successfully but under the Admin Console, the application "Web Services Properties" section will not exist, and thus the EJB Web Service is not available.
b. When running the Assemble step for both the default EJB Web Service and a Custom Web Service the application will again appear to install successfully but under the Admin Console the Application "Web Services Properties" > "Service providers" section will contain an entry for the Custom Web Service but be missing the entry for the default Web Service (<Server_Manager>.jar), so again the EJB Web Service is not available. The Custom Web Service requires the default EJB Web Service to be both installed and working successfully for the Custom Web Service to be able to run.
During either of the above, the WAS SystemOut.log file will show messages WSWS7054E and WSWS7027E because the JAX-WS WSDL and Service Descriptions fail to be built due to the missing runtime class com.ca.gen85.vwrt.IImportView (8.5) or com.ca.gen.vwrt.IImportView (8.6). For example for Gen 8.6:
===
[1/7/21 16:55:20:449 PST] 000001ce InstallSchedu I ADMA5016I: Installation of LYNNWST started.
[1/7/21 16:56:00:692 PST] 000001ce WASWSDLGenera E WSWS7054E: The Web Services Description Language (WSDL) file could not be generated for the lynnwst.PSTEP1_Bean Web service implementation class because of the following error: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
[1/7/21 16:56:00:693 PST] 000001ce WSModuleDescr E WSWS7027E: JAX-WS Service Descriptions could not be correctly built because of the following error: javax.xml.ws.WebServiceException: WSWS7054E: The Web Services Description Language (WSDL) file could not be generated for the lynnwst.PSTEP1_Bean Web service implementation class because of the following error: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
at com.ibm.ws.websvcs.wsdl.WASWSDLGenerator.generateWsdl(WASWSDLGenerator.java:299)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.generateWSDL(EndpointDescriptionImpl.java:2102)
...
Caused by: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
at java.lang.J9VMInternals.prepareClassImpl(Native Method)
...
Caused by: java.lang.ClassNotFoundException: com.ca.gen.vwrt.IImportView
at java.net.URLClassLoader.findClass(URLClassLoader.java:607)
...
[1/7/21 16:56:01:138 PST] 000001ce InstallSchedu I ADMA5013I: Application LYNNWST installed successfully.
[1/7/21 16:56:10:957 PST] 00000178 WASWSDLGenera E WSWS7054E: The Web Services Description Language (WSDL) file could not be generated for the lynnwst.PSTEP1_Bean Web service implementation class because of the following error: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
[1/7/21 16:56:10:957 PST] 00000178 WSModuleDescr E WSWS7027E: JAX-WS Service Descriptions could not be correctly built because of the following error: javax.xml.ws.WebServiceException: WSWS7054E: The Web Services Description Language (WSDL) file could not be generated for the lynnwst.PSTEP1_Bean Web service implementation class because of the following error: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
at com.ibm.ws.websvcs.wsdl.WASWSDLGenerator.generateWsdl(WASWSDLGenerator.java:299)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.generateWSDL(EndpointDescriptionImpl.java:2102)
...
Caused by: java.lang.NoClassDefFoundError: com.ca.gen.vwrt.IImportView
at java.lang.J9VMInternals.prepareClassImpl(Native Method)
...
Caused by: java.lang.ClassNotFoundException: com.ca.gen.vwrt.IImportView
at java.net.URLClassLoader.findClass(URLClassLoader.java:607)
...
[1/7/21 16:56:10:985 PST] 00000178 AppBinaryProc I ADMA7021I: Distribution of application LYNNWST completed successfully.
===
Gen runtime .far file as a Websphere shared library:
A WAS shared library can be created for the Gen runtime .jar file to find the runtime classes at execution time as follows:
a. Create the shared library using steps here: WebSphere Application Server traditional 9.0.5.x > WebSphere Application Server (Distributed and IBM i), Version 9.0 > Setting up the application serving environment > Administering application servers > Managing shared libraries > Creating shared libraries
b. EITHER: Add the shared library to a new Server level Class Loader which is then used by all Applications after WAS restart (WebSphere Application Server traditional 9.0.5.x > WebSphere Application Server (Distributed and IBM i), Version 9.0 > Setting up the application serving environment > Administering application servers > Managing shared libraries > Associating shared libraries with servers)
OR: Using the Detailed option at install time, assign the shared library to the specific application.
However, that shared library still does not get used at install time and therefore does not resolve the WSWS7054E and WSWS7027E errors.
Solution
After further research it was discovered that the classpath used by the WAS wsgen tool can be dynamically changed by creating a custom property under "Java and Process Management > Process Definition > Java Virtual Machine > Custom Properties". The property name is:
com.ibm.websphere.webservices.WSDL_Generation_Extra_ClassPath
Its value should be assigned to the full PATH of the genrt.jar or genrt.85.jar file.
WebSphere Application Server traditional 9.0.5.x >WebSphere Application Server (Distributed and IBM i), Version 9.0 > Developing applications > Developing web services > Developing JAX-WS web services (bottom up) > Generating Java artifacts for JAX-WS applications
WebSphere Application Server traditional 9.0.5.x >WebSphere Application Server (Distributed and IBM i), Version 9.0 > Setting up the application serving environment > Administering application servers > Configuring the JVM > Java virtual machine custom properties > com.ibm.websphere.webservices.WSDL_Generation_Extra_ClassPath
For example, to be able to install both Gen 8.5 and 8.6 EJB Web Services add both runtime jar files to the custom property:
NOTE 1: A forward slash (/) can be used as the file path separator irrespective of the Operating System that WAS is running under. That is the general best practice advice for WAS e.g.:
WebSphere Application Server traditional 9.0.5.x > WebSphere Application Server (Distributed and IBM i), Version 9.0 > Administering applications and their environment > Deploying and administering enterprise applications > Installing enterprise application files with the console > Console pages to configure application installations > Select installation options settings
Restart WAS to pick up the new property which can be verified by viewing the verbosegc.log in the server logs directory e.g. "C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1".
The EJB Web Service then installs successfully and the application "Web Services Properties" > "Service providers" section shows the default EJB Web Service, so the JAX-WS WSDL and Service Descriptions are built successfully and there are no WSWS7054E and WSWS7027E errors in the SystemOut.log file:
===
[1/7/21 18:14:06:210 PST] 00000192 InstallSchedu I ADMA5016I: Installation of LYNNWST started.
[1/7/21 18:14:50:844 PST] 00000192 WebContainer I com.ibm.ws.webcontainer.internal.WebContainer addExtensionFactory SRVE0239I: Extension Factory [class com.ibm.ws.soa.sca.web.extension.SCAWebExtensionFactory] was registered successfully.
[1/7/21 18:14:50:845 PST] 00000192 WebContainer I com.ibm.ws.webcontainer.internal.WebContainer addExtensionFactory SRVE0240I: Extension Factory [class com.ibm.ws.soa.sca.web.extension.SCAWebExtensionFactory] has been associated with patterns [""].
[1/7/21 18:14:50:862 PST] 00000192 WebSphereSCAS I Added Servlet mapping: /dojo
[1/7/21 18:14:50:862 PST] 00000192 WebSphereSCAS I Added Servlet mapping: /dojo
[1/7/21 18:14:50:862 PST] 00000192 WebSphereSCAS I Added Servlet mapping: /tuscany
[1/7/21 18:14:50:862 PST] 00000192 WebSphereSCAS I Added Servlet mapping: /tuscany
[1/7/21 18:14:51:509 PST] 00000192 InstallSchedu I ADMA5013I: Application LYNNWST installed successfully.
[1/7/21 18:16:11:158 PST] 0000018c AppBinaryProc I ADMA7021I: Distribution of application LYNNWST completed successfully.
===
NOTE 2:
The above advice is valid for WebSphere Application Server in standalone mode.
It was later discovered that the required changes are different when running WebSphere Application Server Network Deployment and using a deployment manager with nodeagent to manage the individual servers.
In that environment the com.ibm.websphere.webservices.WSDL_Generation_Extra_ClassPath needs to be set both on the deployment manager and nodegent JVM Custom Properties for the installation and startup of the web service to be 100% successful. The property does not need to be set on the server that will be running the application.
Just setting the property on the deployment manager will appear to install the web service successfully i.e. the application "Web Services Properties" section will be created but when the application is started the web service listener will not start and any attempt to do so will show message "The specified application module does not contain any web service."
The required changes can be made under the Admin Console " System administration" sections for "Deployment manager" and "Node agents".
Both deployment manager and nodeagent need to be restarted after the changes are made. The presence of the new property can be verified for each in the verbosegc.log file located in the relevant logs directory e.g.
"C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\logs\dmgr"
"C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\nodeagent".
At runtime, the corresponding shared library previously created for C:/genrt.jar or C:/genrt.85.jar is then used to resolve the required runtime classes.
Additional Information
The alternative option to all the above is that the "Package runtime in EAR" option could always be selected during the Assemble of Gen EJB Web Services or Custom Web Services and if it is required to use a custom version of the Gen java runtime .far file then after the Assemble step the .ear file can have its Gen runtime .jar replaced with the custom version before installation on the Application Server.
Other related KB articles:
Gen EJB Web Service runtimes as a JBoss EAP global module
URL formats for Default & Custom Gen EJB Web Service
Documentation link:
Gen™ 8.6 > Developing > Designing > Use Gen Studio > Create Custom Proxies and Web Services > Use Custom Web Services
ADDITIONAL NOTE:
For deployment of a Custom Web Service to WebSphere 9.x with the Gen runtime jar included, there is a known problem where the application appears to install successfully but the WSDL document for the default EJB Web Service is not created. The custom property com.ibm.websphere.webservices.WSDL_Generation_Extra_ClassPath used in this KB also resolves that problem so the below documented workaround for changing the Server_Manager.jar MANIFEST.MF file is not needed any more. That is irrespective of whether the .ear file is assembled with or without the Gen runtime .jar file.
Gen™ 8.6 >Technical Requirements > Third Party Software Version > Application Servers
For further details see KB article:
WebSphere 9 install of CA Gen Custom Web Service fails to create WSDL
Feedback
