[
https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795564#comment-13795564
]
Stefan Seifert commented on SLING-3169:
---------------------------------------
took some time to think through the new API twist...
* javadocs in JobExecutionResult is wrong, the constants SUCCEEDED, FAILED are
not accessible because in a class in an impl package
* JobExecutionContext: the "constant methods" are strange with the non-standard
naming all-uppercase. i would preface standard headless camel case for them.
* JobExecutionContext: the fluent syntax is not so fluent here for the new
methods. the result message is optional, but the method has be called to reach
the retryDelay method. and the retryDely method can even be called for
successful jobs. i woud prefer methods like this:
{code}
ResultBuilder succeeded();
ResultBuilder failed();
ResultBuilder failedRetry(final long retryDelayInMs);
ResultBuilder cancelled();
public interface ResultBuilder {
ResultBuilder result(final String message);
}
{code}
or just even simpler but less flexible for future extensions:
{code}
void succeeded();
void succeeded(final String message);
void failed();
void failed(final String message);
void failedRetry(final long retryDelayInMs);
void failedRetry(final String message, final long retryDelayInMs);
void cancelled();
void cancelled(final String message);
{code}
* CANCELLED vs. FAILED state: why keeping the distinction in the job result,
but not in the job state? either we should keep this in the jobstate as well,
or do not distinguish it in the job result?
> Naming of Job related enumerations
> ----------------------------------
>
> Key: SLING-3169
> URL: https://issues.apache.org/jira/browse/SLING-3169
> 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:
> I find the enum name Job.JobType not ideal, because it does not stand of
> a type but for a state of the job. But there is a JobState enum in the
> consumer API package already.
> I find the enum and class names JobState and JobStatus in the consumer
> package not ideal, because they do not stand for a state, but for a job
> result.
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
