[
https://issues.apache.org/jira/browse/CXF-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493140
]
Steven E. Harris commented on CXF-621:
--------------------------------------
When I step through the BusApplicationContext constructor in my debugger, I run
into a class called "JaxbClassPathXmlApplicationContext", a superclass of
BusApplicaitonContext. But when I look in the SVN repository, there is no such
class, and BusApplicationContext derives directly from Spring's
ClassPathXmlApplicationContext. The Maven-distributed JAR for the CXF RT core
contains a class file for JaxbClassPathXmlApplicationContext:
% jar tvf cxf-rt-core-2.0-incubator-SNAPSHOT.jar | egrep JaxbClassPa
4878 Fri Apr 27 15:45:54 PDT 2007
org/apache/cxf/configuration/spring/JaxbClassPathXmlApplicationContext.class
Where is this class coming from? Is it a stale leftover sitting in the
target/classes directory of the machine that builds the Maven artifacts?
> org.apache.cxf.bus.spring.BusApplicationContext constructor does not respect
> "include defaults" flag
> ------------------------------------------------------------------------------------------------------
>
> Key: CXF-621
> URL: https://issues.apache.org/jira/browse/CXF-621
> Project: CXF
> Issue Type: Bug
> Components: Bus
> Affects Versions: 2.0-RC
> Environment: NA
> Reporter: Steven E. Harris
> Assigned To: willem Jiang
> Fix For: 2.0
>
> Attachments: bus_fixes.patch, bus_fixes_post_cs.patch
>
>
> BusApplicationContext's constructors accept a boolean argument "include" to
> indicate whether it should try to load the default configuration files
> discovered on the class path. The problem comes from poor interaction among
> initialization of a member variable (includeDefaults) and the overridden
> method getConfigResources().
> Two of the constructors have similar form:
> public BusApplicationContext(String cf, boolean include,
> ApplicationContext parent) {
> super((String[])null, parent);
> cfgFile = cf;
> includeDefaults = include;
> }
> Note that "includeDefaults" is not initialized until the base class
> constructor returns. However, as part of the base constructor chain,
> ClassPathXmlApplicationContext calls refresh(), which triggers a long call
> chain that results in getConfigResources() being called.
> BusApplicationContext overrides getConfigResources(). One of the first things
> it does is reads its "includeDefaults" flag -- but at this point the flag has
> not been initialized by the constructor, so it defaults to false. Therefore,
> no matter what the value of the "include" parameter to the
> BusApplicationContext constructor, only a false value gets used during
> construction.
> Unfortunately, there's no way to do anything such as initializing member
> variables before calling the superclass's constructor. Therefore, the fix is
> to call on a different ClassPathXmlApplicationContext constructor -- the one
> that takes a boolean flag indicating whether to refresh() immediately. We can
> pass false, initialize our member variables, then call refresh() explicitly:
> public BusApplicationContext(String cf, boolean include,
> ApplicationContext parent) {
> super((String[])null, false, parent);
> cfgFile = cf;
> includeDefaults = include;
> refresh();
> }
> I haven't tested this code, but it looks like it should fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
