Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Carsten Ziegeler]

Chetan Mehrotra wrote
> On Mon, Oct 3, 2016 at 9:37 PM, Carsten Ziegeler  wrote:
>> For example, if you drop a file through webdav, I assume it's still
>> nt:Resource.
> 
> Had a look at the Webdav stuff and story here looks interesting. The
> default implementation in Jackrabbit uses nt:unstructured for the
> jcr:content node [1] however Sling integration changes the default to
> 'nt:resource' [2]. Not sure why they differ. But changing here should
> be simply specifying a new OSGi config or changing the default OSGi
> config.
> 
> I know its case by case basis change but I am not able to figure out
> any easy way out here :(
> 

What about if the node type is changed by default in Oak? This seems to
be according to the spec.
The problem might then only be with old installations and for this you
can provide a switch. Maybe somehow even detecting the situation.

I fear we're creating a monster of configurations here and there,
although the problem itself can be easily solved at the base.

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Build failed in Jenkins: sling-extensions-hapi-client-1.8 #1

[Robert Munteanu]

Please ignore the hapi failures for know, I specified an incorrect SVN
root.

Robert

On Mon, 2016-10-03 at 17:15 +, Apache Jenkins Server wrote:
> See  />
> 
> --
> [...truncated 48 lines...]
>   at hudson.model.Executor.run(Executor.java:410)
> Caused by: hudson.remoting.ProxyException: java.io.IOException:
> Failed to check out https://svn.apache.org/repos/asf/sling/trunk/exte
> nsions/hapi/client
>   at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:
> 130)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:162)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:170)
>   at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.ja
> va:134)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:162)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:996)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
>   at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2772)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:153)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:50)
>   at hudson.remoting.Request$2.run(Request.java:332)
>   at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecut
> orService.java:68)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1145)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> .java:615)
>   at java.lang.Thread.run(Thread.java:745)
>   at ..remote call to ubuntu-2(Native Method)
>   at
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
>   at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
>   at hudson.remoting.Channel.call(Channel.java:781)
>   at hudson.FilePath.act(FilePath.java:1007)
>   ... 12 more
> Caused by: hudson.remoting.ProxyException:
> org.tmatesoft.svn.core.SVNException: svn: E17: URL 'https://svn.a
> pache.org/repos/asf/sling/trunk/extensions/hapi/client' doesn't exist
>   at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorMana
> ger.java:64)
>   at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorMana
> ger.java:51)
>   at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(S
> vnNgAbstractUpdate.java:830)
>   at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckou
> t.java:26)
>   at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckou
> t.java:11)
>   at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNg
> OperationRunner.java:20)
>   at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperati
> onRunner.java:21)
>   at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactor
> y.java:1235)
>   at
> org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
>   at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:
> 119)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:162)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:170)
>   at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.ja
> va:134)
>   at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(Workspac
> eUpdater.java:162)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:996)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
>   at
> hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
>   at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2772)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:153)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:50)
>   at hudson.remoting.Request$2.run(Request.java:332)
>   at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecut
> orService.java:68)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1145)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> .java:615)
>   at java.lang.Thread.run(Thread.java:745)
> Retrying after 10 seconds
> Location 'https://svn.apache.org/repos/asf/sling/trunk/extensions/hap
> i/client' does not exist
> Checking out a fresh workspace because there's no workspace at  

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 9:37 PM, Carsten Ziegeler  wrote:
> For example, if you drop a file through webdav, I assume it's still
> nt:Resource.

Had a look at the Webdav stuff and story here looks interesting. The
default implementation in Jackrabbit uses nt:unstructured for the
jcr:content node [1] however Sling integration changes the default to
'nt:resource' [2]. Not sure why they differ. But changing here should
be simply specifying a new OSGi config or changing the default OSGi
config.

I know its case by case basis change but I am not able to figure out
any easy way out here :(

Chetan Mehrotra
[1] 
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/io/DefaultHandler.java#L112
[2] 
https://github.com/apache/sling/blob/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler/DefaultHandlerService.java#L78

[jira] [Reopened] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz reopened SLING-5848:
-

Needs also be done for Karaf.

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz reassigned SLING-5848:
---

Assignee: Oliver Lietz  (was: Radu Cotescu)

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Ian Boston (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542771#comment-15542771
 ] 

Ian Boston commented on SLING-5645:
---

All changes that were requested have been made except moving the subtree out of 
contrib.

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Carsten Ziegeler]

But again, if you're not using the post servlet, you're not benefiting
For example, if you drop a file through webdav, I assume it's still
nt:Resource.

Carsten

Chetan Mehrotra wrote
> Logic to create a file structure is very much baked in the code so not
> possible to influence that currently i.e. specify a different node for
> jcr:content node of nt:file. So would need some change in Sling
> 
> Though IMHO I would change the default logic to use a non
> referenceable node and avoid relying on user to pass the hint and
> remember yet another optimization flag. If this change causes issue
> and user want old behavior a config switch can be provided for that
> 
> As mentioned earlier changing the default at Oak level is not possible
> as changing the nodetype semantics would break backward compatibility.
> While changing the nodetype used in some content structure created at
> Sling level should have lower impact and something which can be
> mitigated via config switch
> Chetan Mehrotra
> 
> 
> On Mon, Oct 3, 2016 at 5:37 PM, Carsten Ziegeler  wrote:
>> Chetan Mehrotra wrote
>>>
>>> That being said then same argument can be applied to change being done
>>> in Sling level where for same POST request now results in different
>>> nodetypes being used. If that is a big concern then we can make use of
>>> this new nodetype based on some request param. So a user would have to
>>> specify that nodetype hint if he wants to use the oak:Resource
>>> nodetype?
>>
>> Which should be doable today - same would be true for oak:unstructured
>> (vs nt:unstructured). So I think there is nothing to be done in Sling.
>>
>> Regards
>> Carsten
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Resolved] (SLING-5848) Define service user and ACLs for Scripting

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu resolved SLING-5848.
-
Resolution: Fixed

Defined service user + ACLs in 
https://svn.apache.org/viewvc?view=revision=1763177.

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
> Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Ian Boston (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542667#comment-15542667
 ] 

Ian Boston commented on SLING-5645:
---

Ignore that, just looked its only used inside the JMS implementation which 
already embeds active MQ, so no issue embedding another library.
The reason AMQ was embedded, is its big with lots of complex dependencies. 
Embedding it reduced deployment complexity.

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Ian Boston (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542656#comment-15542656
 ] 

Ian Boston commented on SLING-5645:
---

IIUC Embedding is an OSGi anti pattern. 
Could you explain why it would be better to embed it ?

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu updated SLING-5848:

Component/s: Launchpad

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
> Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu updated SLING-5848:

Fix Version/s: Launchpad Builder 9

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
> Fix For: Launchpad Builder 9
>
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5848) Define service user and ACLs for Scripting

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu reassigned SLING-5848:
---

Assignee: Radu Cotescu

> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Launchpad stable and launchpad unstable

[Robert Munteanu]

