Re: Sling Oak Restrictions - Release 1.0.0 now?

[Oliver Lietz]

On Monday 01 August 2016 13:37:26 Robert Munteanu wrote:
> Hi Georg,

Hi,

> On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
> > Hi all,
> > 
> > with SLING-5768/SLING-5891 fixed and the documentation in 
> > https://sling.apache.org/documentation/bundles/sling-oak-restrictions
> > .html 
> > we have everything needed to cut a first release IMHO - could
> > someone 
> > take care of it?
> 
> I think we need to clarify two issues:
> 
> 1. Bundle name and location
> 
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . I would rather
> see it named org.apache.sling.jcr.oak-restrictions and placed under
> contrib/jcr .

the bundle is not using JCR API but Oak API only 
(org.apache.jackrabbit.oak.spi.security.authorization.restriction). Shouldn't 
we go for a simple module and package name org.apache.sling.oak.restriction?

Regards,
O.

> 2. Naming of the restrictions
> 
> There was some discussion related to the name of the
> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
> that we have agreement that this is the best name what we could come up
> with before releasing and committing to this name "forever".
> 
> Once these are agreed on, I can take care of an initial release.
> 
> Robert
> 
> [1]: https://issues.apache.org/jira/browse/SLING-5768

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Robert,

thanks for merging SLING-6042. For your comment regarding the better 
location contrib/jcr I created SLING-6045 including a PR. So if everyone 
is happy with this version then, it would be great to have a first 
release!


Regards
Georg

On 2016-08-01 12:37, Robert Munteanu wrote:


1. Bundle name and location

Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . I would rather
see it named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr .

[jira] [Commented] (SLING-6045) Move oak-restrictions bundle to contrib/jcr, rename java package and GAV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-6045:
---

GitHub user ghenzler opened a pull request:

https://github.com/apache/sling/pull/169

SLING-6045 Moving module to contrib/jcr



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ghenzler/sling 
feature/SLING-6045-move-to-contrib-jcr

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #169


commit 5448934fd6be46c957ef5de8bef14765ac1ffd35
Author: georg.henzler 
Date:   2016-09-07T20:01:07Z

SLING-6045 Moving module to contrib/jcr




> Move oak-restrictions bundle to contrib/jcr, rename java package and GAV
> 
>
> 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
>
> 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.jcr.oak-restrictions and placed under
> contrib/jcr.



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

[GitHub] sling pull request #169: SLING-6045 Moving module to contrib/jcr

[ghenzler]

GitHub user ghenzler opened a pull request:

https://github.com/apache/sling/pull/169

SLING-6045 Moving module to contrib/jcr



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ghenzler/sling 
feature/SLING-6045-move-to-contrib-jcr

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #169


commit 5448934fd6be46c957ef5de8bef14765ac1ffd35
Author: georg.henzler 
Date:   2016-09-07T20:01:07Z

SLING-6045 Moving module to contrib/jcr




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (SLING-6045) Move oak-restrictions bundle to contrib/jcr, rename java package and GAV

[Georg Henzler (JIRA)]

Georg Henzler created SLING-6045:


 Summary: Move oak-restrictions bundle to contrib/jcr, rename java 
package and GAV
 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


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.jcr.oak-restrictions and placed under
contrib/jcr.



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

[jira] [Created] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile

[JIRA]

Jörg Hoh created SLING-6044:
---

 Summary: Conflicting LogManager and LogWriter if using the same 
logfile
 Key: SLING-6044
 URL: https://issues.apache.org/jira/browse/SLING-6044
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 4.0.2
Reporter: Jörg Hoh


When you have a logmanager and a logwriter pointing to the same file, you get 
an exception like this:

