[jira] [Updated] (SLING-5818) make sling pipe writer a persistent configuration

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier updated SLING-5818:
---
Attachment: SLING-5818.patch

updated patch with a few enhancements / bug fixes

> make sling pipe writer a persistent configuration
> -
>
> Key: SLING-5818
> URL: https://issues.apache.org/jira/browse/SLING-5818
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Attachments: SLING-5818.patch
>
>
> right now, the only way to configure the output of a pipe is to add a json as 
> parameter of the pipe request. Sometimes the output is as important/complex 
> as the pipe itself, and should be persisted.
> This could be also the opportunity to rewrite how writer is managed in a far 
> from ideal if/else block. 
> servlet/plumber should *always* take a writer in account, and call it each 
> time,
> default being path writer, writer should still be overridable through a 
> request parameter



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

[jira] [Updated] (SLING-5818) make sling pipe writer a persistent configuration

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier updated SLING-5818:
---
Attachment: (was: SLING-5818.patch)

> make sling pipe writer a persistent configuration
> -
>
> Key: SLING-5818
> URL: https://issues.apache.org/jira/browse/SLING-5818
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>
> right now, the only way to configure the output of a pipe is to add a json as 
> parameter of the pipe request. Sometimes the output is as important/complex 
> as the pipe itself, and should be persisted.
> This could be also the opportunity to rewrite how writer is managed in a far 
> from ideal if/else block. 
> servlet/plumber should *always* take a writer in account, and call it each 
> time,
> default being path writer, writer should still be overridable through a 
> request parameter



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

[jira] [Reopened] (SLING-6030) Unscheduling Cron-Jobs does not work

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reopened SLING-6030:
-

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

[jira] [Resolved] (SLING-6030) Unscheduling Cron-Jobs does not work

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6030.
-
   Resolution: Duplicate
Fix Version/s: (was: Event 4.1.0)

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

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

[Ian Boston (JIRA)]

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

Ian Boston resolved SLING-6017.
---
Resolution: Fixed

Fixed in  https://svn.apache.org/repos/asf/sling/trunk@1758986
Same curl tests mentioned earlier pass.

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



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

[jira] [Resolved] (SLING-6033) Update Sightly bundles to parent pom 28

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6033.
-
Resolution: Fixed

Fixed in https://svn.apache.org/r1758984.

> Update Sightly bundles to parent pom 28
> ---
>
> Key: SLING-6033
> URL: https://issues.apache.org/jira/browse/SLING-6033
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10, Scripting 
> Sightly Engine 1.0.18, Scripting Sightly REPL 1.0.2, Scripting Sightly Models 
> Use Provider 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly JS Use Provider 1.0.12, Scripting 
> Sightly Engine 1.0.20, Scripting Sightly REPL 1.0.4, Scripting Sightly Models 
> Use Provider 1.0.2, Scripting Sightly Compiler 1.0.0, Scripting Sightly Java 
> Compiler 1.0.0
>
>
> The Sightly bundles should be update to use version 28 of the Apache Sling 
> parent pom.



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

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

[Ian Boston (JIRA)]

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

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

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



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

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

[Ian Boston (JIRA)]

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

Ian Boston reopened SLING-6017:
---

Reopening.
Will make the Engine impl of Part match the Servlet API and will adjust the 
Sling POST Servlet bundle to match the documentation.

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



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

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

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-6017:
---

The behaviour documented for Sling is in conflict with the behaviour in the 
Servlet API. Changing Part to match the Servlet API and keeping the Sling 
behaviour requires a patch to the POST Servlet implementation, which I will do. 
If you are implementing a replacement for the the Sling POST Servlet be certain 
to follow the documented behaviour for Sling.

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



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

[jira] [Created] (SLING-6033) Update Sightly bundles to parent pom 28

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6033:
---

 Summary: Update Sightly bundles to parent pom 28
 Key: SLING-6033
 URL: https://issues.apache.org/jira/browse/SLING-6033
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Sightly Models Use Provider 1.0.0, Scripting 
Sightly REPL 1.0.2, Scripting Sightly Engine 1.0.18, Scripting Sightly JS Use 
Provider 1.0.10
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Sightly Java Compiler 1.0.0, Scripting Sightly 
JS Use Provider 1.0.12, Scripting Sightly Engine 1.0.20, Scripting Sightly REPL 
1.0.4, Scripting Sightly Models Use Provider 1.0.2, Scripting Sightly Compiler 
1.0.0


The Sightly bundles should be update to use version 28 of the Apache Sling 
parent pom.



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

[jira] [Resolved] (SLING-6028) Replace Sightly references with HTL in both code and documentation

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6028.
-
Resolution: Fixed

