Ignite 2.7 issue while upgrading java.lang.IllegalAccessError: tried to access field org.h2.util.LocalDateTimeUtils.LOCAL_DATE - ignite

HI while upgrading to ignite 2.7 we face this issue , this hapepns when ignite is about to start certain custom caches.
2019-01-09 19:28:04.260 UTC [SERVER] [exchange-worker-#38%fdap%] [ERROR] [,] ROOT - Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalAccessError: tried to access field org.h2.util.LocalDateTimeUtils.LOCAL_DATE from class o.a.i.i.processors.query.h2.H2DatabaseType]]
java.lang.IllegalAccessError: tried to access field org.h2.util.LocalDateTimeUtils.LOCAL_DATE from class org.apache.ignite.internal.processors.query.h2.H2DatabaseType
at org.apache.ignite.internal.processors.query.h2.H2DatabaseType.fromClass(H2DatabaseType.java:147)
at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dbTypeFromClass(IgniteH2Indexing.java:2972)
at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.createTable(IgniteH2Indexing.java:2873)
at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerType(IgniteH2Indexing.java:2809)
at org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1633)
at org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:805)
at org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:866)
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1330)
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2165)
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:2023)
at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:924)
at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
There is a ticket also for the same https://issues.apache.org/jira/browse/IGNITE-10612 , will this be solved or is there a release guide on how to overcome the issue .
Please help ...

by putting
<properties>
<h2.version>1.4.197</h2.version>
</properties>
works to resolve this.
since the default of h2 is 1.4.199 which can cause other exceptions. you have to override that as well.

Are you sure that you have correct version of H2 dependency? For AI 2.7 it should be com.h2database h2 1.4.197 and not any other. The error you have posted is linkage error which will arise from having incorrect library version in classpath.

Related

Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.confluent.kafka.serializers.KafkaAvroSerializerConfig since 6.0.0

im working on a flink (v.1.13.2) application which should publish some objects to my Kafka broker.
For schema validation I use the Confluent Schema Registry.
I previously used the library in version 5.2.0 (also tried other 5.x.x versions):
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-avro-serializer</artifactId>
<!--<version>5.x.x</version>-->
<version>6.2.0</version>
</dependency>
This seems to work but there was a strange behaviour while registering the schema to the registry. The schema was just ""bytes"" After investigation I found out that the suspect part in 'AvroSchemaUtils' was changed.
https://github.com/confluentinc/schema-registry/blob/a2f80f30d6713c50ee54c47885bcde2945932660/client/src/main/java/io/confluent/kafka/schemaregistry/avro/AvroSchemaUtils.java#L88
So I've tryed to update the library to the next working version.
After I updated to 6.x.x. I've got the following error:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.confluent.kafka.serializers.KafkaAvroSerializerConfig
at io.confluent.kafka.serializers.KafkaAvroSerializer.configure(KafkaAvroSerializer.java:50)
at org.apache.kafka.clients.producer.KafkaProducer.<init>(KafkaProducer.java:369)
... 23 more
How to find out what wrong here?
This may be the problem. After Kafka Avro Serializer is upgraded, the dependent kafka client is upgraded from kafka_2.12 to kafka_2.13
https://mvnrepository.com/artifact/io.confluent/kafka-avro-serializer/6.2.0

An error occurred while mapping from AMQP properties to MessageHeaders

While communicating with RabbitMQ messages are consumed successfully, however, the following warning is displayed in the logs.
**error occurred while mapping from AMQP properties to MessageHeaders**
lang.IllegalStateException: java.lang.ClassNotFoundException: Class_Name
t org.springframework.integration.mapping.support.JsonHeaders.getClassForValue(JsonHeaders.java:89) ~[spring-integration-core-5.2.4.RELEASE.jar:5.2.4.RELEASE]
at org.springframework.integration.mapping.support.JsonHeaders.buildResolvableType(JsonHeaders.java:72) ~[spring-integration-core-5.2.4.RELEASE.jar:5.2.4.RELEASE]
at org.springframework.integration.amqp.support.DefaultAmqpHeaderMapper.createJsonResolvableTypHeaderInAny(DefaultAmqpHeaderMapper.java:169) [spring-integration-amqp-5.2.4.RELEASE.jar:5.2.4.RELEASE].
I know it's just a warning, but I would like to know the way it can be avoided.
Thanks in advance
This has been fixed in Spring Integration 5.2.5: https://github.com/spring-projects/spring-integration/issues/3223. Please, consider to upgrade to the latest Spring Boot 2.2.6 and it is included over there. See Spring Boot docs how to override dependency versions: https://docs.spring.io/spring-boot/docs/2.2.6.RELEASE/reference/html/using-spring-boot.html#using-boot-maven
You can apply workarounds otherwise as mentioned in that GH issue.

Exception while running Seedstack Application

