Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Konrad Windszus]

> On 28 Feb 2017, at 00:29, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 11:45:16 Konrad Windszus wrote:
>>> On 27 Feb 2017, at 11:28, Oliver Lietz  wrote:
>>> 
>>> On Monday 27 February 2017 11:00:54 Konrad Windszus wrote:
> On 27 Feb 2017, at 10:54, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
>>> On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
>>> 
>>> On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
 Hey, I don't really think the change for that in
 https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validati
 on
 /a
 pi
 /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailu
 re
 .j
 ava ?r1=1734530=1784472=1784472 was good. The
 resourceBundle
 parameter is marked as @Nonnull. If you give a null here the return
 value is useless (because the key cannot be resolved against the
 MessageBundle). Your change makes it harder to detect such
 programming
 errors during development, because you no longer throw a (noisy)
 exception, but rather fall back to a IMHO useless default (empty
 string)
 which is rather unexpected.
 
 What is the reason for that change?
>>> 
>>> Hi Konrad,
>>> 
>>> checking for null allows validation even if resource bundle is
>>> missing.
>>> I don't think validation should stop working just because human
>>> readable
>>> message is missing.
>> 
>> Yes I agree, but then your code should not call that specific method.
> 
> Do you mean validation should stop working when messages are not
> present?
> 
>> Where exactly in your code is it called with ResourceBundle = null?
> 
> It's in ValidationPostResponseCreator.
 
 This is test code only. If this cannot rely on a real ResourceBundle
 (which
 previous to your move to PaxExam was the case), then we should rather
 modify the ValidationPostResponseCreator to deal with that. But I would
 really like to validate in the IT that the right english translations are
 provided (therefore PaxExam should provide the slingi18n bundle and
 therefore also the right resource bundle).
>>> 
>>> The faster Pax Exam-based test discloses a situation which can also happen
>>> in production and Validation should handle it gracefully. We can log a
>>> message (warn) in case resource bundle is missing of course.
>>> The tests itself are not modified at all and still check the validation
>>> message.
>> 
>> The ValidationPostResponseCreator is test code only and does not properly
>> protect against null values in the resource bundle (although it would be
>> its obligation). That is the bug which needs to be fixed. For every other
>> client using the ValidationFailure.getMessage(null) should also lead to an
>> exception, because that is definitely an invalid (i.e. not-supported) use
>> case. In the ValidationPostResponseCreator we should just throw an
>> exception if the resource bundle can not be retrieved.
>> 
>> If the tests now always succeed this means that the resource bundle is
>> actually never null, because in case it would be null, the validation
>> failure messages would not be as expected.
> 
> As I said before, a resource bundle could be null in production also and we 
> should handle it gracefully.
Disagree here, no code is forced to call 
ValidationFailure.getMessage(ResourceBundle). Therefore the caller needs to 
handle it gracefully in case the resource bundle is null. The JSR305 annotation 
clearly states that the parameter must not be null.

> Similar situation happens when just a message is 
> missing (the message key is returned – which I don't like because it 
> discloses 
> internal information):
right, but I don't think these two are comparable


> we do not throw an exception and validation still 
> works.
Yes, validation works. It is just that you should not call 
ValidationFailure.getMessage(ResourceBundle) in case you don't have a resource 
bundle.
We could think about adding another method which will expose the message keys 
and arguments.
> 
> * a validation failure can be useful even without human readable message
Agree and as I said, this works even without handling null gracefully.
> * no programming errors are hidden by this change
Don't agree, because your change makes the method return the empty string which 
might hide programming errors like an uninitialized variable of a resource 
bundle variable
> * if validation result is valid, resource bundle is not used at all
Yes, and even if it is actually invalid, that does not necessarily lead to the 
usage of this method. Only in our ITs this is the case.
> 
> There is no reason to break validation on missing resource bundle.
We 

[jira] [Closed] (SLING-5681) Teleporter: Improve mechanism to check if a deployed test bundle can be started

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-5681.
--

> Teleporter: Improve mechanism to check if a deployed test bundle can be 
> started
> ---
>
> Key: SLING-5681
> URL: https://issues.apache.org/jira/browse/SLING-5681
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Tests Teleporter 1.0.12
>
>
> Currently if a bundle being deployed through the {{ClientSideTeleporter}} 
> cannot be started, this is only detected because the Remote JUnit Servlet 
> does not return a non 404 status. This should be improved by relying on the 
> http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html#bundles-plugin
>  and a check on the JSON response.
> An error response of e.g. 
> {{http://localhost:41005/system/console/bundles/ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c:0.json}}
>  might look like this
> {code}
> {
>   "status": "Bundle information: 140 bundles in total, 134 bundles active, 5 
> bundles active fragments, 1 bundle installed.",
>   "s": [
> 140,
> 134,
> 5,
> 0,
> 1
>   ],
>   "data": [
> {
>   "id": 142,
>   "name": 
> "ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c",
>   "fragment": false,
>   "stateRaw": 2,
>   "state": "Installed",
>   "version": "0",
>   "symbolicName": 
> "ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c",
>   "category": "",
>   "props": [
> {
>   "key": "Symbolic Name",
>   "value": 
> "ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c"
> },
> {
>   "key": "Version",
>   "value": "0"
> },
> {
>   "key": "Bundle Location",
>   "value": 
> "inputstream:ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c.jar"
> },
> {
>   "key": "Last Modification",
>   "value": "Fri Apr 22 14:08:27 CEST 2016"
> },
> {
>   "key": "Start Level",
>   "value": 20
> },
> {
>   "key": "Imported Packages",
>   "value": [
> "ERROR: org.apache.sling.junit.rules -- Cannot be resolved",
> "ERROR: org.junit -- Cannot be resolved",
> "org.osgi.service.cm from  href='/system/console/bundles/7'>org.apache.felix.configadmin (7)"
>   ]
> },
> {
>   "key": "Manifest Headers",
>   "value": [
> "Bnd-LastModified: 1461326886812",
> "Built-By: konradwindszus",
> "Bundle-ManifestVersion: 2",
> "Bundle-Name: 
> ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c",
> "Bundle-SymbolicName: 
> ClientSideTeleporter.14-07-21-.837e5ada-c58a-4653-9087-e1c4aad27e0c",
> "Bundle-Version: 0",
> "Created-By: 1.8.0_74 (Oracle Corporation)",
> "Import-Package: org.apache.sling.junit.rules, org.junit, 
> org.osgi.service.cm",
> "Manifest-Version: 1.0",
> "Originally-Created-By: pax-tinybundles-2.0.0",
> "Private-Package: org.apache.sling.testing.samples.modulewit",
> "Sling-Test-Regexp: 
> org.apache.sling.testing.samples.modulewit.BasicTeleportedIT.*",
> "TinybundlesVersion: pax-tinybundles-2.0.0",
> "Tool: Bnd-2.1.0.20130426-122213"
>   ]
> },
> {
>   "key": "nfo",
>   "value": {}
> }
>   ]
> }
>   ]
> }
> {code}
> So the {{state}} as well as the {{Imported Packages}} section gives a good 
> hint, why a bundle could not be started!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6546) Ease debugging of teleporter-based tests

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6546.
--

> Ease debugging of teleporter-based tests
> 
>
> Key: SLING-6546
> URL: https://issues.apache.org/jira/browse/SLING-6546
> Project: Sling
>  Issue Type: Improvement
>  Components: Apache Sling Testing Rules
>Affects Versions: JUnit Tests Teleporter 1.0.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Tests Teleporter 1.0.12
>
>
> There should be optionally some logging which exposes 
> # when a test bundle is being deployed
> # which packages are contained in the test bundle
> # when a test bundle is being uninstalled
> In addition it should be possible to inspect the test bundles post-mortem (by 
> persisting them below {{target/test-bundles}}) and it should be possible to 
> disable uninstalling the test bundle after the test execution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6558) Allow bundle headers to be configured via the DefaultPropertyBasedCustomizer

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6558.
--

> Allow bundle headers to be configured via the DefaultPropertyBasedCustomizer
> 
>
> Key: SLING-6558
> URL: https://issues.apache.org/jira/browse/SLING-6558
> Project: Sling
>  Issue Type: Improvement
>  Components: Apache Sling Testing Rules
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Tests Teleporter 1.0.12
>
>
> The additional bundle headers should be configurable via a System property in 
> the {{DefaultPropertyBasedCustomizer}}. This is e.g. necessary for content 
> loading 
> (https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6551) Allow to embed a complete classes directory in the test bundle

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6551.
--

