discussion about LogService ranking in osgi-over-slf4j
Hi osgi-over-slf4j developers, I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change: Properties props = new Properties(); *props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10);* ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props); to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ... Christian
Hi Christian, Thank you for the suggestion. We have had a pretty good discussion about the eclipse case and came to the conclusion that it would not be a good idea to change the service ranking but instead to create a specific Eclipse logger that can catch all the various Eclipse log events (I think there are three total) and log them to SLF4J. It could depend on this specific LogService via the service query. The Eclipse LogService could then provide a higher service level, even with a Property that would be settable in the Eclipse prefs. Osgi-over-slf4j has many places to live other than Eclipse so it needs to play nice across the board. Upping the service ranking in code is definitely not nice. Matt From: Christian Trutz <christian.trutz@belaso.de<mailto:christian.trutz@belaso.de>> Reply-To: slf4j developers list <slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>> Date: Tuesday, 23 October, 2012 11:05 AM To: "slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>" <slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>> Subject: [slf4j-dev] discussion about LogService ranking in osgi-over-slf4j Hi osgi-over-slf4j developers, I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change: Properties props = new Properties(); props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10); ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props); to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ... Christian [http://elasticpath.com/images/ep.gif] Matthew Bishop, Senior Architect Phone: 604.408.8078 ext. 101 Email: Matthew.Bishop@elasticpath.com<mailto:Matthew.Bishop@elasticpath.com> Elastic Path Software, Inc. Web elasticpath.com <http://www.elasticpath.com/> | Blog getelastic.com <http://www.getelastic.com/> | Twitter twitter.com/elasticpath <http://www.twitter.com/elasticpath> Careers elasticpath.com/jobs<http://www.elasticpath.com/jobs> | Community grep.elasticpath.com <http://grep.elasticpath.com/> Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is prohibited and may be unlawful. If you received this e-mail in error, please reply to the sender immediately to inform us you are not the intended recipient and delete the email from your computer system.
Hi Matt, OK you are right, hard-coding service ranking is too pragmatic. But how about making SLF4J LogService a OSGi managed service (with updated() method). The developer/user can then set the service ranking via admin console ... Christian 2012/10/23 Matthew Bishop <Matthew.Bishop@elasticpath.com>
Hi Christian,
Thank you for the suggestion. We have had a pretty good discussion about the eclipse case and came to the conclusion that it would not be a good idea to change the service ranking but instead to create a specific Eclipse logger that can catch all the various Eclipse log events (I think there are three total) and log them to SLF4J. It could depend on this specific LogService via the service query. The Eclipse LogService could then provide a higher service level, even with a Property that would be settable in the Eclipse prefs.
Osgi-over-slf4j has many places to live other than Eclipse so it needs to play nice across the board. Upping the service ranking in code is definitely not nice.
Matt
From: Christian Trutz <christian.trutz@belaso.de> Reply-To: slf4j developers list <slf4j-dev@qos.ch> Date: Tuesday, 23 October, 2012 11:05 AM To: "slf4j-dev@qos.ch" <slf4j-dev@qos.ch> Subject: [slf4j-dev] discussion about LogService ranking in osgi-over-slf4j
Hi osgi-over-slf4j developers,
I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change:
Properties props = new Properties(); *props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10);* ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props);
to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ...
Christian
Matthew Bishop, Senior Architect Phone: 604.408.8078 ext. 101 Email: Matthew.Bishop@elasticpath.com *Elastic Path Software, Inc.* Web elasticpath.com <http://www.elasticpath.com/>| Blog getelastic.com <http://www.getelastic.com/>| Twitter twitter.com/elasticpath <http://www.twitter.com/elasticpath> Careers elasticpath.com/jobs <http://www.elasticpath.com/jobs> | Community grep.elasticpath.com
Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is prohibited and may be unlawful. If you received this e-mail in error, please reply to the sender immediately to inform us you are not the intended recipient and delete the email from your computer system.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
I like that idea. Do you want to take a crack at it? -- Matthew Bishop Senior Product Architect Elastic Path Inc. On 2012-10-24, at 12:00 AM, "Christian Trutz" <christian.trutz@belaso.de<mailto:christian.trutz@belaso.de>> wrote: Hi Matt, OK you are right, hard-coding service ranking is too pragmatic. But how about making SLF4J LogService a OSGi managed service (with updated() method). The developer/user can then set the service ranking via admin console ... Christian 2012/10/23 Matthew Bishop <Matthew.Bishop@elasticpath.com<mailto:Matthew.Bishop@elasticpath.com>> Hi Christian, Thank you for the suggestion. We have had a pretty good discussion about the eclipse case and came to the conclusion that it would not be a good idea to change the service ranking but instead to create a specific Eclipse logger that can catch all the various Eclipse log events (I think there are three total) and log them to SLF4J. It could depend on this specific LogService via the service query. The Eclipse LogService could then provide a higher service level, even with a Property that would be settable in the Eclipse prefs. Osgi-over-slf4j has many places to live other than Eclipse so it needs to play nice across the board. Upping the service ranking in code is definitely not nice. Matt From: Christian Trutz <christian.trutz@belaso.de<mailto:christian.trutz@belaso.de>> Reply-To: slf4j developers list <slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>> Date: Tuesday, 23 October, 2012 11:05 AM To: "slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>" <slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch>> Subject: [slf4j-dev] discussion about LogService ranking in osgi-over-slf4j Hi osgi-over-slf4j developers, I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change: Properties props = new Properties(); props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10); ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props); to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ... Christian [http://elasticpath.com/images/ep.gif] Matthew Bishop, Senior Architect Phone: 604.408.8078 ext. 101 Email: Matthew.Bishop@elasticpath.com<mailto:Matthew.Bishop@elasticpath.com> Elastic Path Software, Inc. Web elasticpath.com <http://www.elasticpath.com/> | Blog getelastic.com <http://www.getelastic.com/> | Twitter twitter.com/elasticpath <http://www.twitter.com/elasticpath> Careers elasticpath.com/jobs<http://www.elasticpath.com/jobs> | Community grep.elasticpath.com <http://grep.elasticpath.com/> Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is prohibited and may be unlawful. If you received this e-mail in error, please reply to the sender immediately to inform us you are not the intended recipient and delete the email from your computer system. [http://elasticpath.com/images/ep.gif] Matthew Bishop, Senior Architect Phone: 604.408.8078 ext. 101 Email: Matthew.Bishop@elasticpath.com<mailto:Matthew.Bishop@elasticpath.com> Elastic Path Software, Inc. Web elasticpath.com <http://www.elasticpath.com/> | Blog getelastic.com <http://www.getelastic.com/> | Twitter twitter.com/elasticpath <http://www.twitter.com/elasticpath> Careers elasticpath.com/jobs<http://www.elasticpath.com/jobs> | Community grep.elasticpath.com <http://grep.elasticpath.com/> Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is prohibited and may be unlawful. If you received this e-mail in error, please reply to the sender immediately to inform us you are not the intended recipient and delete the email from your computer system. _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch> http://mailman.qos.ch/mailman/listinfo/slf4j-dev _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch<mailto:slf4j-dev@qos.ch> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
Hello Christian, Hi Matthew, yes we have very very long discussion exactly about it a month or two ago. Matthew is strictly against to these tweak with service ranking. I suggested to introduce a system property that will control this "dominante or not" behaviour which will default to not being dominate (not specifying service ranking) thus keeping backward compatibility with current osgi-over-slf4j. See my comments https://github.com/qos-ch/slf4j/pull/24 if you are interested. Becoming service manageable via ConfigAdmin is another option. IMHO maybe too much overkill for >>Simple<< Logging Facade 4 Java.... About Eclipse-specific use: Also a month or two ago I suggested this patch https://github.com/bircow/slf4j/compare/acfb07...a20787. Actually Eclipse doesn't use any specific OSGi Log Service than adding 3-4 methods. So I implemented Equinox ExtendedLogService by inheriting from origin osgi-over-slf4j adding these specific methods. To cite my previous comments on this topic: *To idea to fork OOS and maintain autonomous Eclipse bridge: I'm rather against because *there is no actual difference*. Eclipse Platform log is logging to OSGi Log Service (to be specific to Equinox child of LogService named ExtendedLogService) under the covers. I've reimplemented ExtendedLogService that inherit from current OOS LogService impl, but adding a few of additional methods specific to ExtendedLogService only. You may review all my proposals at https://github.com/bircow/slf4j/compare/acfb07...a20787. ExtendedLogService impl draft is commit a20787. (Ignore commit specific to ease my OSGi development in Eclipse PDE tooling.) In summary, bridging Eclipse Platform log is are two new files that doesn't have impact to non-Equinox OSGi environments (depedency on Equinox is marked optional).* Unfortunatelly due to this difference of opinions among us, these enhancements toward more confortable Eclipse usage still waits. However I'm personally already using it in our own quite large Eclipse-based application with satisfaction. It do what it should do -- real single-target logging, i.e. every log message no matther whether produced by OSGi Log Service or Eclipse Platform Logger is bridged to SLF4J. -- Hezky den / Have a nice day Libor JELÍNEK VIRTAGE SOFTWARE // software - design - web Lucni 542 // 285 04 Uhlirske Janovice // Czech Republic support: +420 315 555 488 // cell: +420 777 205 142 email/jabber: ljelinek@virtage.com // web: www.virtage.com Visit our developer adventures at http://devblog.virtage.com! On Tue, Oct 23, 2012 at 8:05 PM, Christian Trutz <christian.trutz@belaso.de> wrote:
Hi osgi-over-slf4j developers,
I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change:
Properties props = new Properties(); props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10); ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props);
to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ...
Christian
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
Hi Libor, I find that implementing the SLF4J LogService as OSGi ManagedService is better than - configuring service ranking via system property or - bridging Equinox Log Service implementation to SLF4J because: 1) as ManagedService you can change the configuration at runtime and switch between multiple log services. An use case could be: a OSGi application logs regurally with a "default" LogService (not SLF4J LogService) but you want to switsch the log temporally because you want to see the log messages in Beagle for example. With SLF4J as ManagedService you do not have to shutdown and restart you application. 2) bridging Equinox Log Service can be also very confusing for users/admin who don't know that osgi-over-slf4j has this feature ... Anyway, I forked slf4j and I'm going to play around with LogService as ManagedService ... Christian 2012/10/25 Libor Jelinek <ljelinek@virtage.com>
Hello Christian, Hi Matthew, yes we have very very long discussion exactly about it a month or two ago. Matthew is strictly against to these tweak with service ranking. I suggested to introduce a system property that will control this "dominante or not" behaviour which will default to not being dominate (not specifying service ranking) thus keeping backward compatibility with current osgi-over-slf4j.
See my comments https://github.com/qos-ch/slf4j/pull/24 if you are interested.
Becoming service manageable via ConfigAdmin is another option. IMHO maybe too much overkill for >>Simple<< Logging Facade 4 Java....
About Eclipse-specific use: Also a month or two ago I suggested this patch https://github.com/bircow/slf4j/compare/acfb07...a20787. Actually Eclipse doesn't use any specific OSGi Log Service than adding 3-4 methods. So I implemented Equinox ExtendedLogService by inheriting from origin osgi-over-slf4j adding these specific methods.
To cite my previous comments on this topic: *To idea to fork OOS and maintain autonomous Eclipse bridge: I'm rather against because *there is no actual difference*. Eclipse Platform log is logging to OSGi Log Service (to be specific to Equinox child of LogService named ExtendedLogService) under the covers. I've reimplemented ExtendedLogService that inherit from current OOS LogService impl, but adding a few of additional methods specific to ExtendedLogService only. You may review all my proposals at https://github.com/bircow/slf4j/compare/acfb07...a20787. ExtendedLogService impl draft is commit a20787. (Ignore commit specific to ease my OSGi development in Eclipse PDE tooling.)
In summary, bridging Eclipse Platform log is are two new files that doesn't have impact to non-Equinox OSGi environments (depedency on Equinox is marked optional).*
Unfortunatelly due to this difference of opinions among us, these enhancements toward more confortable Eclipse usage still waits. However I'm personally already using it in our own quite large Eclipse-based application with satisfaction. It do what it should do -- real single-target logging, i.e. every log message no matther whether produced by OSGi Log Service or Eclipse Platform Logger is bridged to SLF4J.
-- Hezky den / Have a nice day Libor JELÍNEK
VIRTAGE SOFTWARE // software - design - web Lucni 542 // 285 04 Uhlirske Janovice // Czech Republic support: +420 315 555 488 // cell: +420 777 205 142 email/jabber: ljelinek@virtage.com // web: www.virtage.com
Visit our developer adventures at http://devblog.virtage.com!
On Tue, Oct 23, 2012 at 8:05 PM, Christian Trutz < christian.trutz@belaso.de> wrote:
Hi osgi-over-slf4j developers,
I've tested osgi-over-slf4j 1.7.2 with equinox 3.8 and cannot use the SLF4J LogService because Equinox register also a LogService with default ranking 0. SLF4J gets also ranking 0 (default ranking) because no service ranking is explicitly set. Is it OK for you if I introduce ranking = 10 for SLF4J LogService? If want to commit following change:
Properties props = new Properties(); props.put(Constants.SERVICE_DESCRIPTION, "An SLF4J LogService implementation."); props.put(Constants.SERVICE_RANKING, 10); ServiceFactory factory = new LogServiceFactory(); bundleContext.registerService(LogService.class.getName(), factory, props);
to org.slf4j.osgi.logservice.impl.Activator. I also think, that we should made log service ranking configurable ... (via system property for example). With the above change, I can also see OSGi log messages in Beagle ;-) Thats COOL ...
Christian
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
participants (3)
-
Christian Trutz -
Libor Jelinek -
Matthew Bishop