On Wed, 2016-09-28 at 22:06 +, Stefan Seifert wrote:
> discussed at the Sling Committer Round Table @ adaptTo() 2016
> 
> currently we have only one launchpad in trunk, which contains a
> mixture of release dependencies and snapshot dependencies. this makes
> it difficult to release new versions because one has to release all
> snapshot projects first, and perhaps the last relese version is fine
> as well.
> 
> we came up with a new proposal to fulfill the different needs:
> 
> - the launchpad maintained in trunk should always be the "stable"
> launchpad, referencing only released dependencies of the sling
> bundles and oft the integration tests project
> 
> - the "unstable" launchpad is created dynamically from this stable
> launchpad by using the same bundle list, but for each dependency the
> latest snapshot version that is available in the maven repo,
> including the latest snapshot version oft he integration tests.
> perhaps the slingstart plugin could be extented to generate this.
> 
> - i'm not sure what to do with new bundles which are not released yet
> thus are not referenced in the stable launchpad.

I'm +1 on this change, it makes it much simpler to perform releases. If
we make building an unstable launchpad really simple, e.g. an addition
profile or a mojo property, I don't think we lose anything.

Robert

Re: moving sling to git

[Robert Munteanu]

On Wed, 2016-09-28 at 22:34 +, Stefan Seifert wrote:
> - contact infra
>   - before we take further steps we should ask infra for it's opinion

I started a discussion with infra ( discussion not yet archived, but
should be available at [1] later).

I was pointed to https://reporeq.apache.org/ , which is a git
repository self-serve tool ( PMC members only ). We can use that tool
to automatically provision git repos, without any infra intervention.

This means that we are not blocked at all from an infrastructure point
of view when migrating to git.

Robert

[1]: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/

Re: SLING-5848 - Define service user and ACLs for Scripting

[Oliver Lietz]

On Monday 03 October 2016 12:48:14 Radu Cotescu wrote:
> Hi,

Hi Radu,

> I'd like to start working on SLING-5848 [1] (since it blocks SLING-5236
> [2]). Can we agree on two things before I commit any code?
> 
> 1. the service user should be called sling-scripting
> 2. the service user will only have jcr:read permissions for /apps, /libs
> (the default search paths)

fine with me (issue updated).

Thanks,
O.

> Thanks,
> Radu
> 
> [1] - https://issues.apache.org/jira/browse/SLING-5848
> [2] - https://issues.apache.org/jira/browse/SLING-5236

[jira] [Updated] (SLING-5848) Define service user and ACLs for Scripting

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-5848:

Description: 
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to these paths:
* {{/apps}}
* {{/libs}}
* -{{/etc}}- (?)

Name for service user: {{scripting}} or {{sling-scripting}} or 
{{sling.scripting}} (?)

*repoinit:*
{noformat}
create path /apps
create path /libs

create service user sling-scripting

set ACL for sling-scripting
  allow jcr:read on /apps
  allow jcr:read on /libs
end
{noformat}

  was:
Scripting implementations require a (service) ResourceResolver with very 
limited read rights to read scripts.

Reading can be limited to these paths:
* {{/apps}}
* {{/libs}}
* {{/etc}} (?)

Name for service user: {{scripting}} or {{sling-scripting}} or 
{{sling.scripting}} (?)

*repoinit:*
{noformat}
create path /apps
create path /libs

create service user sling-scripting

set ACL for sling-scripting
  allow jcr:read on /apps
  allow jcr:read on /libs
end
{noformat}


> Define service user and ACLs for Scripting
> --
>
> Key: SLING-5848
> URL: https://issues.apache.org/jira/browse/SLING-5848
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>
> Scripting implementations require a (service) ResourceResolver with very 
> limited read rights to read scripts.
> Reading can be limited to these paths:
> * {{/apps}}
> * {{/libs}}
> * -{{/etc}}- (?)
> Name for service user: {{scripting}} or {{sling-scripting}} or 
> {{sling.scripting}} (?)
> *repoinit:*
> {noformat}
> create path /apps
> create path /libs
> create service user sling-scripting
> set ACL for sling-scripting
>   allow jcr:read on /apps
>   allow jcr:read on /libs
> end
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

SLING-5848 - Define service user and ACLs for Scripting

[Radu Cotescu]

Hi,

I'd like to start working on SLING-5848 [1] (since it blocks SLING-5236
[2]). Can we agree on two things before I commit any code?

1. the service user should be called sling-scripting
2. the service user will only have jcr:read permissions for /apps, /libs
(the default search paths)

Thanks,
Radu

[1] - https://issues.apache.org/jira/browse/SLING-5848
[2] - https://issues.apache.org/jira/browse/SLING-5236

[jira] [Updated] (SLING-6001) ProcessorManagerImpl should move to new ResourceChangeListener API

[Rachit Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rachit Kumar updated SLING-6001:

Attachment: patch.txt

[~cziegeler]

Please review the patch for the issue.


> ProcessorManagerImpl should move to new ResourceChangeListener API
> ---
>
> Key: SLING-6001
> URL: https://issues.apache.org/jira/browse/SLING-6001
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
> Attachments: patch.txt
>
>
> org.apache.sling.rewriter.impl.ProcessorManagerImpl currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6002) ScriptCacheImpl should move to new ResourceChangeListener API

[Rachit Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rachit Kumar updated SLING-6002:

Attachment: Patch.txt

[~cziegeler]

Please review the patch for the issue.

> ScriptCacheImpl should move to new ResourceChangeListener API 
> --
>
> Key: SLING-6002
> URL: https://issues.apache.org/jira/browse/SLING-6002
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
> Attachments: Patch.txt
>
>
> org.apache.sling.scripting.core.impl.ScriptCacheImpl currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6001) ProcessorManagerImpl should move to new ResourceChangeListener API

[Rachit Kumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542309#comment-15542309
 ] 

Rachit Kumar commented on SLING-6001:
-

Working on it.

> ProcessorManagerImpl should move to new ResourceChangeListener API
> ---
>
> Key: SLING-6001
> URL: https://issues.apache.org/jira/browse/SLING-6001
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>
> org.apache.sling.rewriter.impl.ProcessorManagerImpl currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6002) ScriptCacheImpl should move to new ResourceChangeListener API

[Rachit Kumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542310#comment-15542310
 ] 

Rachit Kumar commented on SLING-6002:
-

Working on it.

> ScriptCacheImpl should move to new ResourceChangeListener API 
> --
>
> Key: SLING-6002
> URL: https://issues.apache.org/jira/browse/SLING-6002
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Hanish Bansal
>
> org.apache.sling.scripting.core.impl.ScriptCacheImpl currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

Logic to create a file structure is very much baked in the code so not
possible to influence that currently i.e. specify a different node for
jcr:content node of nt:file. So would need some change in Sling

Though IMHO I would change the default logic to use a non
referenceable node and avoid relying on user to pass the hint and
remember yet another optimization flag. If this change causes issue
and user want old behavior a config switch can be provided for that

As mentioned earlier changing the default at Oak level is not possible
as changing the nodetype semantics would break backward compatibility.
While changing the nodetype used in some content structure created at
Sling level should have lower impact and something which can be
mitigated via config switch
Chetan Mehrotra


On Mon, Oct 3, 2016 at 5:37 PM, Carsten Ziegeler  wrote:
> Chetan Mehrotra wrote
>>
>> That being said then same argument can be applied to change being done
>> in Sling level where for same POST request now results in different
>> nodetypes being used. If that is a big concern then we can make use of
>> this new nodetype based on some request param. So a user would have to
>> specify that nodetype hint if he wants to use the oak:Resource
>> nodetype?
>
> Which should be doable today - same would be true for oak:unstructured
> (vs nt:unstructured). So I think there is nothing to be done in Sling.
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Carsten Ziegeler]

