Hi, nope it's not handled, log "events" are always send to the event admin service [1]
regards, Achim [1] - https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/ops4j/pax/logging/service/internal/PaxLoggingServiceImpl.java#L184-L194 2017-04-26 11:41 GMT+02:00 Roberto Pierpaoli <robe...@iooota.com>: > Hi Achim, > unfortunately we use the EventAdmin service a lot for the events dealing > with our logic, otherwise it would certainly be already switched off :-) > > If the propagation can be already stopped on the PaxLogging side today, it > would be great to know it, if it is not then we don't exclude to patch it > by ourselves, we would just have to take a look at the code, since we never > put our hands inside it: we just don't want to make a mess ':) > > Thanks again. > > Il giorno mercoledì 26 aprile 2017 11:32:59 UTC+2, Achim Nierbeck ha > scritto: >> >> Hi, >> >> ok so now I've got a clearer view ;) >> Do you need the event-admin in your context? >> Maybe just turn that one off ... :) >> >> But either way, just open an issue for this and we'll see what is >> possible. Or maybe you want to come up with a proper solution, in that case >> we highly appreciate pull-requests :-D >> >> regards, achim >> >> >> >> 2017-04-26 11:23 GMT+02:00 Roberto Pierpaoli <rob...@iooota.com>: >> >>> 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>: >>>> >>>>> 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/apach >>>>>>>>> e-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 >>>>> >>>>> --- >>>>> 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 >>> >>> --- >>> 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 - 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. > -- 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.
