[log] enhance the logger names for legacy event mappings

[bjhargrave]

Original bug ID: BZ#3071
From: @rotty3000
Reported version: R7

[bjhargrave]

Comment author: @rotty3000

In order to have finer control of log records produced by the new (1.4) mappings of legacy events:

Events.Bundle
Events.Framework
Events.Service
LogService

It would be a great improvement if the actual logger names were defined as:

mapping := legacyMapping '.' bsn
legacyMapping := Events.Bundle | Events.Framework | Events.Service | LogService

I would like to recommend this as an addendum to the R7 Log 1.4 specification with a relaxation of the CT to accommodate for this.

Currently, it's very hard to control the logging centrally for these legacy logger names because there is no granularity it's either all or nothing. One cannot target bundles either directly or in groups.

[bjhargrave]

Comment author: @bjhargrave

Uh, the spec is now final. So we cannot change this now.

To change for LogService 1.5 (in R8) would be a breaking change for anyone who uses the names specified in LogService 1.4 spec. So I don't think we want to do that either.

Also, no other logger name incorporates BSN. Why is this so special?

[bjhargrave]

Comment author: @rotty3000

(In reply to BJ Hargrave from comment BZ#1)

Uh, the spec is now final. So we cannot change this now.

To change for LogService 1.5 (in R8) would be a breaking change for anyone
who uses the names specified in LogService 1.4 spec. So I don't think we
want to do that either.

Also, no other logger name incorporates BSN. Why is this so special?

I didn't suggest changing the spec right now, I suggested making an immediate addendum (i.e. via bugzilla) that we recognize the limitation in the spec and that Impls can make this change. It's and innocuous change.

[bjhargrave]

Comment author: @rotty3000

(In reply to BJ Hargrave from comment BZ#1)

Also, no other logger name incorporates BSN. Why is this so special?

With every other logger name you have a hierarchy that you can use to target subsets.

for instance if someone has a Logger com.foo.bar.baz.Thing the you can control the level of that thing via

com.foo=DEBUG

which is powerful.

However with the logger names mentioned there is no such grouping possible, unless you consider just

Events=DEBUG

to be useful.

In a system with hundreds of modules the granularity of

Events.Service=INFO

or

LogService=INFO

is not fine enough.

Remember that these 4 logger names are special because they are taking legacy logger categories and attempting to map them for control via LoggerAdmin management. Without a deeper, finer logger name it's painful to currently control them.

[bjhargrave]

Comment author: @rotty3000

defer to R8

[bjhargrave]

Comment author: @tjwatson

In light of bug BZ#3113 we need to keep in mind that in some cases we may not have a Bundle object to find the BSN for. I assume in that case (and in the case of OSGi R3 bundles) logger names would fall back to the "simple" names with no . suffix.

[bjhargrave]

Comment author: @bjhargrave

CPEG call: Will do for R8.