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

[ https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz reopened SLING-5848: - > Define service user and ACLs for Scripting > -- > >

[jira] [Resolved] (SLING-6095) Remove the script resource resolver (admin) from the bindings map provided by HTL to HTL scripts

[ https://issues.apache.org/jira/browse/SLING-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-6095. - Resolution: Fixed Fixed in [r1763290|https://svn.apache.org/r1763290]. > Remove the script

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

[ https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-5848. - Resolution: Fixed Fixed in [r1763177|https://svn.apache.org/r1763177]. > Define service user and

[jira] [Resolved] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider

[ https://issues.apache.org/jira/browse/SLING-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-5254. - Resolution: Fixed Fixed in [r1763288|https://svn.apache.org/r1763288]. > Remove

[jira] [Resolved] (SLING-6096) Extract Sling scripting specific provisioning model configurations into a separate file

[ https://issues.apache.org/jira/browse/SLING-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-6096. - Fixed in [r1763287|https://svn.apache.org/r1763287] - see

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

[ https://issues.apache.org/jira/browse/SLING-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545566#comment-15545566 ] Ian Boston commented on SLING-5645: --- If there are no objections, I would like to leave the code in

[jira] [Created] (SLING-6096) Extract Sling scripting specific provisioning model configurations into a separate file

Radu Cotescu created SLING-6096: --- Summary: Extract Sling scripting specific provisioning model configurations into a separate file Key: SLING-6096 URL: https://issues.apache.org/jira/browse/SLING-6096

Re: Possibility of making nt:resource unreferenceable

On Tue, Oct 4, 2016 at 7:32 PM, Julian Reschke wrote: > At least in our DocumentStoreImplementations (Mongo and RDB), making the > UUID something indexed by the storage (so either Mongo or the relational > database) should be relatively cheap (after all, the UUID never

[jira] [Created] (SLING-6095) Remove the script resource resolver (admin) from the bindings map provided by HTL to HTL scripts

Radu Cotescu created SLING-6095: --- Summary: Remove the script resource resolver (admin) from the bindings map provided by HTL to HTL scripts Key: SLING-6095 URL: https://issues.apache.org/jira/browse/SLING-6095

[jira] [Updated] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

[ https://issues.apache.org/jira/browse/SLING-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-6094: Fix Version/s: Scripting HTL Engine 1.0.22 Scripting HTL Java Compiler 1.0.2 >

[jira] [Assigned] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

[ https://issues.apache.org/jira/browse/SLING-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-6094: --- Assignee: Radu Cotescu > HTL Parser NPE when using data-sly-attribute map and a static

Re: Possibility of making nt:resource unreferenceable

> At least in our DocumentStoreImplementations (Mongo and RDB), making the > UUID something indexed by the storage (so either Mongo or the relational > database) should be relatively cheap (after all, the UUID never changes once > assigned, right?). That would eliminate the indexing overhead in

[jira] [Updated] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

[ https://issues.apache.org/jira/browse/SLING-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-6094: Affects Version/s: Scripting Sightly Engine 1.0.18 > HTL Parser NPE when using data-sly-attribute

Re: Possibility of making nt:resource unreferenceable

On 2016-10-04 15:58, Thomas Mueller wrote: Hi, I still do not understand, why we do not delegate the UUID generation/lookup to the persistence instead of insisting it to be just like any other property index... The UUID _generation_ is not a problem. (I it a bit slow, but scales well - no

Re: Possibility of making nt:resource unreferenceable

Hi, >I still do not understand, why we do not delegate the UUID >generation/lookup to the persistence instead of insisting it to be just >like any other property index... The UUID _generation_ is not a problem. (I it a bit slow, but scales well - no issue there). The UUID _lookup_ is not a

Re: Possibility of making nt:resource unreferenceable

Hi, 2016-10-04 15:21 GMT+02:00 Julian Reschke : > On 2016-10-04 08:43, Chetan Mehrotra wrote: >> >> <> >> >> Hi Team, >> >> Sometime back we discussed the requirement for oak:Resource as a non >> referenceable replacement for nt:resource (OAk-4567). This topic was >> also

Re: Possibility of making nt:resource unreferenceable

On 2016-10-04 08:43, Chetan Mehrotra wrote: <> Hi Team, Sometime back we discussed the requirement for oak:Resource as a non referenceable replacement for nt:resource (OAk-4567). This topic was also discussed on DL [1] and at that time it was decided that changing the defaults (making

[jira] [Commented] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

[ https://issues.apache.org/jira/browse/SLING-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545302#comment-15545302 ] Mark J. Becker commented on SLING-6094: --- 1.0.18 > HTL Parser NPE when using data-sly-attribute map

[jira] [Comment Edited] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[ https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545285#comment-15545285 ] Konrad Windszus edited comment on SLING-6068 at 10/4/16 12:54 PM: -- There

[jira] [Commented] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[ https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545285#comment-15545285 ] Konrad Windszus commented on SLING-6068: There are some more issues which need to be resolved #

[jira] [Commented] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

[ https://issues.apache.org/jira/browse/SLING-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545283#comment-15545283 ] Radu Cotescu commented on SLING-6094: - What version of the scripting engine are you using? > HTL

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

[ https://issues.apache.org/jira/browse/SLING-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545279#comment-15545279 ] Oliver Lietz commented on SLING-5848: - [~bdelacretaz], [~chetanm] Do we need this section at all? We

Re: where should we define service user mappings?

On Tue, Oct 4, 2016 at 2:40 PM, Radu Cotescu wrote: > ...Should I create a scripting.txt provisioning file > in launchpad builder? Then I'd make the following changes... This looks good to me - basically move all the scripting specific stuff in its own provisioning model feature

[jira] [Created] (SLING-6094) HTL Parser NPE when using data-sly-attribute map and a static attribute with colon

Mark J. Becker created SLING-6094: - Summary: HTL Parser NPE when using data-sly-attribute map and a static attribute with colon Key: SLING-6094 URL: https://issues.apache.org/jira/browse/SLING-6094

Re: where should we define service user mappings?

Thanks for the feedback! Should I create a scripting.txt provisioning file in launchpad builder? Then I'd make the following changes: 1. undo some of the changes from r1763177 to *repoinit.txt* and bring this file to this state: [feature name=repoinit] [artifacts]

Re: Replace sling launchpad with karaf?

Hi, On Tue, Oct 4, 2016 at 12:00 PM, Robert Munteanu wrote: ... > So here's my 'keep' list proposal (for moving to Karaf): > - provisioning model > - same CLI arguments ( we can't break backwards compatibility ) > - ability to consume an arbitrary version of Felix ( AFAIK

Re: where should we define service user mappings?

Hi Radu, On Tue, Oct 4, 2016 at 1:34 PM, Radu Cotescu wrote: > ...I've done this > in sling.txt in the launchpad builder project (not yet committed), but I've > been thinking that maybe we should create a service users provisioning file > where we define this If we go in

Fwd: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with limited access

Reviving the discussion around ResourceResolvers for Scripting... Radu, Carsten and me had a face-to-face discussion at adaptTo() and we agree that having resource resolvers for scripting like Radu described below is the way to go (for now) to get rid of administrative resolvers. Any opinions

Re: Sling Launchpad and Sling Karaf features

On 4 October 2016 at 12:02, Oliver Lietz wrote: > On Tuesday 04 October 2016 11:24:38 Ian Boston wrote: > > Hi, > > I have tried many times to use Pax Exam, and always got stuck in its > > complexity and opacity, this time was no different, hence why I resorted > to > >

where should we define service user mappings?

Hi, I've started working on SLING-5254 [1], which seems to be the first implementation of a service user in Sling. Where should we define the amended configuration for the ServiceUserMapper? Currently I've done this in sling.txt in the launchpad builder project (not yet committed), but I've been

Re: pipes release 0.0.10

On Tuesday 04 October 2016 11:22:06 Nicolas Peltier wrote: > thanks i’ll look into it and fix it. Should i create a JIRA for it? Also > need a few update in documentation as well anyway Yes, please. A new issue for 0.0.10 is fine. O. > Nicolas [...]

[jira] [Created] (SLING-6093) NPE in StartupFilterImpl

Chetan Mehrotra created SLING-6093: -- Summary: NPE in StartupFilterImpl Key: SLING-6093 URL: https://issues.apache.org/jira/browse/SLING-6093 Project: Sling Issue Type: Bug

Re: svn commit: r1763255 - in /sling/trunk/contrib/commons/mom: ./ jobs/core/ jobs/core/src/main/java/org/apache/sling/jobs/impl/ jobs/it/ jobs/it/src/test/java/org/apache/sling/jobs/it/ jobs/it/src/t

On 4 October 2016 at 10:49, Chetan Mehrotra wrote: > On Tue, Oct 4, 2016 at 2:53 PM, wrote: > > +public Set getJobTypes(Map > properties) { > > +Object types = properties.get(JobConsumer.JOB_TYPES); > > +

Re: pipes release 0.0.10

thanks i’ll look into it and fix it. Should i create a JIRA for it? Also need a few update in documentation as well anyway Nicolas > On Oct 4, 2016, at 11:41 AM, Oliver Lietz wrote: > > On Monday 03 October 2016 08:31:46 Nicolas Peltier wrote: >> Hi, > > Hi Nicolas, >

Re: Sling Launchpad and Sling Karaf features

On Tuesday 04 October 2016 11:24:38 Ian Boston wrote: > Hi, > I have tried many times to use Pax Exam, and always got stuck in its > complexity and opacity, this time was no different, hence why I resorted to > the crankstart provisioning model. Obviously your mileage varies, but > thanks for the

Re: moving sling to git

On 4 October 2016 at 10:52, Carsten Ziegeler wrote: > Bertrand Delacretaz wrote > > On Tue, Oct 4, 2016 at 10:33 AM, Ian Boston wrote: > >> ...Perhaps Sling has too many independently versioned modules. Linux[1] > >> manages to put many modules into a

Re: Sling Launchpad and Sling Karaf features

Hi, I have tried many times to use Pax Exam, and always got stuck in its complexity and opacity, this time was no different, hence why I resorted to the crankstart provisioning model. Obviously your mileage varies, but thanks for the pointer. The feature.xml looks extensive at 557 lines compared

Re: moving sling to git

On Tuesday 04 October 2016 11:52:09 Carsten Ziegeler wrote: > Bertrand Delacretaz wrote > > > On Tue, Oct 4, 2016 at 10:33 AM, Ian Boston wrote: > >> ...Perhaps Sling has too many independently versioned modules. Linux[1] > >> manages to put many modules into a single repository

Re: moving sling to git

On Tue, 2016-10-04 at 09:43 +0200, Bertrand Delacretaz wrote: > And tools like those listed at  [1] (repo, gitslave etc.) allow for > creating a single "kitchen sink" setup to make it easy to checkout > the > whole codebase with one command. For our 'reactor'/root repository we can setup a

Re: Replace sling launchpad with karaf?

On Tue, 2016-10-04 at 10:02 +0200, Bertrand Delacretaz wrote: > On Fri, Sep 30, 2016 at 11:19 AM, Carsten Ziegeler org> wrote: > > ...I don't know if Karaf has anything compared to crankstart, maybe > > there > > is or we could contribute it - which again would have a much

Re: Sling Launchpad and Sling Karaf features

On Tuesday 04 October 2016 10:19:06 Ian Boston wrote: > Hi, Hi Ian, > On 3 October 2016 at 11:37, Robert Munteanu wrote: > > On Wed, 2016-09-28 at 21:37 +, Stefan Seifert wrote: > > > the launchpad should be split up in separates features/provisioning > > > fragments to

Re: moving sling to git

Bertrand Delacretaz wrote > On Tue, Oct 4, 2016 at 10:33 AM, Ian Boston wrote: >> ...Perhaps Sling has too many independently versioned modules. Linux[1] >> manages to put many modules into a single repository and release it as a >> clean consistent version > > Good point, I

Re: svn commit: r1763255 - in /sling/trunk/contrib/commons/mom: ./ jobs/core/ jobs/core/src/main/java/org/apache/sling/jobs/impl/ jobs/it/ jobs/it/src/test/java/org/apache/sling/jobs/it/ jobs/it/src/t

On Tue, Oct 4, 2016 at 2:53 PM, wrote: > +public Set getJobTypes(Map > properties) { > +Object types = properties.get(JobConsumer.JOB_TYPES); > +if (types instanceof String) { > +return Types.jobType(new

Re: pipes release 0.0.10

On Monday 03 October 2016 08:31:46 Nicolas Peltier wrote: > Hi, Hi Nicolas, > not that i can see, thanks. I tried to do the release, but it failed with javadoc errors. You can try yourself with mvn clean javadoc:javadoc. Can you provide a patch (preferred) or we can skip javadoc. Thanks, O.

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

[ https://issues.apache.org/jira/browse/SLING-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544856#comment-15544856 ] Rachit Kumar commented on SLING-6002: - [~cziegeler] As mentioned on SLING-6001 '.' will work as well

Re: Sling Launchpad and Sling Karaf features

Hi, On 3 October 2016 at 11:37, Robert Munteanu wrote: > 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

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

[ https://issues.apache.org/jira/browse/SLING-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544851#comment-15544851 ] Rachit Kumar commented on SLING-6001: - [~cziegeler] Yes the '.' will work as well but in the code we

Re: Integration tests near to modules

Hi, On Tue, Oct 4, 2016 at 10:48 AM, Stefan Seifert wrote: >>-Original Message- >>From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] >>I...I don't >>think we made any decisions there and those would not be valid anyway >>as they didn't happen on this list.

Re: moving sling to git

On Tue, Oct 4, 2016 at 10:33 AM, Ian Boston wrote: > ...Perhaps Sling has too many independently versioned modules. Linux[1] > manages to put many modules into a single repository and release it as a > clean consistent version Good point, I agree that many of our modules are

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

[ https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544814#comment-15544814 ] Thomas Mueller commented on SLING-6090: --- I understand Carstens reason to avoid a direct dependency

RE: Integration tests near to modules

>-Original Message- >From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] >Sent: Tuesday, October 4, 2016 9:48 AM >To: dev >Subject: Re: Integration tests near to modules ... >I did attend (most of) the committers roundtable at adaptTo, I don't >think we made any decisions there and

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

[ https://issues.apache.org/jira/browse/SLING-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-6090: --- Description: Currently Sling uses {{nt:resource}} nodetype while creating file nodes in

[jira] [Commented] (SLING-3987) move from Subversion to Git

[ https://issues.apache.org/jira/browse/SLING-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544749#comment-15544749 ] Stefan Seifert commented on SLING-3987: --- robert discovered there exists a self service application

Re: moving sling to git

Hi, On 4 October 2016 at 08:43, Bertrand Delacretaz wrote: > Hi Ian, > > On Thu, Sep 29, 2016 at 10:27 AM, Ian Boston wrote: > > ...I think it would be a mistake to attempt to split the repository into > 100s > > of separate Git repositories as it will

Re: removal of it-jackrabbit-oak

On Thu, Sep 29, 2016 at 2:48 PM, Oliver Lietz wrote: > ...I will remove the module in the next days if no one objects. +1 for removing. -Bertrand

Re: Replace sling launchpad with karaf?

On Fri, Sep 30, 2016 at 11:19 AM, Carsten Ziegeler wrote: > ...I don't know if Karaf has anything compared to crankstart, maybe there > is or we could contribute it - which again would have a much larger > outreach than Sling... I agree with that but also with Ian that our

Re: Preparing Launchpad 9 Release

On Fri, Sep 30, 2016 at 2:40 PM, Carsten Ziegeler wrote: > ...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... +1 -Bertrand

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

[ https://issues.apache.org/jira/browse/SLING-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544670#comment-15544670 ] Bertrand Delacretaz commented on SLING-6089: I haven't looked at your latest changes but it

Re: Integration tests near to modules

Hi, On Thu, Sep 29, 2016 at 12:06 AM, 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

Re: moving sling to git

Hi Ian, On Thu, Sep 29, 2016 at 10:27 AM, Ian Boston wrote: > ...I think it would be a mistake to attempt to split the repository into 100s > of separate Git repositories as it will make it near impossible for any > outsider to work on the code base My understanding is that

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

[ https://issues.apache.org/jira/browse/SLING-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544623#comment-15544623 ] Carsten Ziegeler commented on SLING-6002: - Thanks for the patch [~krachi...@gmail.com] It

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

[ https://issues.apache.org/jira/browse/SLING-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-6002: Fix Version/s: Scripting Core 2.0.40 > ScriptCacheImpl should move to new

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

[ https://issues.apache.org/jira/browse/SLING-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-6001: Fix Version/s: Rewriter 1.1.6 > ProcessorManagerImpl should move to new

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

[ https://issues.apache.org/jira/browse/SLING-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544614#comment-15544614 ] Carsten Ziegeler commented on SLING-6001: - Thanks for the patch [~krachi...@gmail.com] It

Re: maven site documentation for sling maven plugins

Good point, would prefer that option as well. I asked INFRA about this option in https://issues.apache.org/jira/browse/INFRA-12701 . Konrad > On 1 Oct 2016, at 21:19, Robert Munteanu wrote: > > > On Wed, 2016-09-28 at

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

Okie. So I have started a new mail thread addressing both project teams to see if we can converge on some agreement here. Kindly provide your feedback there Chetan Mehrotra On Tue, Oct 4, 2016 at 11:55 AM, Carsten Ziegeler wrote: > Thanks Chetan, > > I'm really wondering

Possibility of making nt:resource unreferenceable

<> Hi Team, Sometime back we discussed the requirement for oak:Resource as a non referenceable replacement for nt:resource (OAk-4567). This topic was also discussed on DL [1] and at that time it was decided that changing the defaults (making nt:resource non referenceable ) is not possible and

[jira] [Resolved] (SLING-5900) Improve create agents API handling of duplicate IDs

[ https://issues.apache.org/jira/browse/SLING-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-5900. Resolution: Fixed thanks [~simone.tripodi], I've applied your patch in r1763231. > Improve

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

Thanks Chetan, I'm really wondering if there can't be a better solution :) For example, look at the jcr classloader module, writing class files to the repository. It creates a nt:file with a nt:resource child node. While jcr classloader is not that important nowadays anymore, I think we have

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

On Tue, Oct 4, 2016 at 11:01 AM, Carsten Ziegeler wrote: > 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