Bug 535053

Summary:	Replace org.eclipse.core.databinding activator logging with OSGi logging
Product:	[Eclipse Project] Platform	Reporter:	Lars Vogel <Lars.Vogel>
Component:	UI	Assignee:	Christoph Laeubrich <laeubi>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	dirk.fauth, laeubi, Lars.Vogel, ma.becker, tom.schindl
Version:	3.7.1
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Lars Vogel

2018-05-24 03:37:32 EDT

The org.eclipse.core.databinding bundle uses the Activator for logging. AFAIK there is new OSGi API which makes this easy. 

We should replace the existing logic with OSGI logging, if possible. If we could remove the activator that would be helpful as every activator slows down the startup of Eclipse.

Comment 1 Lars Vogel

2018-05-24 03:38:07 EDT

Dirk, you are the OSGi logging expert. Could you help here?

Comment 2 Thomas Schindl

2018-05-24 03:42:55 EDT

Please make sure that it still works outside osgi!

Comment 3 Lars Vogel

2018-05-24 03:47:23 EDT

(In reply to Thomas Schindl from comment #2)
> Please make sure that it still works outside osgi!

+1, IIRC Dirk did implement it in one of his recent changes optional.

Comment 4 Thomas Schindl

2018-05-25 02:58:08 EDT

If i would have a say I'd stick in all modules who should run outside OSGi to slf4j but that's just my personal preference

Comment 5 Matthias Becker

2018-08-02 02:53:17 EDT

so what is that new API exactly?

Comment 6 Lars Vogel

2020-02-05 05:51:40 EST

Maybe Christoph can help here?

Comment 7 Dirk Fauth

2020-02-06 00:50:09 EST

I have added the optional OSGi logging variant only in our declarative services. Outside the services this is getting more complicated.

To add an idea here for discussion:
Inside the runtime we move from using the Platform.log API or any other OSGi logging variant to SLF4J API. And we add a Platform Logging SLF4J implementation that we ship with the IDE.

This way we could decouple any Platform code from specific logging and still write the logs as before. In non-OSGi environments the usage of a different logging implementation can be used.

For E4 I thought of implementing a Log ExtendedObjectSupplier. The platform could then provide such a provider to return an OSGi logger. Adaptors could implement it to return whatever they like, e.g. an SLF4J logger or a Guava logger for example. I started with such a supplier, but it needs some more work.

@Tom
What do you think about that approach?

@Lars
Would that also be a suitable solution for the platform? Would it be accepted by the project leads?

Comment 8 Christoph Laeubrich

2020-03-01 05:24:14 EST

@Dirk As the platform logging itself delegates to the OSGi-Logging it might be even suitable to use https://github.com/osgi/slf4j-osgi it is even available via orbit deps.

Comment 9 Christoph Laeubrich

2020-03-01 05:35:23 EST

@Lars I have checked this and it seems the Activator already is using OSGi-Services (FrameworkLog in this case) to send logging events to, falling back to System out if not available.

Even though I see some issues with the actual implementation I'm not sure what would be the final goal.

As mentioned before, the activator itself does not do any special logging but only setups the Policy "log", so do you have in mind replacing the whole policy log by some other means? Or maybe just replace the activator itself and let the policy setup lazily logging when it is first requested?