Chetan Mehrotra wrote
> 
> That being said then same argument can be applied to change being done
> in Sling level where for same POST request now results in different
> nodetypes being used. If that is a big concern then we can make use of
> this new nodetype based on some request param. So a user would have to
> specify that nodetype hint if he wants to use the oak:Resource
> nodetype?

Which should be doable today - same would be true for oak:unstructured
(vs nt:unstructured). So I think there is nothing to be done in Sling.

Regards
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Integration tests near to modules

[Andrei Dulvac]

On Mon, Oct 3, 2016 at 12:48 PM Robert Munteanu  wrote:

> On Wed, 2016-09-28 at 22:06 +, Stefan Seifert wrote:
> > a goal would be to move most of module-specific integration tests
> > "near to the module" or just in the module project itself, using one
> > oft the numerous available integration test tool support available in
> > sling today. this is already the case for several new and complex
> > modules.
>
> +1, I think this is a good idea, and makes even more sense once/if we
> move to a git module per repository setup.
>
I wholeheartedly second that +1 (test should be next to the code they're
written for; forking, branching, etc. work ootb), which adds up to a +2 :)
- Andrei

>
> Robert
>

Re: svn commit: r1763153 - /sling/trunk/contrib/extensions/tracer/src/main/java/org/apache/sling/tracer/internal/LogTracer.java

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 5:13 PM, Robert Munteanu  wrote:
> AFAIR it analyses the bytecode
> and the imports are simply not there.

Okie. I thought that inlining of constant is implementation detail of
javac and may or may not work in all cases. However reading [1]
confirms that its guaranteed so can be relied upon!

Chetan Mehrotra
[1] 
http://stackoverflow.com/questions/1406616/is-java-guaranteed-to-inline-string-constants-if-they-can-be-determined-at-compi

Re: svn commit: r1763153 - /sling/trunk/contrib/extensions/tracer/src/main/java/org/apache/sling/tracer/internal/LogTracer.java

[Robert Munteanu]

On Mon, 2016-10-03 at 17:12 +0530, Chetan Mehrotra wrote:
> On Mon, Oct 3, 2016 at 4:57 PM, Robert Munteanu 
> wrote:
> > AFAIK constants will be inlined by javac, so by referencing them
> > bnd
> > will not add imports to the packages.
> 
> 
> Did not knew that bnd avoids adding import in such cases. Changed the
> code to use the constants then. Thanks for the review feedback!

I don't think bnd does anything special, AFAIR it analyses the bytecode
and the imports are simply not there.

Robert

Re: svn commit: r1763153 - /sling/trunk/contrib/extensions/tracer/src/main/java/org/apache/sling/tracer/internal/LogTracer.java

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 4:57 PM, Robert Munteanu  wrote:
> AFAIK constants will be inlined by javac, so by referencing them bnd
> will not add imports to the packages.

Did not knew that bnd avoids adding import in such cases. Changed the
code to use the constants then. Thanks for the review feedback!

Chetan Mehrotra

Re: svn commit: r1763153 - /sling/trunk/contrib/extensions/tracer/src/main/java/org/apache/sling/tracer/internal/LogTracer.java

[Robert Munteanu]

Hi Chetan,

On Mon, 2016-10-03 at 10:59 +, chet...@apache.org wrote:
> +    //Do not use constant name to keep dependency as optional
> +   
> //filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATT
> ERN, "/");
> +   
> //filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_SEL
> ECT,
> +    //    "(" +
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME + "=*)");

AFAIK constants will be inlined by javac, so by referencing them bnd
will not add imports to the packages.

Robert

[jira] [Comment Edited] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541648#comment-15541648
 ] 

Chetan Mehrotra edited comment on SLING-5645 at 10/3/16 11:16 AM:
--

We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 
## It can be moved a level up outside of example to indicate its meant to be 
used in production setups
## Add version annotations - Like add {{ProviderType}} to {{JobManager}}, 
{{Job}}, {{JobBuilder}} etc
## Remove non implemented methods in {{JobManager}} - We can easily add later 
if need arises. Removing would be tricky
# Also not sure if we need to move the code to bundles folder outside of 
contrib to indicate better support for this feature
# Some trimming of classes which are part of exported package in jms. May be 
move the non api class to impl package
{noformat}
Export-Package
  org.apache.sling.amq  {version=0.0.1}
  org.apache.sling.jms  {version=0.0.1}
{noformat}

[1] https://github.com/bdelacretaz/sling-adaptto-2016


was (Author: chetanm):
We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups
# Also not sure if we need to move the code to bundles folder outside of 
contrib to indicate better support for this feature
# Some trimming of classes which are part of exported package in jms. May be 
move the non api class to impl package
{noformat}
Export-Package
  org.apache.sling.amq  {version=0.0.1}
  org.apache.sling.jms  {version=0.0.1}
{noformat}

[1] https://github.com/bdelacretaz/sling-adaptto-2016

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541648#comment-15541648
 ] 

Chetan Mehrotra edited comment on SLING-5645 at 10/3/16 11:11 AM:
--

We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups
# Also not sure if we need to move the code to bundles folder outside of 
contrib to indicate better support for this feature
# Some trimming of classes which are part of exported package in jms. May be 
move the non api class to impl package
{noformat}
Export-Package
  org.apache.sling.amq  {version=0.0.1}
  org.apache.sling.jms  {version=0.0.1}
{noformat}

[1] https://github.com/bdelacretaz/sling-adaptto-2016


was (Author: chetanm):
We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups
# Also not sure if we need to move the code to bundles folder outside of 
contrib to indicate better support for this feature

[1] https://github.com/bdelacretaz/sling-adaptto-2016

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6089) Log Tracer does not work with system having new HTTP whiteboard implementation

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra resolved SLING-6089.

Resolution: Fixed

Fixed with 1763153. The filter is now registered with both old and new 
whiteboard properties and bundle can be used with setup having anytype of 
whiteboard implementation

> Log Tracer does not work with system having new HTTP whiteboard implementation
> --
>
> Key: SLING-6089
> URL: https://issues.apache.org/jira/browse/SLING-6089
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> Log Tracer does not work with Sling setups which have newer HTTP Whiteboard 
> implementation (org.apache.felix.http.whiteboard:3.0.0). Currently the filter 
> is registered with service property
> {noformat}
> pattern=/.*
> {noformat}
> The filter does gets used for calls to /system/console but does not get 
> invoked for any calls which are handled by SlingMainServlet (as reported by 
> [~bdelacretaz] 
> [here|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3CCAEWfVJ%3DWUVaoD9GOTD3WpL7PSEh9_Jk3maP2WPEWWTc7dbCftw%40mail.gmail.com%3E])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6089) Log Tracer does not work with system having new HTTP whiteboard implementation

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542133#comment-15542133
 ] 

Chetan Mehrotra commented on SLING-6089:


Another aspect - Even with warning any bundle using the older approach would 
not work in new setup as the filter would not cover the SlingMainServlet 
(original cause of this issue) and would have to use the newer approach. So a 
compatibility issue people need to be aware of

