Hi Achim, I can't say if the specification describes *how* log events should be propagated or *if* the propagation itself is mandatory, probably we should ask to the OSGi alliance :)
We run our software over an embedded platform, with limited computational power, that's why we try to avoid anything that is not strictly needed, thus the will to turn off log events propagation at its root, rather than on the event-admin side. Anyway, if the latter is the only possible approach, we'll do what's allowed, clearly :) Thanks for your contribution! Il giorno mercoledì 26 aprile 2017 11:14:44 UTC+2, Achim Nierbeck ha scritto: > > Hi, > > according to the spec: > > 101.6.4 Log Events > > Log events must be delivered by the Log Service implementation to the > Event Admin service (if present) asynchronously under the topic: > org/osgi/service/log/LogEntry/<event type> > > For me this sounds a mandatory, one just doesn't need to consume from that > topic? > > But maybe I'm not aware of the real problem you seem to have with all logs > being send as events :) > > regards, Achim > > > > 2017-04-26 11:00 GMT+02:00 Roberto Pierpaoli <rob...@iooota.com > <javascript:>>: > >> Hi Achim, thank you for the super-quick feedback. >> >> I'm sorry, I didn't know that it is mandatory to propagate log events to >> the event-admin service... I thought it could reasonably be a configuration >> option, since not everybody needs that for the business logic, but I guess >> it is needed by the underlying runtime implementation (Apache Karaf, in my >> case). >> >> Do you think that filtering at the event-admin level will be equally >> efficient, in terms of not congestioning the threadpools? >> >> Kind regards, >> >> Roberto >> >> Il giorno mercoledì 26 aprile 2017 10:47:02 UTC+2, Achim Nierbeck ha >> scritto: >>> >>> hmm ... I'm sure it's doable, though wasn't this mandatory from the OSGi >>> spec ?? >>> LOG events should always be send, if there is a event-admin available >>> ... why not filter on the eventadmin, you don't need to consume those? >>> So what is the use-case? >>> >>> regards, Achim >>> >>> 2017-04-26 10:42 GMT+02:00 Roberto Pierpaoli <rob...@iooota.com>: >>> >>>> Hi, I'm looking for the same solution: we would like to prevent >>>> PaxLogging from publishing anything to the OSGi Event Admin, is that >>>> actually possibile? >>>> >>>> Thanks in advance. >>>> >>>> >>>> Il giorno martedì 22 marzo 2016 15:52:35 UTC+1, Guillaume Nodet ha >>>> scritto: >>>>> >>>>> Adding a configuration option to disable that should be easy to do. >>>>> Would you mind writing a pull request for that ? >>>>> >>>>> Though, at the end, I'm not sure there will be much difference in >>>>> upgrading pax-logging or eventadmin, and given it's already supported in >>>>> eventadmin, why not simply upgrading to a recent version of it ? >>>>> >>>>> On Tue, Mar 22, 2016 at 3:02 PM, <ra...@evosent.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Is it possible to disable the publishing of LogEntry events to the >>>>>> org/osgi/service/log/LogEntry/* topic in the OSGi Event Admin? >>>>>> >>>>>> I am seeing nasty contention in a log-heavy application due to >>>>>> congestion in the EventAdmin threadpools. Increasing the size of the >>>>>> threadpools [1] is just a workaround, and ignoring the events via >>>>>> EventAdmin config is not an option because we're running on Felix >>>>>> EventAdmin 1.3.2. >>>>>> >>>>>> Moreover, there are no handlers subscribed to these topics OOTB, so >>>>>> it's not like we'd lose functionality by disabling the generation of the >>>>>> event in the first place. Is it possible to do so? >>>>>> >>>>>> qtp1225771956-3286 <--- Frozen for at least 23 sec >>>>>> >>>>>> EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute(Runnable) >>>>>> >>>>>> *org.apache.felix.eventadmin.im >>>>>> <http://org.apache.felix.eventadmin.im>pl.tasks.DefaultThreadPool.executeTask(Runnable) >>>>>> >>>>>> DefaultThreadPool.java:101* >>>>>> >>>>>> org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks.execute(Collection, >>>>>> >>>>>> Event) AsyncDeliverTasks.java:105 >>>>>> >>>>>> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.postEvent(Event) >>>>>> EventAdminImpl.java:100 >>>>>> >>>>>> org.apache.felix.eventadmin.impl.adapter.LogEventAdapter$1.logged(LogEntry) >>>>>> >>>>>> LogEventAdapter.java:281 >>>>>> >>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl.fire(LogListener, >>>>>> >>>>>> LogEntry) LogReaderServiceImpl.java:92 >>>>>> >>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl.access$300(LogReaderServiceImpl, >>>>>> >>>>>> LogListener, LogEntry) LogReaderServiceImpl.java:46 >>>>>> >>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl$1.fireEvent(LogEntry) >>>>>> >>>>>> LogReaderServiceImpl.java:114 >>>>>> >>>>>> org.ops4j.pax.logging.logback.internal.PaxLoggingServiceImpl$1.handleEvents(Bundle, >>>>>> >>>>>> ServiceReference, int, String, Throwable) PaxLoggingServiceImpl.java:138 >>>>>> >>>>>> org.ops4j.pax.logging.logback.internal.PaxLoggerImpl.inform(String, >>>>>> Throwable, String) PaxLoggerImpl.java:198 >>>>>> >>>>>> org.ops4j.pax.logging.internal.TrackingLogger.inform(String, >>>>>> Throwable, String) TrackingLogger.java:116 >>>>>> >>>>>> org.ops4j.pax.logging.slf4j.Slf4jLogger.log(Marker, String, int, >>>>>> String, Object[], Throwable) Slf4jLogger.java:1098 >>>>>> >>>>>> org.apache.cxf.common.logging.Slf4jLogger.internalLogFormatted(String, >>>>>> LogRecord) Slf4jLogger.java:139 >>>>>> >>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.internalLog(LogRecord) >>>>>> >>>>>> AbstractDelegatingLogger.java:353 >>>>>> >>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.doLog(LogRecord) >>>>>> AbstractDelegatingLogger.java:335 >>>>>> >>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.log(LogRecord) >>>>>> AbstractDelegatingLogger.java:46 >>>>>> >>>>>> org.apache.cxf.interceptor.AbstractLoggingInterceptor.log(Logger, >>>>>> String) AbstractLoggingInterceptor.java:239 >>>>>> >>>>>> org.apache.cxf.interceptor.LoggingInInterceptor.logging(Logger, >>>>>> Message) LoggingInInterceptor.java:157 >>>>>> >>>>>> org.apache.cxf.interceptor.LoggingInInterceptor.handleMessage(Message) >>>>>> LoggingInInterceptor.java:79 >>>>>> >>>>>> ... >>>>>> >>>>>> [1] >>>>>> https://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html >>>>>> >>>>>> Cheers, >>>>>> Raúl. >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OPS4J" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to ops4j+un...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OPS4J" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ops4j+un...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> >>> Apache Member >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >>> & Project Lead >>> blog <http://notizblog.nierbeck.de/> >>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>> >>> Software Architect / Project Manager / Scrum Master >>> >>> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - op...@googlegroups.com <javascript:> >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ops4j+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > > -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
