I am trying to setup a bootstrapcacheloader which will query the database and populate the cache. Here I am using ehcache integrated with spring. But the problem is that I am not able to get the dependencies wired into my cacheloader implementation. The #Autowired,#Resource,#Configurable none of them seem to work. Quite obviously the cacheloader instantiation is not done by Spring container , but is there a way I can inject a spring created cacheloader instance into the cachemanager and bootstrap it?
My implementation details below.
ehcache.xml
<cache name="MyCache"
maxElementsInMemory="100000"
eternal="false"
overflowToDisk="false"
timeToLiveSeconds="500">
<!-- <pinning store="localMemory"/> -->
<bootstrapCacheLoaderFactory class="net.tristargroup.claims.helper.ClaimsCacheLoaderFactory" properties="bootstrapAsynchronously=true"/>
<cacheEventListenerFactory class="net.tristargroup.claims.helper.TristarCacheEventListenerFactory" listenFor="all"/>
</cache>
Spring Context xml
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">
<property name="cacheManager"><ref local="ehcache"/></property>
</bean>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" depends-on="cacheLoader">
<property name="configLocation" value="classpath:ehcache.xml"/>
</bean>
Cache loader class
#Configurable
public class ClaimsCacheLoaderFactory extends BootstrapCacheLoaderFactory{
#Resource
CacheManager cacheManager;
.
.
.
#Override
public BootstrapCacheLoader createBootstrapCacheLoader(Properties arg0) {
System.out.println("Create cache loader method . Cache manager is ->"+cacheManager);
BootstrapCacheLoader cacheLoader = new ClaimsCacheLoader();
return cacheLoader;
}
The cacheManager instance is always null here even if I specify it as an Autowired attribute.
The problem is present even in the cache event listeners.
Someone please help me on this.
If the cacheManager is null, Tthat means you haven't made the bean available to your package. Add a #ComponentScan("yourpackage") in the same place you defined your bean and add #Component where you want to use your cacheManager.
This is old, but i hope it helps someone else.
Related
I have a legacy product's JAR that contain Spring (4.3.8) managed classes. I need to integrate it with CDI (JavaEE 7).
I have an interface from the legacy JAR, that is implemented by a CDI bean. The CDI bean is requested from the CDI BeanManager and returned from a factory method. The factory method is registered inside Spring XML and works as expected.
The problem occurs, when a Spring bean of the legacy JAR depends on the implemented interface. Spring than injects the CDI implementation instance and scans the class it for known annotations, namingly #Inject. It then tries to resolve the dependency, which doesn't work since the dependency is not available to Spring.
I already tweaked context:property-placeholder excludes, but that changes nothing.
So how can I tell Spring to stop trying to inject something in my factory produced bean instance?
I finally was able to solve (work around) the problem. I had to remove all CDI-Annotations in the legacy JAR (by replacining them with their Spring counterparts), so spring would any longer work.
Then I added the following XML block to the applicationContext.xml of my CDI WAR:
<context:component-scan annotation-config="false" base-package="com.example">
</context:component-scan>
<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor">
<property name="autowiredAnnotationTypes">
<set>
<value>org.springframework.beans.factory.annotation.Autowired</value>
<value>org.springframework.beans.factory.annotation.Value</value>
</set>
</property>
</bean>
<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor" />
<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />
<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor" />
<bean class="org.springframework.beans.factory.annotation.CustomAutowireConfigurer">
<property name="customQualifierTypes">
<set>
<value>org.springframework.beans.factory.annotation.Qualifier</value>
</set>
</property>
</bean>
Basically that drops the support for #Inject, etc. from Spring and leaves it where it belongs: CDI.
It's a bit easier.
AutowiredAnnotationBeanPostProcessor is already a bean, so you can configure it before Spring starts to scan with a ServletContextListener to exclude #Inject annotations. At least from Spring 4.1+, AutowiredAnnotationBeanPostProcessor has a method setAutowiredAnnotationTypes, e.g.:
#WebListener
public class ApplicationConfigListener implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent event) {
ApplicationContext appCtx = WebApplicationContextUtils.getWebApplicationContext(event.getServletContext());
Set<Class<? extends Annotation>> autowiredAnnotationTypes = new LinkedHashSet<Class<? extends Annotation>>();
AutowiredAnnotationBeanPostProcessor bean = appCtx.getBean(AutowiredAnnotationBeanPostProcessor.class);
autowiredAnnotationTypes.add(Autowired.class);
autowiredAnnotationTypes.add(Value.class);
bean.setAutowiredAnnotationTypes(autowiredAnnotationTypes);
}
}
You could use a SpringBeanAutowiringInterceptor too.
This is explained here.
I'm trying to inject some #Service / #Repository bean defined in main application context into some jobs loaded by AutomaticJobRegistrar.
<bean class="org.springframework.batch.core.configuration.support.AutomaticJobRegistrar">
<property name="applicationContextFactories">
<bean class="org.springframework.batch.core.configuration.support.ClasspathXmlApplicationContextsFactoryBean">
<property name="resources" value="classpath*:/META-INF/jobs/*Job.xml" />
</bean>
</property>
<property name="jobLoader">
<bean class="org.springframework.batch.core.configuration.support.DefaultJobLoader">
<property name="jobRegistry" ref="jobRegistry" />
</bean>
</property>
</bean>
Using #Autowired inside my ItemWriter implementation class do not inject my services beans.
I have to enable component scanning inside each *Job.xml or declare each bean in order to make injection works, but injected classes are not the same instance of that one used by main application context.
How can I get the same instance bean declared in main application context?
Thank you for any advice
Did you activate context:annotation-config for each job?
If a new applicationcontext is created for every Job you need to activate this or no annotationprocessing (including #Autowired) will happen.
'context:component-scan' also activates 'context:annotation-config' so this might be the reason #Autowired works if you activate it.
I have next applicationContext.xml file on the root of classpath:
<context:annotation-config />
<context:property-placeholder location="classpath:props/datasource.properties" />
<bean id="datasource" class="org.apache.commons.dbcp.BasicDataSource"
p:username="${jdbc.username}"
p:password="${jdbc.password}"
p:url="${jdbc.url}"
p:driverClassName="${jdbc.driverclass}"
p:validationQuery="SELECT sysdate FROM dual" />
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"
p:dataSource-ref="datasource"
p:mapperLocations="classpath:mappers/*-mapper.xml" />
<tx:annotation-driven transaction-manager="txManager" />
<bean id="txManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
p:dataSource-ref="datasource" />
<bean id="mappeScannerConfigurere" class="org.mybatis.spring.mapper.MapperScannerConfigurer"
p:sqlSessionFactory-ref="sqlSessionFactory"
p:basePackage="com.mypackage" />
props/datasource.properties also exists on the root of classpath with such content:
jdbc.url=myjdbcurl
jdbc.driverclass=myClass
jdbc.username=myUserName
jdbc.password=myPassword
I have a spring managed test where I declare to use previously mentioned applicationContext.xml via next annotations:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath:applicationContext.xml"})
When I invoke test method i get next error from spring:
org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class '${jdbc.driverclass}'
As I understand sping didn't resolve reference to jdbc.driverclass.
What have I done wrong?
PS: I'm using spring 3.2.3.RELEASE
**
EDIT
**
Perhaps the problem may be in MapperScannerConfigurer. It is a BeanDefinitionRegistryPostProcessor and as Javadoc says:
Extension to the standard BeanFactoryPostProcessor SPI,
allowing for the registration of further bean definitions
before regular BeanFactoryPostProcessor detection kicks in
So MapperScannerConfigurer instantiates datasource object via sqlSessionFactory with BeanFacoryPostProcessor(which is responsible for <context:property-placeholder/>) have not been utilized.
So my question transforms to how to reorder BeanFacoryPostProcessor from <context:property-placeholder/> and BeanDefinitionRegistryPostProcessor(MapperScannerConfigurer)?
Resolved
After a couple hours of investigation I found the solution:
As I said earlier MapperScannerConfigurer is a BeanDefinitionRegistryPostProcessor which fires before BeanFactoryPostProcessor which is responsible for <context:property-placeholder/>. So, during the creation of MapperScannerConfigurer references to external properties will not be resolved. In this case we have to defer the creation of datasource to the time after BeanFactoryPostProcessorhave been applied. We can do that in several ways:
remove p:sqlSessionFactory-ref="sqlSessionFactory" from MapperScannerConfigurer. In this case datasource object will not be created before MapperScannerConfigurer, but after BeanFactoryPostProcessor which is responsible for <context:property-placeholder/>. If you have more than one sqlSessionFactory in applicationContext, than can be some troubles
In versions of mybatis-spring module higher than 1.0.2 there is a possibility to set sqlSessionFactoryBeanName instead of sqlSessionFactory. It helps to resolve PropertyPlaceHolder issue with BeanFactoryPostProcessor. It is a recommended way to solve this issue described in mybatis-spring doc
I was having the same issue and came across this post but I was unable to resolve it the same way maks did. What ended up working for me was to set the ignoreUnresolvablePlaceholders property value to true.
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>classpath:database.properties</value>
</property>
<property name="ignoreUnresolvablePlaceholders" value="true"/>
</bean>
I am using Spring 3.2.3.RELEASE as well. I realize this post is over 4 months old but I figured someone might find it useful.
Short form: What is the proper way to load an implementation of: BeanDefinitionRegistryPostProcessor?
Expanded form: Is there a way to load BeanDefinitionRegistryPostProcessor before any beans have been created. If you look at the javadoc:
Extension to the standard {#link BeanFactoryPostProcessor} SPI, allowing for
the registration of further bean definitions before regular
BeanFactoryPostProcessor detection kicks in.
So it's meant to be loaded when bean definitions have been created but before any beans have been created. If we just create it as a regular bean in the application xml then it defeats the purpose of having this bean in the first place.
I am working on a project and I need to set the following bean and property but I dont want to do it in XML.. I want to do it in JavaCofig style.. Can someone please show me how I would do this in javaconfig stlye
<!-- Spring Configuration needed to avoid URI using dots to be truncated -->
<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="useDefaultSuffixPattern" value="false" />
</bean>
Something like this should work:
#Bean public DefaultAnnotationHandlerMapping defaultAnnotationHandlerMapping(){
DefaultAnnotationHandlerMapping bean = new DefaultAnnotationHandlerMapping();
bean.setUseDefaultSuffixPattern(false);
return bean;
}
You can see my sample spring MVC app using code config here https://github.com/robhinds/spring-code-configuration-webapp/blob/master/src/main/java/com/tmm/web/configuration/WebMvcConfiguration.java
I am currently usinmg PropertyPlaceholderConfigurer to load properties into my spring context, however I want to have a custom hierarchy/overriding of property files that I am handling in a Java class. Can I have my class, which itself is a bean in the context, inject the properties into the context?
e.g.
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations" value="classpath:/config/conf.properties" />
</bean>
<bean id="config" class="com.main.Config" />
My Config class has a Properties getProperties() method -- can I wire that into spring somehow? Obviously the properties would not be loaded until the config bean is created or inited.
Thanks!
Update: As suggested by the answer I change my Config to Config extends PropertySource<Properties> and had to write a small wrapper around MutablePropertySources that takes a single PropertySource and then my xml looks like this:
<bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
<property name="propertySources">
<bean class="com.main.ConfigMutablePropertySources">
<constructor-arg name="propertySource" ref="config" />
</bean>
</property>
</bean>
Where:
public class ConfigMutablePropertySources extends MutablePropertySources {
public ConfigMutablePropertySources(PropertySource<?> propertySource) {
super(new MutablePropertySources());
addLast(propertySource);
}
}
Looking at the methods available (from JavaDoc for PropertyPlaceholderConfigurer) suggests to me no easy way to do such a thing.
The general comment at the top suggests that, as of Spring 3.1, one should prefer to use PropertySourcesPlaceholderConfigurer instead. Using this solution, it appears that you could register your own set of PropertySource objects via the setPropertySources(...) method. Of course your Config class would have to be fit into the interface (abstract class actually) of PropertySource.
It is worth noting that using the setPropertySources(...) method above will assume nothing else about your property sources and will therefore not add the default property sources (Environment and Local properties).