> Allow to embed a complete classes directory in the test bundle
> --
>
> Key: SLING-6551
> URL: https://issues.apache.org/jira/browse/SLING-6551
> Project: Sling
>  Issue Type: Improvement
>  Components: Apache Sling Testing Rules
>Affects Versions: JUnit Tests Teleporter 1.0.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Tests Teleporter 1.0.12
>
>
> Currently only 
> # directly referenced dependencies from the IT can be automatically be 
> embedded (by whitelisting the package prefixes via 
> {{ClientSideTeleporter.includeDependencyPrefix(...)}}
> # invididual fully-qualified classes can be embedded manually as well via 
> {{ClientSideTeleporter.embedClass(...)}}
> This is not enough in case the teleporter-based IT is part of the bundle 
> which is supposed to be tested. The mechanism in 1) will not detect any 
> implementation classes like OSGi services (because the IT itself only 
> references the according interface). The mechanism 2) causes a lot of effort 
> as each class name needs to be given separately. In this case it would be 
> best to be able to include a full directory containing java classes in the 
> testing bundle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6541) slingstart-maven-plugin: Make enriching the Maven classpath optional

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6541.
--

> slingstart-maven-plugin: Make enriching the Maven classpath optional
> 
>
> Key: SLING-6541
> URL: https://issues.apache.org/jira/browse/SLING-6541
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.7.2
>
> Attachments: SLING-6541-v02.patch
>
>
> Currently the {{o.a.s.maven.slingstart.DependencyLifecycleParticipant}} takes 
> care of enriching the Maven classpath for all projects referencing this Maven 
> plugin. Although in most of the cases this may be desired, this is not 
> necessarily the case.
> E.g. when I have a bundle module which contains some ITs leveraging 
> sling-mocks and others leveraging e.g. a teleporter test, the merged 
> classpath often conflicts with sling-mocks. When using a model leveraging a 
> slingstart project like the sling launchpad the merged classpath is huge and 
> may negatively affect also other ITs (which are not executed remotely).
> I therefore propose to make the extension of the classpath optional.
> Initially this was only done for {{slingstart}} and {{slingfeature}} but 
> changed to all projects referencing this plugin in SLING-6068.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6544) slingstart-maven-plugin: keepLaunchpadRunning should be replaced by an option which can be used with start and/or stop

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6544.
--

> slingstart-maven-plugin: keepLaunchpadRunning should be replaced by an option 
> which can be used with start and/or stop
> --
>
> Key: SLING-6544
> URL: https://issues.apache.org/jira/browse/SLING-6544
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.7.2
>
>
> Right now the parameter {{keepLaunchpadRunning}} blocks the start mojo until 
> one of the servers is terminated. It is not that easy to explicitly terminate 
> the server though because Maven does not propagate the {{Ctrl+C}} to the 
> server. 
> Usually it is much more useful to instead block stopping of the server (i.e. 
> the stop mojo).
> I would propose to deprecate {{keepLaunchpadRunning}} and instead introduce 
> the following parameter (which may be used together with start and/or stop):
> {{blockUntilKeyIsPressed}} which should leverage the {{Prompter}} component 
> (http://stackoverflow.com/a/21977269/5155923) which forces the Mojo to wait 
> until the user entered some value.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6556) slingstart-maven-plugin: Allow to reference the artifact which is being built by the same project as main artifact

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6556.
--

> slingstart-maven-plugin: Allow to reference the artifact which is being built 
> by the same project as main artifact
> --
>
> Key: SLING-6556
> URL: https://issues.apache.org/jira/browse/SLING-6556
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.7.2
>
>
> Currently the slingstart-maven-plugin does not allow to reference the 
> artifact within the model definition which is built by the current module. 
> This restriction should be lifted to allow to consume those artifacts in case 
> they have been built already (i.e. if goal `prepare-package` is bound to a 
> phase after `package`). This is useful for having ITs in the same Maven 
> module as the the actual bundle which should be tested.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6540) Support m2e in slingstart-maven-plugin

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6540.
--

> Support m2e in slingstart-maven-plugin
> --
>
> Key: SLING-6540
> URL: https://issues.apache.org/jira/browse/SLING-6540
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Slingstart Maven Plugin 1.7.2
>
>
> Currently all goals of the {{slingstart-maven-plugin}} do not support m2e 
> (https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html).
>  All goals should be ignored in the incremental build for now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6545) slingstart-maven-plugin: By default do not redirect stderr and stdout of the sling server process to the one from the parent Maven process

[Konrad Windszus (JIRA)]

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

Konrad Windszus closed SLING-6545.
--

> slingstart-maven-plugin: By default do not redirect stderr and stdout of the 
> sling server process to the one from the parent Maven process
> --
>
> Key: SLING-6545
> URL: https://issues.apache.org/jira/browse/SLING-6545
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.7.2
>
>
> Currently the stdout and stderr from the Maven process is also used for the 
> Sling Server Process. That is a problem because even after one Mojo is done, 
> the server is still running and may still emit messages. Those overlap with 
> the messages of the following Maven mojos. Therefore the stdout and stderr of 
> the Sling server should be redirected to a special file.
> The only drawback is, that in case of a central CI server, those additional 
> files are not that easy to evaluate (need to be downloaded separately). Still 
> this is much better than having overlapping log files of two independent 
> processes (Maven and Sling Server).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[RESULT] [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2

[Konrad Windszus]

Hi,

The vote has passed with the following result :

+1 (binding):  Stefan Egli, Stefan Seifert, Daniel Klco, Karl Pauls and myself.

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

Thanks for voting,
Konrad
> On 27 Feb 2017, at 14:25, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> 
> On Mon, Feb 27, 2017 at 2:15 PM, Daniel Klco  wrote:
>> +1 - Checked signatures & build
>> 
>> On Fri, Feb 24, 2017 at 3:40 AM, Konrad Windszus  wrote:
>> 
>>> Hi,
>>> We solved 5 issues in this release:
>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12338702
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachesling-1644/
>>> 
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>> 
>>> Usage:
>>> sh check_staged_release.sh 1644 /tmp/sling-staging
>>> 
>>> Please vote to approve this release:
>>> [ ] +1 Approve the release
>>> [ ] 0 Don't care
>>> [ ] -1 Don't release, because ...
>>> This majority vote is open for at least 72 hours.
>>> 
>>> Thanks,
>>> Konrad
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Oliver Lietz]

On Monday 27 February 2017 11:45:16 Konrad Windszus wrote:
> > On 27 Feb 2017, at 11:28, Oliver Lietz  wrote:
> > 
> > On Monday 27 February 2017 11:00:54 Konrad Windszus wrote:
> >>> On 27 Feb 2017, at 10:54, Oliver Lietz  wrote:
> >>> 
> >>> On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
> > On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
> > 
> > On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
> >> Hey, I don't really think the change for that in
> >> https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validati
> >> on
> >> /a
> >> pi
> >> /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailu
> >> re
> >> .j
> >> ava ?r1=1734530=1784472=1784472 was good. The
> >> resourceBundle
> >> parameter is marked as @Nonnull. If you give a null here the return
> >> value is useless (because the key cannot be resolved against the
> >> MessageBundle). Your change makes it harder to detect such
> >> programming
> >> errors during development, because you no longer throw a (noisy)
> >> exception, but rather fall back to a IMHO useless default (empty
> >> string)
> >> which is rather unexpected.
> >> 
> >> What is the reason for that change?
> > 
> > Hi Konrad,
> > 
> > checking for null allows validation even if resource bundle is
> > missing.
> > I don't think validation should stop working just because human
> > readable
> > message is missing.
>  
>  Yes I agree, but then your code should not call that specific method.
> >>> 
> >>> Do you mean validation should stop working when messages are not
> >>> present?
> >>> 
>  Where exactly in your code is it called with ResourceBundle = null?
> >>> 
> >>> It's in ValidationPostResponseCreator.
> >> 
> >> This is test code only. If this cannot rely on a real ResourceBundle
> >> (which
> >> previous to your move to PaxExam was the case), then we should rather
> >> modify the ValidationPostResponseCreator to deal with that. But I would
> >> really like to validate in the IT that the right english translations are
> >> provided (therefore PaxExam should provide the slingi18n bundle and
> >> therefore also the right resource bundle).
> > 
> > The faster Pax Exam-based test discloses a situation which can also happen
> > in production and Validation should handle it gracefully. We can log a
> > message (warn) in case resource bundle is missing of course.
> > The tests itself are not modified at all and still check the validation
> > message.
> 
> The ValidationPostResponseCreator is test code only and does not properly
> protect against null values in the resource bundle (although it would be
> its obligation). That is the bug which needs to be fixed. For every other
> client using the ValidationFailure.getMessage(null) should also lead to an
> exception, because that is definitely an invalid (i.e. not-supported) use
> case. In the ValidationPostResponseCreator we should just throw an
> exception if the resource bundle can not be retrieved.
> 
> If the tests now always succeed this means that the resource bundle is
> actually never null, because in case it would be null, the validation
> failure messages would not be as expected.

