[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson edited comment on SLING-6187 at 1/17/17 8:28 PM:


And at least for the {{@Encrypted}} case in AEM, the postfix is removed from 
the modification list and I would expect that this is the required practice 
since the {{foo@Postfix}} property is not actually "modified".


was (Author: justinedelson):
And at least for the {{@Encrypted}} case in AEM, the postfix is removed from 
the modification list.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

Ah, thanks for the test. This wasn't apparent from skimming over the code! An 
explicit comment might be great, since it would be crucial.

We should have a look at the @Suffixes we know (in Sling and AEM) and ask the 
community to get a sense.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

And at least for the {{@Encrypted}} case in AEM, the postfix is removed from 
the modification list.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

[~alexander.klimetschek] the way the patch works is that:

1. Look for all the modifications which have an @ in them. Consider the part 
before the @ to be the "base path".
2. For each of those, identify if there is a item in the modification list with 
that "base path"
3. If there is one, fail.

So if the modification list contains
* {{foo}} + {{foo@Suffix}} - fail
* {{foo}} - ok
* {{foo@Suffix}} - ok

I realized I forgot to include the test for the last case in the diff. Here it 
is:

{code}
public void testRemainingPostfixWithoutUnPostfixedIsSuccessful() {
TestingResourceResolver resourceResolver = new 
TestingResourceResolver();

MockSlingHttpServlet3Request request = new 
MockSlingHttpServlet3Request("/test", null, null, null, null);
request.setResourceResolver(resourceResolver);

final PostOperation operation = new AbstractPostOperation() {
@Override
protected void doRun(SlingHttpServletRequest request, PostResponse 
response, List changes) throws RepositoryException {
changes.add(Modification.onChange(ModificationType.CREATE, 
"/content/test@Postfix"));
}
};

HtmlResponse response = new HtmlResponse();
operation.run(request, response, new SlingPostProcessor[0]);
assertTrue(response.isSuccessful());
assertTrue(resourceResolver.commitCalled);
assertFalse(resourceResolver.revertCalled);
}
{code}

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-6187 at 1/17/17 8:13 PM:
---

Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all 
@Suffixes, thus breaking any cases where someone would legitimately try to 
create a {{foo@Suffix}} property in JCR. As [mentioned 
above|#comment-15746876], we can make it a bit more selective by only checking 
for suffixes where there is an according parameter without the suffix:

* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip

I was also thinking of post processors to indicate their suffix(es) in a 
service property and have the post servlet check for it explicitly. However, 
checking the modification list could work as well. Not sure if existing post 
processors would typically remove the @Suffix entries from the change list - if 
not, it would fail.

The other alternative to avoid any backwards compatibility issues (at the cost 
of changing the request signature for the affected clients of the encryption 
use case or any other that wants to benefit from this new validation) would be 
to come up with something distinctively different, say {{@@@Suffix}}.


was (Author: alexander.klimetschek):
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all 
@Suffixes, thus breaking any cases where someone would legitimately try to 
create a {{foo@Suffix}} property in JCR. As [mentioned 
above|#comment-15746876], we can make it a bit more selective by only checking 
for suffixes where there is an according parameter without the suffix:

* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} => skip

I was also thinking of post processors to indicate their suffix(es) in a 
service property and have the post servlet check for it explicitly. However, 
checking the modification list could work as well. Not sure if existing post 
processors would typically remove the @Suffix entries from the change list - if 
not, it would fail.

The other alternative to avoid any backwards compatibility issues (at the cost 
of changing the request signature for the affected clients of the encryption 
use case or any other that wants to benefit from this new validation) would be 
to come up with something distinctively different, say {{@@@Suffix}}.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all 
@Suffixes, thus breaking any cases where someone would legitimately try to 
create a {{foo@Suffix}} property in JCR. As [mentioned 
above|#comment-15746876], we can make it a bit more selective by only checking 
for suffixes where there is an according parameter without the suffix:

* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} => skip

I was also thinking of post processors to indicate their suffix(es) in a 
service property and have the post servlet check for it explicitly. However, 
checking the modification list could work as well. Not sure if existing post 
processors would typically remove the @Suffix entries from the change list - if 
not, it would fail.

The other alternative to avoid any backwards compatibility issues (at the cost 
of changing the request signature for the affected clients of the encryption 
use case or any other that wants to benefit from this new validation) would be 
to come up with something distinctively different, say {{@@@Suffix}}.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-6187 at 1/17/17 8:14 PM:
---

Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all 
@Suffixes, thus breaking any cases where someone would legitimately try to 
create a {{foo@Suffix}} property in JCR. As [mentioned 
above|#comment-15746876], we can make it a bit more selective by only checking 
for suffixes where there is an according parameter without the suffix:

* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip

I was also thinking of post processors to indicate their suffix(es) in a 
service property and have the post servlet check for it explicitly. However, 
checking the modification list at the end as in your patch could work as well. 
Not sure if existing post processors would typically remove the @Suffix entries 
from the change list - if not, it would fail.

The other alternative to avoid any backwards compatibility issues (at the cost 
of changing the request signature for the affected clients of the encryption 
use case or any other that wants to benefit from this new validation) would be 
to come up with something distinctively different, say {{@@@Suffix}}.


was (Author: alexander.klimetschek):
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all 
@Suffixes, thus breaking any cases where someone would legitimately try to 
create a {{foo@Suffix}} property in JCR. As [mentioned 
above|#comment-15746876], we can make it a bit more selective by only checking 
for suffixes where there is an according parameter without the suffix:

* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip

I was also thinking of post processors to indicate their suffix(es) in a 
service property and have the post servlet check for it explicitly. However, 
checking the modification list could work as well. Not sure if existing post 
processors would typically remove the @Suffix entries from the change list - if 
not, it would fail.

The other alternative to avoid any backwards compatibility issues (at the cost 
of changing the request signature for the affected clients of the encryption 
use case or any other that wants to benefit from this new validation) would be 
to come up with something distinctively different, say {{@@@Suffix}}.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Updated] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6187:
--
Attachment: SLING-6187c.diff

[~alexander.klimetschek] I'm attaching a new patch (SLING-6187c.diff) which 
implements what I think you were describing. I'm still a little concerned about 
the backwards compatibility impact, but I am coming around to the simplicity of 
this solution.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6473:
---

[~bdelacretaz] you can either directly reference a file as you show in your 
example or you can reference the slingfeature.txt artifact of a maven module, 
which is what my example above does.

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Closed] (SLING-6445) HTL scripts do not compile on Windows if the compiler needs to generate any warnings

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-6445.
---

> HTL scripts do not compile on Windows if the compiler needs to generate any 
> warnings
> 
>
> Key: SLING-6445
> URL: https://issues.apache.org/jira/browse/SLING-6445
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
>Priority: Critical
> Fix For: Scripting HTL Compiler 1.0.6, HTL Maven Plugin 1.0.6
>
>
> If an HTL script with potential warnings is compiled on Windows, the compiler 
> will fail with a NPE like:
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>   at java.lang.String.substring(Unknown Source)
>   at 
> org.apache.sling.scripting.sightly.compiler.SightlyCompiler.getScriptError(SightlyCompiler.java:170)
>   at 
> org.apache.sling.scripting.sightly.compiler.SightlyCompiler.compile(SightlyCompiler.java:149)
>   at 
> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.internalCompile(SightlyScriptEngine.java:135)
>   at 
> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.compile(SightlyScriptEngine.java:80)
>   at 
> org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider.provide(RenderUnitProvider.java:126)
>   at 
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:72)
>   at 
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:75)
> {code}
> The compiler assumes that system line separators are being used in the files, 
> which most of the times is not happening as the scripts might have been 
> edited on another system.



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