Code updated in https://svn.apache.org/r1758968, documentation updated in 
https://svn.apache.org/r1758970.



> Replace Sightly references with HTL in both code and documentation
> --
>
> Key: SLING-6028
> URL: https://issues.apache.org/jira/browse/SLING-6028
> Project: Sling
>  Issue Type: Task
>  Components: Documentation, Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>
> Sightly references should be replaced with HTL in both code and documentation 
> in order to follow the renaming of the language. API and bundle names 
> providing it should not be changed.
> 1. https://docs.adobe.com/content/docs/en/htl/update.html
> 2. https://github.com/Adobe-Marketing-Cloud/htl-spec



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

[jira] [Updated] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

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

Henry Krause updated SLING-6030:

Fix Version/s: Event 4.1.0

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Fix For: Event 4.1.0
>
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

[jira] [Commented] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

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

Henry Krause commented on SLING-6030:
-

[~cziegeler] I can confirm that this issue is solved in Event 4.1.0.
Reproduced the bug with plain sling launchpad and version Event 4.0.2. Then 
upgraded to Event 4.1.0 and everything was fine.


> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Fix For: Event 4.1.0
>
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

[jira] [Resolved] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

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

Henry Krause resolved SLING-6030.
-
Resolution: Fixed

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Fix For: Event 4.1.0
>
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5356:
---

after playing around with the ResourceBuilder in integration tests i've some 
questions about the API usage/current implementation:

A) why not supporting absolute paths for resource creation?
example 1:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1", "sling:config-ref", 
"/conf/content/page1");
{noformat}
it would be clearer/cleaner to just write /content/page1 to make sure this 
resource starts at the root, and not at an perhaps unknown parent location.
currently it's completely forbidden to use absoulte paths.

B) reusing resourcebuilder instances
example 2:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1");
resourceBuilder.resource("content/page2");
{noformat}
this produces not the expected result - it produces
/content/page1
/content/page1/content/page2
instead of 
/content/page1
/content/page2

it would be useful if the resourcebuilder returned by a resource method has a 
new parent set, but not the builder instance initially applyed the resource 
method on.
currently the only way to get the expected result is something like:

example 3:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1")
.atParent()
resource("content/page2");
{noformat}

but if creating bigger content structures it makes sense to not use one 
gigantic fluent line, but split if up in smaller parts.

[~bdelacretaz] what do you think?


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



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

[jira] [Updated] (SLING-6031) Teleporter.getService() should wait for required services

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-6031:
---
Summary: Teleporter.getService() should wait for required services  (was: 
Teleporter: Wait for Services not ready yet on startup)

> Teleporter.getService() should wait for required services
> -
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[jira] [Assigned] (SLING-6031) Teleporter: Wait for Services not ready yet on startup

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reassigned SLING-6031:
--

Assignee: Bertrand Delacretaz

In the vast majority of cases when the test code calls {{getService}} I suppose 
it expects the service to be available, so the timeout should probably be set 
just once by the active {{TeleporterRule.Customizer}} to avoid repeating the 
timeout in each test.

If a test really needs to find out about an optional service it can use the 
{{BundleContext}} directly as {{getService}} can provide it.

The problem is that currently the {{Customizer}} talks to the client side only, 
it will need to be modified to pass options to the server side - maybe just by 
adding them as headers to the test bundle that's built for running the test.

I'm assigning this ticket to myself to avoid forgetting it but if someone wants 
to implement this feel free to reassign to yourself!

> Teleporter: Wait for Services not ready yet on startup
> --
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[jira] [Created] (SLING-6031) Teleporter: Wait for Services not ready yet on startup

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6031:
-

 Summary: Teleporter: Wait for Services not ready yet on startup
 Key: SLING-6031
 URL: https://issues.apache.org/jira/browse/SLING-6031
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Reporter: Stefan Seifert
 Fix For: JUnit Tests Teleporter 1.0.8


the JUnit TeleporterRule provides a getService method to get OSGi services for 
the test run. this may return null for services that are not yet started.

as a workaround some integration tests implement their own "WaitFor" pattern
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java

it should be supported by the teleporter rule directly.



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

[jira] [Commented] (SLING-6031) Teleporter: Wait for Services not ready yet on startup

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6031:
---

what would be the best way:
# just move this class to a util java package in the teleporter project
# add an optional "waitfor" flag to the existing getService() methods of the 
junit rule, or an alternative method call getServiceWaitFor
# some other semantics?

> Teleporter: Wait for Services not ready yet on startup
> --
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

RE: flaky integration tests with teleporte rule

[Stefan Seifert]

