date:20131014


[ 
https://issues.apache.org/jira/browse/SLING-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794554#comment-13794554
 ] 

Stefan Seifert commented on SLING-3173:
---

we should not bother on this for the first/upcoming release of the new job API, 
but in the medium term it would be good to have more flexibility here - either 
by adding more out of the box queues or allowing to extend them.

our example of a "time window queue" is not easily done using the scheduling 
features because this would put the burden of the time queue to the job 
consumer implementations. the jobs and the cliend code that posts the jobs 
should not need to now about this special queue type, it should be added only 
by configuration like the other queue types.

> Job Engine: Support custome queue implementations
> -
>
> Key: SLING-3173
> URL: https://issues.apache.org/jira/browse/SLING-3173
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>
> follow-up from SLING-3028
> Q: is it possible to add own queue implementations? does not seem so, its 
> using a hardcoded enum. in our own job implementation we have e.g. a "time 
> window queue" think, which queues up jobs and executes them only in defined 
> time windows where low user traffic is expected on the instance.
> A: Own queue implementations: these are not possible at all. For your use 
> case of a time window queue, you maybe could use the scheduled jobs? If you 
> think it's worth exploring this, please create a separate issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3172) Job schedule name handling


[ 
https://issues.apache.org/jira/browse/SLING-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794548#comment-13794548
 ] 

Stefan Seifert commented on SLING-3172:
---

as with the (now deprecated) job name i find it very cumbersome for the client 
code to have to deal with unique names when posting jobs. in most scenarios 
this will be "fire and forget" code and only in few usecase code has the need 
to later reference the schedule and update it.
another topic is a possible management GUI: but in this case the scenario is 
different. the mangement GUI is (normally) not the one which posts the jobs, 
but which visualizes and manages it. thus the GUI needs to access to all 
exsiting jobs, and than should have the possibility to change the schedule if 
required. this should already be possible using the getScheduledJobs method.

for the first usecase with client code wanting to reschedule: if the 
JobManager.getScheduledJob is transformed to something like 
getScheduledJobById() it is possible to re-access a ScheduledJobInfo by 
the jobid which was generated when starting the job, eliminating the schedule 
name altogether.

> Job schedule name handling
> --
>
> Key: SLING-3172
> URL: https://issues.apache.org/jira/browse/SLING-3172
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
> Fix For: Extensions Event 3.3.0
>
>
> follow-up from SLING-3028
> Q: JobBuilder.schedule - for what is the parameter "name" used? i does not 
> get its meaning from the javadocs. why is it required to make it unique?
> A: Schedule Name: each schedule gets a unique name to identify it and have a 
> way to update the schedule or unschedule it. The other option I see would be 
> to create a unique scheduling id when a new schedule is created and then use 
> this to reference it. But in that case the client needs to store this id 
> somewhere. If you think that this needs further enhancements or changes, 
> please open a separate ticket.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3173) Job Engine: Support custome queue implementations

Stefan Seifert created SLING-3173:
-

 Summary: Job Engine: Support custome queue implementations
 Key: SLING-3173
 URL: https://issues.apache.org/jira/browse/SLING-3173
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Stefan Seifert
Priority: Minor


follow-up from SLING-3028

Q: is it possible to add own queue implementations? does not seem so, its using 
a hardcoded enum. in our own job implementation we have e.g. a "time window 
queue" think, which queues up jobs and executes them only in defined time 
windows where low user traffic is expected on the instance.

A: Own queue implementations: these are not possible at all. For your use case 
of a time window queue, you maybe could use the scheduled jobs? If you think 
it's worth exploring this, please create a separate issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3028) Support for progress tracking of jobs and keeping jobs


[ 
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794543#comment-13794543
 ] 

Stefan Seifert commented on SLING-3028:
---

i commented on the seperate ticktes. for the other points:
* 7a-7c: you are right, these transition states would be a different state view 
from the point of the consumer pov, not from the engine pov. so we do not need 
to consider it in the JobState enum as discussed in SLING-3169. if we required 
it we could add it later on, but lets start with the current API and make it 
not too complicated for now.
* 8: you already created SLING-3171
* 9: i've created SLING-3172 for it
* 10: i've created SLING-3173 for it

