Posts Tagged ‘Java’

The @Bean annotation is a great way to declare Spring beans when writing code.  This allows the programmer to control which beans get instantiated and with what arguments.   Some situations call for deciding if beans should be instantiated at runtime based on configuration this is often done with the @Conditional annotation on @Configuration classes.   The @Conditional annotation works well if you are enabling or disabling a particular bean through configuration but sometimes the number of beans needs to be completely dynamic.

This often comes up if your application needs to connect to a bunch of external services such as a database.  You want the number of  services or databases that the application connects to be configurable.

(more…)

Spring integration makes it easy to monitor an sftp server for new files and inject those files into your application for processing.  I like to configure my spring integration applications with annotations and @Bean configurations.  I found the documentation, and online examples for doing this annotations a bit lacking.

 

This post demonstrates the basics on how to connect get a spring-boot (1.3.x or 1.4.x) application to monitor a sftp server.

(more…)

Sometimes the behaviour of an application is controlled through properties
and the application needs to detect changes to the property file so it can switch to the new configuration. You also want to ensure that a particular request either uses the old configuration or the new configuration but not a mixture of old and new. Think of this as ACID like isolation for properties to ensure that your requests don’t get processed using an inconsistent configuration.

We accomplish this by using a property lookup bean (PropertyBean) that returns property lookups. The PropertyLookupBean is a request scoped bean meaning that a new instance is created for each request in a spring MVC application. The PropertyLookup bean has an init method that runs post construction and calls the PropertyCache bean to get the current set of properties. Each instance of the PropertyLookup bean will return the property values from the Properties object it gets at initialization.

properties

The property lookup bean has a reference to a singleton scoped PropertyCache. The PropertyCache maintains a reference to the current Properties object. When the PropertyCache bean is asked to return the current properties it checks to see if they have changed on disk and if so reloads the properties.

class PropertyBean {
    private Properties currentProperties;

    @Autowired
    PropertyCache propertyCache;

    @PostConstruct
    void doInit() {
        currentProperties = propertyCache.getProperties();
    }
    public String getProperty(String propertyName) {
        return currentProperties.getProperty(propertyName);
    }
}

 

The PropertyBean would look similar to the above sample class. This class simply caches an instance of a Properties object post-construction and delegates property requests to this instance.

The PropertyBean needs to be created as a request scoped bean. This can be done with a Spring annotation configuration class as follows.

@Configuration
class MyConfig {
    @Bean
    @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
    public PropertyBean propertyBean() {
        return new PropertyBean();
    }
}

 

Managing the loading of properties falls to the PropertyCache class which would look similar to the below class

@Component
public class PropertyCache {
    private Properties currentProperties;
    private Long lastReloadTime=0;
    @Value("${dynamic.property.file.path")
    private String propertyFileName;


    public Properties getProperties()  {
         reloadIfRequiredProperties();   
         synchronized(this) {
             return currentProperties;
         }
    }

    private reloadPropertiesIfRequired() {
         FileInputStream stream = null;
         try {
             File f = new File(propertyFileName);
             if(f.lastModified() > lastReloadTime) {
                 Properties newProperties = new Properties();
                 stream = new FileInputStream(f);
                 newProperties.load(stream);
                 synchronized(this) {
                     lastReloadTime = System.getCurrentMillis();
                     currentProperties = newProperties;
                 }
             } 
          } 
    }
    catch(IOException exp) {
        //do something intelligent on the error
    }
    finally {
        if (stream != null)
            stream.close();
    }
}

 

All of the business logic code that needs properties to process a request will use the request scoped PropertyBean instance bean. This ensures that the entire request uses the same set of properties even if the underlying property file changes.

class SomeBusinessService {
    @Autowired
    private PropertyBean propertyBean;

   public void someOperation() {
      String v = propertyBean.getProperty("some.property");
       .
       .
    }

}

When a new request is started a new instance of the PropertyBean is created. The doInit() method invokes the PropertyCache getProperties() method. The Property Cache checks the timestamp of the file and looks for modifications, if it detects one it reloads the property file. Any PropertyBean instances that have already been initialized will continue to use the old properties instance.

clustertest is the distributed testing framework that we built for testing Slony. While in Ottawa for PGCon, I modified it such that clustertest can be used to test the streaming replication features built into PostgreSQL 9.1.

(more…)

Embedded Javascript

Posted: April 22, 2010 in Uncategorized
Tags:

A recent project I’ve been working on has me looking at embedding a scripting language inside of the JVM. We have the need for a large number of scripts that will control the overall flow of an application written in Java. A number of popular scripting languages can now be embedded in the JVM. We choose Javascript with the Rhino engine but we could have also used Python with Jython.

Rhino

Rhino is a Mozilla foundation project that provides a Javascript interpreter that runs inside of the JVM. Your Java programs can easily pass a string of Javascript code to the interpreter and tell it to run. Your Javascript programs can also instantiate classes written in Java or make calls to Java objects created by the rest of your program.

Invoking Javascript
The Java code snippet

Context context = ContextFactory.enter();
Scriptable scope = context.initStandardObjects();
scope.evaluateString('for(var i=0;i<10;i++) { ' +
                             'java.lang.System.out.println(i);' +
                          '}');

Will execute the Javascript code passed to evaluateString (a for loop in this case). Notice how easy it is to call Java objects from your embedded Javascript code. You aren’t restricted to the standard Java classes you can also call into (or instantiate) any Java classes you write.

Type Safety

Java is a fairly strongly typed language, Javascript is not. What does embedding Javascript in your Java code mean for type safety? Your Java code will continue to check the types of objects at compile time but any Javascript code continues to be un-typed. Let’s say you have a method that returns a map to objects (say Map<String,Object> ). Maybe you know that the object pointed to by the key “name” always is a String; with Javascript you can just treat the object as a String. For example you could write a line of Javascript like myMap.get("name").substr(2);. With Java you would have to use casting or come up with a better data-structure than a map of objects. If you like type-safety you probably think it is good that Java forces you to fix your data-structure design but if your not a fan of all the work, code, and extra classes that is often entailed in doing so then you might appreciate how ignoring types lets you get by with far fewer lines of Javascript than the equivalent Java.