commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom DeBruycker" <tom.debruyc...@gmail.com>
Subject Re: CombinedConfiguration not reloading
Date Fri, 01 Dec 2006 20:39:35 GMT
Hi,

I think this is the case.  I am calling getProperty() on the
CombinedConfiguration object returned from
DefaultConfigurationBuilder.getConfiguration(true) not the enclosed
configuration.

I will add a bug to Jira.

Thanks,
Tom



On 12/1/06, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
>
> Hi,
>
> CombinedConfiguration registers itself as a ConfigurationListener at the
> added configurations. So if one of these performs a reload, a reload
> event will be triggered and the combined configuration can update itself.
>
> The problem here may be the way reloading is handled at the moment: Only
> when a property is accessed on a configuration, it checks if a reload is
> required. So if you do not directly access the configurations contained
> in the combined configuration, they will never notice that they have to
> be reloaded and thus never trigger the reloading event. Could this be
> the problem?
>
> Oliver
>
> Tom DeBruycker wrote:
> > Hi Oliver,
> >
> > Before I create a bug I wanted to describe the problem in a little more
> > detail. The reason is that I am not sure if it is a bug or designed that
> > way.  From what I see when tracing the code in a debugger the way it is
> > designed a reload can never occur for a CombinedConfiguration for my
> case.
> > In my case the property and xml files which make up my configuration can
> be
> > modified outside of my application.  Because they are modified outside
> my
> > application a ConfigurationEvent is not triggered.
> >
> > When I tried the same tests using a CompositeConfiguration
> requiresReload()
> > is called when getProperty() is invoked.
> >
> > The class CombinedConfiguration extends HierarchicalConfiguration.  The
> > logic which tests for a reload is implemented in
> > AbstractHierachicalFileConfiguration, which is not part of the
> > CombinedConfiguration hierarchy.  The getProperty() of
> > HierarchicalConfiguration does not use the delegate pattern or check for
> > reloadingRequired().
> >
> > So, after this long winded explanation I am not sure if I am using a
> > CombinedConfiguration in the way it was intended.
> >
> > If you still think this is a bug I will create the bug in Jira.
> >
> > Thanks in advance,
> > Tom DeBruycker
> >
> >
> >
> >
> > On 11/29/06, Oliver Heger <oliver.heger@oliver-heger.de > wrote:
> >>
> >> Thomas DeBruycker wrote:
> >> > Hi,
> >> >
> >> > I have a question about using the CombinedConfiguration with the
> >> > FileChangedReloadingStrategy.  For my test case I have a
> configuration
> >> XML
> >> > file that contains one property file and two XML files.  Each file in
> >> the
> >> > configuration XML file specifies a FileChangedReloadingStrategy.  The
> >> > problem that I am seeing is the the files are not reloaded when they
> >> are
> >> > modified.  When I tried this with a CompositeConfiguration the files
> >> were
> >> > reloaded as I had expected.
> >> >
> >> > My questions are:
> >> > 1) Should the CombinedConfiguration reload automatically if it's
> >> > configuration files change?
> >> > 2) Is it up to the user of the CombinedConfiguration to test if a
> >> reload
> >> is
> >> > required and then call DefaultConfigurationBuilder.getConfiguration
> >> (false)
> >> > to force the reload?
> >> >
> >> > Thanks in advance,
> >> > Tom DeBruycker
> >> >
> >>
> >> What you describe sounds like a bug. Regarding reloads
> >> CombinedConfiguration should behave like CompositeConfiguration. Can
> you
> >> open a bug report in JIRA [1] and attach your test case? I will have a
> >> look.
> >>
> >> Thanks
> >> Oliver
> >>
> >> [1] http://jakarta.apache.org/commons/configuration/issue-tracking.html
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message