Hazelcast CacheManager fails in native Quarkus app - quarkus

I have a Camel Quarkus application that starts Hazelcast instance in embedded mode, and a custom cache policy that connects to the cache configured in that Hazelcast instance. Everything works fine in JVM mode, but in native mode it fails with the following exception:
java.lang.NullPointerException: null
at com.hazelcast.client.cache.impl.HazelcastClientCacheManager.findCacheConfig(HazelcastClientCacheManager.java:129)
at com.hazelcast.cache.impl.AbstractHazelcastCacheManager.getCacheUnchecked(AbstractHazelcastCacheManager.java:228)
at com.hazelcast.cache.impl.AbstractHazelcastCacheManager.getCache(AbstractHazelcastCacheManager.java:210)
at com.hazelcast.cache.impl.AbstractHazelcastCacheManager.getCache(AbstractHazelcastCacheManager.java:65)
How do I go about troubleshooting it further? Is there anything I'm missing?
I tried adding a bunch of Hazelcast classes to my reflection-config.json, I have both hazelcast.xml and hazelcast-client.xml in my classpath and they are both listed in the resources-config.json.
The Hazelcast version I use is 5.1.3. Tried with 5.2.0, same issue.

Related

Neo4J connection timed out in Spring Boot 2.2.4 but not in 2.0.5

