I need MDC Context to pass from one thread to another, I need it because when using #ASync it gets lost.
In the projects I have Spring version 1.3.8.RELEASE is used, this guy already comes with version 1.1.7 of LOGBack, in version 1.1.5 logback stopped supporting copying data to the child thread.
As can be seen here:
https://jira.qos.ch/browse/LOGBACK-422
, so it no longer does this by itself in my project.
There is one possibility, a very good possibility actually, which is using TASKDecorator.
However it is only available in version 4.3.x of SPRING:CORE, the version I use in the project only provides version 4.2.8.RELEASE.
Since I can't upgrade the Spring version and I can't downgrade logBack.
Is there another way out of this scenario? Copy context from MDC to Child thread without using TaskDecorator?
thanks in advance
Related
I have a Spring boot 2.25.1 application which is using Camel 2.25.1 with camel-kafka everything is working fine..
In my Kafka consumer, I have a need to add the feature to pause consumption on demand so I upgraded to camel 3.18.1 so I can use the pausable feature.
After upgrading to 3.18.1 I am getting error FileNotFound with class file TimeoutAwareAggregationStategy.class.
when I opened camel-core 3.18.1 jar this class does not exist which was available in came 2.25.1 version.
Please suggest.
I was expecting smoother upgrade from camel 2.25.1 to camel 3.18.1.
According to the Camel upgrade guide for Camel 2.x to 3, the camel-core was modularized and broken up into multiple jar files. In that upgrade guide, they mention a lot of changes to Aggregation Strategies. While I couldn't find a direct implementation of the AggregationStrategy interface called TimeoutAwareAggregationStategy, I can see that class exists in camel-core in version 2.25.4 and the AggregationStrategy interface is moved to camel-api in version 3.0.
I was expecting smoother upgrade from camel 2.25.1 to camel 3.18.1
Normally, when upgrading a major version to a newer major version, there will be major changes that you have to account for. These changes are almost always covered in the change list or upgrade guide.
Is there any Spring 5.0.6.RELEASE osgified version patch available? We have to to do quick release so need to upgrade older spring but currently our framework uses OSGI based container, though spring has officially stopped supported OSGI. Is it possible to have patched version of latest Spring framework?
Though I know it's better to convert to Spring based container but since time doesn't allow I'm in search of any osgified version of Spring jars.
Apache Servicemix produces osgified versions of a lot of well known libraries, Spring included: https://github.com/apache/servicemix-bundles
Currently the latest osgfied version of Spring is "5.0.5.RELEASE", with "5.0.6.RELEASE" probably due to come in the near future. Otherwise, getting servicemix pom.xml for 5.0.5.RELEASE and manually changing Spring version should work (from 5.0.5 to 5.0.6 there should be just internal implementation changes).
I am using the latest (by the time of writing) Spring-Boot-starter-data-jpa (version 1.2.6.RELEASE). I find it actually uses the Spring-data-jpa version 1.7.3.RELEASE, which is considerably behind the latest (1.9).
Is it a supported approach to upgrade individual dependencies such as the Spring-data-jpa? If I do this myself, for example, by declaring a direct dependency on the wanted newer version (may just override the version properties), any side effect you guys foresee?
The reason why I am doing this is that I need to use a special parameter in this annotation:#EnableJpaRepositories(repositoryBaseClass = JpaRepositoryWithI18n.class)
That is not available in the supplied 1.7.3 jpa library.
Any workaround would be appreciated too.
Thanks
EDIT:
I tested the following two ways: 1) declared a direct dependency to Spring-JPA-data 1.9.0 and excluded it from spring-boot-starter-data-jpa 2) upgrade Spring-boot-web-starter to 1.3.0m5
2) worked out well for me. This is also what dunni's answer suggested.
I have not tested Andi's answer as this is a new project, we could easily upgrade the entire spring boot and regression test it without worrying too much about side-effects.
But I can see Andi's answer is an easier approach than 1). More importantly, it shows how you can upgrade other dependencies independently -- just overide the versions in parent pom.
Thanks
Spring Data JPA 1.9 is part of the Spring Data Gosling release train. As described in the Gosling announcement you can use it with Spring Boot 1.2:
To upgrade to the new release train use the BOM we ship as described in our examples repository and configure its version to Gosling-RELEASE. If you’re using Spring Boot, upgrading to the release train is as easy as setting the Maven property spring-data-releasetrain.version to that version. Note, that to use Spring Data REST with Boot 1.2, you also need to upgrade to Spring HATEOAS 0.19.0.RELEASE (by setting the spring-hateoas.version property) and Jackson 2.5 or better (current 2.6.1 preferred, via the jackson.version property).
In short, add this to your pom:
<properties>
<spring-data-releasetrain.version>Gosling-RELEASE</spring-data-releasetrain.version>
</properties>
It's not supported in that matter, that the Spring Boot test cases don't include newer versions. So your application might work with the newer version, but there may be some errors. With minor releases it's more likely to work without problems than with major version upgrades. You can also upgrade Spring Boot to 1.3.0.M5 (you should note however, that this is a milestone version, not yet the release).
According to you what are the risks of using Spring 4 with the jersey-spring3 integration module?
I have tried to use Spring 4.0 with the jersey spring example and the example still works but i'm unable to identify risks linked to this usage.
I have started using Jersey 2.7 and Spring 4.0.x recently in a project. I have setup a context hierarchy to inject beans, so far, I have discovered only one limitiation but that does not seem relate to Spring 4 but rather to the module itself or the HK2 Spring Bridge.
To give more insight about my use. I have a XJC/JAXB-backed which is consumed by a common service, repository and exposed through JAX-WS, and now hopefully through JAX-RS.
The multi-context stuff works now with #Autowiredwith 2.8-SNAPSHOT. I have applied my changes and the 2.8-SNAPSHOT to 2.7. Here is the diff.
Edit (Michael-O; 2014-10-17): Here is a modified Spring module based off 2.11 with multi-context support.
Not an answer to original question, just related information
This may be a little premature, but the new Major 3.0 version of Jersey will be using Spring 4, in the new jersey-spring4 module. The new Major version will be built with Java 8. Though a new Major version will be released, the 2.x line will still be actively developed to keep support for Java 7
I'll update this post once 3.0 has been release.
For anyone interested, you can see this mailing list to see what the Jersey team has to say about the new 3.x line.
Not sure if you came across any issues but I currently face one. It is described in other thread.
Simply, using jersey-spring3 2.12 and spring 4.1.0.RELEASE in one maven project leads to following class incompatibility:
2014-09-14 01:15:44.175:WARN:oejuc.AbstractLifeCycle:main: FAILED org.eclipse.jetty.server.handler.HandlerCollection#696
db620[org.eclipse.jetty.server.handler.ContextHandlerCollection#27abb6ca[o.e.j.m.p.JettyWebAppContext#737d100a{/,file:/C
:/Users/Josef/Workspace/TransitCenter/src/main/webapp/,STARTING}{file:/C:/Users/Josef/Workspace/TransitCenter/src/main/w
ebapp/}], org.eclipse.jetty.server.handler.DefaultHandler#6968c1d6, org.eclipse.jetty.server.handler.RequestLogHandler#7
d986d83]: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependenc
yComparator()Ljava/util/Comparator;
java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparato
r()Ljava/util/Comparator;
at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationCon
figUtils.java:136)
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.