WI have a question about the "Best Practice" Design for controller beans.
I was reading this very good question and the linking article:
Question "JSF backing bean structure (best practices)"
Scoping Best Practice
Online Article
Distinctions between different kinds of JSF Managed-beans
My question is concerning the controller bean. I'm using JSF / Spring and was wondering why I would want to use request scope for Controller beans?
The controller logic being defined as "...execute some kind of business logic and return navigation outcome.." I would think doesn't require a request scope but either session/application scope. Why keep creating those controller objects on every request?
In my case I would create the controller bean in the faces-config obviously and inject it with my managed properties through spring.
Thoughts please around the scoping? Thanks.
Clarification:
Using JSF 1.2, Spring 3. Using faces-config.xml to declare my beans. Not through annotations.
Related
I am actually a EJB developer and very new in spring framework.
i find a couples of conflict conceptually. Like ..
#RestController use by default scope which is singleton. By single object per loc have to manage heavy trafic.
is it a good design?
Of course, it is a good design because the same instance of the object will be reused instead of keep creating it each time you need it. That is the whole point of that design pattern.
Here is a great example where singleton comes to the rescue.
https://rules.sonarsource.com/java/RSPEC-2119
By default, spring will take care of the creation and destruction of all singleton beans, while the prototype has to be manually handled. Therefore in a lot of cases prototype scope is for custom beans made by developers.
In SpringMVC Controller layer, #Scope("prototype") vs #Scope("singleton")
is it a good design?
Yes, all beans in Spring are singletons (by default).
We have 100+ controllers in several applications and it works perfectly.
If you really need to instantiate controllers more than once, you can, of course, consider other bean scopes (see brief explanation of scopes here https://www.baeldung.com/spring-bean-scopes)
I would like to give you some context first.
The Context
I am currently developing a web application using Spring framework, where I would like to provide users with displaying/editing different instances of the same entity type of model in separate tabs. For displaying and retrieving attributes of these entities, I am using Spring managed beans with matching Data Transfer Object instances and with #Autowired annotated instances of service layer interface implementations for persisting the data.
Because I have experienced, that Spring's session scoped beans are not suitable for multi-tab editing and request scoped beans cannot hold the submitted data "long enough" for redisplay, I have implemented a "custom" scoped view beans. That seems to work fine for displaying and editing multiple same type pages (and entities on them) and for holding the data as long as the bean's action methods return void/null.
Navigating between pages is currently done by the String type return value of the destination page on the bean action methods send to the components like h:commandLink and h:commandButton to be resolved by JSF or by using simple html links.
The Problem
How do you navigate with one h:link/h:button to another page and ALSO pass it parameters to display by a Spring view scope bean after page landing?
Is there a way, how to redirect to another page at first -- for example from a page with list of system users, and then displaying details of a user passed from the launching page?
Questions to be answered and possible solutions?
If I have understood and implemented it correctly, they are already managed and injected with Spring, so they cannot work exactly as JSF's ViewScoped beans, so I cannot easily use their attributes annotated as JSF managed and pass them values of parameters for displaying them on a details/edit page AFTER navigating to it. When I try it, it results in a "CDI #ViewScoped bean functionality unavailable" error message. I think, that for the same reason using #ManagedBean annotated JSF beans and it's f:viewParam on destination page did not work. Is that correct?
I have tried passing parameter to Spring view scoped bean's function with return value of a destination page, but obviously(?) the bean gets recreated after landing on it with it's parameters emptied. Trying to define navigation rule for a Spring view scoped bean's action with the void return type and a landing page name also did not work. It seems like the Spring bean was not recognised in faces-config.xml. Is it so?
Should I use some longer-lived Spring bean's method for calling the view scoped one's constructor with the right parameters? But how do I prevent the view scoped bean's recreation after redirecting?
Switching from view scope to session scope would solve my problem, but it would result in a bad user experience as I see it and given, how my application should work with multiple tabs of the same type instances for the same user.
Passing and retrieving the secured parameters by a view scoped bean from the url address seems to me as maybe not the best security practice. But I am also using Spring Security roles in UI, service layer and url intercept as well as AOP on my service methods for checking the owner of retrieved data. Would be using some data identifier in the url be the only solution possibly working? Is it a worse/better solution from the point of security than using session scoped beans?
I welcome and thank you for every advice you could give me, because this is my first Spring pet project and I am learning on the way.
I am developing Spring MVC app, i need to implement singleton pattern for some kind of utilities, ex: imageuploader and others.
My question is: in what way to implement singleton for this utilities, to initialize beans for these classes and inject where i need like Controllers, Services, DAO?, or to use static field implementation of singleton to keep instance of this class?
First, try to avoid singleton as it's considered to be a bad practice. Also their interactions with other instances are difficult to test and validate, compared to non-singleton instances.
If you absolutely need it, I'd suggest you use a Spring bean so you can exploit the autowiring mechanism and Spring's bean lifecycle.
See the Beans section of the Spring reference doc for more info.
Using a Spring bean as will allow you to easily inject a mock in unit tests. However, you will only be able to access it from other Spring beans (or objects created by Spring beans that pass in a reference to it).
Also see this discussion in this question: Difference between static class and singleton pattern?
Traditionally, you'd use PropertyPlaceholderConfigurer to inject config from properties files into a Spring web-app. This blog discusses a variety of newer ways to do this with Spring.
I am working on a project that uses a hybrid of JSF and Spring-MVC. User interface endpoints are accessed through a JSF front controller (javax.faces.webapp.FacesServlet), whereas REST service calls are accessed through a Spring-MVC front controller (org.springframework.web.servlet.DispatcherServlet). Deeper layers are Spring-managed (more-or-less). I don't like this arrangement, but I'm not in a position to change it.
The problem is that Spring's request-scoped beans aren't initialized when processing requests that come in through the JSF front controller. Is there an off-the-shelf solution for integrating Spring's WebApplicationContext with the JSF machinery so that the Spring request-scoped beans are initialized for each request regardless of whether that request comes through the JSF or Spring servlet?
There are two ways to integrate JSF with Spring, depending on which framework you want to give most control:
JSF front controller:
One way is to route all requests via the JSF faces servlet and let JSF route them to controllers, let JSF manage navigation state via faces-config. Then inject spring beans into JSF managed beans and access spring beans from the facelets view using value expressions via SpringBeanFacesELResolver.
See this post for a working example.
Spring front controller: put spring as a front controller with a dispatcher servlet and put in place spring webflow. This is the preferred and most powerful way to integrate the two frameworks, see this section of the documentation.
Spring webflow will manage the navigation state and the faces config file is mostly empty. There is no need for the JSF managed beans layer, request get directly handled by webflow.
Actions in JSF buttons trigger webflow transitions directly, and spring beans can also be used in value expressions to build the view. With this solution the integration with Spring is more seamless as webflow offers more possibilities then the JSF navigation mechanism: trigger bean methods between transitions, post redirect get pattern for avoiding double submissions.
Namelly the problem with the initialization of spring request scoped beans is solved with this direction, altough an alternative for this is to add a RequestContextListener OR a RequestContextFilter to web.xml (see section 3.4.4.1 of the docs).
In case of REST implementations in Spring, spring Controllers are singleton. I want to know why spring controllers are singleton apart from thread-safety issue. Please help in resolving this issue.
This has nothing to do with REST.
Spring beans are, by default, singleton scoped. Since component scanning a #Controller annotated class simply generates a bean, that bean will be singleton scoped.
For reasons why a #Controller bean should be stateless, read any and all of the following:
Are Spring MVC Controllers Singletons?
Controller's life-cycle in Spring MVC
To follow up on the REST question, REST is meant to be stateless. In other words, each request contains all the information it needs for the server to handle it. Knowing that, it's pointless for the server (or #Controller) to keep any information after it's finished handling the request in instance fields and the like. Therefore a singleton is the way to go.