Page Comparison

...

1. byName - candidate based on bean name vis-a-via properties on the target.  E.g. if the target bean has a setFoo(...) method, then another bean with id/name of "foo" would be a candiate

2. byType - candidate based on type.  E.g. if target bean has a setFoo(Bar bar) method, then another bean with a type of Bar is a candidate

3. constructor - like byType, except for constructor

4. no - turns off autowiring explicitly

Except for some special collection support, there generally must be at most one autowiring candiate, otherwise it's an error.  However, autowiring candidacy for a bean may be influenced by <bean autowire-candidate="true/false" /> and <bean primary="true/false" />

...

Regarding what gets inherited, quoting verbatim:

• A child bean definition inherits constructor argument values, property values, and method overrides from the parent, with the option to add new values. Any initialization method, destroy method, and/or static factory method settings that you specify will override the corresponding parent settings.

• The remaining settings are always taken from the child definition: depends on, autowire mode, dependency check, singleton, scope, lazy init.

This would seem incredibly useful for eliminating a lot of boilerplate stuff on the bean definitions, albeit at the minor invasive effect of having to declare the parent on each. (The BeanPostProcessor and/or BeanFactoryPostProcessor techniques would avoid that invasiveness, but at the cost of being more auto-magical and making the effective dependency config less obvious to someone looking at it).

...

In a web context, in addition to the standard singleton and prototype beans, request and session-scoped beans may by used.  Spring implements this by attaching associating such beans to the HttpServletRequest and HttpSession via the use of a ThreadLocal variable to which is bound the current servlet request instance, managed in their holder context class org.springframework.web.context.request.RequestContextHolder.  The data stored in the ThreadLocal is managed (populated and later cleaned up) by one of three techniques:

1. (Spring MVC Only) - Their  DispatcherServlet does this internally, when you use Spring MVC.  Declared as as servlet in web.xml

2. (Servlet 2.4+ web container) - Via a javax javax.servlet.ServletRequestListener implementation declared in web.xml

   Code Block
   language html/xml
   <listener> <listener-class> org.springframework.web.context.request.RequestContextListener </listener-class> </listener>

3. (Servlet 2.3 web container) - Via a javax.servlet.Filter implementation

   Code Block
   language html/xml
   <filter> <filter-name>requestContextFilter</filter-name> <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class> </filter> <filter-mapping> <filter-name>requestContextFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

...

This  can replace an entire method implementation at runtime with generated bytecode.  The method used as the replacement is defined by implementing their interface org.springframework.beans.factory.support.MethodReplacer.

This doesn't seem terribly useful to me at the moment.

...

A JDK interface-based proxy may instead by used via <aop:scoped-proxy proxy-target-class="false"/>. The proxied bean must implement at least one interface, and the collaborator must call the bean through one of these interfaces.

...

We could "autowire" the profile request context (or whatever it winds up being called) into a whole slew of actions, but reduce the clutter/noise of this common dependency, by any of a number of techniques.

• Actual Spring autowiring on the whole container could be used, but at the cost of either marking every action with autowire or pretty global container config with default-autowire.  The effect of the latter can be mitigated somewhat with the autowire-default-candidates attribute.

• Bean definition inheritance is the least auto-magical and makes the dependencies more obvious.  But does require marking all beans with parent.

• BeanPostProcessor could be used to wire based on either an interface (e.g. action instance of ProfileRequestContextAware) or using Java reflection.  Is auto-magical and makes the dependencies less clear, but also results in a very clean config, with no possibilities for errors due to accidental omissions.

• BeanFactoryPostProcessor could be used to actually alter the BeanDefinitions.  Need to prove out that this would actually work.  If does, would have mostly the same advantages and disadvantages as BeanPostProcessor.

• Instead of actually declaring all the action beans in XML, we could possibly consider declaring some or all of them in Java code using the Java-based config technique.  This needs more research.

Injection of HttpServletRequest/Response

HttpSevletRequest/Response are not collaborators in the traditional sense, but are also not our own application domain-specific runtime state that we will manage in our context objects.  Instead, they could be categorized as more of "environmental" runtime state.  Although not a lot of classes (of the classes message handlers and actions) will need access to them, it would clean up some code if we could just get Spring to inject these where appropriate.  This would involve the use of ThreadLocal, similar to how Spring implements support for request and session-scoped beans.  The approach would basically be:

1. Create a ThreadLocal-based request and/or response holder class, similar to my old example.

2. Declare either a ServletRequestListener or Filter in web.xml to populate and clean up the ThreadLocal appropriately. A filter-based example is in my old project.

3. Implement proxy classes for HttpServletRequest and HttpServletResponse that just delegate all methods through to the request or response as obtained from the holder class.

4. Wire this proxy class to the beans that need it, using any of the above techniques:
   

   1. explicit dependency injection

   2. bean or bean factory post processors

   3. bean definition inheritance

   4. Java-based config

   5. etc

Auto-Adapting of non-Spring WebFlow Actions

...