As I said before, a resource bundle could be null in production also and we 
should handle it gracefully. Similar situation happens when just a message is 
missing (the message key is returned – which I don't like because it discloses 
internal information): we do not throw an exception and validation still 
works.

* a validation failure can be useful even without human readable message
* no programming errors are hidden by this change
* if validation result is valid, resource bundle is not used at all

There is no reason to break validation on missing resource bundle.

O.

> Do you want me to put the
> correct null handling in place for the ValidationPostResponseCreator or do
> you take care of that? Thanks,
> Konrad
> 
> > O.
> > 
> > [...]

[jira] [Resolved] (SLING-6572) Generate SCR metadata required for mock-based unit tests

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6572.
---
Resolution: Fixed

Completed: At revision: 1784602  


> Generate SCR metadata required for mock-based unit tests
> 
>
> Key: SLING-6572
> URL: https://issues.apache.org/jira/browse/SLING-6572
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 29
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Parent 30
>
>
> when unit tests are based on osgi-mock the SCR metadata generated for the 
> OSGi components of the project itself needs to be present in the generated 
> classpath before the unit test run.
> the following {{maven-bundle-plugin}} configuration is required for this:
> {code:xml}
> 
> 
> 
> true
> 
> 
> 
> 
> scr-metadata
> 
> manifest
> 
> 
> true
> 
> 
> 
> {code}
> we should add it by default to the global parent pom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6572) Generate SCR metadata required for mock-based unit tests

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6572:
-

 Summary: Generate SCR metadata required for mock-based unit tests
 Key: SLING-6572
 URL: https://issues.apache.org/jira/browse/SLING-6572
 Project: Sling
  Issue Type: Improvement
  Components: General
Affects Versions: Parent 29
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Parent 30


when unit tests are based on osgi-mock the SCR metadata generated for the OSGi 
components of the project itself needs to be present in the generated classpath 
before the unit test run.

the following {{maven-bundle-plugin}} configuration is required for this:
{code:xml}



true




scr-metadata

manifest


true



{code}

we should add it by default to the global parent pom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Radu Cotescu]

Then let's fix this in trunk, given the fact that we've released several
versions of the engine (1.0.0 - 1.0.18) until now with antlr embedded.

Thanks,
Radu

On Mon, 27 Feb 2017 at 17:05 Karl Pauls  wrote:

> That said, if you fix it in trunk and get the majority of the votes I
> suppose it isn't the end of the world as there are already releases of
> the binary with this issue.
>

[RESULT] [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.12

[Konrad Windszus]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Egli, Stefan Seifert, Daniel Klco, Karl Pauls and myself.


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

Thanks to all for voting,
Konrad

> On 27 Feb 2017, at 15:27, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> 
> On Mon, Feb 27, 2017 at 2:32 PM, Daniel Klco  wrote:
>> +1
>> 
>> On Mon, Feb 27, 2017 at 7:10 AM, Stefan Seifert 
>> wrote:
>> 
>>> +1
>>> 
>>> 
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

[jira] [Comment Edited] (SLING-3543) Provide a Felix Web Console Tab exposing the available Scripting Variables

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-3543 at 2/27/17 4:12 PM:
-

Attached is a patch mostly based on the work from 
[~mikolaj.man...@cognifide.com]. It adds a new web console tab as shown in 
!Scripting_Variables_Web_Console.png! It exposes all scripting variables by 
sending a request towards a given resource (via Ajax). We cannot really prevent 
that additional request, because the scripting variables depend heavily on the 
context (i.e. which resource it is).
[~bdelacretaz] Can you have a look?


was (Author: kwin):
Attached is a patch mostly based on the work from 
[~mikolaj.man...@cognifide.com]. It adds a new web console tab as shown in 
!Scripting_Variables_Web_Console! It exposes all scripting variables by sending 
a request towards a given resource (via Ajax). We cannot really prevent that 
additional request, because the scripting variables depend heavily on the 
context (i.e. which resource it is).
[~bdelacretaz] Can you have a look?

> Provide a Felix Web Console Tab exposing the available Scripting Variables
> --
>
> Key: SLING-3543
> URL: https://issues.apache.org/jira/browse/SLING-3543
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.26
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: Scripting_Variables_Web_Console.png, SLING-3543-v01.patch
>
>
> Currently you can very dynamically define the scripting variables 
> (https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables).
>  Therefore it would be very good to expose which variables are exposed within 
> each script provider in a dedicated web console tab.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-3543) Provide a Felix Web Console Tab exposing the available Scripting Variables

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-3543 at 2/27/17 4:12 PM:
-

Attached is a patch mostly based on the work from 
[~mikolaj.man...@cognifide.com]. It adds a new web console tab as shown in 
!Scripting_Variables_Web_Console.png! It exposes all scripting variables by 
sending a request towards a given resource (via Ajax). We cannot really prevent 
that additional request, because the scripting variables depend heavily on the 
context (i.e. which resource it is).
[~bdelacretaz] Can you have a look?


was (Author: kwin):
Attached is a patch mostly based on the work from 
[~mikolaj.man...@cognifide.com]. It adds a new web console tab as shown in 
!Scripting_Variables_Web_Console.png! It exposes all scripting variables by 
sending a request towards a given resource (via Ajax). We cannot really prevent 
that additional request, because the scripting variables depend heavily on the 
context (i.e. which resource it is).
[~bdelacretaz] Can you have a look?

> Provide a Felix Web Console Tab exposing the available Scripting Variables
> --
>
> Key: SLING-3543
> URL: https://issues.apache.org/jira/browse/SLING-3543
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.26
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: Scripting_Variables_Web_Console.png, SLING-3543-v01.patch
>
>
> Currently you can very dynamically define the scripting variables 
> (https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables).
>  Therefore it would be very good to expose which variables are exposed within 
> each script provider in a dedicated web console tab.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-3543) Provide a Felix Web Console Tab exposing the available Scripting Variables

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-3543:
---
Attachment: Scripting_Variables_Web_Console.png
SLING-3543-v01.patch

Attached is a patch mostly based on the work from 
[~mikolaj.man...@cognifide.com]. It adds a new web console tab as shown in 
!Scripting_Variables_Web_Console! It exposes all scripting variables by sending 
a request towards a given resource (via Ajax). We cannot really prevent that 
additional request, because the scripting variables depend heavily on the 
context (i.e. which resource it is).
[~bdelacretaz] Can you have a look?

> Provide a Felix Web Console Tab exposing the available Scripting Variables
> --
>
> Key: SLING-3543
> URL: https://issues.apache.org/jira/browse/SLING-3543
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.26
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: Scripting_Variables_Web_Console.png, SLING-3543-v01.patch
>
>
> Currently you can very dynamically define the scripting variables 
> (https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables).
>  Therefore it would be very good to expose which variables are exposed within 
> each script provider in a dedicated web console tab.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Karl Pauls]

Well, I personally think you'd be better of recutting the release.
After all, release votes are pretty much for the purpose of making
sure there are no legal issues with the release and not having the
proper licenses in place isn't good.

That said, if you fix it in trunk and get the majority of the votes I
suppose it isn't the end of the world as there are already releases of
the binary with this issue.

