Copy MDC context map to worker threads of SimpleAsyncTaskExecutor - spring-batch

We are using using spring-core 4.1.X module and spring-batch-core 3.0.X versions for a spring boot application. We are using SimpleAsyncTaskExecutor for async working of threads. I need to copy MDC information from parent to child thread. I have seen using ThreadDecorators as best way to achieve this. But, i these are not available in version of spring we are using. Any suggestions on equivalent approaches with the spring versions we are using. If we cannot achieve using TaskDecorators, any suggestions on what is the other best way ??

I think you are referring to the usage of TaskDecorator that was added in Spring 4.3 as a means to create a custom MDC decorator and register it in a TaskExecutor, a process that is nicely described in this article.
Actually this is a great idea especially since SimpleAsyncTaskExecutor has also been upgraded in Spring 4.3 to support TaskDecorators.
If you cannot upgrade (which is the recommended approach) I don't think it's especially hard to extend SimpleAsyncTaskExecutor to offer a similar hook if you see what is actually happening under the hood.
Here's the original commit on version 4.3 for SimpleAsyncTaskExecutor to support TaskDecorator's

Related

How to use Axon with Vert.X

I have a CQRS/Eventsourcing architecture with 3 microservices. I implemented 2 microservices with vert.x 4 and I implemented CQRS/Eventsourcing without framework to improve my knowledge of this type of architecture. For the third microservice I would like to use AxonIq Framework but I have a problem with Aggregate annotation because it's not avalaible with vert.x but only with Spring.
I implemented a Spring microservice using Axon and everything work fine but I would like to know if someone can help me for use vert.x with AxonIq ? If anyone know a workaround for this problem ?
Thank
Axon Farmework provide something called Configuration API. You can have a look at the Configuration class but for making use of it, you need a Configurer, which will provide you all means of configuring your components!
On the ref-guide, you also have several examples of how to do the configuration using the API or Srring Boot. Example for Commands can be found here.
To help a bit more, I can also share a small project I made using Dropwizard and Axon Framework, meaning no Spring was used and all the Configuration was done through the API.
You can find it here https://github.com/lfgcampos/axon-playground/tree/master/chat-getting-started-dropwizard

Quarkus with EclipseLink?

Is it possible to use EclipseLink with QUarkus? Or is Quarkus too hardly coupled with Hibernate?
We are in the process of choosing our MP implementation and we want to stick as close to the reference impls as possible
I am not seeing much information on https://quarkus.io/guides/ or even this very forum to indicate that eclipselink too can be used with Quarkus.
Any pointers on why Quarkus is tied so tightly to a specific impl (if it is) of JPA would also be welcome
TIA
Rahul
You can use EclipseLink by adding it in your classpath as fxrobin mentioned. But it won't work for native image generation, nor will be integrated with the database connection pool, the transaction enlistment etc. Finally the startup time will be much longer.
The reason Quarkus focuses on Hibernate ORM is exactly for these reasons. Making Hibernate ORM work on native, making it do work at build time to speed startup time, smoothly integrating it with other areas takes a lot of time. Someone could make the same for EclipseLink with a few months of work ahead of them.
You can add EclipseLink in a class way as if you were in Java SE. But then you have to manage the transactional behaviour by code but not with annotations.

Using tapestry-jpa just with tapestry-ioc in non-web project

this is a very basic question, and I'm kind of sorry, but I don't seem to be able to get a simple Tapestry-IOC based application to work with the built-in Tapestry JPA module.
The application is not necessarily meant as a web project so the dependencies are just tapestry-ioc and tapestry-jpa for the JPA integration. I used the hibernate-entitymanager before and everything worked fine. But I thought I might rather use the official JPA support of Tapestry.
So what I did was to get the above mentioned dependencies (in Tapestry version 5.3.7) and to write the beginning of a test.
This beginning looks like this
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class);
EntityManager em = registry.getService(EntityManager.class);
That's all. Because as soon as I try this I get the error that no service would implement the EntityManager interface.
So I added the Tapestry JPA module:
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class);
But then again I get an error that the JpaModule wants to contribute to the ApplicationStatePersistenceStrategySource service which is not present. This service seems to be defined in the TapestryModule so I did
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class, TapestryModule.class);
But this causes an error due to the missing servlet API. So now I get to the point where I would have to define the web environment for Tapestry. But I don't want this, I just wanted to use the JPA integration.
Is this even possible? And if so, how do I do it? Following the documentation at http://tapestry.apache.org/integrating-with-jpa.html does not help in this regard.
Thank you very much for reading, any hint appreciated!
Quick answer -- I could be wrong -- but I thought Tapestry-jpa was intended for using JPA with Tapestry-core (the web framework). I don't think there would be any benefit over plain JPA in your case.