[jira] [Commented] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6473:


Ah, I see, sorry for the noise:

{code}
new 
ProvisioningModelVersionResolver(getClass().getResource("/test-dependencies.txt"));
{code}

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Created] (SLING-6475) Distribution IT test fail on Jenkins

[Timothee Maret (JIRA)]

Timothee Maret created SLING-6475:
-

 Summary: Distribution IT test fail on Jenkins 
 Key: SLING-6475
 URL: https://issues.apache.org/jira/browse/SLING-6475
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution Integration Tests
Reporter: Timothee Maret
Assignee: Timothee Maret


50 IT tests currently fail on Apache Jenkins, see 
https://builds.apache.org/job/sling-contrib-extensions-distribution-it-1.8



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

[jira] [Commented] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6473:


How do you define which provisioning model files are used?

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Closed] (SLING-6428) DateFormat is printed when date-value is empty

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-6428.
---

> DateFormat is printed when date-value is empty
> --
>
> Key: SLING-6428
> URL: https://issues.apache.org/jira/browse/SLING-6428
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.28, Scripting HTL Java Compiler 
> 1.0.6
>Reporter: Feike Visser
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.30, Scripting HTL Java Compiler 
> 1.0.8
>
>
> When the format-value emtpy, the date-format is printed.
> Example
> {code}
> 
> ${'-MM-dd' @ format=date1}
> 
> {code}
> In my view the date-format should not be printed, never.



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