In other words, up to you (and maybe on how much work is involved in
recutting the release) but I would just declare this vote to continue
for the Engine only (so you don't have to recut that one) and start a
new one for the compiler.

regards,

Karl

On Mon, Feb 27, 2017 at 4:19 PM, Radu Cotescu  wrote:
> Hi Karl,
>
> I guess we should. Do you consider this a release blocker or can I just add
> them into a separate commit?
>
> Cheers,
> Radu
>
> On Mon, 27 Feb 2017 at 15:52 Karl Pauls  wrote:
>
>> [...]
>> Shouldn't they be added to the LICENSE file?
>>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [eclipse] Including automated error reporting in the Eclipse tooling

[Robert Munteanu]

On Mon, 2017-02-27 at 16:47 +0100, Stefan Egli wrote:
> Hi Robert,
> 
> Sounds very useful indeed.
> 
> What comes to mind first is legal. And who would have access to the
> error
> reports at Ctrlflow/Codetrails?

Right, I'm not sure what legal involvement would be here. That's why
I'm posting.

As for access to the error reports, my understanding is that only
accounts explicitly allowed to access the error reports would get that
data.

Robert

> 
> Cheers,
> Stefan
> 
> On 27/02/17 15:59, "Robert Munteanu"  wrote:
> 
> > Hi,
> > 
> > 
> > The automated error reporting project used by the Eclipse
> > Foundation (
> > see [1] for some background ) has now been opened up for all third
> > party Eclipse plug-ins [2] , allowing them to gather error reports
> > and
> > store them on a central instance, hosted by Ctrlflow/Codetrails.
> > 
> > This would be very useful in allowing us to quickly understand what
> > problems occur when the plug-ins are used and getting to reach
> > users
> > faster.
> > 
> > Before setting up an account and configuring the plug-in I would
> > like
> > to see what others think about this.
> > 
> > Briefly, as an Eclipse user:
> > 
> > - I am asked if I want to enable error reporting for my instance
> > and
> > the specific 'provider' - such as the Eclipse Foundation or Apache
> > Sling
> > - whenever an error occurs, I am notified via a popup and can
> > choose to
> > either ignore the issue, or send it alongside with optional
> > comments
> > - I am always able to inspect the details of the report before
> > submitting
> > 
> > The full details of the agreement are at [3], which is what I would
> > agree to when setting up an account.
> > 
> > Thoughts?
> > 
> > Robert
> > 
> > [1]: https://blog.ctrlflow.com/byo-aeri-in-eclipse-neon/
> > [2]: https://blog.ctrlflow.com/free-error-reporting-service-for-ecl
> > ipse
> > /
> > [3]: https://www.ctrlflow.com/assets/media/pdfs/automated-error-rep
> > orti
> > ng/ctrlflow-automated-error-reporting-terms.pdf
> 
> 

Re: [eclipse] Including automated error reporting in the Eclipse tooling

[Stefan Egli]

Hi Robert,

Sounds very useful indeed.

What comes to mind first is legal. And who would have access to the error
reports at Ctrlflow/Codetrails?

Cheers,
Stefan

On 27/02/17 15:59, "Robert Munteanu"  wrote:

>Hi,
>
>
>The automated error reporting project used by the Eclipse Foundation (
>see [1] for some background ) has now been opened up for all third
>party Eclipse plug-ins [2] , allowing them to gather error reports and
>store them on a central instance, hosted by Ctrlflow/Codetrails.
>
>This would be very useful in allowing us to quickly understand what
>problems occur when the plug-ins are used and getting to reach users
>faster.
>
>Before setting up an account and configuring the plug-in I would like
>to see what others think about this.
>
>Briefly, as an Eclipse user:
>
>- I am asked if I want to enable error reporting for my instance and
>the specific 'provider' - such as the Eclipse Foundation or Apache
>Sling
>- whenever an error occurs, I am notified via a popup and can choose to
>either ignore the issue, or send it alongside with optional comments
>- I am always able to inspect the details of the report before
>submitting
>
>The full details of the agreement are at [3], which is what I would
>agree to when setting up an account.
>
>Thoughts?
>
>Robert
>
>[1]: https://blog.ctrlflow.com/byo-aeri-in-eclipse-neon/
>[2]: https://blog.ctrlflow.com/free-error-reporting-service-for-eclipse
>/
>[3]: https://www.ctrlflow.com/assets/media/pdfs/automated-error-reporti
>ng/ctrlflow-automated-error-reporting-terms.pdf

[jira] [Resolved] (SLING-6567) BasicObservationReporter ignores resource changes for resource providers mounted at specific paths

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6567.
---
Resolution: Fixed

should be solved with the fix mentioned above.

> BasicObservationReporter ignores resource changes for resource providers 
> mounted at specific paths
> --
>
> Key: SLING-6567
> URL: https://issues.apache.org/jira/browse/SLING-6567
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.14
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Resource Resolver 1.5.16
>
> Attachments: SLING-6567.patch
>
>
> with the new resource provider SPI an intelligent ResourceListener mechanism 
> was introduced which allows to generate and route resource change events only 
> when a listener is actual interested in this change. this works well when the 
> resource provider is a root provider mounted at {{/}}.
> however this currently fails when an additional resource provider is mounted 
> at a specific path - e.g. at {{/apps/app1}}. in this case listeners mounted 
> to specific glob patterns like {{glob:/apps/**/*.html}} get the changes 
> reported by the resource provider, but listeners registered to {{/}} do not.
> this is a severe problem as some listeners like the script resolution cache 
> are registered to {{/}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6567) BasicObservationReporter ignores resource changes for resource providers mounted at specific paths

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6567:
--
Priority: Critical  (was: Major)

raising priority because it think this is a severe problem for all resource 
providers not mounted at {{/}}.

> BasicObservationReporter ignores resource changes for resource providers 
> mounted at specific paths
> --
>
> Key: SLING-6567
> URL: https://issues.apache.org/jira/browse/SLING-6567
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.14
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Resource Resolver 1.5.16
>
> Attachments: SLING-6567.patch
>
>
> with the new resource provider SPI an intelligent ResourceListener mechanism 
> was introduced which allows to generate and route resource change events only 
> when a listener is actual interested in this change. this works well when the 
> resource provider is a root provider mounted at {{/}}.
> however this currently fails when an additional resource provider is mounted 
> at a specific path - e.g. at {{/apps/app1}}. in this case listeners mounted 
> to specific glob patterns like {{glob:/apps/**/*.html}} get the changes 
> reported by the resource provider, but listeners registered to {{/}} do not.
> this is a severe problem as some listeners like the script resolution cache 
> are registered to {{/}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6567) BasicObservationReporter ignores resource changes for resource providers mounted at specific paths

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6567:
---

Completed: At revision: 1784586  

i've applied the patch with the change you proposed - it's more conservative. i 
think the reason the problem did not exist without this fix for observation 
listeners with patterns because of the special logic in the 
{{o.a.s.api.resource.pathPath.matches}} method which - in case of not matching 
- tries again with partial paths of the pattern until it matches. perhaps this 
was the wrong position for this logic and it should have been better handled 
here.

> BasicObservationReporter ignores resource changes for resource providers 
> mounted at specific paths
> --
>
> Key: SLING-6567
> URL: https://issues.apache.org/jira/browse/SLING-6567
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.5.14
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Resource Resolver 1.5.16
>
> Attachments: SLING-6567.patch
>
>
> with the new resource provider SPI an intelligent ResourceListener mechanism 
> was introduced which allows to generate and route resource change events only 
> when a listener is actual interested in this change. this works well when the 
> resource provider is a root provider mounted at {{/}}.
> however this currently fails when an additional resource provider is mounted 
> at a specific path - e.g. at {{/apps/app1}}. in this case listeners mounted 
> to specific glob patterns like {{glob:/apps/**/*.html}} get the changes 
> reported by the resource provider, but listeners registered to {{/}} do not.
> this is a severe problem as some listeners like the script resolution cache 
> are registered to {{/}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Radu Cotescu]

Hi Karl,

I guess we should. Do you consider this a release blocker or can I just add
them into a separate commit?

Cheers,
Radu

On Mon, 27 Feb 2017 at 15:52 Karl Pauls  wrote:

> [...]
> Shouldn't they be added to the LICENSE file?
>

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Daniel Klco]

+1 -- checked signature and build

On Mon, Feb 27, 2017 at 8:27 AM, Robert Munteanu  wrote:

> On Mon, 2017-02-27 at 11:17 +, Radu Cotescu wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

[eclipse] Including automated error reporting in the Eclipse tooling

[Robert Munteanu]

Hi,