I have used seedstack dependecies for Hibernate and JPA to create DAO services that performs crud operations on Database.
I am trying to Launch this Seedstack application module through Java application Launcher in eclipse, by SeedMain class.
In pom.xml - dependecy for undertow is given.
<dependency>
<groupId>org.seedstack.seed</groupId>
<artifactId>seed-web-undertow</artifactId>
</dependency>
When executing the SeedMain class, I am getting the below error snakeyaml error:-
Exception in thread "main" java.lang.NoSuchMethodError: org.yaml.snakeyaml.DumperOptions.setSplitLines(Z)V
at com.fasterxml.jackson.dataformat.yaml.YAMLGenerator.buildDumperOptions(YAMLGenerator.java:259)
at com.fasterxml.jackson.dataformat.yaml.YAMLGenerator.<init>(YAMLGenerator.java:232)
at com.fasterxml.jackson.dataformat.yaml.YAMLFactory._createGenerator(YAMLFactory.java:447)
at com.fasterxml.jackson.dataformat.yaml.YAMLFactory.createGenerator(YAMLFactory.java:397)
at org.seedstack.seed.core.internal.diagnostic.DefaultDiagnosticReporter.writeDiagnosticReport(DefaultDiagnosticReporter.java:75)
at org.seedstack.seed.core.internal.diagnostic.DefaultDiagnosticReporter.writeDiagnosticReport(DefaultDiagnosticReporter.java:67)
at org.seedstack.seed.core.internal.diagnostic.DiagnosticManagerImpl.dumpDiagnosticReport(DiagnosticManagerImpl.java:70)
at org.seedstack.seed.core.SeedMain.handleException(SeedMain.java:68)
at org.seedstack.seed.core.SeedMain.main(SeedMain.java:61)
As per my understanding the Error is due to some version inconsistency for snakeyaml, But for Seedstack as the versions for dependecies are resolved by seedstack-bom dependecy, so where exactly should I do the changes to resolve the error.
Thanks in Advance!
From reading the stacktrace, it seems that you have some error on startup which is handled by the handleException() method. This method then tries to write a YAML diagnostic report but ultimately fails due to the snakeyaml version issue you mentioned.
You should do two things:
Fix the snakeyaml dependency issue by looking into the dependency tree. This kind of problem is often caused by some library that makes Maven choose an older version. SeedStack needs at least jackson-dataformat-yaml version 2.9.4 which in turn needs at least snakeyaml 1.18.
Fix the other error by looking at the full stacktrace. When a diagnostic report cannot be written, the original exception is still printed on the console (on stderr).

CXF 3.0.2 throwing " java.lang.AssertionError: UNIMPLEMENTED " exception in weblogic10.3

We are trying to make a webservice call using CXF framework involving CXF - ws security and the application being deployed in weblogic 10.3 , but receiving the below exception and seems like the weblogic specific jars are picked up , though the xercesimpl jar is present in the application in /WEB-INF/lib .
Options tried , but did not help:
Setting the weblogic container descriptor with
web-inf preferences
true .
Setting the JVM arguments or system property as -
-Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
-Djavax.xml.soap.SOAPFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl
-Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl
Adding xercesimpl jar to maven pom.
Exception
]] Root cause of ServletException.
java.lang.AssertionError: UNIMPLEMENTED
at weblogic.xml.domimpl.NodeImpl.setTextContent(NodeImpl.java:216)
at org.apache.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeAttribute(XmlWriterToTree.java:137)
at org.apache.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeNamespace(XmlWriterToTree.java:114)
at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:211)
at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:329)
at org.apache.wss4j.dom.message.WSSecSignature.computeSignature(WSSecSignature.java:578)
at org.apache.wss4j.dom.action.SignatureAction.execute(SignatureAction.java:151)
at org.apache.wss4j.dom.handler.WSHandler.doSenderAction(WSHandler.java:226)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$100(WSS4JOutInterceptor.java:54)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessageInternal(WSS4JOutInterceptor.java:282)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:154)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:141)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)enter code here
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:98)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
Thanks,
Soumya
I finally found the answer without modifying any weblogic startup script (tested on CXF 2.7.0 and weblogic 10.3.6
The reason for this issue is that CXF is not compatible with weblogic implementation of SAAJ. http://cxf.apache.org/docs/application-server-specific-configuration-guide.html
1.
Q: I have this error: javax.xml.ws.WebServiceException: Cannot create SAAJ factory instance.
A: Please make sure you have the saaj-impl-1.3.jar in the classpath and make sure your app picks up this one instead of weblogic one.
The same issue is also causing the UNIMPLEMENTED error in the question
So my solution is
1) put saaj-impl in classpath. If you are using maven, put the dependency on pom.xml
2) in weblogic.xml (in your resources folder) put
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>com.sun.xml.messaging.saaj.*</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
3) Restart your server through Node Manager and by right the CXF WS-Security should be working
Hope it helps!

Glassfish 3.1.1 start-local-instance fails with JAXBException

I am setting up a GlassFish cluster following the guide at http://javadude.wordpress.com/2011/04/25/glassfish-3-1-clustering-tutorial/. I started from fresh installs of GlassFish 3.1.1. I also have the same architecture as in the guide: two nodes with one instance each. The DAS is on node1.
I've tried starting from scratch several times and am able to create the cluster, nodes and instances without issue. I also have the DAS communicating with node2 via SSH. However, each time when I get to the point where I attempt to start instance2 it fails:
$ ./asadmin start-local-instance --node node1 --sync normal instance2
Previous synchronization failed at Feb 23, 2012 2:41:53 PM
Will perform full synchronization.
Removing all cached state for instance instance2.
CLI802 Synchronization failed for directory config, caused by:
javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory]
Command start-local-instance failed.
I spent the day Googling and searching GlassFish's Jira, but couldn't find a solution to this issue. I'd very much appreciate any ideas you have on how to solve this problem.
My operating system is CentOS 5.7 and my Java version is 1.6.0_20
Unfortunately my instance directory is empty, I'm assuming because it never started. So there is no log file. I set AS_DEBUG=true but it gives no stack trace. The last debug lines before the error are
Removing all cached state for instance instance2.
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/config
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/applications
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/generated
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/lib
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/docroot
Got exception: javax.xml.bind.JAXBException
Acting on a tip from a user in the Glassfish forum, I learned that Java 1.6.0_20 is an older release of Java that is not supported by Glassfish 3.1.1. I worked with a sysadmin to get Java 1.6.0_31 installed on both nodes of the cluster and that did the trick--both instances start up without errors.