[
https://issues.apache.org/jira/browse/SLING-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793633#comment-13793633
]
Carsten Ziegeler commented on SLING-3170:
-----------------------------------------
I see the use cases for this, and I agree storing json or any other data
structure in a log string entry should not be solution :)
Now, the easiest would be to allow to set resource paths on the job which
contain additional information, the job consumer writes whatever it wants to
the specified paths. The information can be stored in any part of the resource
tree and as the job has a unique job id, the consumer can use it for separating
the information.
A client can ask the job for these additional resource paths and look them up.
When a job is deleted forever (from the history), these paths are deleted as
well by the job engine.
One problem I see are access right, the job engine would need to have the
permission to delete the resources created by the job consumer - the same goes
for clients reading this stuff. Another problem is we have a mixture of APIs
Another option would be to add some api to the JobExecutionContext which allows
to add "something" where "something" could be a value map or a named value map,
like
context.store("infoA", map1);
context.store("infoB", map2);
and the job gets:
String[] getAdditionalXYZNames(); // returning "infoA", "infoB" for the above
case
ValueMap getAdditionalXYZ(String name);
The value map would be written and read by the job engine using the resource api
[[email protected]] Maybe we can continue brain dumping some more ideas?
:)
> 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)