{panel}
07.09.2016 17:33:31.126 *ERROR* [] CM Configuration Updater (Update: 
pid=org.apache.sling.commons.log.LogManager) org.apache.felix.configadmin 
Service [org.apache.felix.cm.ConfigurationAdmin,9, 
[org.osgi.service.cm.ConfigurationAdmin]] [org.osgi.service.cm.ManagedService, 
id=10, 
bundle=7/slinginstall:c:\java\IBM\LibertyProfile\usr\servers\aem-1\sling\_\launchpad\startup\1\org.apache.sling.commons.log-4.0.0.jar]:
 Updating property org.apache.sling.commons.log.file of configuration 
org.apache.sling.commons.log.LogManager caused a problem: LogFile 
C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already 
configured by configuration 
org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
 (org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file 
: LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log 
already configured by configuration 
org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af)
 
org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file : 
LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log 
already configured by configuration 
org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
 
        at 
org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:32)
        at 
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)
 
        at 
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)
 
        at 
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1744)
 
        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) 
        at java.lang.Thread.run(Thread.java:744) 
Caused by: 
org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
        at 
org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLogWriter(LogConfigManager.java:398)
 
        at 
org.apache.sling.commons.log.logback.internal.LogConfigManager.updateGlobalConfiguration(LogConfigManager.java:327)
 
        at 
org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:30)
 
        ... 5 common frames omitted
{panel}

Obviously the Logmanager internally provides a Logwriter, so these conflict. 
This should be documented.



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

[jira] [Commented] (SLING-6027) Support existing Chunked upload functionality in streaming mode.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-6027:
---

Nothing can be done to eliminate the IO from copying chunks into the final 
result other than using streams directly wrapped into a containing stream. 
Discussion on potential improvements to Oak are being discussed on oak-dev at 
http://markmail.org/thread/lnzkwhcsqhvxzj2p.

Implementing both approaches in 
https://github.com/ieb/sling/compare/trunk...ieb:SLING-6027

> Support existing Chunked upload functionality in streaming mode.
> 
>
> Key: SLING-6027
> URL: https://issues.apache.org/jira/browse/SLING-6027
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Servlets Post 2.3.14
>
>
> The non streaming uploads support a  partial upload protocol implemented in 
> request parameters that is known in Sling terms as "Chunked" upload and 
> documented at 
> https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 
>  (not to be confused with Chunked Transfer encoding or the use of Http Range 
> headers).
> Sling Chunked uploading sends a sequence of POSTs containing multiple parts 
> of a file upload. When all the parts are uploaded a final request is sent 
> that causes all the parts to be merged into a single file in the JCR. From a 
> streaming point of view, each part can be streamed with the streaming 
> implementation supported by SLING-5948. Some additional code will be required 
> to set the file name appropriately and the struture.
> However, when the upload is completed, Sling must merge all the parts. To 
> maintain the streaming nature of the upload, this must be achieved without 
> incurring any local IO, otherwise the benefits of a streamed upload are lost.
> I am not certain how to achieve the merge given the limitations of the JCR 
> API other than by transferring all the body parts via the local JVM. That 
> won't incur local Disk IO but will multiply the overall IO requirement by 3x.
> If JCR/Oak had the functionality to concatenate Binaries it could do this 
> more efficiently depending on the DS implementation. If JCR/Oak exposed an 
> Seekable OutputStream the Application could avoid needing to save uploads to 
> the JCR as individual files. If JCR/Oak allowed an update to a binary to 
> start at a known location, again this could be avoided.



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

[jira] [Updated] (SLING-6027) Support existing Chunked upload functionality in streaming mode.

[Ian Boston (JIRA)]

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

Ian Boston updated SLING-6027:
--
Fix Version/s: Servlets Post 2.3.14