The automated error reporting project used by the Eclipse Foundation (
see [1] for some background ) has now been opened up for all third
party Eclipse plug-ins [2] , allowing them to gather error reports and
store them on a central instance, hosted by Ctrlflow/Codetrails.

This would be very useful in allowing us to quickly understand what
problems occur when the plug-ins are used and getting to reach users
faster.

Before setting up an account and configuring the plug-in I would like
to see what others think about this.

Briefly, as an Eclipse user:

- I am asked if I want to enable error reporting for my instance and
the specific 'provider' - such as the Eclipse Foundation or Apache
Sling
- whenever an error occurs, I am notified via a popup and can choose to
either ignore the issue, or send it alongside with optional comments
- I am always able to inspect the details of the report before
submitting

The full details of the agreement are at [3], which is what I would
agree to when setting up an account.

Thoughts?

Robert

[1]: https://blog.ctrlflow.com/byo-aeri-in-eclipse-neon/
[2]: https://blog.ctrlflow.com/free-error-reporting-service-for-eclipse
/
[3]: https://www.ctrlflow.com/assets/media/pdfs/automated-error-reporti
ng/ctrlflow-automated-error-reporting-terms.pdf

[jira] [Created] (SLING-6571) Include automatic error reporting

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6571:
--

 Summary: Include automatic error reporting
 Key: SLING-6571
 URL: https://issues.apache.org/jira/browse/SLING-6571
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Reporter: Robert Munteanu
 Fix For: Sling Eclipse IDE 1.2.0


The automated error reporting project used by the Eclipse Foundation ( see 
https://blog.ctrlflow.com/byo-aeri-in-eclipse-neon/ for some backgroud ) has 
now been opened up for all third party developers, allowing them to gather 
error reports and store them on a central instance.

This would be very useful in allowing us to quickly understand what problems 
occur when the plug-ins are used and getting to reach users faster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Karl Pauls]

The HTL Compiler binary embeds antlr4-runtime-4.1.jar and
org.abego.treelayout.core-1.0.1.jar.

Both are under BSD license. While they are mentioned in the
DEPENDENCIES I couldn't find the actual licenses in the LICENSE file.

Shouldn't they be added to the LICENSE file?

regards,

Karl

On Mon, Feb 27, 2017 at 12:17 PM, Radu Cotescu  wrote:
> Hi,
>
> We solved 2 issues in these releases:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339164
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339176
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1646/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1646 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Cheers,
> Radu



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.12

[Karl Pauls]

+1

regards,

Karl

On Mon, Feb 27, 2017 at 2:32 PM, Daniel Klco  wrote:
> +1
>
> On Mon, Feb 27, 2017 at 7:10 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.12

[Daniel Klco]

+1

On Mon, Feb 27, 2017 at 7:10 AM, Stefan Seifert 
wrote:

> +1
>
>

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Robert Munteanu]

On Mon, 2017-02-27 at 11:17 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

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

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2

[Karl Pauls]

+1

regards,

Karl

On Mon, Feb 27, 2017 at 2:15 PM, Daniel Klco  wrote:
> +1 - Checked signatures & build
>
> On Fri, Feb 24, 2017 at 3:40 AM, Konrad Windszus  wrote:
>
>> Hi,
>> We solved 5 issues in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12338702
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1644/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1644 /tmp/sling-staging
>>
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] 0 Don't care
>> [ ] -1 Don't release, because ...
>> This majority vote is open for at least 72 hours.
>>
>> Thanks,
>> Konrad



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Resolved] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6392.
---
Resolution: Fixed

I added a debug log message in r1784561. 

I think this should work now - hence, I'm resolving this issue. Please close if 
it works for you.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Karl Pauls
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-after-transform.patch, 
> SLING-6392-Fragment.patch, SLING-6392-Fragment-v02.patch, 
> SLING-6392-test-v01.patch, SLING-6392-test-v02.patch, SLING-6392-v01.patch, 
> SLING-6392-v02.patch
>
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

RE: Remove usage of commons legacy releases

[Daniel Klco]

+1

On Feb 27, 2017 7:14 AM, "Stefan Seifert"  wrote:

> +1
>
> >-Original Message-
> >From: Carsten Ziegeler [mailto:cziege...@apache.org]
> >Sent: Monday, February 27, 2017 11:25 AM
> >To: Sling Developers
> >Subject: Remove usage of commons legacy releases
> >
> >While in general we should use the lowest version possible of a
> >dependency (in order to make updating installations easier), I think
> >it's time now to get rid of using commons legacy releases.
> >Especially as for most of them we have dependencies to the legacy and
> >the latest version, which means we have to include to copies of that
> >library.
> >
> >In particular I'm speaking about commons lang, commons collections,
> >commons math and the httpclient. For all of them, except math, we
> >currently have to include two versions in launchpad:
> >commons-collections/commons-collections/3.2.2
> >org.apache.commons/commons-collections4/4.1
> >
> >commons-lang/commons-lang/2.6
> >org.apache.commons/commons-lang3/3.4
> >
> >org.apache.geronimo.bundles/commons-httpclient/3.1_1
> >org.apache.httpcomponents/httpcore-osgi/4.4.1
> >org.apache.httpcomponents/httpclient-osgi/4.4.1
> >
> >For commons math, we are using
> >org.apache.commons/commons-math/2.2
> >and probably should replace this with a 3.x version.
> >
> >WDYT
> >
> >Regards
> >Carsten
> >--
> >Carsten Ziegeler
> >Adobe Research Switzerland
> >cziege...@apache.org
>
>

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2

[Daniel Klco]

+1 - Checked signatures & build

On Fri, Feb 24, 2017 at 3:40 AM, Konrad Windszus  wrote:

> Hi,
> We solved 5 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338702
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1644/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1644 /tmp/sling-staging
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
> This majority vote is open for at least 72 hours.
>
> Thanks,
> Konrad

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Radu Cotescu]

Typo. Yes, we fixed 3 issues. Sorry for that.

On Mon, 27 Feb 2017 at 13:13 Stefan Seifert  wrote:

> +1
>
> stefan
>
> p.s. i count 3 issues, not 2.
>
>
> >-Original Message-
> >From: Radu Cotescu [mailto:r...@apache.org]
> >Sent: Monday, February 27, 2017 12:18 PM
> >To: Sling Dev
> >Subject: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache
> >Sling Scripting HTL Engine 1.0.32
> >
> >Hi,
> >
> >We solved 2 issues in these releases:
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12339164
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12339176
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1646/
> >
> >You can use this UNIX script to download the release and verify the
> >signatures:
> >http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> >Usage:
> >sh check_staged_release.sh 1646 /tmp/sling-staging
> >
> >Please vote to approve this release:
> >
> >  [ ] +1 Approve the release
> >  [ ]  0 Don't care
> >  [ ] -1 Don't release, because ...
> >
> >This majority vote is open for at least 72 hours.
> >
> >Cheers,
> >Radu
>

[jira] [Commented] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-6053:
--

[~kwin] I did double check and it really looks like {{findApplicableHolders}} 
returns a sorted Collection ordered by length.
This should avoid completely the problem you describe. Unless I am missing 
something... Thanks so far!

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

RE: Remove usage of commons legacy releases

[Stefan Seifert]

+1

>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Monday, February 27, 2017 11:25 AM
>To: Sling Developers
>Subject: Remove usage of commons legacy releases
>
>While in general we should use the lowest version possible of a
>dependency (in order to make updating installations easier), I think
>it's time now to get rid of using commons legacy releases.
>Especially as for most of them we have dependencies to the legacy and
>the latest version, which means we have to include to copies of that
>library.
>
>In particular I'm speaking about commons lang, commons collections,
>commons math and the httpclient. For all of them, except math, we
>currently have to include two versions in launchpad:
>commons-collections/commons-collections/3.2.2
>org.apache.commons/commons-collections4/4.1
>
>commons-lang/commons-lang/2.6
>org.apache.commons/commons-lang3/3.4
>
>org.apache.geronimo.bundles/commons-httpclient/3.1_1
>org.apache.httpcomponents/httpcore-osgi/4.4.1
>org.apache.httpcomponents/httpclient-osgi/4.4.1
>
>For commons math, we are using
>org.apache.commons/commons-math/2.2
>and probably should replace this with a 3.x version.
>
>WDYT
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org

RE: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Stefan Seifert]

+1

stefan

p.s. i count 3 issues, not 2.


