Environment :
Spring 4
Hibernate 4
MySQL
Spring MVC REST
Issue :
I am writing a simple REST based application for CRUD operations.
The architecture/components is below :
I have below design issues :
1. In Spring Application , the best practice is to have two separate contexts -
i) applicationContext : initialised through ContextLoaderListener (for servives abd daoLayerClasses)
ii) webApplicationContext : initialised through Dispather servlet (for Controllers/view Resolvers)
2. However I haven't seen any sample Spring REST based application using BOTH THE CONTEXTS above. Only Dispatcher servlet appraoch is used.
3. So , will creating two separate contexts for REST based application as shown in above architecture be an overkill and unnecessary ?
Or It is better to create two contexts separating SPRING REST layer in WebApplicationContext (#RestController) and ApplicationContext containing
(#Services,#Repository)
I think it is totally unnecessary to create separate contexts for your Controllers and Service/Repository classes unless you were thinking of having multiple Dispatchers or something like that. Generally you should keep it simple and have as few contexts as possible.
The answers to this question will be subjective, but as mentioned in other threads and in the Spring MVC docs two contexts are typical, but not the only way to do it.
I think the main reason is to separate them is when you have UI and APIs. They may depend on the same backend services, but probably shouldn't have co-mingled beans.
Related
I'm a little confused by the mixed use of JSF2+Spring+EJB3 or any combination of those. I know one of the Spring principal characteristics is dependency injection, but with JSF managed beans I can use #ManagedBean and #ManagedProperty anotations and I get dependency injection functionality. With EJB3 I'm even more confused about when to use it along with JSF or if there is even a reason to use it.
So, in what kind of situation would it be a good idea to use Spring+JSF2 or EJB3+JSF2?
Until now I have created just some small web applications using only JSF2 and never needed to use Spring or EJB3. However, I'm seeing in a lot of places that people are working with all this stuff together.
First of all, Spring and EJB(+JTA) are competing technologies and usually not to be used together in the same application. Choose the one or the other. Spring or EJB(+JTA). I won't tell you which to choose, I will only tell you a bit of history and the facts so that you can easier make the decision.
Main problem they're trying to solve is providing a business service layer API with automatic transaction management. Imagine that you need to fire multiple SQL queries to perform a single business task (e.g. placing an order), and one of them failed, then you would of course like that everything is rolled back, so that the DB is kept in the same state as it was before, as if completely nothing happened. If you didn't make use of transactions, then the DB would be left in an invalid state because the first bunch of the queries actually succeeded.
If you're familiar with basic JDBC, then you should know that this can be achieved by turning off autocommit on the connection, then firing those queries in sequence, then performing commit() in the very same try in whose catch (SQLException) a rollback() is performed. This is however quite tedious to implement everytime.
With Spring and EJB(+JTA), a single (stateless) business service method call counts by default transparently as a single full transaction. This way you don't need to worry about transaction management at all. You do not need to manually create EntityManagerFactory, nor explicitly call em.getTransaction().begin() and such as you would do when you're tight-coupling business service logic into a JSF backing bean class and/or are using RESOURCE_LOCAL instead of JTA in JPA. You could for example have just the following EJB class utilizing JPA:
#Stateless
public class OrderService {
#PersistenceContext
private EntityManager em;
#EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
If you have a #EJB private OrderService orderService; in your JSF backing bean and invoke the orderService.placeOrder(newOrder); in the action method, then a single full transaction will be performed. If for example one of the updateQuantity() calls or the persist() call failed with an exception, then it will rollback any so far executed updateQuantity() calls, and leave the DB in a clean and crisp state. Of course, you could catch that exception in your JSF backing bean and display a faces message or so.
Noted should be that "Spring" is a quite large framework which not only competes EJB, but also CDI and JPA. Previously, during the dark J2EE ages, when EJB 2.x was extremely terrible to implement (the above EJB 3.x OrderService example would in EJB 2.x require at least 5 times more code and some XML code). Spring offered a much better alternative which required less Java code (but still many XML code). J2EE/EJB2 learned the lessons from Spring and came with Java EE 5 which offers new EJB3 API which is even more slick than Spring and required no XML at all.
Spring also offers IoC/DI (inversion of control; dependency injection) out the box. This was during the J2EE era configured by XML which can go quite overboard. Nowadays Spring also uses annotations, but still some XML is required. Since Java EE 6, after having learned the lessons from Spring, CDI is offered out the box to provide the same DI functionality, but then without any need for XML. With Spring DI #Component/#Autowired and CDI #Named/#Inject you can achieve the same as JSF does with #ManagedBean/#ManagedProperty, but Spring DI and CDI offers many more advantages around it: you can for example write interceptors to pre-process or post-process managed bean creation/destroy or a managed bean method call, you can create custom scopes, producers and consumers, you can inject an instance of narrower scope in an instance of broader scope, etc.
Spring also offers MVC which essentially competes JSF. It makes no sense to mix JSF with Spring MVC. Further Spring also offers Data which is essentially an extra abstraction layer over JPA, further minimizing DAO boilerplate (but which essentially doesn't represent the business service layer as whole).
See also:
What exactly is Java EE?
JSF Controller, Service and DAO
#Stateless beans versus #Stateful beans
There's no real easy answer here as Spring is many things.
On a really high level, Spring competes with Java EE, meaning you would use either one of them as a full stack framework.
On a finer grained level, the Spring IoC container and Spring Beans compete with the combination of CDI & EJB in Java EE.
As for the web layer, Spring MVC competes with JSF. Some Spring xyzTemplate competes with the JPA interfaces (both can use eg Hibernate as the implementation of those).
It's possible to mix and match; eg use CDI & EJB beans with Spring MVC, OR use Spring Beans with JSF.
You will normally not use 2 directly competing techs together. Spring beans + CDI + EJB in the same app, or Spring MVC + JSF is silly.
I know that Spring is most useful for dependency injection. But what I don't understand is how do I have one common "ApplicationContext ac=....." for the whole project, lets say I have a WebApplication and it has multiple number of packages but all of them still in one project , so how do I make the ApplicationContext instantiate only once. I had read somewhere that in Spring objects are initialized only once something as singleton beans but what I dont understand is that how is it different than Singleton design pattern, there is one question on this in SO but I couldn't quite clearly understand the answer as I am a newbie to Spring trying to learn by myself. Any help would really be appreciated. Sorry if the Q is too long. Hope I was able to explain my doubt clearly.
Spring veans are by default Singleton, although it is possible to configure them as prototype which means that a new bean will be created upon each request. In practice, singleton means one instance per context and are their lifecycle is managed by Spring nwhich also provides hooks into the various stages. Spring does not manage prototype beans once they have been created.
It is common in a SpringMVC application to have more than one context (one for the business services, the other for the web controllers). You would only need to create an ApplicationContext when building a standalone application. SpringMVC applications use the ContextLoaderListener to create the necessary contexts.
I am new to spring and I am creating a simple web application. I have been reading about contexts in Spring MVC.
I am using STS plugin for eclipse. I created a
Spring MVC project using the plugin.
Now I have three xml documents in the project, web.xml, root-context.xml and servlet-context.xml. These were created by STS for me.
In web.xml, dispatcher servlet is pointed towards servlet-context.xml and I understand the dispatcher servlets job is to create a web application context which knows how to resolve views and is a place for controller beans to exist.
Is my understanding correct? If so, what other job is accomplished by this context?
Now, there is a file called root-context.xml which has a component scan on my projects default package. My understanding is this context needs to have global beans which many servlets might use. Is my understanding correct? What else does this do? What kind of context is created using this file?
Now, I am further along in the project and I have several *-context.xml files (dao-context.xml, security-context.xml etc) which are loaded using contextLoaderListner (in web.xml). Is this a good idea? Or should everything go into servlet-context.xml? I think it's a good idea to have different contexts as it provides separation of concern. Comments? Also, what kind of context is created from these *-context.xml files? What is the proper folder location for these files?
Web.xml is for the servlet container like tomcat etc and all other xml files in the project are for the spring container. Is that correct? All these files are separated to provide separation of concern?
How many application contexts and web application contexts exists in the current scenario?
Why would anyone need more than one dispatcher servlet?
Why would anyone need more than one application context?
Thoughts? Comments? Corrections? Best practices?
The whole idea behind this design is to handle different architectural layers in a typical web application and provide for inheritance / override mechanism for beans across contexts. Each type of context in Spring is related to different architectural layer for e.g, web layer, service layer etc.
A Spring based web application can have multiple dispatcher servlet configured (although in majority of cases its a single servlet - but dispatcher serlvet is a servlet nonetheless and there could be multiple configured in web.xml). These can be configured to handle different url patterns. So obviously each is a different servlet and hence can have different Spring web Application context. Each of these can contain different configurations for Spring web layer like controllers,interceptors,view resolvers,locale resolvers etc. as these typically belong to the web layer of an application. All these configurations and beans are private to each dispatcher servlet so they are not visible to each other. Hence having a seperate spring web application context makes sense to enable this privacy. However there are other beans which are designed to be shared hence belong to a root context. So all the shareable things belong to the root context and it can be considered global for this web application.
Each dispatcher servlet inherits all the beans defined in the root context. However the important point to note is that the shared beans can be overridden by respective dispatcher servlet specific beans. So in web applications root context can be viewed as something which is inherited but can be overridden.
Well spring does not force you to have xml files in that way, you can very well work everything using only one xml file that would be servlet-context.xml and using only dispatcher servlet. Generally there are different files in order to define your service beans or dao beans, so this basically depends on your application design, for eg if you are using spring security you might want to add one more xml file something like security-context.xml like as I said it depends on design. You can actually eliminate context loader listener completely and still manage to do everything using dispatcher servlet.
Your question is too broad in scope, since you are new to spring may be you should get more details about spring containers and decide what suits your requirement.
I generally have my servlet-context.xml in WEB-INF and other configuration like service-context.xml in classpath, again this is no strict rule just how it suits me.
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