[jira] [Updated] (SLING-3069) Allow attaching an Appender to a Logger without changing its existing Log level
[ https://issues.apache.org/jira/browse/SLING-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3069: Fix Version/s: Commons Log 4.0.0 > Allow attaching an Appender to a Logger without changing its existing Log > level > --- > > Key: SLING-3069 > URL: https://issues.apache.org/jira/browse/SLING-3069 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Priority: Minor > Labels: logback > Fix For: Commons Log 4.0.0 > > > Commons Log now supports attaching Appenders as OSGi services. Current > implementation while trying to attach appender also modifies the Log level to > INFO if none specified. It should be possible to attach an appender without > modifying the existing log level -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3069) Allow attaching an Appender to a Logger without changing its existing Log level
[ https://issues.apache.org/jira/browse/SLING-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768153#comment-13768153 ] Carsten Ziegeler commented on SLING-3069: - I suggest to create three different service registration properties: - logger name - log level (optional) - defaults to empty value - additive (optional) - defaults to true If no log level is set, the log level of the logger is not changed at all > Allow attaching an Appender to a Logger without changing its existing Log > level > --- > > Key: SLING-3069 > URL: https://issues.apache.org/jira/browse/SLING-3069 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Priority: Minor > Labels: logback > > Commons Log now supports attaching Appenders as OSGi services. Current > implementation while trying to attach appender also modifies the Log level to > INFO if none specified. It should be possible to attach an appender without > modifying the existing log level -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2944) Replace administrative login by service-based login
[ https://issues.apache.org/jira/browse/SLING-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768165#comment-13768165 ] Carsten Ziegeler commented on SLING-2944: - Apart from the service implementation, no java client code needs this method - that's why I removed it. So it's completely up to the service implementation how to do the mapping. I've changed the log messages of the clients using this code to not assume how this is done in the service, so they are just outputting the bundle and the sub service name now as separate information. > Replace administrative login by service-based login > --- > > Key: SLING-2944 > URL: https://issues.apache.org/jira/browse/SLING-2944 > Project: Sling > Issue Type: New Feature > Components: API, JCR, ResourceResolver, Service User Mapper >Affects Versions: JCR Resource 2.2.8, JCR Jackrabbit Server 2.1.0, JCR > Base 2.1.2, JCR API 2.1.0, API 2.4.2, Resource Resolver 1.0.6 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Service User Mapper 1.0.0, Servlets Resolver 2.2.6, JCR > Resource 2.3.0, JCR Jackrabbit Server 2.2.0, JCR Base 2.1.4, JCR API 2.2.0, > File System Resource Provider 1.1.4, Extensions Bundleresource 2.1.4, API > 2.5.0, Resource Resolver 1.1.0 > > Attachments: serviceusermapper.tgz, SLING-2944.patch > > > From the start Sling tried to solve the problem of providing services access > to the repository and resource tree without having to hard code and configure > any passwords. This was done first with the > SlingRepository.loginAdministrative and later with the > ResourceResolverFactory.getAdministrativeResourceResolver methods. > Over time this mechanism proved to be the hammer to hit all nails. > Particularly these methods while truly useful have the disadvantage of > providing full administrative privileges to services where just some specific > kind of privilege would be enough. > For example for the JSP compiler it would be enough to be able to read the > JSP source scripts and write the Java classes out to the JSP compiler's > target location. Other access is not required. Similarly to manage users user > management privileges are enough and no access to /content is really required. > To solve this problem a new API for Service Authentication has been proposed > at https://cwiki.apache.org/confluence/display/SLING/Service+Authentication. > The prototype of which is implemented in > http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative. > This issue is about merging the prototype code back into trunk and thus fully > implementing the feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3069) Allow attaching an Appender to a Logger without changing its existing Log level
[ https://issues.apache.org/jira/browse/SLING-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768176#comment-13768176 ] Carsten Ziegeler commented on SLING-3069: - Ah right - yeah, sorry I missed the array part - ok, so yes, a single string it is :) I think the default for additive should be "true" - not false as this is the default logback behaviour > Allow attaching an Appender to a Logger without changing its existing Log > level > --- > > Key: SLING-3069 > URL: https://issues.apache.org/jira/browse/SLING-3069 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Priority: Minor > Labels: logback > Fix For: Commons Log 4.0.0 > > > Commons Log now supports attaching Appenders as OSGi services. Current > implementation while trying to attach appender also modifies the Log level to > INFO if none specified. It should be possible to attach an appender without > modifying the existing log level -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-3060) Enable Logback to use OSGi services for Filters and TurboFilters
[ https://issues.apache.org/jira/browse/SLING-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3060: --- Assignee: Carsten Ziegeler > Enable Logback to use OSGi services for Filters and TurboFilters > > > Key: SLING-3060 > URL: https://issues.apache.org/jira/browse/SLING-3060 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler > Attachments: SLING-3060.patch > > > Currently the Logback integration enabled use of OSGi services as Appenders > [1]. It would be helpful if it can also enabled using OSGi services for > Logback Filters and TurboFilters [2]. > The filters can be used to precisely extract required logs for certain flow > and prove to be very useful for debugging complex issues > [1] > https://github.com/chetanmeh/sling-logback#appenders-and-whiteboard-pattern > [2] http://logback.qos.ch/manual/filters.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-3060) Enable Logback to use OSGi services for Filters and TurboFilters
[ https://issues.apache.org/jira/browse/SLING-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3060. - Resolution: Fixed Thanks for your patch, Chetan - it looks good to me, I'Ve applied it to trunk > Enable Logback to use OSGi services for Filters and TurboFilters > > > Key: SLING-3060 > URL: https://issues.apache.org/jira/browse/SLING-3060 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3060.patch > > > Currently the Logback integration enabled use of OSGi services as Appenders > [1]. It would be helpful if it can also enabled using OSGi services for > Logback Filters and TurboFilters [2]. > The filters can be used to precisely extract required logs for certain flow > and prove to be very useful for debugging complex issues > [1] > https://github.com/chetanmeh/sling-logback#appenders-and-whiteboard-pattern > [2] http://logback.qos.ch/manual/filters.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3060) Enable Logback to use OSGi services for Filters and TurboFilters
[ https://issues.apache.org/jira/browse/SLING-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3060: Fix Version/s: Commons Log 4.0.0 > Enable Logback to use OSGi services for Filters and TurboFilters > > > Key: SLING-3060 > URL: https://issues.apache.org/jira/browse/SLING-3060 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3060.patch > > > Currently the Logback integration enabled use of OSGi services as Appenders > [1]. It would be helpful if it can also enabled using OSGi services for > Logback Filters and TurboFilters [2]. > The filters can be used to precisely extract required logs for certain flow > and prove to be very useful for debugging complex issues > [1] > https://github.com/chetanmeh/sling-logback#appenders-and-whiteboard-pattern > [2] http://logback.qos.ch/manual/filters.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-3036) Feedback on SLING-2707: Support of chunked file upload
[ https://issues.apache.org/jira/browse/SLING-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3036: --- Assignee: Carsten Ziegeler > Feedback on SLING-2707: Support of chunked file upload > -- > > Key: SLING-3036 > URL: https://issues.apache.org/jira/browse/SLING-3036 > Project: Sling > Issue Type: Improvement > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Shashank Gupta >Assignee: Carsten Ziegeler > Fix For: Servlets Post 2.3.4 > > Attachments: SLING-3036.patch > > > * Move chunk node definition to post servlet > * Garbage collection of incomplete chunk uploads > * Improve on chunk merge > * Re-factor chunk related properties from ResourceProperty to new class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3036) Feedback on SLING-2707: Support of chunked file upload
[ https://issues.apache.org/jira/browse/SLING-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3036: Fix Version/s: Servlets Post 2.3.4 > Feedback on SLING-2707: Support of chunked file upload > -- > > Key: SLING-3036 > URL: https://issues.apache.org/jira/browse/SLING-3036 > Project: Sling > Issue Type: Improvement > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Shashank Gupta > Fix For: Servlets Post 2.3.4 > > Attachments: SLING-3036.patch > > > * Move chunk node definition to post servlet > * Garbage collection of incomplete chunk uploads > * Improve on chunk merge > * Re-factor chunk related properties from ResourceProperty to new class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2707) Support of chunked file upload into Sling
[ https://issues.apache.org/jira/browse/SLING-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2707. - Resolution: Fixed > Support of chunked file upload into Sling > - > > Key: SLING-2707 > URL: https://issues.apache.org/jira/browse/SLING-2707 > Project: Sling > Issue Type: New Feature > Components: Servlets >Reporter: Shashank Gupta >Assignee: Carsten Ziegeler > Fix For: Servlets Post 2.3.4 > > Attachments: SLING-2707.patch, SLING-2707-svn.patch, uploadclient.jar > > > Use cases: > 1. Large file upload - With high speed internet connections, advent of cloud > and HD going mainstream, Sling should support large files (> 2GB) upload. > 2. Fault tolerant uploads - Sling should provide capability to resume upload > from failure point. It should not require client to restart the complete > upload process. > 3. Faster upload: Sling should support its clients to initiate multiple > connection and upload file chunks in parallel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-3036) Feedback on SLING-2707: Support of chunked file upload
[ https://issues.apache.org/jira/browse/SLING-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3036. - Resolution: Fixed Thanks for your patch, Shashank. I'Ve applied it to trunk > Feedback on SLING-2707: Support of chunked file upload > -- > > Key: SLING-3036 > URL: https://issues.apache.org/jira/browse/SLING-3036 > Project: Sling > Issue Type: Improvement > Components: Servlets >Affects Versions: Servlets Post 2.3.2 >Reporter: Shashank Gupta >Assignee: Carsten Ziegeler > Fix For: Servlets Post 2.3.4 > > Attachments: SLING-3036.patch > > > * Move chunk node definition to post servlet > * Garbage collection of incomplete chunk uploads > * Improve on chunk merge > * Re-factor chunk related properties from ResourceProperty to new class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-3071) DynamicClassLoaderManager should return DynamicClassLoaders
[ https://issues.apache.org/jira/browse/SLING-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3071: --- Assignee: Carsten Ziegeler > DynamicClassLoaderManager should return DynamicClassLoaders > --- > > Key: SLING-3071 > URL: https://issues.apache.org/jira/browse/SLING-3071 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons ClassLoader 1.3.0 >Reporter: Francesco Mari >Assignee: Carsten Ziegeler >Priority: Minor > Attachments: SLING-3071.patch > > > DynamicClassLoaderManager returns ClassLoader objects which are not instances > of DynamicClassLoader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3071) DynamicClassLoaderManager should return DynamicClassLoaders
[ https://issues.apache.org/jira/browse/SLING-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3071: Fix Version/s: Commons ClassLoader 1.3.2 > DynamicClassLoaderManager should return DynamicClassLoaders > --- > > Key: SLING-3071 > URL: https://issues.apache.org/jira/browse/SLING-3071 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons ClassLoader 1.3.0 >Reporter: Francesco Mari >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: Commons ClassLoader 1.3.2 > > Attachments: SLING-3071.patch > > > DynamicClassLoaderManager returns ClassLoader objects which are not instances > of DynamicClassLoader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-3071) DynamicClassLoaderManager should return DynamicClassLoaders
[ https://issues.apache.org/jira/browse/SLING-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3071. - Resolution: Fixed Thanks for your patch, Francesco. It's applied > DynamicClassLoaderManager should return DynamicClassLoaders > --- > > Key: SLING-3071 > URL: https://issues.apache.org/jira/browse/SLING-3071 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons ClassLoader 1.3.0 >Reporter: Francesco Mari >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: Commons ClassLoader 1.3.2 > > Attachments: SLING-3071.patch > > > DynamicClassLoaderManager returns ClassLoader objects which are not instances > of DynamicClassLoader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3069) Allow attaching an Appender to a Logger without changing its existing Log level
[ https://issues.apache.org/jira/browse/SLING-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768262#comment-13768262 ] Carsten Ziegeler commented on SLING-3069: - Good point, yes, log level and additivity are configurations of the loggers not the appenders > Allow attaching an Appender to a Logger without changing its existing Log > level > --- > > Key: SLING-3069 > URL: https://issues.apache.org/jira/browse/SLING-3069 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Priority: Minor > Labels: logback > Fix For: Commons Log 4.0.0 > > > Commons Log now supports attaching Appenders as OSGi services. Current > implementation while trying to attach appender also modifies the Log level to > INFO if none specified. It should be possible to attach an appender without > modifying the existing log level -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768263#comment-13768263 ] Carsten Ziegeler commented on SLING-3028: - Right - this is right now mutual exclusive and I'm wondering if this is a real use case :) In your scenario you could simply set the number of steps to 5 and increase by two for the second and third part of your three part process. No need to set the ETA. Once the first step is done, the ETA can be estimated by the available information: five steps and the duration for step one. > Support for progress tracking of jobs > - > > Key: SLING-3028 > URL: https://issues.apache.org/jira/browse/SLING-3028 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Victor Saar > Labels: jobs > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3069) Allow attaching an Appender to a Logger without changing its existing Log level
[ https://issues.apache.org/jira/browse/SLING-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768289#comment-13768289 ] Carsten Ziegeler commented on SLING-3069: - I removed the support for log level and additivity for appender registration > Allow attaching an Appender to a Logger without changing its existing Log > level > --- > > Key: SLING-3069 > URL: https://issues.apache.org/jira/browse/SLING-3069 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Log 4.0.0 >Reporter: Chetan Mehrotra >Priority: Minor > Labels: logback > Fix For: Commons Log 4.0.0 > > > Commons Log now supports attaching Appenders as OSGi services. Current > implementation while trying to attach appender also modifies the Log level to > INFO if none specified. It should be possible to attach an appender without > modifying the existing log level -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768473#comment-13768473 ] Carsten Ziegeler commented on SLING-3028: - In rev 1523723 I'Ve added support for the new JobExecutor service - progress tracking/result etc is not implemented yet > Support for progress tracking of jobs > - > > Key: SLING-3028 > URL: https://issues.apache.org/jira/browse/SLING-3028 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Victor Saar > Labels: jobs > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-3075) Update to Metatype 1.0.8
Carsten Ziegeler created SLING-3075: --- Summary: Update to Metatype 1.0.8 Key: SLING-3075 URL: https://issues.apache.org/jira/browse/SLING-3075 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Builder 7 We should update to the new Apache Felix Metatype 1.0.8 releases as this fixes some bugs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-3075) Update to Metatype 1.0.8
[ https://issues.apache.org/jira/browse/SLING-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3075. - Resolution: Fixed > Update to Metatype 1.0.8 > > > Key: SLING-3075 > URL: https://issues.apache.org/jira/browse/SLING-3075 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Launchpad Builder 7 > > > We should update to the new Apache Felix Metatype 1.0.8 releases as this > fixes some bugs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3028: Fix Version/s: Extensions Event 3.2.2 > Support for progress tracking of 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.2.2 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-3028) Support for progress tracking of jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3028: --- Assignee: Carsten Ziegeler > Support for progress tracking of 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 > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Carsten Ziegeler updated SLING-3028: Summary: Support for progress tracking of jobs and keeping jobs (was: Support for progress tracking of jobs) > 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.2.2 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3048) Filter to populate SLF4J MDC with request details
[
https://issues.apache.org/jira/browse/SLING-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770576#comment-13770576
]
Carsten Ziegeler commented on SLING-3048:
-
The session id is currently outputted by Session.toString() - I think this is
not really spec'ed that way, so we should drop this
> Filter to populate SLF4J MDC with request details
> -
>
> Key: SLING-3048
> URL: https://issues.apache.org/jira/browse/SLING-3048
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.extensions.mdc-0.0.1-SNAPSHOT-src.zip
>
>
> With Commons Log moving to Logback its possible to use MDC [1] support of
> SLF4J in Sling to get better logs and also enable better filtering of logs.
> The patch adds a new extension module which registers a
> {{MDCInsertingFilter}}. This filter can extract information from incoming
> request and add them to the MDC
> Features supported
> 1. By default expose details like Request path, Query String etc based on [3]
> 2. Exposes OSGi config where one can define what HTTP Header, Parameter or
> Cookie needs to be added to MDC
> 3. Exposes Session ID, USer Information from RequestResolver associated with
> current thread of execution
> This information can then later be exposed via logs like shown below. Here we
> expose the SessionID as part of log
> ---
> %d{dd.MM. HH:mm:ss.SSS} *%level* [%thread] %logger [%X{jcr.sessionId}]
> %msg%n
> ---
> The same information can also be used to filter logs based on user,url etc or
> used in custom Logging event evaluator
> For more details refer to [2]
> [1] http://www.slf4j.org/manual.html#mdc
> [2] https://github.com/chetanmeh/sling-logback/tree/master/mdc
> [3] http://logback.qos.ch/manual/mdc.html#mis
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3048) Filter to populate SLF4J MDC with request details
[
https://issues.apache.org/jira/browse/SLING-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770726#comment-13770726
]
Carsten Ziegeler commented on SLING-3048:
-
Is this really useful? It's not spec'ed - so it might be anything and we
already know the request, so we can correlate all entries to exactly this
point. The session will be closed after the request anyway, so it's not
available. I don't think that this adds any useful or additional information
> Filter to populate SLF4J MDC with request details
> -
>
> Key: SLING-3048
> URL: https://issues.apache.org/jira/browse/SLING-3048
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.extensions.mdc-0.0.1-SNAPSHOT-src.zip
>
>
> With Commons Log moving to Logback its possible to use MDC [1] support of
> SLF4J in Sling to get better logs and also enable better filtering of logs.
> The patch adds a new extension module which registers a
> {{MDCInsertingFilter}}. This filter can extract information from incoming
> request and add them to the MDC
> Features supported
> 1. By default expose details like Request path, Query String etc based on [3]
> 2. Exposes OSGi config where one can define what HTTP Header, Parameter or
> Cookie needs to be added to MDC
> 3. Exposes Session ID, USer Information from RequestResolver associated with
> current thread of execution
> This information can then later be exposed via logs like shown below. Here we
> expose the SessionID as part of log
> ---
> %d{dd.MM. HH:mm:ss.SSS} *%level* [%thread] %logger [%X{jcr.sessionId}]
> %msg%n
> ---
> The same information can also be used to filter logs based on user,url etc or
> used in custom Logging event evaluator
> For more details refer to [2]
> [1] http://www.slf4j.org/manual.html#mdc
> [2] https://github.com/chetanmeh/sling-logback/tree/master/mdc
> [3] http://logback.qos.ch/manual/mdc.html#mis
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3048) Filter to populate SLF4J MDC with request details
[
https://issues.apache.org/jira/browse/SLING-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770744#comment-13770744
]
Carsten Ziegeler commented on SLING-3048:
-
But this session id is set as part of a request filter - so you log all actions
executed within the scope of this filter with this session id - although
internally a different session might be used. Or do I overlook something?
> Filter to populate SLF4J MDC with request details
> -
>
> Key: SLING-3048
> URL: https://issues.apache.org/jira/browse/SLING-3048
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.extensions.mdc-0.0.1-SNAPSHOT-src.zip
>
>
> With Commons Log moving to Logback its possible to use MDC [1] support of
> SLF4J in Sling to get better logs and also enable better filtering of logs.
> The patch adds a new extension module which registers a
> {{MDCInsertingFilter}}. This filter can extract information from incoming
> request and add them to the MDC
> Features supported
> 1. By default expose details like Request path, Query String etc based on [3]
> 2. Exposes OSGi config where one can define what HTTP Header, Parameter or
> Cookie needs to be added to MDC
> 3. Exposes Session ID, USer Information from RequestResolver associated with
> current thread of execution
> This information can then later be exposed via logs like shown below. Here we
> expose the SessionID as part of log
> ---
> %d{dd.MM. HH:mm:ss.SSS} *%level* [%thread] %logger [%X{jcr.sessionId}]
> %msg%n
> ---
> The same information can also be used to filter logs based on user,url etc or
> used in custom Logging event evaluator
> For more details refer to [2]
> [1] http://www.slf4j.org/manual.html#mdc
> [2] https://github.com/chetanmeh/sling-logback/tree/master/mdc
> [3] http://logback.qos.ch/manual/mdc.html#mis
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-1298) Update Authentication Documentation with Impersonation support info
[ https://issues.apache.org/jira/browse/SLING-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1298: Fix Version/s: (was: Auth Core 1.1.4) Auth Core 1.1.6 > Update Authentication Documentation with Impersonation support info > --- > > Key: SLING-1298 > URL: https://issues.apache.org/jira/browse/SLING-1298 > Project: Sling > Issue Type: Task > Components: Authentication >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Auth Core 1.1.6 > > > Currently the Sling authentication documentation page at > http://sling.apache.org/site/authentication.html does not provide any > information on support for user impersonation by the Sling Authenticator. > This should be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-3079) Move constant for "sling.auth.requirements" to AuthConstants
[ https://issues.apache.org/jira/browse/SLING-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3079. - Resolution: Fixed Thanks. Moved > Move constant for "sling.auth.requirements" to AuthConstants > > > Key: SLING-3079 > URL: https://issues.apache.org/jira/browse/SLING-3079 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Konrad Windszus >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > > As this constant should also be used from Services defining any > authentication restriction with an OSGi component property having that name > (http://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html), > it would be good to make it accessible to other bundles as well, by moving > it from > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticator.java > to > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthConstants.java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-3079) Move constant for "sling.auth.requirements" to AuthConstants
[ https://issues.apache.org/jira/browse/SLING-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3079: --- Assignee: Carsten Ziegeler > Move constant for "sling.auth.requirements" to AuthConstants > > > Key: SLING-3079 > URL: https://issues.apache.org/jira/browse/SLING-3079 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Konrad Windszus >Assignee: Carsten Ziegeler > > As this constant should also be used from Services defining any > authentication restriction with an OSGi component property having that name > (http://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html), > it would be good to make it accessible to other bundles as well, by moving > it from > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticator.java > to > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthConstants.java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3079) Move constant for "sling.auth.requirements" to AuthConstants
[ https://issues.apache.org/jira/browse/SLING-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3079: Fix Version/s: Auth Core 1.1.4 > Move constant for "sling.auth.requirements" to AuthConstants > > > Key: SLING-3079 > URL: https://issues.apache.org/jira/browse/SLING-3079 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Konrad Windszus >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > > As this constant should also be used from Services defining any > authentication restriction with an OSGi component property having that name > (http://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html), > it would be good to make it accessible to other bundles as well, by moving > it from > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticator.java > to > http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/src/main/java/org/apache/sling/auth/core/AuthConstants.java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-2615) allow the LogoutServlet to be configured to only respond to POST requests
[ https://issues.apache.org/jira/browse/SLING-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2615: --- Assignee: Carsten Ziegeler > allow the LogoutServlet to be configured to only respond to POST requests > - > > Key: SLING-2615 > URL: https://issues.apache.org/jira/browse/SLING-2615 > Project: Sling > Issue Type: Improvement > Components: Authentication >Reporter: Justin Edelson >Assignee: Carsten Ziegeler > Attachments: slingLogout.patch > > > see thread http://sling.markmail.org/thread/5dnksd4xwpngoodg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2615) allow the LogoutServlet to be configured to only respond to POST requests
[ https://issues.apache.org/jira/browse/SLING-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2615: Fix Version/s: Auth Core 1.1.4 > allow the LogoutServlet to be configured to only respond to POST requests > - > > Key: SLING-2615 > URL: https://issues.apache.org/jira/browse/SLING-2615 > Project: Sling > Issue Type: Improvement > Components: Authentication >Reporter: Justin Edelson >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > Attachments: slingLogout.patch > > > see thread http://sling.markmail.org/thread/5dnksd4xwpngoodg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2490) User can't add Childnodes after receiving jcr:write and jcr:read privileges
[ https://issues.apache.org/jira/browse/SLING-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2490: Component/s: (was: Authentication) > User can't add Childnodes after receiving jcr:write and jcr:read privileges > --- > > Key: SLING-2490 > URL: https://issues.apache.org/jira/browse/SLING-2490 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Access Manager 2.1.0 > Environment: Xubuntu >Reporter: Chris Papagrigoriou >Priority: Trivial > > Though I granted jcr:read and jcr:write to my user, it is not possible for > him to add any Child nodes. He is able to delete nodes and to set properties > though. > Trying curl -X MKCOL -u Odin:Odin > http://localhost:8080/content/private/Odin/apps > (jcr:write and jcr:read were given for the Odin Folder) gives me an Internal > Server error 500. > Trying via the sling Explorer gives me: javax.jcr.AccessDeniedException: > Access denied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2615) allow the LogoutServlet to be configured to only respond to POST requests
[ https://issues.apache.org/jira/browse/SLING-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2615. - Resolution: Fixed Thanks for your patch, Bob - it looks good, however :) as this service has already been configurable before, I just added metatype information for this. > allow the LogoutServlet to be configured to only respond to POST requests > - > > Key: SLING-2615 > URL: https://issues.apache.org/jira/browse/SLING-2615 > Project: Sling > Issue Type: Improvement > Components: Authentication >Reporter: Justin Edelson >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > Attachments: slingLogout.patch > > > see thread http://sling.markmail.org/thread/5dnksd4xwpngoodg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2076) Make MapEntries more dynamic
[ https://issues.apache.org/jira/browse/SLING-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2076: Fix Version/s: (was: Resource Resolver 1.1.0) > Make MapEntries more dynamic > > > Key: SLING-2076 > URL: https://issues.apache.org/jira/browse/SLING-2076 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Affects Versions: JCR Resource 2.0.10 >Reporter: Vidar S. Ramdal >Assignee: Vidar S. Ramdal > > In some scenarios it would be nice to be able to store mapping specs other > places than under /etc/map (for instance scattered around the > repository/resource tree, or in an external XML file). > It would be better if the entire map specification was provided by a separate > service. The current MapEntries would act as the default implementation. > Mailing list discussion: http://markmail.org/thread/5ww634sqarxtudks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-3014) Generate SCR descriptors using the maven-scr-plugin
[ https://issues.apache.org/jira/browse/SLING-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772963#comment-13772963 ] Carsten Ziegeler commented on SLING-3014: - I really think we should look at the m2e integration and what is missing there - the scr plugin needs to be reconfigured to generate the descriptors at target/classes - which we can do for all projects, there is no need to have them generated in target/scr-plugin-generated. I know that people are using m2e with the scr plugin and the above config change without problems > Generate SCR descriptors using the maven-scr-plugin > --- > > Key: SLING-3014 > URL: https://issues.apache.org/jira/browse/SLING-3014 > Project: Sling > Issue Type: Task > Components: IDE >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Minor > Fix For: Sling Eclipse IDE 1.0.2 > > Attachments: SLING-3014-1.patch > > > Since we're starting to use SCR descriptors it would be nice to generate them > using the maven-scr-plugin. I have the build working in the CLI, but not yet > in the IDE ( see > http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04764.html ). Once that is > done I'll commit my changes to trunk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777272#comment-13777272 ] Carsten Ziegeler commented on SLING-2986: - Thanks for the contribution, Gilles - I had a rough look and I'm wondering why you introduce a new API for this. I would assume that a resource provider doing the merging is all you need - apart from that the api reassembles me a little bit of the collection api (though the intent is different of course). For the implementation of the resource, the listChildren() method should be implemented in the resource provider and the resource should just call the resource resolver listChildren method (inherited from the abstract class). The resource resolver than eventually calls the provider. Before diving further into the implementation, I think we should first talk about the API > Merged Resource Provider > > > Key: SLING-2986 > URL: https://issues.apache.org/jira/browse/SLING-2986 > Project: Sling > Issue Type: New Feature > Components: ResourceResolver >Reporter: Gilles Knobloch > > As exchanged once with Felix Meschberger, the idea is to implement a custom > resource provider, with ability to merge multiple resources based on your > search paths. > For instance, if your search paths are > /apps > /libs > Hitting /merge/my/resource/is/here will check > /apps/my/resource/is/here > /libs/my/resource/is/here > There are some options like: > - add/override property > - delete a property of the resource under /libs > - reorder nodes if available > I intend to submit this patch as soon as possible. > Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports
[
https://issues.apache.org/jira/browse/SLING-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-3114:
Fix Version/s: JCR ContentLoader 2.1.8
> DefaultContentImporter should guard against a closed InputStream on system
> view imports
> ---
>
> Key: SLING-3114
> URL: https://issues.apache.org/jira/browse/SLING-3114
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Alex Parvulescu
>Priority: Minor
> Fix For: JCR ContentLoader 2.1.8
>
>
> For the special case of system view imports the null check [0] fails to take
> into account the fact that the input stream is now closed (twice even [1],
> [2]).
> This means that if something happened and the import did not go throught
> (hence the _null_ node), the code will continue and fail later (line 99) with
> a cryptic message: _java.io.IOException: Stream Closed_ [3]
> My proposal (no patch) is to add an else clause with a warn log and a return
> statement.
> [0]
> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
> [1]
> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
> [2]
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
> [3]
> {noformat}
> Caused by: java.io.IOException: Stream Closed
> at java.io.FileInputStream.available(Native Method)
> at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
> at
> org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
> at
> org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778590#comment-13778590 ] Carsten Ziegeler commented on SLING-1778: - I totally agree that symlink is not the best name, other names which came to my mind like Mirroring etc. are not quiet correct either. So why not Superimposing - it's a little bit long. If no one comes up with a better name, a new patch would be nice :) > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: 130704_symlinks-0.0.4.patch, symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778612#comment-13778612 ] Carsten Ziegeler commented on SLING-1778: - I really prefer a name with a meaning - marketing names are not helpful on a technical level > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Julian Sedding > Attachments: 130704_symlinks-0.0.4.patch, symlinks.patch > > > I have implemented a ResourceProvider, which allows to create symlink nodes > in the JCR repository. A symlink node has a sling:symlinkTarget property, > which should contain a valid JCR path. JCR content from the > sling:symlinkTarget path is then exposed below the symlink node. > There is a mixin node type, sling:Symlink with a mandatory property > sling:symlinkTarget and an optional property sling:overlayable. Additionally, > there is a convenience node type, sling:SymlinkResource, which extends from > sling:symlinkTarget and nt:unstructured. > ResourceProvider instances are registered for existing symlinks when the > bundle is started. Modifications are taken care of via JCR observation. > To get started: > * apply the attached patch to a trunk checkout > * build and install the bundle > * create a symlink node, pointing to some existing content > * access the symlink node e.g. via a browser -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=13780041#comment-13780041 ] Carsten Ziegeler commented on SLING-3028: - I've started with the implementation now, cancelled jobs are kept (searching, removing etc. doesn't work yet) And I changed the interface for progress tracking a little bit > 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.2.2 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-3138) Add fluent api to create new jobs
Carsten Ziegeler created SLING-3138: --- Summary: Add fluent api to create new jobs Key: SLING-3138 URL: https://issues.apache.org/jira/browse/SLING-3138 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 3.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 3.2.2 With the addition of new features, a fluent api (builder approach) would be easier to use than adding N methods getting all the different possibilities of arguments -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3139) Provide a way to schedule jobs
Carsten Ziegeler created SLING-3139: --- Summary: Provide a way to schedule jobs Key: SLING-3139 URL: https://issues.apache.org/jira/browse/SLING-3139 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 3.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 3.2.2 The current way of scheduling jobs is not very user friendly: it requires to send an event via event admin. We should add a java api to create scheduled job creation. In addition, we could add a new queue type: maintenance queue which is an order queue with the difference of running jobs exactly at the point of time when they are created. So a scheduled maintenance job is executed exactly at the scheduled time - unless another job is currently running. Apart from starting such jobs, stopping a job would be another nice addition -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3141) AbstractAuthenticationFormServlet should make sure resource is a valid redirect
Carsten Ziegeler created SLING-3141: --- Summary: AbstractAuthenticationFormServlet should make sure resource is a valid redirect Key: SLING-3141 URL: https://issues.apache.org/jira/browse/SLING-3141 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Auth Core 1.1.4 The resource paramter should be checked to be a valid redirect value in AbstractAuthenticationFormServlet -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3141) AbstractAuthenticationFormServlet should make sure resource is a valid redirect
[ https://issues.apache.org/jira/browse/SLING-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782858#comment-13782858 ] Carsten Ziegeler commented on SLING-3141: - Fixed by using the helper method AuthUtil.isRedirectValid and additionally escaping <, >, &, " and ' > AbstractAuthenticationFormServlet should make sure resource is a valid > redirect > --- > > Key: SLING-3141 > URL: https://issues.apache.org/jira/browse/SLING-3141 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > > The resource paramter should be checked to be a valid redirect value in > AbstractAuthenticationFormServlet -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (SLING-3141) AbstractAuthenticationFormServlet should make sure resource is a valid redirect
[ https://issues.apache.org/jira/browse/SLING-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782858#comment-13782858 ] Carsten Ziegeler edited comment on SLING-3141 at 10/1/13 12:09 PM: --- Fixed by using the helper method AuthUtil.isRedirectValid and additionally escaping <, >, &, " and ' Revision 1528062 was (Author: cziegeler): Fixed by using the helper method AuthUtil.isRedirectValid and additionally escaping <, >, &, " and ' > AbstractAuthenticationFormServlet should make sure resource is a valid > redirect > --- > > Key: SLING-3141 > URL: https://issues.apache.org/jira/browse/SLING-3141 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > > The resource paramter should be checked to be a valid redirect value in > AbstractAuthenticationFormServlet -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3140) ClassCastException while serializing byte[] in Sling Job with JCR Resource Resolver
[
https://issues.apache.org/jira/browse/SLING-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783078#comment-13783078
]
Carsten Ziegeler commented on SLING-3140:
-
[~teofili] Thanks for the patch - what about first doing all the instanceof
tests and as a default case casting to Object[] array instead of catching the
exception and then doing the checks?
> ClassCastException while serializing byte[] in Sling Job with JCR Resource
> Resolver
> ---
>
> Key: SLING-3140
> URL: https://issues.apache.org/jira/browse/SLING-3140
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 2.2.8
>Reporter: Tommaso Teofili
> Fix For: JCR Resource 2.3.0
>
>
> When trying to serialize a byte[] in Sling Job properties Map I noticed that
> an error occurs when using the JCR Resource Resolver caused by a
> ClassCastException in JcrPropertyMapCacheEntry since it tries to cast a byte
> to Object. This therefore doesn't happen when serializing Byte[].
> This also happens when trying to serialize long/int/...[] due to the same
> cast.
> Here's the stacktrace:
> could not add an item to the queue java.lang.ClassCastException: [B cannot be
> cast to [Ljava.lang.Object;
> at
> org.apache.sling.jcr.resource.internal.helper.JcrPropertyMapCacheEntry.(JcrPropertyMapCacheEntry.java:94)
> at
> org.apache.sling.jcr.resource.internal.JcrModifiableValueMap.put(JcrModifiableValueMap.java:630)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:453)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1076)
> at
> org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:578)
> at
> org.apache.sling.event.impl.support.ResourceHelper.getOrCreateResource(ResourceHelper.java:221)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.writeJob(JobManagerImpl.java:1323)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJobInteral(JobManagerImpl.java:1242)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJob(JobManagerImpl.java:794)
> Here's the code snippet that triggers the error:
> Map properties = new HashMap();
> properties.put("BIN","a string".getBytes());
> Job job = jobManager.addJob("name", "id", properties);
> See testcase below to reproduce the problem on the JCR Resource Resolver:
> package org.apache.sling.jcr.resource.internal.helper;
> import org.junit.Test;
> public class JcrPropertyMapCacheEntryTest {
> @Test
> public void testByteArray() throws Exception {
> Byte[] ba = new Byte[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> byte[] ba2 = new byte[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> @Test
> public void testLongArray() throws Exception {
> Long[] ba = new Long[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> long[] ba2 = new long[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (SLING-3140) ClassCastException while serializing byte[] in Sling Job with JCR Resource Resolver
[
https://issues.apache.org/jira/browse/SLING-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-3140:
---
Assignee: Carsten Ziegeler
> ClassCastException while serializing byte[] in Sling Job with JCR Resource
> Resolver
> ---
>
> Key: SLING-3140
> URL: https://issues.apache.org/jira/browse/SLING-3140
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 2.2.8
>Reporter: Tommaso Teofili
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.3.0
>
>
> When trying to serialize a byte[] in Sling Job properties Map I noticed that
> an error occurs when using the JCR Resource Resolver caused by a
> ClassCastException in JcrPropertyMapCacheEntry since it tries to cast a byte
> to Object. This therefore doesn't happen when serializing Byte[].
> This also happens when trying to serialize long/int/...[] due to the same
> cast.
> Here's the stacktrace:
> could not add an item to the queue java.lang.ClassCastException: [B cannot be
> cast to [Ljava.lang.Object;
> at
> org.apache.sling.jcr.resource.internal.helper.JcrPropertyMapCacheEntry.(JcrPropertyMapCacheEntry.java:94)
> at
> org.apache.sling.jcr.resource.internal.JcrModifiableValueMap.put(JcrModifiableValueMap.java:630)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:453)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1076)
> at
> org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:578)
> at
> org.apache.sling.event.impl.support.ResourceHelper.getOrCreateResource(ResourceHelper.java:221)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.writeJob(JobManagerImpl.java:1323)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJobInteral(JobManagerImpl.java:1242)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJob(JobManagerImpl.java:794)
> Here's the code snippet that triggers the error:
> Map properties = new HashMap();
> properties.put("BIN","a string".getBytes());
> Job job = jobManager.addJob("name", "id", properties);
> See testcase below to reproduce the problem on the JCR Resource Resolver:
> package org.apache.sling.jcr.resource.internal.helper;
> import org.junit.Test;
> public class JcrPropertyMapCacheEntryTest {
> @Test
> public void testByteArray() throws Exception {
> Byte[] ba = new Byte[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> byte[] ba2 = new byte[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> @Test
> public void testLongArray() throws Exception {
> Long[] ba = new Long[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> long[] ba2 = new long[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (SLING-3140) ClassCastException while serializing byte[] in Sling Job with JCR Resource Resolver
[
https://issues.apache.org/jira/browse/SLING-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-3140:
Fix Version/s: JCR Resource 2.3.0
> ClassCastException while serializing byte[] in Sling Job with JCR Resource
> Resolver
> ---
>
> Key: SLING-3140
> URL: https://issues.apache.org/jira/browse/SLING-3140
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 2.2.8
>Reporter: Tommaso Teofili
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.3.0
>
>
> When trying to serialize a byte[] in Sling Job properties Map I noticed that
> an error occurs when using the JCR Resource Resolver caused by a
> ClassCastException in JcrPropertyMapCacheEntry since it tries to cast a byte
> to Object. This therefore doesn't happen when serializing Byte[].
> This also happens when trying to serialize long/int/...[] due to the same
> cast.
> Here's the stacktrace:
> could not add an item to the queue java.lang.ClassCastException: [B cannot be
> cast to [Ljava.lang.Object;
> at
> org.apache.sling.jcr.resource.internal.helper.JcrPropertyMapCacheEntry.(JcrPropertyMapCacheEntry.java:94)
> at
> org.apache.sling.jcr.resource.internal.JcrModifiableValueMap.put(JcrModifiableValueMap.java:630)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:453)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1076)
> at
> org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:578)
> at
> org.apache.sling.event.impl.support.ResourceHelper.getOrCreateResource(ResourceHelper.java:221)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.writeJob(JobManagerImpl.java:1323)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJobInteral(JobManagerImpl.java:1242)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJob(JobManagerImpl.java:794)
> Here's the code snippet that triggers the error:
> Map properties = new HashMap();
> properties.put("BIN","a string".getBytes());
> Job job = jobManager.addJob("name", "id", properties);
> See testcase below to reproduce the problem on the JCR Resource Resolver:
> package org.apache.sling.jcr.resource.internal.helper;
> import org.junit.Test;
> public class JcrPropertyMapCacheEntryTest {
> @Test
> public void testByteArray() throws Exception {
> Byte[] ba = new Byte[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> byte[] ba2 = new byte[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> @Test
> public void testLongArray() throws Exception {
> Long[] ba = new Long[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> long[] ba2 = new long[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (SLING-3142) NullPointerException with Java8 in AbstractUsingBundleList
Carsten Ziegeler created SLING-3142: --- Summary: NullPointerException with Java8 in AbstractUsingBundleList Key: SLING-3142 URL: https://issues.apache.org/jira/browse/SLING-3142 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes Affects Versions: Maven Launchpad Plugin 2.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Maven Launchpad Plugin 2.2.2 When using the launchpad plugin with java 8 I get an NPE with: Caused by: java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:203) at java.util.ArrayList.removeAll(ArrayList.java:674) at org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers(DefaultMavenFileFilter.java:215) at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:75) at org.apache.sling.maven.projectsupport.AbstractUsingBundleListMojo.readSlingProperties(AbstractUsingBundleListMojo.java:411) at org.apache.sling.maven.projectsupport.AbstractUsingBundleListMojo.getSlingProperties(AbstractUsingBundleListMojo.java:460) It seems that while ArrayList#removeAll(null) does not throw with pre Java8 it now does - the javadocs clearly state that a NPE is thrown, so we should adjust our code -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3141) AbstractAuthenticationFormServlet should make sure resource is a valid redirect
[ https://issues.apache.org/jira/browse/SLING-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3141. - Resolution: Fixed > AbstractAuthenticationFormServlet should make sure resource is a valid > redirect > --- > > Key: SLING-3141 > URL: https://issues.apache.org/jira/browse/SLING-3141 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.1.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Auth Core 1.1.4 > > > The resource paramter should be checked to be a valid redirect value in > AbstractAuthenticationFormServlet -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3140) ClassCastException while serializing byte[] in Sling Job with JCR Resource Resolver
[
https://issues.apache.org/jira/browse/SLING-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3140.
-
Resolution: Fixed
Thanks for your updated patch, Tommas. It's applied
> ClassCastException while serializing byte[] in Sling Job with JCR Resource
> Resolver
> ---
>
> Key: SLING-3140
> URL: https://issues.apache.org/jira/browse/SLING-3140
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 2.2.8
>Reporter: Tommaso Teofili
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.3.0
>
>
> When trying to serialize a byte[] in Sling Job properties Map I noticed that
> an error occurs when using the JCR Resource Resolver caused by a
> ClassCastException in JcrPropertyMapCacheEntry since it tries to cast a byte
> to Object. This therefore doesn't happen when serializing Byte[].
> This also happens when trying to serialize long/int/...[] due to the same
> cast.
> Here's the stacktrace:
> could not add an item to the queue java.lang.ClassCastException: [B cannot be
> cast to [Ljava.lang.Object;
> at
> org.apache.sling.jcr.resource.internal.helper.JcrPropertyMapCacheEntry.(JcrPropertyMapCacheEntry.java:94)
> at
> org.apache.sling.jcr.resource.internal.JcrModifiableValueMap.put(JcrModifiableValueMap.java:630)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:453)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1076)
> at
> org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:578)
> at
> org.apache.sling.event.impl.support.ResourceHelper.getOrCreateResource(ResourceHelper.java:221)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.writeJob(JobManagerImpl.java:1323)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJobInteral(JobManagerImpl.java:1242)
> at
> org.apache.sling.event.impl.jobs.JobManagerImpl.addJob(JobManagerImpl.java:794)
> Here's the code snippet that triggers the error:
> Map properties = new HashMap();
> properties.put("BIN","a string".getBytes());
> Job job = jobManager.addJob("name", "id", properties);
> See testcase below to reproduce the problem on the JCR Resource Resolver:
> package org.apache.sling.jcr.resource.internal.helper;
> import org.junit.Test;
> public class JcrPropertyMapCacheEntryTest {
> @Test
> public void testByteArray() throws Exception {
> Byte[] ba = new Byte[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> byte[] ba2 = new byte[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> @Test
> public void testLongArray() throws Exception {
> Long[] ba = new Long[0];
> new JcrPropertyMapCacheEntry(ba, null);
> // ok
> long[] ba2 = new long[0];
> new JcrPropertyMapCacheEntry(ba2, null);
> // fail
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (SLING-3142) NullPointerException with Java8 in AbstractUsingBundleList
[ https://issues.apache.org/jira/browse/SLING-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3142. - Resolution: Fixed Fixed by passing in an empty list instead of null > NullPointerException with Java8 in AbstractUsingBundleList > -- > > Key: SLING-3142 > URL: https://issues.apache.org/jira/browse/SLING-3142 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Affects Versions: Maven Launchpad Plugin 2.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Maven Launchpad Plugin 2.2.2 > > > When using the launchpad plugin with java 8 I get an NPE with: > Caused by: java.lang.NullPointerException > at java.util.Objects.requireNonNull(Objects.java:203) > at java.util.ArrayList.removeAll(ArrayList.java:674) > at > org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers(DefaultMavenFileFilter.java:215) > at > org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:75) > at > org.apache.sling.maven.projectsupport.AbstractUsingBundleListMojo.readSlingProperties(AbstractUsingBundleListMojo.java:411) > at > org.apache.sling.maven.projectsupport.AbstractUsingBundleListMojo.getSlingProperties(AbstractUsingBundleListMojo.java:460) > It seems that while ArrayList#removeAll(null) does not throw with pre Java8 > it now does - the javadocs clearly state that a NPE is thrown, so we should > adjust our code -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3147) Oak: i18n dictionaries observation no longer works
[ https://issues.apache.org/jira/browse/SLING-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787222#comment-13787222 ] Carsten Ziegeler commented on SLING-3147: - Is this a bug in Oak - or is the Sling implementation relying on non spec'ed behaviour from the jackrabbit implementation? > Oak: i18n dictionaries observation no longer works > -- > > Key: SLING-3147 > URL: https://issues.apache.org/jira/browse/SLING-3147 > Project: Sling > Issue Type: Bug > Components: Extensions, Oak >Affects Versions: i18n 2.2.6 >Reporter: Alexander Klimetschek > Labels: i18n > > When running Sling with Oak, the JcrResourceBundleProvider [0] in the i18n > bundle apparently no longer gets the observation events for sling:message > nodes in the JCR. This means that changing a string in the repo or installing > a package with new translations won't have an effect if the resource bundle > is already loaded in memory. > Workaround is to restart the i18n bundle after every string change. > [0] > http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (SLING-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-2999. --- > JMX Resource Provider > - > > Key: SLING-2999 > URL: https://issues.apache.org/jira/browse/SLING-2999 > Project: Sling > Issue Type: New Feature >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JMX Resource Provider 0.5.0 > > > For easier rendering of JMX mbeans within Sling, a special resource provider > should make the JMX information available at > */system/sling/monitoring/mbeans* (Configurable) > /system/sling/monitoring/mbeans - resource type = sling:mbeans > + resource sub tree with all mbeans > An MBean has an object name which has > * a domain > * properties where type and name are very common > The domain is converted into a sub path and the properties are converted to a > resource name. For example: _org.apache.sling:name=test,type=hello_ creates a > resource _org/apache/sling/name=test,type=hello_. The name can be obtained by > calling _ObjectName.getCanonicalKeyPropertyListString()_. The result might > need escaping (for the values and the = character) in order to create valid > resource names. > Each MBean resource has at least: > ||Property name ||Description| > |sling:resourceType|object name of the MBean| > |sling:resourceSuperType| sling:mbean| > |mbean:description|The description of the MBean (optional)| > |mbean:className|MBean class name| > |mbean:objectName|MBean object name| > |mbean properties|separate property for each property of the object name| > And a child resource named _mbean:attributes_ if the MBean has attributes. > For each attribute a child resource of _mbean:attributes_ is created where > the name of the resource is the name of the attribute and: > ||Property name ||Description| > |sling:resourceType|Type of the attribute| > |sling:resourceSuperType| sling:mbeanattribute| > |mbean:description|The description of the attribute (optional)| > |mbean:value|String representation of the value or a string array for multi > values| -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3018) Add an inventory printer which dumps a resource tree into json
[ https://issues.apache.org/jira/browse/SLING-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3018. - Resolution: Fixed > Add an inventory printer which dumps a resource tree into json > -- > > Key: SLING-3018 > URL: https://issues.apache.org/jira/browse/SLING-3018 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Inventory 0.5.0 > > > An inventory printer could be configured with a path in the repository and > dumps this path into the configuration zip created by the inventory module. > This could, e.g. be used to dump the whole jmx tree created by the jmx > provider -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2999. - Resolution: Fixed > JMX Resource Provider > - > > Key: SLING-2999 > URL: https://issues.apache.org/jira/browse/SLING-2999 > Project: Sling > Issue Type: New Feature >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JMX Resource Provider 0.5.0 > > > For easier rendering of JMX mbeans within Sling, a special resource provider > should make the JMX information available at > */system/sling/monitoring/mbeans* (Configurable) > /system/sling/monitoring/mbeans - resource type = sling:mbeans > + resource sub tree with all mbeans > An MBean has an object name which has > * a domain > * properties where type and name are very common > The domain is converted into a sub path and the properties are converted to a > resource name. For example: _org.apache.sling:name=test,type=hello_ creates a > resource _org/apache/sling/name=test,type=hello_. The name can be obtained by > calling _ObjectName.getCanonicalKeyPropertyListString()_. The result might > need escaping (for the values and the = character) in order to create valid > resource names. > Each MBean resource has at least: > ||Property name ||Description| > |sling:resourceType|object name of the MBean| > |sling:resourceSuperType| sling:mbean| > |mbean:description|The description of the MBean (optional)| > |mbean:className|MBean class name| > |mbean:objectName|MBean object name| > |mbean properties|separate property for each property of the object name| > And a child resource named _mbean:attributes_ if the MBean has attributes. > For each attribute a child resource of _mbean:attributes_ is created where > the name of the resource is the name of the attribute and: > ||Property name ||Description| > |sling:resourceType|Type of the attribute| > |sling:resourceSuperType| sling:mbeanattribute| > |mbean:description|The description of the attribute (optional)| > |mbean:value|String representation of the value or a string array for multi > values| -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-3018) Add an inventory printer which dumps a resource tree into json
[ https://issues.apache.org/jira/browse/SLING-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3018: Fix Version/s: Resource Inventory 0.5.0 > Add an inventory printer which dumps a resource tree into json > -- > > Key: SLING-3018 > URL: https://issues.apache.org/jira/browse/SLING-3018 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Inventory 0.5.0 > > > An inventory printer could be configured with a path in the repository and > dumps this path into the configuration zip created by the inventory module. > This could, e.g. be used to dump the whole jmx tree created by the jmx > provider -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2999: Fix Version/s: JMX Resource Provider 0.5.0 > JMX Resource Provider > - > > Key: SLING-2999 > URL: https://issues.apache.org/jira/browse/SLING-2999 > Project: Sling > Issue Type: New Feature >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JMX Resource Provider 0.5.0 > > > For easier rendering of JMX mbeans within Sling, a special resource provider > should make the JMX information available at > */system/sling/monitoring/mbeans* (Configurable) > /system/sling/monitoring/mbeans - resource type = sling:mbeans > + resource sub tree with all mbeans > An MBean has an object name which has > * a domain > * properties where type and name are very common > The domain is converted into a sub path and the properties are converted to a > resource name. For example: _org.apache.sling:name=test,type=hello_ creates a > resource _org/apache/sling/name=test,type=hello_. The name can be obtained by > calling _ObjectName.getCanonicalKeyPropertyListString()_. The result might > need escaping (for the values and the = character) in order to create valid > resource names. > Each MBean resource has at least: > ||Property name ||Description| > |sling:resourceType|object name of the MBean| > |sling:resourceSuperType| sling:mbean| > |mbean:description|The description of the MBean (optional)| > |mbean:className|MBean class name| > |mbean:objectName|MBean object name| > |mbean properties|separate property for each property of the object name| > And a child resource named _mbean:attributes_ if the MBean has attributes. > For each attribute a child resource of _mbean:attributes_ is created where > the name of the resource is the name of the attribute and: > ||Property name ||Description| > |sling:resourceType|Type of the attribute| > |sling:resourceSuperType| sling:mbeanattribute| > |mbean:description|The description of the attribute (optional)| > |mbean:value|String representation of the value or a string array for multi > values| -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (SLING-3018) Add an inventory printer which dumps a resource tree into json
[ https://issues.apache.org/jira/browse/SLING-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3018. --- > Add an inventory printer which dumps a resource tree into json > -- > > Key: SLING-3018 > URL: https://issues.apache.org/jira/browse/SLING-3018 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Resource Inventory 0.5.0 > > > An inventory printer could be configured with a path in the repository and > dumps this path into the configuration zip created by the inventory module. > This could, e.g. be used to dump the whole jmx tree created by the jmx > provider -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3150) Error handler does not get original exception
Carsten Ziegeler created SLING-3150:
---
Summary: Error handler does not get original exception
Key: SLING-3150
URL: https://issues.apache.org/jira/browse/SLING-3150
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.2.8
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: Engine 2.2.10
The sling documentation [1] indicates for uncaught exceptions the java simple
name of the Throwable class is used to find the error handler. However, Sling
request processor is type casting any exception into SlingException & hence the
requested error handler is not caught.
Steps to reproduce:
*Create file Exception.jsp & FileNotFoundException.jsp at
/apps/sling/servlet/errorhandler/
* In jsp throw new FileNotFoundException("Really does not exists");
*The handler calls Exception.jsp
*Now create SlingException.jsp & Now for all exceptions this handler get
called.
[1]
http://sling.apache.org/documentation/the-sling-engine/errorhandling.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (SLING-3150) Error handler does not get original exception
[
https://issues.apache.org/jira/browse/SLING-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3150.
-
Resolution: Fixed
Fixed by unwrapping the exception for as long as it is a SlingException
> Error handler does not get original exception
> -
>
> Key: SLING-3150
> URL: https://issues.apache.org/jira/browse/SLING-3150
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.2.8
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Engine 2.2.10
>
>
> The sling documentation [1] indicates for uncaught exceptions the java
> simple name of the Throwable class is used to find the error handler.
> However, Sling request processor is type casting any exception into
> SlingException & hence the requested error handler is not caught.
> Steps to reproduce:
> *Create file Exception.jsp & FileNotFoundException.jsp at
> /apps/sling/servlet/errorhandler/
> * In jsp throw new FileNotFoundException("Really does not exists");
> *The handler calls Exception.jsp
> *Now create SlingException.jsp & Now for all exceptions this handler get
> called.
> [1]
> http://sling.apache.org/documentation/the-sling-engine/errorhandling.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (SLING-2212) Implement Servlet API 3.0
[ https://issues.apache.org/jira/browse/SLING-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2212: Fix Version/s: (was: Engine 2.2.10) > Implement Servlet API 3.0 > - > > Key: SLING-2212 > URL: https://issues.apache.org/jira/browse/SLING-2212 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.2.6 >Reporter: Aleksander Bandelj > Attachments: servlet30.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > New versions of Pax Web, Equinox Web, Grizzly and other OSGI web servers will > use version 3.0 of Servlet API. Sling Engine implementing only 2.5 will not > run in these. Since Sling Engine implements API interfaces (ServletContext > notably), it will have to implement new API methods and tighten some existing > type signatures. Change is supposed to be backward-compatible (Sling Engine > implementing 3.0 API can be used with 2.5 API as well). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3139) Provide a way to schedule jobs
[ https://issues.apache.org/jira/browse/SLING-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789190#comment-13789190 ] Carsten Ziegeler commented on SLING-3139: - I've added a first api to the JobManager to create scheduled jobs, to query information about scheduled jobs and unschedule them In addition I've added a method to stop a job, a job executor implementation can check periodically the context if it has been stopped and act accordingly. Not sure if we need a maintenance queue as an ordered queue should do the trick as well > Provide a way to schedule jobs > -- > > Key: SLING-3139 > URL: https://issues.apache.org/jira/browse/SLING-3139 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Event 3.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.2.2 > > > The current way of scheduling jobs is not very user friendly: it requires to > send an event via event admin. We should add a java api to create scheduled > job creation. > In addition, we could add a new queue type: maintenance queue which is an > order queue with the difference of running jobs exactly at the point of time > when they are created. So a scheduled maintenance job is executed exactly at > the scheduled time - unless another job is currently running. > Apart from starting such jobs, stopping a job would be another nice addition -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3138) Add fluent api to create new jobs
[ https://issues.apache.org/jira/browse/SLING-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3138. - Resolution: Fixed I've added a fluent api to create/add new jobs including scheduled jobs > Add fluent api to create new jobs > - > > Key: SLING-3138 > URL: https://issues.apache.org/jira/browse/SLING-3138 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Event 3.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.2.2 > > > With the addition of new features, a fluent api (builder approach) would be > easier to use than adding N methods getting all the different possibilities > of arguments -- 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=13789192#comment-13789192 ] Carsten Ziegeler commented on SLING-3028: - The implementation should be feature complete by now (haven't tested everything yet). Would be great to get some feedback on the api / usage. > 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.2.2 > > 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] [Commented] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790226#comment-13790226 ] Carsten Ziegeler commented on SLING-3157: - I think we don't need anything here, look at our Adobe projects where we have run mode dependent bundles and configurations and this is using plain Sling launchpad/launchpad plugin > Launchpad bootstrap: prepare bundles for launchpad installer > > > Key: SLING-3157 > URL: https://issues.apache.org/jira/browse/SLING-3157 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > > Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap > code to copy the runmode-dependent bundles to where the launchpad installer > expects to find them. > Currently, bundles found in the launchpad jar under paths like > resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the > bootstrap installer, we might just need to copy those to the right filesystem > folder. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790229#comment-13790229 ] Carsten Ziegeler commented on SLING-3156: - We don't need to implement this, simply don't use the launchpad installer for these bundles and delegate them to the OSGi installer. This is just a tweak of configuration (we use this within Adobe) and everything works ootb > Add bundles support to Launchpad installer > -- > > Key: SLING-3156 > URL: https://issues.apache.org/jira/browse/SLING-3156 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Installer 1.2.0 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > The launchpad installer currently supports only configurations, but for > SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790230#comment-13790230 ] Carsten Ziegeler commented on SLING-3156: - Otherwise we would duplicate stuff already in the OSGi installer which is not worth the effort > Add bundles support to Launchpad installer > -- > > Key: SLING-3156 > URL: https://issues.apache.org/jira/browse/SLING-3156 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Installer 1.2.0 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > The launchpad installer currently supports only configurations, but for > SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790233#comment-13790233 ] Carsten Ziegeler commented on SLING-3156: - The startup bundles (OSGi installer, launchpad installer and one or two more) need to be specified with: in the bundle list - these bundles are the once which can't be run mode dependent. All bundles in real start levels including the default can use a run mode configuration in the bundle list. and then the maven launchpad plugin needs to be configured with install bundles Et voila > Add bundles support to Launchpad installer > -- > > Key: SLING-3156 > URL: https://issues.apache.org/jira/browse/SLING-3156 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Installer 1.2.0 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > The launchpad installer currently supports only configurations, but for > SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-1605) Update documentation
[ https://issues.apache.org/jira/browse/SLING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1605: Fix Version/s: (was: Launchpad Base 2.5.2) Launchpad Base 2.5.4 > Update documentation > > > Key: SLING-1605 > URL: https://issues.apache.org/jira/browse/SLING-1605 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Carsten Ziegeler > Fix For: Launchpad Base 2.5.4 > > > When releasing version 2.1.0 and 2.2.0 we left some tasks open to be > documented: > SLING-1157 > SLING-922 > SLING-1200 > SLING-1189 > SLING-1443 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-2757) Support Java 8 as a platform
[ https://issues.apache.org/jira/browse/SLING-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2757: Fix Version/s: (was: Launchpad Base 2.5.2) Launchpad Base 2.5.4 > Support Java 8 as a platform > > > Key: SLING-2757 > URL: https://issues.apache.org/jira/browse/SLING-2757 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.4.0 >Reporter: Felix Meschberger > Fix For: Launchpad Base 2.5.4 > > > The Sling launchpad currently has Java platform definitions for Java 5, 6, > and 7 but is lacking them for Java 8. As a consequence the framework fails to > start on Java 8 platforms with exceptions such as: > 26.11.2012 18:13:10.171 *ERROR* [main] ERROR: Error parsing system bundle > export statement: org.osgi.framework; version=1.6, > org.osgi.framework.hooks.bundle; version=1.0, > org.osgi.framework.hooks.resolver; version=1.0, > org.osgi.framework.hooks.service; version=1.1, > org.osgi.framework.hooks.weaving; version=1.0, org.osgi.framework.launch; > version=1.0, org.osgi.framework.startlevel; version=1.0, > org.osgi.framework.wiring; version=1.0, org.osgi.service.packageadmin; > version=1.2, org.osgi.service.startlevel; version=1.1, org.osgi.service.url; > version=1.0, org.osgi.util.tracker;version="1.5", > org.apache.sling.launchpad.api;version=1.1.0, > (org.osgi.framework.BundleException: Exported package names cannot be zero > length.) > org.osgi.framework.BundleException: Exported package names cannot be zero > length. > at > org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729) > at > org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:191) > at > org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:221) > at org.apache.felix.framework.Felix.(Felix.java:374) > at > org.apache.sling.launchpad.base.impl.SlingFelix.(SlingFelix.java:45) > at > org.apache.sling.launchpad.base.impl.Sling.createFramework(Sling.java:343) > at org.apache.sling.launchpad.base.impl.Sling.(Sling.java:212) > at > org.apache.sling.launchpad.base.app.MainDelegate$1.(MainDelegate.java:183) > at > org.apache.sling.launchpad.base.app.MainDelegate.start(MainDelegate.java:183) > at org.apache.sling.launchpad.app.Main.doStart(Main.java:386) > at org.apache.sling.launchpad.app.Main.doStart(Main.java:322) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3158) Warning "Property scheduler.runOn ignored for schedule" when no property is set
Carsten Ziegeler created SLING-3158: --- Summary: Warning "Property scheduler.runOn ignored for schedule" when no property is set Key: SLING-3158 URL: https://issues.apache.org/jira/browse/SLING-3158 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Scheduler 2.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Scheduler 2.4.2 When no runOn property is set for a whiteboard scheduler, the warning Property scheduler.runOn ignored for schedule is put out - in this case no warning should be logged as a missing property is fine -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3158) Warning "Property scheduler.runOn ignored for schedule" when no property is set
[ https://issues.apache.org/jira/browse/SLING-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3158. - Resolution: Fixed > Warning "Property scheduler.runOn ignored for schedule" when no property is > set > --- > > Key: SLING-3158 > URL: https://issues.apache.org/jira/browse/SLING-3158 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Scheduler 2.4.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Scheduler 2.4.2 > > > When no runOn property is set for a whiteboard scheduler, the warning > Property scheduler.runOn ignored for schedule is put out - in this case no > warning should be logged as a missing property is fine -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3019) Provide a mechanism to install a bundle based on a directory
[
https://issues.apache.org/jira/browse/SLING-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791365#comment-13791365
]
Carsten Ziegeler commented on SLING-3019:
-
Sure, we could upload the whole jar, but this requires more work to do in
Eclipse - instead of just doing a simple ping to the server.
I believe that in the local case, the current mechanism is a little bit faster
(we could even improve and create the jar just in memory).
The alternative would be to post against the web console and let the web
console do the stuff (install or update, refresh packages etc.) - this would be
the same as the maven sling plugin does ootb
> Provide a mechanism to install a bundle based on a directory
>
>
> Key: SLING-3019
> URL: https://issues.apache.org/jira/browse/SLING-3019
> Project: Sling
> Issue Type: New Feature
> Components: IDE
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>
> With an IDE integration and incremental builds, it would be great to have a
> mechanism to install/update a bundle based on the output directory of a
> project.
> I'll start with a prototype of a bundle which receives post requests
> containing the path of a local directory. The servlet will then either
> install or update the bundle from that directory
> For this to work, the scr descriptor files of a project should go into a
> bundle. So configure the scr plugin like this:
>
> org.apache.felix
> maven-scr-plugin
>
>
> ${project.build.directory}/classes
>
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-3019) Provide a mechanism to install a bundle based on a directory
[
https://issues.apache.org/jira/browse/SLING-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791403#comment-13791403
]
Carsten Ziegeler commented on SLING-3019:
-
Yes, I think we should go the full way and enhance the current install bundle
to also take a jar via post and install it - so we won't rely on any
additional stuff being there (like the web console etc) and the only
difference between those two mechanisms would be that the local case first
creates the jar and performs the action while the remote gets the jar and
performs the exact same action.
> Provide a mechanism to install a bundle based on a directory
>
>
> Key: SLING-3019
> URL: https://issues.apache.org/jira/browse/SLING-3019
> Project: Sling
> Issue Type: New Feature
> Components: IDE
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>
> With an IDE integration and incremental builds, it would be great to have a
> mechanism to install/update a bundle based on the output directory of a
> project.
> I'll start with a prototype of a bundle which receives post requests
> containing the path of a local directory. The servlet will then either
> install or update the bundle from that directory
> For this to work, the scr descriptor files of a project should go into a
> bundle. So configure the scr plugin like this:
>
> org.apache.felix
> maven-scr-plugin
>
>
> ${project.build.directory}/classes
>
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (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:all-tabpanel ] Carsten Ziegeler resolved SLING-3028. - Resolution: Fixed > 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] [Resolved] (SLING-3139) Provide a way to schedule jobs
[ https://issues.apache.org/jira/browse/SLING-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3139. - Resolution: Fixed > Provide a way to schedule jobs > -- > > Key: SLING-3139 > URL: https://issues.apache.org/jira/browse/SLING-3139 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Event 3.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.3.0 > > > The current way of scheduling jobs is not very user friendly: it requires to > send an event via event admin. We should add a java api to create scheduled > job creation. > In addition, we could add a new queue type: maintenance queue which is an > order queue with the difference of running jobs exactly at the point of time > when they are created. So a scheduled maintenance job is executed exactly at > the scheduled time - unless another job is currently running. > Apart from starting such jobs, stopping a job would be another nice addition -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3041) Mark job as failed if async job consumer disappears
[ https://issues.apache.org/jira/browse/SLING-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3041. - Resolution: Fixed > Mark job as failed if async job consumer disappears > --- > > Key: SLING-3041 > URL: https://issues.apache.org/jira/browse/SLING-3041 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Event 3.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.3.0 > > > If a job consumer is processing events async and goes down while doing so, > the jobs should be marked as failed. Otherwise the queue keeps these jobs in > the async state -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3160) Creating ResourceResolverFactory as ServiceFactory leads to multiple MapEntries creation
[ https://issues.apache.org/jira/browse/SLING-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792646#comment-13792646 ] Carsten Ziegeler commented on SLING-3160: - I've applied a potential fix in rev 1531301 which splits the resource resolver factory implementation into two classes: a common singleton instance shard by all instances of the factory > Creating ResourceResolverFactory as ServiceFactory leads to multiple > MapEntries creation > > > Key: SLING-3160 > URL: https://issues.apache.org/jira/browse/SLING-3160 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.1.0 >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler > Attachments: threaddump.txt > > > With SLING-2944 ResourceResolverFactory is now being created as > ServiceFactory leading to multiple instances being created for each consuming > bundle. > Each ResourceResolverFactoryImpl instance keeps a reference to MapEntries > which internally spawns a thread to keep the entries upto date. Due to > creation of multiple instances there are multiple "MapEntries Update" thread > getting created which is probably not desirable. > I think all the ResourceResolverFactoryImpl must *share* a singleton state > where only single instance of MapEntries gets created -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (SLING-3160) Creating ResourceResolverFactory as ServiceFactory leads to multiple MapEntries creation
[ https://issues.apache.org/jira/browse/SLING-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3160: --- Assignee: Carsten Ziegeler > Creating ResourceResolverFactory as ServiceFactory leads to multiple > MapEntries creation > > > Key: SLING-3160 > URL: https://issues.apache.org/jira/browse/SLING-3160 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.1.0 >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler > Attachments: threaddump.txt > > > With SLING-2944 ResourceResolverFactory is now being created as > ServiceFactory leading to multiple instances being created for each consuming > bundle. > Each ResourceResolverFactoryImpl instance keeps a reference to MapEntries > which internally spawns a thread to keep the entries upto date. Due to > creation of multiple instances there are multiple "MapEntries Update" thread > getting created which is probably not desirable. > I think all the ResourceResolverFactoryImpl must *share* a singleton state > where only single instance of MapEntries gets created -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3166) Job Scheduling Possibilities
Carsten Ziegeler created SLING-3166: --- Summary: 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] [Created] (SLING-3167) Job Logging
Carsten Ziegeler created SLING-3167: --- Summary: 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] [Created] (SLING-3168) Deprecating JobUtil class?
Carsten Ziegeler created SLING-3168: --- Summary: 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] [Created] (SLING-3169) Naming of Job related enumerations
Carsten Ziegeler created SLING-3169: --- Summary: 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-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 commented on SLING-3028: - 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 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 > 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-3170) Complex Job Result Structures
Carsten Ziegeler created SLING-3170: --- Summary: 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-3166) Job Scheduling Possibilities
[ https://issues.apache.org/jira/browse/SLING-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793622#comment-13793622 ] Carsten Ziegeler commented on SLING-3166: - [~sseif...@pro-vision.de] Agreed, right now the api is limiting the possibilities (with no good reason), so I can imagine we add monthly and yearly, allow a single schedule to be composed if different types and in addition also allow to define a schedule based on cron expressions. WDYT? > 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-3167) Job Logging
[ https://issues.apache.org/jira/browse/SLING-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793623#comment-13793623 ] Carsten Ziegeler commented on SLING-3167: - The idea is that all information about a job is stored as information of a single resource, and making the usage of the whole log easy (string array). I can see that this might become a performance issue if a job heavily uses the log as each entry is directly written to the repository. We could do batch writes for this if necessary. There are already resource changed events when the log is updated, so these could be used by a listener directly (filter would be resource type and the property holding the log entries). [~sseif...@pro-vision.de] Do you have an alternative in mind? > 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-3168) Deprecating JobUtil class?
[ https://issues.apache.org/jira/browse/SLING-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793627#comment-13793627 ] Carsten Ziegeler commented on SLING-3168: - Ok, unfortunately the damage is already done as we released the Job interface with the last version. However, I suggest to add JobPriority as an enum to the job interface, deprecate the old getJobPriority method and add a new getPriority() method returning the new enum. Then move all constants wrt notification into a separate constants class and deprecate the whole JobUtil class [~sseif...@pro-vision.de] WDYT? > 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-3169) Naming of Job related enumerations
[ https://issues.apache.org/jira/browse/SLING-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793629#comment-13793629 ] Carsten Ziegeler commented on SLING-3169: - I agree this is a little bit tricky (and confusing) - let's start with the obvious one, Job.JobType. I agree this is a state and I choose this name because there is JobState in the consumer package :) Now JobState in the consumer package is more a result, but not quiet. One could argue that the result of a job is whatever it produced, so the result of an image rendering job is the newly rendered image. Subtle differences I agree, so what about renaming JobStatus to JobExecutionResult? (to distinguish it from a job result) We could think about merging JobState and Job.JobType - however there is the problem with FAILED vs QUEUED, QUEUED would mean it has never been executed and is in the queue, FAILED means it has been executed but processing failed and the job is now in the queue. [~sseif...@pro-vision.de] WDYT? > 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-3170) Complex Job Result Structures
[
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
[~sseif...@pro-vision.de] 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)
[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] [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-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] [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)
[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] [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)
[jira] [Reopened] (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 reopened SLING-3171: - > 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-3171) Deprecate job name handling
[ https://issues.apache.org/jira/browse/SLING-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794947#comment-13794947 ] Carsten Ziegeler commented on SLING-3171: - [~sseif...@pro-vision.de] What about definining two constants for such properties in the Job class? A client starting the job can set them (or not) > 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)
