[jira] [Created] (SLING-2994) Update to latest SCR plugin
Carsten Ziegeler created SLING-2994: --- Summary: Update to latest SCR plugin Key: SLING-2994 URL: https://issues.apache.org/jira/browse/SLING-2994 Project: Sling Issue Type: Improvement Components: General Affects Versions: Parent 17 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Parent 18 A new version of the SCR plugin is out with some bug fixes, we should update to that version -- 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-2994) Update to latest SCR plugin
[ https://issues.apache.org/jira/browse/SLING-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2994. - Resolution: Fixed Updated to version 1.14.0 and annotations version 1.9.6 in rev 1510862 > Update to latest SCR plugin > --- > > Key: SLING-2994 > URL: https://issues.apache.org/jira/browse/SLING-2994 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Parent 17 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Parent 18 > > > A new version of the SCR plugin is out with some bug fixes, we should update > to that version -- 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-2995) Update Maven Plugins to latest version
Carsten Ziegeler created SLING-2995: --- Summary: Update Maven Plugins to latest version Key: SLING-2995 URL: https://issues.apache.org/jira/browse/SLING-2995 Project: Sling Issue Type: Improvement Components: General Affects Versions: Parent 17 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Parent 18 We could update the following plugins: [INFO] maven-changes-plugin . 2.8 -> 2.9 [INFO] maven-dependency-plugin .. 2.6 -> 2.8 [INFO] maven-javadoc-plugin ... 2.9 -> 2.9.1 [INFO] maven-surefire-report-plugin . 2.12.4 -> 2.15 [INFO] maven-war-plugin . 2.3 -> 2.4 [INFO] org.apache.rat:apache-rat-plugin . 0.8 -> 0.9 [INFO] org.codehaus.cargo:cargo-maven2-plugin ... 1.3.1 -> 1.4.3 [INFO] org.codehaus.mojo:build-helper-maven-plugin .. 1.7 -> 1.8 -- 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-2995) Update Maven Plugins to latest version
[ https://issues.apache.org/jira/browse/SLING-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2995. - Resolution: Fixed Updated in rev 1510863 > Update Maven Plugins to latest version > -- > > Key: SLING-2995 > URL: https://issues.apache.org/jira/browse/SLING-2995 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Parent 17 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Parent 18 > > > We could update the following plugins: > [INFO] maven-changes-plugin . 2.8 -> 2.9 > [INFO] maven-dependency-plugin .. 2.6 -> 2.8 > [INFO] maven-javadoc-plugin ... 2.9 -> 2.9.1 > [INFO] maven-surefire-report-plugin . 2.12.4 -> 2.15 > [INFO] maven-war-plugin . 2.3 -> 2.4 > [INFO] org.apache.rat:apache-rat-plugin . 0.8 -> 0.9 > [INFO] org.codehaus.cargo:cargo-maven2-plugin ... 1.3.1 -> 1.4.3 > [INFO] org.codehaus.mojo:build-helper-maven-plugin .. 1.7 -> 1.8 -- 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=13730490#comment-13730490 ] Carsten Ziegeler commented on SLING-2944: - I'm wondering if we shouldn't remove the support for a header in the manifest and simply rely on bundle symbolic name? E.g. if a dev knows that the Sling eventing bundle uses this mechanism to get an admin session (or whatever is configured), the dev can simply use the header entry and use the symbolic name of the eventing bundle as the value, using the same configuration as the Sling eventing bundle. It's try that once a bundle can be deployed, more or less everything is possible, but still just relying on the symbolic name makes this concept a little bit easier, doesn't open the above mentioned door and doesn't make it's usage more difficult. > 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] [Closed] (SLING-2988) Support primitive types for ValueMap.get()
[ https://issues.apache.org/jira/browse/SLING-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-2988. --- > Support primitive types for ValueMap.get() > -- > > Key: SLING-2988 > URL: https://issues.apache.org/jira/browse/SLING-2988 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.1.0 >Reporter: Konrad Windszus > > Currently the call for ValueMap.get(, boolean.class) returns null while > ValueMap.get(, Boolean.class) returns true for a JCR property with type > String having the value "true". > Please either throw an exception if primitive classes are given as second > argument or support them as well. Just returning null is confusing, because > it is not obvious from the Javadoc that no JCR attribute can be converted > into a primitive. > Currently the Javadoc states that this call either returns null or the value. > Assigning null to a primitive would lead to an NPE. -- 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-2988) Support primitive types for ValueMap.get()
[ https://issues.apache.org/jira/browse/SLING-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2988. - Resolution: Won't Fix > Support primitive types for ValueMap.get() > -- > > Key: SLING-2988 > URL: https://issues.apache.org/jira/browse/SLING-2988 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.1.0 >Reporter: Konrad Windszus > > Currently the call for ValueMap.get(, boolean.class) returns null while > ValueMap.get(, Boolean.class) returns true for a JCR property with type > String having the value "true". > Please either throw an exception if primitive classes are given as second > argument or support them as well. Just returning null is confusing, because > it is not obvious from the Javadoc that no JCR attribute can be converted > into a primitive. > Currently the Javadoc states that this call either returns null or the value. > Assigning null to a primitive would lead to an NPE. -- 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-2988) Support primitive types for ValueMap.get()
[ https://issues.apache.org/jira/browse/SLING-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730645#comment-13730645 ] Carsten Ziegeler commented on SLING-2988: - We discussed this in SLING-2712, throwing an IAE would be a contract change > Support primitive types for ValueMap.get() > -- > > Key: SLING-2988 > URL: https://issues.apache.org/jira/browse/SLING-2988 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.1.0 >Reporter: Konrad Windszus > > Currently the call for ValueMap.get(, boolean.class) returns null while > ValueMap.get(, Boolean.class) returns true for a JCR property with type > String having the value "true". > Please either throw an exception if primitive classes are given as second > argument or support them as well. Just returning null is confusing, because > it is not obvious from the Javadoc that no JCR attribute can be converted > into a primitive. > Currently the Javadoc states that this call either returns null or the value. > Assigning null to a primitive would lead to an NPE. -- 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-2996) use project.* properties instead of pom.* properties
[ https://issues.apache.org/jira/browse/SLING-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-2996: --- Assignee: Carsten Ziegeler > use project.* properties instead of pom.* properties > > > Key: SLING-2996 > URL: https://issues.apache.org/jira/browse/SLING-2996 > Project: Sling > Issue Type: Improvement >Reporter: Oliver Lietz >Assignee: Carsten Ziegeler >Priority: Trivial > Attachments: SLING-2996.patch > > > pom.* properties are deprecated -- 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-2996) use project.* properties instead of pom.* properties
[ https://issues.apache.org/jira/browse/SLING-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2996. - Resolution: Fixed Thanks for your patch, I've applied it > use project.* properties instead of pom.* properties > > > Key: SLING-2996 > URL: https://issues.apache.org/jira/browse/SLING-2996 > Project: Sling > Issue Type: Improvement >Reporter: Oliver Lietz >Assignee: Carsten Ziegeler >Priority: Trivial > Attachments: SLING-2996.patch > > > pom.* properties are deprecated -- 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-2997) ResourceAccessSecurityImpl uses @Override for interface methods, but does not declare compiler version as Java 6
[ https://issues.apache.org/jira/browse/SLING-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730855#comment-13730855 ] Carsten Ziegeler commented on SLING-2997: - Do we really want to require java 6 just because of an annotation? I think we should rather not use the annotation and stick to java 5 unless there are good reasons > ResourceAccessSecurityImpl uses @Override for interface methods, but does not > declare compiler version as Java 6 > > > Key: SLING-2997 > URL: https://issues.apache.org/jira/browse/SLING-2997 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Minor > Fix For: Resource Access Gate 1.0.0 > > > The class > org.apache.sling.resourceaccesssecurity.impl.ResourceAccessSecurityImpl uses > @Override to indicate interface implementation. This, however, is only valid > on Java 6 and above. -- 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-2997) ResourceAccessSecurityImpl uses @Override for interface methods, but does not declare compiler version as Java 6
[ https://issues.apache.org/jira/browse/SLING-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730884#comment-13730884 ] Carsten Ziegeler commented on SLING-2997: - So could we simply set source fixed to 1.6 (for now), and by default target is 1.5 and can be changed to 1.6? > ResourceAccessSecurityImpl uses @Override for interface methods, but does not > declare compiler version as Java 6 > > > Key: SLING-2997 > URL: https://issues.apache.org/jira/browse/SLING-2997 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Minor > Fix For: Resource Access Gate 1.0.0 > > > The class > org.apache.sling.resourceaccesssecurity.impl.ResourceAccessSecurityImpl uses > @Override to indicate interface implementation. This, however, is only valid > on Java 6 and above. -- 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-2999) JMX Resource Provider
Carsten Ziegeler created SLING-2999: --- Summary: 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 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 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-2999) JMX Resource Provider
[
https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731771#comment-13731771
]
Carsten Ziegeler commented on SLING-2999:
-
Yes, the namespace is there do avoid collision with potentially existing
properties. The properties are already contained in the object name, so we
could go without them, thus avoiding the use of a namespace. I don't have a
concrete use case for needing the object name properties as properties of the
mbean resource, but if we need them later on, we would need some separation.
The only alternative I see is to prefix the property names which is kind of a
namespace but not in the jcr sense, like property-{name}
> 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
>
> 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 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-2972) Improve processing performance if job is processed locally
[ https://issues.apache.org/jira/browse/SLING-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2972. - Resolution: Fixed Direct processing of local events has been added in rev 1504035 > Improve processing performance if job is processed locally > -- > > Key: SLING-2972 > URL: https://issues.apache.org/jira/browse/SLING-2972 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.2.0 > > > Currently the job processing is completely observation based: even if a job > is added locally and also processed locally, this is not immediately put into > the queue. This creates an unnecessary delay between adding a job and > processing it which can easily be avoided by directly putting the job into > the queue. -- 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-2971) BackgroundLoader thread dies for invalid paths
[ https://issues.apache.org/jira/browse/SLING-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2971. - Resolution: Fixed I think we can close this now - as the underlying problem is due to Oak > BackgroundLoader thread dies for invalid paths > -- > > Key: SLING-2971 > URL: https://issues.apache.org/jira/browse/SLING-2971 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: Extensions Event 3.2.0 > > Attachments: SLING-2971.patch > > > BackgroundLoader thread which is used by JobManager to load and process job > asynchronously dies if any submitted job path is found to be invalid. > --- > 14.07.2013 11:14:22.599 *ERROR* [Apache Sling Job Background Loader] > org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception > in Thread Thread[Apache Sling Job Background Loader,5,main] > java.lang.NullPointerException > at > org.apache.sling.event.impl.jobs.BackgroundLoader.run(BackgroundLoader.java:219) > at java.lang.Thread.run(Thread.java:662) > --- > It might not happen in actual scenario always but it would be better if the > while loop does not end for such cases -- 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-2950) Disabling the distribution flag takes only effect after bundle restart
[ https://issues.apache.org/jira/browse/SLING-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2950. - Resolution: Fixed This has been changed in rev 1501098 > Disabling the distribution flag takes only effect after bundle restart > -- > > Key: SLING-2950 > URL: https://issues.apache.org/jira/browse/SLING-2950 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.2.0 > > > If the disable distribution flag is changed, it only has an effect after a > restart of the bundle -- 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-2724) Error handling doesn't respect servlet spec
[ https://issues.apache.org/jira/browse/SLING-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2724. - Resolution: Fixed > Error handling doesn't respect servlet spec > --- > > Key: SLING-2724 > URL: https://issues.apache.org/jira/browse/SLING-2724 > Project: Sling > Issue Type: Bug > Components: Engine, Servlets >Reporter: Antonio Sanso >Assignee: Carsten Ziegeler > Fix For: Servlets Resolver 2.2.6, Engine 2.2.10 > > > If there is some servlet that is sending a 500 error > (response.sendError(500)) and output something after e.g. "All good" (maybe > this is the wrong part...) and a 500.jsp exists, Sling will "shows" both: > - the error page 500.jsp > - and the the extra output (e.g. All good) > This seems to violate the spec: > "These methods [sendError, sendRedirect] will have the side effect of > committing the response, if it has not already been committed, and > terminating it. No further output to the client should be made by the servlet > after these methods are called. If data is written to the response after > these methods are called, the data is ignored." > Integration test showing the issue in [0] > Mailing list thread in [1] > [0] > https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/resolver/errorhandler/ErrorHandlingTest.java > [1] sling.markmail.org/thread/k2t7p5mhi4hgelwb -- 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=13731925#comment-13731925 ] Carsten Ziegeler commented on SLING-2944: - Right - I think the point is to be able to configure this without a specific packaging (bundling) of services - so we rather want to configure this based on a service than on a bundle - as the service might move from one bundle to another. Unfortunately we only get support for the client bundle through a ServiceFactory. On the other hand we can't rely alone on a service identifier (comparable to the PID) as this would be open to the same "attack" as the additional header. So the only thing which is quiet safe to use is the bundle symbolic name as we have it right now. I think it's better to be a little bit safer with the burden of potentially more configuration if sub services spread across bundles. So I would remove the header > 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-2788) Sling running using Apache OAK
[ https://issues.apache.org/jira/browse/SLING-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733425#comment-13733425 ] Carsten Ziegeler commented on SLING-2788: - What's the current status here? I guess this project needs some updates esp to a current Oak version? > Sling running using Apache OAK > -- > > Key: SLING-2788 > URL: https://issues.apache.org/jira/browse/SLING-2788 > Project: Sling > Issue Type: Wish > Components: General >Reporter: Antonio Sanso >Assignee: Ian Boston > > It would be nice to have a runMode of Sling that runs on top of Apache OAK > [0] > [0] http://jackrabbit.apache.org/oak/ -- 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-3002) Make the Mongo Resource Provider easier to subclass
[ https://issues.apache.org/jira/browse/SLING-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3002: --- Assignee: Carsten Ziegeler > Make the Mongo Resource Provider easier to subclass > --- > > Key: SLING-3002 > URL: https://issues.apache.org/jira/browse/SLING-3002 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: dan mcweeney >Assignee: Carsten Ziegeler > Attachments: enableSubClass.patch > > > The Mongo Provider isn't the easiest thing to extend and specialize. Most of > the methods are marked as private and once those are loosened up other issues > came up, like changing the field that ID is stored in etc. Attached is a > patch to help make subclassing possible. -- 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-3002) Make the Mongo Resource Provider easier to subclass
[ https://issues.apache.org/jira/browse/SLING-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3002. - Resolution: Fixed Fix Version/s: Mongo Resource Provider 1.0.0 Thanks for your patch, Dan - i've applied it. I'm just curious, what are the reasons to subclass the provider? Is this something we could solve in a general way ootb? > Make the Mongo Resource Provider easier to subclass > --- > > Key: SLING-3002 > URL: https://issues.apache.org/jira/browse/SLING-3002 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: dan mcweeney >Assignee: Carsten Ziegeler > Fix For: Mongo Resource Provider 1.0.0 > > Attachments: enableSubClass.patch > > > The Mongo Provider isn't the easiest thing to extend and specialize. Most of > the methods are marked as private and once those are loosened up other issues > came up, like changing the field that ID is stored in etc. Attached is a > patch to help make subclassing possible. -- 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-3001) Support wildcard (was: regular expressions) in IP whitelist for discovery/topology connectors
[ https://issues.apache.org/jira/browse/SLING-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3001: Fix Version/s: (was: Discovery Impl 1.0.0) Discovery Impl 1.0.2 > Support wildcard (was: regular expressions) in IP whitelist for > discovery/topology connectors > - > > Key: SLING-3001 > URL: https://issues.apache.org/jira/browse/SLING-3001 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: Discovery Impl 1.0.2 > > > Currently the IP white listing feature of discovery.impl requires explicit IP > addresses or fully qualified hostnames. I more complex setups it can be > useful to define regular expressions, eg for hostnames, eg *.mydomain.com. -- 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-3003) Add XML serializer
Carsten Ziegeler created SLING-3003: --- Summary: Add XML serializer Key: SLING-3003 URL: https://issues.apache.org/jira/browse/SLING-3003 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Rewriter 1.0.6 We should add an xml serializer to get xml output from the pipeline -- 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-3003) Add XML serializer
[ https://issues.apache.org/jira/browse/SLING-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3003. - Resolution: Fixed Added in rev 1512194 > Add XML serializer > -- > > Key: SLING-3003 > URL: https://issues.apache.org/jira/browse/SLING-3003 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Rewriter 1.0.6 > > > We should add an xml serializer to get xml output from the pipeline -- 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734686#comment-13734686 ] Carsten Ziegeler commented on SLING-2987: - Thanks for the work, Bertrand. For the API, I think there are some things which should be changed as well (we discussed these briefly in the original thread): - we don't need a ResultLog, the result can have a string (array/list) of messages - the result should not be based on the level of a log message, but have a level to be set (so we need an enum for that) - the result should not hold the service, it should be a plain data object - I assume the info props of the HealthCheck are also OSGi service props? - not sure if we need the HealthCheckSelector, it rather looks like an utility method > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734688#comment-13734688 ] Carsten Ziegeler commented on SLING-2987: - For the impl, I think we should separate the api from all the additional stuff currently in core. The only thing implementation wise would be the HealthCheckSelector service if we keep it > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734690#comment-13734690 ] Carsten Ziegeler commented on SLING-2987: - I think we should create a third bundle, which simply registers health check services as JMX beans, to have everything nicely separated > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734695#comment-13734695 ] Carsten Ziegeler commented on SLING-2987: - The log could maybe be part of a scripting api for hcs > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734854#comment-13734854 ] Carsten Ziegeler commented on SLING-2999: - On the other hand, is there a problem with using "mbeans:" ? As this is not a jcr backed resource provider, we don't need to register the namespace in the repository > 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 > > 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 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734873#comment-13734873 ] Carsten Ziegeler commented on SLING-2987: - For the ResultLog: Right now, the caller passed in a result log instance and forces the HC service to call appropriate log messages, finally depending if a message with a specific log level arrived, the result is either ok or fail. I think, when calling the check method of the HC service, this method doesn't take any argument, but just returns a result object - this result object has at least two methods, so something like: - (boolean)success(); (though I would prefer an enum) - (String[]) getMessages(); // can also be a list etc. And that's it - how the HC service does the check and how it determines whether it passes or not is up to the service. I'm not sure if the messages should be structured like a log message in general, I would expect that we have different messages: information messages telling what has been tested, result messages showing and explaining the result, and maybe advice messages suggesting how to fix the problem, what to check etc. But I think this doesn't directly map to typical log levels. Now, for scripted tests, using the log approach might be useful. So you can define a hc scripting api containing the ResultLog class and defining that this is set when a HC script is called and for this case the level of the log messages coming from the script is evaluated like today. > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734904#comment-13734904 ] Carsten Ziegeler commented on SLING-2999: - I've added a stub for the implementation in rev 1512336 > 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 > > 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 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-3007) NPE in JSON Rendering if value map contains a null value
Carsten Ziegeler created SLING-3007: --- Summary: NPE in JSON Rendering if value map contains a null value Key: SLING-3007 URL: https://issues.apache.org/jira/browse/SLING-3007 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Get 2.1.6 If the value map contains a null value for a key, this fails with a NPE during JSON rendering as the ResourceTraversor does not handle this case -- 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-3007) NPE in JSON Rendering if value map contains a null value
[ https://issues.apache.org/jira/browse/SLING-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3007. - Resolution: Fixed Added an extra null check > NPE in JSON Rendering if value map contains a null value > > > Key: SLING-3007 > URL: https://issues.apache.org/jira/browse/SLING-3007 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Servlets Get 2.1.6 > > > If the value map contains a null value for a key, this fails with a NPE > during JSON rendering as the ResourceTraversor does not handle this case -- 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-3008) Render resource type (and super type) if resource can't be adapted to a map in JSON
Carsten Ziegeler created SLING-3008: --- Summary: Render resource type (and super type) if resource can't be adapted to a map in JSON Key: SLING-3008 URL: https://issues.apache.org/jira/browse/SLING-3008 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Servlets Get 2.1.6 If the resource can't be adapted to a (value) map, at least resource type and resource super type (if not null) should be rendered in the json output -- 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-3008) Render resource type (and super type) if resource can't be adapted to a map in JSON
[ https://issues.apache.org/jira/browse/SLING-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3008. - Resolution: Fixed Added the two values to json rendering if the resource can't be adapted to a map > Render resource type (and super type) if resource can't be adapted to a map > in JSON > --- > > Key: SLING-3008 > URL: https://issues.apache.org/jira/browse/SLING-3008 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Servlets Get 2.1.6 > > > If the resource can't be adapted to a (value) map, at least resource type and > resource super type (if not null) should be rendered in the json output -- 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] [Closed] (SLING-2976) Add support for instance name and description
[ https://issues.apache.org/jira/browse/SLING-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-2976. --- > Add support for instance name and description > - > > Key: SLING-2976 > URL: https://issues.apache.org/jira/browse/SLING-2976 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Settings 1.2.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Settings 1.3.0 > > > With the introduction of the topology API, we added support for two framework > properties sling.name and sling.description. Right now, these values need > either be set as system properties or in the sling.properties file. > There are two issues with these: > - we don't have any default values > - they are not changeable at run time -- 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-3012) Create unique id if timed event does not contain one
Carsten Ziegeler created SLING-3012: --- Summary: Create unique id if timed event does not contain one Key: SLING-3012 URL: https://issues.apache.org/jira/browse/SLING-3012 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Extensions Event 3.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 3.2.2 If a timed event does neither contain a job id nor a timed event id, a unique id should be created. Otherwise all timed events without such an id get the same default id, overwriting each other -- 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-3012) Create unique id if timed event does not contain one
[ https://issues.apache.org/jira/browse/SLING-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3012. - Resolution: Fixed Adding a unique id consisting of the instance id and an incremental counter > Create unique id if timed event does not contain one > > > Key: SLING-3012 > URL: https://issues.apache.org/jira/browse/SLING-3012 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Extensions Event 3.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 3.2.2 > > > If a timed event does neither contain a job id nor a timed event id, a unique > id should be created. Otherwise all timed events without such an id get the > same default id, overwriting each other -- 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-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736872#comment-13736872 ] Carsten Ziegeler commented on SLING-2999: - Enhanced the implementation to create a tree based on the domain name > 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 > > 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 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] [Comment Edited] (SLING-2999) JMX Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736872#comment-13736872 ] Carsten Ziegeler edited comment on SLING-2999 at 8/12/13 1:51 PM: -- Enhanced the implementation to create a tree based on the domain name. Rev 1513140 was (Author: cziegeler): Enhanced the implementation to create a tree based on the domain name > 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 > > 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 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-2999) JMX Resource Provider
[
https://issues.apache.org/jira/browse/SLING-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736967#comment-13736967
]
Carsten Ziegeler commented on SLING-2999:
-
Rev 1513172 : I've changed the path creation to
* {Domain}/{type property}/{name property}{all other props}
A good object name should have a type property, and maybe a name property but
no others - therefore I think this path resolution makes it much easier to get
a resource based on the object name
> 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
>
> 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 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-3018) Add an inventory printer which dumps a resource tree into json
Carsten Ziegeler created SLING-3018: --- Summary: 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 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 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-3019) Provide a mechanism to install a bundle based on a directory
Carsten Ziegeler created SLING-3019:
---
Summary: 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 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-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=13740755#comment-13740755
]
Carsten Ziegeler commented on SLING-3019:
-
Added a first prototype implementation - posting to
/system/sling/tooling/install with the parameter "dir" pointing to a directory,
installs or updates the bundle from there.
> 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 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-3009) [Tooling] support auto-deploy of osgi bundles from eclipse to a running sling launchpad
[ https://issues.apache.org/jira/browse/SLING-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742019#comment-13742019 ] Carsten Ziegeler commented on SLING-3009: - I've added a first implemented for SLING-3019 which could also be used to update a bundle by triggering a special servlet from the IDE once the project has changed and the build directory is updated. > [Tooling] support auto-deploy of osgi bundles from eclipse to a running sling > launchpad > --- > > Key: SLING-3009 > URL: https://issues.apache.org/jira/browse/SLING-3009 > Project: Sling > Issue Type: New Feature > Components: IDE >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: Sling Eclipse IDE 1.0.0 > > > From Eclipse, for a bundle type maven project, it should be possible to > auto-deploy the built bundle into the configured sling launchpad. Ideally, > but optionally, we'd have hot-code replacement of individual classes of that > bundle. But auto redeploying the entire bundle is fine as a start. > We should look into such tools like Eclipse libra > (http://www.eclipse.org/libra/) or Spring-Loaded > (https://github.com/SpringSource/spring-loaded) for help on redeploy/hotcode > replacement -- 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-3020) Immutable HealthCheck Results
[ https://issues.apache.org/jira/browse/SLING-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742020#comment-13742020 ] Carsten Ziegeler commented on SLING-3020: - I think it would make sense to "lock" the ResultLog instance once it's added to the Result - so the returned object is really immutable > Immutable HealthCheck Results > - > > Key: SLING-3020 > URL: https://issues.apache.org/jira/browse/SLING-3020 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > > As discussed on list, I'll change the Result class to be immutable and allow > for both single-value and log-based results: > Result is immutable. > Result has two constructors, one that takes a Status and a message String and > one that takes a ResultLog, and sets the Result status to > ResultLog.getStatus(). > The ResultLog is a list of messages, each with a Status and a message String. > It's getStatus() method returns the highest Status that was added to it. -- 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-3021) Use service properties for HC meta data and improve JMX registration
Carsten Ziegeler created SLING-3021: --- Summary: Use service properties for HC meta data and improve JMX registration Key: SLING-3021 URL: https://issues.apache.org/jira/browse/SLING-3021 Project: Sling Issue Type: Improvement Reporter: Carsten Ziegeler As discussed in the mailing list, we can simplify the health check api by using service properties for all meta data of a HC. In addition, the jmx registration bridge needs updates on how to handle if two HC services are using the same name for registration Mail threads: http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3CCAKkCf4r89JbsVP_-RQK=r304wbl8gqpzaq4rw3z9sijwbbo...@mail.gmail.com%3E http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3ccakkcf4q79no26va542s_qghof1f1uvsjnyls6as_2xqczre...@mail.gmail.com%3E -- 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-3020) Immutable HealthCheck Results
[ https://issues.apache.org/jira/browse/SLING-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742049#comment-13742049 ] Carsten Ziegeler commented on SLING-3020: - In rev 1514626 I added a copy constructor to result log, and the result log is now copied to an internal log if passed into the Result constructor. This makes the result completely immutable > Immutable HealthCheck Results > - > > Key: SLING-3020 > URL: https://issues.apache.org/jira/browse/SLING-3020 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > > As discussed on list, I'll change the Result class to be immutable and allow > for both single-value and log-based results: > Result is immutable. > Result has two constructors, one that takes a Status and a message String and > one that takes a ResultLog, and sets the Result status to > ResultLog.getStatus(). > The ResultLog is a list of messages, each with a Status and a message String. > It's getStatus() method returns the highest Status that was added to it. -- 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-3021) Use service properties for HC meta data and improve JMX registration
[ https://issues.apache.org/jira/browse/SLING-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13743582#comment-13743582 ] Carsten Ziegeler commented on SLING-3021: - In a first step, I removed the separate constants class, added the properties as service props to the HealthCheck interface and updated all code to use the service ref props instead of the getInfos() method. Rev 1515281 > Use service properties for HC meta data and improve JMX registration > > > Key: SLING-3021 > URL: https://issues.apache.org/jira/browse/SLING-3021 > Project: Sling > Issue Type: Improvement >Reporter: Carsten Ziegeler > > As discussed in the mailing list, we can simplify the health check api by > using service properties for all meta data of a HC. > In addition, the jmx registration bridge needs updates on how to handle if > two HC services are using the same name for registration > Mail threads: > http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3CCAKkCf4r89JbsVP_-RQK=r304wbl8gqpzaq4rw3z9sijwbbo...@mail.gmail.com%3E > http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3ccakkcf4q79no26va542s_qghof1f1uvsjnyls6as_2xqczre...@mail.gmail.com%3E -- 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-3024) Move SimpleConstraintChecker to healthchecks bundle
Carsten Ziegeler created SLING-3024: --- Summary: Move SimpleConstraintChecker to healthchecks bundle Key: SLING-3024 URL: https://issues.apache.org/jira/browse/SLING-3024 Project: Sling Issue Type: Bug Components: Extensions Reporter: Carsten Ziegeler The SimpleConstraintChecker is useful for scripted tests and therefore should be moved into the healthchecks bundle. -- 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-2987) Simplified health check services
[ https://issues.apache.org/jira/browse/SLING-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2987: Fix Version/s: healthcheck-api 1.0.0 > Simplified health check services > > > Key: SLING-2987 > URL: https://issues.apache.org/jira/browse/SLING-2987 > Project: Sling > Issue Type: Improvement > Components: Health Check >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: healthcheck-api 1.0.0 > > Attachments: webconsole-is-back.jpg > > > After some prototyping, the health check tools are ready for a rewrite that > will make them simpler and more OSGi friendly. > The functionality will be similar but with much less code, more focused on > the actual use cases that have emerged during prototyping. > The new API is being discussed on list, > http://markmail.org/thread/i6ib7tgax4cn2sss -- 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-3024) Move SimpleConstraintChecker to healthchecks bundle
[ https://issues.apache.org/jira/browse/SLING-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3024. - Resolution: Fixed Fix Version/s: healthcheck-api 1.0.0 Assignee: Carsten Ziegeler I've movd the class and also removed the dependency to a slf4j impl > 1.6.0, rev 1515292 > Move SimpleConstraintChecker to healthchecks bundle > --- > > Key: SLING-3024 > URL: https://issues.apache.org/jira/browse/SLING-3024 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: healthcheck-api 1.0.0 > > > The SimpleConstraintChecker is useful for scripted tests and therefore should > be moved into the healthchecks bundle. -- 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-3021) Use service properties for HC meta data and improve JMX registration
[ https://issues.apache.org/jira/browse/SLING-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13743739#comment-13743739 ] Carsten Ziegeler commented on SLING-3021: - I rewrote the jmx registration: a health check is now only registered, if it sets the hc.mbean.name property. This value is used for the name property of the object name. All services with such a property are registered in the domain org.apache.sling.healthcheck and have the type property set to HealthCheck. If there is more than one service with the same hc.mbean.name property, the one with highest service ranking is used. Rev 1515349 > Use service properties for HC meta data and improve JMX registration > > > Key: SLING-3021 > URL: https://issues.apache.org/jira/browse/SLING-3021 > Project: Sling > Issue Type: Improvement >Reporter: Carsten Ziegeler > > As discussed in the mailing list, we can simplify the health check api by > using service properties for all meta data of a HC. > In addition, the jmx registration bridge needs updates on how to handle if > two HC services are using the same name for registration > Mail threads: > http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3CCAKkCf4r89JbsVP_-RQK=r304wbl8gqpzaq4rw3z9sijwbbo...@mail.gmail.com%3E > http://mail-archives.us.apache.org/mod_mbox/sling-dev/201308.mbox/%3ccakkcf4q79no26va542s_qghof1f1uvsjnyls6as_2xqczre...@mail.gmail.com%3E -- 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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13745937#comment-13745937
]
Carsten Ziegeler commented on SLING-2779:
-
I'm not sure about the "deletedProperties" part - does this mean you pass in a
defaults map with a set of deleted properies and if the default map contains a
property which is in the deleted set, this one is ignored? Why not simply
removing the properties from the default map then?
For the location I think this makes sense to have it in the api bundle.
I'm not sure about the name, DefaultsValueMap - while it sounds fine it's
similar to the CompositeMap
(http://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/index.html).
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
> Attachments: SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747858#comment-13747858
]
Carsten Ziegeler commented on SLING-2779:
-
I think we should make this as simple as possible. Creating a copy of an
immutable map, deleting properties and then passing it into the composite map,
seems to be much easier for me than having all these edge cases within the
composite value map.
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
> Attachments: SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748669#comment-13748669
]
Carsten Ziegeler commented on SLING-2779:
-
I agree, I was rather focusing on the API for now . I think a CompositeValueMap
which combines two value maps is a nice thing. However it really should behave
like a value map and implement all the methods properly. [~gknob] can you
please update your patch?
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
> Attachments: SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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: Component/s: (was: JCR) ResourceResolver > 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-2076) Make MapEntries more dynamic
[ https://issues.apache.org/jira/browse/SLING-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749500#comment-13749500 ] Carsten Ziegeler commented on SLING-2076: - I think the provider approach is not suited for this case - the different mappings have to be aggregated/merged by the implementation in order to call them in a meaningfull order (longest match first). In addition, mappings might change at any time. If we would use the provider approach, we would have to call all providers each time a mapping is handled, merge the results and apply the mappings. This doesn't sound like a fast solution. Of course a provider could indicate whether it has changed since the last time, but still, once a provider a changes, this will block all map handling until the list of mappings is updated. The current implementation uses an async background thread avoiding any blocking. Therefore I think we should do an inverse approach: we define a manager like service (don't have a good name yet), which can be called by providers (provider is not an interface) whenever the provider has an update. The provider uses an identififer together with the new set of mappings. So basically this is the same way the OSGi installer works today, where providers inform the installer about changes. In this case we can do the processing in the background inside the manager, and simply switch to the new mapping once the calculation is done > 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] [Updated] (SLING-1421) Resorce Resolver Mapping - Better Support for Multiple Domain/Protocol Mapping
[ https://issues.apache.org/jira/browse/SLING-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1421: Component/s: (was: JCR) ResourceResolver > Resorce Resolver Mapping - Better Support for Multiple Domain/Protocol Mapping > -- > > Key: SLING-1421 > URL: https://issues.apache.org/jira/browse/SLING-1421 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Affects Versions: JCR Resource 2.0.6 >Reporter: Stefan Seifert > Attachments: 100303_slingtest-mapping.zip > > > in our sling CMS-based web projects we've the following scenario: > * most pages of a website are accessed via HTTP, but some of the via HTTPs > (e.g. including forms submitting personal data) > * at the same time we use the mapping features at /etc/map to shorten the > urls for a given domain name > * in fact we have to configure two mappings for two domain names (one for > HTTP and one for HTTPS), pointing to the same start path in JCR > with this configuration in place the sling ResourceResolver.map method > sometimes produces unexpected or incorrect results with the current > implementation. > if the current host name and port does not match with the configured mapping > host name and port sling automatically adds protocol, host name and port from > the configuration to the result of the map method. but in the case above with > multiple mappings for the same start path this cannot produce correct > results, because the decision whether the secure or non-secure domain name > should be chosen is custom application logic. > i'm not sure what the best solution is for this problem, because the current > implementation makes sense in some way and works well for the simple > scenarios. but in complex scenarios with multiple domain mappings it would be > more practical to use the map method only for shortening the urls and not for > adding the hostname. > of course it is possible to parse the value of the map method and strip off > any hostname returned manually and add an own one, but this seems not > "right". and if the cms does a check if the internal url is valid this url > can be treated as invalid. > for easy reproduction of the scenario i've attached a simple test project > [^100303_slingtest-mapping.zip]. please deploy it to a sling instance using > "mvn install" and then call in the intro page > http://localhost:8080/content/slingtest-mapping.html and follow the > instructions on the page (two host names have to be added to the local hosts > file). the test project contains two templates/jsp components, a > configuration at /etc/map with two domain names pointing to the same path and > some sample content nodes. > depending whether a default mapping "/content/-/" is configured in "apache > sling resource resolver" the generated links on the "site 1" test page are > correct. but the links generate on the "site 2" test pages are wrong. -- 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] [Closed] (SLING-2797) Null dynamicClassLoaderManager in ClassLoaderWriterImpl.getOrCreateClassLoader()
[ https://issues.apache.org/jira/browse/SLING-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-2797. --- > Null dynamicClassLoaderManager in > ClassLoaderWriterImpl.getOrCreateClassLoader() > > > Key: SLING-2797 > URL: https://issues.apache.org/jira/browse/SLING-2797 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: error.txt > > > I got this just once when running integration tests on revision 1460730: > NullPointerException: Specified service reference cannot be null. > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458) > at > org.apache.sling.jcr.classloader.internal.ClassLoaderWriterImpl.getOrCreateClassLoader(ClassLoaderWriterImpl.java:215) > and that line 215 is: > final DynamicClassLoaderManager dclm = (DynamicClassLoaderManager) > this.callerBundle.getBundleContext().getService( > this.dynamicClassLoaderManager); > looks like this.dynamicClassLoaderManager is unexpectedly null. > This happened while running > org.apache.sling.launchpad.webapp.integrationtest.servlets.resolver.errorhandler.ErrorHandlingTest > which installs JSP error scripts just before running, there might be a race > condition here. > I won't investigate further right now, cannot reliably reproduce, saving this > info in case we see this again. -- 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-2797) Null dynamicClassLoaderManager in ClassLoaderWriterImpl.getOrCreateClassLoader()
[ https://issues.apache.org/jira/browse/SLING-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2797. - Resolution: Duplicate Looks like a duplicate of SLING-2732 > Null dynamicClassLoaderManager in > ClassLoaderWriterImpl.getOrCreateClassLoader() > > > Key: SLING-2797 > URL: https://issues.apache.org/jira/browse/SLING-2797 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: error.txt > > > I got this just once when running integration tests on revision 1460730: > NullPointerException: Specified service reference cannot be null. > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458) > at > org.apache.sling.jcr.classloader.internal.ClassLoaderWriterImpl.getOrCreateClassLoader(ClassLoaderWriterImpl.java:215) > and that line 215 is: > final DynamicClassLoaderManager dclm = (DynamicClassLoaderManager) > this.callerBundle.getBundleContext().getService( > this.dynamicClassLoaderManager); > looks like this.dynamicClassLoaderManager is unexpectedly null. > This happened while running > org.apache.sling.launchpad.webapp.integrationtest.servlets.resolver.errorhandler.ErrorHandlingTest > which installs JSP error scripts just before running, there might be a race > condition here. > I won't investigate further right now, cannot reliably reproduce, saving this > info in case we see this again. -- 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=13753236#comment-13753236 ] Carsten Ziegeler commented on SLING-3028: - I like the idea in general - can we come up with some criteria when a job needs to be kept after its finished? I don't want to keep all jobs all the time.So as you suggest we can configure a time for how long the jobs are kept, but I think we need an additional way to identify the jobs to keep. Simplest solution would be to add this as a configuration property of the queue - but this doesn't feel quiet right > 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 > > 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-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=13754454#comment-13754454 ] Carsten Ziegeler commented on SLING-3028: - Ok, we have three options of where a decision to keep a job can be made: - the job sender by setting a property - the job consumer - the job engine Keeping failed jobs seems to be the most natural decision to me, so this would be the job engine deciding it based on the result. I think this is a good first step. But this leads me to the question, why do we want to keep a job - or the result of a job? I think the no.1 reason is trouble shooting and knowing that things have failed and why. So I have the feeling that this simple decision (job failed) is enough. I have the tendency to keep failed jobs forever - but have an API to retry or remove them. A scheduled configuration might always lead to the problem that failed jobs are removed before someone took an action. > 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 > > 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-3034) Check contents of healtchecks bundle
Carsten Ziegeler created SLING-3034:
---
Summary: Check contents of healtchecks bundle
Key: SLING-3034
URL: https://issues.apache.org/jira/browse/SLING-3034
Project: Sling
Issue Type: Task
Components: Health Check
Reporter: Carsten Ziegeler
Fix For: healthcheck-api 1.0.0
The current healtchecks bundle seems to be a collection of completely different
things. I think we should reduce this to the bare minimum as these services are
API.
I think the CompositeHealthCheck is fine, as well as the ScriptableHealthCheck
and the JmxAttributeHealthCheck.
But I think the DefaultLoginsHealthCheck and the SlingRequestStatusHealthCheck
should rather be moved out. Checking this stuff might look nice, but it imho it
doesn't really provide a huge value. If you want to check the status of a
request than you have to go all the way, the client browser would go. Otherwise
your server looks fine but still a user does not get anything.
The OsgiScriptBinding looks like a sample to me, we should rather remove this
for now. Bundle information should be availabel as jmx info anyway.
All services are configuration factories (which is good) but set the name to
"org.apache.sling.hc.{classname}". I think we should use the real package name
here, I see no good reason to use some fake package name
--
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-3034) Check contents of healtchecks bundle
[
https://issues.apache.org/jira/browse/SLING-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754536#comment-13754536
]
Carsten Ziegeler commented on SLING-3034:
-
And maybe we should rename this module to "support"? It doesn't contain any
"real" health checks
> Check contents of healtchecks bundle
>
>
> Key: SLING-3034
> URL: https://issues.apache.org/jira/browse/SLING-3034
> Project: Sling
> Issue Type: Task
> Components: Health Check
>Reporter: Carsten Ziegeler
> Fix For: healthcheck-api 1.0.0
>
>
> The current healtchecks bundle seems to be a collection of completely
> different things. I think we should reduce this to the bare minimum as these
> services are API.
> I think the CompositeHealthCheck is fine, as well as the
> ScriptableHealthCheck and the JmxAttributeHealthCheck.
> But I think the DefaultLoginsHealthCheck and the
> SlingRequestStatusHealthCheck should rather be moved out. Checking this stuff
> might look nice, but it imho it doesn't really provide a huge value. If you
> want to check the status of a request than you have to go all the way, the
> client browser would go. Otherwise your server looks fine but still a user
> does not get anything.
> The OsgiScriptBinding looks like a sample to me, we should rather remove this
> for now. Bundle information should be availabel as jmx info anyway.
> All services are configuration factories (which is good) but set the name to
> "org.apache.sling.hc.{classname}". I think we should use the real package
> name here, I see no good reason to use some fake package name
--
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-3034) Check contents of healtchecks bundle
[
https://issues.apache.org/jira/browse/SLING-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756083#comment-13756083
]
Carsten Ziegeler commented on SLING-3034:
-
I really would like to separate support for writing/creating health checks from
concrete checks and keep them in separate bundles
Now, I think we can argue a lot about the DefaultLoginsHealthCheck - as this is
configurable, an open system might be reconfigured and in this case this check
might be changed to check something different. And you don't notice this. The
same for the SlingRequestStatusHealthCheck - it's a long chain from the browser
until the request arives at Sling. While this check is a good first step, it
still gives you no guarantee what arives at the user, especially as it's not
using a real user.
Don't get me wrong, these checks have a value and serve a purpose - however,
just relying on them is simply not enough.
Maybe we should simply move CompositeHealthCheck, ScriptableHealthCheck and
JmxAttributeHealthCheck to the api bundle - as this is kind of an api
> Check contents of healtchecks bundle
>
>
> Key: SLING-3034
> URL: https://issues.apache.org/jira/browse/SLING-3034
> Project: Sling
> Issue Type: Task
> Components: Health Check
>Reporter: Carsten Ziegeler
> Fix For: healthcheck-api 1.0.0
>
>
> The current healtchecks bundle seems to be a collection of completely
> different things. I think we should reduce this to the bare minimum as these
> services are API.
> I think the CompositeHealthCheck is fine, as well as the
> ScriptableHealthCheck and the JmxAttributeHealthCheck.
> But I think the DefaultLoginsHealthCheck and the
> SlingRequestStatusHealthCheck should rather be moved out. Checking this stuff
> might look nice, but it imho it doesn't really provide a huge value. If you
> want to check the status of a request than you have to go all the way, the
> client browser would go. Otherwise your server looks fine but still a user
> does not get anything.
> The OsgiScriptBinding looks like a sample to me, we should rather remove this
> for now. Bundle information should be availabel as jmx info anyway.
> All services are configuration factories (which is good) but set the name to
> "org.apache.sling.hc.{classname}". I think we should use the real package
> name here, I see no good reason to use some fake package name
--
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-3034) Check contents of healtchecks bundle
[
https://issues.apache.org/jira/browse/SLING-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756107#comment-13756107
]
Carsten Ziegeler commented on SLING-3034:
-
While I don't see why the bundle can't be named api, I'm fine with renaming it
to core.
Yes, this thing moves back and forth a little bit, but this is imho a good
thing as we're making good progress
> Check contents of healtchecks bundle
>
>
> Key: SLING-3034
> URL: https://issues.apache.org/jira/browse/SLING-3034
> Project: Sling
> Issue Type: Task
> Components: Health Check
>Reporter: Carsten Ziegeler
> Fix For: healthcheck-api 1.0.0
>
>
> The current healtchecks bundle seems to be a collection of completely
> different things. I think we should reduce this to the bare minimum as these
> services are API.
> I think the CompositeHealthCheck is fine, as well as the
> ScriptableHealthCheck and the JmxAttributeHealthCheck.
> But I think the DefaultLoginsHealthCheck and the
> SlingRequestStatusHealthCheck should rather be moved out. Checking this stuff
> might look nice, but it imho it doesn't really provide a huge value. If you
> want to check the status of a request than you have to go all the way, the
> client browser would go. Otherwise your server looks fine but still a user
> does not get anything.
> The OsgiScriptBinding looks like a sample to me, we should rather remove this
> for now. Bundle information should be availabel as jmx info anyway.
> All services are configuration factories (which is good) but set the name to
> "org.apache.sling.hc.{classname}". I think we should use the real package
> name here, I see no good reason to use some fake package name
--
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-2993) Properly tag and annotate interfaces and classes
[ https://issues.apache.org/jira/browse/SLING-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2993: Fix Version/s: Parent 18 > Properly tag and annotate interfaces and classes > > > Key: SLING-2993 > URL: https://issues.apache.org/jira/browse/SLING-2993 > Project: Sling > Issue Type: Task > Components: API, JCR >Affects Versions: JCR API 2.1.0, API 2.4.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Parent 18, JCR API 2.2.0, API 2.5.0 > > Attachments: SLING-2993.patch > > > The interfaces and classes in the Sling API bundle are not currently properly > documented as to who is intended to implement or extend these. In the > interest of stable extensibility, the types should be marked as follows: > * Exceptions: Nothing to mark. These are concrete classes intended for > extension > * Abstract Classes: Annotate with @ConsumerType. These are intended for > extension. > * Helper/Util/Constant Classes: Mark final because there is no use > extending them. > * Interfaces: For each interface decide whether they are implemented by a > single service (e.g. ResourceResovlerFactory) or by multiple service > providers (e.g. ResourceProvider). > Technically the @ConsumerType annotation is not required because it is the > default. Yet, I think we should mark all non-@ProviderType types with > @ConsumerType to clarify the distinction. > Will attach a proposed patch to this issue. -- 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-2993) Properly tag and annotate interfaces and classes
[ https://issues.apache.org/jira/browse/SLING-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756384#comment-13756384 ] Carsten Ziegeler commented on SLING-2993: - I'Ve updated the parent pom to use 2.4.0 of the maven bundle plugin > Properly tag and annotate interfaces and classes > > > Key: SLING-2993 > URL: https://issues.apache.org/jira/browse/SLING-2993 > Project: Sling > Issue Type: Task > Components: API, JCR >Affects Versions: JCR API 2.1.0, API 2.4.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Parent 18, JCR API 2.2.0, API 2.5.0 > > Attachments: SLING-2993.patch > > > The interfaces and classes in the Sling API bundle are not currently properly > documented as to who is intended to implement or extend these. In the > interest of stable extensibility, the types should be marked as follows: > * Exceptions: Nothing to mark. These are concrete classes intended for > extension > * Abstract Classes: Annotate with @ConsumerType. These are intended for > extension. > * Helper/Util/Constant Classes: Mark final because there is no use > extending them. > * Interfaces: For each interface decide whether they are implemented by a > single service (e.g. ResourceResovlerFactory) or by multiple service > providers (e.g. ResourceProvider). > Technically the @ConsumerType annotation is not required because it is the > default. Yet, I think we should mark all non-@ProviderType types with > @ConsumerType to clarify the distinction. > Will attach a proposed patch to this issue. -- 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-2854) Move the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils
[ https://issues.apache.org/jira/browse/SLING-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2854. - Resolution: Fixed Assignee: Carsten Ziegeler I've applied the patch with a minor change: instead of throwing a runtimeexception I changed this to throw a PersistenceException > Move the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils > - > > Key: SLING-2854 > URL: https://issues.apache.org/jira/browse/SLING-2854 > Project: Sling > Issue Type: Bug > Components: API, Extensions >Affects Versions: API 2.4.0 >Reporter: Felix Meschberger >Assignee: Carsten Ziegeler > Fix For: API 2.5.0, Resource Collections 1.0.0 > > Attachments: SLING-2854 > > > As discussed in SLING-2853, it should be considered to move the utility > method to the ResourceUtils helper 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-2854) Move the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils
[ https://issues.apache.org/jira/browse/SLING-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2854: Summary: Move the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils (was: Consider moving the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils) > Move the ResourceCollectionUtil.createUniqueChildName method to ResourceUtils > - > > Key: SLING-2854 > URL: https://issues.apache.org/jira/browse/SLING-2854 > Project: Sling > Issue Type: Bug > Components: API, Extensions >Affects Versions: API 2.4.0 >Reporter: Felix Meschberger > Fix For: API 2.5.0, Resource Collections 1.0.0 > > Attachments: SLING-2854 > > > As discussed in SLING-2853, it should be considered to move the utility > method to the ResourceUtils helper 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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-2779:
---
Assignee: Carsten Ziegeler
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
>Assignee: Carsten Ziegeler
> Attachments: SLING-2779_20130828.patch, SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-2779:
Fix Version/s: API 2.5.0
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
>Assignee: Carsten Ziegeler
> Fix For: API 2.5.0
>
> Attachments: SLING-2779_20130828.patch, SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756472#comment-13756472
]
Carsten Ziegeler commented on SLING-2779:
-
Thanks for updating the patch. I'Ve applied a modified version in rev 1519608:
- moved the CompositeValueMap class to the wrappers package - as this is more a
wrapper
- keySet(), entrySet() and values() now share their implementation
- Removed the ValueMapUtil class - we don't say anything about how the key
should be structured, some implementations strip the ./, some dont. For example
the ValueMapDecorator does not. And I think adding this check in the JCR
implementation was wrong in the first place, the caller should be responsible
for providing a correct key. As each implementation might do the check - or
not, we preserve the same behaviour as calling the single value maps one after
the other.
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
>Assignee: Carsten Ziegeler
> Fix For: API 2.5.0
>
> Attachments: SLING-2779_20130828.patch, SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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-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 updated SLING-2707: Fix Version/s: Servlets Post 2.3.4 > 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: General >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] [Updated] (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 updated SLING-2707: Component/s: (was: General) Servlets > 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] [Assigned] (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 reassigned SLING-2707: --- Assignee: Carsten Ziegeler > 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: General >Reporter: Shashank Gupta >Assignee: Carsten Ziegeler > 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] [Commented] (SLING-2707) Support of chunked file upload into Sling
[ https://issues.apache.org/jira/browse/SLING-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756545#comment-13756545 ] Carsten Ziegeler commented on SLING-2707: - Thanks for your patch, Shashank. I've applied it to trunk. I'll leave this issue open for a little time to give others a chance to comment > 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] [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=13756656#comment-13756656 ] Carsten Ziegeler commented on SLING-3028: - Ok, so what about keeping failed jobs and adding a configuration to a queue whether successful jobs should be kept as well - this can be used as a first configuration option, to keep the number of jobs kept to a minimum. We'll then enhance the job manager api to query for failed and successful jobs - I think we can use the already existing api of the JobManager and just need to add two values to the QueryType enumeration. The same api can be used to delete these jobs permanently from the repository. We might need a new method to reschedule a failed job. So let's think about the api to set the progress and give log statements > 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 > > 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-3034) Check contents of healtchecks bundle
[
https://issues.apache.org/jira/browse/SLING-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756735#comment-13756735
]
Carsten Ziegeler commented on SLING-3034:
-
the package-info in the util package of core should be 1.0, we haven't done any
release yet (i've fixed this)
Still the CompositeHealthCheck, ScriptableHealthCheck and
JmxAttributeHealthCheck contain a fake name for their config factories. I think
we should use the real package
And we really should remove the OsgiScriptBinding - I don't want to carry this
around forever for compatibility
Other than that, lgtm
> Check contents of healtchecks bundle
>
>
> Key: SLING-3034
> URL: https://issues.apache.org/jira/browse/SLING-3034
> Project: Sling
> Issue Type: Task
> Components: Health Check
>Reporter: Carsten Ziegeler
>Assignee: Bertrand Delacretaz
> Fix For: healthcheck-api 1.0.0
>
>
> The current healtchecks bundle seems to be a collection of completely
> different things. I think we should reduce this to the bare minimum as these
> services are API.
> I think the CompositeHealthCheck is fine, as well as the
> ScriptableHealthCheck and the JmxAttributeHealthCheck.
> But I think the DefaultLoginsHealthCheck and the
> SlingRequestStatusHealthCheck should rather be moved out. Checking this stuff
> might look nice, but it imho it doesn't really provide a huge value. If you
> want to check the status of a request than you have to go all the way, the
> client browser would go. Otherwise your server looks fine but still a user
> does not get anything.
> The OsgiScriptBinding looks like a sample to me, we should rather remove this
> for now. Bundle information should be availabel as jmx info anyway.
> All services are configuration factories (which is good) but set the name to
> "org.apache.sling.hc.{classname}". I think we should use the real package
> name here, I see no good reason to use some fake package name
--
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=13757508#comment-13757508 ] Carsten Ziegeler commented on SLING-3028: - A job consumer returns a result: success or fail - so we know that the processing failed or not > 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 > > 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-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=13757556#comment-13757556 ] Carsten Ziegeler commented on SLING-3028: - I've added a prototype of an api with rev 1519939. A new interface JobExecutor is an enhanced version of the JobConsumer - it allows to return a JobStatus which provides more return information than just the state, like an additional message etc. A new JobExecutionContext is passed to the process method of JobExecutor - it allows to log messages, set the progress etc. Just a first quick draft > 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 > > 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] [Reopened] (SLING-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-3037: - I think this needs to be fixed in the logging as this is actually a regression > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Scripting Core 2.0.24 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Scripting Core 2.0.26 > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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-3039) Obsolete events should be removed in batches from the resource tree
Carsten Ziegeler created SLING-3039: --- Summary: Obsolete events should be removed in batches from the resource tree Key: SLING-3039 URL: https://issues.apache.org/jira/browse/SLING-3039 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 distributed event receiver removes obsolete events from the resource tree. If e.g. an instance goes down, this can result of a rather large tree being removed. Removing large trees is problematic with current jackrabbit implementations and should rather be deleted recursively with batch saves in between -- 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-3039) Obsolete events should be removed in batches from the resource tree
[ https://issues.apache.org/jira/browse/SLING-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3039. - Resolution: Fixed Fixed in 1520051 > Obsolete events should be removed in batches from the resource tree > --- > > Key: SLING-3039 > URL: https://issues.apache.org/jira/browse/SLING-3039 > 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 distributed event receiver removes obsolete events from the resource > tree. If e.g. an instance goes down, this can result of a rather large tree > being removed. > Removing large trees is problematic with current jackrabbit implementations > and should rather be deleted recursively with batch saves in between -- 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-3041) Mark job as failed if async job consumer disappears
Carsten Ziegeler created SLING-3041: --- Summary: 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.2.2 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 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-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759112#comment-13759112 ] Carsten Ziegeler commented on SLING-3037: - Can't we provide a fix for logback? I think overlaying the class until it's fixed there is fine. However we should really provide a patch to logback, so it gets fixed with the next release > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Scripting Core 2.0.24 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Scripting Core 2.0.26 > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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=13759149#comment-13759149 ] Carsten Ziegeler commented on SLING-3028: - Ok, yes I see the point with ETA - let's change that - the other idea is to get the status in per cent - so by default the engine assumes you have 100 steps, and then you call setProgress() with how many steps you have finished. YOu can also change the number of steps to a different value. I would rather go with a specific log method, we could think about log(String, Object...) though The other option would be to allow a job to specify whether it should be kept or not > 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 > > 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-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=13760055#comment-13760055 ] Carsten Ziegeler commented on SLING-3028: - The JobExecutionContext is more than just progress tracking, it provides a log and the feedback for async handlers. For timestamps, yes, the log would contain the timestamp of the log message provided. I'm not happy with the progress tracking api yet, the general idea is that a job consumer calls first start() to indicate that it's able to track progress (not every job consumer is able to do so). With the start method, the consumer gives a hint (if possible) when processing might be finished (either a count, or an ETA - number of seconds from now). During processing it updates this information and/or the current state (ETA can be updated, step count can be set). I've committed an updated version of the API (where I also changed the feedback for async processing) > 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 > > 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-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3037: Affects Version/s: (was: Scripting Core 2.0.24) > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Engine >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Scripting Core 2.0.26 > > Attachments: SLING-3037.patch > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3037: Component/s: (was: Engine) Commons > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Scripting Core 2.0.26 > > Attachments: SLING-3037.patch > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3037: Fix Version/s: (was: Scripting Core 2.0.26) Commons Log 4.0.0 > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3037.patch > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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-3037) IllegalArgumentException in logback Logger
[ https://issues.apache.org/jira/browse/SLING-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3037. - Resolution: Fixed Thanks Chetan, I've applied your patch and reverted the change to scripting.core > IllegalArgumentException in logback Logger > -- > > Key: SLING-3037 > URL: https://issues.apache.org/jira/browse/SLING-3037 > Project: Sling > Issue Type: Bug > Components: Commons >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: Commons Log 4.0.0 > > Attachments: SLING-3037.patch > > > Since switching to logback in SLING-2024, a number of integration tests are > failing, typical stack trace: > java.lang.IllegalArgumentException: > For logger [apps.integration-test] child name > [apps.integration-test.srt$1378284549103 passed as parameter, may not include > '.' after index22 > at ch.qos.logback.classic.Logger.createChildByName(Logger.java:357) > at > ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:143) > at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:45) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) > at > org.apache.sling.scripting.core.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:676) -- 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: 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 > Fix For: Resource Resolver 1.1.0 > > > 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] [Created] (SLING-3043) Allow regexp filtering of vanity paths
Carsten Ziegeler created SLING-3043: --- Summary: Allow regexp filtering of vanity paths Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- 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=13760085#comment-13760085 ] Carsten Ziegeler commented on SLING-2944: - I've removed the header stuff in rev 1520522 > 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] [Resolved] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-2779.
-
Resolution: Fixed
> Support for default properties values of a resource
> ---
>
> Key: SLING-2779
> URL: https://issues.apache.org/jira/browse/SLING-2779
> Project: Sling
> Issue Type: New Feature
> Components: API
>Affects Versions: API 2.3.0
>Reporter: Gilles Knobloch
>Assignee: Carsten Ziegeler
> Fix For: API 2.5.0
>
> Attachments: SLING-2779_20130828.patch, SLING-2779.patch
>
>
> I already noticed several times it would be useful to be able to specify a
> default properties for a resource:
> * if the resource itself contains the property, it will override the default
> one.
> * but if it doesn't, the default value is used.
> This could be done either via:
> * specifying a {{sling:defaults}} property on the resource, which contains
> the path to the resource which properties will be used by default.
> * providing a default map of properties
> Attaching a patch for review.
> For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
> imagine it could go to {{org.apache.sling.api.resource}}.
--
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=13760141#comment-13760141 ] Carsten Ziegeler commented on SLING-3028: - This depends :) If I understand you correctly, you say that you have an ETA for each step, right? The steps are intended to be used when you don't know the eta but you know the progress, so for example if you have ten steps to do, you can calculate a percentage once each step is finished. Of course assuming that each step takes the same time - but that's as good as having a rough ETA. I've looked at other progress tracker api's and they usually provide both ways > 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-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=13768103#comment-13768103 ] Carsten Ziegeler commented on SLING-2944: - I think this method makes not that much sense if we don't support the header as it's basically concatenating the bundle symbolic name with the service id. So this is more an utility method than a service method. But if you think that it's worth having it in the service, we can add it back again > 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
