Grzegorz Kossakowski skrev:
[Snipping lots of technical details]
I want to create dynamic proxies around pipeline components. Actual
wrapping would be performed by class implementing BeanPostProcessor
interface. Taking one perspective one could say that this it's almost
the way as discussed one paragraph above. However, going with this path
makes whole pipeline scope completely *orthogonal* to the pipeline and
its components' code. No existing class will be touched and there is no
requirement on pipeline components' configuration files. No need for
custom namespace in XML config, etc.
I feel proud of this solution as it solves non-trivial problem just in
few lines of code and few config files in transparent way. 8-)
Seem like a neat solution.
Actually there are more that could be done with BeanPostProcessors.
As you know sitemap components has a rather involved life cycle, where
they first are created by the container and then the setup method is
called in the pipeline to insert the object model, the parameters and
some other stuff. Now if these objects already are part of the sitemap
scope, we could have a special SitemapModelComponent aware
BeanPostProcessor that just takes the needed objects from the current
scope and use the for setting up the sitemap component.
What is needed is that the right scope is set before looking up the
sitemap component from the container. This will only work for prototype
scoped beans as we must be sure that they actually are created in the
scope where they are looked up. All Springified sitemap components are
prototypes, (I don't know how it would work for the Avalon bridge
handled components).
This far we only have a possible simplification of the setup mechanism.
But with other BeanPostProcessors we could get the same style of
interceptor based dependecy injection as in Struts2, where various
request objects are injected in the action bean based on marker
interfaces. We could do something similar for sitemap components and
maybe go further and have convention based autoviring so e.g. a set
method that takes a ServletRequest automatically get the one from the
call injetcted.
We could use the same mechanism for a new type of actions that are
created in prototype scope and get all dependencies injected by Spring
in the sitemap scope.
/Daniel
