Community
Participate
Working Groups
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.
Dirk, you are the OSGi logging expert. Could you help here?
Please make sure that it still works outside osgi!
(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.
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
so what is that new API exactly?
Maybe Christoph can help here?
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?
@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.
@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?
