Obtaining Spring beans elegantly without polluting classes with spring dependencies

[Sebastian Janisch]

Hey,

I am changing the mechanism for handling services to spring beans. now I was wondering how to obtain spring beans in an elegant way. What I do not want is to call

beanFactory.getBean("beanId");

in all of my service consuming classes, as this would pollute these classes with spring dependencies.

I figured the following approach to be more elegant. I was wondering though, if there are any arguments against it.

So here goes:

bean definition

<bean id="IFancyService" class="net.service.FancyServiceImpl">
   ... some dependencies ...
</bean>

ServiceLocator class

public class ServiceLocator{
    private static final ClassPathXmlApplicationContext _context;

    static
    {
        _context = new ClassPathXmlApplicationContext("context.xml");
    }

    public static <E> E getService(Class<E> clazz)
    {
        return (E) _context.getBean(clazz.getSimpleName());
    }
}

This way I have the dependency to the bean factory centralized in one class and also a central service accessor class.

Looking forward to hear your opinions

[Mark Spritzler]

In all my Spring applications, I never need to call getBean. I just use Spring to do dependency injections to inject beans into other beans. At the client level, it depends on the technology that I am using, but even with that all the technologies have some Spring integration to have beans injected into them without you ever calling getBean.

Where were you calling getBean? Can you give us an example>

Thanks

Mark

[Sebastian Janisch]

hey mark,

thanks for your reply.

yah, this is the general approach. usually there is some other spring consuming framework that takes care of all the beans.

in this context though, there is no other framework involved in the application. it is a server application based on jboss netty. the architecture is set up to have a service layer. as of now, they are all wired together in a ServiceLocator class, as all of these services are singletons and are instantiated once in a static initializer and that's it.

now though, a service cannot run as a singleton. and that's where i find it's easier to hand this task over to spring.

as for the service consuming classes, these can be message handlers that are triggered by the netty framework that need some services to perform their task.

[Saifuddin Merchant]

Your approach sounds pretty reasonable!! (In the absence of spring framework consuming class!)

[Kevin Cho]

I'm a bit confused...

I assume you created that class to centralize Spring dependency. If so... I guess that's fine but why not utilize Sun's standar JSR250 and 330.

I forget the details but you can use JEE5 annotations instead of using Spring Annogations. Maybe I misunderstood your question.