Doorgaan naar hoofdcontent

Adding custom properties to applicationcontext

For testing, I wanted the option to have the applicaitoncontext be modifyable.
Normally, I'd use the Spring4UnitRunner for testcases in combination with a @ConfigurationContext(...)

However, in this case,  I wanted to modify the applicationcontext, or more precisely, I wanted to override a property, with a different value for each test.
(overriding the properties for the entire test with a property-file should be easy, using @TestPropertySource)
Injecting the applicationcontext didn't work, as we receive a GenericApplicationContext, which cannot be refreshed.
So, we create our own applicationcontext, update the properties, and refresh the context:
    private ApplicationContext createApplicationContextWithProperties(String applicationContextXmlLocation, Map<String, Object> propertiesMap) {
        ClassPathXmlApplicationContext overridenApplicationContext = new ClassPathXmlApplicationContext(applicationContextXmlLocation);
        PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
        Properties properties = new Properties();
        properties.putAll(propertiesMap);
        configurer.setProperties(properties);
        configurer.setOrder(PriorityOrdered.HIGHEST_PRECEDENCE);
        configurer.setLocalOverride(true);
        configurer.setIgnoreUnresolvablePlaceholders(true);
        overridenApplicationContext.addBeanFactoryPostProcessor(configurer);
        overridenApplicationContext.refresh();
        return overridenApplicationContext;
    }

Important to note: localOverride to true, Order to highest, and ingoreunresolvable to true (which allows fallback to the existing properties)

Reacties

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

Windows batch scripting god ( java runtime switch)

 I am a batch scripting god. After a lot of pain, I managed to create a script which allows me to switch jvm's easily. For posterity, and my own flex skills, the script: @echo off rem set your local path to all the JVM's here. set jvmdir=c:\code\apps\jvms if NOT EXIST %jvmdir% goto invaliddir rem a little bit of manipulation rem first we remove everything before the jvms dir call set __temp=%%path:*%jvmdir%\=%% rem then we determine everything that follows after the next slash set __lastbit=%__temp:*\=% rem then we remove that lastbit, leaving only the entire directory and a \ at the end. call set __currentpath=%%__temp:%__lastbit%=%% rem then we remove the \ at the end set __currentjvm=%__currentpath:\=% if "%~1"=="" goto missingarg if NOT EXIST %jvmdir%\%1 goto unknowndir set __currentpath=%jvmdir%\%__currentjvm% set __replacement=%jvmdir%\%1 call SET path=%%path:%__currentpath%=%__replacement%%% CALL SET JAVA_HOME=%%JAVA_HOME:%__currentpath%=%__replacemen...

Using spring's @transactional to only roll back when you really want to

In spring you can use the @Transactional annotation to marcate public methods as transactions. Any exception thrown in such an exception causes a rollback... Any exception? No, spring only does so on runtime exceptions. Checked exceptions are allowed and do not result in a rollback. And even then, you can allow some transactions to rollback, or not, with the proper properties for the transactions. For examle, @Transactional(rollbackFor="MyCheckedException.class") will rollback for a specific checked exception, and similarly, you can use @Transactional(noRollbackFor="MyUncheckedException.class") for unchecked exceptions. Of course, you might want to make it a little simpler on yourself. This article on stackoverflow shows us a different way: we can use our own transaction handler by overriding spring's. Let's have a sample interface which defines whether an exception should perform a rollback: interface ConfigurableRollback shouldRollbackOnE...