[
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.
