I am developing an application for WebSphere 6.1 which uses a Java servlet. Within my servlet, I have defined a serial vesion ID of 1L. Upon deploying and running my application, I am receiving a LinkageError of the following type (from the server log):
[5/9/11 15:14:26:868 EDT] 0000001c WebApp
E [Servlet Error]-[ManageRecordsConsumerServlet]: java.lang.Exception:
java.lang.LinkageError: LinkageError while defining class:
<redacted>.docindexupdate.batch.servlet.ManageRecordsConsumerServlet
Could not be defined due to: (<redacted>/docindexupdate/batch/servlet
/ManageRecordsConsumerServlet) class name must be a string at offset=2074
This is often caused by having a class defined at multiple
locations within the classloader hierarchy. Other potential causes
include compiling against an older or newer version of the class
that has an incompatible method signature.
I'm not sure what the issue is. I was seeing this previously before defining a serial version uid and figured that by defining that and being consistent, future updates to the class file would run successfully. There are no errors during compilation or deployment to the server. Is it possible that an older version of the servlet is cached somewhere on the WebSphere instance (I am only deploying on my dev machine at the moment)?
The
class name must be a string at offset=2074
line is also confusing.
I am suspecting you have a jar that is being loaded in two different classloaders. By that I mean, your websphere server on startup loads that jar or has an endorsed directory with that jar. Also your EAR you are deploying has that jar in its lib. The two can conflict at runtime
What I would suggest is to find out which jar ManageRecordsConsumerServlet belongs to and either remove it from your EAR lib or your Websphere endorsed lib (best would be your EAR lib).
It may be versioning, but I don't thing so.
When two classes loaded by different classloader, a ClassNotFoundException is normally thrown.
When a class is passed over a wire/loaded from disk cache, VersionMismatchException is normally thrown.
When a class with different method signatures is used, NoSuchMethodError or alike is thrown.
I think this case is a corrupted class file. Could be corrupted in cache or in the JAR.
Related
When deploying a Springboot maven project(version 2.3.4.RELEASE) to an external Tomcat container,official guide says you need to mark the "spring-boot-starter-tomcat" dependency as provided ,but actually even if without doing that,the final war package which contains lib like "spring-boot-starter-tomcat","tomcat-embed-core" and "tomcat-embed-websocket" also works fine in tomcat8.5.54 or tomcat 9.0 ,so I am confused about that,"Do we really need set spring-boot-starter-tomcat as provided or not?" ,anyone could explains why?
"Traditional Deployment"
You don't want to have multiple versions of the same classes on the classpath. This can lead to many errors during runtime. For example, if you have a
public class MyServlet implements javax.servlet.Servlet
and you package both MyServlet.class and javax.servlet-api.jar (which contains javax.servlet.Servlet) into your application, you might get an error:
Servlet class MyServlet is not a javax.servlet.Servlet
What happens is: when the application classloader loads MyServlet, it looks for javax.servlet.Servlet in the application first and it finds it in javax.servlet-api.jar. The server compares this class with the one loaded by the server's classloader and concludes that they differ, since classes from different JARs are not equal. If the application is shipped without javax.servlet-api.jar this does not happen: the classloader does not find javax.servlet.Servlet in its own classpath, so it looks in the parent classloader.
Remark: This example can not actually be reproduced on Tomcat. Due probably to many incorrectly packaged applications the WebappClassLoader has an exception to the class loading rule: special classes such as those starting with javax.servlet or org.apache.tomcat are always loaded from the server's classloader (cf. the source code for a list of these exceptions).
TL;DR: due to the remark above, leaving spring-boot-starter-tomcat in the compile scope probably will do no harm, but it is a risk not worth taking.
I've deployed an application(EAR) on IBM WebSphere succesffully. When I hit the URL - "https://WAS-External-IP:PORT/ProjectName/OtherInfo/ServletName, I get the error:
Error 404: javax.servlet.UnavailableException: SRVE0200E: Servlet [ServletName]: Could not find required class - class ServletName : javax.servlet.ServletException: Project's Exception: com.sun.crypto.provider.SealedObjectForKeyProtector
From the post - identify whether is code running on app engine runtime (Java)
I figure that GAE runtime 1.9.23 has the fix for runtime whitelisting, which omitted one or more classes needed to load the JCEKS key store. However, I can't figure out where can I find the GAE runtime version in my WebSphere.
When the same code is run when Application is installed on a Windows box, I don't get this error.
When I looked at the trace logs, I get the error:
Caused by: java.lang.IllegalStateException: No implementation could be
SystemErr R at jarName.classname.methodName(className.java:LineNumber)
From debugging, I see the class-name string is not loaded in the classpath. However, when I checked the jars available in the path mentioned in the classpath, I can see the JAR is present there. The JAR is also present in the pom file of the project.
I'm not able to set debug points at static blocks of missing class to see what is going wrong.
Windows and Linux often return list of files in different order, which can lead to jars being added to the classpath in a different order. How can I make Linux read the missing JAR in the classpath the way Windows does?
Websphere 8.0.0.11
Hibernate 4.2.21.Final
I have found many questions about this same problem but none of them worked for me.
If I deploy the application in Websphere it works OK.
However we have defined a shared library that contains all the third party libraries (spring, hibernate, javassist, etc) so that our WARs are thinner.
This way during deployment we associate our thin WAR against that Websphere shared library.
The point is that when we deploy the application this way the ClassCastException Hibernate exception _$$_javassist_856 cannot be cast to javassist.util.proxy.Proxy is thrown.
I have checked the loaded jars in the websphere console and can only see one javassist jar (3.18.1-GA) in the classpath.
Why could this be happening?
UPDATE
I have also tried using PARENT_FIRST and PARENT_LAST class loading.
UPDATE 2
I just found out that Websphere is loading its own javassist jar:
URL location = ProxyFactory.class.getProtectionDomain().getCodeSource().getLocation();
logger.info("{}", location);
It prints: file:/opt/IBM/WebSphere/AppServer/plugins/javassist.jar
After trying pretty much everything I found on S.O. without any success I decided to downgrade Hibernate to version 4.1.12.Final. This is the maximum 4.x version compatible with Websphere 8.x.
The problem is that Javassist leaves traces in its generated code. With Javassist on the class path twice, its classes are loaded twice. Two types are however only equal if they have the same name and are loaded by the same class loader. In your case, the generated class resolves its Javassist dependeny to a type that is loaded by your application class loader while your code is casting the instance to the Javassist type that is loaded by the Websphere class loader (or the other way around).
Are you sharing any Hibernate dependencies between applications? Try to not use any shared libraries related to Hibernate in your application to avoid this.
I have two distinct archives within in the same .ear deployed on an application server. One is a .war and one is a .jar. I have the same package names in both archives
in .jar archive>> com.me.dummy.MyClass
in .war archive>> com.me.dummy.CLientClass
In com.me.dummy.MyClass I have a protected method called proctectedMethod() . In com.me.dummy.CLientClass i invoke com.me.dummy.MyClass.proctectedMethod().
This does not cause any compile time issues, but at runtime it throws accessError
java.lang.IllegalAccessError
Why does this only throw the IllegalAccessError at runtime?
Thanks
I believe that this happens because your application server loads web application using separate class loader. You should consult your app server documentation how to make it to use the same class loader for whole enterprise application.
I am trying to add metrics library to existing webservice on WAS 7. I am getting below error
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [AdminServlet]: com.yammer.metrics.reporting.AdminServlet was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime class path SRVE0234I
What are the other run-time dependencies required for metrics-servlet-2.2.0?
I have metrics-core-2.2.0.jar and metrics-servlet-2.2.0.jar in my WEB-INF\lib folder.
Threads, ping and healthcheck servlets work fine.
I think your missing some more required jars, are you not using maven or gradle for dependency management
Please refer here to know all required jars that metrics-servlet-2.2.0.jar depends on. http://mvnrepository.com/artifact/com.yammer.metrics/metrics-servlets/3.0.0-BETA1
My suggestion is, it is always difficult to maintain dependencies without Maven/Gradle or any other build tools :).