Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <13820005.1187696016252.JavaMail.jira@brutus>
Date: Tue, 21 Aug 2007 04:33:36 -0700 (PDT)
From: "Andrea Smyth (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Resolved: (CXF-153) Simplify Registration of Extensions
In-Reply-To: <17028837.1161017675001.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.