Are you saying that a custom karaf distribution will (hopefully) exhibit different behaviour from the standard distribution with the fragment manually added to etc/startup.properties? If so I'll give that a go and I guess log bug with the results from these 3 ways of adding the fragment.
Thanks, Paul On 18 July 2016 at 08:08, Guillaume Nodet <[email protected]> wrote: > I don't understand where the bug is. > If you install a fragment, either you add it to a feature somehow, or you > add it to the etc/startup.properties. > In the first case, the pax-logging bundle has to be refreshed. Else, the > fragment won't be wired to the bundle. > This may lead to the console being restarted, and that's not necessarily a > problem. > Note that the above should only happen at the first boot. > A work around would be to generate a custom karaf distribution and make > sure that fragment bundle is part of the startup phase, in which case it > will be added to the etc/startup.properties and be correctly installed in > the very first startup and the need to refresh the pax-logging service > bundle should go away. > > Guillaume > > 2016-07-01 13:42 GMT+02:00 pkmcculloch <[email protected]>: > >> I'm encountering what I think is exactly the same issue in a vanilla >> 4.0.5. >> Once my logging fragment is installed any subsequent feature installation >> results in a partial framework restart, and a re-display of the console >> banner. >> >> If I do a verbose installation of (in this case webconsole) then I see >> >> ... >> No deployment change. >> Stopping bundles: >> org.ops4j.pax.logging.pax-logging-service/1.8.5 >> Refreshing bundles: >> org.ops4j.pax.logging.pax-logging-service/1.8.5 (Attached fragments >> changed: []) >> Starting bundles: >> org.ops4j.pax.logging.pax-logging-service/1.8.5 >> ... >> >> I did some debugging and found that in >> >> org.apache.karaf.features.internal.service.Deployer.computeBundlesToRefresh() >> the 'newFragments' that are calculated for the pax logging bundle don't >> include the fragment. The 'oldFragments' variable does include the bundle, >> so a change is flagged & the pax logging bundle is restarted. >> >> The content of the fragment (beyond the manifest) is irrelevant - a >> fragment >> containing no classes also causes this behaviour. >> >> I also found that the same behaviour is exhibited if the fragment is >> installed as any other bundle, rather than via startup.properties. The >> fragment also works in this scenario, so I wonder if the advice in the >> manual to install via startup is out of date? >> >> Thanks for any advice on this. >> >> Paul >> >> >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Karaf-4-0-5-Strange-console-log-messages-when-using-custom-log-appenders-tp4046563p4047053.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
