Category: Uncategorized

Property file reader

In my current project we have some property files and we need to read properties from those property files, so we come up with an approach to read property files. The main points that we need to focus was
1.) The properties should be loaded only once, In a way we need singleton behavior
2.) We can have multiple property files
One assumption that we have is property files will always be located in root class path

Now for the solution of this problem we thought of using Enum (effective java ;)) as they internally provide the feature of singleton behavior, also for multiple property file situation we created multiple instances corresponding property file.

So the code that we have written is like this


public enum PropertiesReader {
     SEARCH("search.properties"),APP("app.properties");

     Properties properties;
     private Logger log = LoggerFactory.getLogger(PropertiesReader.class);

     private PropertiesReader(String propertyFile) {
   properties = new Properties();
          try {
               InputStream inputStream =    this.getClass().getClassLoader().getResourceAsStream(propertyFile);
               properties.load(inputStream);
          }
          catch (IOException e) {
               log.error(propertyFile + " was not found in classpath");
          }
   }

     public String getValue(String key) {
          return (String) properties.get(key);
     }
}

So now
if we want to read a property from search.properties file
assertThat(PropertiesReader.SEARCH.getValue(“max.pages.to.display”)

if we want to read a property from app.properties file
assertThat(PropertiesReader.APP.getValue(“debug_mode”)

JSR-303

JSR-303
The main idea behind JSR-303 is to have a common approach for validation at all places of the application in a simplistic way. The bean validation is built keeping in mind the validation process as a kind of meta information for a bean, so if you say that a property of bean should be not null or the content of a bean property should match to the format of e-mail or telephone. Such kind of information can be treated as meta-information of bean properties. One of the other motive for having JSR-303 into picture is to remove the boilerplate code introduced due to the need of bean validation at multiple places in the application, such as at UI level, while persisting a bean or performing some business operation.

JSR-303 provides bean validation using two ways, either you can configure validations using annotations on properties or using a XML validation descriptor. Annotations can be used as Meta-data for bean validation in case of some simple validations such as not null, e-mail, telephone number check. XML validation descriptor is used for some complex validations or context aware validation.

JSR-303 also defines API for Java Bean validation, so this API can be used to programmatically validate the bean .

Bean validation JSR-303

In my current project we are working on a web-application using JBoss Seam. One of the very common requirements while working on a web application is validating the data contained in a bean. Seam is powered with annotation based validation, seam uses Hibernate Validator for this feature. Hibernate validator is a reference implementation of Bean Validation (JSR-303).JSR-303 defines a meta-data model and API for JavaBean validation based on annotations.
In my coming posts I’ll be focussing on JSR-303 and it’s reference implementations. Some of the posts I’m thinking of right now
– Bean Validation JSR-303
– Hibernate Reference implementation
– Using Hibernate Validation, accessing it programmatically
– Creating custom annotation validator

2010 Focus

So a new year has begun it’s the time to plan things for this year. It’s good to plan things in advance 🙂 atleast you dont need to plan every time, you already have things that you need to focus right :).
Initially I’ll be focussing on Seam, as in my current project I’m working on seam, since it’s a new technology for me so a lot needs to be learnt in it.
Other things on which I’ll be wroking will be Java EE6, Spring, JPA . Other then this I’ll be picking something as of interest so right now I’m thinking of mobile applications.
Let’s see how things go this year. Happy blogging 🙂

Introducing EasyMock

This blog will share my understanding about EasyMock, before moving forward to EasyMock first want to tell you about what is Mock and what is Mock Object and there purpose.

One of the web definition of Mock is “An intimation of counterfeit”. If we apply definition of mock to mock objects, mock objects are just an intimation or counterfeit of objects. Now we have to look where these mock objects are applied in real world.

Consider a use case where we have a UserService that performs some business operation on a User entity and then persists user entity using UserDao(Persistence Service). When we write test case for UserService, unintentionally we will be testing UserDao also and we have to take care of successful execution of UserDao also. In such cases Mock Objects comes into picture, we create a mock object of UserDao and provide this mock object to UserService. UserDao mock object will intimate as UserDao and will behave as required.

In coming sections I’ll be taking this use case as an example

EasyMock is about creating mock objects for interfaces. The mock objects are created using java proxy mechanism. Once mock objects are created you have to record the behavior of mock objects before using mock objects. Recording behavior of mock objects signifies registering method calls to mock object which can be invoked while testing.

Before using a mock object it needs to be instantiated. To instantiate a mock object first it needs to created using createMock(EasyMock.createMock()) . Once a mock object is created it comes into record state, in record state the expected behavior of mock object is recorded which includes specifying methods which can be invoked on mock objects. After recording behaviors to a mock object the state of mock object is changed to replay state by calling replay(EasyMock.replay()) api.

So if we have to create a mock object for UserDao using EasyMock, the API call will be like this
userDao = EasyMock.createMock(UserDao.class);

This section tells you about adding behavior for method call to mock objects. As told in previous section behaviors to a mock object are added in record sate. Adding behavior for method call is similar to actually calling the method, the only difference is that at the time of recording behavior gets registered to mock object. If we have to record the delete operation of user entity we have to write userDao.delete(user) in the record phase of userDao.

So if we have to record the persistence behaviour to mock “userDao” object the code code will be like this
// Setting up the expected value of the method call delete
userDao.delete(dummyUser);
// Setup is finished need to activate the mock userDao object
EasyMock.replay(userDao);

In next blog I’ll discuss behavior of mock objects in replay phase and the advanced features of easy mock such as restricting no of times a method can be called, ensuring the sequence of method calls, verifying the return values etc.
So keep waiting 🙂