[
https://issues.apache.org/jira/browse/SLING-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795499#comment-13795499
]
Carsten Ziegeler commented on SLING-3170:
-----------------------------------------
For option B), you could do a fake tree, by using paths in the keys, like
putting a value map for "a", "a.b", "a.c" - but that's neither nice nor really
usable. So I tend to drop B) as well
Option C sounds good to me as this would require the least changes :) Removing
a job with the default data is simply as this is just a single resource in the
resource tree . as the repository is shared across the cluster, removing it on
one node removes the whole thing in the cluster. So it's not important whether
the remove() method has been called on the master or on any other node.
I see some problems with proposal C, what happens if the JobExecutor is not
available when the job is removed?
What if we relax option C) and don't add the cleanup method, and leave it up to
OSGi events - we could send out a JOB_REMOVED event via the event admin and
whoever is interested does it. This comes with the same problems as C) (what
happens if the event handler is not available etc.), but it's not worse and
requires nearly zero changes to the job handling.
The out of sync can be handled by implementing a clean up task which checks for
the additional data if the corresponding job is still there. Not that nice,
but would do the trick
So the only reliable way of removing the additional job data together with the
job is to let the engine remove it - in a single transaction (save call). But
this comes with the above mentioned problems of Option A) (ACLs and mixture of
APIs). One way to solve that would be to add an create api to the job context
which allows you to create a tree of data through some job specific api - and
then add the counterpart to the job interface to get the data. But this doesn't
sound right either.
This would leave us with option C) - and I would prefer the event instead of
api additions.
> 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)
