I´m trying to deploy a war that connects to CISC into a Websphere Liberty Profile app server 8.5.5. It works perfectly in WAS, however there is a feature missing but I don´t know which.
java.lang.ClassNotFoundException: com.ibm.etools.marshall.util.ConversionUtils
at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonLibraryClassLoaders(AppClassLoader.java:504)
at com.ibm.ws.classloading.internal.AppClassLoader.findClass(AppClassLoader.java:276)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:941)
at java.lang.ClassLoader.loadClass(ClassLoader.java:876)
at com.ibm.ws.classloading.internal.AppClassLoader.findOrDelegateLoadClass(AppClassLoader.java:482)
at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppClassLoader.java:443)
at java.lang.ClassLoader.loadClass(ClassLoader.java:846)
It looks like you are missing the "Record" class from the development tools (such as Rational Application Developer). In Liberty these classes are not bundled with the runtime and need to be imported. The instructions are here:
https://www.ibm.com/support/knowledgecenter/en/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/twlp_dat_radrecdata.html
This includes the conversion utils that your stack trace is showing.
Related
I have a web application that used to run fine on many web servers (tomcat, jboss, weblogic and websphere). Now, however, it has an error when deploying on WebSphere 9.
The app contains the jar javax.transaction-api-1.2. Some of its classes, e.g., javax.transaction.xa.XAResource, are also included in Java SE, but not all of them. Some are specific to Java EE and are required by some 3rd-party libraries in my app. The app is always deploying with child-first (parent-last) classloader.
WebSphere 9 throws this error during startup when the app tries to load the Oracle JDBC driver:
java.lang.LinkageError: loading constraint violation: loader "com/ibm/ws/classloader/CompoundClassLoader#7157be44" previously initiated loading for a different type with name
"javax/transaction/xa/XAResource" defined by loader "com/ibm/oti/vm/BootstrapClassLoader#422c7b1b"
Note that we aren't actually using XA transactions in the app, we are using regular transactions.
On other servers, and previous versions of WebSphere, it was never a problem. The server didn't care that we load XAResource from inside the war, even if it was previously loaded somewhere in the server. Now WebSphere 9 is different, it says that the app classloader already loaded this class from the server, but I don't know why or when did this happen.
Any idea how to solve this?
Remove the transaction API from your application. JTA 1.2 is already included in the server and provides no value in your applications. It's always risky to bring Java EE/SE APIs in a parent-last class loader unless you are 100% certain that they are technically necessary, because they can lead to issues like this one.
I can't say how this worked in previous server versions (there have been some Java-level changes in enforcing linkage issues like this), but the solution is reasonably straightforward.
At the end we did two things to solve this problem.
1) We upgraded the jta jar to version 1.3 (link here). This jar solves the problem by avoiding duplicate classes - it contains only J2EE classes and omits the J2SE classes that are already included in the JVM.
2) We upgraded WebSphere server from 9.0.0.7 to 9.0.0.11.
At the time, I suspected just upgrading the jar should suffice, but our QA had some issues with it and they also upgraded the server. Due to lack of time, we didn't investigate it further and just decided to do both.
I currently have an environment where I am trying to get a Liberty Profile v8.5.5.9(using Java 7) to utilize a WebSphere MQ v9.0.3(using Java 8). These two are on the same box, the server.xml is configured correctly, but I'm getting a namespace error when I'm trying to do a direct client connection.
I'm just trying to rule out if there's a problem using these two versions together that would cause a JNDI problem.
There apparently is a conflict between the two environments. Once I removed 9.0.3 and installed 7.5(MQ) it now works.
I started using WAS Liberty 8.5 in my eclipse,when i try to deploy an application I am getting this error.
Caused by: java.lang.NoClassDefFoundError: com/ibm/CORBA/iiop/ORB
I found that its due to the WAS runtime jar ibmorb.jar provided with WAS server install.
I dont know how to configure in WAS Liberty profile.Any clues.
Even i mentioned in the library path,but still error getting.
<variable name="DRIVER_PATH" value="C:\NovemberR2\DMS\deploy\lib"/>
<library id="db2Lib">
<fileset dir="${DRIVER_PATH}" includes="com.ibm.ws.orb_8.5.0.jar classes12.jar oracleJDBC.jar ojdbc6.jar ojdbc14.jar ibmorbapi.jar ibmorb.jar"/>
</library>
The stacktrace is --->
here is the stack trace. ...` 61 more
Caused by: java.lang.NoClassDefFoundError: com/ibm/CORBA/iiop/ORB
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getMethod0(Class.java:2685)
at java.lang.Class.getMethod(Class.java:1620)
at com.ibm.ws.naming.util.Helpers.getInitORBMethodForNonApplet(Helpers.java:411)
at com.ibm.ws.naming.util.Helpers.getOrb(Helpers.java:390)
at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:462)
at com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:128)
orSourcesPropertyResolver.java:84)
at org.springframework.core.env.PropertySourcesPropertyResolver.getProperty(PropertySourcesPropertyResolver.java:60)
at org.springframework.core.env.AbstractEnvironment.getProperty(AbstractEnvironment.java:511)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$1.getProperty(PropertySourcesPlaceholderConfigurer.java:135)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$1.getProperty(PropertySourcesPlaceholderConfigurer.java:132)
at org.springframework.core.env.PropertySourcesPropertyResolver.getProperty(PropertySourcesPropertyResolver.java:84)
at org.springframework.core.env.PropertySourcesPropertyResolver.getPropertyAsRawString(PropertySourcesPropertyResolver.java:70)
at org.springframework.core.env.AbstractPropertyResolver$1.resolvePlaceholder(AbstractPropertyResolver.java:207)
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:147)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:204)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:178)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$2.resolveStringValue(PropertySourcesPlaceholderConfigurer.java:175)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:801)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:962)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:949)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:533)
... 63 more
Thanks for the hints,but i used to run this application well in WAS 8.0 server and IBM WAS JDK provide in built and i started migration to WAS 8.5 using liberty profile thought of experimenting it.
Hope this answer would be helpful to others as it may be too late!
Try adding com.ibm.ws.orb_8.5.0.jar in the class path. This jar will be available under <WAS_HOME>\AppServer\runtimes . This will resolve the issue.
The issue here looks like you are using the JDK provided with WAS traditional to run a Liberty server.
The JDK that comes with WAS traditional is going to have extra stuff in it that is specifically for running with WAS traditional (it does not not support pluggable JDKs).
Instead:
Use a standard JDK to run your Liberty server. You can get a standard JDK from IBM (not the one that comes with WAS traditional), Oracle, or OpenJDK.
The question states that the application worked correctly on WAS 8.0. With WAS 8.5, you are now trying to run the same application on the Liberty Profile. The Liberty profile supports a subset of the functionality of the traditional WAS profile (now termed 'full profile').
As user #aguibert mentioned in their answer, you have to provide the Java runtime environment for the Liberty profile. This can be any compliant Java SE 6/7/8 JRE/JDK*. For the full profile, a different JDK is required; this is bundled with the installation package. This WebSphere JDK should contain the ibmorb.jar file.
Therefore, try running your application using the WAS 8.5 full profile. This should resolve the problem. You can also consider migrating to the latest version of WAS, which is v9.0.
Additional resource at IBM Knowledge Center: Liberty profile overview.
*Subject to minimum supported Java levels.
I am developing a simple java program in CICS Explorer to connect to DB2 on mainframe.
Using the plug-in development option in CICS Explorer, I have converted the DB2 jars as plug-ins,deployed them and added the deployed plugins in the JVM profile OSGi Bundles option .I have also added the same in the LIBPATH option in JVMProfile and in the CICS Explorer target platform.
But on deploying the bundle in CICS , I am getting the error :
Error msg : No Suitable driver
SQLSTATE : 08001
Error code : 0
Kindly help me trace the issue
If you're having to convert the DB2 JARs into OSGi bundles it's likely that you've not got the requisite APARs applied. If you use the JARs that are provided with the following APARs:
PM36832
PM36838
then they are already OSGi bundles, plus, they also register the DB2 Driver automatically - avoiding the 'No Suitable driver' problem.
From developer viewpoint, what is diference between WebSphere Application Server(1.5GB) installed by Installation Manager and WebSphere Application Server V8.5 Liberty Profile (65 MB)? I will develop an application based on EJB, JSF and JPA. According to my search, Liberty Profile is an easy way to start develop with Websphere. I would appreciate any comment because I am in charge of preparing the workstations for a team and it is my first time to heard about Liberty Profile. I guess that Liberty Profile must be a smaller Web Server similiar to Tomcat plus EJB support and without Console Administration.
The key difference between WAS Liberty and WAS Classic boil down to the following: Java EE 7 support and Legacy app support
WebSphere Liberty supports Java EE 7 as of 8.5.5.6, WAS classic does not. WAS 9.0 supports Java EE 7
WAS Liberty does not support some of the older apps that have now been deprecated in the Java EE API such as JAX-RPC.
If you inherited an old application that takes advantage of WebSphere specific extensions you're generally bound to WAS Classic
Existing administrative and deployment scripts would not likely work on WAS Liberty
Network Deployment support is not as robust in WAS Liberty
However, if you are doing a new app it isn't too bad and you can pay for support for it without having to redeploy to something new unlike Glassfish or WildFly. There's a 2GB limit for production on the organization level, but you can have unlimited development instances. From what I can tell this is based on the honor system.
The following article documents at a high level the differences
https://developer.ibm.com/wasdev/docs/was-classic-or-was-liberty-how-to-choose/
The white paper also referenced by the article details each difference
http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/documentation/ChoosingWASClassicorWASLiberty.pdf
The WebSphere Application Server chief architect has a blog post entitled Liberty Archive Install and Installation Manager that compares the two approaches.
There is also a side-by-side comparison on page 9 of the IBM WebSphere Application Server V8.5.5 Packaging Highlights document.
You can take a look at this Redbook http://www.redbooks.ibm.com/abstracts/sg248076.html?Open particularly chapter 1 "An introduction to the Liberty profile" to learn more about Liberty Profile.
As for the programming models supported (which you can check on the same chapter), depending on the exact versions of EJB, JSF and JPA you need to work with, Liberty could, our could not be a fit for development. Also, in the same chapter you can read about the compatibility between Liberty Profile and the full Profile.
You can find also this post helpful https://www.ibmdw.net/wasdev/2013/05/20/alasdair_nottingham_talks_about_what_makes_liberty_different/