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
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.
What is the point of using spring transaction while we have database level transaction ?
If you use mysql, oracle or any other db in java, they provide methods to make things inside transaction then why spring transaction if I can do transaction using java DB driver methods ?
It's another layer of abstraction over the database transaction API. So if you wanted to use multiple databases with global transactions, Spring would allow you to do this. While I have never done it, I believe it would allow you to use DB2 and Hibernate together, for example.
Generally, what I've found is, if a feature is available in Spring, it's because there is a use case for it. They don't just put things into the framework without a reason.
Also, Spring provides declarative transaction demarcation, which produces more readable and maintainable Java code. The declarative approach lets us change the transaction strategy easily, without changing the code.
The Declarative transaction management approach allows you to manage the transaction with the help of configuration instead of hard coding in your source code. This means that you can separate transaction management from the business code. You only use annotations or XML based configuration to manage the transactions
We used Spring AOP along with Hibernate using this transaction strategy Here is an example, Spring AOP transaction mangement with Hibernate.
I am involved in building framework offering financial, non financial mobile services.
Underlying technology we are using is Spring 3.2 framework , especially Spring MVC.
Now Spring MVC offers many features by way of annotations.for example, to create controller just annotate class with #Controller annotation and you are done.besides this, there are many more things like handlers,adapters, exception resolver.
My question is.
As I already leveraged Spring framework and I know how to use Spring framework or customize by available hook points.and I might had did it but what about my framework users.
Should I create wrappers on above offerings by Spring so that my framework user does not need to know or learn Spring framework?
For example, Spring provides flexibility to register exception handlers to handle exceptions but for that we need to create bean entry for required exception handler and need to register in exception resolvers class and its his job to dig into Spring details to get idea how they have provided exception handlers and all those stuff.
He needs to do exactly same as I already did.
instead of that Should I provide some provision so that user just can define bean entry for their exception handler and register it in my framework provided registry, not in Spring provided bean class?|
Spring already provide all those features, is widely used, is well documented, have thriving community, etc.
You should expose them directly so the user of your framework can easily adapt to your framework.
You should not try to hide Spring.
No matter how hard you try, your abstraction will leak,
and then the API users will need to know Spring anyway.
See http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Im working with the Spring Framework 3.0.5 and the Hibernate Framework and Im starting to use now Springs Transactionmanagement. I have some questions, just to understand how Springs Transactionmanagement works.
1)
I read this things in the Spring reference:
a) Consistent programming model across different transaction APIs such as Java Transaction API (JTA), JDBC, Hibernate, Java Persistence API (JPA), and Java Data Objects (JDO).
b) Spring resolves the disadvantages of global and local transactions. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments.
c) Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions such as those on JDBC connections, and face a hefty rework if you need that code to run within global, container-managed transactions. With the Spring Framework, only some of the bean definitions in your configuration file, rather than your code, need to change.
From a) I understand that I can use those APIs with Spring without changing the code
From b) I understand that I can use global or local transactions *without changing the code
From c) I understand that while switching between different APIs and global/local transactions I need to change the code
Now I wonder what is correct?
=> Do I need to change the code? When switching between different APIs? When switching between local and global transactions? (Or does it maybe depend on prorgammatic and declarative transaction management?)
2)
I also got an additional question: I really wonder what the use of programmatic transaction management is? Everywhere I read that declarative transactionmanagement is recommended
I read this in spring reference too:
d) With programmatic transaction management, developers work with the Spring Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence do not depend on the Spring Framework transaction API, or any other transaction API.
From d) I understand: with programmatic transaction management I can use any underlying transaction infrastructure... which means what? the different APIs mentioned above?
and: with declarative I do not depend on any api
=> isnt this the same? when I can use any underlying api, I do not depend on any api. I do not really understand this.
where is the difference? I only know that the declarative transaction management is more lightweight, that I have not to start the transaction by my self and catch the exception and handle it and so on. But what is the use of programmatic transaction management then?
Thank you for answering! :-)
You're over-thinking this a bit. The Spring API provides an abstract transaction model that has the same API and semantics regardless of which underlying transaction technology you use. In order to switch from one technology to another, you generally have to alter your Spring config, but the idea is that you never needs to to alter your business logic. So whether you're using local, in-VM JDBC transactions or fully distributed, two-phase-commit XA JPA-style transactions, the API usage within your Spring code is the same. Only the configuration changes.
The difference between declarative and programmatic transaction management is that with the former, you use annotations or XML config to say which bits of code are supposed to be transactional. With programmatic style, you specifically enclose transactional logic using method calls into the Spring API. Note that if you use the declarative style, then Spring will wrap your code in generated logic which uses the programmatic style. The latter is simply a more explicit and low-level version of the former. It gives you more control, but it's more verbose.
I have a GWT application where its RPC services are handled by a GWTHandler bean so that it can integrate with Spring smoothly. The application works. No problem with that.
My issue is I can't do any AOP logging with Spring. I like to log user activities from the GWT interface using AOP. (I could of course do it the old way of calling an RPC service for every action that a user does and log those action, but that is not the AOP way). I have to do it in AOP because that's the client's requirements.
I tried using the normal Spring AOP with a generic pointcut pattern "execution(* .(..))". It's able to capture all methods except for the GWT services. So in other words, it's useless. I could of course log the backend Spring DAO's using AOP but how do I know which RPC service it came from? These DAO's are used by numerous classes and methods (not exclusive to GWT).
I tried exploring GWT-ENT package. It looks good. However, it works on the client's side and your classes must implement Aspectable. This means requiring changes on all client classes on my GWT application. Furthermore, you can't use private methods since to handle AOP with GWT-ENT, you need to create your classes via GWT.create instead of the new(). Having private methods throws an error. I set-up a simple application and really private methods don't work.
I tried searching the GWT-SL package (where my GWTHandler came from). They mentioned about something about AOP, but the info is very scarce. Google didn't give me any solutions or examples.
I've tried everything I could think of and searched Google with all my efforts but I can't find a solution to my problem.
All I want to do is log methods from my GWT services via AOP. Let's say a client goes to the Report tab. Then he click on Delete button record. I want to log that activity via AOP.
I'm using GWT (with SmartGWT) and Spring/Hibernate stack.
Spring AOP will only advise public methods of beans in your Spring context, so GWT infrastructure is out unless you specifically instantiate it through the Spring container.
You could use compile-time weaving with AspectJ to wire your AOP into everything, but it might get a bit messy. It's also uncertain that it would work, unless you are compiling the GWT classes in question.
I'm gonna answer my question.
Instead of performing AOP logging on the GWT server implementations (which theoretically should work but in practice it's not), I decided to do AOP logging on the DAO layer. Just make sure you log the DAO not the Hibernate Session