This question already has answers here:
Spring JSF integration: how to inject a Spring component/service in JSF managed bean?
(4 answers)
Closed 7 years ago.
I'd like to do a login page for my web application. On my example project that I found on internet for integrating Spring Security and LDAP, I got it working. When I tried to integrate working example to real app, I'm always gettin NullPointerException.
You have both spring annotation AND jsf annotations on the same class, so if you refer to them by different names (like you most likely did seeing your own 'answer'), you get different instances. That is not good and the cause of your original problem. Most likely (and you did not post your xhtml) you referred to the bean in your xhtml as loginViewBean. Now you removed that AND (I suspect) you started referring to it as loginView, you got the Spring managed instance back with the authenticationManager injected, instead of the JSF managed one without the authenticationManger injected. This resulted in the NPE. That you got the Spring one back then is most likely caused by the SpringEL resolver that you configured having precedence over the default JSF resolver. So removing the #ManagedBean and #RequestScoped AND refering to the bean by the spring name would have solved the problem to and in a better way.
See also
Spring JSF integration: how to inject a Spring component/service in JSF managed bean?
Solved my question.
I just need to edit this line
#ManagedBean(name = "loginViewBean")
to
#ManagedBean
And do the rest configuration on login.xhtml file. And it's done.
Related
I am having a JSF application and I am using Spring for bean management. I registered all JSF beans as Spring beans and everything was running very smoothly. Now, I have got a requirement to use JSF's view scope, so it means I have to create a JSF managed bean (which I did using JSF annotations and all).
Now, I want to access this JSF bean in a Spring bean, certainly I cannot inject or get it using Spring's application context because Spring container doesn't know about this bean. So, currently in my Spring bean code I am getting this JSF bean using JSF's EL Resolver (examples mentioned here).
What I want to know is that is there any better way to do this?
My application is on Spring 4.0 and JSF 2.0 (MyFaces implementation), please let me know if you need any other information. I have not placed code because all my code is in remote server, moreover I think code is not required for this as there is no debugging over here.
Does anyone know a workaround for https://java.net/jira/browse/JAVASERVERFACES-3947 ?
In my project , I am using primefaces 5.3 , mojarra 2.2.12
wilfly 8.2.1
I profile the application , and I see ViewScopedManaged beans are not garbaged collected , and the heaps keeps increasing and increasing until there is a memory leak
In faces-config, I have this to integrate with Spring:
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
I think my issue is related to https://java.net/jira/browse/JAVASERVERFACES-3947 . Does anyone know a workaround ? I think there are some jsf parameters to configure the max number of views scopbed beans in memnory ? will it work out ?
This is an example of a bean class:
#ManagedBean
#ViewScoped
#Data
public class JSFBean {
//springBeanImpl is a Spring bean
#ManagedProperty(value = "#{springBeanImpl }")
private SpringBean springBean;
}
In our last JSF project, we did the following:
#ManagedBean
#ViewScoped
public class CountryBean extends SpringBeanAutowiringSupport {
#Autowired // you can also use #Inject
private SpringBean springBean;
}
So you don't use the newer CDI Annotations, but the 'old' ones from JSF. By extending your class from SpringBeanAutowiringSupport, Spring will handle the dependency injection. I suppose the JSF annotations will be removed one day and be completely replaced by CDI annotations. So that might not work in future releases of JSF.
About the garbage collection - are you sure that they are not removed at some time? Be aware that by default the last 25 Views are kept in memory. This link JSF 2.2 Memory Consumption: Why does Mojarra keep the ViewScoped Beans of the last 25 Views in Memory? explains it a little. Hopefully those parameters are better documented in JSF 2.3.
Anyway, as balusc mentioned - Spring and JSF are currently not the best combination since JSF relies more and more on CDI. I personally think that it is a pity that the current situation is like that. This was one of the main reasons why we stopped using JSF in new projects. It is just to unclear whether JSF and Spring will be less or more compatible in coming releases.
I would like to achieve this idealism :
To have only 1 implementation for the JSF Bean container, like to use only Spring or Weld but not both. Currently i am using Spring for my backend, so i prefer Spring.
To have only 1 annotation, to choose between #ManagedBean, #Named, #Model
To be able to use all supported scopes, like #RequestScoped, #SessionScoped, #ViewScoped, #FlashScoped, maybe also #ConversationScoped
The JSF Beans could be injected with spring-managed-services (The backend services), perhaps using #Inject or #Autowired
So far i've been finding no best combination to achieve these because as far as i know, please correct me if i am wrong, :
#ManagedBean can not be injected with spring services ?
#Named can be injected with spring services using #Inject, but #Named is using Weld. Can i just use spring to managed the #Named instead of Weld ?
#Named doesnt support #ViewScoped and FlashScope ?
Please share your thoughts and experiences.
Thank you :-)
UPDATE 15 March 2011
Found an interesting page that describes how to replace Jboss Weld with Spring as the JSR 299 CDI implementation. So basically, the question number 2 is answered. Number 1 is also answered indirectly since i can now inject spring services.
But still, the number 3 question remains. I would find very helpful if i can use the #ViewScoped and Flash Scope in the #Named, something like this article. Flash scope implementation has yet to be seen, but the closest one i can get so far is this page.
Hopefully, replacing weld with spring as the jsr 299 implementation will still enable me to use #ConversationScoped.
Gotta test things now, wish me luck :-)
UPDATE 18 MARCH 2011
Successfully make use of Spring 3 instead of weld to do the #Named, #Inject. The important thing is to set the el-resolver in the faces-config.xml.
AFAIK, Spring 3 currently doesnt support CDI yet, so bye2 #ConversationScoped.
For the scoping, i must still use #Scope("request") or #Scope("session"), but if i prefer the #RequestScoped (javax.enterprise.context.RequestScoped) and #SessionScoped, i can make use of the bridge provided from this article.
The Scope("view") for spring from this article works like magic :-)
One problem remain though, how to pass objects between Scope("view")-beans ..
Wish me luck !
update
Ahhh .. finally done ..
Passing the variables using Flash provided by JSF2 really works like magic.
I dont need an 3rd party implementation for that.
So basically, i can do without weld, but with spring, with the common scopes available, including the view scope, dan can pass between beans using the flash object.
One thing missing is the conversation scope, which isnt a major problem to me yet.
Hopefully the future spring can support this conversation scope.
Cheers :-)
I can successfully Inject Spring bean using ManagedProperty annotation like below. This is on JSF Managed Bean. Spring bean is for backend and I prefer spring for backend.
#ManagedProperty(name="userRepository", value="#{userRepository}")
private UserRepository userRepository;
//Setter and/or Getter
value is the most important thing here. It's actually the bean name of spring. I hope this helps.
Weld (actually, the reference implementation of JSR-299 Context and Dependency Injection, also known as Java EE 6 CDI) was less or more invented to supplant Spring in Java EE 6 environments. I would suggest to use Java EE 6 CDI instead of Spring. Why would you use a 3rd party framework when Java EE 6 provides the same functionality out the box?
If the Spring backend really cannot be changed, then I'd suggest to stick to it and not to intermix with Java EE 6 CDI annotations to save yourself from confusions and maintenance headache.
I'm trying to understand the best way to use Spring (for dependency injection) with ICEfaces (Spring 3, ICEfaces 1.8.2, JSF RI 1.1).
Regarding the Spring reference manual, there are several possibilities to handle EL resolutions of beans:
If I use SpringBeanVariableResolver (which look best at first sight):
Beans that are refered in an EL-Expression will be managed by Spring
BUT the missing "extended request"-scope of Spring will cause problems, won't it?
If the DelegatingVariableResolver is used:
Beans that are refered in an EL-Expression will be managed by JSF
I need to define the EL-aware beans in faces-config.xml, which means I'm restraint to the limited options (e.g. no constructor DI).
Bean declarations are scattered across different files
Is this correct? Any suggestions? Hints? Best practices?
I ended up in mixing common JSF DI with Spring DI. That means that I inject Spring beans as JSF managed properties.
i have a JSF web application. I use Beans as Spring Beans (not JSF managed beans). Now i have an URL to application www.example.com?parameter=2
I would like to set this parameter into bean on the page load. I now how to do this with spring web flow but with JSF Navigation i cant do this.
What do you think about using JSTL c:set or jsp:setProperty?
Thanks for your help.
Kind regards
Sebastian
From here:
One could extend a Springs org.springframework.beans.factory.config.PropertyPlaceholderConfigurer which accesses the RequestContext (org.springframework.web.context.request.RequestContextHolder#getRequestAttributes()) to resolve ${xyz}-like properties in the bean.
Of course that would only work for Spring beans with “request”-scope.
If the bean is in session-scope you could simply use the following in a Phase Listener method:
property = FacesContezt.getCurrentInstance().getExternalContext
.getRequestMap().get("paramName");
the phase listener is defined with
<f:view beforePhase="#{bean.method}">
if using facelets, its beforePhaseListener
If you were using faces-context.xml, you could've used the <managed-property>.