[jira] [Closed] (SLING-6450) [HTL] Cannot retrieve "length" property for arrays of primitive types

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-6450.
---

> [HTL] Cannot retrieve "length" property for arrays of primitive types
> -
>
> Key: SLING-6450
> URL: https://issues.apache.org/jira/browse/SLING-6450
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.6, Scripting HTL Java 
> Compiler 1.0.8
>
>
> When attempting to retrieve the {{length}} property of an array of 
> primitives, HTL will return {{null}}. The behaviour should, however, be 
> unitary with the one for Object arrays.



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

[jira] [Updated] (SLING-6471) [HTL] data-sly-repeat should add a new line after every appended element in the output

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6471:

Fix Version/s: (was: Scripting HTL Compiler 1.0.6)
   Scripting HTL Compiler 1.0.8

> [HTL] data-sly-repeat should add a new line after every appended element in 
> the output
> --
>
> Key: SLING-6471
> URL: https://issues.apache.org/jira/browse/SLING-6471
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.8
>
>
> The {{data-sly-repeat}} block element should append a new line after every 
> rendered element, to make the resulting markup more easy to follow.



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

[RESULT][VOTE] Release Apache Sling Scripting HTL Compiler 1.0.6, Apache Sling Scripting HTL Java Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.30, Apache Sling HTL Maven Plugin 1.0.6

[Radu Cotescu]

Hello,

The release passes with 3 +1 binding votes from Stefan Seifert, Radu
Cotescu and Robert Munteanu.

Thanks,
Radu

[jira] [Created] (SLING-6474) Commons Metrics DOES not declare provide capability for Metrics service

[Nino Martinez (JIRA)]

Nino Martinez created SLING-6474:


 Summary: Commons Metrics DOES not declare provide capability for 
Metrics service
 Key: SLING-6474
 URL: https://issues.apache.org/jira/browse/SLING-6474
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Metrics 1.2.0
Reporter: Nino Martinez


Commons Metrics needs to declare provide capability for 
org.apache.sling.commons.metrics.MetricsService in manifest.MF

otherwise other bundles that specifies require capability on the MetricsService 
will fail to start.

AS of maven bundle plugin 3.2.0 this will become a problem, since they fixed 
the capabilities generation.



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

[jira] [Deleted] (SLING-6455) Local importer should not fail if package stream is unnecessarily reset

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili deleted SLING-6455:
---


> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6455
> URL: https://issues.apache.org/jira/browse/SLING-6455
> Project: Sling
>  Issue Type: Bug
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the 
> beginning of the block for handling non reference package as to support also 
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}. 
> Currently it fails if reset is called unnecessarily, while it shouldn't be 
> the case.



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

[jira] [Deleted] (SLING-6454) Local importer should not fail if package stream is unnecessarily reset

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili deleted SLING-6454:
---


> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6454
> URL: https://issues.apache.org/jira/browse/SLING-6454
> Project: Sling
>  Issue Type: Bug
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the 
> beginning of the block for handling non reference package as to support also 
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}. 
> Currently it fails if reset is called unnecessarily, while it shouldn't be 
> the case.



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

Re: Allow PaxExam to consume provisioning models

[Julian Sedding]

I went ahead and implememnted this idea[0]. The issue also shows a usage sample.

Regards
Julian

[0] https://issues.apache.org/jira/browse/SLING-6473

[jira] [Commented] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6473:
---

The feature can be used e.g. as follows:

{code:java}
// create version resolver based on sling launchpad as defined in the pom
final VersionResolver versionResolver = ProvisioningModelVersionResolver
.fromSlingfeature(maven("org.apache.sling", 
"org.apache.sling.launchpad").versionAsInProject());
// get the sling engine bundle in the same version that's defined in the sling 
launchpad
mavenBundle("org.apache.sling", 
"org.apache.sling.engine").version(versionResolver);
{code}

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Commented] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6473:
---

Fixed in [r1779180|https://svn.apache.org/r1779180].

[~olli] Since you created the Testing PaxExam module, could you please review? 
If you think this code does not fit the module, feel free to revert or give me 
a shout.

> Create a VersionResolver that provides versions from provisioning model files
> -
>
> Key: SLING-6473
> URL: https://issues.apache.org/jira/browse/SLING-6473
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> It would be convenient to have a {{VersionResolver}} for PaxExam tests that 
> is based on the versions defined in the {{launchpad/builder}} module. In more 
> general terms this would be a {{VersionResolver}} that can consume a 
> provisioning model file in order to provide versions for maven artifacts to 
> PaxExam tests.
> The [idea was also discussed on the mailing 
> list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Created] (SLING-6473) Create a VersionResolver that provides versions from provisioning model files

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6473:
-

 Summary: Create a VersionResolver that provides versions from 
provisioning model files
 Key: SLING-6473
 URL: https://issues.apache.org/jira/browse/SLING-6473
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing PaxExam 0.0.2
Reporter: Julian Sedding
Assignee: Julian Sedding
Priority: Minor


It would be convenient to have a {{VersionResolver}} for PaxExam tests that is 
based on the versions defined in the {{launchpad/builder}} module. In more 
general terms this would be a {{VersionResolver}} that can consume a 
provisioning model file in order to provide versions for maven artifacts to 
PaxExam tests.

The [idea was also discussed on the mailing 
list|http://sling.markmail.org/thread/o2gkkizydt375poz] a little while ago.



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

[jira] [Closed] (SLING-6328) JSP concurrent compiling issue

[Julian Sedding (JIRA)]

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

Julian Sedding closed SLING-6328.
-

> JSP concurrent compiling issue
> --
>
> Key: SLING-6328
> URL: https://issues.apache.org/jira/browse/SLING-6328
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.1.6
>Reporter: Sameer Charles
>Assignee: Julian Sedding
>Priority: Critical
> Fix For: Scripting JSP 2.2.4
>
> Attachments: SLING-6328-backported-changes-jsedding.patch
>
>
> At times JSP fails to compile due to duplicate variable error (Duplicate 
> local variable _jspx_temp0).
> This is suppose to be fixed in jasper (within Tomcat) but not in Sling impl. 
> See https://bz.apache.org/bugzilla/show_bug.cgi?id=45691
> This seems to be the culprit (see line 623) but there might be other issues.
> https://github.com/apache/sling/blob/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/jasper/compiler/JspUtil.java



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

[jira] [Comment Edited] (SLING-6250) Importing packages with large headers fails

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili edited comment on SLING-6250 at 1/17/17 11:19 AM:
--

the _stream.reset()_ call was set there to make 
{{LocalDistributionPackageImporter}} work together with 
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used 
for both storing a reference package and the referenced (actual) package which 
come with different headers.
I have put a _TODO_ as I think that reset should be avoided at all if possible, 
but that's not needed in most of the cases (async dispatching is not used by 
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much 
anyway) and open a new one for improving the way headers are read in sync and 
async cases.


was (Author: teofili):
the _stream.reset()_ call was set there to make 
{{LocalDistributionPackageImporter}} work together with 
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used 
for both storing a reference package and the referenced (actual) package.
I have put a _TODO_ as I think that reset should be avoided at all if possible, 
but that's not needed in most of the cases (async dispatching is not used by 
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much 
anyway) and open a new one for improving the way headers are read in sync and 
async cases.

> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many 
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
>   at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the 
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This 
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]



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

[jira] [Commented] (SLING-6250) Importing packages with large headers fails

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SLING-6250:


the _stream.reset()_ call was set there to make 
{{LocalDistributionPackageImporter}} work together with 
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used 
for both storing a reference package and the referenced (actual) package.
I have put a _TODO_ as I think that reset should be avoided at all if possible, 
but that's not needed in most of the cases (async dispatching is not used by 
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much 
anyway) and open a new one for improving the way headers are read in sync and 
async cases.

> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many 
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
>   at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the 
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This 
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]



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

[jira] [Commented] (SLING-6250) Importing packages with large headers fails

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6250:
---

[~teofili] I don't understand how swallowing the exception fixes the issue. 
Could you please explain why that's a valid fix?

> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many 
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
>   at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the 
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This 
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]



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

[jira] [Resolved] (SLING-6472) Update to SCR 2.0.8 and Web Console Plugin 2.0.4

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6472.
-
Resolution: Fixed

Updated in rev 1779165

> Update to SCR 2.0.8 and Web Console Plugin 2.0.4
> 
>
> Key: SLING-6472
> URL: https://issues.apache.org/jira/browse/SLING-6472
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Builder 9
>
>




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

[jira] [Created] (SLING-6472) Update to SCR 2.0.8 and Web Console Plugin 2.0.4

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6472:
---

 Summary: Update to SCR 2.0.8 and Web Console Plugin 2.0.4
 Key: SLING-6472
 URL: https://issues.apache.org/jira/browse/SLING-6472
 Project: Sling
  Issue Type: Task
  Components: Launchpad
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Launchpad Builder 9






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

[jira] [Resolved] (SLING-6250) Importing packages with large headers fails

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-6250.

Resolution: Fixed

test added in r1779164, fix was introduced in r1778443.

> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many 
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
>   at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the 
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This 
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]



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

Re: [RESULT] [VOTE] Release Apache Sling Tenant version 1.1.0

[Timothee Maret]

Thanks Stefan! I could complete the release process.

Regards,

Timothee

2017-01-17 9:54 GMT+01:00 Stefan Seifert :

>
> > Actually, could someone from the PMC please copy the release to the Sling
> >dist repository ?
>
> done in rev. 17833
>
> stefan
>

[jira] [Closed] (SLING-5240) Remove getAdministrativeResourceResolver() usage from org.apache.sling.tenant

[Timothee Maret (JIRA)]

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

Timothee Maret closed SLING-5240.
-

> Remove getAdministrativeResourceResolver() usage from org.apache.sling.tenant
> -
>
> Key: SLING-5240
> URL: https://issues.apache.org/jira/browse/SLING-5240
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Antonio Sanso
>Assignee: Timothee Maret
> Fix For: Tenant 1.1.0
>
> Attachments: patch.txt
>
>
> Counted 1 occurrence



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

[jira] [Closed] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Timothee Maret (JIRA)]

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

Timothee Maret closed SLING-4753.
-

> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.1.0
>Reporter: Agraj Mangal
>Assignee: Timothee Maret
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[jira] [Closed] (SLING-4234) Tenant create implementation does not match with the API

[Timothee Maret (JIRA)]

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

Timothee Maret closed SLING-4234.
-