ah, thanks for the hint. works fine.
created https://issues.apache.org/jira/browse/SLING-6031 for the final solution 
within the teleporter rule.

stefan

>-Original Message-
>From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
>Sent: Friday, September 2, 2016 2:29 PM
>To: dev
>Subject: Re: flaky integration tests with teleporte rule
>
>Hi Stefan,
>
>On Fri, Sep 2, 2016 at 12:32 PM, Stefan Seifert 
>wrote:
>>
>> ...in the old HttpTestBase there was a concept with launchpad.ready.1
>URLs defined which were checked to see if the
>> instances was really ready - is there an equivalent concept in the
>teleporter rule, how to configure it?...
>
>Ah, the "are we ready yet" topic ;-)
>
>In the repoinit tests I'm using a locally implemented WaitFor class
>for that, we might want to move that to the teleporter client module,
>and maybe implement a more declarative way of defining the required
>services. But for now that should help you.
>
>-Bertrand
>
>[1]
>https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit
>/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java

[jira] [Created] (SLING-6032) Not sling pipe

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-6032:
--

 Summary: Not sling pipe
 Key: SLING-6032
 URL: https://issues.apache.org/jira/browse/SLING-6032
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Nicolas Peltier


a not sling pipe, working as a reference sling pipe would be useful:
- output nothing if referred pipe has any output,
- output input if referred pipe has no output



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

[jira] [Commented] (SLING-6031) Teleporter: Wait for Services not ready yet on startup

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6031:
---

once we have this feature existing integration tests should be migrated:
* repoinit integration tests
* context-aware configuration integration tests

> Teleporter: Wait for Services not ready yet on startup
> --
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
> Fix For: JUnit Tests Teleporter 1.0.8
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[jira] [Resolved] (SLING-6029) Context-Aware Config: Adapt defaulting strategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6029.
---
   Resolution: Fixed
Fix Version/s: Context-Aware Configuration 1.0.0

Completed: At revision: 1758950  


> Context-Aware Config: Adapt defaulting strategy
> ---
>
> Key: SLING-6029
> URL: https://issues.apache.org/jira/browse/SLING-6029
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> as discusesd in mail thread 
> http://apache-sling.73963.n3.nabble.com/contextaware-config-Default-configuration-and-naming-td4064399.html
>  we should change:
> * default folder name to /conf
> * rename the {{sling:config}} property name to {{sling:config-ref}}
> * and change the way default configuration is detected by following the 
> example below
> for a content structure like this
> {noformat}
>  /content
>/tenant1   - context path /content/tenant1
>  /region1 - context path /content/tenant1/region1
>/site1 - context path /content/tenant1/region1/site1
>  /page1
> {noformat}
> the configuration is looked up at this paths (in this order)
> {noformat}
>  /conf/tenant1/region1/site1
>  /conf/tenant1/region1
>  /conf/tenant1
>  /conf/global
>  /apps/conf
>  /libs/conf
> {noformat}



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

[jira] [Resolved] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-5890.

Resolution: Fixed

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

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



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

[jira] [Comment Edited] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-5890 at 9/2/16 1:04 PM:


Reopening to apply updated docs


was (Author: rombert):
Reopening to apply update change

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



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

[jira] [Reopened] (SLING-5890) Documentation for the new sling oak restrictions from SLING-5768

[Robert Munteanu (JIRA)]

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

Robert Munteanu reopened SLING-5890:


Reopening to apply update change

> Documentation for the new sling oak restrictions from SLING-5768
> 
>
> Key: SLING-5890
> URL: https://issues.apache.org/jira/browse/SLING-5890
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Attachments: sling-oak-restrictions.mdtext
>
>
> Attached the markdown file for the documentation of SLING-5768, I suppose the 
> best location for it is 
> sling/site/trunk/content/documentation/bundles/sling-oak-restrictions.mdtext 



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

Re: [VOTE] Release Apache Sling Discovery Oak 1.2.10

[Karl Pauls]

+1

regards,

Karl

On Wed, Aug 31, 2016 at 6:16 PM, Stefan Egli  wrote:

> Hi,
>
> We solved 1 issue in this release:
>
> https://issues.apache.org/jira/browse/SLING/fixforversion/12337849
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1516
>
> 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 1516 /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,
> Stefan
>
>
>


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

Re: flaky integration tests with teleporte rule

[Bertrand Delacretaz]

Hi Stefan,

On Fri, Sep 2, 2016 at 12:32 PM, Stefan Seifert  wrote:
>
> ...in the old HttpTestBase there was a concept with launchpad.ready.1 URLs 
> defined which were checked to see if the
> instances was really ready - is there an equivalent concept in the teleporter 
> rule, how to configure it?...

Ah, the "are we ready yet" topic ;-)

