{"type":"doc","content":[{"type":"paragraph","content":[{"text":"This page is mostly a braindump of various \"advanced\" Spring capabilities and related techniques that might be useful for various things. Some of it is stuff that is was new to me (since the last time I read the Spring docs) and some other is basically just capabilities that we've never used, but which might be useful.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Autowiring","type":"text"}]},{"type":"paragraph","content":[{"text":"The container can autowire dependencies into other beans, avoiding the need to explicitly declare those dependencies. ","type":"text"}]},{"type":"paragraph","content":[{"text":"Auto-wiring is often set directly on the bean to be autowired, e.g. ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":". Several strategies are available for resolving the candiate bean(s) to wire in:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"byName","type":"text","marks":[{"type":"strong"}]},{"text":" - 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","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"byType","type":"text","marks":[{"type":"strong"}]},{"text":" - 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","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"constructor","type":"text","marks":[{"type":"strong"}]},{"text":" - like byType, except for constructor","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"no","type":"text","marks":[{"type":"strong"}]},{"text":" - turns off autowiring explicitly","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"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 ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" and ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]}]},{"type":"paragraph","content":[{"text":"A default autowiring strategy can also be set on the entire context via ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":", taking the same strategy values as ","type":"text"},{"text":"autowire","type":"text","marks":[{"type":"code"}]},{"text":".","type":"text"}]},{"type":"panel","attrs":{"panelType":"warning"},"content":[{"type":"paragraph","content":[{"text":"Ian: I think this may actually be per-configuration-file and not per-context, see for example para 5.","type":"text"}]}]},{"type":"paragraph","content":[{"text":"When using default strategy, the selection of candidates for auto-wiring as dependencies into other beans can be influenced by ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":". The candidateList is a comma-separated list of regexes which is matched on bean id/name.","type":"text"}]},{"type":"paragraph","content":[{"text":"TODO: how do defaults behave when you create a context based on multiple files?","type":"text","marks":[{"type":"em"}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"BeanPostProcessor","type":"text"}]},{"type":"paragraph","content":[{"text":"This is an interface for a component which post-processes bean instances. It can be defined in the context as just another bean, and the context auto-registers it based on its type. It can have dependencies/collaborators injected into it just like any other bean, which in this case can be used to configure how it works. It has 2 callback methods: 1) called before any init lifecycle methods are invoked 2) called after all init lifecycle methods are invoked.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"java"},"content":[{"text":"Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;\n\nObject postProcessAfterInitialization(Object bean, String beanName) throws BeansException;","type":"text"}]},{"type":"paragraph","content":[{"text":"The order of execution can be deterministic by having the processor(s) implement the ","type":"text"},{"text":"Ordered","type":"text","marks":[{"type":"code"}]},{"text":" interface.","type":"text"}]},{"type":"paragraph","content":[{"text":"A post processor can wrap the returned bean in a proxy.","type":"text"}]},{"type":"paragraph","content":[{"text":"This would seem to be a good candidate for effectively auto-wiring things like ProfileRequestContexts or HttpServletRequest/Responses. The processor could either look for an -Aware interface that we define, or could use full reflection to figure out where/when to wire.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"BeanFactoryPostProcessor","type":"text"}]},{"type":"paragraph","content":[{"text":"This is an interface for a component which post-processes (primarily) BeanDefinitions. It can be defined in the context as just another bean, and the context auto-registers it based on its type. It can have dependencies/collaborators injected into it just like any other bean, which in this case can be used to configure how it works. It has 1 callback method:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"java"},"content":[{"text":"void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;","type":"text"}]},{"type":"paragraph","content":[{"text":"Other than the ","type":"text"},{"text":"BeanDefinitions","type":"text","marks":[{"type":"code"}]},{"text":", It could theoretically modify other aspects of the bean factory handed to it.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Bean Definition Inheritance","type":"text"}]},{"type":"paragraph","content":[{"text":"This technique essentially allows a ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" definition to inherit various properties of a parent bean. Basically it's a way to do templating. It is implemented by simply declaring a parent bean reference on the bean:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n\n","type":"text"}]},{"type":"paragraph","content":[{"text":"Parent may also be declared abstract, in which case the container does not instantiate it. Then it really does just become a \"template\" for other beans.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n \n \n\n\n \n \n","type":"text"}]},{"type":"paragraph","content":[{"text":"As can be seen above, the class relationships between the beans themselves really don't matter. This is not Java inheritance, it's BeanDefinition inheritance. So the parent can completely omit the class attribute and just be a template of properties.","type":"text"}]},{"type":"paragraph","content":[{"text":"Regarding what gets inherited, quoting verbatim:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"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 ","type":"text"},{"text":"static","type":"text","marks":[{"type":"code"}]},{"text":" factory method settings that you specify will override the corresponding parent settings.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The remaining settings are ","type":"text"},{"text":"always","type":"text","marks":[{"type":"em"}]},{"text":" taken from the child definition: ","type":"text"},{"text":"depends on","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"autowire mode","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"dependency check","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"singleton","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"scope","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"lazy init","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"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 ","type":"text"},{"text":"parent","type":"text","marks":[{"type":"code"}]},{"text":" 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).","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Request and Session Scoped Beans","type":"text"}]},{"type":"paragraph","content":[{"text":"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 ","type":"text"},{"text":"HttpServletRequest","type":"text","marks":[{"type":"code"}]},{"text":" and ","type":"text"},{"text":"HttpSession","type":"text","marks":[{"type":"code"}]},{"text":" via the use of a ","type":"text"},{"text":"ThreadLocal","type":"text","marks":[{"type":"code"}]},{"text":" variable to which is bound the current servlet request instance, managed in their holder context class ","type":"text"},{"text":"org.springframework.web.context.request.RequestContextHolder","type":"text","marks":[{"type":"code"}]},{"text":". The data stored in the ","type":"text"},{"text":"ThreadLocal","type":"text","marks":[{"type":"code"}]},{"text":" is managed (populated and later cleaned up) by one of three techniques:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"(Spring MVC Only) - Their ","type":"text"},{"text":"DispatcherServlet","type":"text","marks":[{"type":"code"}]},{"text":" does this internally, when you use Spring MVC. Declared as as servlet in web.xml","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"(Servlet 2.4+ web container) - Via a ","type":"text"},{"text":"javax.servlet.ServletRequestListener","type":"text","marks":[{"type":"code"}]},{"text":" implementation declared in web.xml","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n \n org.springframework.web.context.request.RequestContextListener\n \n","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"(Servlet 2.3 web container) - Via a ","type":"text"},{"text":"javax.servlet.Filter","type":"text","marks":[{"type":"code"}]},{"text":" implementation","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n requestContextFilter\n org.springframework.web.filter.RequestContextFilter\n\n\n requestContextFilter\n /*\n","type":"text"}]}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Java-based Config","type":"text"}]},{"type":"paragraph","content":[{"text":"This used to be in a separate project, but is now since relatively recently in Spring core. It occupies the middle ground between completely externalized XML-based container config, and completely internalized annotation-based config (where the annotations are invasively placed on the bean classes themselves). Essentially separate Java classes are used to define the container, the beans within it and so on. These classes are annotated appropriately.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"java"},"content":[{"text":"@Configuration\npublic class AppConfig {\n\n @Bean\n public Foo foo() {\n return new Foo(bar());\n }\n\n @Bean\n public Bar bar() {\n return new Bar();\n }\n\n} ","type":"text"}]},{"type":"paragraph","content":[{"text":"Dependencies are specified by just having the Java code inject the appropriate instances, although the behavior is more advanced than it appears. The default is still for singleton beans, so unlike what the above implies, each instance of Foo gets the same instance of Bar. ","type":"text"},{"text":"@Scope ","type":"text","marks":[{"type":"code"}]},{"text":"annotation can be used to influence this. ","type":"text"}]},{"type":"paragraph","content":[{"text":"Seems this can also be combined with XML-based config and component scanning, which might be pretty powerful.","type":"text"}]},{"type":"paragraph","content":[{"text":"This is pretty complex, I won't attempt to document it all here.","type":"text"}]},{"type":"paragraph","content":[{"text":"At first I thought this would be of little use to us. But on more thought, I suppose it might be. It might be attractive to wire up our dozens or hundreds of action/handler type beans this way, rather than with reams of XML config.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Lookup Method Injection","type":"text"}]},{"type":"paragraph","content":[{"text":"Used primarily to effectively inject a bean with a shorter lifecycle (e.g. prototype) into a bean with a longer lifecycle (e.g. singleton). This is accomplished with runtime bytecode generation.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n\n \n\n\n\n\n \n","type":"text"}]},{"type":"paragraph","content":[{"text":"This would be useful if we actually have any cases like this, but I don't personally know of any at the moment.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Arbitrary Method Replacement/Injection","type":"text"}]},{"type":"paragraph","content":[{"text":"This can replace an entire method implementation at runtime with generated bytecode. The method used as the replacement is defined by implementing their interface ","type":"text"},{"text":"org.springframework.beans.factory.support.MethodReplacer","type":"text","marks":[{"type":"code"}]},{"text":".","type":"text"}]},{"type":"paragraph","content":[{"text":"This doesn't seem terribly useful to me at the moment.","type":"text"}]},{"type":"paragraph","content":[{"text":" ","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"AOP Scoped Proxies","type":"text"}]},{"type":"paragraph","content":[{"text":"This technique allows the injection of an automatically bytecode-generated proxy, rather than the actual bean instance itself. The use case is similar to the lookup method injection use case re: mismatches in bean lifecycles, but the docs discuss it more in the context of scoped beans as dependencies, specifically injecting request and session scope objects into singletons. It's implemented by just declaring an additional element on the bean which is to be injected:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n \n \n\n\n\n\n \n \n","type":"text"}]},{"type":"paragraph","content":[{"text":"The type of proxy injected may be either a class-level or interface level proxy. The former is the default and uses the CGLIB library. This type of proxy only intercepts public method calls.","type":"text"}]},{"type":"paragraph","content":[{"text":"A JDK interface-based proxy may instead by used via ","type":"text"},{"text":". ","type":"text","marks":[{"type":"code"}]},{"text":"The proxied bean must implement at least one interface, and the collaborator must call the bean through one of these interfaces.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Static and Instance Factory Methods","type":"text"}]},{"type":"paragraph","content":[{"text":"These features aren't terribly new or advanced, just noting them for completeness as they may be useful.","type":"text"}]},{"type":"paragraph","content":[{"text":"A bean may be produced by Spring invoking a static factory method on a class:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"","type":"text"}]},{"type":"paragraph","content":[{"text":" ","type":"text"}]},{"type":"paragraph","content":[{"text":"A bean may also be produced by Spring invoking a factory method on a non-static bean:","type":"text"}]},{"type":"codeBlock","attrs":{"language":"html/xml"},"content":[{"text":"\n \n\n\n\n\n\n","type":"text"}]},{"type":"heading","attrs":{"level":1},"content":[{"text":"Use Cases","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Reducing Noise of Injection of ProfileRequestContext","type":"text"}]},{"type":"paragraph","content":[{"text":"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.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Actual Spring autowiring on the whole container could be used, but at the cost of either marking every action with ","type":"text"},{"text":"autowire","type":"text","marks":[{"type":"code"}]},{"text":" or pretty global container config with ","type":"text"},{"text":"default-autowire","type":"text","marks":[{"type":"code"}]},{"text":". The effect of the latter can be mitigated somewhat with the ","type":"text"},{"text":"autowire-default-candidates","type":"text","marks":[{"type":"code"}]},{"text":" attribute.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Bean definition inheritance is the least auto-magical and makes the dependencies more obvious. But does require marking all beans with ","type":"text"},{"text":"parent","type":"text","marks":[{"type":"code"}]},{"text":".","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"BeanPostProcessor","type":"text","marks":[{"type":"code"}]},{"text":" could be used to wire based on either an interface (e.g. action instance of ","type":"text"},{"text":"ProfileRequestContextAware","type":"text","marks":[{"type":"code"}]},{"text":") 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.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"BeanFactoryPostProcessor","type":"text","marks":[{"type":"code"}]},{"text":" could be used to actually alter the ","type":"text"},{"text":"BeanDefinitions","type":"text","marks":[{"type":"code"}]},{"text":". Need to prove out that this would actually work. If does, would have mostly the same advantages and disadvantages as ","type":"text"},{"text":"BeanPostProcessor","type":"text","marks":[{"type":"code"}]},{"text":".","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"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.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Injection of HttpServletRequest/Response","type":"text"}]},{"type":"paragraph","content":[{"text":"HttpSevletRequest/Response","type":"text","marks":[{"type":"code"}]},{"text":" 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 ","type":"text"},{"text":"ThreadLocal","type":"text","marks":[{"type":"code"}]},{"text":", similar to how Spring implements support for request and session-scoped beans. The approach would basically be:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Create a ","type":"text"},{"text":"ThreadLocal","type":"text","marks":[{"type":"code"}]},{"text":"-based request and/or response holder class, similar to my old ","type":"text"},{"text":"example","type":"text","marks":[{"type":"link","attrs":{"href":"http://svn.middleware.georgetown.edu/view/java-shib-msgapi-temp/trunk/src/main/java/apitest/examples/spring/HttpServletRequestResponseContext.java?view=markup"}}]},{"text":".","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Declare either a ServletRequestListener or Filter in web.xml to populate and clean up the ThreadLocal appropriately. A filter-based ","type":"text"},{"text":"example","type":"text","marks":[{"type":"link","attrs":{"href":"http://svn.middleware.georgetown.edu/view/java-shib-msgapi-temp/trunk/src/main/java/apitest/examples/spring/RequestResponseContextFilter.java?view=markup"}}]},{"text":" is in my old project.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Implement proxy classes for ","type":"text"},{"text":"HttpServletRequest","type":"text","marks":[{"type":"code"}]},{"text":" and ","type":"text"},{"text":"HttpServletResponse","type":"text","marks":[{"type":"code"}]},{"text":" that just delegate all methods through to the request or response as obtained from the holder class.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Wire this proxy class to the beans that need it, using any of the above techniques:","type":"text"},{"type":"hardBreak"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"explicit dependency injection","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"bean or bean factory post processors","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"bean definition inheritance","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Java-based config","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"etc","type":"text"}]}]}]}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Auto-Adapting of non-Spring WebFlow Actions","type":"text"}]},{"type":"paragraph","content":[{"text":"The current notion of using OpenSAML profile actions which are Spring-independent is to wrap them in an Spring-dependent adaptor class. Instead of doing this declaratively in the beans configuration XML, this could be done auto-magically in a ","type":"text"},{"text":"BeanPostProcessor","type":"text","marks":[{"type":"code"}]},{"text":", allowing the beans XML to be simplified and contain only the declaration of the Spring-independent action bean.","type":"text"}]},{"type":"paragraph","content":[{"text":" ","type":"text"}]},{"type":"paragraph","content":[{"text":" ","type":"text"}]},{"type":"paragraph","content":[{"text":" ","type":"text"}]}],"version":1}