I am facing the following problem. Using a compiled software I am trying to launch it on Tomcat 8 instead of Tomcat 7. After resolving some minor problems I get stuck at this one:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ... Invocation of init method failed; nested exception is java.lang.IncompatibleClassChangeError: Found class org.objectweb.asm.AnnotationVisitor, but interface was expected
Reading around, it seems like it comes from Spring version difference. Trouble is I'm not touching the application here at all. Tomcat 7 and Tomcat 8 get exactly same program to launch.
Could I ask you for your suggestions on solving it?
On the way of investigating the problem I've learned about this ticket: https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
It looks like Tomcat 8, as opposed to earlier Tomcat version does not load classes alphabetically. In my project it caused a problem as libraries holding different versions of asm where used.
Note: In the ticket from above - raised to apache, someone links the workaround at https://github.com/openwide-java/tomcat-classloader-ordered. For me it did not work, though.
In the end we had to go through a complex work of removing dependencies and fixing the project up so that it relies on one lib version only.
Good luck for everyone struggling with similar stuff!
Related
I am upgrading Hibernate from 5.1.17 to 5.4.11. I am getting org.hibernate.LazyInitializationException while running Junit on collection whose fetch type is LAZY. I am trying to find different ways to make it work and run it in transaction(still facing some issues). Before that I would like to know what is changed after 5.1.17 which is causing this issue because earlier Junit test cases were working perfectly fine.
So what are the things changed related to lazy loading after 5.1.17?
Many things changed, so it's hard to say. What I suggest is, start upgrading your hibernate by updating 1 minor version at a time (according to https://semver.org).
Once you pinpoint which minor version is causing a problem, check:
https://hibernate.org/orm/releases/
Hope that helps.
The title is inspecific, sorry, but I don't know what's really wrong ...
Ok, so I have working springboot app (version 2.0.4.RELEASE), weblogic 12.2.1.1. When running standalone, it's OK. But when executed under weblogic, beanvalidation silently ignores all validation issues. The typical weblogic cause for this is, that it ignores libraries which apps wants, and using it's own instead resulting in unexpected and unreliable app behavior. And yes, when debugging, bean validation code does not match with what is being declared in pom.xml. So I added
<package-name>org.hibernate.validator.*</package-name>
<package-name>javax.validation.*</package-name>
as prefer-application-packages, but now I'm getting
org.eclipse.persistence.jpa.PersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider
which was described here: Weblogic 10.3.3 trying to load org.eclipse.persistence.jpa.PersistenceProvider instead of configured Hibernate Provider but I cannot get it to work. Any help please? I understand, that this means that weblogic is probably ruining foundations of springboot app, I'd like to fix it, however it kinda works, except for beanvalidation. So complete fix is probably not that necessary, and maybe someone does have an idea how to differently pretty-please weblogic to turn bean validation on?
I'd really like to share more, but that thing does not log any issue at all. It just dont validate beans, and the same code (except for weblogic tooling) does work properly, when weblogic is avoided.
There must be following in weblogic.xml
...
<prefer-application-resources>
<resource-name>META-INF/services/javax.persistence.spi.PersistenceProvider</resource-name>
...
</prefer-application-resources>
...
I just tried to run an OptaPlanner project in Spring Boot, but there's only very simple text in OptaPlanner User Guide for Spring.
Actually, I think it is very easy to copy all domain objects, configuration files and drools files from an OptaPlanner project to Spring Boot project without any changes, but the only question is how to call Solver's solve method.
I made it run after Spring Boot startup with a class (named CommandLineAppStartupRunner) which implements CommandLineRunner interface, and I called solve method in its run method. Finally, I got an exception like follows:
Caused by: java.lang.IllegalArgumentException: Can not set org.optaplanner.core.api.score.buildin.hardmediumsoft.HardMediumSoftScore field springbootcloudbalance.domain.CloudBalance.score to springbootcloudbalance.domain.CloudBalance
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:58)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:393)
at org.optaplanner.core.impl.domain.common.accessor.ReflectionFieldMemberAccessor.executeGetter(ReflectionFieldMemberAccessor.java:54)
at org.optaplanner.core.impl.domain.solution.descriptor.SolutionDescriptor.getScore(SolutionDescriptor.java:1071)
at org.optaplanner.core.impl.score.director.AbstractScoreDirector.cloneSolution(AbstractScoreDirector.java:212)
at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.setWorkingSolutionFromBestSolution(DefaultSolverScope.java:230)
at org.optaplanner.core.impl.solver.AbstractSolver.solvingStarted(AbstractSolver.java:75)
at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:210)
at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:190)
at springbootcloudbalance.CommandLineAppStartupRunner.run(CommandLineAppStartupRunner.java:55)
at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:818)
... 10 common frames omitted
I checked the code, and found the exception throws because the object from field.getDeclaringClass() is a different instance from the one from var1.getClass(). I'm afraid it due to the implementation of java reflection conflicts between OptaPlanner and Spring Boot.
The version I used is as follows:
OptaPlanner 7.11.0.Final
Spring Boot 2.0.5.RELEASE
JVM 1.8.0_181
Removing the spring-boot-devtools dependency fixes this error. Another SO question similar to this one explains it has something to do with different classloaders: Optaplanner's Drools working memory is empty. The accepted answer also mentions a possible fix:
To fix it, configure spring dev tools to load Drools libraries in the RestartClassLoader, together with the project's classes: using-boot-devtools-customizing-classload
Nick's answer is correct. This is just to figure out what's going on.
This line means that optaplanner is extracting CloudBalance.getScore():
at org.optaplanner.core.impl.domain.solution.descriptor.SolutionDescriptor.getScore(SolutionDescriptor.java:1071)
This line means that it's using a ReflectionFieldMemberAccessor for that, which is just way to read a field through reflection (including private fields):
at org.optaplanner.core.impl.domain.common.accessor.ReflectionFieldMemberAccessor.executeGetter(ReflectionFieldMemberAccessor.java:54)
Now the error message is where it gets interesting:
Can not set ...HardMediumSoftScore field ...CloudBalance.score to ...CloudBalance
It looks like basically doing:
CloudBalance cloudBalance2 = cloudBalance.getScore();
Huh?
Musa provided this answer, but someone deleted it, despite that the JIRA link is extremely relevant, as it points out which version of OptaPlanner will deal better with this problem:
"An issue was submitted to OptaPlanner to provide better error messages for such cases: https://issues.jboss.org/browse/PLANNER-1586. Feel free to add any comments or suggestions."
I am getting a error when deploying spring-saml application in Wildfly 8 with IBM JDK 1.7. Interestingly Googling got me no answers.
The error stacktrace is
Caused by: org.w3c.dom.ls.LSException: [ERR 0462] An unsupported encoding is encountered.
at org.apache.xml.serializer.dom3.LSSerializerImpl.write(Unknown Source) [xml.jar:]
at org.opensaml.xml.util.XMLHelper.writeNode(XMLHelper.java:892)
at org.opensaml.xml.util.XMLHelper.writeNode(XMLHelper.java:872)
at org.opensaml.xml.util.XMLHelper.nodeToString(XMLHelper.java:834)
at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:159)
at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:143)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:203)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:186)
at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:92)
at org.opensaml.PaosBootstrap.bootstrap(PaosBootstrap.java:27)
at org.springframework.security.saml.SAMLBootstrap.postProcessBeanFactory(SAMLBootstrap.java:42)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:696)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:686)
at org.springframework.context.support.AbstractApplicationContext.__refresh(AbstractApplicationContext.java:461)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:410)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:194)
Any ideas?
I think the problem is the dependency between opensaml.jar and serializer.jar.
As you used Spring Security SAML plugin, you may be using the following libraries (as they are in the demo application):
opensaml-2.6.1.jar
spring-security-config-3.1.2.jar
spring-security-core-3.2.1.jar
spring-security-web-3.2.1.jar
spring-security-saml2-core-1.0.2.jar
Wildfly 8 (and 9 too) both are packed with serializer-2.7.1.jbossorg-1.jar (/modules/system/layers/base/org/apache/xalan/main) which seems to have some differences with the "standard" serializer-2.7.1.jar (https://mvnrepository.com/artifact/xalan/serializer/2.7.1).
I compared both jars and they contain the same classes and resources, however their sizes differ. The "standard" one was compiled with IBM JDK 1.3.1, JBoss version with Oracle JDK 1.6_20 - This is based on both MANIFEST.MF files.
Note opensaml.jar was compiled with the "standard" serializer library based on the Maven repository information.
I was searching for the source code of the "standard" serializer-2.7.1.jar but I could not find it. However, I found another 2.7.1 build, this time from Spring and compared with the one JBoss source, and they have some differences. I assume that if I compare the "standard" source code I will find the same. It is not a simple file renaming as I have seen before.
The next thing I did was a little bit of experimentation.
Firstly just dropped serializer-2.7.1.jar into my application.war/WEB-INF/lib, started Wildfly (v 8.2.1) and the application started without any issues. Removed the JAR and back to the exception.
Next, I changed WF’s xalan module to use serializer-2.7.1.jar instead serializer-2.7.1.jbossorg-1.jar (removed the jar file and edited module.xml). Started WF, and surprise, I got the same exception. I even tried changing to serializer-2.7.1.jbossorg-2.jar (packed with Wildfly 10) and serializer-2.7.2.jar (https://mvnrepository.com/artifact/xalan/serializer/2.7.2) and the exception still occurred.
Finally, I rolled back the module changes to the original state and created a custom WF module including serializer-2.7.1.jar and added the module dependency in the application “jboss-deployment-structure.xml”.
It is important to highlight the application starts without any issue (or additional serializer.jar) under WAS 8.5.5 and WAS Liberty Profile 8.5.5. (target production AS and another development AS respectively). Custom modules in Wildfly are handy to avoid modifying the application WAR on this kind of scenarios.
As an additional note, as part of my test to solve this issue I upgraded to the latest Spring-Security (3.2.9) and Open-SAML (2.6.4) and I needed to upgrade to serialize.jar to 2.7.2.
P.S. I worked with Mahe in the same project, but he left few months ago and I got the task to work out this issue.
I have followed the instructions to run the demo provided. I also tried to create a simple plugin to see if I can get it to work. I am running into a problem where the factory cannot instantiate the Plugins, be it one I created or any of the other (e.g. AdminPlugin).
The exception indicates that the constructor that takes org.jwebsocket.api.PluginConfiguration as param is missing.
Has anybody else run into this problem?
Is the 20614 version broken?
Is the versions packaged incorrectly?
Any help would be appreciated.