Re: [xwiki-devs] [Idea] Implementing a Log console inside XE

On Fri, Mar 18, 2011 at 10:10, Vincent Massol <vincent(a)massol.net> wrote: > > On Mar 18, 2011, at 10:01 AM, Thomas Mortagne wrote: > >> On Fri, Mar 18, 2011 at 09:46, Vincent Massol <vincent(a)massol.net> wrote: >>> I'm stupid, there's no need to relate it to the AS. The AS can simply ignore those events and we can have a separate listener to receive them.... >> >> Yes can be a special tool for that. >> >>> >>> -Vincent >>> >>> On Mar 18, 2011, at 9:39 AM, Vincent Massol wrote: >>> >>>> Hi, >>>> >>>> Right now logs go to a file on the filesystem. However this is not right since most logs are application logs and should be visible to wiki developers. For ex, if I use a deprecated API, I need to see it. It shouldn't go to admins only and shouldn't "pollute" the system logs. >>>> >>>> Hence I believe we need a Log Console available somewhere (we could make it avail in the Admin UI FTM). >>>> >>>> I'd like to discuss an implementation idea I've had this morning: >>>> >>>> * Send application logs as Observation Events and make the available in the Activity Stream (AS) >>>> >>>> Pros: >>>> * Infrastructure already in place >>>> * Fits the AS goal: temporary information and is purged regularly >>>> * (Of course the Activity gadget would not display them) >>>> * They can be sent remotely as remote events in the future; this allows implementing a remote console to monitor an XE or XEM from a distance >>>> >>>> Cons: >>>> * We need to assess the performance risk and more generally we need to make the AS scalable (I don't think it is now). >>>> * 2 ideas for scaling up the Observation/AS: >>>> 1) Have the Observation Manager save events to be notified into a Queue and have one or several separate threads take those events and send them to listeners. Right now if one listener takes time in its onEvent() method it slows down the whole chain since they are called serially. Note that if we want even better scalability, the Queue could be stored externally to XWiki (a JMS queue for ex) and scalability can be achieved by app server instances listening to this queue to process it. >> >> IMO if a listener takes time in its onEvent() it can always do that >> message queue itself, that's what Lucene plugin do for example. > > Yes i know but it's nice from an architecture POV to do it at this level rather than *hope* that all listeners (including those not coded by us) will be good citizens.

If we want all the log to produce events that's the way to go IMO. 1) it's a lot easier to use a logging API to log 2) you can be sure you will have very few log events if you don't do it that way, people will always forget to send log events since that's really not natural. I don't think it's really turn the logic upside down, it make the Logger API an helper that's all. If you have to create event called "LogEvent" and not something unrelated directly to logging that is transformed as log by a listener it's exactly the same logic. -- Thomas Mortagne