>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Monday, February 27, 2017 12:18 PM
>To: Sling Dev
>Subject: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache
>Sling Scripting HTL Engine 1.0.32
>
>Hi,
>
>We solved 2 issues in these releases:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12339164
>https://issues.apache.org/jira/browse/SLING/fixforversion/12339176
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1646/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1646 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Radu

RE: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.12

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2

[Stefan Seifert]

+1

[jira] [Commented] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-6053:
--

[~kwin] I need to check but I think that {{findApplicableHolders}} returns a 
sorted {{Collection}} ordered by length.
Hence the problem you mentioned should not occur right?
Thanks about the wrong import . I will remove it..

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[VOTE] Release Apache Sling Scripting HTL Compiler 1.0.8, Apache Sling Scripting HTL Engine 1.0.32

[Radu Cotescu]

Hi,

We solved 2 issues in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12339164
https://issues.apache.org/jira/browse/SLING/fixforversion/12339176

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1646/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1646 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Cheers,
Radu

[jira] [Comment Edited] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6053 at 2/27/17 11:12 AM:
--

[~asanso] The patch is only a heuristic and does not work for all cases. Just 
imagine the following use case
{{resource1}} requires authentication
{{resource1.test2}} does not require authentication
In that case the latter would also be covered by your logic in 
{{isNodeRequiresAuthHandler}} which returns {{true}} but in fact it should not.

I am not sure, whether that behavior is better or worse than before. (Better 
because it will for most of the cases work as expected, worse, because it is 
even harder to document the behavior for resource names containing "." itself).

The problem is that with just having the request URL String you cannot tell, 
what is a selector and what belongs to the resource's name.

Also the import to {{import javax.crypto.spec.OAEPParameterSpec}} seems wrong 
in the patch.


was (Author: kwin):
[~asanso] The patch is only a heuristic and does not work for all cases. Just 
imagine the following use case
{{resource1}} requires authentication
{{resource1.test2}} does not require authentication
In that case the latter would also be covered by your logic in 
{{isNodeRequiresAuthHandler}} which returns {{true}} but in fact it should not.

I am not sure, whether that behavior is better or worse than before. (Better 
because it will for most of the cases work as expected, worse, because it is 
even harder to document the behavior for resource names containing "." itself).

The problem is that with just having the request URL String you cannot tell, 
what is a selector and what belongs to the resource's name.

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6053 at 2/27/17 11:09 AM:
--

[~asanso] The patch is only a heuristic and does not work for all cases. Just 
imagine the following use case
{{resource1}} requires authentication
{{resource1.test2}} does not require authentication
In that case the latter would also be covered by your logic in 
{{isNodeRequiresAuthHandler}} which returns {{true}} but in fact it should not.

I am not sure, whether that behavior is better or worse than before. (Better 
because it will for most of the cases work as expected, worse, because it is 
even harder to document the behavior for resource names containing "." itself).

The problem is that with just having the request URL String you cannot tell, 
what is a selector and what belongs to the resource's name.


was (Author: kwin):
[~asanso] The patch is only a heuristic and does not work for all cases. Just 
imagine the following use case
{{resource1}} requires authentication
{{resource1.test2}} does not require authentication
In that case the latter would also be covered by your logic in 
{{isNodeRequiresAuthHandler}} but in fact it should not.
I am not sure, whether that behavior is better or worse then before. (Better 
because it will for most of the cases work as expected, worse, because it is 
even harder to document the behaviour for resource names containing "." itself).

The problem is that with just having the request URL String you cannot tell, 
what is a selector and what belongs to the resource's name.

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6053:


[~asanso] The patch is only a heuristic and does not work for all cases. Just 
imagine the following use case
{{resource1}} requires authentication
{{resource1.test2}} does not require authentication
In that case the latter would also be covered by your logic in 
{{isNodeRequiresAuthHandler}} but in fact it should not.
I am not sure, whether that behavior is better or worse then before. (Better 
because it will for most of the cases work as expected, worse, because it is 
even harder to document the behaviour for resource names containing "." itself).

The problem is that with just having the request URL String you cannot tell, 
what is a selector and what belongs to the resource's name.

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-6053:
-
Attachment: SLING-6053-patch.txt

Attaching proposing patch. [~kwin] WDYT? 

> SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
> 
>
> Key: SLING-6053
> URL: https://issues.apache.org/jira/browse/SLING-6053
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.18
>Reporter: Miklos Csere
>Assignee: Antonio Sanso
>Priority: Blocker
> Attachments: SLING-6053-patch.txt
>
>
> Issue can be reproduced with the following steps:
> Create node "/page" 
> Create sibling node "/page1"
> Define a protection handler for node: "/page"
> Expected: 
> "/page" has AuthenticationInfo
>  "/page1" does not have AuthenticationInfo (has anonymous)
>   
> Actual:  "/page" & "page1" are both having AuthenticationInfo
>  
> Reason: SlingAuthenticator.java line 726:  if (path.startsWith(holder.path)) 
> Warning: The same check is used in 4 more places in code with similar 
> behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Konrad Windszus]

> On 27 Feb 2017, at 11:28, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 11:00:54 Konrad Windszus wrote:
>>> On 27 Feb 2017, at 10:54, Oliver Lietz  wrote:
>>> 
>>> On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
> On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
>> Hey, I don't really think the change for that in
>> https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation
>> /a
>> pi
>> /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure
>> .j
>> ava ?r1=1734530=1784472=1784472 was good. The resourceBundle
>> parameter is marked as @Nonnull. If you give a null here the return
>> value is useless (because the key cannot be resolved against the
>> MessageBundle). Your change makes it harder to detect such programming
>> errors during development, because you no longer throw a (noisy)
>> exception, but rather fall back to a IMHO useless default (empty
>> string)
>> which is rather unexpected.
>> 
>> What is the reason for that change?
> 
> Hi Konrad,
> 
> checking for null allows validation even if resource bundle is missing.
> I don't think validation should stop working just because human readable
> message is missing.
 
 Yes I agree, but then your code should not call that specific method.
>>> 
>>> Do you mean validation should stop working when messages are not present?
>>> 
 Where exactly in your code is it called with ResourceBundle = null?
>>> 
>>> It's in ValidationPostResponseCreator.
>> 
>> This is test code only. If this cannot rely on a real ResourceBundle (which
>> previous to your move to PaxExam was the case), then we should rather
>> modify the ValidationPostResponseCreator to deal with that. But I would
>> really like to validate in the IT that the right english translations are
>> provided (therefore PaxExam should provide the slingi18n bundle and
>> therefore also the right resource bundle).
> 
> The faster Pax Exam-based test discloses a situation which can also happen in 
> production and Validation should handle it gracefully. We can log a message 
> (warn) in case resource bundle is missing of course.
> The tests itself are not modified at all and still check the validation 
> message.
The ValidationPostResponseCreator is test code only and does not properly 
protect against null values in the resource bundle (although it would be its 
obligation). That is the bug which needs to be fixed.
For every other client using the ValidationFailure.getMessage(null) should also 
lead to an exception, because that is definitely an invalid (i.e. 
not-supported) use case.
In the ValidationPostResponseCreator we should just throw an exception if the 
resource bundle can not be retrieved. 

If the tests now always succeed this means that the resource bundle is actually 
never null, because in case it would be null, the validation failure messages 
would not be as expected.
Do you want me to put the correct null handling in place for the 
ValidationPostResponseCreator or do you take care of that?
Thanks,
Konrad

> 
> O.
> 
> [...]
> 

[jira] [Resolved] (SLING-6570) HTL engine does not correctly generate Java classes for templates stored in different files

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6570.
-
Resolution: Fixed

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

> HTL engine does not correctly generate Java classes for templates stored in 
> different files
> ---
>
> Key: SLING-6570
> URL: https://issues.apache.org/jira/browse/SLING-6570
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.20
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Blocker
> Fix For: Scripting HTL Engine 1.0.32
>
>
> The HTL engine might not correctly generate the Java classes corresponding to 
> HTL templates which are stored in template files. This happens because the 
> {{RenderUnitProvider}} does not extract a script name for the unit it wants 
> to compile.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2

[Konrad Windszus]

+1

Anyone else?
Thanks,
Konrad

