Great news, yepp, I agree with Justin
2014-02-06 18:51 GMT+01:00 Justin Edelson jus...@justinedelson.com:
Hi Chetan,
Thanks for following through on this. I think the loss of messages
during initialization is less than ideal, but acceptable and certainly
understandable.
Justin
On Thu,
Just an update. The issue has now been fixed on Slf4j side and a new
release 1.7.6 was made which contains the fix. So this completes the
#3 approach mentioned previously.
With this there is just a small issue that while Slf4j is getting
initialized the log message would get lost as at that time
Any comments ... which approach to take?
Chetan Mehrotra
On Sat, Jan 25, 2014 at 12:59 PM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
Yes such a situation might occur. Some approaches I can think of are
1. Special case Log bundles when installing bundle in
BootstrapInstaller. So in the
I would prefer 3 if feasible/doable in a short time frame.
The other option I see would be to enhance our launchpad support and allow
for different start levels for both, the bootstrap installer and the osgi
installer. For now, all bundles in the boot level get the same start
level. Unfortunately
So an ugly option would be to have:
startLevel level=boot
log bundles
/startlevel
startLevel level=boot:2
everything else
/startLevel
Carsten
2014-01-29 Carsten Ziegeler cziege...@apache.org
I would prefer 3 if feasible/doable in a short time frame.
The other option I see would be to
On Wed, Jan 29, 2014 at 3:24 PM, Carsten Ziegeler cziege...@apache.org wrote:
I would prefer 3 if feasible/doable in a short time frame.
Seeing the slow release cycle of Slf4j API it might take some time to
push for such change and get a release done. I would start a
discussion on there DL.
For
On Wed, Jan 29, 2014 at 10:58 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
...So can we go for #2?...
Which is adding custom bundle header 'x-sling-startup-order' that our
bootstrap installer takes into account?
But how is that handled? Set the bundle's OSGi start level to a
different
Right, there is no well defined start order for bundles in the same start
level - so this doesn't help us. If we need an order, we have to use
different start levels
Adjusting the start level for an update should be easy (the OSGi installer
does so already) and hopefully a simple fix in the
On Wed, Jan 29, 2014 at 11:21 AM, Carsten Ziegeler cziege...@apache.org wrote:
...all this adds a lot of cruft to fix a single simple problem in a
logging implementation. I see the point that slf4j releases might take some
time, but I think that's the right place to fix it and avoids adding
on the next startup the bundles will again start in an
unpredictable order, if they have the same start level.
Aah .. I misread the code. I thought Sling starts the bundle always
though that code path. Missed the facts that such a flow is only used
for new bundles.
Chetan, do you see a
Funnily we had a discussion about the start order of bundles in the same
start level last week during our OSGi CPEG meeting and leaving out all the
nice details, never ever rely on that.
And for B we would need changes at least in the launchpad - for A we just
fix slf4j
Carsten
2014-01-29
On Wed, Jan 29, 2014 at 4:39 PM, Carsten Ziegeler cziege...@apache.org wrote:
never ever rely on that.
Agreed. But ...
And for B we would need changes at least in the launchpad - for A we just
fix slf4j
Change in our code is in our control and easy to do without incurring
any penalty. Fix in
Yes such a situation might occur. Some approaches I can think of are
1. Special case Log bundles when installing bundle in
BootstrapInstaller. So in the installBundle call [2] we would have to
add some kind of sorting such that Slf4j related bundles get started
first *before* any other bundle is
13 matches
Mail list logo
