[jira] Updated: (OFBIZ-2042) Individual logfiles for scheduled jobs

["Philipp Hoppen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philipp Hoppen updated OFBIZ-2042:
----------------------------------

    Attachment: joblog.diff

Here is an updated version of this patch. Beside updating it for the latest trunk version, I tried to fix some of the issues mentioned by Adam Heath and Jaques. It now uses InheritableThreadLocal insted of a Map to temporarly store the Log4J-Appenders. It was suggested to not use java.io.File but I had no idea how else to delete the logfiles (FlexibleLocation doesn't seem to be suited for that). What's so wrong about using java.io.File for this anyway?  Further changes include some method inlining in org.ofbiz.base.util.Debug to make it a bit clearer, and I appended the jobId parameter on  the "Refresh" button on /webtools/control/LogView if available.

What doesn't work is to completly include the log output form services that were asynchronously called by the job service because as soon as the calling service returns, GenericServiceJob removes the Appender.


> Individual logfiles for scheduled jobs
> --------------------------------------
>
>                 Key: OFBIZ-2042
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2042
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Philipp Hoppen
>            Assignee: Jacques Le Roux
>            Priority: Minor
>             Fix For: SVN trunk
>
>         Attachments: joblog.diff, joblogging.diff
>
>
> It is useful to have the ability to see the logs of a single scheduled job on the job list. 
> In implementation (see attached patch) the user can specify whether he wants an individual logfile or not using a checkbox when he schedules the job. The information is passed from scheduleService() in CoreEvents.java to the Dispatcher class and finally to the JobManager, where it is stored in the ownLogfile field of the JobSandbox entity. 
> When the job runs, JobInvoker initializes the job-thread with an own ThreadGroup. PersistentServiceJob then checks for the ownLogfile field of the job and eventually initializes the logLocation (using serviceName+ timestamp value) , which is stored in another field on JobSandbox. PersistentServiceJob passes the logLocation using setLogLocation() on GenericServiceJob, which in turn calls registerCurrentThreadGroupLogger on the Debug class. Debug maintains a list of these loggers for each running job and sends them the log entries when log() is called. After the job finished the logger is unregistered.
> On the Job List there the ownLogfile field is displayed (useful to find out if pending jobs will generate own logfile) and eventually a link to "View Log" (which receives a jobId parameter that is checked for in LogView.groovy). 
> in purgeOldJobs() there are some lines to check for ownLogfile and to delete the physical logfile.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.