[ 
https://issues.apache.org/jira/browse/CXF-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678041#action_12678041
 ] 

Daniel Kulp commented on CXF-2075:
----------------------------------



I'd STRONGLY prefer trying to remove the second call entirely.   This has a 
side affect of possibly causing objects to be instantiated twice which could do 
strange things if the objects aren't expecting that.   One example could be 
management which would setup connections to MBean servers and such.  You could 
end up with two things listed in the MBean servers.

Thus, I'd like to figure out why the second was necessary and try to fix that.  
 Do you know if it couldn't find a resource?   Couldn't find a config file?   
Couldn't find a class?   etc....?

One option COULD be to create a new Classloader that would delegate first to 
the current contextClassLoader and then to the 
BusApplicationContext.class.getClassLoader() and set the contextClassLoader to 
that.   That SHOULD allow anything that wasn't found the old method to be 
found.   

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

Reply via email to