> Support existing Chunked upload functionality in streaming mode.
> 
>
> Key: SLING-6027
> URL: https://issues.apache.org/jira/browse/SLING-6027
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Servlets Post 2.3.14
>
>
> The non streaming uploads support a  partial upload protocol implemented in 
> request parameters that is known in Sling terms as "Chunked" upload and 
> documented at 
> https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 
>  (not to be confused with Chunked Transfer encoding or the use of Http Range 
> headers).
> Sling Chunked uploading sends a sequence of POSTs containing multiple parts 
> of a file upload. When all the parts are uploaded a final request is sent 
> that causes all the parts to be merged into a single file in the JCR. From a 
> streaming point of view, each part can be streamed with the streaming 
> implementation supported by SLING-5948. Some additional code will be required 
> to set the file name appropriately and the struture.
> However, when the upload is completed, Sling must merge all the parts. To 
> maintain the streaming nature of the upload, this must be achieved without 
> incurring any local IO, otherwise the benefits of a streamed upload are lost.
> I am not certain how to achieve the merge given the limitations of the JCR 
> API other than by transferring all the body parts via the local JVM. That 
> won't incur local Disk IO but will multiply the overall IO requirement by 3x.
> If JCR/Oak had the functionality to concatenate Binaries it could do this 
> more efficiently depending on the DS implementation. If JCR/Oak exposed an 
> Seekable OutputStream the Application could avoid needing to save uploads to 
> the JCR as individual files. If JCR/Oak allowed an update to a binary to 
> start at a known location, again this could be avoided.



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

Re: http-based/teleporter unit tests vs. paxexam integraiton tests (was: RE: flaky integration tests with teleporte rule)

[Carsten Ziegeler]

> 
>> 2. paxexam integration tests do not run in the IDE (at least not in
>> eclipse/junit runner - the problem seems to be that the pom information is
>> not available for version lookup). this is only nice-to-have.
> 
> Neither do I use Eclipse nor do I run ITs from my IDE, but I'm sure that 
> issue 
> can be solved.
> 

The simplest workaround for this is to manually add a few dependencies
to your Eclipse project - you don't need to add the bundles that are
launched by pax exam, but some of pax exams dependencies itself and
then this works perfectly.

You can also invoke the pax exam tests in debug mode from maven and then
connect to it using remote debugging.

I'm not saying this is perfect and if this could be simplified would be
great, but it's not rocket science either.

Carsten

 

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

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.0, Apache Sling Scripting HTL Java Compiler 1.0.0, Apache Sling Scripting HTL Engine 1.0.20, Apache Sling Scripting HTL JS Use Provider 1.0.1

[Bertrand Delacretaz]

Hi,

On Mon, Sep 5, 2016 at 6:59 PM, Radu Cotescu  wrote:
> ...Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1517 ...

+1 to release the artifacts listed below - checked signatures, builds
and that the svn tags match.

Although the renaming is infortunate, considering Roy's comment in the
"What's wrong with Sightly?" thread, the above comments indicating
that there should be no backwards compatibility issues, and
https://svn.apache.org/r1759438 which IIUC fixes the website issues I
think it's ok to proceed.

Artifacts:
SHA1(./htl-maven-plugin/1.0.0/htl-maven-plugin-1.0.0-source-release.zip)=
c6293c9f7b2aa819b3fe22b5d2c6fd8f7fa0f277
SHA1(./org.apache.sling.scripting.sightly/1.0.20/org.apache.sling.scripting.sightly-1.0.20-source-release.zip)=
7607cefd33ab699632dca8e5f839736f837f3f9b
SHA1(./org.apache.sling.scripting.sightly.compiler/1.0.0/org.apache.sling.scripting.sightly.compiler-1.0.0-source-release.zip)=
585b92cd0ea35ad33965db295524b175de1eb69a
SHA1(./org.apache.sling.scripting.sightly.compiler.java/1.0.0/org.apache.sling.scripting.sightly.compiler.java-1.0.0-source-release.zip)=
91dd1e79c51dad2e10c884c6111ca9809466122e
SHA1(./org.apache.sling.scripting.sightly.js.provider/1.0.12/org.apache.sling.scripting.sightly.js.provider-1.0.12-source-release.zip)=
ae8f1b2e68c9406cf727839942f47f6c9add2701
SHA1(./org.apache.sling.scripting.sightly.models.provider/1.0.2/org.apache.sling.scripting.sightly.models.provider-1.0.2-source-release.zip)=
6c8200ccea3d7a27590e730a7f1a5086cea26c51
SHA1(./org.apache.sling.scripting.sightly.repl/1.0.4/org.apache.sling.scripting.sightly.repl-1.0.4-source-release.zip)=
f4798a33cac848c60e7e12a4955d0f12f519095d