> Log Tracer does not work with system having new HTTP whiteboard implementation
> --
>
> Key: SLING-6089
> URL: https://issues.apache.org/jira/browse/SLING-6089
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> Log Tracer does not work with Sling setups which have newer HTTP Whiteboard 
> implementation (org.apache.felix.http.whiteboard:3.0.0). Currently the filter 
> is registered with service property
> {noformat}
> pattern=/.*
> {noformat}
> The filter does gets used for calls to /system/console but does not get 
> invoked for any calls which are handled by SlingMainServlet (as reported by 
> [~bdelacretaz] 
> [here|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3CCAEWfVJ%3DWUVaoD9GOTD3WpL7PSEh9_Jk3maP2WPEWWTc7dbCftw%40mail.gmail.com%3E])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Integration tests near to modules

[Robert Munteanu]

On Wed, 2016-09-28 at 22:06 +, Stefan Seifert wrote:
> a goal would be to move most of module-specific integration tests
> "near to the module" or just in the module project itself, using one
> oft the numerous available integration test tool support available in
> sling today. this is already the case for several new and complex
> modules.

+1, I think this is a good idea, and makes even more sense once/if we
move to a git module per repository setup.

Robert

Re: Resource packaging/content packaging in Sling

[Robert Munteanu]

On Sat, 2016-10-01 at 13:43 +0200, Konrad Windszus wrote:
> What about an HTTP API to list, download, upload/install and build
> packages? I guess the installer factory would only cover the
> upload/install part of it.

I think this is a good idea, but should probably tackled in a follow-up 
task, once we have the basics in place.

Robert
> 
> > Am 30.09.2016 um 14:25 schrieb Carsten Ziegeler  > rg>:
> > 
> > Stefan Seifert wrote
> > > i've created a new ticket for further discussion about a "sling
> > > content package plugin"
> > > https://issues.apache.org/jira/browse/SLING-6081
> > > 
> > > open in this thread is the "receiver part" to deploy content
> > > packages on sling instances which is currently not possible
> > > without 3rdparty applications.
> > > 
> > 
> > 
> > Created SLING-6082 for this :) I think I can add an initial version
> > in
> > the next days.
> > 
> > Regards
> > 
> > Carsten
> > 
> > -- 
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> > 
> 
> 
> 

Re: Sling Launchpad and Sling Karaf features

[Robert Munteanu]

On Wed, 2016-09-28 at 21:37 +, Stefan Seifert wrote:
> the launchpad should be split up in separates features/provisioning
> fragments to make it possible to easily build a "minimal launchpad"
> or "minimal launchpad + X" by selection only some but not all
> features.

+1, this would be very useful.

Robert

Re: sling attic / cleanup

[Robert Munteanu]

On Sat, 2016-10-01 at 09:25 +0200, Oliver Lietz wrote:
> On Saturday 01 October 2016 01:54:17 Robert Munteanu wrote:
> > On Fri, 2016-09-30 at 12:55 +, Stefan Seifert wrote:
> > > i assume in samples/ there are also some candidates.
> 
> 
> Hi Robert,
> 
> > I think it would be a good time to make a distinction between
> > 'real'
> > samples, i.e. here's how you do X with Sling and demos, which are
> > complete applications.
> > 
> > For samples I see for instance
> > 
> > - custom-login-form
> > - path-based-rtp
> > - inplace-integration-test
> > 
> > while the following are full-fledged demos
> > 
> > - espblog
> > - fling
> > - slingshot
> > 
> > The samples are IMO fine to be kept there as long as they build and
> > still showcase good practices. With the demos though we should be
> > more
> > conservative and consider them for the attic. And perhaps move them
> > somewhere else?
> 
> 
> that doesn't make sense or I don't understand your point probably.
> The fling and slingshot samples/demos are under active development.
> The 
> Fling[1] sample shows several features of Sling, e.g. scripting with 
> Thymeleaf, Sling Models, Sling Validation, Messaging and of course
> some low-
> level stuff. So why should they go to attic?

I did not suggest that any of the demos go to the attic, but I might
not have been very clear in my wording :-)

So let me put it this way:

There are tons of individual sling _features_ we may want to showcase (
samples ). There should be fewer ways we want to showcase sling
_applications_ ( demos ).

The reasons for fewer demos are:

- demos typically need to be updated to latest dependencies/slingstart
to be relevant
- demos are a larger investment in time
- multiple demos lead to confusion - at some point in the future we
might want to have _the_ reference Sling demo to point the users to

That means that the bar for demos is (again, IMHO) set higher than for
samples.

It does not mean that any of the current demos should be outright moved
to the attic, but that we should carefully consider which demos we want
to keep.

Thanks,

Robert

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 3:43 PM, Carsten Ziegeler  wrote:
> why can't do Oak the right thing?

Compatibility constraints :). Had this discussion earlier also but
given compatibility constraints its not possible to change the
defaults. If a nodetype says its referenceable/orderable once then its
not possible to change the semantics later as it would break down
those code which rely on that semantic.

However user of the api can decide to use a different nodetype as per
his requirement. So its more like the api user deciding to switch a
more performant nodetype with the understanding around what that
nodetype guarantees (think of using ArrayList instead of LinkedList
depending on usage pattern).

That being said then same argument can be applied to change being done
in Sling level where for same POST request now results in different
nodetypes being used. If that is a big concern then we can make use of
this new nodetype based on some request param. So a user would have to
specify that nodetype hint if he wants to use the oak:Resource
nodetype?

I am just aiming for a solution here which enables a user to use a
more optimum nodetype and get best performance out of underlying
repository.

Chetan Mehrotra
[1] http://markmail.org/thread/uj2ht4jwdrck7eja

Re: Preparing Launchpad 9 Release

[Robert Munteanu]

On Mon, 2016-10-03 at 11:57 +0200, Carsten Ziegeler wrote:
> Chetan Mehrotra wrote
> > Currently we are including 1.5.x version of Oak in Sling which are
> > considered unstable. Not sure on best way to deal with that.
> > 
> > One way out could be to align release of launchpad in Sling with
> > major
> > version release of Oak which typically happens once in year around
> > Feb-March. This would allow us to include the latest stable release
> > of
> > Oak in launchpad and would also ensure that any feature work in
> > Sling
> > which rely on Oak also get completed. For example currently the
> > Sling
> > Listener feature needs some further work and has some dependency on
> > works being done around observation event filtering in Oak
> > 
> 
> 
> Hmm, if there is an Oak release once per year and we do quartly Sling
> releases, we can basically only include new stuff of Oak every year.
> 
> As we definitely want to do a release of Launchpad 9 this year, we
> would
> have to switch back to Oak 1.4.x, cutting out some stuff

I would ask first what the exact issues are with the current 1.5.x
implementations.

It is much simpler for us to just ship what we have under the
assumption that the launchpad is mostly used for demo/experimental
setups, and that people are building their own launchpads for
production setups.

Robert

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Carsten Ziegeler]

Chetan Mehrotra wrote
> On Mon, Oct 3, 2016 at 3:30 PM, Carsten Ziegeler  wrote:
>> And then all scripts or code dealing with nt:resource fails as the node
>> or resource type is now oak:resource ?
> 
> Yes if the code checks if nodetype of jcr:content node under nt:file
> is of type nt:resource. So far my reading of code is that code does
> not rely on specific nodetype but just that node name is 'jcr:content'
> as that is defined in nt:file nodetype definition itself
> 

