[
https://issues.apache.org/jira/browse/CXF-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678047#action_12678047
]
Sergey Beryozkin commented on CXF-2075:
---------------------------------------
> Do you know if it couldn't find a resource? Couldn't find a config file?
> Couldn't find a class? etc....?
It was probably 5/6 months ago when I applied this now infamous :-) retry. I
belive it was about either classes or class resources being not found when run
in OSGI. I honestly don't remember.
But I'd personally would not remove the second try before a Progress project
which depends on CXF would run all the OSGI tests without it. Dan - perhaps
creating a tailored ClassLoader would be a neat idea indeed - but it can also
cause some OSGI issues as well as we might end up with some resources/classes
being loaded by different loaders.
> This has a side affect of possibly causing objects to be instantiated twice
This is something we obviously do not want - but so far we haven't had any
sideeffects - may be because it's now a dead code altogether which just kick in
by swallowing an exception.
IMHO it would be good if a quick Progress-internal build could be setup without
this second retry. If it works then this code can be just removed, If it does
not then I'd start with what Seumas suggested - logging the original exception
and opened a JIRA for exploring the possibility of creating a new class loader
- the idea behind it does sound good - but it can be difficult to implement
while working at the CXF/Fuse level only
> 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.
