Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <22235538.1178124015989.JavaMail.jira@brutus>
Date: Wed, 2 May 2007 09:40:15 -0700 (PDT)
From: "Steven E. Harris (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Commented: (CXF-621)
 org.apache.cxf.bus.spring.BusApplicationContext constructor does not
 respect "include defaults" flag
In-Reply-To: <25173523.1178057475793.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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