You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2007/12/05 15:29:43 UTC
[jira] Created: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
-----------------------------------------------------------------------------------------------------------------------
Key: CXF-1260
URL: https://issues.apache.org/jira/browse/CXF-1260
Project: CXF
Issue Type: Bug
Components: Configuration
Affects Versions: 2.0.3
Reporter: Gary Tully
Fix For: 2.0.4
Since: http://svn.apache.org/viewvc?view=rev&revision=584908
cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
This is not uncommon as cxf.xml is the default user configuration file name.
It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549096 ]
Gary Tully commented on CXF-1260:
---------------------------------
patch committed, thanks dan:
URL: http://svn.apache.org/viewvc?rev=601763&view=rev
Log:
[CXF-1260] Fix spurious warnings and issues loading multiple contexts and such Fix spurious warnings and issues loading multiple contexts and such
> ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-1260
> URL: https://issues.apache.org/jira/browse/CXF-1260
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.0.3
> Reporter: Gary Tully
> Fix For: 2.0.4
>
> Attachments: ignore_cxf_xml.patch.txt
>
>
> Since: http://svn.apache.org/viewvc?view=rev&revision=584908
> cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
> When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
> This is not uncommon as cxf.xml is the default user configuration file name.
> It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
> Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
> I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved CXF-1260.
-----------------------------
Resolution: Fixed
> ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-1260
> URL: https://issues.apache.org/jira/browse/CXF-1260
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.0.3
> Reporter: Gary Tully
> Fix For: 2.0.4
>
> Attachments: ignore_cxf_xml.patch.txt
>
>
> Since: http://svn.apache.org/viewvc?view=rev&revision=584908
> cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
> When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
> This is not uncommon as cxf.xml is the default user configuration file name.
> It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
> Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
> I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548683 ]
Gary Tully commented on CXF-1260:
---------------------------------
A workaround is to move your user cxf.xml to say user-cxf.xml and provide -Dcxf.config.file=user-cxf.xml to the jvm.
In this case, ConfigureImpl will not find cxf.xml on the classpath and will not try and create a BusApplicationContext when constructed from spring.
Spring bus factory will already have resolved user-cxf.xml and added it to its application context which will eventually be set on the ConfigureImpl that spring created so all still hangs together.
> ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-1260
> URL: https://issues.apache.org/jira/browse/CXF-1260
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.0.3
> Reporter: Gary Tully
> Fix For: 2.0.4
>
>
> Since: http://svn.apache.org/viewvc?view=rev&revision=584908
> cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
> When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
> This is not uncommon as cxf.xml is the default user configuration file name.
> It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
> Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
> I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully closed CXF-1260.
---------------------------
> ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-1260
> URL: https://issues.apache.org/jira/browse/CXF-1260
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.0.3
> Reporter: Gary Tully
> Fix For: 2.0.4
>
> Attachments: ignore_cxf_xml.patch.txt
>
>
> Since: http://svn.apache.org/viewvc?view=rev&revision=584908
> cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
> When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
> This is not uncommon as cxf.xml is the default user configuration file name.
> It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
> Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
> I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1260) ConfigureImpl with spring construction
duplicates looking for cxf.xml on the classpath and can error out with a
warning
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully updated CXF-1260:
----------------------------
Attachment: ignore_cxf_xml.patch.txt
this patch ensures that ConfigureImpl will not look for cxf.xml on the classpath and will not create a Busapplicaiton context. The application context is either passed in in the constructor or set via the setter. at the moment the set injection is preformed automatically as it implements the ApplicationContextAware interface.
> ConfigureImpl with spring construction duplicates looking for cxf.xml on the classpath and can error out with a warning
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-1260
> URL: https://issues.apache.org/jira/browse/CXF-1260
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.0.3
> Reporter: Gary Tully
> Fix For: 2.0.4
>
> Attachments: ignore_cxf_xml.patch.txt
>
>
> Since: http://svn.apache.org/viewvc?view=rev&revision=584908
> cxf.xml in rt-core is responsible for creating an instance of ConfigureImpl. This is problematic because the defauilt constructed version of ConfigureImpl looks for cxf.xml (or cxf.config.file sys property) on the classpath (it does not look for cxf.config.uri!) and creates a BusApplicationContex if it finds one. This is unnecessary as the current applicaton context will be injected in via the ApplicationContextAwareProcessor.
> When cxf.xml on the classpath references other beans that come from extensions, application context creation fails with an exception that is logged as a warning. this is ugly.
> This is not uncommon as cxf.xml is the default user configuration file name.
> It seems like ConfigureImpl is duplicating code around default configuration that is already managed by the BusApplicaitonContext.
> Does ConfigureImpl have a place outside spring that necessitates looking for cxf.xml?
> I think the fix may be to remove the posibility that ConfigureImpl can create its own BusApplicationContext. What do you think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.