done for this ticket

> Support for progress tracking of jobs and keeping jobs
> --
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>Assignee: Carsten Ziegeler
>  Labels: jobs
> Fix For: Extensions Event 3.3.0
>
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3172) Job schedule name handling

Stefan Seifert created SLING-3172:
-

 Summary: Job schedule name handling
 Key: SLING-3172
 URL: https://issues.apache.org/jira/browse/SLING-3172
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Priority: Minor
 Fix For: Extensions Event 3.3.0


follow-up from SLING-3028

Q: JobBuilder.schedule - for what is the parameter "name" used? i does not get 
its meaning from the javadocs. why is it required to make it unique?

A: Schedule Name: each schedule gets a unique name to identify it and have a 
way to update the schedule or unschedule it. The other option I see would be to 
create a unique scheduling id when a new schedule is created and then use this 
to reference it. But in that case the client needs to store this id somewhere. 
If you think that this needs further enhancements or changes, please open a 
separate ticket.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3169) Naming of Job related enumerations


[ 
https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794536#comment-13794536
 ] 

Stefan Seifert commented on SLING-3169:
---

ok, lets have a look on the current implementation:
{code}
enum JobType {
  QUEUED,
  ACTIVE,
  SUCCEEDED,
  CANCELLED
};
public enum JobState {
  SUCCEEDED,  // processing finished successfully
  FAILED, // processing failed, can be retried
  CANCELLED   // processing failed permanently
}
{code}

a new, merged enum could look like this:
{code}
enum JobState {
  QUEUED, // waiting in queue after adding or for restart after failing
  ACTIVE, // job is currently processed
  SUCCEEDED,  // processing finished successfully
  CANCELLED,  // processing was canceled during processing
  FAILED  // processing failed even after the number of configured retries
};
{code}

please note that i slightly redefined some of the states, this can be 
questioned of course. first of all i think the merging is a good option, it 
removes the partially redundancy betweend the two enums and solves the naming 
clash problem in an elegant way. i thought it was usful for a reporting 
perpective of history jobs to have a distinction whether a job was failed due 
to errors, or because it was interrupted by human or other intraction via the 
stopJobById method.

but the merging has one problem: the enum is used as part of the JobStatus 
class to allow the job reporting back its status from the JobConsumer point of 
view. then it would be possible for the consumer to report the status "QUEUED" 
or "ACTIVE" - which should not be allowed. this could be handled by ignoring it 
and logging an error, but still is not elegant. perhaps reducing the JobStatus 
succeeded feedback to a boolean true/false? the job engine knows if it forced a 
stopping/canceling of the job or not. (but to be precise it does not know if 
the stop event was ignored by the job consumer and the job perhaps succeeded 
anyway)

> 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)

[jira] [Commented] (SLING-3171) Deprecate job name handling


[ 
https://issues.apache.org/jira/browse/SLING-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794528#comment-13794528
 ] 

Stefan Seifert commented on SLING-3171:
---

+1 for removing/deprecating the current unique job name handling which makes it 
cumbersome for client code to care about the uniqueness

still, thinking about management GUIs it would be useful to have an optional 
non-unique job name or description attribute which is chosen by the job start 
process and can be displayed to a user/admin in a management GUI additionally 
to the topic.

> Deprecate job name handling
> ---
>
> Key: SLING-3171
> URL: https://issues.apache.org/jira/browse/SLING-3171
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Extensions Event 3.2.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Extensions Event 3.3.0
>
>
> The job name feature is disturbing, complicated to implement and usually not 
> needed: it is used to handle the case where the same job is created more than 
> once. This can usually easily be handled by the client code creating the job, 
> especially with the new topology stuff.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3167) Job Logging


[ 
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)

[jira] [Commented] (SLING-3170) Complex Job Result Structures


[ 
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)

[jira] [Commented] (SLING-3168) Deprecating JobUtil class?


[ 
https://issues.apache.org/jira/browse/SLING-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794494#comment-13794494
 ] 

Stefan Seifert commented on SLING-3168:
---

ok, good

