I am writing a Spring Boot service and wanted to include some form of RequestContext available to the controllers that might store things like the authenticated user and a request id. However, I see multiple approaches:
Use an #RequestScope bean
Use ServletRequest.setAttribute
Use Spring RequestContextHolder
What are the tradeoffs between these approaches?
Broadly speaking, RequestScope is the Spring magic way. It internally uses a RequestContextHolder which in turn depends on ServletRequest.setAttribute.
Said differently, the Spring way, is IMHO RequestScope. RequestContextHolder makes sense if you prefer limit the magic of Spring annotations.
Finaly, ServletRequest.setAttribute is still lower level, and should mainly be used if you want the code to be compatible with a non Spring application.
Moreover, for the first two ways, Spring uses a thread scoped object to store a reference to the request context, which allows the programmer to access the beans even in methods that do not explicitely receive the Request object.
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.
I recently readed carefully about the spring mvc 3 beans scope, specifically the web ones(session, request and global session) and i have some doubdts:
If i have a controller, why should i annotate him with other scope aside of singleton? I mean, the controllers are supossed to handle the requests and instantiate the view resources of all the app, so why give them a, for instance, session scope? what is the advantage of do that?
Is advisable making the services layer session scoped?
And finally, is there any convention or good practices that dictates where and when is more convenient the use each one of the web scopes? If there is, can somebody provides me the link or information about it? Not necessary convention or good practices, also your experience about it.
Thanks very much.
I mean, the controllers are supossed to handle the requests and
instantiate the view resources of all the app, so why give them a, for
instance, session scope?
In an average web application, you have various objects that exist on a per-session basis. Example can be user profile, or some kind of cabinet, or wallet, etc.
To be able to use those objects in service, every time you should get from session, and pass through the service chain. Instead of doing this, of course it is better to have those available in your service, without a need to pass it explicitly.
Really good example (in practice) you can find here.
An ideal practical example of request scope bean is HttpServletRequest, which should be unique obviously for each request, therefore it is request scoped and created for each request.
From my experience, without any explicit need for a case, you don't need to bother yourself with changing scopes. It is not without reason that default scope is Singleton, it is by purpose - because in most of the applications and basic scenarios you need beans as singleton. However as your main concern was with Session and Request scopes, the above examples are cases which you need often in web application.
I am a Struts2 and Spring newbie and looking for some insight. When we load a web application we would typically want to cache some default look up data. e.g. if we wanted to store states or other data that does not change frequently and add it to the application context where we can access it across the application. What is the best way to realize this in a Struts2 application integrated with Spring? I read a bit about annotating with #PostConstruct which means I define my own class/method that would get a handle to the context by calling ServletActionContext.getServletContext() and then use setAttribute to add something. Is that a good way of going about things or is there a better option? Or would simply implementing a ServletContextListener be ideal?
Thanks for any input.
If you want to use the ServletContext, use Spring's ServletContextAware interface and then use an #PostConstruct or afterPropertiesSet method to add items to the servlet context.
This is simpler to use than the listener and integrates seamlessly with Spring, giving you access to properties files declared in Spring and any other 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 using Spring framework. Should my service classes be created as singletons? Can someone please explain why or why not? Thanks!
Yes, they should be of scope singleton.
Services should be stateless, and hence they don't need more than one instance.
Thus defining them in scope singleton would save the time to instantiate and wire them.
singleton is the default scope in spring, so just leave your bean definitions as they are, without explicitly specifying the scope attribute.
You can read more about scopes in the spring docs.
Spring is easier to use if you stick with singleton-scoped beans. Singletons are its "default position", if you like. Yes, it supports other scopes (using scope="xyz" in the XML file), but it makes things harder to use and hurts performance.
Essentially, unless you have a good reason to do otherwise, stick with singletons.
You need mostly singletons. (Spring default.) Singletons must be thread-safe, because parallel requests will use the same single instance. In fact, they must be completely stateless, because it can be destroyed and recreated at any time.
If you need to keep track of state inside of your bean (you should not, this should be in the database or stored in the request), you will get many instances of the same type of bean, memory usage goes up with the number of requests, whereby with singletons you will still have just one instance.
Even if you scope you beans to a request, they must still need be at least thread-safe (requests coming from the same browser at the same time).
Service layer should be Singleton, otherwise for every incoming request a new object will be created and these objects are heavy contains business logic and lots of line of code. They must be Singleton.