Shantibhushan Naik

Tag: setter

  • Spring and Logback

    IoC, or DI definitely takes a perspective turnaround inside your head, but you get around it slowly.  I was playing around ways to integrate LogBack, and Spring – essentially around having Spring give me a pre-created instance of LogBack logger.

    I searched around posts, but most people seem to be against using Spring just for substituting one-line of Logback (Logger log = LoggerFactory.getLogger("LogbackTest");) to get your logger.

    I, on the other hand, was more interested in how to get Spring give me a LogBack logger instance without too much contrived hand-written code to achieve so. And with a bit of reading through Spring principles, documentation I found the way.

    Essentially, when using Logback’s LoggerFactory you have access to only a single getLogger() factory method. This is static which makes things a bit different for what Spring would call a bean – a class providing constructor, getter, setter methods. To circumvent this non-bean style, Spring provides what you call as static initializers a.k.a substitutes for constructors, which allow you to call a static method in lieu of calling a constructor on an object.

    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
 "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
 <bean id="bean1" class="org.slf4j.LoggerFactory" factory-method="getLogger">
 <constructor-arg value="LogbackTest" />
 </bean>
</beans>

    Now, this bean1 can be used as a regular bean inside your class

    ApplicationContext ctx = new FileSystemXmlApplicationContext("logbacktest.xml");
 Logger log = (Logger) ctx.getBean("bean1");

 log.debug("This is my first message");
 log.info("How about this information message");

    Throw in a logback.xml in your classpath, and viola you have a nice Spring injected dependency – log in your code, while still using Logback!

  • Spring IoC, DI quick tutorial

    There has been an (evident) craze amongst Java community with contrived terms such as IoC (Inversion of Control), DI (Dependency Injection) mainly through Spring. I initially found the connotation “Don’t call me, I’ll call you” a bit difficult (yeah, it’s bending your head upside down) to understand, but after spending few hours around Spring documentation, I get the gist.

    To a layman (Java layman, of course) it is helpful to picture that each Java program is a set of one or more classes, which act together. Essentially, this means classes are “dependent” on some classes in order to be fully functional. Usually, the class requiring functionality of another class instantiates the class, and uses it. This is called coupling because class instantiates the object of required class. What if we always got an “instantiated” instance of required class, and our class did not have to worry of instantiation? – This is called IoC (Inversion of Control) principle in Spring, and it achieves this by providing ready-to-use instance (injecting dependency) to your class. This has some important uses, since now you don’t worry of creating connections to databases, loggers to log4j, or sessions for JMS queues. Spring will create these for you, and your class can focus on the actual purpose – using the pre-instantiated ready-to-use object.

    Get it? OK, to simplify it further, let us assume you have a class A having one field – log. You want to use log to log information, but your class nowhere has the logic to instantiate or initialize log. You accept a pre-instantiated log through constructor, or getter/setter methods, and you will have a ready-to-use log instance passed to your class via Spring!

    I won’t go into details of Spring further, since Spring’s own documentation on http://static.springsource.org/spring/docs/2.5.x/reference/index.html is the definitive source to look into.