why was job priority completely disabled? replaced by the new threadpriority in 
QueueConfiguration?
although i've not fully though through the concept of job priorities it looked 
useful for me first, if a new job is added to the queues which should run 
faster than other jobs - perhaps from the same topic and even running in the 
same queue. or was this never implements this way with the old JobPriority enum?

> Deprecating JobUtil class?
> --
>
> Key: SLING-3168
> URL: https://issues.apache.org/jira/browse/SLING-3168
> 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:
> the JobUtil class is deprecated by 90%. perhaps its better to deprecated it 
> completely and move the remaining 10% to a new location or other classes more 
> suitable. This would solve the inconsistency with the JobUtil.JobPriority 
> enum as well, which is not part of the Job interface, whereas JobType is part 
> of the Job interface.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3166) Job Scheduling Possibilities


[ 
https://issues.apache.org/jira/browse/SLING-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794447#comment-13794447
 ] 

Stefan Seifert commented on SLING-3166:
---

thanks, looks perfect and the api is much cleaner now

> Job Scheduling Possibilities
> 
>
> Key: SLING-3166
> URL: https://issues.apache.org/jira/browse/SLING-3166
> Project: Sling
>  Issue Type: New Feature
>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:
> JobBuilder.ScheduleBuilder: why only for hourly, dayly, weekly? whats about 
> monthly, yearly? esp. because we have a good support for persisting jobs and 
> picking them up later on this job processing is suited for seldom running 
> jobs as well. like cron.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3169) Naming of Job related enumerations


[ 
https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794375#comment-13794375
 ] 

Carsten Ziegeler commented on SLING-3169:
-

Or maybe we don't need the FAILED state at all - QUEUED/ACTIVE in combination 
with getRetryCount() gives the same information

> 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)

Jenkins build is back to normal : sling-trunk-1.7 #338

See

Build failed in Jenkins: sling-trunk-1.7 #337

See 

Changes:

[cziegeler] SLING-3168 : Deprecating JobUtil class?

