PaxLogging does not do anything related to its configuration, it just reads
what is given from ConfigAdmin.

However the fix for KARAF-1243 might be a problem.
First the direct calls to file install is a bad idea as it maintains stuff
internally as to wether files were handled, checksum to detect changes and
such.
Second, if you want to update the configuration, you could have used a call
to updateConfiguration() which would have been easier without adding a
unwanted dependency between shell/config and file install.

On an unrelated point, I strongly disagree with the way KARAF-1279 has been
handled.
It should be something like:
   throw (IOException) new IOException().initCause(e);

In fact, I really suspect KARAF-1143 which may screw file install by
storing a URL/URI instead of a String as expected by file install.
See line 115
https://github.com/apache/felix/blob/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/ConfigInstaller.java#L115

Last, the problem may actually come from a regression in file install,
which is the one supposed to save back changes from the configuration to
the disk, but I'd check the above before.

On Fri, Apr 13, 2012 at 09:55, Christian Schneider
<[email protected]>wrote:

> Hi all,
>
> as far as I know this never was expected to work. Currently we do not
> change the felix config admin. So direct updates to the config pid are not
> expected to be persisted.
> Only config changes using the karaf config  mbean or the karaf shell
> commands write the config back.
> JB wrote we might have had a hook somewhere but I was not able to find it
> in the karaf 2.2.5 sources.
>
> JB tested using log:set DEBUG which persists the change in the config file
> in Karaf 2.2.5 but not in 2.2.6. I am not sure though that the perist is
> done by karaf code here. It might also be done by pax logging. I will check
> this.
>
> Christian
>
> Am 12.04.2012 14:27, schrieb Jean-Baptiste Onofré:
>
>  Hi guys,
>>
>> In Karaf 2.2.6, in order to improve the ConfigAdmin management (using
>> config:* commands and ConfigMBean), we changed the way to handle
>> configuration files and flush on the storage.
>>
>> It leads to a "critical" regression where the ConfigAdmin update are not
>> flushed into the configuration file:
>> https://issues.apache.org/**jira/browse/KARAF-1360<https://issues.apache.org/jira/browse/KARAF-1360>
>>
>> I'm gonna take a look on this issue and fix it asap.
>>
>> I just wonder if:
>> - it makes sense to release a 2.2.6.1 (a kind of hotfix release)
>> - it makes sense to wait 2.2.7 but we should cut off this release very
>> soon
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Reply via email to