Hmm, ok  - in general this is nothing Sling should deal with. I think if
oak:Resource is the better option, why can't do Oak the right thing?
Why do we have to add workarounds on top in Sling? And if someone is not
using the post servlet then it's again nt:Resource.

Carsten
-- 

Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-6089) Log Tracer does not work with system having new HTTP whiteboard implementation

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542055#comment-15542055
 ] 

Carsten Ziegeler commented on SLING-6089:
-

Yes, it's the same, you can also use the regex registration property for the 
filter as defined in the http whiteboard.

> Log Tracer does not work with system having new HTTP whiteboard implementation
> --
>
> Key: SLING-6089
> URL: https://issues.apache.org/jira/browse/SLING-6089
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> Log Tracer does not work with Sling setups which have newer HTTP Whiteboard 
> implementation (org.apache.felix.http.whiteboard:3.0.0). Currently the filter 
> is registered with service property
> {noformat}
> pattern=/.*
> {noformat}
> The filter does gets used for calls to /system/console but does not get 
> invoked for any calls which are handled by SlingMainServlet (as reported by 
> [~bdelacretaz] 
> [here|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3CCAEWfVJ%3DWUVaoD9GOTD3WpL7PSEh9_Jk3maP2WPEWWTc7dbCftw%40mail.gmail.com%3E])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6090) Avoid using nt:resource while creating file nodes via SlingPostServlet

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542041#comment-15542041
 ] 

Chetan Mehrotra commented on SLING-6090:


Can you elaborate bit more here i.e. what kind of switch in Oak? See also [1] 
for some discussion around changing default behaviour for nt:resource in Oak

[1] http://markmail.org/thread/uj2ht4jwdrck7eja

> Avoid using nt:resource while creating file nodes via SlingPostServlet
> --
>
> Key: SLING-6090
> URL: https://issues.apache.org/jira/browse/SLING-6090
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
> {{SlingFileUploadHandler}} and {{StreamedChunk}}. 
> As discussed in OAK-4567 and also in best practices at [1] it would be better 
> to avoid using a referenceable nodetype and instead use another nodetype like 
> {{oak:Resource}} 
> [1] 
> https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 3:30 PM, Carsten Ziegeler  wrote:
> And then all scripts or code dealing with nt:resource fails as the node
> or resource type is now oak:resource ?

Yes if the code checks if nodetype of jcr:content node under nt:file
is of type nt:resource. So far my reading of code is that code does
not rely on specific nodetype but just that node name is 'jcr:content'
as that is defined in nt:file nodetype definition itself

Chetan Mehrotra

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Carsten Ziegeler]

Chetan Mehrotra wrote
> On Mon, Oct 3, 2016 at 2:43 PM, Julian Sedding  wrote:
>> Actually, the Sling POST Servlet bundle has a dependency on the JCR
>> API, as does SlingFileUploadHandler.
> 
> Aah missed seeing that. Makes decision simpler then. Would try to come
> up with the patch then
> 

And then all scripts or code dealing with nt:resource fails as the node
or resource type is now oak:resource ?


 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-6089) Log Tracer does not work with system having new HTTP whiteboard implementation

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542033#comment-15542033
 ] 

Chetan Mehrotra commented on SLING-6089:


I want this to be usable on older AEM setups which I believe do not have the 
newer implementation. So would go for simpler option now of registering with 
both properties now. 

btw just for my understanding. Earlier I had to use regex like {{/.*}} while 
now {{/}}. Are they functionally same?

> Log Tracer does not work with system having new HTTP whiteboard implementation
> --
>
> Key: SLING-6089
> URL: https://issues.apache.org/jira/browse/SLING-6089
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> Log Tracer does not work with Sling setups which have newer HTTP Whiteboard 
> implementation (org.apache.felix.http.whiteboard:3.0.0). Currently the filter 
> is registered with service property
> {noformat}
> pattern=/.*
> {noformat}
> The filter does gets used for calls to /system/console but does not get 
> invoked for any calls which are handled by SlingMainServlet (as reported by 
> [~bdelacretaz] 
> [here|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3CCAEWfVJ%3DWUVaoD9GOTD3WpL7PSEh9_Jk3maP2WPEWWTc7dbCftw%40mail.gmail.com%3E])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6090) Avoid using nt:resource while creating file nodes via SlingPostServlet

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542031#comment-15542031
 ] 

Carsten Ziegeler commented on SLING-6090:
-

What about a switch in Oak?

> Avoid using nt:resource while creating file nodes via SlingPostServlet
> --
>
> Key: SLING-6090
> URL: https://issues.apache.org/jira/browse/SLING-6090
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
> {{SlingFileUploadHandler}} and {{StreamedChunk}}. 
> As discussed in OAK-4567 and also in best practices at [1] it would be better 
> to avoid using a referenceable nodetype and instead use another nodetype like 
> {{oak:Resource}} 
> [1] 
> https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Preparing Launchpad 9 Release

[Carsten Ziegeler]

Chetan Mehrotra wrote
> Currently we are including 1.5.x version of Oak in Sling which are
> considered unstable. Not sure on best way to deal with that.
> 
> One way out could be to align release of launchpad in Sling with major
> version release of Oak which typically happens once in year around
> Feb-March. This would allow us to include the latest stable release of
> Oak in launchpad and would also ensure that any feature work in Sling
> which rely on Oak also get completed. For example currently the Sling
> Listener feature needs some further work and has some dependency on
> works being done around observation event filtering in Oak
> 

Hmm, if there is an Oak release once per year and we do quartly Sling
releases, we can basically only include new stuff of Oak every year.

As we definitely want to do a release of Launchpad 9 this year, we would
have to switch back to Oak 1.4.x, cutting out some stuff


Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-6089) Log Tracer does not work with system having new HTTP whiteboard implementation

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542023#comment-15542023
 ] 

Carsten Ziegeler commented on SLING-6089:
-

[~chetanm] I think the best option is to use both properties, the old and the 
new ones. The warning can be ignored as this is actually exactly what you want 
:)
I'm personally not sure, if it is worth supporting the old whiteboard, as the 
new one is now out for over a year - and I guess this could be solved with a 
configuration as well:
You just use the new official properties - if someone wants to run it in an 
older version, an OSGi configuration for the filter, adding the pattern 
property would do the trick.

> Log Tracer does not work with system having new HTTP whiteboard implementation
> --
>
> Key: SLING-6089
> URL: https://issues.apache.org/jira/browse/SLING-6089
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> Log Tracer does not work with Sling setups which have newer HTTP Whiteboard 
> implementation (org.apache.felix.http.whiteboard:3.0.0). Currently the filter 
> is registered with service property
> {noformat}
> pattern=/.*
> {noformat}
> The filter does gets used for calls to /system/console but does not get 
> invoked for any calls which are handled by SlingMainServlet (as reported by 
> [~bdelacretaz] 
> [here|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3CCAEWfVJ%3DWUVaoD9GOTD3WpL7PSEh9_Jk3maP2WPEWWTc7dbCftw%40mail.gmail.com%3E])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6090) Avoid using nt:resource while creating file nodes via SlingPostServlet

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542017#comment-15542017
 ] 

