[jira] [Updated] (SLING-4797) Improve handling of Move events
[ https://issues.apache.org/jira/browse/SLING-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4797: --- Description: In case you are moving a node with a lot of subnodes, this leads to a distributed deletion of the node, followed by the distributed addition of the node with all subnodes. To improve the performance it would be good, if the move operation would really be distributed through a move event, which means that each receiver would try to move the node (instead of first deleting it and then adding it with all its subnodes). was: In case you are moving a node with a lot of subnodes, this leads to a distributed deletion of the node, followed by the distributed addition of the node with all subnodes. To improve the performance it would be good, if the move operation would really by distributed by a move event, which means that each receiver would try to move the node (instead of first deleting it and then adding it with all its subnodes). Improve handling of Move events --- Key: SLING-4797 URL: https://issues.apache.org/jira/browse/SLING-4797 Project: Sling Issue Type: Improvement Components: Distribution Affects Versions: Content Distribution Core 0.1.4 Reporter: Konrad Windszus In case you are moving a node with a lot of subnodes, this leads to a distributed deletion of the node, followed by the distributed addition of the node with all subnodes. To improve the performance it would be good, if the move operation would really be distributed through a move event, which means that each receiver would try to move the node (instead of first deleting it and then adding it with all its subnodes). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
+1 (non-binding) here is a workaround when using the slingstart-maven-plugin for generating the files if you do not want the multilines in config files: plugin groupIdorg.apache.sling/groupId artifactIdslingstart-maven-plugin/artifactId extensionstrue/extensions version1.2.0/version dependencies dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.configadmin/artifactId version1.8.4/version /dependency /dependencies /plugin worked for me. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Thursday, June 11, 2015 8:07 AM To: dev@sling.apache.org Subject: Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0 Am 10.06.15 um 22:41 schrieb Stefan Seifert: i've a problem with this new release. in rev. 1684389 you updated the dependency on org.apache.felix.configadmin from 1.2.8 to 1.8.6. the problem is that this version always writes osgi config files with arrays in multiple lines - and if such a version is deployed to a felix instance with an older version org.apache.felix.configadmin 1.8.4 or below the configuration cannot be read and is ignored. thus this slingstart plugin version only supports instances with the very latest configadmin - is this intended? Yes, this is really unfortunate. However, you don't need the latest configadmin but the lastest OSGi installer core (I've started a vote for that because of exactly this reason). I don't think this is a blocker for this release, we can decide whether we're fine with this and if not find a solution and release updated versions. I agree that this coupling is not nice and is usually not what we do. However, I don't see a good solution for this. The new format is really very handy for making a diff with multi value properties, so I really want this :) If we want to stay 100% compatible, it would mean, we only support reading the new format but always write out the old format - and in that case we'll never take advantage of it. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
Am 11.06.15 um 11:43 schrieb Stefan Seifert: +1 (non-binding) here is a workaround when using the slingstart-maven-plugin for generating the files if you do not want the multilines in config files: plugin groupIdorg.apache.sling/groupId artifactIdslingstart-maven-plugin/artifactId extensionstrue/extensions version1.2.0/version dependencies dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.configadmin/artifactId version1.8.4/version /dependency /dependencies /plugin worked for me. Right, that solves it as well. Thanks for mentioning this, I'll update the docs accordingly Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
Am 11.06.15 um 11:02 schrieb Bertrand Delacretaz: Hi, On Thu, Jun 11, 2015 at 8:07 AM, Carsten Ziegeler cziege...@apache.org wrote: ...you don't need the latest configadmin but the lastest OSGi installer core (I've started a vote for that because of exactly this reason). I don't think this is a blocker for this release, we can decide whether we're fine with this and if not find a solution and release updated versions I'm trying to understand the issue, what's the failure scenario if a Sling instance is running a version of installer core that's too old? I saw the SLING-4793 / http://svn.apache.org/r1684563 changes to the installer but that doesn't say much. Configurations with multi values are missing. Again, I don't think that is a huge problem - we can add a check to the maven plugin to fail the build of installer core is below a specific version Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4793) Support new format from Apache Felix config admin
[ https://issues.apache.org/jira/browse/SLING-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581702#comment-14581702 ] Bertrand Delacretaz commented on SLING-4793: Do you have more details on what this new format is? A reference to the corresponding FELIX- ticket might be good enough if that explains it. Support new format from Apache Felix config admin - Key: SLING-4793 URL: https://issues.apache.org/jira/browse/SLING-4793 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: Installer Core 3.6.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.6.6 With version 1.8.6 of the config admin implementation, an improved format for multi values has been introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] sling pull request: SLING-4777 separate model provider
Github user asfgit closed the pull request at: https://github.com/apache/sling/pull/95 --- 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. ---
Re: [VOTE] Release Apache Sling Default POST Servlets 2.3.8
+1, Cheers, Stefan On 6/11/15 10:58 AM, Antonio Sanso asa...@adobe.com wrote: Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12328043 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1260 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1260 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
Jenkins build is still unstable: sling-trunk-1.8 #1202
See https://builds.apache.org/job/sling-trunk-1.8/changes
Jenkins build is still unstable: sling-trunk-1.8 #1203
See https://builds.apache.org/job/sling-trunk-1.8/changes
[VOTE] Release Apache Sling Default POST Servlets 2.3.8
Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12328043 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1261 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1261 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Created] (SLING-4799) ConfigAdmin format for multi values has changed, clarify the impact
Bertrand Delacretaz created SLING-4799: -- Summary: ConfigAdmin format for multi values has changed, clarify the impact Key: SLING-4799 URL: https://issues.apache.org/jira/browse/SLING-4799 Project: Sling Issue Type: Task Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz SLING-4793 introduces a change in the installer core to support a new format for loading and saving OSGi configs from files, where multi values use an improved but different format. An example failure scenario is given below, and we might have other similar issues with Crankstart and in upgrade scenarios - we need to find out more about those potential issues. Failure scenario: * I create a Sling Launchpad using the latest slingstart plugin * The provisioning model includes configs with multi values * The provisioning model includes an installer core bundle that is too old * Configs with multi values will then be ignored -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4793) Support new format from Apache Felix config admin
[ https://issues.apache.org/jira/browse/SLING-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581746#comment-14581746 ] Carsten Ziegeler commented on SLING-4793: - The changes are described in FELIX-4844 Support new format from Apache Felix config admin - Key: SLING-4793 URL: https://issues.apache.org/jira/browse/SLING-4793 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: Installer Core 3.6.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.6.6 With version 1.8.6 of the config admin implementation, an improved format for multi values has been introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #166
See https://builds.apache.org/job/sling-contrib-1.7/166/
[jira] [Commented] (SLING-4777) Decouple the model provider from the actual validation service
[ https://issues.apache.org/jira/browse/SLING-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581719#comment-14581719 ] ASF GitHub Bot commented on SLING-4777: --- Github user asfgit closed the pull request at: https://github.com/apache/sling/pull/95 Decouple the model provider from the actual validation service -- Key: SLING-4777 URL: https://issues.apache.org/jira/browse/SLING-4777 Project: Sling Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Validation 1.0.0 As being mentioned in SLING-4027, it would be good to completely decouple the model providing capabilities from the actual validation, as that would a) make the codebase cleaner (and would ease testing) b) allow to plug-in other services which provide models (e.g. based on annotations on some files) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4777) Decouple the model provider from the actual validation service
[ https://issues.apache.org/jira/browse/SLING-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-4777. Resolution: Fixed Applied the PR with some minor changes in rev 1684841. Decouple the model provider from the actual validation service -- Key: SLING-4777 URL: https://issues.apache.org/jira/browse/SLING-4777 Project: Sling Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Validation 1.0.0 As being mentioned in SLING-4027, it would be good to completely decouple the model providing capabilities from the actual validation, as that would a) make the codebase cleaner (and would ease testing) b) allow to plug-in other services which provide models (e.g. based on annotations on some files) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4799) ConfigAdmin format for multi values has changed, clarify the impact
[
https://issues.apache.org/jira/browse/SLING-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581744#comment-14581744
]
Bertrand Delacretaz commented on SLING-4799:
[~sseif...@pro-vision.de] mentions the following workaround to force the
slingstart plugin to use the old format:
{code}
plugin
groupIdorg.apache.sling/groupId
artifactIdslingstart-maven-plugin/artifactId
extensionstrue/extensions
version1.2.0/version
dependencies
dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.configadmin/artifactId
version1.8.4/version
/dependency
/dependencies
/plugin
{code}
ConfigAdmin format for multi values has changed, clarify the impact
---
Key: SLING-4799
URL: https://issues.apache.org/jira/browse/SLING-4799
Project: Sling
Issue Type: Task
Components: Launchpad
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
SLING-4793 introduces a change in the installer core to support a new format
for loading and saving OSGi configs from files, where multi values use an
improved but different format.
An example failure scenario is given below, and we might have other similar
issues with Crankstart and in upgrade scenarios - we need to find out more
about those potential issues.
Failure scenario:
* I create a Sling Launchpad using the latest slingstart plugin
* The provisioning model includes configs with multi values
* The provisioning model includes an installer core bundle that is too old
* Configs with multi values will then be ignored
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE] Release Apache Sling Default POST Servlets 2.3.8
Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12328043 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1260 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1260 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
Am 11.06.15 um 11:15 schrieb Bertrand Delacretaz: On Thu, Jun 11, 2015 at 11:07 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 11.06.15 um 11:02 schrieb Bertrand Delacretaz: ...what's the failure scenario if a Sling instance is running a version of installer core that's too old?... Configurations with multi values are missing Sorry but I still don't understand exactly when that happens, is that: -I create a Sling Launchpad using the latest slingstart plugin -The provisioning model includes configs with multi values -The provisioning model includes an installer core bundle that is too old -Configs with multi values will be ignored Is this what happens? Yepp ...we can add a check to the maven plugin to fail the build of installer core is below a specific version... Maybe, but I'm working on converting Crankstart to use the provisioning model, and we might have different, more dynamic failure scenarios there - we might need runtime detection of that issue then. True, but right now we don't have any - so for example you put in an invalid configuration in the model which can't be parsed, then you end up in the same scenario. And that happens already today. And this also happened before we had the provisioning model. I'm not saying we shouldn't do this, all I'm trying to say is that the situation is as good or as bad as before. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[CANCELLING] [VOTE] Release Apache Sling Default POST Servlets 2.3.8
something went wrong with the artifact signature… respinning the process regards antonio On Jun 11, 2015, at 10:58 AM, Antonio Sanso asa...@adobe.com wrote: Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12328043 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1260 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1260 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
Hi, On Thu, Jun 11, 2015 at 8:07 AM, Carsten Ziegeler cziege...@apache.org wrote: ...you don't need the latest configadmin but the lastest OSGi installer core (I've started a vote for that because of exactly this reason). I don't think this is a blocker for this release, we can decide whether we're fine with this and if not find a solution and release updated versions I'm trying to understand the issue, what's the failure scenario if a Sling instance is running a version of installer core that's too old? I saw the SLING-4793 / http://svn.apache.org/r1684563 changes to the installer but that doesn't say much. -Bertrand
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
On Thu, Jun 11, 2015 at 11:07 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 11.06.15 um 11:02 schrieb Bertrand Delacretaz: ...what's the failure scenario if a Sling instance is running a version of installer core that's too old?... Configurations with multi values are missing Sorry but I still don't understand exactly when that happens, is that: -I create a Sling Launchpad using the latest slingstart plugin -The provisioning model includes configs with multi values -The provisioning model includes an installer core bundle that is too old -Configs with multi values will be ignored Is this what happens? ...we can add a check to the maven plugin to fail the build of installer core is below a specific version... Maybe, but I'm working on converting Crankstart to use the provisioning model, and we might have different, more dynamic failure scenarios there - we might need runtime detection of that issue then. -Bertrand
[jira] [Resolved] (SLING-4027) Improvement of the validation API
[ https://issues.apache.org/jira/browse/SLING-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-4027. Resolution: Fixed Improvement of the validation API - Key: SLING-4027 URL: https://issues.apache.org/jira/browse/SLING-4027 Project: Sling Issue Type: Improvement Components: Validation Reporter: Carsten Ziegeler Assignee: Konrad Windszus Fix For: Validation 1.0.0 Some comments / thoughts about the validation api: a) Why is there a validator lookup service? I don't think we need this in the API - it's a simple OSGI service lookup. b) A Validator can only validate a single value - what if a property is an array and the validation needs to validate based on all supplied values? Same goes with dependencies between two properties? c) The Validator interface returns null on success and a String (message) if validation fails. But it can also throw an exception if e.g. the provided value is null. I think a null value should be treated the same as a wrong value. Throwing the exception if some configuration like the regexp for the regexp validator is missing, is fine. but all errors of validating a value should be treated the same. d) NonExistingTypeException I don't think we need this - IllegalArgumentException is fine to throw from the type enumeration e) Maybe we can also remove the SlingValidationException - it is only thrown (see c) if a validator does not get its required configuration - which can be seen as an IllegalStateException f) It would be nice to have a ValidationModelProvider interface - we will then have the current way of defining models as the default implememtation. But can allow other means of defining the validation model -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4027) Improvement of the validation API
[ https://issues.apache.org/jira/browse/SLING-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581729#comment-14581729 ] Konrad Windszus commented on SLING-4027: f) was solved in SLING-4777. Since all the points mentioned here have been addressed in related issues I consider this fixed. Improvement of the validation API - Key: SLING-4027 URL: https://issues.apache.org/jira/browse/SLING-4027 Project: Sling Issue Type: Improvement Components: Validation Reporter: Carsten Ziegeler Assignee: Konrad Windszus Fix For: Validation 1.0.0 Some comments / thoughts about the validation api: a) Why is there a validator lookup service? I don't think we need this in the API - it's a simple OSGI service lookup. b) A Validator can only validate a single value - what if a property is an array and the validation needs to validate based on all supplied values? Same goes with dependencies between two properties? c) The Validator interface returns null on success and a String (message) if validation fails. But it can also throw an exception if e.g. the provided value is null. I think a null value should be treated the same as a wrong value. Throwing the exception if some configuration like the regexp for the regexp validator is missing, is fine. but all errors of validating a value should be treated the same. d) NonExistingTypeException I don't think we need this - IllegalArgumentException is fine to throw from the type enumeration e) Maybe we can also remove the SlingValidationException - it is only thrown (see c) if a validator does not get its required configuration - which can be seen as an IllegalStateException f) It would be nice to have a ValidationModelProvider interface - we will then have the current way of defining models as the default implememtation. But can allow other means of defining the validation model -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4799) ConfigAdmin format for multi values has changed, clarify the impact
[ https://issues.apache.org/jira/browse/SLING-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4799: --- Description: SLING-4793 introduces a change in the installer core to support a new format for loading and saving OSGi configs from files, where multi values use an improved but different format (FELIX-4844). An example failure scenario is given below, and we might have other similar issues with Crankstart and in upgrade scenarios - we need to find out more about those potential issues. Failure scenario: * I create a Sling Launchpad using the latest slingstart plugin * The provisioning model includes configs with multi values * The provisioning model includes an installer core bundle that is too old * Configs with multi values will then be ignored was: SLING-4793 introduces a change in the installer core to support a new format for loading and saving OSGi configs from files, where multi values use an improved but different format. An example failure scenario is given below, and we might have other similar issues with Crankstart and in upgrade scenarios - we need to find out more about those potential issues. Failure scenario: * I create a Sling Launchpad using the latest slingstart plugin * The provisioning model includes configs with multi values * The provisioning model includes an installer core bundle that is too old * Configs with multi values will then be ignored ConfigAdmin format for multi values has changed, clarify the impact --- Key: SLING-4799 URL: https://issues.apache.org/jira/browse/SLING-4799 Project: Sling Issue Type: Task Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz SLING-4793 introduces a change in the installer core to support a new format for loading and saving OSGi configs from files, where multi values use an improved but different format (FELIX-4844). An example failure scenario is given below, and we might have other similar issues with Crankstart and in upgrade scenarios - we need to find out more about those potential issues. Failure scenario: * I create a Sling Launchpad using the latest slingstart plugin * The provisioning model includes configs with multi values * The provisioning model includes an installer core bundle that is too old * Configs with multi values will then be ignored -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582029#comment-14582029
]
Stefan Seifert commented on SLING-4779:
---
we could even make it more compact and include only the one class (and inner
class) that is required, not the whole package.
i just saw such a solution in \[1\] for the ConfigurationHandler of
{{org.apache.felix.configadmin}}.
\[1\]
https://svn.apache.org/repos/asf/sling/trunk/tooling/support/provisioning-model/pom.xml
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4781) Implement MockBundle.getEntryPaths
[
https://issues.apache.org/jira/browse/SLING-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582021#comment-14582021
]
Stefan Seifert commented on SLING-4781:
---
the goal is to be as close to the contract defined of the OSGi Bundle API as
possible, even it it breaks with an earlier release of the mock.
the javadocs of Bundle.getEntry state:
{quote}
The specified path is always relative to the root of this bundle and may begin
with /. A path value of / indicates the root of this bundle.
{quote}
in my interpretation that means a path is always absolute, and if a / is
missing it should be added before calling {{getClass().getResource()}}.
Implement MockBundle.getEntryPaths
--
Key: SLING-4781
URL: https://issues.apache.org/jira/browse/SLING-4781
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing OSGi Mock 1.3.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Testing OSGi Mock 1.4.0
The MockBundle already supports the {{getEntry}} method, but not
{{getEntryPaths}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #167
See https://builds.apache.org/job/sling-contrib-1.7/changes
RE: Sling JCR Mocks, testing dependencies and imported ranges
hello robert. to clarify for the others, this does not affect the primary mocks jcr-mock and sling-mock, but only if you want to use one of the (more experimental) mocks with real repository underneath, namely sling-mock-jackrabbit and sling-mock-oak. for most usecases the resourcresolver-mock or jcr-mock will suffice and has not this problem. but if a real repository like oak or jackrabbit is required one hits the problem as described by robert. 1+2 are real no options, 3 is quite inconvenient and complicates code coverage checks a lot. yes, embedding the oak/jackrabbit dependencies in the sling-mock-jackrabbit/sling-mock-oak artifacts could be a good option. the only small drawback i see is the bloating of the JAR file. perhaps we should give it a try. stefan -Original Message- From: Robert Munteanu [mailto:romb...@apache.org] Sent: Wednesday, June 10, 2015 5:08 PM To: Sling Dev Subject: Sling JCR Mocks, testing dependencies and imported ranges Hi, I'm starting to be very much convinced that the Sling Mocks are the simplest way to add fast, repository and OSGi-enabled tests. Since they are executed out-of-container, they can live in the same module as the code under test. One conflict that I found with this approach is that while the Sling JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require recent versions of jackrabbit ( api, commons ), while we typically aim to keep the dependency versions as low as possible. One example is the recent change I added to the jcr.contentloader module [1], bumping the jackrabbit-api version from 2.2.0 to 2.10.1 (!). I have considered various approaches, but none of them looks good. 1. Declaring two dependencies with different scopes - used to work with Maven 3, no longer works with Maven 2. 2. Just live with the more strict import range - a bad idea to restrict bundles from running on older versions just because the tests need new versions. 3. Split the tests in a different module - defies the purpose of having the tests live with the code under test 4. Manually set the import-package versions in the pom.xml file - manual and error-prone Hm ... writing this email I just got the idea of the JCR mocks packaging all dependencies using the maven-shade-plugin [2] so that the actual dependencies used for testing are not the ones used at compile time and implicitly not the ones used to calculate dependencies. This means that for instance org.apache.sling.testing.sling-mock-oak will embed all of oak and the dependendent jackrabbit apis. Thoughts? Alternatives? Thanks, Robert [1]: http://svn.apache.org/viewvc?view=revisionrevision=r1684450 [2]: https://maven.apache.org/plugins/maven-shade-plugin/
Build failed in Jenkins: sling-trunk-1.8 #1204
See https://builds.apache.org/job/sling-trunk-1.8/1204/changes Changes: [bdelacretaz] SLING-4728 - update names and versions, next release will be 2.0.x [bdelacretaz] SLING-4728 - move new Crankstart (that uses provisioning model) under contrib [bdelacretaz] SLING-4728 - keep old Crankstart around, just in case -- [...truncated 39673 lines...] [INFO] Apache Sling JSP Tag Library .. SUCCESS [6.086s] [INFO] Apache Sling JSP Standard Tag Library . SUCCESS [2.354s] [INFO] Apache Sling Scripting Sightly Engine . SUCCESS [14.918s] [INFO] Apache Sling Scripting Sightly JavaScript Use Provider SUCCESS [3.328s] [INFO] Apache Sling Scripting Sightly Read-Eval-Print Loop Environment SUCCESS [2.298s] [INFO] Apache Sling Scripting Sightly Integration Tests Content SUCCESS [5.977s] [INFO] Apache Sling Launchpad Base ... SUCCESS [14.446s] [INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [3.520s] [INFO] Apache Sling Internationalization Support . SUCCESS [1:19.227s] [INFO] Apache Sling Models API ... SUCCESS [3.320s] [INFO] Apache Sling Models Implementation SUCCESS [5.441s] [INFO] Apache Sling XSS Protection Bundle SUCCESS [11.471s] [INFO] Apache Sling Launchpad Application Builder SUCCESS [24.114s] [INFO] Apache Sling Scripting Sightly Integration Tests .. SUCCESS [3:32.503s] [INFO] Apache Sling Scripting Sightly Models Use Provider SUCCESS [4.274s] [INFO] Apache Sling Scripting Sightly Reactor SUCCESS [1.446s] [INFO] Apache Sling Bundle Resource Provider . SUCCESS [3.166s] [INFO] Apache Sling Distributed Event Admin .. SUCCESS [3.718s] [INFO] Apache Sling Discovery API SUCCESS [2.640s] [INFO] Apache Sling Discovery Commons Bundle . SUCCESS [5.534s] [INFO] Apache Sling Resource-Based Discovery Service . FAILURE [52:42.717s] [INFO] Apache Sling Discovery Support Bundle . SKIPPED [INFO] Apache Sling Discovery Standalone Implementation .. SKIPPED [INFO] Apache Sling Event Support SKIPPED [INFO] Apache Sling Feature Flags SKIPPED [INFO] Apache Sling Filesystem Resource Provider . SKIPPED [INFO] Apache Sling javax.activation bundle .. SKIPPED [INFO] Apache Sling Service User Mapper .. SKIPPED [INFO] Apache Sling Settings . SKIPPED [INFO] Apache Sling Web Console Branding . SKIPPED [INFO] Apache Sling Web Console Security Provider SKIPPED [INFO] Apache Sling Explorer . SKIPPED [INFO] Apache Sling Health Check Core SKIPPED [INFO] Apache Sling Health Check Annotations . SKIPPED [INFO] Apache Sling Health Check Samples . SKIPPED [INFO] Apache Sling Health Check Support Components .. SKIPPED [INFO] Apache Sling Health Check Webconsole Plugin ... SKIPPED [INFO] Apache Sling Health Check JUnit Bridge SKIPPED [INFO] Apache Sling Health Check Integration Tests ... SKIPPED [INFO] Apache Sling Health Check Reactor POM . SKIPPED [INFO] Apache Sling Resource Access Security . SKIPPED [INFO] Apache Sling Resource Access Security Integration Tests SKIPPED [INFO] Apache Sling Validation Framework API . SKIPPED [INFO] Apache Sling Validation Framework Core Implementation SKIPPED [INFO] Apache Sling Validation Framework Testing Services SKIPPED [INFO] Apache Sling Validation Framework Integration Tests SKIPPED [INFO] Apache Sling Validation Framework Examples SKIPPED [INFO] Apache Sling Validation Framework Builder . SKIPPED [INFO] Apache Sling Models Validation Implementation . SKIPPED [INFO] Apache Sling Models Integration Tests . SKIPPED [INFO] Apache Sling Test Tools ... SKIPPED [INFO] Apache Sling JUnit Core ... SKIPPED [INFO] Apache Sling JUnit Scriptable Tests Provider .. SKIPPED [INFO] Apache Sling JUnit Health Checks .. SKIPPED [INFO] Apache Sling JUnit Remote Tests Runners ... SKIPPED [INFO] Apache Sling JUnit Performance SKIPPED [INFO] Apache Sling Testing Mock Log Configuration ... SKIPPED [INFO] Apache Sling Testing Resource Resolver Mock ... SKIPPED [INFO] Apache Sling Pax Exam Utilities ... SKIPPED [INFO] Apache Sling Sample Server-Side Tests . SKIPPED [INFO] Apache Sling Failing Server-Side Tests SKIPPED [INFO] Apache Sling Sample Integration Tests . SKIPPED [INFO] Apache Sling Testing Modules Reactor .. SKIPPED [INFO] Apache Sling Installer SKIPPED [INFO] Apache Sling Installer WebConsole Plugin .. SKIPPED [INFO] Apache
Jenkins build is unstable: sling-trunk-1.8 #1205
See https://builds.apache.org/job/sling-trunk-1.8/1205/changes
Re: sling models api + impl 1.2 release soon?
Makes a lot of sense. I will do some more testing with a real project on the most recent SNAPSHOT early next week. If you could start the release process afterwards, that would be great. Konrad On 11 Jun 2015, at 17:52, Stefan Seifert sseif...@pro-vision.de wrote: it's a long time since sling models 1.1 release, and a bunch of new features was added since then. what do you think about making a 1.2.0 release soon? i currently see no outstanding issues assigned to the versions in JIRA, and due to the separation of the validation in a separate bundle we no longer have a dependency to the release of the validation bundle. stefan
Jenkins build is still unstable: sling-contrib-1.7 #169
See https://builds.apache.org/job/sling-contrib-1.7/changes
RE: sling models api + impl 1.2 release soon?
fine - just give notice when you are ready. i'm currently doing the same with the current snapshot in one of our projects. stefan -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Thursday, June 11, 2015 6:26 PM To: dev@sling.apache.org Subject: Re: sling models api + impl 1.2 release soon? Makes a lot of sense. I will do some more testing with a real project on the most recent SNAPSHOT early next week. If you could start the release process afterwards, that would be great. Konrad On 11 Jun 2015, at 17:52, Stefan Seifert sseif...@pro-vision.de wrote: it's a long time since sling models 1.1 release, and a bunch of new features was added since then. what do you think about making a 1.2.0 release soon? i currently see no outstanding issues assigned to the versions in JIRA, and due to the separation of the validation in a separate bundle we no longer have a dependency to the release of the validation bundle. stefan
Build failed in Jenkins: sling-trunk-1.7 #1919
See https://builds.apache.org/job/sling-trunk-1.7/1919/changes Changes: [sseifert] SLING-4773 ensure sling namespace is always registered when using JCR_MOCK resource resolver adapter [sseifert] SLING-4802 JcrMock: Support Session close and isLive methods [bdelacretaz] SLING-4728 - refactor before adding more tests [bdelacretaz] SLING-4728 - work towards passing the Sling Launchpad integration tests -- [...truncated 31056 lines...] [INFO] Apache Sling Scripting JavaScript Support . SUCCESS [1:26.686s] [INFO] Apache Sling Scripting JSP Support SUCCESS [30.159s] [INFO] Apache Sling JSP Tag Library .. SUCCESS [29.033s] [INFO] Apache Sling JSP Standard Tag Library . SUCCESS [1:10.250s] [INFO] Apache Sling Scripting Sightly Engine . SUCCESS [50.194s] [INFO] Apache Sling Scripting Sightly JavaScript Use Provider SUCCESS [1:16.790s] [INFO] Apache Sling Scripting Sightly Read-Eval-Print Loop Environment SUCCESS [58.292s] [INFO] Apache Sling Scripting Sightly Integration Tests Content SUCCESS [48.638s] [INFO] Apache Sling Launchpad Base ... SUCCESS [53.557s] [INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [22.878s] [INFO] Apache Sling Internationalization Support . SUCCESS [1:50.456s] [INFO] Apache Sling Models API ... SUCCESS [40.573s] [INFO] Apache Sling Models Implementation SUCCESS [1:03.497s] [INFO] Apache Sling XSS Protection Bundle SUCCESS [23.645s] [INFO] Apache Sling Launchpad Application Builder SUCCESS [2:14.179s] [INFO] Apache Sling Scripting Sightly Integration Tests .. FAILURE [4:50.668s] [INFO] Apache Sling Scripting Sightly Models Use Provider SKIPPED [INFO] Apache Sling Scripting Sightly Reactor SKIPPED [INFO] Apache Sling Bundle Resource Provider . SKIPPED [INFO] Apache Sling Distributed Event Admin .. SKIPPED [INFO] Apache Sling Discovery API SKIPPED [INFO] Apache Sling Discovery Commons Bundle . SKIPPED [INFO] Apache Sling Resource-Based Discovery Service . SKIPPED [INFO] Apache Sling Discovery Support Bundle . SKIPPED [INFO] Apache Sling Discovery Standalone Implementation .. SKIPPED [INFO] Apache Sling Event Support SKIPPED [INFO] Apache Sling Feature Flags SKIPPED [INFO] Apache Sling Filesystem Resource Provider . SKIPPED [INFO] Apache Sling javax.activation bundle .. SKIPPED [INFO] Apache Sling Service User Mapper .. SKIPPED [INFO] Apache Sling Settings . SKIPPED [INFO] Apache Sling Web Console Branding . SKIPPED [INFO] Apache Sling Web Console Security Provider SKIPPED [INFO] Apache Sling Explorer . SKIPPED [INFO] Apache Sling Health Check Core SKIPPED [INFO] Apache Sling Health Check Annotations . SKIPPED [INFO] Apache Sling Health Check Samples . SKIPPED [INFO] Apache Sling Health Check Support Components .. SKIPPED [INFO] Apache Sling Health Check Webconsole Plugin ... SKIPPED [INFO] Apache Sling Health Check JUnit Bridge SKIPPED [INFO] Apache Sling Health Check Integration Tests ... SKIPPED [INFO] Apache Sling Health Check Reactor POM . SKIPPED [INFO] Apache Sling Resource Access Security . SKIPPED [INFO] Apache Sling Resource Access Security Integration Tests SKIPPED [INFO] Apache Sling Validation Framework API . SKIPPED [INFO] Apache Sling Validation Framework Core Implementation SKIPPED [INFO] Apache Sling Validation Framework Testing Services SKIPPED [INFO] Apache Sling Validation Framework Integration Tests SKIPPED [INFO] Apache Sling Validation Framework Examples SKIPPED [INFO] Apache Sling Validation Framework Builder . SKIPPED [INFO] Apache Sling Models Validation Implementation . SKIPPED [INFO] Apache Sling Models Integration Tests . SKIPPED [INFO] Apache Sling Test Tools ... SKIPPED [INFO] Apache Sling JUnit Core ... SKIPPED [INFO] Apache Sling JUnit Scriptable Tests Provider .. SKIPPED [INFO] Apache Sling JUnit Health Checks .. SKIPPED [INFO] Apache Sling JUnit Remote Tests Runners ... SKIPPED [INFO] Apache Sling JUnit Performance SKIPPED [INFO] Apache Sling Testing Mock Log Configuration ... SKIPPED [INFO] Apache Sling Testing Resource Resolver Mock ... SKIPPED [INFO] Apache Sling Pax Exam Utilities ... SKIPPED [INFO] Apache Sling Sample Server-Side Tests . SKIPPED [INFO] Apache Sling Failing Server-Side Tests SKIPPED [INFO] Apache Sling Sample Integration Tests . SKIPPED [INFO] Apache
Jenkins build is still unstable: sling-contrib-1.7 #170
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-trunk-1.8 #1206
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: i18n: RequestLocaleResolver#resolveLocale(HttpServletRequest request):ListLocale
On Wednesday 10 June 2015 18:17:41 Alexander Klimetschek wrote: On 10.06.2015, at 09:53, Oliver Lietz apa...@oliverlietz.de wrote: is the type of parameter request in resolveLocale(HttpServletRequest request) a bug? Shouldn't that be SlingHttpServletRequest like it is in LocaleResolver and described in javadoc instead? No, this might be called in the filter chain before sling request/response objects are available: https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/ java/org/apache/sling/i18n/impl/I18NFilter.java#L114-L126 I see! Thanks, Alex. So we have to fix the javadoc. O. Cheers, Alex
[jira] [Updated] (SLING-4728) Crankstart should use the Sling Provisioning Model
[ https://issues.apache.org/jira/browse/SLING-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4728: --- Fix Version/s: Crankstart Test Services 2.0.0 Crankstart Launcher 2.0.0 Crankstart should use the Sling Provisioning Model -- Key: SLING-4728 URL: https://issues.apache.org/jira/browse/SLING-4728 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Fix For: Crankstart Launcher 2.0.0, Crankstart Test Services 2.0.0 Crankstart should be converted to use the Sling Provisioning Model that was created in the meantime. This should preserve the following features: Set Initial classpath, select framework version Set defaults for variables, override with system properties Set OSGi framework properties, with variable Install configs early, as soon as ConfigAdmin is available OSGi configs with typed values Guard against multiple factory config creation (CRANKSTART_CONFIG_ID) Ability to register new startup commands mvn:protocol is optional, can also use http log messages during startup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4755) DiscoveryService isn't shutdown aware (Asynchronously sending topology events)
[
https://issues.apache.org/jira/browse/SLING-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4755:
---
Summary: DiscoveryService isn't shutdown aware (Asynchronously sending
topology events) (was: DiscoveryService isn't shutdown aware)
DiscoveryService isn't shutdown aware (Asynchronously sending topology events)
--
Key: SLING-4755
URL: https://issues.apache.org/jira/browse/SLING-4755
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: Discovery Impl 1.0.10
Environment: AEM 6 SP2
Reporter: Ilyas Türkben
Assignee: Stefan Egli
Priority: Blocker
Fix For: Discovery Impl 1.1.6
DiscoveryServiceImpl seems to perform write operations and require repository
reference during a shutdown and it blocks the shutdown for a unpredictable
time(here, almost 26 minutes).
*Error log*
{code:java}
26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl
Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131]
ServiceEvent UNREGISTERING
26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository
Service [5185] ServiceEvent REGISTERED
26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository
Service [5185] ServiceEvent UNREGISTERING
{code}
*Thread dump for Thread-60*
{code:java}
Thread-60 daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable
[0x7f783b0ea000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
at com.mongodb.OutMessage.pipe(OutMessage.java:236)
at com.mongodb.DBPort$1.execute(DBPort.java:140)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked 0x00050a8eee30 (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
at com.mongodb.DBCursor._check(DBCursor.java:458)
at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
at
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
- locked 0x000768234398 (a
com.google.common.cache.LocalCache$StrongAccessEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
at
org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
at
[jira] [Commented] (SLING-4800) If SlingMainServlet has allowTrace = false, default Allow header shouldn't contain TRACE method
[ https://issues.apache.org/jira/browse/SLING-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581944#comment-14581944 ] Justin Edelson commented on SLING-4800: --- proposed patch: https://codereview.appspot.com/247970043 If SlingMainServlet has allowTrace = false, default Allow header shouldn't contain TRACE method --- Key: SLING-4800 URL: https://issues.apache.org/jira/browse/SLING-4800 Project: Sling Issue Type: Bug Components: API, Engine Reporter: Justin Edelson Priority: Minor If the configuration of the SlingMainServlet specifies that the TRACE method isn't allowed, the Allow header in an OPTIONS response from servlets extending the SlingSafeMethodsServlet still contain the TRACE method. This shouldn't be the case. Although technically allowable by the HTTP spec, this behavior isn't ideal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
Am 10.06.15 um 22:41 schrieb Stefan Seifert: i've a problem with this new release. in rev. 1684389 you updated the dependency on org.apache.felix.configadmin from 1.2.8 to 1.8.6. the problem is that this version always writes osgi config files with arrays in multiple lines - and if such a version is deployed to a felix instance with an older version org.apache.felix.configadmin 1.8.4 or below the configuration cannot be read and is ignored. thus this slingstart plugin version only supports instances with the very latest configadmin - is this intended? Yes, this is really unfortunate. However, you don't need the latest configadmin but the lastest OSGi installer core (I've started a vote for that because of exactly this reason). I don't think this is a blocker for this release, we can decide whether we're fine with this and if not find a solution and release updated versions. I agree that this coupling is not nice and is usually not what we do. However, I don't see a good solution for this. The new format is really very handy for making a diff with multi value properties, so I really want this :) If we want to stay 100% compatible, it would mean, we only support reading the new format but always write out the old format - and in that case we'll never take advantage of it. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-4796) Add a simpler way to debug server-side integration tests
Konrad Windszus created SLING-4796:
--
Summary: Add a simpler way to debug server-side integration tests
Key: SLING-4796
URL: https://issues.apache.org/jira/browse/SLING-4796
Project: Sling
Issue Type: Improvement
Affects Versions: org.apache.sling.testing.tools 1.0.10
Reporter: Konrad Windszus
Currently you have to tweak the {{jar.executor.vm.options}} to be able to debug
the server-side part of the integration tests.
Actually the java process is forked twice:
# For the surefire-plugin which executes the client (=Maven) part which can be
debugged like described in
http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html
# In the {{JarExecutor}} which starts the Sling server.
To ease debugging of the server side part of test I could think of two
different options.
# Allow to prevent the 2nd forking (so the Sling server would be executed in
the same Java process as the actual test). That would ease debugging as you
could at the same time debug client-side and server-side code
# Come up with an easy option like {{maven.surefire.debug}} which would
automatically listen on a specific port for a debugger.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4223) Make Content Loader extensible to support new import formats
[
https://issues.apache.org/jira/browse/SLING-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso resolved SLING-4223.
--
Resolution: Fixed
mark as resolved as per http://markmail.org/thread/cwx6wofa6mq2tw5p
Make Content Loader extensible to support new import formats
Key: SLING-4223
URL: https://issues.apache.org/jira/browse/SLING-4223
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Oliver Lietz
Assignee: Tomek Rękawek
Fix For: JCR ContentLoader 2.2.0, Servlets POST 2.3.8
Attachments: SLING-4223.patch
The current Content Loader supports a basic set of import formats which are
identified by extension: {{.xml}}, {{.jcr.xml}}, {{.json}}, {{.jar}} and
{{.zip}}.
There is a [user
request|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3cd0a6198c.20fbeb%25bruce.e...@nextissuemedia.com%3e]
to support custom formats like Adobe Folio and [some ideas how to
implement|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3ca2ab572f-fa83-4ae2-806e-49cce87b9...@adobe.com%3e]:
* we create a new org.apache.sling.contentloader.reader package to be
exported at version 1.0
* move the ContentCreator (@ProviderType) and ContentReader (@ConsumerType)
to that new package
* convert the BaseImportLoader into a standalone ContentReader service holder
used by the DefaultContentImporter and ContentLoaderService components.
* For the ContentReader service interface we define service registration
properties for the service to expose the file name extension (and maybe
content type) the reader supports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4797) Improve handling of Move events
Konrad Windszus created SLING-4797: -- Summary: Improve handling of Move events Key: SLING-4797 URL: https://issues.apache.org/jira/browse/SLING-4797 Project: Sling Issue Type: Improvement Components: Distribution Affects Versions: Content Distribution Core 0.1.4 Reporter: Konrad Windszus In case you are moving a node with a lot of subnodes, this leads to a distributed deletion of the node, followed by the distributed addition of the node with all subnodes. To improve the performance it would be good, if the move operation would really by distributed by a move event, which means that each receiver would try to move the node (instead of first deleting it and then adding it with all its subnodes). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4798) ResourceResolver should extend java.io.Closeable
Robert Munteanu created SLING-4798: -- Summary: ResourceResolver should extend java.io.Closeable Key: SLING-4798 URL: https://issues.apache.org/jira/browse/SLING-4798 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Robert Munteanu Fix For: Resource Resolver 1.2.6 As discussed at [dev@sling : Make ResourceResolver implement Closeable|http://sling-dev.markmail.org/thread/fbvium36fnx6emol], the ResourceResolver should extend java.io.Closeable. This will allow its usage in the try-with-resources statement,while preserving compatibility with older versions ( java.io.Closeable was added in Java 1.5 ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Make ResourceResolver implement Closeable
On Fri, May 29, 2015 at 1:29 PM, Roy Teeuwen r...@teeuwen.be wrote: To come back to my initial question. The closeable interface has been there from Java 1.5, so adding it would do no harm to older versions and would still make it work in Java 1.7+ Good point, filed SLING-4798 [1] Robert [1]: https://issues.apache.org/jira/browse/SLING-4798 Greets Roy On 26 May 2015, at 16:38, Carsten Ziegeler cziege...@apache.org wrote: Am 26.05.15 um 16:14 schrieb Robert Munteanu: Hi Roy, On Tue, 2015-05-26 at 15:51 +0200, Roy Teeuwen wrote: Hello, As of Java 7, it is possible by implementing the Closeable or AutoCloseable to use the try-with-resources statement. This makes the notation a lot shorter than the try-finally block. Is there a reason that the ResourceResolver does not implement the Closeable interface, and would it be possible to let it implement it? We should just move to Java 7 by default. +1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Sent from my (old) computer
[jira] [Comment Edited] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582044#comment-14582044
]
Konrad Windszus edited comment on SLING-4779 at 6/11/15 3:12 PM:
-
Making it even smaller is really dangerous. Because then you would depend on
other classes from the commons-osgi bundle. That would force a dependency of
models-impl to the commons-osgi bundle. And then the SortingServiceTracker
might be provided through both classloaders: the commons-osgi bundle
classloader and through the embedded classloader. Since I don't want to debug
such class loading issues I guess it is just safer to completely embed the
necessary classes from commons-osgi and get rid of the import-package statement
completely! Then you don't run into any conflicts, because then the
commons-osgi classloader is not used at all.
was (Author: kwin):
Making it even smaller is really dangerous. Because then you would depend on
other classes from the commons-osgi bundle. That would force a dependency
models-impl to the commons-osgi bundle. And then the SortingServiceTracker
might be provided through both classloaders: the commons-osgi bundle
classloader and through the embedded classloader. Since I don't want to debug
such class loading issues I guess it is just safer to completely embed the
necessary classes from commons-osgi and get rid of the import-package statement
completely! Then you don't run into any conflicts, because then the
commons-osgi classloader is not used at all.
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #168
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582044#comment-14582044
]
Konrad Windszus commented on SLING-4779:
Making it even smaller is really dangerous. Because then you would depend on
other classes from the commons-osgi bundle. That would force a dependency
models-impl to the commons-osgi bundle. And then the SortingServiceTracker
might be provided through both classloaders: the commons-osgi bundle
classloader and through the embedded classloader. Since I don't want to debug
such class loading issues I guess it is just safer to completely embed the
necessary classes from commons-osgi and get rid of the import-package statement
completely! Then you don't run into any conflicts, because then the
commons-osgi classloader is not used at all.
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4802) JcrMock: Support Session close and isLive methods
Stefan Seifert created SLING-4802: - Summary: JcrMock: Support Session close and isLive methods Key: SLING-4802 URL: https://issues.apache.org/jira/browse/SLING-4802 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing JCR Mock 1.1.6 Reporter: Stefan Seifert Assignee: Stefan Seifert Priority: Minor Fix For: Testing JCR Mock 1.1.8 a simple implementation of a sessions logout and isLive should be supported by simply setting a flag if its live or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582050#comment-14582050
]
Stefan Seifert commented on SLING-4779:
---
ah yes, you're right - forgot about the further dependencies inside
commons.osgi.
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582081#comment-14582081
]
Stefan Seifert commented on SLING-4779:
---
as far as i known felix osgi implementation does not support this when both
bundles have the same symbolic name.
the solution chosen by konrad seems the best to me - no need to deploy
anything, just a few more kb on the jar.
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4773) SlingMocks always returns the value of property jcr:primaryType for Resource.getResourceType()
[
https://issues.apache.org/jira/browse/SLING-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-4773.
---
Resolution: Fixed
Fix Version/s: Testing Sling Mock 1.3.2
Completed: At revision: 1684924
the problem should be solved - i moved the namespace registering part to the
adapter which is the better solution anyways.
please give it a try.
SlingMocks always returns the value of property jcr:primaryType for
Resource.getResourceType()
--
Key: SLING-4773
URL: https://issues.apache.org/jira/browse/SLING-4773
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing Sling Mock 1.3.0
Reporter: Konrad Windszus
Assignee: Stefan Seifert
Fix For: Testing Sling Mock 1.3.2
Attachments: SLING-4773-testcase-v1.diff
Even if a resource was created with {{sling:resourceType}} being set to some
value calling {{Resource.getResourceType()}} will always return the value of
its jcr:primaryType property, even if the sling:resourceType property is
being set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582074#comment-14582074
]
Oliver Lietz commented on SLING-4779:
-
Why not deploy {{2.2.x}} *and* {{2.3.x}} of {{org.apache.sling.commons.osgi}}
as it's just a lib? Is package {{org.apache.sling.commons.osgi.bundleversion}}
with same version in 2.2 and 2.3 a problem?
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Sling Models Impl 1.2.0
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
