Im getting a weird error when running my spring2.5.6,jpa(hibernate3.4) webapp in weblogic 10.3
[ERROR] Javassist Enhancement failed: com.xxx.domain.model.Scheme
java.lang.NoSuchMethodError: pcGetManagedFieldCount
at com.xxx.domain.model.Fund.<clinit>(Fund.java)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAc
cessorFactory.java:25)
The com.xxx.domain.model.Scheme class is a mapped subclass entity of the abstract fund entity on a single_table inheritance hierarchy, and I'm getting this error for all entities on the hierarchy. I'm using both annotated classes and xml metadata to define the mappings for my persistence classes.
I only get this error when the app is deployed to weblogic, so everything runs fine using junit. I have tried upgrading to the latest version on javaassit.jar.
Problem Looks to me like an issue with classloading order, but I cant figure it out.
PS. As suggested by bea I have added the following to the weblogic.xml
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Anyone got any ideas, other config tips, or directions I should take my investigation?
I had the same problem.
My entities extended a class (#MappedSuperClass) which lived inside a jar dependency. I had to move that class from the jar into my project. Only then it would work and deployed fine.
Also another way to solve this is to specify your entities explicitly in the persistence.xml
I'm sorry, I only have WebLogic 10.0 on my machine, and it doesn't have any javassist JARs in the distro. Looks like javassist was only added in 10.3 for AOP byte code generation.
It might be worth a try to remove the javassist JAR from your WebLogic deployment and use the version that it supports. Take the "prefer-web-inf-classes" tag out of your web.xml and see if it can work with the version that WebLogic prefers.
Can you post the code for the entity class and, if you're not using annotations, the segment of your hbm mapping file?
Your classpath hunch may be right on. In your weblogic-application.xml, try this
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>org.antlr.*</package-name>
</prefer-application-packages>
If you have any more log output, please post that as well.
I just lost a couple of days on this myself. The problem for me was that I 2 separate data-services modules in my app. I'm thinking 10.3 has some trouble with that. I'm not sure of the solution, but a work around for me was to combine both of my data-services modules into just one.
BEA seems to be aware of this issue. Hopefully the URL below will help. Reference CR370788.
http://edocs.bea.com/wls/docs103/issues/known_resolved.html
Related
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 some Java code that is currently packaged in the BEA Workshop for WebLogic Platform.
My task is to migrate the structure of the project (without actually touching the code) to a maven structure to be packaged from command line (or from eclipse m2e).
Problem is, the code has some annotations like this:
#WebService(serviceName = "Cancelacion", targetNamespace =
"http://www.banamex.com.mx/OtorgamientoPension/cancelacion")
#WLHttpTransport(contextPath = "OtorgamientoPension", serviceUri =
"cancelacion", portName = "cancelacionSOAP")
#Policies({
#Policy(uri="policy:Wssp1.2-Wss1.0-X509-Basic256.xml", direction = Policy.Direction.inbound),
})
public class CancelacionPortImpl implements CancelacionPort {
...
}
That create some configuration inside the war (a mysterious meta-inf inside the web-inf and plenty of xml).
Please notice the #Policies which is from a WebLogic library. It creates some security-related config and that's (alongside the ws stuff) is what i want to generate.
Is there a way to process this from maven?
EDIT
So far I have tried with the weblogic-maven-plugin. It didn't work (also, due to internal policies, the not-so-straightforward way of installing this plugin is not an option).
I'm trying to find a vague reference a co-worker gave me about certain "jtools" compiler... but can't find anything that comes with that name and have some relation with WebLogic.
So the #Policies annotation is still a problem.
Right now I'm looking for a eclipse-plugin that does this, based on the premise that was the IDE who process that annotations.
For the wsdl issue, I find out that the namespace definition whas wrong. I corrected it and now it's working. I used the jaxb2-maven-plugin because I have no knowledge of jaxws-maven-plugin and I already had the config of the former.
Looks like you might need some Weblogic classes on your classpath. Short of uploading these to your own private Maven repository, you might consider checking out the Oracle Maven repository to find the Weblogic artifacts you need. Since these are likely container-provided jars (i.e. you don't need to package them in your war), you'll want to define them with a scope of "provided" in your dependencies, e.g. <scope>provided</scope>.
We are integrating an internal framework into our weblogic application and we are running into deployment problems.
Technologies Used
Weblogic 10.3.6 application
Spring 3.0
Maven 2
Eclipse J2EE
The Problem
On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the org.joda.time (2.0) jar.
Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
. . . excluded . . .
Things We Have Tried
After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.
Googling "NoSuchMethodError" usually gave JAR hell solutions.
Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.
.war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files
One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.
Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.
Questions:
Can anyone explain why the method could not be found?
Are there more places to check for existing or conflicting jars?
Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?
Here's some interesting reading:
prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a
element (a sub-element of the
element). By default, this element is set to
False. Setting this element to True subverts the classloader
delegation model so that class definitions from the Web application
are loaded in preference to class definitions in higher-level
classloaders. This allows a Web application to use its own version of
a third-party class, which might also be part of WebLogic Server. See
“weblogic.xml Deployment Descriptor Elements.”
taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html
Other troubleshooting tips:
You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.
An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.
--whereis.jsp --
<%# page import="java.security.*" %>
<%# page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>
You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial
A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.
Weblogic is pulling the org.joda jar.
Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.
The below is from my application, you can have a look what all we have to removed for our application.
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.slf4j.helpers.*</wls:package-name>
<wls:package-name>org.slf4j.impl.*</wls:package-name>
<wls:package-name>org.slf4j.spi.*</wls:package-name>
<wls:package-name>org.hibernate.*</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.xmlbeans.*</wls:package-name>
<wls:package-name>javassist.*</wls:package-name>
<wls:package-name>org.joda.*</wls:package-name>
<wls:package-name>javax.xml.bind.*</wls:package-name>
<wls:package-name>com.sun.xml.bind.*</wls:package-name>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
</wls:prefer-application-packages>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
This should be a very easy question but I am not able to get this fixed. I have 2 import statements and in Netbeans it does not show any error but when I run the project, I am getting a ClassnotFoundDef error
<%# page import="mastertables.BranchMaster, mastertables.CreateBranchMaster"%>
both the classes are in the same package. The error is
javax.servlet.ServletException: java.lang.NoClassDefFoundError:org/hibernate/HibernateException
Please help, I am stuck on this small thing.
Thanks,
Abhijeet.
The application server is not able to retrieve the org.hibernate.HibernateException in the classpath. In this case i think you actually have the hibernate jars in your classpath, but the application server is complaining about not being able to find its definition.
Think about it: the most obvious exception for a missing dependency would be a ClassNotFoundExeption.
You are not getting this one, and you are also getting problems on instantiating an hibernate exception. Who would throw an hibernate exception if not the hibernate library itself.
So some part of hibernate is already loaded in the classpath, but not this specific class.
In my experience i'd check for libraries version conflicts/mismatch. Check the version of all the hibernate jars and dependencies.
When we started using JPA in WebLogic 10.3.5, we noticed the following exception occasionally. About half of the time we would start the server any JPA call would result in the error, the other half of the time it was fine.
java.lang.ClassCastException: :
org.apache.xerces.parsers.StandardParserConfiguration cannot be cast
to org.apache.xerces.xni.parser.XMLParserConfiguration" occurred while
attempting to determine the version of "myPersistenceXmlFileHere.xml"
Inside our EAR is a xercesImpl jat used by other portions of the project (non-JPA) without issue. I suspect the problem is simply interference from the WebLogic implementation jar.
Update: (Re)deploying in Eclipse seems to reproduce this issue regardless of settings in answer below. Once the exception appears once, it will not resolve and the only solution is to restart the server instance.
In our weblogic-application.xml we added the following, through trial and error. We now do not have any ClassCastExceptions, as the local jar should be taking precedence in this scenario.
<wls:prefer-application-packages>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
<wls:package-name>org.apache.xerces.xni.parser.*</wls:package-name>
<wls:package-name>org.apache.xerces.parsers.*</wls:package-name>
<wls:package-name>org.apache.xalan.*</wls:package-name>
</wls:prefer-application-packages>