Camel Upgrade 2.22 breaks Apache CXF endpoints - spring-boot

I have upgraded Camel 2.22. along with CXF version 3.2.5,Spring boot 2.04.RELEASE
When I start my application I can't see any errors but the can't access endpoints anymore
below is the code:
1) Camel route:
<cxf:cxfEndpoint id="porEndpoint" address="/por/" serviceClass="x.y.z.service.PorService" publishedEndpointUrl="">
<cxf:binding>
<soap:soapBinding version="1.2"/>
</cxf:binding>
</cxf:cxfEndpoint>
2) Properties:
cxf.path=/services
server.servlet.context-path=/fuse-test
3)This URL worked fine earlier :http://localhost:8080/fuse-test/services/por?wsdl
I have enabled trace at context level and log mode as debug but I can't find any errors apart from :
o.s.s.ldap.SpringSecurityLdapTemplate : Ignoring PartialResultException

camel-cxf(v 3.2.5) somehow doesn't include the cxf spring boot. After adding the below dependency the endpoint is available
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-spring-boot-starter-jaxws</artifactId>
<version>3.2.6</version>
</dependency>

Related

How can I expose camel mbean in spring boot?

I am migrating the application from 2.23.2 to 3.1.0 version.
The application works fine having 2 routes.
But a mbean is not exposed in jconsole.
There are basic mbeans in jconsole.
- JMImplementation
- com.sun.management
- com.zaxxer.hikari
- connector
- java.lang
- java.nio
- java.util.logging
- javax.management.remote.rmi
- org.apache.logging.log4j2
- org.springframework.boot
How can I handle this issue?
You need to add a dependency to your project for camel-management. For example:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-management</artifactId>
<version>3.1.0</version>
</dependency>
There's a note about this in the Camel 3.x upgrade guide:
https://camel.apache.org/manual/latest/camel-3x-upgrade-guide.html#_spring_boot_jmx

OpenTracing not activating for Sleuth-Zipkin in Spring Boot App

Spring Doc says
Spring Cloud Sleuth is compatible with OpenTracing. If you have OpenTracing on the classpath, we automatically register the OpenTracing Tracer bean. If you wish to disable this, set spring.sleuth.opentracing.enabled to false
I have the below dependency in my POM.
<dependency>
<groupId>io.opentracing.contrib</groupId>
<artifactId>opentracing-spring-cloud-starter</artifactId>
<version>${version.opentracing.spring}</version>
</dependency>
But, I get the following print out it the logs when I try to print the trace and span information : tracer: NoopTracer
2018-11-19 12:12:03.938 [{X-B3-SpanId=4cd8eed6fe759bd1, X-B3-TraceId=5bf25b3bd0714ae54cd8eed6fe759bd1, X-Span-Export=true, spanExportable=true, spanId=4cd8eed6fe759bd1, traceId=5bf25b3bd0714ae54cd8eed6fe759bd1}] DEBUG ahallim-1ef960 --- [nio-7070-exec-1] a.h.w.RestaurantController : tracer: NoopTracer
2018-11-19 12:12:03.939 [{X-B3-SpanId=4cd8eed6fe759bd1, X-B3-TraceId=5bf25b3bd0714ae54cd8eed6fe759bd1, X-Span-Export=true, spanExportable=true, spanId=4cd8eed6fe759bd1, traceId=5bf25b3bd0714ae54cd8eed6fe759bd1}] INFO ahallim-1ef960 --- [nio-7070-exec-1] a.h.w.RestaurantController : active span: null
Why am I getting a NopTracer? Why isn't Brave being registered automatically as promised? Am I doing something wrong?
I am using
Finchley.SR2
I was using Finchley.SR2 train of releases. Once I upgraded to the latest Spring Boot and Spring Cloud versions, the issue fixed itself.
I removed the opentracing-spring-cloud-starter dependency and am now just using
<dependency>
<groupId>io.opentracing.brave</groupId>
<artifactId>brave-opentracing</artifactId>
</dependency>

Tiles + Spring + wildfly 11 + java 8: java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"

