[
https://issues.apache.org/jira/browse/CXF-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Smyth resolved CXF-153.
------------------------------
Resolution: Fixed
The BusExtension interface and a BusExtensionPostProcessor were added a good
while ago.
> Simplify Registration of Extensions
> -----------------------------------
>
> Key: CXF-153
> URL: https://issues.apache.org/jira/browse/CXF-153
> Project: CXF
> Issue Type: Improvement
> Components: Bus
> Affects Versions: 2.0-M1
> Reporter: Andrea Smyth
>
> Many bus extensions have a data member of type Bus, a corresponding setter
> that is typically injected (as per cxf-extensions.xml), and a @PostConstruct
> annotated method voif register(), in which they use the reference to the bus
> to register themselves as an extension to the bus. Otherwise the bus data
> member is never used.
> This should be simplified to avoid duplication and the trivial use of the bus
> data member just for the purpose of this registration.
> A second type of dynamically loaded objects (typically the on demand loaded
> bus extensions which do not actually register with the Bus) are the Foo
> factory objects (binding factories, destination factories, conduit
> initiators). They all follow the same priniciple that after creation they
> register themselves with their corresponding Foo factory manager. Again,
> this is a lot of duplicated code.
> See thread with subject "Two better ideas for Spring discovery" on cxf-dev
> for ideas on how to improve this - essentially based on searching the
> application context for objects of a certain type:
> (17:11:47) dandiep: instead of having the transport register itself, we can
> have a Collection class which we write which searches through the spring
> context for all the DestinationFactorys
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
