Re: [jira] [Resolved] (SLING-6569) NPE in DefaultValidationFailure when resource bundle is null
> 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&r2=1784472&pathrev=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 never did. It is just that you should not call ValidationFailure.getMessage(Resour
[jira] [Closed] (SLING-5681) Teleporter: Improve mechanism to check if a deployed test bundle can be started
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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&r2=1784472&pathrev=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
[ 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 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
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
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
[ https://issues.apache.org/jira/browse/SLING-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SLING-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
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
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
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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/SLING-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
+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
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 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
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
+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
+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
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
+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
[ 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
+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
+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
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
[ https://issues.apache.org/jira/browse/SLING-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
+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
+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
+1
RE: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.2
+1
[jira] [Commented] (SLING-6053) SlingAuthenticator identifies wrong sibling node with AuthenticationInfo
[ https://issues.apache.org/jira/browse/SLING-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ https://issues.apache.org/jira/browse/SLING-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SLING-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SLING-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
> 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&r2=1784472&pathrev=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
[ 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
+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
+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
[ https://issues.apache.org/jira/browse/SLING-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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&r2=1784472&pathrev=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
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
[ https://issues.apache.org/jira/browse/SLING-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> 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&r2=1784472&pathrev=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
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&r2=1784472&pathrev=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
> 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&r2=1784472&pathrev=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
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&r2=1784472&pathrev=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
[ 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)