[
https://issues.apache.org/jira/browse/SLING-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794518#comment-13794518
]
Stefan Seifert commented on SLING-3170:
---------------------------------------
option A): job engine provides a resource path, job consumer writes results,
job engine cleans up in case of removal
- mixture of APIs: you mean the job api and the resource API? yes, this is
true. currently there is no direct dependency between these APIs.
- ACLs: solvable by some conventions or configurabel users, still makes it
difficult and un-elegant to set up
option B): enhances JobExecutionConext to add "something" like value maps
- not good to limit this to 2 levels (e.g. a list of keys with a list of flat
value lists), should support deeper nested structures as well
- mimicks a ValueList but is not a ValueList - i do not think we want to exend
the original ValueList by supporting nested deepter structures
what about option C): enhance JobConsumer interface
- the job engine or JobExecutionContext does not support any complex job result
structures
- the job consumer implementation can decide to store any custom result data
anyhwere in a repository with any ACL - the job engine does not care
- but a new method "cleanup(Job)" is added to the API which is called be the
job engine if the job should be removed finally - the job consumer
implementation can check for custom result data and delete it accordingly
- of course this is a very loose contract, and the job engine does not have any
real control over the data.
how can we handle the topology case with this three options - or esp. the last
option? how is it handled for the default job data, is it synchronized to all
nodes within a topology, or only to the master (what if the master changes)?
will be difficult to support with option C).
> Complex Job Result Structures
> -----------------------------
>
> Key: SLING-3170
> URL: https://issues.apache.org/jira/browse/SLING-3170
> 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:
> we need a possible to store complex result structures in our jobs, e.g. a
> subtree of nodes/resources with static and other process infos, definitely
> too much for a single string. ok, we could build an JSON structure and pass
> it over as log messages, but this would e really ugly hack. it would be
> possible to store this structure in the job logic and have an own management
> gui which can detect this additional result info by job id and display it.
> but when thinking about a cluster of nodes where the job runs only on one
> node it would be good to collect this job results centrally. i've not a
> perfect idea for an API extension for this, perhaps we should create a
> separate ticket for it.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
