Doorgaan naar hoofdcontent

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 properties value should be true (default) or false
     */
    boolean on() default true;
    /**
     * Name of the bean containing the properties.
     */
    String propertiesBeanName();
}

/**
 * Condition that matches on the value of a property.
 *
 * @see ConditionalOnProperty
 */
class OnPropertyCondition implements ConfigurationCondition {
    private static final Logger LOG = LoggerFactory.getLogger(OnPropertyCondition.class);

    @Override
    public boolean matches(final ConditionContext context, final AnnotatedTypeMetadata metadata) {
        final Map attributes = metadata.getAnnotationAttributes(ConditionalOnProperty.class.getName());
        final String propertyName = (String) attributes.get("value");
        final String propertiesBeanName = (String) attributes.get("propertiesBeanName");
        final boolean propertyDesiredValue = (boolean) attributes.get("on");

        // for some reason, we cannot use the environment here, hence we get the actual properties bean instead.
        Properties props = context.getBeanFactory().getBean(propertiesBeanName, Properties.class);
        final boolean propValue = parseBoolean(props.getProperty(propertyName, Boolean.toString(false)));
        LOG.info("Property '{}' resolved to {}, desired: {}", new Object[] { propertyName, propValue, "" + propertyDesiredValue });
        return propValue == propertyDesiredValue;
    }
    /**
     * Set the registration to REGISTER, else it is handled during the parsing of the configuration file
     * and we have no guarantee that the properties bean is loaded/exposed yet
     */
    @Override
    public ConfigurationPhase getConfigurationPhase() {
        return ConfigurationPhase.REGISTER_BEAN;
    }
}
This allows us to have a service or component be available or not upon startup Moreover, it allows us to define two beans *under the same name*, as in:
@ConditionalOnProperty(value="usenew", on=false, propertieBeanName="myprops")
@Service("service")
public class oldService implements ServiceFunction{
// some old implementaion of the service function.
}

@ConditionalOnProperty(value="usenew", on=true, propertieBeanName="myprops")
@Service("service")
public class newService implements ServiceFunction{
// some new implementaion of the service function.
}

Reacties

Populaire posts van deze blog

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...