A well documented limitation of Quarkus CDI is
BEFORE_COMPLETION, AFTER_COMPLETION, AFTER_FAILURE and AFTER_SUCCESS transactional observers are not implemented yet
Will this functionality be implemented in future releases of Quarkus?
Yes, we do plan to implement transactional observers in Quarkus. There's already an open issue: https://github.com/quarkusio/quarkus/issues/2224. However, we don't have a schedule yet.
Related
I have a web application with controllers, services and simple beans.
I want to use Spring Integration as a glue to link the beans. So instead of using a reference to the next bean to be called in a bean I just want to send (return) a message (e.g. a domain object) which would be the incoming parameter in the method signature of the next bean.
Is it a good idea to use Spring Integration for this? Would SI degrade the performance?
Thanks,
V.
Please, read the Reference Manual (http://projects.spring.io/spring-integration/) and other resources before asking similar questions. Spring Integration isn't a glue.
It's an Enterprise Integration Patterns implementation Framework. Even if it can do what you are asking, its purpose is much farther.
I'd say such a requirements may be addressed just with the raw ApplicationEvent model.
As far as I understand, TestExecutionListeners act like #BeforeClass methods in JUnit. What I don't understand is why I need to use DependencyInjectionTestExecutionListener, TransactionalTestExecutionListener and DirtiesContextTestExecutionListener to use DbUnitTestExecutionListener.
Normally without DbUnit, I can create and populate the database. Why suddenly do I need to use these listeners to do some CRUD for my database?
TestExecutionListeners provide various types of functionality to tests running in the Spring TestContext Framework.
If you are interested in what a particular listener does, the best way to find out is to read the Javadoc for the respective class. In addition, the Testing chapter of the Spring reference manual goes into detail about how to use each of the listeners and what they do.
In your particular case, if you're not using #DirtiesContext, then you don't need to use the DirtiesContextTestExecutionListener. As for DependencyInjectionTestExecutionListener and TransactionalTestExecutionListener, you will likely need them to inject dependencies into your test (e.g., via #Autowired, #Inject, #Resource, etc.) and for transactional tests (i.e., tests annotated with #Transactional).
Note as well that the aforementioned listeners are enabled by default. So if you've been using the Spring TestContext Framework without any custom listeners like the one for DbUnit, then you just never realized that the listeners existed. The section on TestExecutionListener configuration in the reference manual should also help clarify things. Note, however, that some features like merging and auto-detection of default listeners are only available in Spring Framework 4.1+.
Regards,
Sam (author of the Spring TestContext Framework)
I am using struts2.0 for my project named online examination system.
I am using traditional JDBC approach in datya access layer. I can't use JPA.
I want to make entire service layer transactional, but i searched for the transaction support in struts2 but didn't get anything.
Although spring provides good support for making service layer transactional.
Please help me on this issue to find out transaction support in struts2.
You are on a wrong track here.Struts2 is only for MVC part and what you are doing at your service layer it has nothing to do with that.
If you want to take advantage of transaction API i suggest you to use either Spring AOP of if i am correct Google Guice also provides a way for AOP.
Whatever you use at your service layer for transaction handling Struts2 is independent of it and out of context
I am using the following versions:
Spring 3.1.1.RELEASE
Netty 3.4.0.Final
Hibernate 3.5.6-Final
Now, I have a Netty server that works fairly well - the root of the server, the pipeline factories and the base "stub" of the server that owns everything are all set up with Spring. In this stub, spring #Transactional annotations work just fine.
However, in the handlers, which are stateful and created dynamically depending on what state the user is in - #Transactional doesn't work. I'm fairly sure I understand why. I even have a "solution" - but it's not very good.
After the decoders and encoders, I add an ExecutionHandler:
pipeline.addLast("execution", new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(16,1000000, 1000000)));
This appears to be where the Spring transaction support is breaking. Since Spring is unaware of these threads, it can't bind any transactions to them. The classes are proxied correctly, but in debug they have no associated transactions.
My solution is crappy, and it needs to be replaced by a real solution:
Session sess = SessionFactoryUtils.getSession(getSessionFactory(), true);
That's bad because it relies on me to release the session, and it may not even be transactional, I haven't checked. It sucks in a lot of ways.
Anyway - the root of the question. Given the above tech, what's my path to getting my #Transactional notations working on the Netty handlers?
Write an ExecutionHandler that's Spring aware?
NOTE: I can't upgrade to Hibernate 4, due to lack of compatibility with Spring-Flex, used in another project in the group. Probably the same story for the Spring version, can't remember.
I suggest you create these netty's handler inside spring container and inject the service or persistence layer into the handlers so you can have these layers independence from netty and of course these are old school spring beans.
Spring Modules had a #Cacheable annotation:
org.springmodules.cache.annotations.Cacheable
Now that Spring Module is deprecated, what is the recommendation for caching? And is still still possible to work with ehCache?
Users of Spring Modules have rather been left out on a limb. There's no direct replacement for #Cacheable that I'm aware of.
Spring does have some support for EhCache, though, in the form of EhCacheFactoryBean and related classes (see javadoc). This gives a pretty easy way of creating and managing EhCache instances, but you then have to make use of it manually.
The distribute cache server is memcached. I has api to java.
http://memcached.org/
This project is intended as a direct replacement: http://code.google.com/p/ehcache-spring-annotations/
This is now found in spring-context. I have not checked how far back it is, but it is in the 4.1.4.RELEASE.
\org\springframework\cache\annotation\