In the repoinit tests I'm using a locally implemented WaitFor class
for that, we might want to move that to the teleporter client module,
and maybe implement a more declarative way of defining the required
services. But for now that should help you.

-Bertrand

[1] 
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java

[jira] [Commented] (SLING-6030) Unscheduling Cron-Jobs does not work

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6030:
-

[~henry.k] Thanks for filing the issue. At first look ,this looks like 
SLING-5666 to me. Could you please try Event 4.1.0?

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

FYI, playing with Apache Camel in Sling

[Bertrand Delacretaz]

Hi,

We've created https://github.com/bdelacretaz/sling-camel-playground with a
few colleagues, to explore how to best use Camel in Sling for accessing and
integrating external data sources.

That prototype is very basic for now, but feedback and ideas are welcome as
usual. I'm planning to contribute a sample to Sling once we converge on a
good set of best practices.

-Bertrand

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6017:

Summary: Streaming Uploads detection of request parameters is wrong.  (was: 
Streaming Uplads detection of request parameters is wrong.)

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



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

flaky integration tests with teleporte rule

[Stefan Seifert]

i've used the teleporter rules in the integration tests for the context-aware 
configs:
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config/integration-tests

on my machines they run smooth on a fast machine, but flaky on a not-so-fast 
machine.

source of the problem is that the integration tests sometimes start before the 
ResourceResolverFactory service becomes available, it's a racing condition.

in the old HttpTestBase there was a concept with launchpad.ready.1 URLs defined 
which were checked to see if the instances was really ready - is there an 
equivalent concept in the teleporter rule, how to configure it?

stefan

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

[Satya Deep Maheshwari (JIRA)]

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

Satya Deep Maheshwari commented on SLING-6017:
--

[~ianeboston], if I use a POST request as follows:

{code}
curl -v -F key1=value1 -F file=@test.jpg 
http://admin:admin@localhost:4502/content/test?uploadmode=stream
{code}

then for the {{part}} containing the file binary, 
{{part.getSubmittedFileName()}} returns {{file}} rather than {{test.jpg}} . 
This seems incorrect as per the expected behavior of 
{{part.getSubmittedFileName()}} documented at this 
[link|https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/http/Part.html].

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

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



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

[jira] [Comment Edited] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

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

Henry Krause edited comment on SLING-6030 at 9/2/16 7:58 AM:
-

attached simple maven project to create a bundle to reproduce the bug.


was (Author: henry.k):
simple maven project to create a bundle to reproduce the bug.

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

[jira] [Updated] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

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

Henry Krause updated SLING-6030:

Attachment: crontest.tar

simple maven project to create a bundle to reproduce the bug.

> Unscheduling Cron-Jobs does not work
> 
>
> Key: SLING-6030
> URL: https://issues.apache.org/jira/browse/SLING-6030
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Event 4.0.0
> Environment: AEM-6.2
>Reporter: Henry Krause
>  Labels: events
> Attachments: crontest.tar
>
>
> Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old 
> cron jobs reappear after some time. Events are fired multiple times.
> I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
> remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
> them.
> Please notice attached simple app with two components. CronScheduler should 
> schedule/unschedule 1 cron job on activation/deactivation. CronProcessor 
> simply consumes the events and logs.
> When manually deactivating the CronScheduler-Component all seems fine in the 
> first place, but after some time old cron-jobs reappear for they have never 
> been removed from the repository.
> To reproduce deactivate/activate the CronScheduler-Component some times and 
> you get multiple instances of the same cron-Job.



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

[jira] [Created] (SLING-6030) Unscheduling Cron-Jobs does not work

[Henry Krause (JIRA)]

Henry Krause created SLING-6030:
---

 Summary: Unscheduling Cron-Jobs does not work
 Key: SLING-6030
 URL: https://issues.apache.org/jira/browse/SLING-6030
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Event 4.0.0
 Environment: AEM-6.2
Reporter: Henry Krause


Unscheduling a scheduled (cron-) Job is not being persisted. Therefore old cron 
jobs reappear after some time. Events are fired multiple times.

I encountered this bug with AEM-6.2. Cronjobs are unusable this way. I must 
remove corresponding nodes under /var/eventing/scheduled-jobs to get rid of 
them.

Please notice attached simple app with two components. CronScheduler should 
schedule/unschedule 1 cron job on activation/deactivation. CronProcessor simply 
consumes the events and logs.

When manually deactivating the CronScheduler-Component all seems fine in the 
first place, but after some time old cron-jobs reappear for they have never 
been removed from the repository.

To reproduce deactivate/activate the CronScheduler-Component some times and you 
get multiple instances of the same cron-Job.



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