I deploy a ear with spring4, tiles 3.0.7, java 8 and in wildfly 11 but i get the following error:
:45:18,865 INFO [org.jboss.as] (Controller Boot Thread)
WFLYSRV0060: Http management interface listening on
http://127.0.0.1:9990/management
00:45:18,865 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
00:45:18,865 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
started in 15761ms - Started 915 of 1144 services (356 services are
lazy, passive or on-demand)
00:45:19,773 ERROR Digester:789 - Digester.getParser:
java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"
at javax.xml.parsers.SAXParserFactory.setSchema(SAXParserFactory.java:394)
at __redirected.__SAXParserFactory.setSchema(__SAXParserFactory.java:158)
at org.apache.commons.digester.Digester.getFactory(Digester.java:536)
at org.apache.commons.digester.Digester.getParser(Digester.java:786)
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:1058)
at org.apache.commons.digester.Digester.parse(Digester.java:1887)
at org.apache.tiles.definition.digester.DigesterDefinitionsReader.read(DigesterDefinitionsReader.java:325)
at org.apache.tiles.definition.dao.BaseLocaleUrlDefinitionDAO.loadDefinitionsFromResource(BaseLocaleUrlDefinitionDAO.java:150)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:234)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:225)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:225)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:203)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadDefinitions(CachingLocaleUrlDefinitionDAO.java:192)
at org.apache.tiles.definition.dao.ResolvingLocaleUrlDefinitionDAO.loadDefinitions(ResolvingLocaleUrlDefinitionDAO.java:68)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.checkAndloadDefinitions(CachingLocaleUrlDefinitionDAO.java:174)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinitions(CachingLocaleUrlDefinitionDAO.java:131)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinition(CachingLocaleUrlDefinitionDAO.java:105)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinition(CachingLocaleUrlDefinitionDAO.java:49)
at org.apache.tiles.definition.UnresolvingLocaleDefinitionsFactory.getDefinition(UnresolvingLocaleDefinitionsFactory.java:89)
at org.apache.tiles.impl.BasicTilesContainer.getDefinition(BasicTilesContainer.java:286)
at org.apache.tiles.impl.BasicTilesContainer.isValidDefinition(BasicTilesContainer.java:273)
at org.apache.tiles.renderer.DefinitionRenderer.isRenderable(DefinitionRenderer.java:64)
at org.springframework.web.servlet.view.tiles3.TilesView.checkResource(TilesView.java:116)
at org.springframework.web.servlet.view.UrlBasedViewResolver.loadView(UrlBasedViewResolver.java:483)
at org.springframework.web.servlet.view.AbstractCachingViewResolver.createView(AbstractCachingViewResolver.java:244)
at
I tried a lot of solutions but they dont works.
I use tiles version 3.0.7
Any idea?
I just had the same issue as you while trying to upgrade from tiles 1 to 3.
Anyway my fix was to upgrade the xercesimpl version to 2.11.0
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>

log4j2 shutdownHook="disable" not working

I have the shutdownhook error in my Spring boot application in which i use log4j2.
I saw that it was a bug in log4j2 and shutdownHook="disable" was suppossed to resolve it. But inspite of using the same i still get the same error.
I am using spring boot version 1.3.7.RELEASE and the dependecy for log4j2 is
spring-boot-starter-log4j2 .
Error which i get whetry to close the session using Ctrl-C
2016-08-23 13:38:56,098 Thread-7 ERROR No log4j2 configuration file found. Using
default configuration: logging only errors to the console.
2016-08-23 13:38:56,105 Thread-7 FATAL Unable to register shutdown hook because
JVM is shutting down. java.lang.IllegalStateException: Cannot add new shutdown h
ook as this is not started. Current state: STOPPED
at org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry.ad
dShutdownCallback(DefaultShutdownCallbackRegistry.java:113)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.addShutdownCal
lback(Log4jContextFactory.java:271)
at org.apache.logging.log4j.core.LoggerContext.setUpShutdownHook(LoggerC
ontext.java:256)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:
216)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log
4jContextFactory.java:146)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log
4jContextFactory.java:41)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:185)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(Abstrac
tLoggerAdapter.java:103)
at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFac
tory.java:43)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(Abstract
LoggerAdapter.java:42)
at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFact
ory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
at com.worldline.frm.dataloader.policy.CustomQueueRoutePolicy.onStop(Cus
tomQueueRoutePolicy.java:90)
at org.apache.camel.impl.RouteService.doStop(RouteService.java:249)

Spring Boot 1.2.1 still WARN "Error initializing SpringLiquibase" with liquibase 3.3.x

It appears there is still an issue with Spring Boot and libuibase 3.3.x.
2015-02-16 11:07:34.117 WARN 7576 --- [ main] liquibase : Error initializing SpringLiquibase
java.io.FileNotFoundException: ServletContext resource [/] cannot be resolved to URL because it does not exist
at org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:156) ...
The same problem was noted already here on stackoverflow and the answer was that new version of Spring Boot 1.2.1 contains a patch for this issue but it seems still to be a problem with SB 1.2.1 and liquibase 3.3.0 (this is the version number of liquibase that SB 1.2.1 provides by default).
I'm just wondering if others who are using SB 1.2.1 and liquibase observe the same issue and maybe there is a solution to it.
Yes, I observe the same, my solution was to use a previous liquibase version, as it seems SB 1.2.1 still has problems with 3.3.1.
This version did the trick:
<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
<version>3.2.1</version>
</dependency>

Resources