> Tenant create implementation does not match with the API 
> -
>
> Key: SLING-4234
> URL: https://issues.apache.org/jira/browse/SLING-4234
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.0.2
>Reporter: Timothee Maret
>Assignee: Carsten Ziegeler
> Fix For: Tenant 1.1.0
>
>
> The API org.apache.sling.tenant.TenantManager#create stipulates
> {code}
> @throws IllegalArgumentException if a tenant with the same {@code tentantId} 
> already exists.
> {code}
> However, the implementation in 
> org.apache.sling.tenant.internal.TenantProviderImpl#create does not implement 
> this. Instead, it returns null when the tenant already exists.



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

[jira] [Closed] (SLING-3695) TenantProvider throws NPE when listing tenants root tenant resource does not exist

[Timothee Maret (JIRA)]

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

Timothee Maret closed SLING-3695.
-

> TenantProvider throws NPE when listing tenants root tenant resource does not 
> exist
> --
>
> Key: SLING-3695
> URL: https://issues.apache.org/jira/browse/SLING-3695
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.0.2
>Reporter: Timothee Maret
>Assignee: Carsten Ziegeler
>Priority: Minor
>  Labels: tenant
> Fix For: Tenant 1.1.0
>
> Attachments: SLING-3695.patch
>
>
> The method
> org.apache.sling.tenant.TenantProvider#getTenants
> throws an NPE when the tenant root resource does not exists.
> The tenant root resource is created if needed when creating a tenant (see 
> org.apache.sling.tenant.internal.TenantProviderImpl#createTenantResource)
> A workaround is to create a tenant and remove it.



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

[jira] [Updated] (SLING-4207) Add notifications upon tenant changes

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-4207:
--
Fix Version/s: (was: Tenant 1.1.0)
   Tenant 1.1.2

> Add notifications upon tenant changes
> -
>
> Key: SLING-4207
> URL: https://issues.apache.org/jira/browse/SLING-4207
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Tenant 1.0.2
>Reporter: Timothee Maret
>Assignee: Felix Meschberger
> Fix For: Tenant 1.1.2
>
> Attachments: SLING-4207.patch, SLING-4207.patch, SLING-4207.patch, 
> SLING-4207.patch
>
>
> Currently, there is no clean way to detect when a tenant has been 
> added/removed/modified.
> We may detect when a change is required by implementing the TenantCustomizer 
> interface, however, it tells nothing about the actual completion of the 
> change.
> We may listen for OSGI events under /etc/tenants but this requires the user 
> to know where the tenants are located (which afaik, currently is not exposed).
> In order to allow apps reacting on tenant changes, I propose to either:
> I. extend the current SPI with an interface TenantEventListener that users 
> can implement ; or 
> II. send OSGI events form the current implementation.
> In both cases, the events should cover
> * Tenant added
> * Tenant removed
> * Property added
> * Property removed



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

RE: [RESULT] [VOTE] Release Apache Sling Tenant version 1.1.0

[Stefan Seifert]

> Actually, could someone from the PMC please copy the release to the Sling
>dist repository ?

done in rev. 17833

stefan

[jira] [Resolved] (SLING-6471) [HTL] data-sly-repeat should add a new line after every appended element in the output

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6471.
-
Resolution: Fixed

Fixed in [r1779151|https://svn.apache.org/r1779151].

> [HTL] data-sly-repeat should add a new line after every appended element in 
> the output
> --
>
> Key: SLING-6471
> URL: https://issues.apache.org/jira/browse/SLING-6471
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.6
>
>
> The {{data-sly-repeat}} block element should append a new line after every 
> rendered element, to make the resulting markup more easy to follow.



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

[jira] [Created] (SLING-6471) [HTL] data-sly-repeat should add a new line after every appended element in the output

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6471:
---

 Summary: [HTL] data-sly-repeat should add a new line after every 
appended element in the output
 Key: SLING-6471
 URL: https://issues.apache.org/jira/browse/SLING-6471
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL Compiler 1.0.6


The {{data-sly-repeat}} block element should append a new line after every 
rendered element, to make the resulting markup more easy to follow.



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