[
https://issues.apache.org/jira/browse/SLING-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794523#comment-13794523
]
Stefan Seifert commented on SLING-3167:
---------------------------------------
perhaps this is somewhat related to SLING-3170.
the problem arises if the job produces massive log entries. perhaps this should
be stored then in a custom format (e.g. with log levels etc.) in a custom
result structure like as discussed in SLING-3170.
still the ProcessLog array in the job API could be misused with massive log
entries. this could be encountered with some JavaDoc hints on the related
methods.
using a resource update event is not perfect - first of all the job engine is
independently of the resource API, and the job API client code does not have
the knowledge where the job data is stored and to which event he has to listen
to.
it somewhat depends on what should be done with all this log messages. if it
should be used for complex admin GUIs with good support for detailed looking
into the current work steps of running jobs making this more performant and
flexible with listeners would be a good option. leaving it it to the job
consumer implementations with custom job structures solves the problem without
complex extensions to the API, but leaves the display of the log messages to
custom job management GUIs, no support for a central GUI with this feature.
> Job Logging
> -----------
>
> Key: SLING-3167
> URL: https://issues.apache.org/jira/browse/SLING-3167
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: Extensions Event 3.3.0
>
>
> This is a follow up from SLING-3028 based on comments by Stefan Seifert:
> Job.getProcessLog() - is it a good solution to use a String[] type for this?
> as i see this is currently through all the implementation that every writing
> of a log message reads gets the existing string array, copies it to a new
> array and adds the new log message. the reason is that its easy then to store
> it in a JCR compatible value map. i'm just thinking if its a good idea if a
> job produces thousands of log messages. perhaps its acceptable overall. if
> you think about and admin GUI which refreshes every second to show the log
> messages of a job currently running... perhaps it would be nice to have a
> listener interface for such log messages as well.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