> On 24 Feb 2017, at 11:09, Stefan Egli  wrote:
> 
> +1
> 
> Cheers,
> Stefan
> 
> On 24/02/17 09:40, "Konrad Windszus"  wrote:
> 
>> Hi, 
>> We solved 5 issues in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12338702
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1644/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1644 /tmp/sling-staging
>> 
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] 0 Don't care 
>> [ ] -1 Don't release, because ...
>> This majority vote is open for at least 72 hours.
>> 
>> Thanks,
>> Konrad
> 
> 

Re: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.12

[Konrad Windszus]

+1

Anyone else?
Thanks,
Konrad

> On 24 Feb 2017, at 11:10, Stefan Egli  wrote:
> 
> +1
> 
> Cheers,
> Stefan
> 
> On 24/02/17 09:57, "Konrad Windszus"  wrote:
> 
>> Hi, 
>> We solved 4 issues in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12339660
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1645
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>> Usage:
>> sh check_staged_release.sh 1645 /tmp/sling-staging
>> 
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] 0 Don't care 
>> [ ] -1 Don't release, because ...
>> This majority vote is open for at least 72 hours.
>> 
>> Thanks,
>> Konrad
> 
> 

[jira] [Commented] (SLING-5423) embedded raft based discovery mechanism

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5423:
---

Apache is incubating at least two implentations of Raft or DS log that may be 
worth looking at

https://incubator.apache.org/projects/ratis.html
http://incubator.apache.org/projects/distributedlog.html

 

> embedded raft based discovery mechanism
> ---
>
> Key: SLING-5423
> URL: https://issues.apache.org/jira/browse/SLING-5423
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Discovery Standalone 1.0.2
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> The Raft consensus algorithm [0] is a good pick for implenting the discovery 
> API or more generally clustering solutions.
> Indeed, Raft algorithm design aims at being "easy" to understand and thus 
> "easy" to be implemented/debugged maybe by mere mortals.
> One of the major implementation of Raft is etcd [1] which Sling can already 
> leverage (SLING-4842).
> However, etcd requires an extra piece of infrastructure to be deployed (the 
> etcd servers) which can't be shipped as part of the Sling quickstart (Go vs 
> Java techs). 
> Using an embedded Raft based discovery and clustering mechanism would bring 
> an easy to deploy solution (OOTB) and based on proven algorithm.
> As Raft is designed to be easy to implement, many implementations already 
> exists [0].
> Ideally an existing implementation could be reused instead of reimplementing 
> it though. 
> An interesting one is Copycat [2] which is now released and Apache 2 licensed.
> [0] https://raft.github.io
> [1] https://github.com/coreos/etcd
> [2] https://github.com/atomix/copycat



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Oliver Lietz]

On Monday 27 February 2017 11:00:54 Konrad Windszus wrote:
> > On 27 Feb 2017, at 10:54, Oliver Lietz  wrote:
> > 
> > On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
> >>> On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
> >>> 
> >>> On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
>  Hey, I don't really think the change for that in
>  https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation
>  /a
>  pi
>  /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure
>  .j
>  ava ?r1=1734530=1784472=1784472 was good. The resourceBundle
>  parameter is marked as @Nonnull. If you give a null here the return
>  value is useless (because the key cannot be resolved against the
>  MessageBundle). Your change makes it harder to detect such programming
>  errors during development, because you no longer throw a (noisy)
>  exception, but rather fall back to a IMHO useless default (empty
>  string)
>  which is rather unexpected.
>  
>  What is the reason for that change?
> >>> 
> >>> Hi Konrad,
> >>> 
> >>> checking for null allows validation even if resource bundle is missing.
> >>> I don't think validation should stop working just because human readable
> >>> message is missing.
> >> 
> >> Yes I agree, but then your code should not call that specific method.
> > 
> > Do you mean validation should stop working when messages are not present?
> > 
> >> Where exactly in your code is it called with ResourceBundle = null?
> > 
> > It's in ValidationPostResponseCreator.
> 
> This is test code only. If this cannot rely on a real ResourceBundle (which
> previous to your move to PaxExam was the case), then we should rather
> modify the ValidationPostResponseCreator to deal with that. But I would
> really like to validate in the IT that the right english translations are
> provided (therefore PaxExam should provide the slingi18n bundle and
> therefore also the right resource bundle).

The faster Pax Exam-based test discloses a situation which can also happen in 
production and Validation should handle it gracefully. We can log a message 
(warn) in case resource bundle is missing of course.
The tests itself are not modified at all and still check the validation 
message.

O.

[...]

Remove usage of commons legacy releases

[Carsten Ziegeler]

While in general we should use the lowest version possible of a
dependency (in order to make updating installations easier), I think
it's time now to get rid of using commons legacy releases.
Especially as for most of them we have dependencies to the legacy and
the latest version, which means we have to include to copies of that
library.

In particular I'm speaking about commons lang, commons collections,
commons math and the httpclient. For all of them, except math, we
currently have to include two versions in launchpad:
commons-collections/commons-collections/3.2.2
org.apache.commons/commons-collections4/4.1

commons-lang/commons-lang/2.6
org.apache.commons/commons-lang3/3.4

org.apache.geronimo.bundles/commons-httpclient/3.1_1
org.apache.httpcomponents/httpcore-osgi/4.4.1
org.apache.httpcomponents/httpclient-osgi/4.4.1

For commons math, we are using
org.apache.commons/commons-math/2.2
and probably should replace this with a 3.x version.

WDYT

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

[jira] [Commented] (SLING-6392) OSGi Installer: Symbolic name changes on a resource keeping the same URL are not supported

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6392:


Sounds good. Thanks for all your efforts.

