I use spring integration and java-dsl dependencies with this versions.
spring-integration-jdbc- 5.0.0M6
spring-integration-ws- 5.0.0M6
spring-integration-http- 5.0.0M6
spring-integration-jmx- 5.0.0M6
spring-integration-core- 5.0.0M6
spring-integration-java-dsl-
1.2.2RELEASE
I must use 5.0.0M6 version because of new JdbcMetadataStore.
Last week, I used spring integration 4.3.11RELEASE and java-dsl-1.2.2RELEASE and my application worked.
After the upgrade process, this runtime exception is thrown:
Caused by: java.lang.NoClassDefFoundError: org/springframework/integration/expression/IntegrationEvaluationContextAware
at org.springframework.integration.dsl.config.IntegrationFlowBeanPostProcessor.registerComponent(IntegrationFlowBeanPostProcessor.java:280) ~[spring-integration-java-dsl-1.2.2.RELEASE.jar:na]
at org.springframework.integration.dsl.config.IntegrationFlowBeanPostProcessor.processStandardIntegrationFlow(IntegrationFlowBeanPostProcessor.java:242) ~[spring-integration-java-dsl-1.2.2.RELEASE.jar:na]
at org.springframework.integration.dsl.config.IntegrationFlowBeanPostProcessor.processIntegrationFlowImpl(IntegrationFlowBeanPostProcessor.java:254) ~[spring-integration-java-dsl-1.2.2.RELEASE.jar:na]
at org.springframework.integration.dsl.config.IntegrationFlowBeanPostProcessor.postProcessBeforeInitialization(IntegrationFlowBeanPostProcessor.java:103) ~[spring-integration-java-dsl-1.2.2.RELEASE.jar:na]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:422) ~[spring-beans-5.0.0.RC3.jar:5.0.0.RC3]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1707) ~[spring-beans-5.0.0.RC3.jar:5.0.0.RC3]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:582) ~[spring-beans-5.0.0.RC3.jar:5.0.0.RC3]
... 15 common frames omitted
There are 2 of The IntegrationFlowBeanPostProcessor class definition and my application work to use this:
org.springframework.integration.dsl.config.IntegrationFlowBeanPostProcessor
and the code below, it throws class not found exception:
if (component instanceof org.springframework.integration.expression.IntegrationEvaluationContextAware)
The other class is in this package:
org.springframework.integration.config.dsl
It don't use IntegrationEvaluationContextAware.
But my application works to use the first one.
What can be the reason of it?
Thanks
I read Spring Integration 4.3 to 5.0 Migration Guide now and I see this: Java DSL The Spring Integration Java DSL has been merged to the Core project with Java 8 code base. The old project remains for the previous Spring Integration versions and isn't compatible with version 5.0. I remove the java-dsl dependency and my project works. Sorry for my question
Related
I am using Hibernate OGM 5.1.0.Final and hazelcast-hibernate5 1.1.3 ( even checked with 1.2 ). The OGM compatible hibernate ORM dependency is 5.1.5 , which is present in POM.
Caused by: java.lang.IncompatibleClassChangeError: Expected static method org.hibernate.cache.internal.DefaultCacheKeysFactory.createEntityKey(Ljava/lang/Object;Lorg/hibernate/persister/entity/EntityPersister;Lorg/hibernate/engine/spi/SessionFactoryIm
at com.hazelcast.hibernate.region.EntityRegionAccessStrategyAdapter.generateCacheKey(EntityRegionAccessStrategyAdapter.java:66)
at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:198)
at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:125)
at org.hibernate.ogm.loader.impl.OgmLoader.initializeEntitiesAndCollections(OgmLoader.java:807)
at org.hibernate.ogm.loader.impl.OgmLoader.doQuery(OgmLoader.java:393)
at org.hibernate.ogm.loader.impl.OgmLoader.doQueryAndInitializeNonLazyCollections(OgmLoader.java:283)
at org.hibernate.ogm.loader.impl.OgmLoader.loadEntity(OgmLoader.java:201)
at org.hibernate.ogm.loader.impl.OgmLoader.loadEntitiesFromTuples(OgmLoader.java:220)
at org.hibernate.ogm.loader.entity.impl.DynamicBatchingEntityLoaderBuilder$DynamicBatchingEntityLoader.loadEntitiesFromTuples(DynamicBatchingEntityLoaderBuilder.java:127)
at org.hibernate.ogm.query.impl.OgmQueryLoader.listOfEntities(OgmQueryLoader.java:92)
at org.hibernate.ogm.query.impl.OgmQueryLoader.list(OgmQueryLoader.java:78)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501)
at org.hibernate.ogm.query.impl.OgmQueryTranslator.list(OgmQueryTranslator.java:129)
at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1339)
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87)
at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606)
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483)
at com.olp.jpa.common.AbstractRepositoryImpl.findAll(AbstractRepositoryImpl.java:137)
The issue looked similar to the one reported here - https://github.com/hazelcast/hazelcast-hibernate5/issues/13 , however I cannot upgrade ORM to 5.2, since it is not supported by OGM yet. Please suggest if there is a solution/workaround for the issue.
Version 1.1.3 and 1.2 of hazelcast-hibernate5 depend on Hibernate version 5.0.9.Final. You might need to exclude that in your Maven configuration and declare Hibernate dependency with version 5.1.5 yourself.
Update
It seems hazelcast-hibernate5 doesn't support Hibernate 5.1.5. So I have modified hazelcast-hibernate5 code to support Hibernate 5.1.5 and released a custom version which can be found here. Note that this is not available on Maven central and it's not an official release of the plugin, just a quick change to support Hibernate 5.1.5 for your use case. It means that you have to install it to your local Maven repository first (or embed the JAR directly to your project). You can see the changes I have made in this branch to examine the code, or build from the source yourself.
Reading the documentation of redhat (https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/chap-Class_Loading_and_Modules.html) I found that the application server classloader
has a priority list when loading classes that are used to avoid any conflict between
loaded classes, The order is as below
Implicit dependencies.
These are the dependencies that are added automatically by JBoss Enterprise Application Platform 6, such as the JAVA EE APIs. These dependencies have the highest class loader precedence because they contain common functionality and APIs that are supplied by JBoss Enterprise Application Platform 6.
Refer to Section 3.7.1, “Implicit Module Dependencies” for complete details about each implicit dependency.
Explicit dependencies.
These are dependencies that are manually added in the application configuration. This can be done using the application's MANIFEST.MF file or the new optional JBoss deployment descriptor jboss-deployment-structure.xml file.
Refer to Section 3.2, “Add an Explicit Module Dependency to a Deployment” to learn how to add explicit dependencies.
Local resources.
Class files packaged up inside the deployment itself, e.g. from the WEB-INF/classes or WEB-INF/lib directories of a WAR file.
Inter-deployment dependencies.
These are dependencies on other deployments in a EAR deployment. This can include classes in the lib directory of the EAR or classes defined in other EJB jars.
I tried to test this order by using a JSF webapp (rich faces) in my EAR archive
My ear is as below :
sample.ear
--- sport.war
--- mysql.jar
--- lib
Usescase 1 : I added the JSF jars under the webapp (sport.war/WEB-INF/lib): [jsf-api-2.1.14.jar/jsf-impl-2.1.14.jar/portletbridge-api-3.1.2.Final.jar/portletbridge-impl-3.1.2.Final.jar], the jboss server started well and I don't have any exception
Usescase2: I added the JSF jars under sample.ear/lib
==> When I start the jboss server I get an exception (it sounds that the application server loaded the module JSF provided by jboss Implicit dependencies instead of the one in my sample.ear/lib)
I can't understand why in the 1srt usescase the Class Loading Precedence is not respected while in the 2sd usescase the Class Loading Precedence is respected?
Could you please clarify me this point
ENV
JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8)
JDK 6
Without seeing the exact deployment exception that you got it is difficult to diagnose the issue.
In the first scenario the packaged libraries are loaded in the same class loader as your application.
In the second scenario the packaged libraries are loaded in a separate module and class loader.
The above means that , The deployment issue you were having fo not have to be related to Class Loading Precedence they could also be related to Class Loading Isolation.
Also Jboss and EAP already come with a prepackaged implementation of JSF, and you might be experiencing collisions due to version mismatch
If you were looking to replace the default JSF implementation on JBoss the better option to do so would have been to put the new JSF implementation in a static module, just like the default one , and have Jboss load it on demand.
I've pulled helloworld-spring-webapp from https://github.com/marko-asplund/jersey.git and tried to deploy it onto the latest Glassfish 4 application server, using java ee-7 (jdk 1.7.0_45) and jersey 2.3-SNAPSHOT. Deployment fails with this error:
Error occurred during deployment: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Ref] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref, ProcessingProviders)]. Please see server.log for more details.
My installed version of Jersey on Glassfish 4 is 2.0-0.1, with an update available to move to 2.0-0.2.
I attempted this because I'm getting similar errors attempting to get CDI working with an application I'm working with, so it's fortunate to find that this example also fails with similar results. Does anyone know how to make this deploy and function correctly with Glassfish 4?
Edit:
I pulled a mirror image of that example and pulled it again from the source (here: https://github.com/jersey/jersey/tree/2.4.1). I can deploy that sample. There is a reference to a jira item JERSEY-2032 in the latest pom of the helloworld-spring-webapp. So now I need to figure out what was done differently between versions that makes this sample deploy correctly so that I can make the same changes to my work-in-progress application.
I am trying to deploy an application on Websphere 8.5.5
I've created a shared library for Websphere that includes myfaces 2.2 jars and other dependencies like commons-collections.
I also made the class loader of my application as PARENT_LAST.
When I deploy the application, I get this exception:
An error occured while initializing MyFaces: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
java.lang.IllegalArgumentException: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:557)
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:524)
I was looking at running a newer version of MyFaces on WAS 8.5.5, and ran into a similar issue. It appears to be a conflict between the code IBM wrote to support its embedded version of MyFaces, and an application- or shared library-provided MyFaces.
IBM provides a way to circumvent this issue. When WAS 8.0 shipped, it provided a feature to allow select either "SunRI1.2" or "MyFaces" as the server-provided JSF. Setting the default to "SunRI1.2" would remove the server-provided MyFaces from the classpath and allow the developer to provide their own.
Select any application
Click JSP and JSF Options
In the JSF implementation section, change the drop-down to SunRI1.2
Click OK
Save configuration and restart server
I'm developing a web application using JSF 2.0, NetBeans 6.9.1, GlassFish Server 3.1, mojarra 2.0.3, and JasperReports 3.7.6. Included in my project library is the jar file "xerces-2.8.0.jar". This file was imported as part of the JasperReports jar file library. Whenever I try to deploy, run, or debug my project through NetBeans, I receive this error:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
After any change in my project my build fails, and I receive the above error, when I try to deploy, run, or debug it. I have to restart the server and run/debug a second time. I've searched the internet and cannot find a solution to this problem. I've looked at the jar file in question, and and DTDDVFactoryImpl does indeed extend from DTDDVFactory - I don't know why I'm receiving this error. While I can eventually get my project running, it would be much nicer if I wasn't receiving this error.
Can anyone please tell me how I can fix this? Do I need to remove this file from my project library? Do I need to update this file with a newer version/older version?
If you provide your own xerces.jar, you have to do that through the Endorsed Standards Override Mechanism (java -Djava.endorsed.dirs=/path/to/xerces.jar), you are not allowed to just add it on the classpath (and will sooner or later run into trouble if you do). Let me explain.
JAXP is the Java API for XML Processing. The creation of JAXP objects (like parsers, XSLT transfomers, DOM Documents) is done through the factory/factory-method pattern so you can plugin a new JAXP implementation (it has to be newer than the one provided in your JRE). Xerces provides (part of) a JAXP implementation and contains endorsed standards (an endorsed standard is a Java API defined through a standards process other than the Java Community Process, see the Endorsed Standards Override Mechanism). You'll run in all kinds of troubles if you don't use the ESOM.
I got this error when using Selenium with Glassfish. I got around it by copying XML jars (xerces-*, xalan-*, xml-apis*, serialize*) from selenium/libs/ to $AS_HOME/lib/endorsed (for Glassfish 2) or to $AS_HOME/glassfish/lib/endorsed for Glassfish 4.