I have a problem on my project implemented on JSF 1.2 (MyFaces 1.2.6) and integrated Spring.
The problem is about #PostConstruct annotation.
It is executed but I see that it is executed before managed properties are populated.
First I suspect about managed properties taken from Spring context so I tried a simple integer managed property, I see it is not populated too.
Do you have any idea?
Thanks in advance.
I have just solved it. It is a bug of MyFaces 1.2.6.
It is resolved when upgraded to 1.2.7
Related
I updated dependencies
org.springdoc:springdoc-openapi-ui
org.springdoc:springdoc-openapi-common
org.springdoc:springdoc-openapi-webmvc-core
org.springdoc:springdoc-openapi-webflux-core
from version 1.6.9 to 1.6.11. And now bean of class org.springdoc.webmvc.api.OpenApiResource doesn't initialize well.
I found that it should have been created in SpringDocWebMvcConfiguration.class, however I discovered that SpringDocWebMvcConfiguration.class didn't initialize itself after update of springdoc version, but on previous version it was initializing well. The only change they made in a new version of springdoc is annotation:
#ConditionalOnBean(SpringDocConfiguration.class)
on SpringDocWebMvcConfiguration, so it depends on SpringDocConfiguration.class. I printed all beans from my spring context by calling
context.getBeanDefinitionNames()
and figured out that context contains SpringDocConfiguration bean, but not SpringDocWebMvcConfiguration. May be somebody already had same issue and can help me?
I'm working with Spring Boot + Spring Data JPA and facing this problem when trying to inject a class that extends CrudRepository:
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'topicRepository': Could not resolve
matching constructor (hint: specify index/type/name arguments for
simple parameters to avoid type ambiguities)
Repository Class:
public interface TopicRepository extends CrudRepository<Topic, Integer> {}
Service Class:
#Service
public class TopicService {
#Autowired
private TopicRepository topicRepository;
}
Any suggestions?
I was having the same issue, and I fixed it by switching Spring Boot versions. Changing the Spring Data JPA versions did nothing (this is where I assumed the bug would be), so I think there is a bug in Spring Boot version 1.5.1. I switched back to version 1.4.3 and the error was gone. I didn't try subsequent/different versions, so you may just have to experiment with your dependencies and their versions.
For the record, you can have your service class annotated with #Repository, it shouldn't make any difference. I've been setting these apps up the same way using the service/dao pattern, and it has never been too picky with the annotations. Hopefully this may help others whose Spring Boot development flow suddenly throws an error!
Which versions of spring-data-commons and spring-data-jpa are you using. I just ran into this using spring-data-commons 1.13.x with spring-data-jpa 1.10.x. Upgrading spring-data-jpa to 1.11.x fixed the issue for me.
I too had the same issue after updating Spring Boot to 1.5.4.
I am also using spring-data-envers, which was at version 1.0.4. Upgrading to 1.4.1 solved the problem.
I hope it helps someone :)
Make sure:
1) TopicRepository is annotated with #Repository.
2) You have the scanning packages configured:
<jpa:repositories base-package="mypkg.repositories"></jpa:repositories>
Had the same issue on 1.5.2. Upgrading to 1.5.5 solved the problem.
You can use Applicationcontext to inject repository to this reference topicRepository..
You just declare applicationcontext in #rest controller class
Same like topicRepository by using annotation. Then you pass this to the service class which should take parms through constructor.
Ex-
public TopicService(Applicationcontext ctx) {this.topicRepository =context.getBean(TopicRepository.class);
}
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.
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.
Is there a possibility to configure spring so that it doesn't initialize beans with #Named annotations?
My current work around is to make such beans #Lazy so they don't get initialized when the application context is created, but I would prefer to have nothing related to spring in such classes.
Note this two options are not good for me:
1. Suggesting to go back to a previous version of spring that didn't support JSR-299 is not an
2. Putting JSF beans in a package that is not auto-scanned by spring.
You can try to exclude #Named using a filter when configuring component scanning (in <context:component-scan> or #ComponentScan).
See also:
4.10.3 Using filters to customize scanning