
|
If you were logged in you would be able to see more operations.
|
|
|
|
I'd like a way to extend the capabilities of the module contexts created by the extender. My particular use case is to register a set of bean post processors that will then be invoked during context creation for all contexts created by the extender bundle, but I can imagine in general a desire to share common configuration (e.g. turning on annotation processing) across all bundles.
A suggestion is to allow users to attach fragments to the extender bundle, which contain configuration file(s) in META-INF/spring. Then when the extender bundle is creating contexts, add all of the META-INF/spring/*.xml files attached to the extender bundle to the configuration set used to create the contexts for spring-powered bundles.
If fragments are attached and unattached at runtime, semantics would be that a bundle gets the blueprint files that were available at the time it was started.
There may be other designs - this is just a suggestion.
|
|
Description
|
I'd like a way to extend the capabilities of the module contexts created by the extender. My particular use case is to register a set of bean post processors that will then be invoked during context creation for all contexts created by the extender bundle, but I can imagine in general a desire to share common configuration (e.g. turning on annotation processing) across all bundles.
A suggestion is to allow users to attach fragments to the extender bundle, which contain configuration file(s) in META-INF/spring. Then when the extender bundle is creating contexts, add all of the META-INF/spring/*.xml files attached to the extender bundle to the configuration set used to create the contexts for spring-powered bundles.
If fragments are attached and unattached at runtime, semantics would be that a bundle gets the blueprint files that were available at the time it was started.
There may be other designs - this is just a suggestion. |
Show » |
|