I'm building a Spring Boot application with neo4j. I have an issue connecting to a deployed database when I'm running on Spring Boot 2.2.4. In an other project with Spring Boot 2.0.5 it works, but when I upgrade that project to 2.2.4 it also breaks with the same exception.
The weird thing is that it also works on 2.2.4 locally when using a local Docker image.
I get the following exception when I try to connect to a deployed neo4j instance in the cloud using an uri of the form bolt://35.xx.xx.xx:7687 AND on Spring Boot 2.2.4:
If I run my docker image and I change the connection uri to bolt://localhost:7687 it also works perfectly fine on Spring Boot 2.2.4.
Even in my gitlab CI/CD pipeline the test works fine using a service inside the pipeline, also with the same neo4j image.
This is my build.gradle:
And these are the versions effectively installed:
I also can always use browser to connect to my database that's why I assume that it has something to do with the versions instead of my cloud configuration.
Anyone any idea what I have to change on my configuration?
Thanks in advance!
We run following versions:
neo4j 3.5.14
Spring Boot 2.2.4
Java 11
EDIT 1
As someone proposed, I also setup a very simplistic example application (https://neo4j.com/developer/java/) using just the neo4j driver v4 with my GCP instance of Neo4J. This works perfectly fine.
EDIT 2
My application.properties looks like this:
spring.data.neo4j.uri=bolt://35.xxx.xxx.xxx:7687 # <- in prod
spring.data.neo4j.uri=bolt://localhost:7687 # <- in dev
spring.data.neo4j.uri=bolt://neo4j:7687 # <- in CI/CD
spring.data.neo4j.username=neo4j
spring.data.neo4j.password=****
spring.data.neo4j.embedded.enabled=false
The different environments are splitted in seperate property files that set the spring active profile. Im always testing this with replacing the localhost one in the application-dev.properties to the public ip.
My final setup (and solution) was to use only following dependencies:
implementation 'org.springframework.boot:spring-boot-starter-data-neo4j'
implementation 'org.neo4j.driver:neo4j-java-driver-spring-boot-starter:4.0.0.1'
And use following settings in the properties file:
org.neo4j.driver.uri=bolt://35.xx.xx.xx:7687
org.neo4j.driver.authentication.username=neo4j
org.neo4j.driver.authentication.password=neo4j
org.neo4j.driver.config.encrypted=false
Encryption wasn't the problem, but the settings had to be set to org.neo4j.driver instead of the org.springramework.boot dependency. The springframework dependency is still needed to use #Query etc in the repositories, thats why I needed both.

How -Dlogging.level JVM argument is handled in spring boot, spring cloud

I have a spring cloud application, which under the covers uses spring boot.
In the bootstrap phase of the app I am using some classes from the apache commons config library under: org.apache.commons.configuration
My application is started with this flag per the spring docs:
-Dlogging.level.org.apache.commons.configuration=INFO
Despite this, i am still getting DEBUG level logs emitted during the bootstrap phase of spring....
I am lost as to how to properly specify the log level of INFO specified for the bootstrap phase of spring boot.
Ensure you are not setting debug=true in application properties or not passing --debug flag to the application.
In application.properties set:
debug=false
The configuration of spring boot has a specific order, so probably somewhere in the application or bootstrap configuration files the logging level is configured to DEBUG.
Source:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

SpringBoot war and JNDI DataSource standalone not working

I have a SpringBoot2-Application configured as a war package that I want to run on the command-line but also be deployable in an application server.
Per the instructions, I configured the dependency to the embedded Tomcat to scope "provided" and also added a TomcatServletWebServerFactory to override the initialization of the embedded Tomcat so that I can enable jndi.naming because I want the datasource to be read from the jndi of the application server. In case I start the application standalone, I provide the jndi-resource by adding it to the embedded Tomcat during start.
This fails nicely: if the scope is "provided" and starting standalone, my TomcatServletWebServerFactory is not run and jndi is not activated so the lookup of the datasource fails. But that package works fine in Wildfly. If I remove "provided", the standalone application starts fine but it crashes in Wildfly out of obvious reasons (there is a Tomcat instance started to many that can not be cast to an Undertow-instance).
Has anybody else experienced this and has a solution? What does the SpringBoot-Maven plugin do to "hide" an embedded Tomcat in a war? Maybe my TomcatServletWebServerFactory has to adjust to the "provided"(hidden) configuration?
Thanks for all suggestions.

Spring Boot: Embedded servlet container is not working properly

My project is using MDHT(Model Driven Health Tools) Runtime Api Library which is based on Eclipse Modeling Framework(EMF). It works when servers in Spring MVC project. But for some reason the EMF package registry is not getting loaded properly and therefore it cannot deserialize as a Consol CCD document when try to servers in Sprint Boot project.
Code Sample:
Mu2consolPackage.eINSTANCE.unload();
ConsolPackage.eINSTANCE.eClass();
CDAUtil.load(in, result);
Link:
MDHT(https://github.com/mdht/mdht-models)
User Documentation (https://www.projects.openhealthtools.org/sf/wiki/do/viewPage/projects.mdht/wiki/User%20Documentation)
Edit:
After changing to use external tomcat to deploy instead of spring boot embedded servlet container. It works, but still cannot resolve using embedded container.

deploying Spring boot in websphere

Websphere 8.5.5.2
Trying to deploy spring boot application in to websphere server. I already made sure class loader policy is parent last. Issue seems because websphere may need some additional configuration to recognize war without any web.xml? Not sure. Getting below error.
Caused by: javax.xml.bind.JAXBException: ClassCastException: attempting to cast jar:file:/usr/WebSphere850/AppServer/endorsed_apis/jaxb-api.jar!/javax/xml/bind/JAXBContext.class
to
wsjar:file:/usr/WebSphere850/AppServer/profiles/node01/installedApps/dchislwsapp020Cell01/My%20Application%20Service%20-%20Test%20Service.ear/test-plan-rest.war/WEB-INF/lib/jaxb-api-2.2.11.jar!/javax/xml/bind/JAXBContext.class.Please make sure that you are specifying the proper ClassLoader.`
You should be able to do this by adding
DisableIBMJAXWSEngine: true
to your application's META-INF/MANIFEST.MF to disable it at the application level.
To disable it at the server level follow the directions at: http://www-01.ibm.com/support/knowledgecenter/SS7JFU_6.1.0/com.ibm.websphere.express.doc/info/exp/ae/twbs_thirdparty.html?cp=SS7JFU_6.1.0%2F1-7-9-4-1-14-0 to disable at the server level.

Resources