Spring AOP: <context:load-time-weaver> Vs <aop:aspectj-autoproxy>

I was looking for the option to profile my APIs. I found Spring AOP is one of the options to profile the methods.
There are two options in Spring AOP to configure and use the aspects:
context:load-time-weaver
aop:aspectj-autoproxy
As per my understanding first option (load-time-weaver) performs weaving at load time without creating any proxy objects. And second option (aspectj-autoproxy) creates proxy objects. Am I correct on this? I believe, creation of proxy objects may hit the performance. wouldn't it?
Which option is best to choose considering better performance? What are the pros and cons of both approaches?
Well, Narendra, first of all there are profilers for profiling software. Maybe there is no need to code anything on your own.
As for your question: I have not idea how to configure Spring because I never use it. I am an AspectJ user. What I do know though, is that Spring AOP always uses proxies (JDK or CGLIB, depending on whether you need to proxy interfaces or classes). This is, as you said, something you probably do not want for profiling. AspectJ, no matter if you use compile or load time weaving, does not need or use proxies and thus should be faster. If you are not already using Spring in your project anyway, I would not touch it just to satisfy your profiling needs. Furthermore, Spring AOP only works for Spring Beans and just offers method interception, not much more. AspectJ is a full-blown AOP implementation and much more powerful. If you are already using Spring, you have a choice of using Spring AOP, AspectJ within Spring or a mixture of both.

Vert.x - what's missing for Scala?

The Vert.x documentation says that Scala (and Clojure) will be supported 'soon'.
What's actually missing for using it with Scala as is??
So, as of 2013/11/04:
Scala support has everything up to Vert.x 2.0.2-final plus DNS support. So you need 2.1M1 of Vert.x core and the 0.2.0 release of Scala.
We need to add UDP support, EventBus timeouts (mostly done, but there seems to be a bug in the vert.x core project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420850 ), provide asynchronous registerHandler methods (as these changed to async style) and provide a solution for the unregisterHandler problem we were facing (probably use the asynchronous registerHandler to provide a RegisteredHandler object that has an unregisterHandler() method).
and a followup
Update: EventBus timeouts are done, waiting for review in pull request https://github.com/vert-x/mod-lang-scala/pull/77
I forgot to mention that HTTP Compression was also missing. Just added another PR to review here: https://github.com/vert-x/mod-lang-scala/pull/78
Also added docs for both of them.
To recap what's still missing:
UDP support + test + docs
asynchronous registerHandler methods + test + docs
unregisterHandler issue + tests + docs (I guess this should be done with the asynchronous registerHandler providing a AsyncResult[RegisteredHandler] => Unit callback)
Also announced today:
I'm really proud to announce the release of Vert.x Scala 0.2.0 which includes full Vert.x 2.0 API support as well as new DNS API support coming up in Vert.x 2.1. This means that mod-lang-scala 0.2.0 now requires Vert.x 2.1.
The amazing API work has been driven by the tireless Joern Bernhardt and his colleague Sascha Schmidt. Between them two they've added all the missing APIs and reworked the testsuite to add Scala specific testtools. This was a big tasks and both Joern and Sascha deserve full credit for pulling this off. Kudos to both for this fantastic work!! :). On top of this, we've also added the capability to deploy Scala scripts into Vert.x, bringing the Vert.x Scala examples in line with other languages.
For next release, 0.3.0, we'll be focusing on polishing some these APIs, adding new APIs that Vert.x 2.1 brings, documentation and more examples :)
While we complete the documentation, the best place to get started with the Scala language module is to look at the README file in the Vert.x mod-lang-scala repository.