Chetan Mehrotra commented on SLING-6090:


We can avoid direct Oak dependency by going for either #2 or #3 here

> Avoid using nt:resource while creating file nodes via SlingPostServlet
> --
>
> Key: SLING-6090
> URL: https://issues.apache.org/jira/browse/SLING-6090
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
> {{SlingFileUploadHandler}} and {{StreamedChunk}}. 
> As discussed in OAK-4567 and also in best practices at [1] it would be better 
> to avoid using a referenceable nodetype and instead use another nodetype like 
> {{oak:Resource}} 
> [1] 
> https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 2:43 PM, Julian Sedding  wrote:
> Actually, the Sling POST Servlet bundle has a dependency on the JCR
> API, as does SlingFileUploadHandler.

Aah missed seeing that. Makes decision simpler then. Would try to come
up with the patch then

Chetan Mehrotra

[jira] [Commented] (SLING-6090) Avoid using nt:resource while creating file nodes via SlingPostServlet

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542000#comment-15542000
 ] 

Carsten Ziegeler commented on SLING-6090:
-

This is really a little bit annoying - this would mean we're leaving the 
standard now - and directly bind us on Oak. If we have to go this way, we 
should change all of our documentation that we are relying on JCR to we're 
basing on Oak as clearly the post servlet is the most fundamental thing and if 
that is bound to Oak, we don't run on any other implementation.

> Avoid using nt:resource while creating file nodes via SlingPostServlet
> --
>
> Key: SLING-6090
> URL: https://issues.apache.org/jira/browse/SLING-6090
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> Currently Sling uses {{nt:resource}} nodetype while creating file nodes in 
> {{SlingFileUploadHandler}} and {{StreamedChunk}}. 
> As discussed in OAK-4567 and also in best practices at [1] it would be better 
> to avoid using a referenceable nodetype and instead use another nodetype like 
> {{oak:Resource}} 
> [1] 
> https://adapt.to/2016/en/schedule/let_s-run-the-whole-web-on-apache-sling-and-oak-.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Julian Sedding]

Actually, the Sling POST Servlet bundle has a dependency on the JCR
API, as does SlingFileUploadHandler.

In that case #2 seems the best way forward. Use oak:Resource if
available, otherwise fall back to nt:resource.

Regards
Julian


On Mon, Oct 3, 2016 at 10:49 AM, Chetan Mehrotra
 wrote:
> On Mon, Oct 3, 2016 at 2:01 PM, Oliver Lietz  wrote:
>> I'm aware of that thread and therefore suggest to drive the spec towards
>> version 3. Providing tools for upgrading from 2 to 3 would allow to break
>> backwards compatibility and evolve.
>
> I believe this is orthogonal to current issue that we are discussing.
> Something which require wider effort! In this thread I would prefer to
> focus on the issue at hand and determine the approach to take.
>
>> When using special Oak nodetypes (and moving further away from JCR) we should
> stop claiming to be a web framework  using JCR but Oak.
>
> That may be one option as authentication layer depends on how Oak
> authentication works. But if we want to stick to JCR we can define our
> own nodetype and use that and not rely on Oak specific nodetype
> (Option #3)
>
> Chetan Mehrotra

[jira] [Created] (SLING-6092) Create OSGi-only development feature

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6092:
--

 Summary: Create OSGi-only development feature
 Key: SLING-6092
 URL: https://issues.apache.org/jira/browse/SLING-6092
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Reporter: Robert Munteanu
Priority: Minor
 Fix For: Sling Eclipse IDE 1.1.2


For some scenarios - mostly backend-only work - it can be useful to install a 
stripped down variation of the IDE Tooling which only provides the OSGi support 
for publishing bundles and debugging.

Splitting off the code into a new feature and probably a new bundle should not 
be too hard, but we need to handle the upgrade scenario so that when upgrading 
to a post-split version all required bundles are installed.

Also, the Eclipse Marketplace listing would need to be updated to make the new 
feature a mandatory one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 2:01 PM, Oliver Lietz  wrote:
> I'm aware of that thread and therefore suggest to drive the spec towards
> version 3. Providing tools for upgrading from 2 to 3 would allow to break
> backwards compatibility and evolve.

I believe this is orthogonal to current issue that we are discussing.
Something which require wider effort! In this thread I would prefer to
focus on the issue at hand and determine the approach to take.

> When using special Oak nodetypes (and moving further away from JCR) we should
stop claiming to be a web framework  using JCR but Oak.

That may be one option as authentication layer depends on how Oak
authentication works. But if we want to stick to JCR we can define our
own nodetype and use that and not rely on Oak specific nodetype
(Option #3)

Chetan Mehrotra

[jira] [Closed] (SLING-6045) Improve java package and GAV for oak restrictions

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-6045.
--

> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6042) Use sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-6042.
--

> Use sling:resourceTypesWithDescendants instead of 
> sling:resourceTypesWithChildren
> -
>
> Key: SLING-6042
> URL: https://issues.apache.org/jira/browse/SLING-6042
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> After some discussion at [1], the current version of the oak restrictions 
> initially committed with SLING-5768 should be updated to use 
> sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren 
> (the latter is semantically not correct as not only the children are matched 
> but all descendants, thanks [~jsedding] for pointing this out). 
> The documentation has already been updated via SLING-5890 and is available at 
> [2]
> [1] https://www.mail-archive.com/dev@sling.apache.org/msg58935.html
> [2] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-5768.
--

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Preparing Launchpad 9 Release

[Oliver Lietz]

On Friday 30 September 2016 14:40:11 Carsten Ziegeler wrote:
> Looking at the snapshot references from our launchpad project, I think
> there are only a few things to be done. (List is below)
> 
> I think it should be doable to release all these things in the near
> future and then get launchpad 9 out.
> 
> I'm wondering about sub system support. I think this never really took
> off, so I personally would rather remove all subsystem support for now.
> 
> WDYT?

+1

I would like to have service users for scripting implemented and some other 
outstanding issues fixed/done for 9.

Regards,
O.

> PS: Feel free to grab any of those modules and fix the remaining issues
> if there are and do a release.
> 
> List of snapshot refs:
> 
> org.apache.sling.installer.factory.subsystems-base/1.0.0-SNAPSHOT
> org.apache.sling.launchpad.base/5.4.0-2.6.11-SNAPSHOT
> org.apache.sling.repoinit.parser/1.0.3-SNAPSHOT
> org.apache.sling.jcr.repoinit/1.0.1-SNAPSHOT
> org.apache.sling.commons.fsclassloader/1.0.3-SNAPSHOT
> org.apache.sling.commons.mime/2.1.9-SNAPSHOT
> org.apache.sling.fsresource/1.1.5-SNAPSHOT
> org.apache.sling.installer.console/1.0.1-SNAPSHOT
> org.apache.sling.installer.provider.jcr/3.1.19-SNAPSHOT
> org.apache.sling.jcr.contentloader/2.1.11-SNAPSHOT
> org.apache.sling.xss/1.0.15-SNAPSHOT
> org.apache.sling.jcr.webdav/2.3.5-SNAPSHOT
> org.apache.sling.commons.metrics/1.0.1-SNAPSHOT
> 
> Regards
> Carsten

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

On Mon, Oct 3, 2016 at 2:06 PM, Julian Sedding  wrote:
> In an ideal world I would decouple the logic of what constitutes a
> file, i.e. create an API/convention in Sling, that is JCR agnostic and
> move the JCR-specific implementation to the JCR ResourceProvider
> bundle.

In an ideal world probably yes. That would require decent amount of
refactoring of existing code. Current code already uses JCR nodetypes,
just that it inlines the constant names and does not have a direct
dependency on the API

In real world I am looking for least intrusive change here :)

