|
Please make certain this gets into the documentation
thanks I've been testing this in our 2.5 deployment and am getting the impression so far that the sakai.properties setting doesn't do anything.
I'm finding that the reads only get logged if the property is set in the commandComponents.xml file. Owen, please note that this is fixed in trunk only (for 2.5 this must be set in commandComponents.xml). Is it failing for trunk, also? Thanks
Sorry, my mistake. We don't this fix yet.
Any chance this code be added to 2.5.x?
Could this be added to 2.5.x?
Is the current behaviour preserved by this change? i.e. will including it in 2-5-x affect OTB behaviour for people on the branch
From looking at the code this defaults to false, which is the current position in 2-5-x (i.e. we're not getting wiki.read events in our 2-5-x build), so it seems to retain the current behaviour.
Setting as 2.5.x Status as Won't Fix based on the "no new features" policy and Megan's comment.
Could you provide a 2.5.x patch for Owen, Nuno? I applied the patch generated from this issue commit to our production server replica (2.5.x) with "wiki.trackreads=true" in sakai.properties but, when I access a wiki page, "wiki.read" is not logged to SAKAI_EVENT and:
- for existing wiki pages, an email is automatically sent as in the case a page has been modified; - on new (non-existing) pages, the stacktrace below is sent to catalina.out. WARN: postEvent, notifyObservers(), event: 0:wiki.read@/wiki/site/test-site-28-12-2005/outra pagina.[m, 3] (2008-12-03 14:49:21,772 http-8080-Processor23_org.sakaiproject.event.impl.ClusterEventTracking) java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:372) at java.lang.Long.parseLong(Long.java:461) at uk.ac.cam.caret.sakai.rwiki.component.service.impl.SiteEmailNotificationRWiki.getMessageContent(SiteEmailNotificationRWiki.java:243) at uk.ac.cam.caret.sakai.rwiki.component.service.impl.SiteEmailNotificationRWiki.getPlainMessage(SiteEmailNotificationRWiki.java:179) at uk.ac.cam.caret.sakai.rwiki.component.service.impl.SiteEmailNotificationRWiki.plainTextContent(SiteEmailNotificationRWiki.java:263) at org.sakaiproject.util.EmailNotification.notify(EmailNotification.java:198) at org.sakaiproject.event.impl.BaseNotificationService$BaseNotification.notify(BaseNotificationService.java:1094) at org.sakaiproject.event.impl.BaseNotificationService.update(BaseNotificationService.java:607) at java.util.Observable.notifyObservers(Observable.java:142) at org.sakaiproject.event.impl.BaseEventTrackingService.notifyObservers(BaseEventTrackingService.java:119) at org.sakaiproject.event.impl.ClusterEventTracking.postEvent(ClusterEventTracking.java:255) at org.sakaiproject.event.impl.BaseEventTrackingService.post(BaseEventTrackingService.java:239) at uk.ac.cam.caret.sakai.rwiki.tool.service.impl.CommandServiceImpl$DefaultCommand.execute(CommandServiceImpl.java:114) at uk.ac.cam.caret.sakai.rwiki.tool.RWikiServlet.execute(RWikiServlet.java:186) at uk.ac.cam.caret.sakai.rwiki.tool.RWikiServlet.doGet(RWikiServlet.java:117) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:555) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:364) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.sakaiproject.tool.impl.ActiveToolComponent$MyActiveTool.forward(ActiveToolComponent.java:459) at org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1344) at org.sakaiproject.portal.charon.handlers.ToolHandler.doTool(ToolHandler.java:163) at org.sakaiproject.portal.charon.handlers.ToolHandler.doGet(ToolHandler.java:86) at org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:892) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:592) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) Sorry, Nuno. I thought you might already have tried it.
Does anybody else have an idea? Has anybody tried wiki.trackreads=true with 2.6? wow....
Same issue, with one difference: "wiki.read" is actually logged to SAKAI_EVENT in all cases. So, if the page exists, accessing it in wiki causes a notification email to be sent; if the page is new (does not exist), the stacktrace above is presented. Should this issue be re-opened or a new one created?!?! If your last comment is the result of 2.6 testing, reopening is a good idea.
This is the result of trunk (updated) testing - I assume this is the case of 2.6.x as well. I currently don't have a 2.6.x checked out - I will check it out and test this against 2.6.x.
New JIRA created for the above issues:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Allow enable/disable of wiki reads events through sakai.properties
wiki.trackreads=true
for sakai.properties