--
[...truncated 14839 lines...]
14.10.2013 15:13:22.513 *INFO* [main] org.apache.sling.event Service 
[org.apache.sling.event.impl.jobs.deprecated.JobStatusProviderImpl,94] 
ServiceEvent REGISTERED
14.10.2013 15:13:27.515 *WARN* [Apche Sling JCR Resource Event Queue Processor 
for path '/'] org.apache.felix.eventadmin EventAdmin: Blacklisting 
ServiceReference [[org.apache.sling.event.jobs.JobManager, 
org.osgi.service.event.EventHandler, 
org.apache.sling.discovery.TopologyEventListener, java.lang.Runnable] | 
Bundle(org.apache.sling.event [66])] due to timeout!
Build timed out (after 150 minutes). Marking the build as failed.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Reactor Summary:
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JAR Resource Bundle .. SUCCESS [18.833s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling (Parent) . SUCCESS [19.300s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Adapter Annotations . SUCCESS [20.286s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin to create Jackrabbit OCM descriptors  SUCCESS 
[22.680s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Compiling JSP Sources into Bundles  SUCCESS 
[23.351s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Supporting Bundle Development  SUCCESS 
[26.637s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Launchpad Maven Plugin ... SUCCESS [39.630s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Standalone Archetype .. SUCCESS [14.387s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Webapp Archetype .. SUCCESS [12.199s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Initial Content Archetype ... SUCCESS [18.304s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Servlet Archetype ... SUCCESS [17.548s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Bundle Archetype  SUCCESS [14.852s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling JCRInstall Bundle Archetype . SUCCESS [14.116s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Taglib Archetype  SUCCESS [23.389s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling API .. SUCCESS [31.645s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Service User Mapper .. SUCCESS [19.709s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Resource Resolver  SUCCESS [14.425s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[20.190s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: XML APIs  SUCCESS [21.484s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Activation API  SUCCESS [13.059s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: WS APIs . SUCCESS [26.063s]
Oct 14, 2013 5:20:14 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Dynamic Class Loader Support . SUCCESS [19.945s]
Oct 14, 2013 5:20:14 PM org

[jira] [Comment Edited] (SLING-3028) Support for progress tracking of jobs and keeping jobs

[
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793608#comment-13793608
]

Carsten Ziegeler edited comment on SLING-3028 at 10/14/13 4:43 PM:
---

Many thanks for your comments [~sseif...@pro-vision.de] - it's more than
appreciated. For the most issues, I've created a separate one for further
discussion, except those which I'm atm unsure if we should address them now.
Feel free to open additional issues :)
1. Scheduling options : I've created SLING-3166 to further discuss this
2. DAYLY vs DAILY: Yes, I noticed this as well and corrected it some days ago
3. Logging: I've created SLING-3167 for this
4. JobUtil class is deprecated: I've created SLING-3168 for this
5. and 6. Names of enumeration: SLING-3169
7a "how type/state is set if the job sets a state/result FAILED? SUCCEEDED or
CANCELLED? both is not correct". - FAILED means it's retried again so it is
either QUEUED or ACTIVE - unless the max retries is reached, then it goes into
CANCELLED.
7b. "btw. CANCELLED is british englisch, CANCELED is american english" -
thanks, I'll leave it like this as we already have released api using this
variant.
7c. "in our own job implementation with have states for "transitions" as well
like "CANCELING". this is useful because sometimes a job that is canceled
cannot cancel at once, but takes some seconds or minutes to wait for the best
time when the job can be canceled. if this job is displayed in a management GUI
it would be helpful to show this transition state as well. to make it complete
a transition state "STARTING" should be added as well. more enhance features
like PAUSING/PAUSED/RESTARTING could be added in the feature - too much for now"
The current job model does not have the support for such transition states as
the states are regarded from the engine pov: this simply starts the job
processing (calling the consumer) and gets a result. I assume that the
transition states are handled/set by the consumer? If you think we should
support this directly via the API please make an additional issue.
8. Job Name: Yes, this is an old relict we probably should rather drop it for
the new API - the job name is a user given unique id - while the job id is the
internal unique job id. The job name is only relevant if there is the chance
that addJob is called more than once for creating the same job. For example in
a clustered installation if you have an observation listener creating jobs
based on repository changes, you need to make sure that this is only done once
cluster wide. Either you code this into your observation listeners or you let
everyone use the same job name when creating the job (well the same name for
the same job) - in this case the job eventing takes care of it and such a job
is created only once. I'll think about it once more and probably drop it (set
it to deprecated)
9. Schedule Name: each schedule gets a unique name to identify it and have a
way to update the schedule or unschedule it. The other option I see would be to
create a unique scheduling id when a new schedule is created and then use this
to reference it. But in that case the client needs to store this id somewhere.
If you think that this needs further enhancements or changes, please open a
separate ticket.
10. Own queue implementations: these are not possible at all. For your use case
of a time window queue, you maybe could use the scheduled jobs? If you think
it's worth exploring this, please create a separate issue.
11. Complex result structures: SLING-3170

was (Author: cziegeler):
Many thanks for your comments [~sseif...@pro-vision.de] - it's more than
appreciated. For the most issues, I've created a separate one for further
discussion, except those which I'm atm unsure if we should address them now.
Feel free to open additional issues :)
1. Scheduling options : I've created SLING-3166 to further discuss this
2. DAYLY vs DAILY: Yes, I noticed this as well and corrected it some days ago
3. Logging: I've created SLING-3167 for this
4. JobUtil class is deprecated: I've created SLING-3168 for this
5. and 6. Names of enumeration: SLING-3169
7a "how type/state is set if the job sets a state/result FAILED? SUCCEEDED or
CANCELLED? both is not correct". - FAILED means it's retried again so it is
either QUEUED or ACTIVE - unless the max retries is reached, then it goes into
CANCELLED.
7b. "btw. CANCELLED is british englisch, CANCELED is american english" -
thanks, I'll correct this.
7c. "in our own job implementation with have states for "transitions" as well
like "CANCELING". this is useful because sometimes a job that is canceled
cannot cancel at once, but takes some seconds or minutes to wait for the best
time when the job can be canceled. if this job is displayed in a management GUI
it would be helpful to show this transition state as we

[jira] [Resolved] (SLING-3166) Job Scheduling Possibilities


 [ 
https://issues.apache.org/jira/browse/SLING-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-3166.
-

Resolution: Fixed

I've added monthly and yearly and also support for a cron expression - 
scheduling can now be done as flexible as required

> Job Scheduling Possibilities
> 
>
> Key: SLING-3166
> URL: https://issues.apache.org/jira/browse/SLING-3166
> Project: Sling
>  Issue Type: New Feature
>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:
> JobBuilder.ScheduleBuilder: why only for hourly, dayly, weekly? whats about 
> monthly, yearly? esp. because we have a good support for persisting jobs and 
> picking them up later on this job processing is suited for seldom running 
> jobs as well. like cron.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Jenkins build is back to stable : sling-trunk-1.6 #1971

See

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #1971

See

Jenkins build became unstable: sling-trunk-1.6 #1970

See

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1970

See

[jira] [Resolved] (SLING-3171) Deprecate job name handling


 [ 
https://issues.apache.org/jira/browse/SLING-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-3171.
-

Resolution: Fixed

> Deprecate job name handling
> ---
>
> Key: SLING-3171
> URL: https://issues.apache.org/jira/browse/SLING-3171
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Extensions Event 3.2.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Extensions Event 3.3.0
>
>
> The job name feature is disturbing, complicated to implement and usually not 
> needed: it is used to handle the case where the same job is created more than 
> once. This can usually easily be handled by the client code creating the job, 
> especially with the new topology stuff.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3171) Deprecate job name handling

Carsten Ziegeler created SLING-3171:
---

 Summary: Deprecate job name handling
 Key: SLING-3171
 URL: https://issues.apache.org/jira/browse/SLING-3171
 Project: Sling
  Issue Type: Task
  Components: Extensions
Affects Versions: Extensions Event 3.2.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Extensions Event 3.3.0


The job name feature is disturbing, complicated to implement and usually not 
needed: it is used to handle the case where the same job is created more than 
once. This can usually easily be handled by the client code creating the job, 
especially with the new topology stuff.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (SLING-3168) Deprecating JobUtil class?


 [ 
https://issues.apache.org/jira/browse/SLING-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-3168.
-

Resolution: Fixed

I've dropped the priority completely and therefore simply deprecated it. 
NotificationConstants now contains the constants for notifications and JobUtil 
is completely deprecated now

> Deprecating JobUtil class?
> --
>
> Key: SLING-3168
> URL: https://issues.apache.org/jira/browse/SLING-3168
> 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:
> the JobUtil class is deprecated by 90%. perhaps its better to deprecated it 
> completely and move the remaining 10% to a new location or other classes more 
> suitable. This would solve the inconsistency with the JobUtil.JobPriority 
> enum as well, which is not part of the Job interface, whereas JobType is part 
> of the Job interface.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3162) Sling virtual resource tree only appears in the Project Explorer, not the Package Explorer

2013-10-14 Thread Justin Edelson (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Edelson updated SLING-3162:
--

  Description: 
In the Java EE perspective, the default navigator view is the Project Explorer. 
In the Java perspective, it is the Package Explorer. Personally, I never use 
the Java EE perspective (and thus the Project Explorer) because Sling != JavaEE 
:)

It seems to be OK if I just remove the Package Explorer view from the Java 
perspective and add the Project Explorer. But IMHO, this isn't intuitive.

  was:This requirement doesn't seem intuitive to me  as Sling != Java EE :)

Fix Version/s: (was: Sling Eclipse IDE 1.0.0)
   Issue Type: Improvement  (was: Bug)

> Sling virtual resource tree only appears in the Project Explorer, not the 
> Package Explorer
> --
>
> Key: SLING-3162
> URL: https://issues.apache.org/jira/browse/SLING-3162
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Justin Edelson
>Priority: Minor
>
> In the Java EE perspective, the default navigator view is the Project 
> Explorer. In the Java perspective, it is the Package Explorer. Personally, I 
> never use the Java EE perspective (and thus the Project Explorer) because 
> Sling != JavaEE :)
> It seems to be OK if I just remove the Package Explorer view from the Java 
> perspective and add the Project Explorer. But IMHO, this isn't intuitive.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3162) Sling virtual resource tree only appears in project when in Java EE perspective, not Java perspective

2013-10-14 Thread Justin Edelson (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794102#comment-13794102
 ] 

Justin Edelson commented on SLING-3162:
---

[~egli] Ah... good point. I didn't notice that in the Java EE perspective, the 
Project Explorer was used as the default navigator whereas in the Java 
perspective, it was the Package Explorer. I'll update the description 
accordingly.

> Sling virtual resource tree only appears in project when in Java EE 
> perspective, not Java perspective
> -
>
> Key: SLING-3162
> URL: https://issues.apache.org/jira/browse/SLING-3162
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Justin Edelson
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.0.0
>
>
> This requirement doesn't seem intuitive to me  as Sling != Java EE :)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3162) Sling virtual resource tree only appears in the Project Explorer, not the Package Explorer

2013-10-14 Thread Justin Edelson (JIRA)


 [ 
https://issues.apache.org/jira/browse/SLING-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Edelson updated SLING-3162:
--

Summary: Sling virtual resource tree only appears in the Project Explorer, 
not the Package Explorer  (was: Sling virtual resource tree only appears in 
project when in Java EE perspective, not Java perspective)

> Sling virtual resource tree only appears in the Project Explorer, not the 
> Package Explorer
> --
>
> Key: SLING-3162
> URL: https://issues.apache.org/jira/browse/SLING-3162
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Justin Edelson
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.0.0
>
>
> This requirement doesn't seem intuitive to me  as Sling != Java EE :)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling JCR Installer #1969

See

Jenkins build is back to normal : sling-trunk-1.6 #1969

See

[jira] [Commented] (SLING-3165) Cannot remove Bundle or Content Package Module from Server

2013-10-14 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794059#comment-13794059
 ] 

Robert Munteanu commented on SLING-3165:


As a workaround, you can right-click on the server and click 'Add and Remove...'

> Cannot remove Bundle or Content Package Module from Server
> --
>
> Key: SLING-3165
> URL: https://issues.apache.org/jira/browse/SLING-3165
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Justin Edelson
> Fix For: Sling Eclipse IDE 1.0.0
>
>
> From the Servers view, right clicking on a module (bundle or content package) 
> includes a "Remove" option which opens a confirmation dialog, but this 
> doesn't seem to do anything.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3162) Sling virtual resource tree only appears in project when in Java EE perspective, not Java perspective

2013-10-14 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794060#comment-13794060
 ] 

Robert Munteanu commented on SLING-3162:


I don't think the package explorer uses the same contributions as the project 
explorer.

> Sling virtual resource tree only appears in project when in Java EE 
> perspective, not Java perspective
> -
>
> Key: SLING-3162
> URL: https://issues.apache.org/jira/browse/SLING-3162
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Justin Edelson
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.0.0
>
>
> This requirement doesn't seem intuitive to me  as Sling != Java EE :)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3164) Clarify and deprecate ClusterView.getId


 [ 
https://issues.apache.org/jira/browse/SLING-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-3164:
---

Fix Version/s: Discovery API 1.0.2

> Clarify and deprecate ClusterView.getId
> ---
>
> Key: SLING-3164
> URL: https://issues.apache.org/jira/browse/SLING-3164
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery API 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery API 1.0.2
>
>
> As discussed on the list (at [0]) the ClusterView.getId() is currently 
> unspecific about whether the id is stable/persistent or not. The current 
> implementation of it is not stable and returns a new id with every changing 
> cluster view. Without assumptions on the underlying implementation details it 
> is not trivial to provide a stable id. This contrasts to the slingId of an 
> InstanceDescription - which is guaranteed to be stable. A cluster can reshape 
> and join another cluster, hence a cluster id is not trivial to be stable.
> The suggestion is to clarify the unstable nature of that id in its javadoc 
> and marking it as deprecated - since there is no use for an unstable id 
> really.
> --
> [0] - http://markmail.org/message/kf3pydso7eruiwfg



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (SLING-3164) Clarify and deprecate ClusterView.getId


 [ 
https://issues.apache.org/jira/browse/SLING-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-3164.


Resolution: Fixed

deprecated ClusterView.getId() and adjusted javadoc accordingly

> Clarify and deprecate ClusterView.getId
> ---
>
> Key: SLING-3164
> URL: https://issues.apache.org/jira/browse/SLING-3164
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery API 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> As discussed on the list (at [0]) the ClusterView.getId() is currently 
> unspecific about whether the id is stable/persistent or not. The current 
> implementation of it is not stable and returns a new id with every changing 
> cluster view. Without assumptions on the underlying implementation details it 
> is not trivial to provide a stable id. This contrasts to the slingId of an 
> InstanceDescription - which is guaranteed to be stable. A cluster can reshape 
> and join another cluster, hence a cluster id is not trivial to be stable.
> The suggestion is to clarify the unstable nature of that id in its javadoc 
> and marking it as deprecated - since there is no use for an unstable id 
> really.
> --
> [0] - http://markmail.org/message/kf3pydso7eruiwfg



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (SLING-3164) Clarify and deprecate ClusterView.getId


 [ 
https://issues.apache.org/jira/browse/SLING-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli reassigned SLING-3164:
--

Assignee: Stefan Egli

> Clarify and deprecate ClusterView.getId
> ---
>
> Key: SLING-3164
> URL: https://issues.apache.org/jira/browse/SLING-3164
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery API 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> As discussed on the list (at [0]) the ClusterView.getId() is currently 
> unspecific about whether the id is stable/persistent or not. The current 
> implementation of it is not stable and returns a new id with every changing 
> cluster view. Without assumptions on the underlying implementation details it 
> is not trivial to provide a stable id. This contrasts to the slingId of an 
> InstanceDescription - which is guaranteed to be stable. A cluster can reshape 
> and join another cluster, hence a cluster id is not trivial to be stable.
> The suggestion is to clarify the unstable nature of that id in its javadoc 
> and marking it as deprecated - since there is no use for an unstable id 
> really.
> --
> [0] - http://markmail.org/message/kf3pydso7eruiwfg



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [jira] [Commented] (SLING-1778) Symlinks

2013-10-14 Thread Bertrand Delacretaz

Hi Felix,

On Mon, Oct 14, 2013 at 10:27 AM, Felix Meschberger  wrote:
>> Bertrand Delacretaz commented on SLING-1778:
...
>> The shared components might go under bundles/commons/resourceprovider

> ---Currently we have two non-JCR resource providers: Filesystem and Bundle 
> Resource Provider; both in bundles/extensions.
> So either we continue with this and thus this new one goes into 
> bundles/extensions (or contrib/extensions), too.
> Or we create a new subtree bundles/resource where we put all non-JCR resource 
> providers...

bundles/resource sounds good to me, and we could move both
resourceaccesssecurity and resourceresolver in there.

The reusable "overlay" components of SLING-1778 (which is what I was
talking about, not the resource provider itself) could then be a
bundles/resource/overlay or bundles/resource/commons.

-Bertrand

Re: [jira] [Commented] (SLING-1778) Symlinks

2013-10-14 Thread Felix Meschberger

Hi

Bertrand on where to potentially add such a resource provider...

Am 14.10.2013 um 10:06 schrieb Bertrand Delacretaz (JIRA):

> Bertrand Delacretaz commented on SLING-1778:
> 
> 
> The shared components might go under bundles/commons/resourceprovider

I think the commons area is basically "Sling-free" space and should remain such.

Currently we have two non-JCR resource providers: Filesystem and Bundle 
Resource Provider; both in bundles/extensions. So either we continue with this 
and thus this new one goes into bundles/extensions (or contrib/extensions), 
too. Or we create a new subtree bundles/resource where we put all non-JCR 
resource providers (we could even move the Resource Resolver implementation 
bundle there).

I have a slight preference for a new bundles/resource subtree.

WDYT ?

Regards
Felix

smime.p7s
Description: S/MIME cryptographic signature

[jira] [Commented] (SLING-3162) Sling virtual resource tree only appears in project when in Java EE perspective, not Java perspective