Chetan Mehrotra

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Julian Sedding]

Hi Chetan

I think point #2 (cannot check for oak:Resource nodetype because Sling
POST Servlet has no JCR dependency)  indicates that we have an
abstraction leak. I.e. the POST servlet needs to know the correct JCR
node-structure despite the fact that it "officially" has no JCR
dependency.

In an ideal world I would decouple the logic of what constitutes a
file, i.e. create an API/convention in Sling, that is JCR agnostic and
move the JCR-specific implementation to the JCR ResourceProvider
bundle.

WDYT? Is that possible? Would it break backwards compatibility?

Regards
Julian


On Mon, Oct 3, 2016 at 7:23 AM, Chetan Mehrotra
 wrote:
> Hi Team,
>
> Have a look at SLING-6090 where its suggested to avoid using
> nt:resource. It also mentions few possible solutions.
>
> Kindly have a look and provide your feedback on which solution to implement
>
> Chetan Mehrotra

[RESULT][VOTE] Release Apache Sling Oak Restrictions version 1.0.0

[Robert Munteanu]

Hi,

The vote has passed with the following result:

+1 (binding): Karl Pauls, Daniel Klco, Robert Munteanu
+1 (non-binding): Georg Henzler


I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Thanks,

Robert

Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

[Robert Munteanu]

On Tue, 2016-09-27 at 22:32 +0200, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: pipes release 0.0.10

[Nicolas Peltier]

Hi,

not that i can see, thanks.

Nicolas
> On Oct 2, 2016, at 2:32 PM, Oliver Lietz  wrote:
> 
> On Friday 30 September 2016 07:48:24 Nicolas Peltier wrote:
>> Hi,
>> 
>> +1 this would be clearer indeed
> 
> Done. Anything else? Otherwise I would try to do the release tonight.
> 
> Regards,
> O.
> 
>> Thanks,
>> Nicolas
> [...]
> 

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Oliver Lietz]

On Monday 03 October 2016 13:43:44 Chetan Mehrotra wrote:
> Hi Oliver,

Hi Chetan,

> Defaults for nt:resource was changed in JCR 2.0 and it was made
> unreferenceable. See [1] for some background. However JR2 and then Oak
> continued to use the older definition for compatibility purpose and
> hence the need for defining a custom nodetype

I'm aware of that thread and therefore suggest to drive the spec towards 
version 3. Providing tools for upgrading from 2 to 3 would allow to break 
backwards compatibility and evolve.

When using special Oak nodetypes (and moving further away from JCR) we should 
stop claiming to be a web framework  using JCR but Oak.

Regards,
O.

> Chetan Mehrotra
> [1] http://markmail.org/thread/uj2ht4jwdrck7eja
> 
> On Mon, Oct 3, 2016 at 1:20 PM, Oliver Lietz  wrote:
> > On Monday 03 October 2016 10:53:40 Chetan Mehrotra wrote:
> >> Hi Team,
> > 
> > Hi Chetan,
> > 
> >> Have a look at SLING-6090 where its suggested to avoid using
> >> nt:resource. It also mentions few possible solutions.
> >> 
> >> Kindly have a look and provide your feedback on which solution to
> >> implement
> > 
> > rather than using implementation specific nodetypes I would like to stick
> > to JCR spec and expect the Jackrabbit/Oak team (togehter with other
> > implementers) to evolve the spec to version 3.
> > 
> > See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?
> > 
> > Regards,
> > O.
> > 
> >> Chetan Mehrotra

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Chetan Mehrotra]

Hi Oliver,

Defaults for nt:resource was changed in JCR 2.0 and it was made
unreferenceable. See [1] for some background. However JR2 and then Oak
continued to use the older definition for compatibility purpose and
hence the need for defining a custom nodetype

Chetan Mehrotra
[1] http://markmail.org/thread/uj2ht4jwdrck7eja


On Mon, Oct 3, 2016 at 1:20 PM, Oliver Lietz  wrote:
> On Monday 03 October 2016 10:53:40 Chetan Mehrotra wrote:
>> Hi Team,
>
> Hi Chetan,
>
>> Have a look at SLING-6090 where its suggested to avoid using
>> nt:resource. It also mentions few possible solutions.
>>
>> Kindly have a look and provide your feedback on which solution to implement
>
> rather than using implementation specific nodetypes I would like to stick to
> JCR spec and expect the Jackrabbit/Oak team (togehter with other implementers)
> to evolve the spec to version 3.
>
> See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?
>
> Regards,
> O.
>
>> Chetan Mehrotra
>

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

[Oliver Lietz]

On Monday 03 October 2016 10:53:40 Chetan Mehrotra wrote:
> Hi Team,

Hi Chetan,

> Have a look at SLING-6090 where its suggested to avoid using
> nt:resource. It also mentions few possible solutions.
> 
> Kindly have a look and provide your feedback on which solution to implement

rather than using implementation specific nodetypes I would like to stick to 
JCR spec and expect the Jackrabbit/Oak team (togehter with other implementers) 
to evolve the spec to version 3.

See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?

Regards,
O.

> Chetan Mehrotra

[jira] [Comment Edited] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541648#comment-15541648
 ] 

Chetan Mehrotra edited comment on SLING-5645 at 10/3/16 6:56 AM:
-

We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups
# Also not sure if we need to move the code to bundles folder outside of 
contrib to indicate better support for this feature

[1] https://github.com/bdelacretaz/sling-adaptto-2016


was (Author: chetanm):
We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups



[1] https://github.com/bdelacretaz/sling-adaptto-2016

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541702#comment-15541702
 ] 

Chetan Mehrotra commented on SLING-5645:


In that case it would be better to embed it

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Release the Sling MOM Bundles (SLING-5645)

[Ian Boston]

Hi,
AFAIK there isn't anything that absolutely needs to be done. I notice some
cleanup was suggested in Jira which is fine. I made some comments.
Happy to do the release if you want.

Best Regards
Ian

On 3 October 2016 at 07:13, Chetan Mehrotra 
wrote:

> Hi,
>
> We have used the snapshot version of Sling MOM Feature (ActiveMQ based
> Job management) in our poc for adaptTo [1] and have found it very
> useful.
>
> To enable wider usage I think we should now provide an official
> release of these bundles. What would be required to have the first
> release done?
>
> Chetan Mehrotra
> [1]  https://github.com/bdelacretaz/sling-adaptto-2016
>

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Ian Boston (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541688#comment-15541688
 ] 

Ian Boston commented on SLING-5645:
---

GSon is being used for performance reasons. Probably not a good idea to remote 
it. In small file tests it is reported as being 20x faster than simple json 
parsing libraries like the Sling json library and 72% faster than Jackson. In 
large file tests is slower than Jackson. The message payloads should all be 
small, hence the choice. There are probably other faster encoding methods that 
could be used in place of Json, but the implementation is intended to be 
consumed by any language that can consume The AMQ protocol, not limited to java.

