We use Spring and are integrating Flyway in a webapp that uses DispatcherServlet and runs a background DB thread.
How do control the execution flow of Spring so the migration happens before it fires up? Delaying DispatcherServlet start and Controller creation should be enough for our purposes.
You can try Spring Boot flyway support http://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html
I havent used it, but I hope it run the flyway scripts before it "starts" the "real" application. (If not it would be quite useless)
What you really want is for Flyway to migrate the database before your persistence layer comes up.
Since your controllers already depend this persistence layer, you now need to make the persistence layer itself depend on Flyway. Using XML configuration, this can be achieved using a depends-on attribute as described in the official docs.
I think afterMigrate method of Flyway Callbacks are what you are looking for.
You could have flyway in a separate factory to your spring MVC stuff. That way you can force the factory with flyway and other business logic etc to be completely created and done before the specifically MVC stuff comes up.
I would recommend you separate these two concerns in to separate factories in any case as it separates the two contexts quite nicely.
One way to achieve this is to start the business logic/flyway factory with a listener that is before the spring MVC stuff...
Related
We are currently using Spring 3.2.3 + JPA (Hibernate). We use aspects for transaction support as opposed to annotations. We write out own entity services (read: repositories) to abstract the persistence away from our application.
I've read a lot about Spring Data and feel it would make our code considerably cleaner and more robust. I wonder though, are there any gotchas that I should consider before transitioning?
Thanks
If you're already on JPA the transition should be as easy as it can be: activate the repositories, point the infrastructure to your EntityManagerFactoryBean and off you go.
Transactions should just work fine as well. The annotation based usage within Spring Data is selectively activated for the repository beans only. They are configured to take part in existing transactions by default, so any custom larger scoped transaction setting should be in effect already.
I am using hibernate to persist data on a MySql database.
Now I am already configuring what my business model is in the hibernate configuration file.
What I am looking for is, are there any tools that on building/deploying the application will generate the Model Layer (POJOs), Persistence Layer and the Service Layer (Business logic) for the controllers to communicate with the database server. In short I wish to generated all the basic essentials from a single configuration point.
Ant or Spring or combination of other frameworks, anything that can achieve the solution.
Any reference to an existence thread or a handful document would be highly appreciated.
Thanks in advance.
Your closest bet is Grails.
I'm not a fan of what you'd like to do. Code generation can result in a brittle system.
spring roo can be also good option to look at as your stack is based on spring framework.
Another option which can be used is MyEclipse IDE for Spring this supports code generation based on domain/table.
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.
All websites state that the Spring core container is the basis for complete Spring framework i.e., it is used across
the all modules like AOP, JDBC module, Web module, etc. As per my understanding, the Spring core container's main purpose is
to inject dependencies, so avoiding the need of factory classes and methods. Is that correct?
Second question: When it is said, Spring core container is the basis for complete Spring framework (e.g., for Spring AOP). As per my understanding, in Spring AOP also, getting the object of classes like
ProxyFactoryBean is achieved by core container. Right?
Thirdly, it is stated that Spring core container avoids the need for programming the use of singletons. How come singleton
classes are avoided by core container?
yep
yep
All beans declared in Spring config files are singleton by default. They are instantiated when your application starts.
First off, your understanding of what you get from Spring is about right. So let's get on to your third question, the interesting one.
The key is it's not that you don't have singletons, it's that they're singletons by configuration. This is a vital difference, as it means you can avoid all the complicated singleton enforcement code (the source of frequent problems) and instead just write exceptionally simple programs that focus on the business end of things. This is particularly important when you are writing a program with non-trivial object lifetimes: for example, in a webapp it makes it very easy to manage the lifespan of objects that hold state associated with a user's session, since if the objects have session scope, they'll be “singleton per user session”. That's enormously easier to work with than many of the alternatives.
The fact that Spring can also help out with transactions is just perfect as transaction handling is distinctly non-trivial, and AOP is the best solution to them in Java that I've seen (other languages have other options open) with Spring supporting a pretty straight-forward way of doing it. Try to do it properly without if you don't believe me. Spring's pretty much wonderful.
I am starting to learn the Spring Framework. I came across this link but I can't understand in which order to learn from these?
Can anybody help me out?
The order of the entries on that page isn't organized so that you can gradually learn the concepts.
I'd rather advise you to try and go through the official Spring documentation first and take a look at the samples that come together with Spring. It'll give you an idea of the possibilities. Also, don't forget to make sure that you understand what the Inversion of Control (IoC) pattern is and why it's useful.
Here's what I'd recommend to someone starting out with Spring and IoC:
You should first try to use Spring in a very simple command-line application (hello world style).
Create an application context in xml and load it from your main method
Define a bean and retrieve it from your freshly loaded application context
Try to add a second bean definition in the application context and play with the bean definitions
Learn how to inject beans in properties, in constructors, ...
Play with those for a while in order to get a good feeling of what Spring core actually does for you (the IoC container) and how it can help you to decouple components in your code
Once you have a clear understanding of that, you can move on and read about Spring annotations and how you can either use xml or annotations (or even combine both approaches) to wire up your beans
You should only start using Spring in a Web application after having played around enough with the above. Once you have all that under control, then it'll be time to discover more advanced stuff and other Spring portfolio projects such as Spring Security, Spring MVC, Spring AOP, ...
The following are nice to have on the desk:
- Spring Configuration Refcard
- Spring Annotations Refcard
In any case, have fun! :)
I suggest you to learn from a books
I use Spring Recipes Second Edition to learn spring, the books is very technical and explain a good concept about spring