[jira] [Commented] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661850#comment-14661850 ] Carsten Ziegeler commented on SLING-4930: - Simplified the inventory printer handling in rev 1694686 InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4897) Sling Web Console - Log Tail Plugin
[ https://issues.apache.org/jira/browse/SLING-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-4897. Resolution: Fixed Assignee: Bertrand Delacretaz I have committed your contribution in revision 1694685, many thanks! In revision 1694687 I moved the bundle resources under /libs/sling/logtail-plugin to be more specific and avoid potentiall collisions. Sling Web Console - Log Tail Plugin --- Key: SLING-4897 URL: https://issues.apache.org/jira/browse/SLING-4897 Project: Sling Issue Type: New Feature Components: Console Reporter: Varun Nagpal Assignee: Bertrand Delacretaz Labels: patch Attachments: sling-logtail.zip This issue tracks the introduction of a Log Tail Plugin for the Sling Log Web Console under /contrib As the name suggests, the plugin simulates the behaviour of the UNIX shell tail command and follows the server logs outputting on browser allowing for ease of log monitoring in remote systems. The plugin code depends on logback implementations and is sling independent currently. Relevant mail archive thread: http://apache-sling.73963.n3.nabble.com/Sling-Web-Console-Log-Tail-Plugin-td4050756.html External github src link: https://github.com/vnagpal81/sling-logtail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4931) Allow the script cache to observe other paths than search paths
Radu Cotescu created SLING-4931: --- Summary: Allow the script cache to observe other paths than search paths Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4931) Allow the script cache to observe other paths than search paths
[
https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661651#comment-14661651
]
Radu Cotescu commented on SLING-4931:
-
I'm referring to scripts handled by {{javax.script.ScriptEngine}}s, like the
ECMA scripts from CQ's workflow engine.
Allow the script cache to observe other paths than search paths
---
Key: SLING-4931
URL: https://issues.apache.org/jira/browse/SLING-4931
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
There are cases when a script resides outside of search paths, in which case
custom locations should be allowed to be added to the Script Cache Event
Handler implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE RESULT] Release Apache Sling Provisioning Model 1.3.0 and Slingstart Maven Plugin 1.3.0
Vote passed with three binding +1 votes. Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661648#comment-14661648 ] Bertrand Delacretaz commented on SLING-4931: Scripts outside of search paths sounds scary, all executable scripts should be under well specified paths for security reasons - can you elaborate? Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [vote] Accept the contribution of Log Tail Plugin tracked in SLING-4897
Hi Bertrand, I have received the acceptance mail from Craig stating that the ICLA has been filed. Please let me know the further steps to take. Thanks. -- Varun On Thu, Aug 6, 2015 at 4:16 PM, Varun Nagpal varun.nag...@gmail.com wrote: Thanks Bertrand, Chetan and Robert for the +1s @Bertrand, I have mailed the iCLA. Awaiting further instructions. Thanks. -- Varun On Tue, Aug 4, 2015 at 7:08 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Wed, Jul 22, 2015 at 4:15 PM, Varun Nagpal varun.nag...@gmail.com wrote: This thread is about voting for the acceptance of the Log Tail Plugin tracked in SLING-4897... +1 for the donation - with this we have 3 +1s from PMC members so we can go on. Varun, could you submit an iCLA as per https://www.apache.org/licenses/icla.txt ? Once that's filed we can commit your patch, as it's a fairly small contribution I don't think a software grant is required. -Bertrand
[jira] [Closed] (SLING-4879) Slingstart Maven Plugin: Allow to read variables from POM
[ https://issues.apache.org/jira/browse/SLING-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4879. --- Slingstart Maven Plugin: Allow to read variables from POM - Key: SLING-4879 URL: https://issues.apache.org/jira/browse/SLING-4879 Project: Sling Issue Type: New Feature Components: Maven Plugins and Archetypes Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Sling Provisioning Model 1.3.0, Slingstart Maven Plugin 1.3.0 by default provisioning variables can only be resolved by a variables section defined inside the provisioning file. if processed by the slingstart maven plugin it should be optionally possible to reference variables defined within the pom from which the plugin is executed. additionally it should be possible to attach an resolved (effective model) with those variables replaced when storing it as artifact. this is useful if the same property is required within the POM and the provisioning file and avoids haven to define and maintain it in two locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4807) Variables in configurations are not replaced
[ https://issues.apache.org/jira/browse/SLING-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4807. --- Variables in configurations are not replaced Key: SLING-4807 URL: https://issues.apache.org/jira/browse/SLING-4807 Project: Sling Issue Type: Bug Components: Tooling Affects Versions: Sling Provisioning Model 1.0.0, Sling Provisioning Model 1.1.0, Sling Provisioning Model 1.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.3.0 If a configuration contains variables, these are not replaced. We should add support for it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661621#comment-14661621 ] Bertrand Delacretaz commented on SLING-4930: In revision 1694647 I have kept only the mappings by user section, thinking about it the raw mappings are redundant, it's the same information. InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661654#comment-14661654 ] Bertrand Delacretaz commented on SLING-4931: Ah ok makes sense, thanks for clarifying. Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4880) Slingstart Maven Plugin: Allow to get artifact versions from POM
[ https://issues.apache.org/jira/browse/SLING-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4880. --- Slingstart Maven Plugin: Allow to get artifact versions from POM Key: SLING-4880 URL: https://issues.apache.org/jira/browse/SLING-4880 Project: Sling Issue Type: New Feature Components: Maven Plugins and Archetypes, Tooling Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Sling Provisioning Model 1.3.0, Slingstart Maven Plugin 1.3.0 Currently it is possible to define an exact artifact version in a provisioning file, or define now version, LATEST is used in this case automatically. When no explicit version is defined in the provisioning file it should be optionally possible to use the version defined in the dependency or dependencyManagement section of the maven projects POM file. This is especially useful if the dependency is there defined anyway and should not have to be set and maintained on two locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661671#comment-14661671 ] Carsten Ziegeler edited comment on SLING-4931 at 8/7/15 11:35 AM: -- Why are these outside of the search paths? All code should be in a single place which is by definition at one of the search paths. It doesn't matter what it is used for. Spreading around the code in the resource tree is not a good idea was (Author: cziegeler): Why are these outside of the search paths? Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4912) Support inlining the model in the pom
[ https://issues.apache.org/jira/browse/SLING-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4912. --- Support inlining the model in the pom - Key: SLING-4912 URL: https://issues.apache.org/jira/browse/SLING-4912 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.0 While it is nice to have the models in a separate file as the maven pom, especially for small models it would be nice to inline the model in the pom. This allows to create projects consisting of a single file. I suggest we process such an inlined model first, followed by the files from the directory (if there are any) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4936) Enhance the Sling Script Cache to only cache scripts from the search path
Radu Cotescu created SLING-4936:
---
Summary: Enhance the Sling Script Cache to only cache scripts from
the search path
Key: SLING-4936
URL: https://issues.apache.org/jira/browse/SLING-4936
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
The {{ScriptCache}} implementation should not cache scripts which are not
stored in any of the configured search paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4936) Enhance the Sling Script Cache to only cache scripts from the search paths
[
https://issues.apache.org/jira/browse/SLING-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-4936:
Summary: Enhance the Sling Script Cache to only cache scripts from the
search paths (was: Enhance the Sling Script Cache to only cache scripts from
the search path)
Enhance the Sling Script Cache to only cache scripts from the search paths
--
Key: SLING-4936
URL: https://issues.apache.org/jira/browse/SLING-4936
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
The {{ScriptCache}} implementation should not cache scripts which are not
stored in any of the configured search paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4930: --- Assignee: Carsten Ziegeler (was: Bertrand Delacretaz) InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4930. - Resolution: Fixed Changed in rev 1694670 Resolving this one as we can open new issues for new features InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4934) Sling Mock: Embed transitive dependencies
Konrad Windszus created SLING-4934: -- Summary: Sling Mock: Embed transitive dependencies Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4931) Allow the script cache to observe other paths than search paths
[
https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661792#comment-14661792
]
Radu Cotescu commented on SLING-4931:
-
Probably because people were not considerate when they implemented this
functionality a few years ago. However I figured out that the core issue can be
fixed locally, without having to modify the Script Cache's Event Handler.
Sling itself doesn't enforce from what kind of resources a {{SlingScript}} can
be obtained. Therefore you could create a {{SlingScript}} with a fake resource,
because the {{SlingScriptAdapterFactory}} doesn't check a resource's path
against the configured search paths.
Allow the script cache to observe other paths than search paths
---
Key: SLING-4931
URL: https://issues.apache.org/jira/browse/SLING-4931
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
There are cases when a script resides outside of search paths, in which case
custom locations should be allowed to be added to the Script Cache Event
Handler implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-4931. - Resolution: Won't Fix Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661794#comment-14661794 ] Bertrand Delacretaz commented on SLING-4931: Actually I think you can create a SlingScript from any resource, whatever its path - so we don't currently have a limitation on where scripts can be executed from. I agree that it's best not to implement what was suggested here, but if we really want to limit where scripts come from we need other changes. Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4934: --- Description: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. (was: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.) Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661695#comment-14661695 ] Carsten Ziegeler commented on SLING-4930: - We should make the import also dynamic and register the service as a service factory (as we do at other places). This way the start order does not play a role and the printer is available even if the inventory bundle is started/resolved after the mapper. If you want I can take care of this InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
Konrad Windszus created SLING-4932:
--
Summary: Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory :
no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4932:
---
Issue Type: Improvement (was: Bug)
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4934: --- Description: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. (was: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.) Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4934: --- Description: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. (was: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.) Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4930) InventoryPrinter for Service User Mappings
[ https://issues.apache.org/jira/browse/SLING-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661720#comment-14661720 ] Bertrand Delacretaz commented on SLING-4930: ok, feel free to improve this! I also looked at outputting the ACLs of the service users, but I'm not sure how to do that efficiently, if you have examples I could use them. InventoryPrinter for Service User Mappings -- Key: SLING-4930 URL: https://issues.apache.org/jira/browse/SLING-4930 Project: Sling Issue Type: Improvement Components: Service User Mapper Affects Versions: Service User Mapper 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Service User Mapper 1.2.2 There's currently no simple way to list the configured service user mappings - we should provide an InventoryPrinter to be able to get that info from the OSGi console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4931) Allow the script cache to observe other paths than search paths
[
https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661651#comment-14661651
]
Radu Cotescu edited comment on SLING-4931 at 8/7/15 12:15 PM:
--
I'm referring to scripts handled by {{javax.script.ScriptEngine}}, like the
ECMA scripts from CQ's workflow engine.
was (Author: radu.cotescu):
I'm referring to scripts handled by {{javax.script.ScriptEngine}}s, like the
ECMA scripts from CQ's workflow engine.
Allow the script cache to observe other paths than search paths
---
Key: SLING-4931
URL: https://issues.apache.org/jira/browse/SLING-4931
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
There are cases when a script resides outside of search paths, in which case
custom locations should be allowed to be added to the Script Cache Event
Handler implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4933) Dependency to inventory api should be optional
Carsten Ziegeler created SLING-4933: --- Summary: Dependency to inventory api should be optional Key: SLING-4933 URL: https://issues.apache.org/jira/browse/SLING-4933 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Event 3.7.4 Reporter: Carsten Ziegeler Fix For: Event 3.7.6 If the inventory api is not available, the event bundle does not resolve. This dependency should be optional -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4933) Dependency to inventory api should be optional
[ https://issues.apache.org/jira/browse/SLING-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4933. - Resolution: Fixed Assignee: Carsten Ziegeler Fixed in rev 1694677 Dependency to inventory api should be optional -- Key: SLING-4933 URL: https://issues.apache.org/jira/browse/SLING-4933 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Event 3.7.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Event 3.7.6 If the inventory api is not available, the event bundle does not resolve. This dependency should be optional -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Sling JCR Mocks, testing dependencies and imported ranges
Actually this does also affect sling-mocks IMHO (please compare with https://issues.apache.org/jira/browse/SLING-4932 https://issues.apache.org/jira/browse/SLING-4932). Therefore I suggest to also do the embedding in sling-mocks (https://issues.apache.org/jira/browse/SLING-4934 https://issues.apache.org/jira/browse/SLING-4934). Usually in our projects we have one big dependency management section reflecting the actual versions being running in Apache Felix (i.e. the runtime version). This may be newer versions than the ones sling-mocks is using. Unfortunately the dependency management does also affect the transitive dependencies of sling-mock at run-time (i.e. while executing the tests). Anything speaks against embedding all transitive dependencies there? Konrad On 11 Jun 2015, at 16:43, Stefan Seifert sseif...@pro-vision.de wrote: 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/
[jira] [Created] (SLING-4935) Rhino scripts not based on repository resource will not get cached correctly by the Sling Script Cache
Radu Cotescu created SLING-4935:
---
Summary: Rhino scripts not based on repository resource will not
get cached correctly by the Sling Script Cache
Key: SLING-4935
URL: https://issues.apache.org/jira/browse/SLING-4935
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting JavaScript 2.0.20
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting JavaScript 2.0.22
Rhino scripts not based on repository resources will not get cached correctly
by the Sling Script Cache since their default name will be set to the value of
the
{{org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine#NO_SCRIPT_NAME}}
constant.
The first such script will get cached and attempts to run similar scripts
afterwards will always return the first compiled script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