> OSGi Installer: Symbolic name changes on a resource keeping the same URL are 
> not supported
> --
>
> Key: SLING-6392
> URL: https://issues.apache.org/jira/browse/SLING-6392
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.8.0
>Reporter: Konrad Windszus
>Assignee: Karl Pauls
> Fix For: Installer Core 3.8.8
>
> Attachments: SLING-6392-after-transform.patch, 
> SLING-6392-Fragment.patch, SLING-6392-Fragment-v02.patch, 
> SLING-6392-test-v01.patch, SLING-6392-test-v02.patch, SLING-6392-v01.patch, 
> SLING-6392-v02.patch
>
>
> After deploying bundle with symbolic name {{A}} to JCR location 
> {{/apps/myapp/install/mybundle.jar}} or somewhere in the filesystem it is 
> correctly being picked up by the JcrInstaller or FileInstaller and deployed 
> in Apache Felix. Now the symbolic name has been changed to {{B}} and the 
> updated JAR has been deployed to the same location in the JCR  
> {{/apps/myapp/install/mybundle.jar}} or to the file system the updated bundle 
> is not correctly deployed.
> The OSGI installer console exposes that both bundles {{A}} and {{B}} are in 
> state {{Installed}} but the /system/console/bundle only shows bundle {{A}} 
> but not {{B}}.
> It would actually be expected that {{A}} is uninstalled, while {{B}} is 
> getting installed!
> Such a change can happen if you use the {{maven-bundle-plugin}} with a 
> default configuration and you just change the groupId of the underlying maven 
> project. That will not affect the finalName of the artifact (by default 
> artifactId) but the symbolic name of the bundle (see 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#default-behavior).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Konrad Windszus]

> On 27 Feb 2017, at 10:54, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
>>> On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
>>> 
>>> On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
 Hey, I don't really think the change for that in
 https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation/a
 pi
 /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure.j
 ava ?r1=1734530=1784472=1784472 was good. The resourceBundle
 parameter is marked as @Nonnull. If you give a null here the return
 value is useless (because the key cannot be resolved against the
 MessageBundle). Your change makes it harder to detect such programming
 errors during development, because you no longer throw a (noisy)
 exception, but rather fall back to a IMHO useless default (empty string)
 which is rather unexpected.
 
 What is the reason for that change?
>>> 
>>> Hi Konrad,
>>> 
>>> checking for null allows validation even if resource bundle is missing.
>>> I don't think validation should stop working just because human readable
>>> message is missing.
>> 
>> Yes I agree, but then your code should not call that specific method.
> 
> Do you mean validation should stop working when messages are not present?
> 
>> Where exactly in your code is it called with ResourceBundle = null?
> 
> It's in ValidationPostResponseCreator.
This is test code only. If this cannot rely on a real ResourceBundle (which 
previous to your move to PaxExam was the case), then we should rather modify 
the ValidationPostResponseCreator to deal with that. But I would really like to 
validate in the IT that the right english translations are provided (therefore 
PaxExam should provide the slingi18n bundle and therefore also the right 
resource bundle).

> 
> O.
> 
>>> Regards,
>>> O.
>>> 
 Thanks,
 Konrad
 
> On 26 Feb 2017, at 20:04, Oliver Lietz (JIRA)  wrote:
>   [
>   https://issues.apache.org/jira/browse/SLING-6569?page=com.atlassian.j
>   ira.plugin.system.issuetabpanels:all-tabpanel ]>
> 
> Oliver Lietz resolved SLING-6569.
> -
> 
>  Resolution: Fixed
> 
> [r1784472|https://svn.apache.org/r1784472]
> 
>> NPE in DefaultValidationFailure when resource bundle is null
>> 
>> 
>>  Key: SLING-6569
>>  URL: https://issues.apache.org/jira/browse/SLING-6569
>> 
>>  Project: Sling
>> 
>>   Issue Type: Bug
>>   Components: Extensions, Validation
>> 
>> Reporter: Oliver Lietz
>> Assignee: Oliver Lietz
>> 
>>  Fix For: Validation 1.0.0
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Oliver Lietz]

On Monday 27 February 2017 10:30:32 Konrad Windszus wrote:
> > On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
> > 
> > On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
> >> Hey, I don't really think the change for that in
> >> https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation/a
> >> pi
> >> /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure.j
> >> ava ?r1=1734530=1784472=1784472 was good. The resourceBundle
> >> parameter is marked as @Nonnull. If you give a null here the return
> >> value is useless (because the key cannot be resolved against the
> >> MessageBundle). Your change makes it harder to detect such programming
> >> errors during development, because you no longer throw a (noisy)
> >> exception, but rather fall back to a IMHO useless default (empty string)
> >> which is rather unexpected.
> >> 
> >> What is the reason for that change?
> > 
> > Hi Konrad,
> > 
> > checking for null allows validation even if resource bundle is missing.
> > I don't think validation should stop working just because human readable
> > message is missing.
> 
> Yes I agree, but then your code should not call that specific method.

Do you mean validation should stop working when messages are not present?

> Where exactly in your code is it called with ResourceBundle = null?

It's in ValidationPostResponseCreator.

O.
 
> > Regards,
> > O.
> > 
> >> Thanks,
> >> Konrad
> >> 
> >>> On 26 Feb 2017, at 20:04, Oliver Lietz (JIRA)  wrote:
> >>>[
> >>>https://issues.apache.org/jira/browse/SLING-6569?page=com.atlassian.j
> >>>ira.plugin.system.issuetabpanels:all-tabpanel ]>
> >>> 
> >>> Oliver Lietz resolved SLING-6569.
> >>> -
> >>> 
> >>>   Resolution: Fixed
> >>> 
> >>> [r1784472|https://svn.apache.org/r1784472]
> >>> 
>  NPE in DefaultValidationFailure when resource bundle is null
>  
>  
>    Key: SLING-6569
>    URL: https://issues.apache.org/jira/browse/SLING-6569
>    
>    Project: Sling
> 
> Issue Type: Bug
> Components: Extensions, Validation
> 
>   Reporter: Oliver Lietz
>   Assignee: Oliver Lietz
>   
>    Fix For: Validation 1.0.0
> >>> 
> >>> --
> >>> This message was sent by Atlassian JIRA
> >>> (v6.3.15#6346)

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Konrad Windszus]

> On 27 Feb 2017, at 10:28, Oliver Lietz  wrote:
> 
> On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
>> Hey, I don't really think the change for that in
>> https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation/api
>> /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure.java
>> ?r1=1734530=1784472=1784472 was good. The resourceBundle
>> parameter is marked as @Nonnull. If you give a null here the return value
>> is useless (because the key cannot be resolved against the MessageBundle).
>> Your change makes it harder to detect such programming errors during
>> development, because you no longer throw a (noisy) exception, but rather
>> fall back to a IMHO useless default (empty string) which is rather
>> unexpected.
>> 
>> What is the reason for that change?
> 
> Hi Konrad,
> 
> checking for null allows validation even if resource bundle is missing.
> I don't think validation should stop working just because human readable 
> message is missing.
Yes I agree, but then your code should not call that specific method.
Where exactly in your code is it called with ResourceBundle = null?

> 
> Regards,
> O.
> 
>> Thanks,
>> Konrad
>> 
>>> On 26 Feb 2017, at 20:04, Oliver Lietz (JIRA)  wrote:
>>>[
>>>https://issues.apache.org/jira/browse/SLING-6569?page=com.atlassian.j
>>>ira.plugin.system.issuetabpanels:all-tabpanel ]> 
>>> Oliver Lietz resolved SLING-6569.
>>> -
>>> 
>>>   Resolution: Fixed
>>> 
>>> [r1784472|https://svn.apache.org/r1784472]
>>> 
 NPE in DefaultValidationFailure when resource bundle is null
 
 
   Key: SLING-6569
   URL: https://issues.apache.org/jira/browse/SLING-6569
 
   Project: Sling
 
Issue Type: Bug
Components: Extensions, Validation
 
  Reporter: Oliver Lietz
  Assignee: Oliver Lietz
 
   Fix For: Validation 1.0.0
>>> 
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.15#6346)
> 
> 

Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null

[Oliver Lietz]

On Monday 27 February 2017 08:00:14 Konrad Windszus wrote:
> Hey, I don't really think the change for that in
> https://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation/api
> /src/main/java/org/apache/sling/validation/spi/DefaultValidationFailure.java
> ?r1=1734530=1784472=1784472 was good. The resourceBundle
> parameter is marked as @Nonnull. If you give a null here the return value
> is useless (because the key cannot be resolved against the MessageBundle).
> Your change makes it harder to detect such programming errors during
> development, because you no longer throw a (noisy) exception, but rather
> fall back to a IMHO useless default (empty string) which is rather
> unexpected.
> 
> What is the reason for that change?

Hi Konrad,

checking for null allows validation even if resource bundle is missing.
I don't think validation should stop working just because human readable 
message is missing.

Regards,
O.

> Thanks,
> Konrad
> 
> > On 26 Feb 2017, at 20:04, Oliver Lietz (JIRA)  wrote:
> > [
> > https://issues.apache.org/jira/browse/SLING-6569?page=com.atlassian.j
> > ira.plugin.system.issuetabpanels:all-tabpanel ]> 
> > Oliver Lietz resolved SLING-6569.
> > -
> > 
> >Resolution: Fixed
> > 
> > [r1784472|https://svn.apache.org/r1784472]
> > 
> >> NPE in DefaultValidationFailure when resource bundle is null
> >> 
> >> 
> >>Key: SLING-6569
> >>URL: https://issues.apache.org/jira/browse/SLING-6569
> >>
> >>Project: Sling
> >> 
> >> Issue Type: Bug
> >> Components: Extensions, Validation
> >> 
> >>   Reporter: Oliver Lietz
> >>   Assignee: Oliver Lietz
> >>   
> >>Fix For: Validation 1.0.0
> > 
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)

[jira] [Resolved] (SLING-6562) Remove getAdministrativeResourceResolver from Sling Validation

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6562.

Resolution: Fixed

Fixed in [r1784509|http://svn.apache.org/r1784509].
I also refactored the SPI {{ValidationModelProvider}} a bit, so that there is 
no longer a ResourceResolver being passed as argument. That way each 
{{ValidationModelProvider}} needs to take care to open its own service resource 
resolver (if necessary).
Still a resource resolver is necessary in {{2.}} because that one needs to 
resolve the resource inheritance of the to be validated resource type.

> Remove getAdministrativeResourceResolver from Sling Validation
> --
>
> Key: SLING-6562
> URL: https://issues.apache.org/jira/browse/SLING-6562
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Affects Versions: Validation 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> 3 occurrences in
> # {{o.a.s.validation.impl.resourcemodel.ResourceValidationModelProviderImpl}},
> # {{o.a.s.validation.impl.ValidationModelRetrieverImpl}} (most probably the 
> latter should not deal with resource resolvers at all (compare with 
> http://www.mail-archive.com/dev@sling.apache.org/msg64770.html))
> # {{o.a.s.validation.impl.ValidationServiceImpl}} to retrieve the search 
> paths (for relativizing resource types)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)