Sunday, 19 April 2015

No message found under code '<<XXX>> for locale '<<YYY>>'.

Recently while I was working on some Spring based Web Application, I encountered an Error Message No message found under code '<<XXX>>' for locale '<<YYY>>'., when I was trying to fetch the message code Using MessageSource implementation which is autowired in a service class.

I first checked the MessageSource bean definition in the @Configuration annotated java class is good or not. The underlying implementation class as used in the bean definition ResourceBundleMessageSource. So I checked its parameters like baseName is having proper path to the resource or not,defaultEncoding is UTF-8 (As I have been using UTF-8 for encoding) or not etc and I found them perfectly good. Then I checked whether the resource (i.e. .properties file) the MessageSource is pointing to, is at per with the baseName and in classpath, and surprisingly I found it also perfectly good.
Next, I thought of using ReloadableResourceBundleMessageSource with appropiate parameter set and this effort of mine is also vain and this implementation too could not made the code error-free. Even for both the implementation classes I have appended classpath: with value in the parameter baseName but nothing is turning to be effective enough for me.

I was really scratching my head, as I could not figure out where I was going wrong. Since you all could understand that I have really tried out each and every possible course of action.

Next, I thought of looking at the debug log file, which logs the details of all Spring configured beans of the application context, there I found that my bean is getting overwritten by another bean of same name, as a result of which I was getting the above mentioned error. Actually my Web Application is has got its own MessageResource bean configured, and this application is dependent on another module (which is present as jar in the Web Application's classpath), which has got its MessageResource bean configured with the same name as that of Web Application's. Now when I am trying to fetch the messages for the dependent module I was getting the above error as the MessageResource bean confugured in the dependent module's configuration is being overwritten with that of Web Application's.

So, we should always configure our logging properly and always be very careful while configuring beans, so that they should not have same name.
View Subhankar Paul's profile on LinkedIn

Mocking with Annotation

Believe me, the following annotations are really helpful and they are part of Mockito framework.
1) @InjectMock
2) @Mock
Although there are various other usages of the Mockito Framework, I am going to share my experience with the above two annotations.

My Business Class has the following structure:
class Business
{
 @Autowired
    private BusinessPlanner businessPlanner;
 
 public String createBusinessPlan() {
  String plan = businessPlanner.planBusiness();
  return plan;
 }

}

& my Test Class has the following structure.

 @RunWith(PowerMockRunner.class)
 @PrepareForTest(Business.class)
 class BusinessTest
 {
 @InjectMock
 private Business business = new Business();
 
 @Mock
 private BusinessPlanner businessPlanner;
 
 public void testBusinessFunctionality()
 {
  <<Define the Behaviour of the Mocked Object i.e. businessPlanner here >>
  <<Invoke the Business Method here i.e. business.createBusinessPlan()>>
  <<Assert ActualResult with the ExpectedResult>>
  
 }
 }

Here in the above Test Class, @Mock annotation injects a mocked instance of BusinessPlanner into the class Business annotated with @InjectMock
Then we can define the behaviour in these test methods and carry out the testing.
Really, these annotations has made life much easier.
For Mocking or Spying with Spock (for Groovy classes), the Mock() and Spy() methods are really awesome.
Spy() is basically used for Partial Mocking.

They come with other features such as wildcard matching (any) of method parameters with _, setting the members of the mocked instance using closures, Verification of method invocation with Groovy Ranges etc.
For groovy classes annotated with @Immutable we could use MockFor class, which is really helpful. I think it is the Groovy Closures which has made these options more powerful. Check out these features!!!!!.

So Till Next Time Keep Code and Keep sharing your Views
View Subhankar Paul's profile on LinkedIn