[jira] [Commented] (SLING-3679) Required fields validation
[
https://issues.apache.org/jira/browse/SLING-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041770#comment-14041770
]
Krystian Panek commented on SLING-3679:
---
OK, so maybe in other words...
My idea is to implement custom strategy of injecting (or even more) that tries
to inject all annotated field as if all of them were optional (so in
consequence model variable from taglib sling:adaptTo adaptable=${resource}
adaptTo=... var=model/ never be a null - what I care most). Yes I
understand that it is currently possible if I annotate all fields with
@Optional, but I think that there could be a better way to do this :)
Required fields validation
--
Key: SLING-3679
URL: https://issues.apache.org/jira/browse/SLING-3679
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.4
Reporter: Krystian Panek
Labels: models
Currently if some field cannot be injected (and it is not annotated with
@Optional), model adapter factory returns null. However fact that some field
has null and all other are properly injected is acceptable in my context.
Proposal:
* model adapter factory does not return null if not all required fields are
injected,
* result of requirement validation is serviced as for example:
** injecting it to some extra annotated field: @Valid boolean valid; (with
default false),
** passing bool parameter in @PostConstruct callback, for example 'valid'
(true if all required field are injected, false otherwise),
* behave current behavior, new available only with extra model class
annotation, for example @NotNull .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SLING-3679) Required fields validation
[
https://issues.apache.org/jira/browse/SLING-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041770#comment-14041770
]
Krystian Panek edited comment on SLING-3679 at 6/24/14 6:37 AM:
OK, so maybe in other words...
My idea is to implement custom strategy of injecting (or even more) that tries
to inject all annotated field as if all of them were optional (so in
consequence model variable from taglib sling:adaptTo var=model ... / never
be a null - what I care most). Yes I understand that it is currently possible
if I annotate all fields with @Optional, but I think that there could be a
better way to do this :)
was (Author: kpanek):
OK, so maybe in other words...
My idea is to implement custom strategy of injecting (or even more) that tries
to inject all annotated field as if all of them were optional (so in
consequence model variable from taglib sling:adaptTo adaptable=${resource}
adaptTo=... var=model/ never be a null - what I care most). Yes I
understand that it is currently possible if I annotate all fields with
@Optional, but I think that there could be a better way to do this :)
Required fields validation
--
Key: SLING-3679
URL: https://issues.apache.org/jira/browse/SLING-3679
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.4
Reporter: Krystian Panek
Labels: models
Currently if some field cannot be injected (and it is not annotated with
@Optional), model adapter factory returns null. However fact that some field
has null and all other are properly injected is acceptable in my context.
Proposal:
* model adapter factory does not return null if not all required fields are
injected,
* result of requirement validation is serviced as for example:
** injecting it to some extra annotated field: @Valid boolean valid; (with
default false),
** passing bool parameter in @PostConstruct callback, for example 'valid'
(true if all required field are injected, false otherwise),
* behave current behavior, new available only with extra model class
annotation, for example @NotNull .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3689) JCR Properties shows up empty the first time
Catalin Buzoiu created SLING-3689:
-
Summary: JCR Properties shows up empty the first time
Key: SLING-3689
URL: https://issues.apache.org/jira/browse/SLING-3689
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Catalin Buzoiu
Priority: Minor
First time the {{JCR Properties}} view is displayed, it shows up empty, even if
there is a node selected in the Project Explorer. Clinking on another node and
then back to the original node shows correctly the expected properties.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3690) Cannot create JCR Nodes under a sling:Folder
Catalin Buzoiu created SLING-3690:
-
Summary: Cannot create JCR Nodes under a sling:Folder
Key: SLING-3690
URL: https://issues.apache.org/jira/browse/SLING-3690
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Catalin Buzoiu
The {{New Node...}} option is not shown when right-clicking on
{{sling:Folder}} nodes, although JCR Nodes should be allowed there.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3691) Add Cut / Copy / Paste nodes to content navigator
Catalin Buzoiu created SLING-3691: - Summary: Add Cut / Copy / Paste nodes to content navigator Key: SLING-3691 URL: https://issues.apache.org/jira/browse/SLING-3691 Project: Sling Issue Type: New Feature Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Catalin Buzoiu Priority: Critical In day-to-day activities, being able to manipulate nodes in the content navigator with Cut / Copy / Paste operations is really critical. /cc [~fvisser] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3691) Add Cut / Copy / Paste nodes to content navigator
[ https://issues.apache.org/jira/browse/SLING-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3691: --- Fix Version/s: Sling Eclipse IDE 1.0.2 Add Cut / Copy / Paste nodes to content navigator - Key: SLING-3691 URL: https://issues.apache.org/jira/browse/SLING-3691 Project: Sling Issue Type: New Feature Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Catalin Buzoiu Priority: Critical Fix For: Sling Eclipse IDE 1.0.2 In day-to-day activities, being able to manipulate nodes in the content navigator with Cut / Copy / Paste operations is really critical. /cc [~fvisser] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3690) Cannot create JCR Nodes under a sling:Folder
[
https://issues.apache.org/jira/browse/SLING-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3690:
---
Fix Version/s: Sling Eclipse IDE 1.0.2
Cannot create JCR Nodes under a sling:Folder
Key: SLING-3690
URL: https://issues.apache.org/jira/browse/SLING-3690
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Catalin Buzoiu
Fix For: Sling Eclipse IDE 1.0.2
The {{New Node...}} option is not shown when right-clicking on
{{sling:Folder}} nodes, although JCR Nodes should be allowed there.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3689) JCR Properties shows up empty the first time
[
https://issues.apache.org/jira/browse/SLING-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3689:
---
Fix Version/s: Sling Eclipse IDE 1.0.2
JCR Properties shows up empty the first time
Key: SLING-3689
URL: https://issues.apache.org/jira/browse/SLING-3689
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Catalin Buzoiu
Priority: Minor
Fix For: Sling Eclipse IDE 1.0.2
First time the {{JCR Properties}} view is displayed, it shows up empty, even
if there is a node selected in the Project Explorer. Clinking on another node
and then back to the original node shows correctly the expected properties.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Triggering logic on commit of ResourceResolver
Hi everyone, I'm currently doing some research to implement a feature where I need to integrate 3rd party systems that act as client and need to perform some local changes that I can trigger from the sling instance. The issue I do have is that there seems to be no proper way to transport the information that I do have when preparing the changes in the local repo via resourceresolver to some code that is executed after the transient changes have been commited. The only mechansim available is listening for the Resource events but I lose a lot of information. One example is removal of a node where I cannot access the values of the removed resource anymore. The remove event for a resource testa with attribute testb with value testc provides me the following information: event.topicsorg/apache/sling/api/resource/Resource/REMOVEDpath/content/testa useridadminresourceRemovedAttributes[testb, jcr:primaryType] Beside losing information it just feels wrong that I have to bind to the persisted information but cannot bind specific logic to a commit. When thinking about this a bit more I wonder why Event and JobHandling shouldn't have an option to only be triggered on commit. If I'd have a way to prepare events/jobs that only get fired if the commit could successfully be performed I'd have a way to transport all the metadata I need to trigger the 3rd system via EventListener/JobConsumer. My concrete usecase is about triggering securitymechanisms of multiple third party system based on changes persisted in a sling instance (synching accesscontrol for a highly integrated system that is not only composed of sling instances). I had a related requirement some years ago where a search integration did require some metadata about deleted resources to be able to perform a proper cleanup and we had to turn on jcr versioning to be able to get this data from the corresponding frozen nodes since the original nodes are already gone when the event is fired. Any alternative idea or opinions regarding such an extension? Best regards Dominik
[jira] [Updated] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-3505: -- Attachment: MapEntry.java.rej Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042018#comment-14042018 ] Justin Edelson commented on SLING-3505: --- [~asanso] your patch doesn't apply cleanly against trunk for me. 1 out of 4 hunks FAILED -- saving rejects to file src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntry.java.rej Attaching MapEntry.java.rej Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3499) Support custom annotations with Sling Models
[ https://issues.apache.org/jira/browse/SLING-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042022#comment-14042022 ] Konrad Windszus commented on SLING-3499: With the changes from SLING-3683 the attached documentation patch needs to be adjusted (in the section Custom Annotations). [~justinedelson] Can you take care of that? Support custom annotations with Sling Models Key: SLING-3499 URL: https://issues.apache.org/jira/browse/SLING-3499 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Sling Models API 1.0.0, Sling Models Implementation 1.0.2 Reporter: Konrad Windszus Assignee: Justin Edelson Fix For: Sling Models Implementation 1.0.6, Sling Models API 1.0.2 Attachments: SLING-3499-Documentation-v1.patch, SLING-3499-Documentation-v2.patch To support custom annotations the API needs to be extended. The reasons for custom annotations are listed in http://www.mail-archive.com/dev%40sling.apache.org/msg27918.html. Also it is much more comfortable for developers, since they can use code completion in the IDE to see which options are available for each injector-specific annotation, apart from that it is less code to write (instead of multiple annotations on one field/method I would only have to write one annotation with some attributes). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3692) Provide access to list of vanity paths/aliases in SLING-3505
Dominique Pfister created SLING-3692: Summary: Provide access to list of vanity paths/aliases in SLING-3505 Key: SLING-3692 URL: https://issues.apache.org/jira/browse/SLING-3692 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Dominique Pfister In our infrastructure, we're using a web server in front of our application hosting Sling, and this web server blocks a lot of requests based on their URL, except those that actually map to a vanity path. In order to keep this information up to date, a plugin in the web server periodically requests the list of vanity paths from a servlet registered in Sling. It would be great if this servlet could have access to the internal list built in SLING-3505, so it could benefit from the performance gain. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3693) Repository import wizard blocks UI thread and is not cancellable
Robert Munteanu created SLING-3693: -- Summary: Repository import wizard blocks UI thread and is not cancellable Key: SLING-3693 URL: https://issues.apache.org/jira/browse/SLING-3693 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3693) Repository import wizard blocks UI thread and is not cancellable
[ https://issues.apache.org/jira/browse/SLING-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3693: --- Description: For large import jobs, the import wizard dialog looks unresponsive, since it is executed in the UI thread and it does not allow cancellation. Repository import wizard blocks UI thread and is not cancellable Key: SLING-3693 URL: https://issues.apache.org/jira/browse/SLING-3693 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.2 For large import jobs, the import wizard dialog looks unresponsive, since it is executed in the UI thread and it does not allow cancellation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3693) Repository import wizard blocks UI thread and is not cancellable
[ https://issues.apache.org/jira/browse/SLING-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-3693. Resolution: Fixed * http://svn.apache.org/viewvc?view=revisionrevision=1605086 added ProgressUtils * http://svn.apache.org/viewvc?view=revisionrevision=1605087 use ProgressUtils in the wizard classes * http://svn.apache.org/viewvc?view=revisionrevision=1605088 tweak the import wizard for progress reporting and for being cancellable Repository import wizard blocks UI thread and is not cancellable Key: SLING-3693 URL: https://issues.apache.org/jira/browse/SLING-3693 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.2 For large import jobs, the import wizard dialog looks unresponsive, since it is executed in the UI thread and it does not allow cancellation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042149#comment-14042149 ] Justin Edelson commented on SLING-3505: --- [~asanso] This looks like it should work, but I honestly am afraid I can't grok the patch fully with the formatting issues. A few questions: * Why is there a TODO on line 498 of MapEntries.java? * Why were the unit tests I added in patch2 removed? Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3694) Full coverage nodes are not imported with an XML extension
Robert Munteanu created SLING-3694:
--
Summary: Full coverage nodes are not imported with an XML extension
Key: SLING-3694
URL: https://issues.apache.org/jira/browse/SLING-3694
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.2
When importing content from the repository full coverage nodes ( e.g. those
with primary type {{sling:OsgiConfig}} ) are imported without extension.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3694) Full coverage nodes are imported without the XML extension
[
https://issues.apache.org/jira/browse/SLING-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3694:
---
Summary: Full coverage nodes are imported without the XML extension (was:
Full coverage nodes are not imported with an XML extension)
Full coverage nodes are imported without the XML extension
--
Key: SLING-3694
URL: https://issues.apache.org/jira/browse/SLING-3694
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.2
When importing content from the repository full coverage nodes ( e.g. those
with primary type {{sling:OsgiConfig}} ) are imported without extension.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042186#comment-14042186 ] Justin Edelson commented on SLING-3505: --- Actually, I take it back. Seeing a NPE during testing. Will report more in a bit. I do see one minor problem - after installing this patch, duplicate vanity paths are listed in the Sling Resource Resolver web console plugin. Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3694) Full coverage nodes are imported without the XML extension
[
https://issues.apache.org/jira/browse/SLING-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-3694.
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1605101
Full coverage nodes are imported without the XML extension
--
Key: SLING-3694
URL: https://issues.apache.org/jira/browse/SLING-3694
Project: Sling
Issue Type: Bug
Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.2
When importing content from the repository full coverage nodes ( e.g. those
with primary type {{sling:OsgiConfig}} ) are imported without extension.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042213#comment-14042213 ] Antonio Sanso commented on SLING-3505: -- bq. Why is there a TODO on line 498 of MapEntries.java? sorry this is probably a left over bq. Why were the unit tests I added in patch2 removed? same here did not do intentionally Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-3505: -- Attachment: SLING-3505-patch3-je.txt [~asanso] here's an updated version of your patch which fixes the formatting problems and does not remove the test cases. I found the NPE is that it was caused by failing to remove the /jcr:content path segment correctly. Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3-je.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2217
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2217/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2217
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2217/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Models Integration Tests #2217
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2217/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2217
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2217/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Installer Integration Tests #2217
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.installer.it/2217/
Jenkins build is still unstable: sling-trunk-1.6 #2217
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Created] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist
Timothee Maret created SLING-3695: - Summary: TenantProvider throws NPE when listing tenants root tenant resource does not exist Key: SLING-3695 URL: https://issues.apache.org/jira/browse/SLING-3695 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.2 Reporter: Timothee Maret Priority: Minor The method org.apache.sling.tenant.TenantProvider#getTenants throws an NPE when the tenant root resource does not exists. The tenant root resource is created if needed when creating a tenant (see org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource) A workaround is to create a tenant and remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
FYI, Crankstart cluster demo screencast
Hi, See http://git.io/SlingDevOps-v4-demo for a demo of the work done by my intern Artyom Stetsenkos's on zero-downtime upgrades of clustered Sling instances. This is still an early prototype where you have to start and stop the Sling instances manually, but it already demonstrates upgrading a cluster of Sling instances atomically, by just pushing an updated Crankstart definition file [1] to a Git repository. We hope to be able to demonstrate the full automated scenario soon, where you just push to Git to get your cluster upgraded. Note that this is fully experimental so far. I think the systems approach of zero-downtime upgrades, where the individual instances are immutable and throwaway, is worth a closer look at least for production instances where you want strict configuration control, ideally based on version control systems. Enjoy, and feedback is welcome! -Bertrand [1] https://github.com/ArtyomStetsenko/sling-devops-experiments/blob/master/crankstart/sling-minion.crank.txt
[GitHub] sling pull request: SLING-3695 - TenantProvider throws NPE when li...
GitHub user tmaret opened a pull request: https://github.com/apache/sling/pull/21 SLING-3695 - TenantProvider throws NPE when listing tenants root tenant ... ...resource does not exist * fix NPE * add unit test You can merge this pull request into a Git repository by running: $ git pull https://github.com/tmaret/sling SLING-3695a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 1c065647ccd0267a8f992ff450d60031520e4f3a Author: tmaret tma...@adobe.com Date: 2014-06-24T15:35:43Z SLING-3695 - TenantProvider throws NPE when listing tenants root tenant resource does not exist * fix NPE * add unit test --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist
[ https://issues.apache.org/jira/browse/SLING-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042272#comment-14042272 ] ASF GitHub Bot commented on SLING-3695: --- GitHub user tmaret opened a pull request: https://github.com/apache/sling/pull/21 SLING-3695 - TenantProvider throws NPE when listing tenants root tenant ... ...resource does not exist * fix NPE * add unit test You can merge this pull request into a Git repository by running: $ git pull https://github.com/tmaret/sling SLING-3695a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 1c065647ccd0267a8f992ff450d60031520e4f3a Author: tmaret tma...@adobe.com Date: 2014-06-24T15:35:43Z SLING-3695 - TenantProvider throws NPE when listing tenants root tenant resource does not exist * fix NPE * add unit test TenantProvider throws NPE when listing tenants root tenant resource does not exist -- Key: SLING-3695 URL: https://issues.apache.org/jira/browse/SLING-3695 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.2 Reporter: Timothee Maret Priority: Minor Labels: tenant The method org.apache.sling.tenant.TenantProvider#getTenants throws an NPE when the tenant root resource does not exists. The tenant root resource is created if needed when creating a tenant (see org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource) A workaround is to create a tenant and remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist
[ https://issues.apache.org/jira/browse/SLING-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042273#comment-14042273 ] Timothee Maret commented on SLING-3695: --- Opened https://github.com/apache/sling/pull/21 TenantProvider throws NPE when listing tenants root tenant resource does not exist -- Key: SLING-3695 URL: https://issues.apache.org/jira/browse/SLING-3695 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.2 Reporter: Timothee Maret Priority: Minor Labels: tenant The method org.apache.sling.tenant.TenantProvider#getTenants throws an NPE when the tenant root resource does not exists. The tenant root resource is created if needed when creating a tenant (see org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource) A workaround is to create a tenant and remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist
[ https://issues.apache.org/jira/browse/SLING-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042273#comment-14042273 ] Timothee Maret edited comment on SLING-3695 at 6/24/14 3:53 PM: Opened https://github.com/apache/sling/pull/21 https://github.com/apache/sling/pull/21.patch was (Author: marett): Opened https://github.com/apache/sling/pull/21 TenantProvider throws NPE when listing tenants root tenant resource does not exist -- Key: SLING-3695 URL: https://issues.apache.org/jira/browse/SLING-3695 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.2 Reporter: Timothee Maret Priority: Minor Labels: tenant The method org.apache.sling.tenant.TenantProvider#getTenants throws an NPE when the tenant root resource does not exists. The tenant root resource is created if needed when creating a tenant (see org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource) A workaround is to create a tenant and remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is back to normal : sling-trunk-1.7 » Apache Sling Pax Exam Utilities #592
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.paxexam.util/592/
Jenkins build is unstable: sling-trunk-1.7 #592
See https://builds.apache.org/job/sling-trunk-1.7/592/changes
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Installer Integration Tests #592
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.installer.it/592/
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #592
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/592/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Models Integration Tests #592
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.models.integration-tests/592/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource Access Security Integration Tests #592
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/592/
[jira] [Updated] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist
[ https://issues.apache.org/jira/browse/SLING-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-3695: -- Attachment: SLING-3695.patch TenantProvider throws NPE when listing tenants root tenant resource does not exist -- Key: SLING-3695 URL: https://issues.apache.org/jira/browse/SLING-3695 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Tenant 1.0.2 Reporter: Timothee Maret Priority: Minor Labels: tenant Attachments: SLING-3695.patch The method org.apache.sling.tenant.TenantProvider#getTenants throws an NPE when the tenant root resource does not exists. The tenant root resource is created if needed when creating a tenant (see org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource) A workaround is to create a tenant and remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2218
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2218/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2218
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2218/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Models Integration Tests #2218
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2218/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2218
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2218/
Jenkins build is still unstable: sling-trunk-1.6 #2218
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Commented] (SLING-3692) Provide access to list of vanity paths/aliases in SLING-3505
[ https://issues.apache.org/jira/browse/SLING-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042363#comment-14042363 ] Justin Edelson commented on SLING-3692: --- [~dpfister] Vanity Paths (with or with SLING-3505) aren't differentiated from other mapping entries (i.e. /etc/map). Is this necessary? Also, for every sling:vanityPath, we actually create two map entries: one for the vanity path itself and one with a trailing regex, i.e. a sling:vanityPath of /foo, the created mappings are /foo$ and /foo(\..*). Do both of those make sense in this feed? Is that the right format? Provide access to list of vanity paths/aliases in SLING-3505 Key: SLING-3692 URL: https://issues.apache.org/jira/browse/SLING-3692 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Dominique Pfister In our infrastructure, we're using a web server in front of our application hosting Sling, and this web server blocks a lot of requests based on their URL, except those that actually map to a vanity path. In order to keep this information up to date, a plugin in the web server periodically requests the list of vanity paths from a servlet registered in Sling. It would be great if this servlet could have access to the internal list built in SLING-3505, so it could benefit from the performance gain. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3696) Allow a model class to be annotated so that by default injections are optional
Justin Edelson created SLING-3696: - Summary: Allow a model class to be annotated so that by default injections are optional Key: SLING-3696 URL: https://issues.apache.org/jira/browse/SLING-3696 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Sling Models Implementation 1.0.6 By default, injections are required and individual injections can be declared as optional. It should be possible to flip this - the default being optional and individual injections can be required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3679) Required fields validation
[ https://issues.apache.org/jira/browse/SLING-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042496#comment-14042496 ] Justin Edelson commented on SLING-3679: --- Can you look at the change I made for SLING-3696 ? I *think* this meets your needs, but I'm not sure you'll think it is sufficient (thus creating a separate issue). Let me know what you think. Required fields validation -- Key: SLING-3679 URL: https://issues.apache.org/jira/browse/SLING-3679 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Sling Models Implementation 1.0.4 Reporter: Krystian Panek Labels: models Currently if some field cannot be injected (and it is not annotated with @Optional), model adapter factory returns null. However fact that some field has null and all other are properly injected is acceptable in my context. Proposal: * model adapter factory does not return null if not all required fields are injected, * result of requirement validation is serviced as for example: ** injecting it to some extra annotated field: @Valid boolean valid; (with default false), ** passing bool parameter in @PostConstruct callback, for example 'valid' (true if all required field are injected, false otherwise), * behave current behavior, new available only with extra model class annotation, for example @NotNull . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3696) Allow a model class to be annotated so that by default injections are optional
[ https://issues.apache.org/jira/browse/SLING-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-3696. --- Resolution: Fixed supported added in r1605150 done by adding defaultInjectionStrategy = OPTIONAL to the @Model annotation. Where necessary, an @Required annotation can be used to declare a field/method as required. Allow a model class to be annotated so that by default injections are optional -- Key: SLING-3696 URL: https://issues.apache.org/jira/browse/SLING-3696 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Justin Edelson Assignee: Justin Edelson Labels: models Fix For: Sling Models Implementation 1.0.6 By default, injections are required and individual injections can be declared as optional. It should be possible to flip this - the default being optional and individual injections can be required. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3677) Array to list conversion in ValueMap
[ https://issues.apache.org/jira/browse/SLING-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-3677. --- Resolution: Fixed Assignee: Justin Edelson Applied patch in r1605153. Thanks! Array to list conversion in ValueMap Key: SLING-3677 URL: https://issues.apache.org/jira/browse/SLING-3677 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Sling Models Implementation 1.0.4 Reporter: Krystian Panek Assignee: Justin Edelson Priority: Minor Labels: models Fix For: Sling Models Implementation 1.0.6 Attachments: valuemap-injector-list-support.diff I suppose that many people prefer lists more than arrays. Automatic conversion in value map would be useful. See attachment (svn diff this time as Justin asked). Only default value support is missing... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3499) Support custom annotations with Sling Models
[ https://issues.apache.org/jira/browse/SLING-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042530#comment-14042530 ] Justin Edelson commented on SLING-3499: --- Yes, I'll take care of the documentation updates. Support custom annotations with Sling Models Key: SLING-3499 URL: https://issues.apache.org/jira/browse/SLING-3499 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Sling Models API 1.0.0, Sling Models Implementation 1.0.2 Reporter: Konrad Windszus Assignee: Justin Edelson Fix For: Sling Models Implementation 1.0.6, Sling Models API 1.0.2 Attachments: SLING-3499-Documentation-v1.patch, SLING-3499-Documentation-v2.patch To support custom annotations the API needs to be extended. The reasons for custom annotations are listed in http://www.mail-archive.com/dev%40sling.apache.org/msg27918.html. Also it is much more comfortable for developers, since they can use code completion in the IDE to see which options are available for each injector-specific annotation, apart from that it is less code to write (instead of multiple annotations on one field/method I would only have to write one annotation with some attributes). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3682) Sling Models: ModelPackageBundleListener should support .* notation for scanning packages
[
https://issues.apache.org/jira/browse/SLING-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042539#comment-14042539
]
Stefan Seifert commented on SLING-3682:
---
ok - but then at least the documentation should be updated, because the
behavior is different from export-package which does not include subpackages.
Sling Models: ModelPackageBundleListener should support .* notation for
scanning packages
-
Key: SLING-3682
URL: https://issues.apache.org/jira/browse/SLING-3682
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.2
Reporter: Stefan Seifert
Attachments: 140620_SLING-3682_slingmodels_starpackagesupport.patch
the maven-bundle-plugin currently supports exporting single packages or
packages including subpackages using {{.*}} notation, e.g. in the
{{Export-Package}} instruction.
this is currently not possible in sling models using the
{{Sling-Model-Packages}} instruction. it always includes the subpackages. it
would be more consistent to respect the {{.*}} as well.
a patch is included that fixes this behavior.
unfortunately this is not backward compatibly - but perhaps this is it worth
any way for the sake of consistency?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Models Integration Tests #593
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.models.integration-tests/593/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #593
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/593/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource Access Security Integration Tests #593
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/593/
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #593
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/593/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #593
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/593/
Jenkins build is still unstable: sling-trunk-1.7 #593
See https://builds.apache.org/job/sling-trunk-1.7/changes
Sling With Oak
Hello, Is there is any document of how to start Sling (Trunk version) using MongoDB as persistence. Only instruction I found was http://jackrabbit.apache.org/oak/docs/osgi_config.html#config-sling which does not work OOTB. Also Oak specific bundles are not part of build sling standalone jar file. Yogesh
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2219
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2219/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2219
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2219/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2219
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2219/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Event Support #2219
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2219/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Models Integration Tests #2219
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2219/
Jenkins build is still unstable: sling-trunk-1.6 #2219
See https://builds.apache.org/job/sling-trunk-1.6/changes
Re: FYI, Crankstart cluster demo screencast
On 24.06.2014, at 08:43, Bertrand Delacretaz bdelacre...@apache.org wrote: See http://git.io/SlingDevOps-v4-demo for a demo of the work done by my intern Artyom Stetsenkos's on zero-downtime upgrades of clustered Sling instances. Nice! OT: That HttpResourceMonitor (top right window in the video) could be replaced by a simple watch curl -s localhost/mynode.test ;-) Cheers, Alex
Re: Triggering logic on commit of ResourceResolver
Is this for a resource provider implementation that is not backed by JCR? Because if we are talking about JCR resources I would advocate solutions on the JCR repo layer, Oak has some options with commit hooks. Just my 2 cents, Alex On 24.06.2014, at 04:22, Dominik Süß dominik.su...@gmail.com wrote: Hi everyone, I'm currently doing some research to implement a feature where I need to integrate 3rd party systems that act as client and need to perform some local changes that I can trigger from the sling instance. The issue I do have is that there seems to be no proper way to transport the information that I do have when preparing the changes in the local repo via resourceresolver to some code that is executed after the transient changes have been commited. The only mechansim available is listening for the Resource events but I lose a lot of information. One example is removal of a node where I cannot access the values of the removed resource anymore. The remove event for a resource testa with attribute testb with value testc provides me the following information: event.topicsorg/apache/sling/api/resource/Resource/REMOVEDpath/content/testa useridadminresourceRemovedAttributes[testb, jcr:primaryType] Beside losing information it just feels wrong that I have to bind to the persisted information but cannot bind specific logic to a commit. When thinking about this a bit more I wonder why Event and JobHandling shouldn't have an option to only be triggered on commit. If I'd have a way to prepare events/jobs that only get fired if the commit could successfully be performed I'd have a way to transport all the metadata I need to trigger the 3rd system via EventListener/JobConsumer. My concrete usecase is about triggering securitymechanisms of multiple third party system based on changes persisted in a sling instance (synching accesscontrol for a highly integrated system that is not only composed of sling instances). I had a related requirement some years ago where a search integration did require some metadata about deleted resources to be able to perform a proper cleanup and we had to turn on jcr versioning to be able to get this data from the corresponding frozen nodes since the original nodes are already gone when the event is fired. Any alternative idea or opinions regarding such an extension? Best regards Dominik
[jira] [Created] (SLING-3697) Incorrect handling of deeply nested aggregates
Robert Munteanu created SLING-3697: -- Summary: Incorrect handling of deeply nested aggregates Key: SLING-3697 URL: https://issues.apache.org/jira/browse/SLING-3697 Project: Sling Issue Type: Bug Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.2 With SLING-3656 we now have improved handling of structures serialized under nt:file/nt:resource nodes. For such derived nodes, Vault uses a concept called leaf aggregates, tied to a main aggregate. It has become apparent that our handling of leaf aggregates is insufficient, for two reasons: * when looking for a leaf aggregate, we don't descend into nested leaf aggregates * when calculating the filesystem path of an aggregate which is built from a leaf, we always assume that it has a single parent -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #594
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/594/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #594
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/594/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Models Integration Tests #594
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.models.integration-tests/594/
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Resource Access Security Integration Tests #594
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/594/
Jenkins build is still unstable: sling-trunk-1.7 #594
See https://builds.apache.org/job/sling-trunk-1.7/changes
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2220
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2220/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2220
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2220/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2220
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2220/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Event Support #2220
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2220/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Models Integration Tests #2220
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2220/
Jenkins build is still unstable: sling-trunk-1.6 #2220
See https://builds.apache.org/job/sling-trunk-1.6/changes
