You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by pkmcculloch <pk...@gmail.com> on 2016/07/01 11:42:36 UTC
Re: [Karaf 4.0.5] Strange console log messages when using custom
log appenders
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.
Re: [Karaf 4.0.5] Strange console log messages when using custom log appenders
Posted by Paul McCulloch <pk...@gmail.com>.
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 <gn...@apache.org> 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 <pk...@gmail.com>:
>
>> 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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
Re: [Karaf 4.0.5] Strange console log messages when using custom log appenders
Posted by Guillaume Nodet <gn...@apache.org>.
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 <pk...@gmail.com>:
> 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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/