And this listener can also log the events using log4j (or slf4j or any other tool) if we really want it...
-Vincent On Mar 18, 2011, at 9:46 AM, Vincent Massol 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.... > > -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. >> 2) Have a way to tell the AS what storage to use for specific Event Types. >> For example the AS could use an in-memory storage for Log Events while using >> a DB storage for other events. This would be useful since I don't think we >> really need to store logs in the DB. Note that the cache could be indexed on >> the message so only one instance of each log message is preserved (no need >> for dups), possibly with a counter to mention how many of them there were >> (that's an optimization). >> >> I believe 2) might be enough for performances in a first implementation of >> the log console. >> >> WDYT? >> >> Thanks >> -Vincent >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
