Nov 27th, 2008, 02:08 AM
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
Nov 27th, 2008, 02:23 AM
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.
Nov 27th, 2008, 02:56 AM
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 ;-)
Nov 27th, 2008, 03:11 AM
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.
Nov 27th, 2008, 08:58 AM
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.
Nov 27th, 2008, 09:57 PM
Many thanks for advice, dejanp.
Can you give me resources about DI by Aspectj?
Nov 28th, 2008, 03:54 AM
Aug 3rd, 2009, 02:29 PM
blog providing alternative
Aug 3rd, 2009, 02:49 PM
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.
Originally Posted by TomDesmet
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.