Servlet DI

[uenluena]

So Spring "aware" just means that we have the freedom to use another IoC container. If thats the only reason why you dont want to use those classes, the reason is quiet cheap ;-) If im dependent on a IoC container, why not chosing dependento on the best one ;-)

We all know that Spring is the most advanced framework in this area and using such a strategic framework is not someting you can abandon just like that....so it's just a very theoretic approach to think that you can throw away Spring and everything just works like that

[Mr.A]

It's not only that reason. But in theory, yes, we don't need to use Spring at all, we can change IoC container if we want to.

But if we don't use DI, why we use Spring? We can just use Service Locator pattern.

I just want to know is there a way to inject bean to servlet.

You know benefit of DI over service locator, right?
Even using service locator, client code needs to have dependency to something such as JNDI name or service name.

But by using DI/IoC, the controll is inversed, client code just define interfaces in contructor arguments/setter methods/arguments to a factory method, that is all.

[uenluena]

sorry but why do you compare the Service Locator pattern with DI? It has no relation at all. Through dependency injection and the configuration files, you wire your beans together and retrieve your beans from a BeanFactory, which saves you from having your own Factory pattern implementation.
There are many patterns that are implemented in the Spring Framework but thats another story...

And yes i know the hollywood principle ;-)

[Mr.A]

I mean if we get beans from ApplicationContext, it's very similar to Service Locator pattern.

I don't want to do that, I want to use DI.

[dejanp]

There are many frameworks/specs that are not Spring friendly and do not have any backdoors that one can use to hook the Spring into.

EJB2 and servlet specs are good examples - the best you can do is use the ejb/servlet to wrap the actual implementation (which is also good - your implementation has nothing to do with ejb/servlet api).

Otoh, you can always use aspectj support to DI into classes not created by Spring and afaik it should work with servlets too.

[Mr.A]

Many thanks for advice, dejanp.
Can you give me resources about DI by Aspectj?

[dejanp]

AspectJ LTW

[TomDesmet]

Is this a reasonable alternative to the problem?

http://andykayley.blogspot.com/2008/...eans-into.html

[constv]

Is this a reasonable alternative to the problem?

http://andykayley.blogspot.com/2008/...eans-into.html

Perhaps I am missing something obvious, but why does everyone keep looking for a crafty solution (I have seen several smarty-pants revelation-type posts online like that one) instead of simply using what Spring already has: ServletContextAttributeExporter? Define the bean to be injected into the servlet in the exporter's definition in your Spring app context, and that's it! One line of configuration code. No need for special interfaces, or anything other than defining your POJO and exporting it into the servlet context.

It seems very convenient - and quite logical - to inject the bean instance into the servlet context, not into the instance of the servlet itself. The servlet class, instead of maintaining the local reference, just obtains the bean reference any time it needs it from its context. Yes, the servlet code depends the presence of a particular context attriubute, but that's probably better than hardwiring the bean into the servlet as a local member attribute and then going out of your way creating more elaborate solutions. My $.02.