-Bertrand

[jira] [Resolved] (SLING-6043) Switch from inline configurations to config files

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6043.
-
Resolution: Fixed

[r1759600|https://svn.apache.org/r1759600]
[r1759601|https://svn.apache.org/r1759601]
[r1759603|https://svn.apache.org/r1759603]
[r1759604|https://svn.apache.org/r1759604]

> Switch from inline configurations to config files
> -
>
> Key: SLING-6043
> URL: https://issues.apache.org/jira/browse/SLING-6043
> Project: Sling
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
> Karaf Distribution 0.2.0, Karaf Configs 0.2.0
>
>
> Inline configurations (in features) have two major drawbacks in Karaf (4.0.5):
> * only [{{java.util.Property}} 
> format|https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#property-files-cfg]
>  ({{.cfg}}) is supported, not the required [Apache Felix ConfigAdmin 
> format|https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config]
>  ({{.config}})
> * factory configurations are created twice
> Though configuration files means more maintenance.



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

[jira] [Commented] (SLING-6017) Streaming Uploads detection of request parameters is wrong.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-6017:
---

Thanks for testing. 
I am still working on SLING-6027 (support for the Sling Chunked Upload 
protocol) and think we should wait till that is fixed before doing any 
releases. Can you work with the Snapshots for the time being ? 

> Streaming Uploads detection of request parameters is wrong.
> ---
>
> Key: SLING-6017
> URL: https://issues.apache.org/jira/browse/SLING-6017
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.6.2
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Servlets Post 2.3.14, Engine 2.6.4
>
>
> The way in which a request field that is not a file upload is detected is 
> wrong. Reported in SLING-5948.



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

[jira] [Assigned] (SLING-6027) Support existing Chunked upload functionality in streaming mode.

[Ian Boston (JIRA)]

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

Ian Boston reassigned SLING-6027:
-

Assignee: Ian Boston

> Support existing Chunked upload functionality in streaming mode.
> 
>
> Key: SLING-6027
> URL: https://issues.apache.org/jira/browse/SLING-6027
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> The non streaming uploads support a  partial upload protocol implemented in 
> request parameters that is known in Sling terms as "Chunked" upload and 
> documented at 
> https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 
>  (not to be confused with Chunked Transfer encoding or the use of Http Range 
> headers).
> Sling Chunked uploading sends a sequence of POSTs containing multiple parts 
> of a file upload. When all the parts are uploaded a final request is sent 
> that causes all the parts to be merged into a single file in the JCR. From a 
> streaming point of view, each part can be streamed with the streaming 
> implementation supported by SLING-5948. Some additional code will be required 
> to set the file name appropriately and the struture.
> However, when the upload is completed, Sling must merge all the parts. To 
> maintain the streaming nature of the upload, this must be achieved without 
> incurring any local IO, otherwise the benefits of a streamed upload are lost.
> I am not certain how to achieve the merge given the limitations of the JCR 
> API other than by transferring all the body parts via the local JVM. That 
> won't incur local Disk IO but will multiply the overall IO requirement by 3x.
> If JCR/Oak had the functionality to concatenate Binaries it could do this 
> more efficiently depending on the DS implementation. If JCR/Oak exposed an 
> Seekable OutputStream the Application could avoid needing to save uploads to 
> the JCR as individual files. If JCR/Oak allowed an update to a binary to 
> start at a known location, again this could be avoided.



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

[jira] [Created] (SLING-6043) Switch from inline configurations to config files

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6043:
---

 Summary: Switch from inline configurations to config files
 Key: SLING-6043
 URL: https://issues.apache.org/jira/browse/SLING-6043
 Project: Sling
  Issue Type: Improvement
  Components: Karaf
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
Karaf Distribution 0.2.0, Karaf Configs 0.2.0


Inline configurations (in features) have two major drawbacks in Karaf (4.0.5):
* only [{{java.util.Property}} 
format|https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#property-files-cfg]
 ({{.cfg}}) is supported, not the required [Apache Felix ConfigAdmin 
format|https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config]
 ({{.config}})
* factory configurations are created twice

Though configuration files means more maintenance.



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

Re: Fwd: http-based/teleporter unit tests vs. paxexam integraiton tests (was: RE: flaky integration tests with teleporte rule)

[Oliver Lietz]

On Wednesday 07 September 2016 09:29:15 Andrei Dulvac wrote:
> -- Forwarded message -
> From: Stefan Seifert 
> Date: Tue, Sep 6, 2016 at 11:25 PM
> Subject: http-based/teleporter unit tests vs. paxexam integraiton tests
> (was: RE: flaky integration tests with teleporte rule)
> To: dev@sling.apache.org 
> 
> Hi.
> 
> I'd also like to recommend the newly added
> https://github.com/apache/sling/tree/trunk/testing/junit/rules for
> HTTP-based tests. Having HTTP-level tests make sense to me when you have
> multiple instances, for example or want to have functional tests that cover
> a whole bunch of functionality.

hi Andrei,

managing tests over HTTP and invoking functionality over HTTP in tests (which 
I do in Scripting Thymeleaf also) are different things.

Regards,
O.

> >To be honest, I see only 2, maybe 3 cases where managing tests over HTTP
> >makes
> >sense:
> >
> >1. you do not want to start your (fat and slow) application under test from
> >the tests itself
> >2. you need a different runner than PaxExam (runners and rules are gone in
> >JUnit 5)
> >3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration-
> >tests
> >
> >In any other case I would use Pax Exam and @Inject to ensure required
> >services
> >are available before tests are executed.
> 
> this may be true.
> 
> before again using a http-based test (also with latest
> slingstart/provisoining features and teleporter rule they are much nicer
> than before) i played some minutes with paxexam and was drawn back by two
> isses (without further thinking or researching on them):
> 
> 1. within the codebase of org.apache.sling.testing.paxexam a long list of
> dependencies was hard-coded. this is usually not what i want. using
> slingstart i reference one sling launchpad version i want to target (e.g.
> 8) and deploy only few additional bundles. then i can be sure that my
> application works exactly with this versions of dependencies and felix
> framework, not only with the latest and greatest versions. if paxexam could
> be equipped with an "externalized" dependency management based on sling
> provisioning files and their modularization/overlay/inheritance features
> this would be great.
> 
> 2. paxexam integration tests do not run in the IDE (at least not in
> eclipse/junit runner - the problem seems to be that the pom information is
> not available for version lookup). this is only nice-to-have.
> 
> stefan

Re: http-based/teleporter unit tests vs. paxexam integraiton tests (was: RE: flaky integration tests with teleporte rule)

[Oliver Lietz]

On Tuesday 06 September 2016 21:25:45 Stefan Seifert wrote:
> >To be honest, I see only 2, maybe 3 cases where managing tests over HTTP
> >makes
> >sense:
> >
> >1. you do not want to start your (fat and slow) application under test from
> >the tests itself
> >2. you need a different runner than PaxExam (runners and rules are gone in
> >JUnit 5)
> >3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration-
> >tests
> >
> >In any other case I would use Pax Exam and @Inject to ensure required
> >services
> >are available before tests are executed.
> 
> this may be true.
> 
> before again using a http-based test (also with latest
> slingstart/provisoining features and teleporter rule they are much nicer
> than before) i played some minutes with paxexam and was drawn back by two
> isses (without further thinking or researching on them):

Note: I wrote Pax Exam, not Sling Testing PaxExam.

I've added Sling Testing PaxExam, because all of our existing testing options 
have one or the other drawback which prevent me from using them with *my* 
requirements.

> 1. within the codebase of org.apache.sling.testing.paxexam a long list of
> dependencies was hard-coded. this is usually not what i want. using
> slingstart i reference one sling launchpad version i want to target (e.g.
> 8) and deploy only few additional bundles. then i can be sure that my
> application works exactly with this versions of dependencies and felix
> framework, not only with the latest and greatest versions.

There is currently only Launchpad 8 with slingstart, you can not choose 
between different Launchpad versions. Slingstart is more or less *one* long 
list of hard-coded dependencies where Testing PaxExam provides a bunch of 
"features" (sets of dependencies) to use.  A release of Testing PaxExam will 
reflect a point in time with a working (tested) set of dependencies and 
configurations. And there will be a release in the future which matches 
Launchpad 9 of course.

Sightly, which occupies the .html extension, comes with Launchpad 8 and this 
prevents testing Scripting Thymeleaf with HTML scripts using .html extension. 
The removal of bundles from slingstart was added quite recently, right?
Another drawback of slingstart is the requirement for an extra IT module. With 
Testing PaxExam I can have all in one module.

> if paxexam could
> be equipped with an "externalized" dependency management based on sling
> provisioning files and their modularization/overlay/inheritance features
> this would be great.

You can override Testing PaxExam's "features" and use a different 
VersionResolver or override single versions. Bertrand came up with a 
requirement to pick up versions from project – added with SLING-6038.

> 2. paxexam integration tests do not run in the IDE (at least not in
> eclipse/junit runner - the problem seems to be that the pom information is
> not available for version lookup). this is only nice-to-have.

Neither do I use Eclipse nor do I run ITs from my IDE, but I'm sure that issue 
can be solved.

Regards,
O.

> stefan

Fwd: http-based/teleporter unit tests vs. paxexam integraiton tests (was: RE: flaky integration tests with teleporte rule)

[Andrei Dulvac]

-- Forwarded message -
From: Stefan Seifert 
Date: Tue, Sep 6, 2016 at 11:25 PM
Subject: http-based/teleporter unit tests vs. paxexam integraiton tests
(was: RE: flaky integration tests with teleporte rule)
To: dev@sling.apache.org 

Hi.

I'd also like to recommend the newly added
https://github.com/apache/sling/tree/trunk/testing/junit/rules for
HTTP-based tests. Having HTTP-level tests make sense to me when you have
multiple instances, for example or want to have functional tests that cover
a whole bunch of functionality.

>To be honest, I see only 2, maybe 3 cases where managing tests over HTTP
>makes
>sense:
>
>1. you do not want to start your (fat and slow) application under test from
>the tests itself
>2. you need a different runner than PaxExam (runners and rules are gone in
>JUnit 5)
>3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration-
>tests
>
>In any other case I would use Pax Exam and @Inject to ensure required
>services
>are available before tests are executed.


this may be true.

before again using a http-based test (also with latest
slingstart/provisoining features and teleporter rule they are much nicer
than before) i played some minutes with paxexam and was drawn back by two
isses (without further thinking or researching on them):

1. within the codebase of org.apache.sling.testing.paxexam a long list of
dependencies was hard-coded. this is usually not what i want. using
slingstart i reference one sling launchpad version i want to target (e.g.
8) and deploy only few additional bundles. then i can be sure that my
application works exactly with this versions of dependencies and felix
framework, not only with the latest and greatest versions. if paxexam could
be equipped with an "externalized" dependency management based on sling
provisioning files and their modularization/overlay/inheritance features
this would be great.

2. paxexam integration tests do not run in the IDE (at least not in
eclipse/junit runner - the problem seems to be that the pom information is
not available for version lookup). this is only nice-to-have.

stefan

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-6042:
---

Github user asfgit closed the pull request at:

https://github.com/apache/sling/pull/168


> 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)

[GitHub] sling pull request #168: SLING-6042 using sling:resourceTypesWithDescendants...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/sling/pull/168


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (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 resolved SLING-6042.

Resolution: Fixed

Applied in https://svn.apache.org/r1759570, thanks!

> 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)

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.0, Apache Sling Scripting HTL Java Compiler 1.0.0, Apache Sling Scripting HTL Engine 1.0.20, Apache Sling Scripting HTL JS Use Provider 1.0.1

[Robert Munteanu]

On Mon, 2016-09-05 at 16:59 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

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

[jira] [Commented] (SLING-6017) Streaming Uploads detection of request parameters is wrong.

[Satya Deep Maheshwari (JIRA)]

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

Satya Deep Maheshwari commented on SLING-6017:
--

[~ianeboston], I verified that  the fix works fine. Can you please release the 
related artifacts so that I can use the released version?

cc [~shgu...@adobe.com]

> Streaming Uploads detection of request parameters is wrong.
> ---
>
> Key: SLING-6017
> URL: https://issues.apache.org/jira/browse/SLING-6017
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.6.2
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Servlets Post 2.3.14, Engine 2.6.4
>
>
> The way in which a request field that is not a file upload is detected is 
> wrong. Reported in SLING-5948.



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

[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-5135 at 9/7/16 8:56 AM:


bq. ...I suppose calls to 
ResourceResolverFactory.getAdministrativeResourceResolver ultimately end up in 
a call to loginAdministrative which is subject to the whitelist?

The whitelist is indeed called but with the wrong client bundle reference. 

Calls to {{getAdministrativeResourceResolver()}} end up calling 
{{repository.loginAdministrative(null)}} in {{JcrProviderStateFactory}} which 
uses a {{SlingRepository}} service acquired by the {{JcrResourceProvider}} 
service. The reference client bundle for the whitelist is then the 
{{o.a.s.jcr.resource}} bundle even if it's another bundle which called 
{{getAdministrativeResourceResolver()}}, hiding the actual client bundle from 
the whitelist.

To fix this and take the whitelist into account for 
{{getAdministrativeResourceResolver()}} calls which end up hitting the 
{{JcrResourceProvider}} we need to modify that service so that it's registered 
with a custom {{ServiceFactory}} which stores a reference to the client bundle 
that's using the {{JcrResourceProvider}} service, as is done in 
{{AbstractSlingRepositoryManager.registerService()}}. That client bundle 
reference can then be passed to {{JcrProviderStateFactory}} so that the 
{{LoginAdminWhitelist}} can be used there, evaluated against the correct client 
bundle.

That's a somewhat complicated explanation - as I said I probably won't have 
time to work on this right now, so saving this knowledge for later ;-)


was (Author: bdelacretaz):
bq. ...I suppose calls to 
ResourceResolverFactory.getAdministrativeResourceResolver ultimately end up in 
a call to loginAdministrative which is subject to the whitelist?

That's not the case - calls to {{getAdministrativeResourceResolver()}} end up 
calling {{repository.loginAdministrative(null)}} in {{JcrProviderStateFactory}} 
which uses a {{SlingRepository}} service acquired by the 
{{JcrResourceProvider}} service. The reference client bundle for the whitelist 
is then the {{o.a.s.jcr.resource}} bundle even if it's another bundle which 
called {{getAdministrativeResourceResolver()}}, hiding the actual client bundle 
from the whitelist.

To fix this and take the whitelist into account for 
{{getAdministrativeResourceResolver()}} calls which end up hitting the 
{{JcrResourceProvider}} we need to modify that service so that it's registered 
with a custom {{ServiceFactory}} which stores a reference to the client bundle 
that's using the {{JcrResourceProvider}} service, as is done in 
{{AbstractSlingRepositoryManager.registerService()}}. That client bundle 
reference can then be passed to {{JcrProviderStateFactory}} so that the 
{{LoginAdminWhitelist}} can be used there, evaluated against the correct client 
bundle.

That's a somewhat complicated explanation - as I said I probably won't have 
time to work on this right now, so saving this knowledge for later ;-)

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

[jira] [Commented] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5135:


bq. ...I suppose calls to 
ResourceResolverFactory.getAdministrativeResourceResolver ultimately end up in 
a call to loginAdministrative which is subject to the whitelist?

That's not the case - calls to {{getAdministrativeResourceResolver()}} end up 
calling {{repository.loginAdministrative(null)}} in {{JcrProviderStateFactory}} 
which uses a {{SlingRepository}} service acquired by the 
{{JcrResourceProvider}} service. The reference client bundle for the whitelist 
is then the {{o.a.s.jcr.resource}} bundle even if it's another bundle which 
called {{getAdministrativeResourceResolver()}}, hiding the actual client bundle 
from the whitelist.

To fix this and take the whitelist into account for 
{{getAdministrativeResourceResolver()}} calls which end up hitting the 
{{JcrResourceProvider}} we need to modify that service so that it's registered 
with a custom {{ServiceFactory}} which stores a reference to the client bundle 
that's using the {{JcrResourceProvider}} service, as is done in 
{{AbstractSlingRepositoryManager.registerService()}}. That client bundle 
reference can then be passed to {{JcrProviderStateFactory}} so that the 
{{LoginAdminWhitelist}} can be used there, evaluated against the correct client 
bundle.

That's a somewhat complicated explanation - as I said I probably won't have 
time to work on this right now, so saving this knowledge for later ;-)

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

[jira] [Resolved] (SLING-5356) New ResourceBuilder module - fluent API to create content structures

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5356.

Resolution: Fixed

Makes sense, I agree with releasing this soon - marking this fixed.

> New ResourceBuilder module - fluent API to create content structures
> 
>
> Key: SLING-5356
> URL: https://issues.apache.org/jira/browse/SLING-5356
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> As discussed recently on our dev list the {{ContentBuilder}} currently 
> provided by the Sling Mocks library [1] can be very useful in testing.  
> _(edit: while implementing I have diverged from that idea and created a new, 
> more powerful {{ResourceBuilder}} API, for now that {{ContentBuilder}} stays 
> unchanged)_.
> In order to make it usable for both client-side and server-side testing (as 
> well as in server-side code) I'm planning to
> * Extract it into its own module
> * Define an API that allows for creating nodes and properties, importing JSON 
> and other files via the Sling ContentLoader and providing a simple a way to 
> cleanup the test content
> * Implement (first) a server-side version of that API
> * Implement (as a second priority) a client-side version that can be used in 
> test run via HTTP
> This shouldn't affect the existing Sling Mocks library users, except maybe 
> forcing them to rebuild their tests to use the new API.
> [1] 
> https://sling.apache.org/documentation/development/sling-mock.html#building-content



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

[jira] [Updated] (SLING-5998) NewJobSender should move to new ResourceChangeListener API

[Hanish Bansal (JIRA)]

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

Hanish Bansal updated SLING-5998:
-
Attachment: diff_SLING-5998.txt

> NewJobSender should move to new ResourceChangeListener API
> --
>
> Key: SLING-5998
> URL: https://issues.apache.org/jira/browse/SLING-5998
> Project: Sling
>  Issue Type: Task
>Reporter: Hanish Bansal
> Attachments: diff_SLING-5998.txt
>
>
> org.apache.sling.event.impl.jobs.notifications.NewJobSender 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-5998) NewJobSender should move to new ResourceChangeListener API

[Hanish Bansal (JIRA)]

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

Hanish Bansal commented on SLING-5998:
--

Attaching a diff patch which fixes this issue "diff_SLING-5998.txt"

> NewJobSender should move to new ResourceChangeListener API
> --
>
> Key: SLING-5998
> URL: https://issues.apache.org/jira/browse/SLING-5998
> Project: Sling
>  Issue Type: Task
>Reporter: Hanish Bansal
> Attachments: diff_SLING-5998.txt
>
>
> org.apache.sling.event.impl.jobs.notifications.NewJobSender 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)