[
https://issues.apache.org/jira/browse/CXF-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677403#action_12677403
]
Sergey Beryozkin commented on CXF-2075:
---------------------------------------
Hi Seumas
I think the solution should be about introducing a new type of exception. The
second class loading attempt is there to ensure things work nicely in OSGI,
though it does mask an issue if the problem is caused by the corrupt
configuration file. Perhaps the original problem has been fixed but before CXF
can get updated with your fix it would be good if a higher-level project which
might be depending on CXF run the OSGI tests with the proposed fix in a local
snapshot.
Having a seperate catch block like catch (CorruptConfigurationFile) might be
simpler if it's just a poorly formatted config file which causes the problems.
If the application context loading has failed due to class loading issues then
it could be trickier.
Now that I've said it all I reckon the best option would be actually to store
the original BeansException, give it a second try, and if the exception is
thrown again then rethrow the original BeansException
> Error in spring config file reported as a missing config file during
> initialization of BusApplicationContext
> ------------------------------------------------------------------------------------------------------------
>
> Key: CXF-2075
> URL: https://issues.apache.org/jira/browse/CXF-2075
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.4
> Reporter: Seumas Soltysik
>
> The current code to create a Bus in SpringBusFactory masks any problem in
> processing the spring config file passed in to SpringBusFactory. Currently if
> a config file is corrupt, the exception thrown trying to process this file is
> eaten and an attempt to create a Bus is tried again with a different thread
> context classloader. This completely hides the source of the error and
> results in a message which indicates that the config file could not be found
> which is completely misleading for the user.
> The solution is to not perform the 2nd attempt to create a
> BusApplicationContext and let the original exception propagate upwards.
> private BusApplicationContext createApplicationContext(String
> cfgFiles[], boolean includeDefaults) {
> try {
> return new BusApplicationContext(cfgFiles, includeDefaults,
> context);
> } catch (BeansException ex) {
> ClassLoader contextLoader =
> Thread.currentThread().getContextClassLoader();
> if (contextLoader !=
> BusApplicationContext.class.getClassLoader()) {
> Thread.currentThread().setContextClassLoader(
> BusApplicationContext.class.getClassLoader());
> try {
> return new BusApplicationContext(cfgFiles,
> includeDefaults, context);
> } finally {
>
> Thread.currentThread().setContextClassLoader(contextLoader);
> }
> } else {
> throw ex;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