No problem with other changes.

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6088) Distribution ITs fail on Jenkins

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned SLING-6088:
--

Assignee: Tommaso Teofili

> Distribution ITs fail on Jenkins
> 
>
> Key: SLING-6088
> URL: https://issues.apache.org/jira/browse/SLING-6088
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: Jenkins
>Reporter: Robert Munteanu
>Assignee: Tommaso Teofili
>
> The tests give up after 60 seconds:
> {noformat}
> 60433 [main] INFO org.apache.sling.testing.tools.sling.SlingTestBase - Server 
> not ready after 60 seconds, giving up
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 60.479 sec 
> <<< FAILURE! - in 
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest
> testAddExportImportTemp(org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest)
>   Time elapsed: 0.006 sec  <<< FAILURE!
> java.lang.AssertionError: Server not ready after 60 seconds, giving up
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.waitForServerReady(SlingTestBase.java:326)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.startServerIfNeeded(SlingTestBase.java:169)
>   at 
> org.apache.sling.testing.tools.sling.SlingTestBase.getServerBaseUrl(SlingTestBase.java:231)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.init(DistributionIntegrationTestBase.java:87)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:63)
>   at 
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:59)
>   at 
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest.(DistributionPackageExporterImporterTemporaryFoldersTest.java:36){noformat}
> The only relevant snippet that I can find in the logs is related to the 
> health check bundles:
> {noformat}01.10.2016 18:09:51.724 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.hc.webconsole FrameworkEvent ERROR 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement 
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement 
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))]
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
>   at 
> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063)
>   at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253)
>   at 
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188)
>   at java.lang.Thread.run(Thread.java:745){noformat}
> but I'm not sure that this leads to the test failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Preparing Launchpad 9 Release

[Chetan Mehrotra]

Currently we are including 1.5.x version of Oak in Sling which are
considered unstable. Not sure on best way to deal with that.

One way out could be to align release of launchpad in Sling with major
version release of Oak which typically happens once in year around
Feb-March. This would allow us to include the latest stable release of
Oak in launchpad and would also ensure that any feature work in Sling
which rely on Oak also get completed. For example currently the Sling
Listener feature needs some further work and has some dependency on
works being done around observation event filtering in Oak

Thoughts?

Chetan Mehrotra


On Fri, Sep 30, 2016 at 6:52 PM, Daniel Klco  wrote:
> Okay, that should be very doable. I'm 80-90% sure all of the code changes
> are there. I'm just running into a wall trying to test it out, I opened
> another email thread to discuss that issue.
>
> On Fri, Sep 30, 2016 at 9:18 AM, Carsten Ziegeler 
> wrote:
>
>> Daniel Klco wrote
>> > I'd also like to include the changes I've been meaning to make for
>> > normalizing the scripting cache clear. Affected modules are:
>> >
>> >- org.apache.sling.commons.classloader
>> >- org.apache.sling.commons.fsclassloader
>> >- org.apache.sling.scripting.jsp
>> >
>> > What's the target release date for Launchpad 9?
>> >
>> We don't have a target date, but it should definitely happen this year :)
>> It would be great if we can make end of October though I think
>>
>> Carsten
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
>>

[jira] [Commented] (SLING-5645) Provide a Jobs API and implementation suitable for widely distributed job processing.

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541648#comment-15541648
 ] 

Chetan Mehrotra commented on SLING-5645:


We have used this feature in poc for adaptTo [1] and have found it be useful. 
Probably we should now do an initial release. Some changes which I think would 
be useful (prior to first release)

# Remove comments like below from source code. 
{noformat}
Created by ieb on 31/03/2016.
{noformat}
# Look into replacing Google JSON library with org.json which is already being 
used in Sling. Would reduce one extra dependency!
# [{{jobs}} 
module|https://github.com/apache/sling/tree/trunk/contrib/commons/mom/examples/jobs]
 can be moved a level up outside of example to indicate its meant to be used in 
production setups



[1] https://github.com/bdelacretaz/sling-adaptto-2016

> Provide a Jobs API and implementation suitable for widely distributed job 
> processing.
> -
>
> Key: SLING-5645
> URL: https://issues.apache.org/jira/browse/SLING-5645
> Project: Sling
>  Issue Type: New Feature
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> This issue is to track work on a proof of concept to create a Jobs API and 
> implementation that will work in a distributed environment where the job 
> submitters and job consumers are not necessarily in the same JVM or in the 
> same Sling cluster. 
> Work is being done in a branch at 
> https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs
> Since the implementation needs supporting APIs/Capabilities not already 
> present in Sling. There are some sub-tasks associated with this issue to 
> address those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Release the Sling MOM Bundles (SLING-5645)

[Chetan Mehrotra]

Hi,

We have used the snapshot version of Sling MOM Feature (ActiveMQ based
Job management) in our poc for adaptTo [1] and have found it very
useful.

To enable wider usage I think we should now provide an official
release of these bundles. What would be required to have the first
release done?

Chetan Mehrotra
[1]  https://github.com/bdelacretaz/sling-adaptto-2016

[jira] [Resolved] (SLING-6091) Make dependency on jackrabbit-jcr-rmi as optional in jcr base

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra resolved SLING-6091.

Resolution: Fixed

Marked the dependency as optional in 1763118

> Make dependency on jackrabbit-jcr-rmi as optional in jcr base
> -
>
> Key: SLING-6091
> URL: https://issues.apache.org/jira/browse/SLING-6091
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Base 2.4.2
>
>
> Currently {{org.apache.sling.jcr.base}} has a required dependency on 
> {{jackrabbit-jcr-rmi}}. The rmi usage is only for util class 
> {{RepositoryAccessor}} and is an optional feature.
> We should mark this dependency as optional so as to allow usage of this 
> bundle in setups where the {{jackrabbit-jcr-rmi}} is not present



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6091) Make dependency on jackrabbit-jcr-rmi as optional in jcr base

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated SLING-6091:
---
Priority: Minor  (was: Major)

> Make dependency on jackrabbit-jcr-rmi as optional in jcr base
> -
>
> Key: SLING-6091
> URL: https://issues.apache.org/jira/browse/SLING-6091
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Base 2.4.2
>
>
> Currently {{org.apache.sling.jcr.base}} has a required dependency on 
> {{jackrabbit-jcr-rmi}}. The rmi usage is only for util class 
> {{RepositoryAccessor}} and is an optional feature.
> We should mark this dependency as optional so as to allow usage of this 
> bundle in setups where the {{jackrabbit-jcr-rmi}} is not present



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6091) Make dependency on jackrabbit-jcr-rmi as optional in jcr base

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-6091:
--

 Summary: Make dependency on jackrabbit-jcr-rmi as optional in jcr 
base
 Key: SLING-6091
 URL: https://issues.apache.org/jira/browse/SLING-6091
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: JCR Base 2.4.2


Currently {{org.apache.sling.jcr.base}} has a required dependency on 
{{jackrabbit-jcr-rmi}}. The rmi usage is only for util class 
{{RepositoryAccessor}} and is an optional feature.

We should mark this dependency as optional so as to allow usage of this bundle 
in setups where the {{jackrabbit-jcr-rmi}} is not present



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)