[i18n] Integration tests fails with Oak

[Carsten Ziegeler]

Hi,

I moved the i18n integration tests to use Oak (instead of jackrabbit 2)
and now one integration test fails. Right now, I don't see a good reason
why.
Any help or hint appreciated.

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

[jira] [Resolved] (SLING-5709) OakViewChecker#updateProperties() issueHeartbeat: discoveryService is null

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-5709.
-
   Resolution: Fixed
 Assignee: Stefan Egli
Fix Version/s: Discovery Oak 1.2.14

[r1761753|https://svn.apache.org/r1761753] (SLING-6065)

> OakViewChecker#updateProperties() issueHeartbeat: discoveryService is null
> --
>
> Key: SLING-5709
> URL: https://issues.apache.org/jira/browse/SLING-5709
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Base 1.1.2, Discovery Oak 1.2.6
> Environment: Karaf 4.0.5
>Reporter: Oliver Lietz
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.14
>
>
> {noformat}
> 2016-05-03 08:12:21,647 | ERROR | odeStoreService) | OakViewChecker   
> | issueHeartbeat: discoveryService is null
> {noformat}
> * {{org.apache.sling.discovery.base/1.1.3-SNAPSHOT}}
> * {{org.apache.sling.discovery.oak/1.2.7-SNAPSHOT}}



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

Re: [Oak] Too many OSGi configurations required

[Oliver Lietz]

On Wednesday 21 September 2016 15:18:36 Carsten Ziegeler wrote:
> > On Wednesday 21 September 2016 14:03:00 Carsten Ziegeler wrote:
> >>> On Wednesday 21 September 2016 11:56:30 Carsten Ziegeler wrote:
> >>> And use Testing PaxExam which comes with all required
> >>> configurations.
> >> 
> >> I want to keep my dependencies low
> > 
> > One bundle (3 classes) vs. lots of boilerplate code... YMMV.
>  
>  I tried this for the i18n module, but I get
>  
>  Caused by: java.lang.ClassNotFoundException:
>  org.osgi.service.cm.ConfigurationAdmin
> >>> 
> >>> That exception is not possible with o.a.s.testing.paxexam as the most
> >>> basic
> >>> Sling Option "sling" pulls in "config" (org.apache.felix.configadmin).
> >> 
> >> Do you want to place a bet on this? :)
> > 
> > Too late... 8D
> > 
> >>> Did you use the outdated o.a.s.paxexam.util instead maybe?
> >> 
> >> I don't think so, I've committed the initial work in rev 1761721. I
> >> followed your readme, but I might be missing something obvious?
> >> It would be great if you could have a quick look at the i18n module to
> >> see whether I made a stupid mistake.
> > 
> > fixed some scopes and added missing dependencies in r1761724
> 
> Thanks! I think the missing part from the readme is maybe the
> depends-maven-plugin?

README extended in r1761806 (also explaining when depends-maven-plugin is 
required)

Thanks,
O.

> Regards
> 
> Carsten

[CANCEL][VOTE] Release Apache Sling Discovery Commons 1.0.14 and Discovery Oak 1.2.12

[Stefan Egli]

Thx Daniel for spotting, not sure why I didn't spot this during testing..

I'm cancelling this release and will redo.

Cheers,
Stefan

On 21/09/16 18:13, "Daniel Klco"  wrote:

>-1 This seems to depend on an unreleased version of the Sling API,
>specifically:
>
>org.apache.sling:org.apache.sling.api:jar:2.10.0
>
>Released versions:
>
>http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.sling%22%20A
>ND%20a%3A%22org.apache.sling.api%22
>
>Please find build failure logs here:
>https://gist.github.com/klcodanr/70cb1d351ec92e40936490f117c9d7c2
>
>
>On Wed, Sep 21, 2016 at 11:11 AM, Stefan Egli 
>wrote:
>
>> +1
>>
>> Cheers,
>> Stefan
>>
>> On 21/09/16 17:06, "Stefan Egli"  wrote:
>>
>> >Hi,
>> >
>> >We solved 3 issues in these 2 related releases:
>> >
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12335443
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338203
>> >
>> >Staging repository:
>> >https://repository.apache.org/content/repositories/orgapachesling-1525
>> >
>> >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 1525 /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
>> >
>> >
>> >
>> >
>> >
>>
>>
>>

Re: [VOTE] Release Apache Sling Discovery Commons 1.0.14 and Discovery Oak 1.2.12

[Daniel Klco]

-1 This seems to depend on an unreleased version of the Sling API,
specifically:

org.apache.sling:org.apache.sling.api:jar:2.10.0

Released versions:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.sling%22%20AND%20a%3A%22org.apache.sling.api%22

Please find build failure logs here:
https://gist.github.com/klcodanr/70cb1d351ec92e40936490f117c9d7c2


On Wed, Sep 21, 2016 at 11:11 AM, Stefan Egli  wrote:

> +1
>
> Cheers,
> Stefan
>
> On 21/09/16 17:06, "Stefan Egli"  wrote:
>
> >Hi,
> >
> >We solved 3 issues in these 2 related releases:
> >
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12335443
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338203
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1525
> >
> >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 1525 /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
> >
> >
> >
> >
> >
>
>
>

Re: [VOTE] Release Apache Sling Discovery Commons 1.0.14 and Discovery Oak 1.2.12

[Stefan Egli]

+1

Cheers,
Stefan

On 21/09/16 17:06, "Stefan Egli"  wrote:

>Hi,
>
>We solved 3 issues in these 2 related releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12335443
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338203
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1525
>
>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 1525 /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
>
>
>
>
>

[VOTE] Release Apache Sling Discovery Commons 1.0.14 and Discovery Oak 1.2.12

[Stefan Egli]

Hi,

We solved 3 issues in these 2 related releases:

https://issues.apache.org/jira/browse/SLING/fixforversion/12335443
https://issues.apache.org/jira/browse/SLING/fixforversion/12338203

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

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 1525 /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

[jira] [Updated] (SLING-5598) Exclude slow tests by default with assume(sling.slow.tests.enabled)

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5598:
---
Fix Version/s: (was: Discovery Oak 1.2.12)
   (was: Discovery Commons 1.0.14)
   Discovery Commons 1.0.16
   Discovery Oak 1.2.14

> Exclude slow tests by default with assume(sling.slow.tests.enabled) 
> 
>
> Key: SLING-5598
> URL: https://issues.apache.org/jira/browse/SLING-5598
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.6, Discovery Base 1.1.2, Discovery 
> Commons 1.0.10, Discovery Oak 1.2.6
>Reporter: Stefan Egli
> Fix For: Discovery Base 1.1.6, Discovery Impl 1.2.10, Discovery 
> Oak 1.2.14, Discovery Commons 1.0.16
>
> Attachments: SLING-5598-commons-testing.patch, 
> SLING-5598-discovery.patch
>
>
> As suggested by [~bdelacretaz] on [the 
> list|http://markmail.org/message/yad5awqg53epk3ck] we should improve test 
> duration (ideally 1-2min per bundle max, 10-15min overall). While they are 
> not yet improved however, slow tests should be excluded by default and run 
> only if enabled explicitly. Here's an example {{@Before}} method to achieve 
> that:
> {noformat}
> @Before
> public void checkSlowTests() {
> assumeNotNull(System.getProperty("sling.slow.tests.enabled"));
> }
> {noformat}
> and to enable the slow tests you do: {{mvn -Dsling.slow.tests.enabled=true 
> clean test}}



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

[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5231:
---
Fix Version/s: (was: Discovery Oak 1.2.12)
   (was: Discovery Commons 1.0.14)
   Discovery Commons 1.0.16
   Discovery Oak 1.2.14

> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Commons 1.0.2, Discovery 
> Base 1.0.2, Discovery Oak 1.0.2
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
> Fix For: Discovery Base 1.1.6, Discovery Impl 1.2.10, Discovery 
> Oak 1.2.14, Discovery Commons 1.0.16
>
> Attachments: base-patch.txt, commons-patch.txt, impl-patch.txt, 
> oak-patch.txt
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences 



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

[jira] [Resolved] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5995.

Resolution: Fixed

fixed in http://svn.apache.org/viewvc?rev=1761756=rev

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12, Discovery Oak 1.2.10
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.14, Discovery Oak 1.2.12
>
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Updated] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5995:
---
Fix Version/s: Discovery Oak 1.2.12
   Discovery Commons 1.0.14

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12, Discovery Oak 1.2.10
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.14, Discovery Oak 1.2.12
>
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Updated] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5995:
---
Affects Version/s: Discovery Commons 1.0.12
   Discovery Oak 1.2.10

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12, Discovery Oak 1.2.10
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.14, Discovery Oak 1.2.12
>
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Resolved] (SLING-6065) in discovery: avoid OakViewChecker issueHeartbeat: discoveryService is null

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-6065.

Resolution: Fixed

removed unnecessary log.error - it's a legitimate case: 
http://svn.apache.org/viewvc?rev=1761753=rev

> in discovery: avoid OakViewChecker issueHeartbeat: discoveryService is null
> ---
>
> Key: SLING-6065
> URL: https://issues.apache.org/jira/browse/SLING-6065
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.10
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.12
>
>
> At startup the following log line sometimes appears:
> {noformat}
> 21.09.2016 16:05:08.594 *ERROR* [FelixStartLevel] 
> org.apache.sling.discovery.oak.pinger.OakViewChecker issueHeartbeat: 
> discoveryService is null
> {noformat}



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

[jira] [Created] (SLING-6065) in discovery: avoid OakViewChecker issueHeartbeat: discoveryService is null

[Stefan Egli (JIRA)]

Stefan Egli created SLING-6065:
--

 Summary: in discovery: avoid OakViewChecker issueHeartbeat: 
discoveryService is null
 Key: SLING-6065
 URL: https://issues.apache.org/jira/browse/SLING-6065
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Discovery Oak 1.2.10
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Oak 1.2.12


At startup the following log line sometimes appears:
{noformat}
21.09.2016 16:05:08.594 *ERROR* [FelixStartLevel] 
org.apache.sling.discovery.oak.pinger.OakViewChecker issueHeartbeat: 
discoveryService is null
{noformat}



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

Re: [Oak] Too many OSGi configurations required

[Carsten Ziegeler]

> On Wednesday 21 September 2016 14:03:00 Carsten Ziegeler wrote:
>>> On Wednesday 21 September 2016 11:56:30 Carsten Ziegeler wrote:
>>> And use Testing PaxExam which comes with all required configurations.
>>
>> I want to keep my dependencies low
>
> One bundle (3 classes) vs. lots of boilerplate code... YMMV.

 I tried this for the i18n module, but I get

 Caused by: java.lang.ClassNotFoundException:
 org.osgi.service.cm.ConfigurationAdmin
>>>
>>> That exception is not possible with o.a.s.testing.paxexam as the most
>>> basic
>>> Sling Option "sling" pulls in "config" (org.apache.felix.configadmin).
>>
>> Do you want to place a bet on this? :)
> 
> Too late... 8D
> 
>>> Did you use the outdated o.a.s.paxexam.util instead maybe?
>>
>> I don't think so, I've committed the initial work in rev 1761721. I
>> followed your readme, but I might be missing something obvious?
>> It would be great if you could have a quick look at the i18n module to
>> see whether I made a stupid mistake.
> 
> fixed some scopes and added missing dependencies in r1761724
> 
Thanks! I think the missing part from the readme is maybe the
depends-maven-plugin?

Regards

Carsten

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

Re: Observation with the ResourceChangeListener

[Stefan Egli]

On 21/09/16 14:28, "Carsten Ziegeler"  wrote:

>> On 21/09/16 14:14, "Robert Munteanu"  wrote:
>> 
>>> On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote:
 On 21/09/16 11:26, "Robert Munteanu"  wrote:

>
> On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
>>
>> So we a) need to clarify the contract and b) think about what we
>> do
>> if
>> someone registers for a glob pattern. Do we send removal of
>> parents
>> automatically or do we expect to listener to register at /?
>
> I would say that we send removal of parents automatically, it's
> simpler
> for the clients.

 Ok, I start to see the advantage of getting automatically notified on
 parent removal.. am thinking though if such a choice should not be up
 to
 the listener (perhaps yes, with default 'true')?
>>>
>>> In what scenarios would it be useful to have this choice?
>> 
>> Good question, I'll try to come up with one :) Not in the cache
>>scenario,
>> agreed. How's the exact definition here though: say you register for
>> removal of **.jsp - are you getting notified *only* for parents that
>> actually contain any *.jsp I assume? Otherwise I'm expecting noise..
>> 
>How does the sender now?

Depending on how you implement the observer in oak it could be done.

But exactly, it's potentially expensive as it has to do a traversal of a
removed subtree.

Cheers,
Stefan

Re: [Oak] Too many OSGi configurations required

[Oliver Lietz]

On Wednesday 21 September 2016 14:03:00 Carsten Ziegeler wrote:
> > On Wednesday 21 September 2016 11:56:30 Carsten Ziegeler wrote:
> > And use Testing PaxExam which comes with all required configurations.
>  
>  I want to keep my dependencies low
> >>> 
> >>> One bundle (3 classes) vs. lots of boilerplate code... YMMV.
> >> 
> >> I tried this for the i18n module, but I get
> >> 
> >> Caused by: java.lang.ClassNotFoundException:
> >> org.osgi.service.cm.ConfigurationAdmin
> > 
> > That exception is not possible with o.a.s.testing.paxexam as the most
> > basic
> > Sling Option "sling" pulls in "config" (org.apache.felix.configadmin).
> 
> Do you want to place a bet on this? :)

Too late... 8D

> > Did you use the outdated o.a.s.paxexam.util instead maybe?
> 
> I don't think so, I've committed the initial work in rev 1761721. I
> followed your readme, but I might be missing something obvious?
> It would be great if you could have a quick look at the i18n module to
> see whether I made a stupid mistake.

fixed some scopes and added missing dependencies in r1761724

Regards,
O.

> Thanks
> Carsten
> 
> >> Do we have any example project where this is used?
> > 
> > Sure, e.g. the module itself, Oak Server, Scripting Thymeleaf
> > 
> > Please let me know if README[1] is missing anything for getting started.

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> On 21/09/16 14:14, "Robert Munteanu"  wrote:
> 
>> On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote:
>>> On 21/09/16 11:26, "Robert Munteanu"  wrote:
>>>

 On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
>
> So we a) need to clarify the contract and b) think about what we
> do
> if
> someone registers for a glob pattern. Do we send removal of
> parents
> automatically or do we expect to listener to register at /?

 I would say that we send removal of parents automatically, it's
 simpler
 for the clients.
>>>
>>> Ok, I start to see the advantage of getting automatically notified on
>>> parent removal.. am thinking though if such a choice should not be up
>>> to
>>> the listener (perhaps yes, with default 'true')?
>>
>> In what scenarios would it be useful to have this choice?
> 
> Good question, I'll try to come up with one :) Not in the cache scenario,
> agreed. How's the exact definition here though: say you register for
> removal of **.jsp - are you getting notified *only* for parents that
> actually contain any *.jsp I assume? Otherwise I'm expecting noise..
> 
How does the sender now?

Carsten

 

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

Re: Observation with the ResourceChangeListener

[Stefan Egli]

On 21/09/16 14:14, "Robert Munteanu"  wrote:

>On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote:
>> On 21/09/16 11:26, "Robert Munteanu"  wrote:
>> 
>> > 
>> > On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
>> > > 
>> > > So we a) need to clarify the contract and b) think about what we
>> > > do
>> > > if
>> > > someone registers for a glob pattern. Do we send removal of
>> > > parents
>> > > automatically or do we expect to listener to register at /?
>> > 
>> > I would say that we send removal of parents automatically, it's
>> > simpler
>> > for the clients.
>> 
>> Ok, I start to see the advantage of getting automatically notified on
>> parent removal.. am thinking though if such a choice should not be up
>> to
>> the listener (perhaps yes, with default 'true')?
>
>In what scenarios would it be useful to have this choice?

Good question, I'll try to come up with one :) Not in the cache scenario,
agreed. How's the exact definition here though: say you register for
removal of **.jsp - are you getting notified *only* for parents that
actually contain any *.jsp I assume? Otherwise I'm expecting noise..

Cheers,
Stefan

Re: Observation with the ResourceChangeListener

[Robert Munteanu]

On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote:
> On 21/09/16 11:26, "Robert Munteanu"  wrote:
> 
> > 
> > On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
> > > 
> > > So we a) need to clarify the contract and b) think about what we
> > > do
> > > if
> > > someone registers for a glob pattern. Do we send removal of
> > > parents
> > > automatically or do we expect to listener to register at /?
> > 
> > I would say that we send removal of parents automatically, it's
> > simpler
> > for the clients.
> 
> Ok, I start to see the advantage of getting automatically notified on
> parent removal.. am thinking though if such a choice should not be up
> to
> the listener (perhaps yes, with default 'true')?

In what scenarios would it be useful to have this choice?

Robert

Re: Observation with the ResourceChangeListener

[Stefan Egli]

On 21/09/16 11:26, "Robert Munteanu"  wrote:

>On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
>>So we a) need to clarify the contract and b) think about what we do
>> if
>> someone registers for a glob pattern. Do we send removal of parents
>> automatically or do we expect to listener to register at /?
>
>I would say that we send removal of parents automatically, it's simpler
>for the clients.

Ok, I start to see the advantage of getting automatically notified on
parent removal.. am thinking though if such a choice should not be up to
the listener (perhaps yes, with default 'true')?

Cheers,
Stefan

Re: [Oak] Too many OSGi configurations required

[Carsten Ziegeler]

> On Wednesday 21 September 2016 11:56:30 Carsten Ziegeler wrote:
> And use Testing PaxExam which comes with all required configurations.

 I want to keep my dependencies low
>>>
>>> One bundle (3 classes) vs. lots of boilerplate code... YMMV.
>>
>> I tried this for the i18n module, but I get
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.osgi.service.cm.ConfigurationAdmin
> 
> That exception is not possible with o.a.s.testing.paxexam as the most basic 
> Sling Option "sling" pulls in "config" (org.apache.felix.configadmin).

Do you want to place a bet on this? :)


> Did you use the outdated o.a.s.paxexam.util instead maybe?

I don't think so, I've committed the initial work in rev 1761721. I
followed your readme, but I might be missing something obvious?
It would be great if you could have a quick look at the i18n module to
see whether I made a stupid mistake.

Thanks
Carsten

> 
>> Do we have any example project where this is used?
> 
> Sure, e.g. the module itself, Oak Server, Scripting Thymeleaf
> 
> Please let me know if README[1] is missing anything for getting started.
> 


 

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

Re: [i18n] IT Tests failing in reactor build

[Carsten Ziegeler]

> On Wednesday 21 September 2016 13:09:39 Konrad Windszus wrote:
>> Is this a known issue in Pax Exam or in Maven Failsafe? I had a quick look
>> through the open issues in the latter and couldn’t find a report related to
>> our issues. Do you have any references or enough information to report the
>> issue upstream? Thanks,
> 
> Sorry, no. I *guess* it's an issue in Failsafe (and Surefire) as older 
> versions of Pax Exam (3.x) are also affected but hadn't time to investigate 
> further. You may search for Failsafe 2.19 and Pax Exam to find several 
> reports 
> on mailing lists and SO. Simply sticking to 2.18.1 _solved_ it for me.
> 
I guess we should maybe update our parent pom and downgrade to 2.18.1 there

 Carsten

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

Re: [i18n] IT Tests failing in reactor build

[Oliver Lietz]

On Wednesday 21 September 2016 13:09:39 Konrad Windszus wrote:
> Is this a known issue in Pax Exam or in Maven Failsafe? I had a quick look
> through the open issues in the latter and couldn’t find a report related to
> our issues. Do you have any references or enough information to report the
> issue upstream? Thanks,

Sorry, no. I *guess* it's an issue in Failsafe (and Surefire) as older 
versions of Pax Exam (3.x) are also affected but hadn't time to investigate 
further. You may search for Failsafe 2.19 and Pax Exam to find several reports 
on mailing lists and SO. Simply sticking to 2.18.1 _solved_ it for me.

Regards,
O.

> Konrad
> 
> > Am 21.09.2016 um 12:59 schrieb Oliver Lietz :
> > 
> > On Wednesday 21 September 2016 08:15:12 Carsten Ziegeler wrote:
> >> It seems the problem on Jenkins was related to the latest failsafe
> >> plugin, 2.19.1 - I ran into the exact same problem yesterday while
> >> updating the event IT tests to Oak. Downgrading to 2.18.1 solved the
> >> problem. So I downgraded i18n to use that version as well and now it
> >> seems that the project is built fine on Jenkins as well.
> > 
> > Versions greater 2.18.1 are known to cause trouble (with Pax Exam).
> > Also, you may want to use the forked container (instead of native) to run
> > in a "clean" VM.
> > 
> > Regards,
> > O.
> > 
> >> Carsten

[jira] [Commented] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5995:


Note that this change requires sling.api 2.10 or newer - something to keep in 
mind when updating discovery.impl as that might be installed on older versions 
of sling.api (2.9)

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

Re: [Oak] Too many OSGi configurations required

[Oliver Lietz]

On Wednesday 21 September 2016 11:56:30 Carsten Ziegeler wrote:
> >>> And use Testing PaxExam which comes with all required configurations.
> >> 
> >> I want to keep my dependencies low
> > 
> > One bundle (3 classes) vs. lots of boilerplate code... YMMV.
> 
> I tried this for the i18n module, but I get
> 
> Caused by: java.lang.ClassNotFoundException:
> org.osgi.service.cm.ConfigurationAdmin

That exception is not possible with o.a.s.testing.paxexam as the most basic 
Sling Option "sling" pulls in "config" (org.apache.felix.configadmin).
Did you use the outdated o.a.s.paxexam.util instead maybe?

> Do we have any example project where this is used?

Sure, e.g. the module itself, Oak Server, Scripting Thymeleaf

Please let me know if README[1] is missing anything for getting started.

Regards,
O.

[1] 
https://github.com/apache/sling/tree/trunk/testing/org.apache.sling.testing.paxexam

> Regards
> Carsten

Re: Sling JMS Based Job Support - Difference between queue name and job type

[Chetan Mehrotra]

Thanks Ian for the details. That helps!
Chetan Mehrotra


On Wed, Sep 21, 2016 at 4:32 PM, Ian Boston  wrote:
> Hi,
> Documentation (README.md) and JavaDoc has been updated. Hopefully that will
> make it easier for everyone to follow, including myself in a few months
> time.
> Best Regards
> Ian
>
> On 21 September 2016 at 11:08, Ian Boston  wrote:
>
>> Hi,
>> Its been a while since I have looked at this code, and I realise the
>> JavaDoc on the API isn't quite as complete as it should be. The bundle was
>> originally intended as an example of how to use the MoM API, but it does
>> serve as a Job subsystem.
>>
>> Its probably best to talk about how a job is run first.
>> A message goes onto a named queue that that the JobQueueConsumer consumes.
>> That message updates the state of a job and takes it through its
>> lifecycle. There may be many messages on the queue relating to each Job.
>> (eg abort).
>> The JobQueueConsumer will forward all messages it recognises as Job
>> related to the JobSubsystem.
>> The JobSubsystem will have multiple JobConsumers registered with it, each
>> registration capable of executing a number of JobTypes.
>> If a sequence of messages is dequeued to start a Job, the appropriate
>> JobConsumer capable of executing that Job will execute that Job.
>>
>> Hierarchically the execution of jobs follows
>>
>> Queue -> JobQueueConsumer -> JobSubsystem -> JobConsumer
>>
>> To consume a job of a certain type on a certain queue, implement the
>> JobConsumer API and give it a list of JobTypes that it can execute. Load
>> that into an OSGi container with a JobQueueConsumer configured to consume a
>> named queue.
>>
>> To queue jobs, do as you have done with the JobBuilder.
>>
>> The indirections are there to allow multiple queues to exist in the system
>> each capable of routing messages to multiple job consumers, potentially via
>> multiple routes.
>>
>> The Jobs API was an example of how to use the MoM API. I will try and
>> improve the documentation to capture the above.
>>
>> HTH
>> Best Regards
>> Ian
>>
>>
>> On 21 September 2016 at 07:48, Chetan Mehrotra 
>> wrote:
>>
>>> I was looking at the Sling JMS based Job SLING-5645 and trying to
>>> understand the api flow.
>>>
>>> Sender side submits a job for a given queue and job type
>>>
>>> --
>>> Job job = jobManager.newJobBuilder(Types.jobQueue(TOPIC),
>>> Types.jobType(AsyncJobConsumer.JOB_TYPE)).addProperties(
>>> ImmutableMap.of("jobtest", (Object) "jobtest")).add();
>>> --
>>>
>>> While on consumer side we specify only job type
>>>
>>> ---
>>> @Component(immediate = true)
>>> @Properties({
>>> @Property(name = JobConsumer.JOB_TYPES, cardinality =
>>> Integer.MAX_VALUE, value = {
>>> AsyncJobConsumer.JOB_TYPE
>>> })
>>> })
>>> @Service(value = JobConsumer.class)
>>> public class AsyncJobConsumer implements JobConsumer
>>> ---
>>>
>>> So whats the purpose of queue name here?
>>>
>>> Chetan Mehrotra
>>>
>>
>>

Re: [i18n] IT Tests failing in reactor build

[Konrad Windszus]

Is this a known issue in Pax Exam or in Maven Failsafe? I had a quick look 
through the open issues in the latter and couldn’t find a report related to our 
issues.
Do you have any references or enough information to report the issue upstream?
Thanks,
Konrad

> Am 21.09.2016 um 12:59 schrieb Oliver Lietz :
> 
> On Wednesday 21 September 2016 08:15:12 Carsten Ziegeler wrote:
>> It seems the problem on Jenkins was related to the latest failsafe
>> plugin, 2.19.1 - I ran into the exact same problem yesterday while
>> updating the event IT tests to Oak. Downgrading to 2.18.1 solved the
>> problem. So I downgraded i18n to use that version as well and now it
>> seems that the project is built fine on Jenkins as well.
> 
> Versions greater 2.18.1 are known to cause trouble (with Pax Exam).
> Also, you may want to use the forked container (instead of native) to run in 
> a 
> "clean" VM.
> 
> Regards,
> O.
> 
>> Carsten
> 

Re: Sling JMS Based Job Support - Difference between queue name and job type

[Ian Boston]

Hi,
Documentation (README.md) and JavaDoc has been updated. Hopefully that will
make it easier for everyone to follow, including myself in a few months
time.
Best Regards
Ian

On 21 September 2016 at 11:08, Ian Boston  wrote:

> Hi,
> Its been a while since I have looked at this code, and I realise the
> JavaDoc on the API isn't quite as complete as it should be. The bundle was
> originally intended as an example of how to use the MoM API, but it does
> serve as a Job subsystem.
>
> Its probably best to talk about how a job is run first.
> A message goes onto a named queue that that the JobQueueConsumer consumes.
> That message updates the state of a job and takes it through its
> lifecycle. There may be many messages on the queue relating to each Job.
> (eg abort).
> The JobQueueConsumer will forward all messages it recognises as Job
> related to the JobSubsystem.
> The JobSubsystem will have multiple JobConsumers registered with it, each
> registration capable of executing a number of JobTypes.
> If a sequence of messages is dequeued to start a Job, the appropriate
> JobConsumer capable of executing that Job will execute that Job.
>
> Hierarchically the execution of jobs follows
>
> Queue -> JobQueueConsumer -> JobSubsystem -> JobConsumer
>
> To consume a job of a certain type on a certain queue, implement the
> JobConsumer API and give it a list of JobTypes that it can execute. Load
> that into an OSGi container with a JobQueueConsumer configured to consume a
> named queue.
>
> To queue jobs, do as you have done with the JobBuilder.
>
> The indirections are there to allow multiple queues to exist in the system
> each capable of routing messages to multiple job consumers, potentially via
> multiple routes.
>
> The Jobs API was an example of how to use the MoM API. I will try and
> improve the documentation to capture the above.
>
> HTH
> Best Regards
> Ian
>
>
> On 21 September 2016 at 07:48, Chetan Mehrotra 
> wrote:
>
>> I was looking at the Sling JMS based Job SLING-5645 and trying to
>> understand the api flow.
>>
>> Sender side submits a job for a given queue and job type
>>
>> --
>> Job job = jobManager.newJobBuilder(Types.jobQueue(TOPIC),
>> Types.jobType(AsyncJobConsumer.JOB_TYPE)).addProperties(
>> ImmutableMap.of("jobtest", (Object) "jobtest")).add();
>> --
>>
>> While on consumer side we specify only job type
>>
>> ---
>> @Component(immediate = true)
>> @Properties({
>> @Property(name = JobConsumer.JOB_TYPES, cardinality =
>> Integer.MAX_VALUE, value = {
>> AsyncJobConsumer.JOB_TYPE
>> })
>> })
>> @Service(value = JobConsumer.class)
>> public class AsyncJobConsumer implements JobConsumer
>> ---
>>
>> So whats the purpose of queue name here?
>>
>> Chetan Mehrotra
>>
>
>

Re: [i18n] IT Tests failing in reactor build

[Oliver Lietz]

On Wednesday 21 September 2016 08:15:12 Carsten Ziegeler wrote:
> It seems the problem on Jenkins was related to the latest failsafe
> plugin, 2.19.1 - I ran into the exact same problem yesterday while
> updating the event IT tests to Oak. Downgrading to 2.18.1 solved the
> problem. So I downgraded i18n to use that version as well and now it
> seems that the project is built fine on Jenkins as well.

Versions greater 2.18.1 are known to cause trouble (with Pax Exam).
Also, you may want to use the forked container (instead of native) to run in a 
"clean" VM.

Regards,
O.

>  Carsten

Re: Sling JMS Based Job Support - Difference between queue name and job type

[Ian Boston]

Hi,
Its been a while since I have looked at this code, and I realise the
JavaDoc on the API isn't quite as complete as it should be. The bundle was
originally intended as an example of how to use the MoM API, but it does
serve as a Job subsystem.

Its probably best to talk about how a job is run first.
A message goes onto a named queue that that the JobQueueConsumer consumes.
That message updates the state of a job and takes it through its lifecycle.
There may be many messages on the queue relating to each Job. (eg abort).
The JobQueueConsumer will forward all messages it recognises as Job related
to the JobSubsystem.
The JobSubsystem will have multiple JobConsumers registered with it, each
registration capable of executing a number of JobTypes.
If a sequence of messages is dequeued to start a Job, the appropriate
JobConsumer capable of executing that Job will execute that Job.

Hierarchically the execution of jobs follows

Queue -> JobQueueConsumer -> JobSubsystem -> JobConsumer

To consume a job of a certain type on a certain queue, implement the
JobConsumer API and give it a list of JobTypes that it can execute. Load
that into an OSGi container with a JobQueueConsumer configured to consume a
named queue.

To queue jobs, do as you have done with the JobBuilder.

The indirections are there to allow multiple queues to exist in the system
each capable of routing messages to multiple job consumers, potentially via
multiple routes.

The Jobs API was an example of how to use the MoM API. I will try and
improve the documentation to capture the above.

HTH
Best Regards
Ian


On 21 September 2016 at 07:48, Chetan Mehrotra 
wrote:

> I was looking at the Sling JMS based Job SLING-5645 and trying to
> understand the api flow.
>
> Sender side submits a job for a given queue and job type
>
> --
> Job job = jobManager.newJobBuilder(Types.jobQueue(TOPIC),
> Types.jobType(AsyncJobConsumer.JOB_TYPE)).addProperties(
> ImmutableMap.of("jobtest", (Object) "jobtest")).add();
> --
>
> While on consumer side we specify only job type
>
> ---
> @Component(immediate = true)
> @Properties({
> @Property(name = JobConsumer.JOB_TYPES, cardinality =
> Integer.MAX_VALUE, value = {
> AsyncJobConsumer.JOB_TYPE
> })
> })
> @Service(value = JobConsumer.class)
> public class AsyncJobConsumer implements JobConsumer
> ---
>
> So whats the purpose of queue name here?
>
> Chetan Mehrotra
>

Re: [Oak] Too many OSGi configurations required

[Carsten Ziegeler]

> 
>>> And use Testing PaxExam which comes with all required configurations.
>>
>> I want to keep my dependencies low
> 
> One bundle (3 classes) vs. lots of boilerplate code... YMMV.

I tried this for the i18n module, but I get

Caused by: java.lang.ClassNotFoundException:
org.osgi.service.cm.ConfigurationAdmin

Do we have any example project where this is used?

Regards
Carsten



 

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

Re: Observation with the ResourceChangeListener

[Robert Munteanu]

On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote:
> > 
> > On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote:
> > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 21.9.16 9:14 , Carsten Ziegeler wrote:
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 21.9.16 8:50 , Carsten Ziegeler wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 21.9.16 8:33 , Carsten Ziegeler wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Pushing filters as much into Oak has many
> > > > > > > > > > performance
> > > > > > > > > > advantages
> > > > > > > > > > though
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > compared to filter messages after delivery. Also
> > > > > > > > > > > Oak
> > > > > > > > > > > would easily
> > > > > > > > > > > able
> > > > > > > > > > > to support the delete use case described above.
> > > > > > > > > > > 
> > > > > > > > > In all cases, always, guaranteed?
> > > > > > > > 
> > > > > > > > For some definition of "all cases, always, guaranteed":
> > > > > > > > yes
> > > > > > > > ;-)
> > > > > > > 
> > > > > > > :) So there is no compaction, never?
> > > > > > 
> > > > > > There isn't if you configure it that way. It's up to you.
> > > > > > 
> > > > > > But this is completely irrelevant here. If compaction would
> > > > > > cause events
> > > > > > to get lost, there is nothing you could do about it in
> > > > > > Sling.
> > > > > > Regardless
> > > > > > whether you implement an ad-hoc DYI filter in Sling or use
> > > > > > Oak
> > > > > > filters.
> > > > > > 
> > > > > I agree.
> > > > > 
> > > > > Just to clarify, if I delete "/libs/foo" I get oak
> > > > > observation
> > > > > events
> > > > > for all nodes that where under /foo with the removed
> > > > > properties
> > > > > of each
> > > > > node, right?
> > > > 
> > > > No, just for the root of the removed tree.
> > > > 
> > > > See
> > > > https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId
> > > > =139
> > > > 11484=com.atlassian.jira.plugin.system.issuetabpanels:comm
> > > > ent-
> > > > tabpanel#comment-13911484
> > > > 
> > > > 
> > > ah..memories :)
> > > 
> > > ok, but that proves my point that glob filtering does not work
> > > for
> > > remove
> > 
> > Is that a hard blocker? I can imagine that it's more convenient for
> > the
> > application to get discrete change events for each removal, but if
> > we
> > slightly change the contract to follow Oak's approach, would it be
> > more
> > performant?
> > 
> > Without looking in more detail, I would imagine that the
> > application
> > usually needs to clear caches or stop doing work when such an
> > instance
> > is removed. The application can then do this for all resources with
> > a
> > common parent. Sure, it's slightly more verbose and might require a
> > slight rearrangement of in-memory data structures, but overall
> > doable.
> 
> It's not a problem in general - the problem is that we don't specify
> the
> behaviour correctly. Right now code registering a listener with a
> glob
> pattern of **.jsp expects to get remove events in all case for
> exactly
> the removed jsps. But this is only true if the jsp is directly
> removed,
> not if any parent is removed.
> 
> So we a) need to clarify the contract and b) think about what we do
> if
> someone registers for a glob pattern. Do we send removal of parents
> automatically or do we expect to listener to register at /?

I would say that we send removal of parents automatically, it's simpler
for the clients.

Robert

> 
> Regards
> Carsten
> > 
> > 
> > Stefan also echoed the same concern - sometimes it's not possible (
> > or
> > performant/scalable ) to have such fine-grained change
> > notifications.
> > 
> > Robert
> > 
> > > 
> > > 
> > > Carsten
> > > 
> > > > 
> > > > 
> > > > ;-)
> > > > 
> > > > Michael
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Carsten
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > >  
> > > 
> > 
> > 
> 
> 
>  
> 

Re: Observation with the ResourceChangeListener

[Stefan Egli]

On 21/09/16 11:18, "Carsten Ziegeler"  wrote:

>So we a) need to clarify the contract and b) think about what we do if
>someone registers for a glob pattern. Do we send removal of parents
>automatically or do we expect to listener to register at /?

I'd say clarifying the contract is enough (and to me slightly more
intuitive).

Cheers,
Stefan

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote:
>>>
>>>
>>>
>>> On 21.9.16 9:14 , Carsten Ziegeler wrote:

>
>
>
> On 21.9.16 8:50 , Carsten Ziegeler wrote:
>>
>>>
>>>
>>>
>>> On 21.9.16 8:33 , Carsten Ziegeler wrote:

>
> Pushing filters as much into Oak has many performance
> advantages
> though
>>
>> compared to filter messages after delivery. Also Oak
>> would easily
>> able
>> to support the delete use case described above.
>>
 In all cases, always, guaranteed?
>>>
>>> For some definition of "all cases, always, guaranteed": yes
>>> ;-)
>>
>> :) So there is no compaction, never?
>
> There isn't if you configure it that way. It's up to you.
>
> But this is completely irrelevant here. If compaction would
> cause events
> to get lost, there is nothing you could do about it in Sling.
> Regardless
> whether you implement an ad-hoc DYI filter in Sling or use Oak
> filters.
>
 I agree.

 Just to clarify, if I delete "/libs/foo" I get oak observation
 events
 for all nodes that where under /foo with the removed properties
 of each
 node, right?
>>>
>>> No, just for the root of the removed tree.
>>>
>>> See
>>> https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=139
>>> 11484=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel#comment-13911484
>>>
>>>
>> ah..memories :)
>>
>> ok, but that proves my point that glob filtering does not work for
>> remove
> 
> Is that a hard blocker? I can imagine that it's more convenient for the
> application to get discrete change events for each removal, but if we
> slightly change the contract to follow Oak's approach, would it be more
> performant?
> 
> Without looking in more detail, I would imagine that the application
> usually needs to clear caches or stop doing work when such an instance
> is removed. The application can then do this for all resources with a
> common parent. Sure, it's slightly more verbose and might require a
> slight rearrangement of in-memory data structures, but overall doable.

It's not a problem in general - the problem is that we don't specify the
behaviour correctly. Right now code registering a listener with a glob
pattern of **.jsp expects to get remove events in all case for exactly
the removed jsps. But this is only true if the jsp is directly removed,
not if any parent is removed.

So we a) need to clarify the contract and b) think about what we do if
someone registers for a glob pattern. Do we send removal of parents
automatically or do we expect to listener to register at /?

Regards
Carsten
> 
> Stefan also echoed the same concern - sometimes it's not possible ( or
> performant/scalable ) to have such fine-grained change notifications.
> 
> Robert
> 
>>
>> Carsten
>>
>>>
>>> ;-)
>>>
>>> Michael
>>>


 Carsten



>>>
>>
>>
>>  
>>
> 
> 


 

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

Re: Observation with the ResourceChangeListener

[Stefan Egli]

On 21/09/16 11:12, "Carsten Ziegeler"  wrote:

>> Hi,
>> 
>> On 21/09/16 08:13, "Carsten Ziegeler"  wrote:
>> 
>>> Finally, recently some people suggested that we support all of Oaks
>>> filtering possibilities for the ResourceChangeListener. I'm not a fan
>>>of
>>> that - first of all, we should only support what is really needed.
>>> Second, as soon as we support it, it means that every resource provider
>>> needs to support it which might but a high burden for nothing on the
>>> implementations. And finally, as we already see with the globbing,
>>> filtering is nice but we have to be careful for remove events and
>>> clearly specifiy how this works - and specify it in a way that it
>>>really
>>> works for the listeners.
>> 
>> What about support for the famous ExcludeExternal?
>> 
>
>That's already there - a listener by default just listens for local
>events. If it implements ExternalRCL as well (marker interface), it gets
>the external events as well

Ah, good to know!

Cheers,
Stefan

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> Hi,
> 
> On 21/09/16 08:13, "Carsten Ziegeler"  wrote:
> 
>> Finally, recently some people suggested that we support all of Oaks
>> filtering possibilities for the ResourceChangeListener. I'm not a fan of
>> that - first of all, we should only support what is really needed.
>> Second, as soon as we support it, it means that every resource provider
>> needs to support it which might but a high burden for nothing on the
>> implementations. And finally, as we already see with the globbing,
>> filtering is nice but we have to be careful for remove events and
>> clearly specifiy how this works - and specify it in a way that it really
>> works for the listeners.
> 
> What about support for the famous ExcludeExternal?
> 

That's already there - a listener by default just listens for local
events. If it implements ExternalRCL as well (marker interface), it gets
the external events as well

 Carsten

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

Re: Observation with the ResourceChangeListener

[Robert Munteanu]

On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote:
> > 
> > 
> > 
> > On 21.9.16 9:14 , Carsten Ziegeler wrote:
> > > 
> > > > 
> > > > 
> > > > 
> > > > On 21.9.16 8:50 , Carsten Ziegeler wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 21.9.16 8:33 , Carsten Ziegeler wrote:
> > > > > > > 
> > > > > > > > 
> > > > > > > > Pushing filters as much into Oak has many performance
> > > > > > > > advantages
> > > > > > > > though
> > > > > > > > > 
> > > > > > > > > compared to filter messages after delivery. Also Oak
> > > > > > > > > would easily
> > > > > > > > > able
> > > > > > > > > to support the delete use case described above.
> > > > > > > > > 
> > > > > > > In all cases, always, guaranteed?
> > > > > > 
> > > > > > For some definition of "all cases, always, guaranteed": yes
> > > > > > ;-)
> > > > > 
> > > > > :) So there is no compaction, never?
> > > > 
> > > > There isn't if you configure it that way. It's up to you.
> > > > 
> > > > But this is completely irrelevant here. If compaction would
> > > > cause events
> > > > to get lost, there is nothing you could do about it in Sling.
> > > > Regardless
> > > > whether you implement an ad-hoc DYI filter in Sling or use Oak
> > > > filters.
> > > > 
> > > I agree.
> > > 
> > > Just to clarify, if I delete "/libs/foo" I get oak observation
> > > events
> > > for all nodes that where under /foo with the removed properties
> > > of each
> > > node, right?
> > 
> > No, just for the root of the removed tree.
> > 
> > See
> > https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=139
> > 11484=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> > tabpanel#comment-13911484
> > 
> > 
> ah..memories :)
> 
> ok, but that proves my point that glob filtering does not work for
> remove

Is that a hard blocker? I can imagine that it's more convenient for the
application to get discrete change events for each removal, but if we
slightly change the contract to follow Oak's approach, would it be more
performant?

Without looking in more detail, I would imagine that the application
usually needs to clear caches or stop doing work when such an instance
is removed. The application can then do this for all resources with a
common parent. Sure, it's slightly more verbose and might require a
slight rearrangement of in-memory data structures, but overall doable.

Stefan also echoed the same concern - sometimes it's not possible ( or
performant/scalable ) to have such fine-grained change notifications.

Robert

> 
> Carsten
> 
> > 
> > ;-)
> > 
> > Michael
> > 
> > > 
> > > 
> > > Carsten
> > > 
> > > 
> > > 
> > 
> 
> 
>  
> 

[jira] [Created] (SLING-6064) Redirect servlet should encode url for redirecting

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6064:
---

 Summary: Redirect servlet should encode url for redirecting
 Key: SLING-6064
 URL: https://issues.apache.org/jira/browse/SLING-6064
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Get 2.1.18
Reporter: Carsten Ziegeler
 Fix For: Servlets Get 2.1.20


The RedirectServlet is directly setting the location header (wondering why 
sendRedirect is not used instead?) however it is not encoding the URL (calling 
encodeRedirectURL). Therefore if query parameters are appended these are not 
encoded. According to the servlet spec, the url should be encoded before being 
passed to sendRedirect. I would assume the same applies to setting the header 
as it goes in there unmodified



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

[jira] [Resolved] (SLING-6063) plumber servlet doesn't persist changes anymore

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6063.

Resolution: Fixed

Committed in https://svn.apache.org/r1761699, thanks for the patch!

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Pipes 1.0.0
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 1.0.0
>
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

[jira] [Updated] (SLING-6063) plumber servlet doesn't persist changes anymore

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6063:
---
Fix Version/s: Pipes 1.0.0

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Pipes 1.0.0
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 1.0.0
>
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

[jira] [Assigned] (SLING-6063) plumber servlet doesn't persist changes anymore

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-6063:
--

Assignee: Robert Munteanu

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Pipes 1.0.0
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

Re: Observation with the ResourceChangeListener

[Stefan Egli]

Hi,

On 21/09/16 08:13, "Carsten Ziegeler"  wrote:

>Finally, recently some people suggested that we support all of Oaks
>filtering possibilities for the ResourceChangeListener. I'm not a fan of
>that - first of all, we should only support what is really needed.
>Second, as soon as we support it, it means that every resource provider
>needs to support it which might but a high burden for nothing on the
>implementations. And finally, as we already see with the globbing,
>filtering is nice but we have to be careful for remove events and
>clearly specifiy how this works - and specify it in a way that it really
>works for the listeners.

What about support for the famous ExcludeExternal?

Cheers,
Stefan

Re: [VOTE] Release Apache Sling Testing Clients 1.0.0, Apache Sling Server Setup Tools 1.0.0 and Apache Sling Testing Rules 1.0.0

[Andrei Dulvac]

Sorry, I forgot I had already added
https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html#http-based-integration-tests

Would it make sense to add it to the page you linked and maybe drop a
couple of lines regarding the usecases?

 - Andrei

On Wed, Sep 21, 2016 at 10:31 AM Andrei Dulvac  wrote:

> Hi Konrad,
>
> On Wed, Sep 21, 2016 at 10:18 AM Konrad Windszus  wrote:
>
>> Hey Andrei, could you briefly mention those new bundles in
>> https://sling.apache.org/documentation/development/sling-testing-tools.html
>> and/or
>> https://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html
>> just to have the complete picture on those pages?
>>
>
> Yes, I'll update those pages. Might take a while, as I'm still learning
> the ways of the apache CMS and all that.
>
>
>>
>> To me the difference to the Teleporter approach is not that obvious.
>> Maybe you can write some sentences on when it is recommended to choose
>> which approach.
>>
>
> Hmm, I think there are almost NO collisions there.
>
> The teleporter is a brilliant mechanism that runs a test on both the
> client-side (but only what's going on before the teleporter rule swaps the
> junit statement with a bundle creation, upload and test trigger on the
> server) and on the server-side, using sling junit core. You write tests on
> the serverside, but trigger them from the client-side and report them on
> the client-side.
>
> The Sling HTTP testing clients/ rules are a toolset of HTTP/ Junit goodies
> for writing tests that interact with instances at HTTP level. Think that
> you'd wanna test a servlet or a jsp. It would be a bit weird to do that
> from a server-side test written with the teleporter.
>
> Or that you want to test some clustering functionality where you have/
> provision 3 instances and interact with them "from the top" and the test
> logic needs 3 instances (see *SlingInstanceRule*). If you write a test
> with the teleporter, it will run *inside* one instance.
>
> Or that you want to use the clients in a stress-testing scenario (we're
> using the http clients in an internal tool in Adobe to stress test the
> system with Sling-specific operations, like creating and deleting nodes).
> The client-side junit stays stable and can keep going if the server is
> unresponsive.
>
> Also, you can perfectly have a module with some  tests using the http
> framework and some tests using the teleporter.
>
> I hope this makes sense and that I haven't misunderstood the question.
>
> - Andrei
>
>
>>
>> Thanks,
>> Konrad
>>
>> > Am 21.09.2016 um 10:11 schrieb Andrei Dulvac :
>> >
>> > Hi Stefan.
>> > Thanks for the +1.
>> > On Tue, Sep 20, 2016 at 6:20 PM Stefan Seifert 
>> > wrote:
>> >
>> >> +1
>> >>
>> >> this is a lot of interesting stuff - do we already have some
>> >> documentation/sample project for this?
>> >>
>> > We have some docu on the junit rules [0] - the entrypoint for writing a
>> > test, some docu on the clients [1] (the FAQ at the end also provides
>> some
>> > insight into some design choices).
>> >
>> > I've also adapted the old SlingTestBase from sling.testing.tools in
>> > serversetup [2] in order to use those in the sling tests, using the
>> > existing mechanism to start a new sling instance for tests, as part of
>> the
>> > maven build. It's used in the SlingInstanceRule [3] which I used to
>> adapt
>> > some sample tests like [4] (I didn't want to touch launchpad tests or
>> > anything like that, but I'm willing to put in some work if needed). I
>> see
>> > Bertrand also adapted some tests there, in samples/ lately.
>> >
>> > That's mostly what we have, no wholesome documentation, unfortunately.
>> Ah,
>> > another helpful thing to have a look at is the unit tests for the
>> clients,
>> > like AbstractSlingClientGetUrlTest [5] which makes sure there are no
>> > regressions in terms of how URIs are dealt with.
>> >
>> > HTH,
>> > - Andrei
>> >
>> > ---
>> > [0] https://github.com/apache/sling/tree/trunk/testing/junit/rules
>> > [1] https://github.com/apache/sling/tree/trunk/testing/http/clients
>> > [2]
>> >
>> https://github.com/apache/sling/blob/trunk/testing/serversetup/src/main/java/org/apache/sling/testing/serversetup/instance/SlingTestBase.java
>> > [3]
>> >
>> https://github.com/apache/sling/blob/trunk/testing/junit/rules/src/main/java/org/apache/sling/testing/junit/rules/SlingInstanceRule.java
>> > [4]
>> >
>> https://github.com/apache/sling/blob/b0debb458d0ac7098ded772412adc11163865d2c/testing/samples/bundle-with-it/src/test/java/org/apache/sling/testing/samples/bundlewit/OsgiConsoleHttpIT.java
>> > [5]
>> >
>> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/AbstractSlingClientGetUrlTest.java
>>
>>

Re: [VOTE] Release Apache Sling Testing Clients 1.0.0, Apache Sling Server Setup Tools 1.0.0 and Apache Sling Testing Rules 1.0.0

[Andrei Dulvac]

Hi Konrad,

On Wed, Sep 21, 2016 at 10:18 AM Konrad Windszus  wrote:

> Hey Andrei, could you briefly mention those new bundles in
> https://sling.apache.org/documentation/development/sling-testing-tools.html
> and/or
> https://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html
> just to have the complete picture on those pages?
>

Yes, I'll update those pages. Might take a while, as I'm still learning the
ways of the apache CMS and all that.


>
> To me the difference to the Teleporter approach is not that obvious. Maybe
> you can write some sentences on when it is recommended to choose which
> approach.
>

Hmm, I think there are almost NO collisions there.

The teleporter is a brilliant mechanism that runs a test on both the
client-side (but only what's going on before the teleporter rule swaps the
junit statement with a bundle creation, upload and test trigger on the
server) and on the server-side, using sling junit core. You write tests on
the serverside, but trigger them from the client-side and report them on
the client-side.

The Sling HTTP testing clients/ rules are a toolset of HTTP/ Junit goodies
for writing tests that interact with instances at HTTP level. Think that
you'd wanna test a servlet or a jsp. It would be a bit weird to do that
from a server-side test written with the teleporter.

Or that you want to test some clustering functionality where you have/
provision 3 instances and interact with them "from the top" and the test
logic needs 3 instances (see *SlingInstanceRule*). If you write a test with
the teleporter, it will run *inside* one instance.

Or that you want to use the clients in a stress-testing scenario (we're
using the http clients in an internal tool in Adobe to stress test the
system with Sling-specific operations, like creating and deleting nodes).
The client-side junit stays stable and can keep going if the server is
unresponsive.

Also, you can perfectly have a module with some  tests using the http
framework and some tests using the teleporter.

I hope this makes sense and that I haven't misunderstood the question.

- Andrei


>
> Thanks,
> Konrad
>
> > Am 21.09.2016 um 10:11 schrieb Andrei Dulvac :
> >
> > Hi Stefan.
> > Thanks for the +1.
> > On Tue, Sep 20, 2016 at 6:20 PM Stefan Seifert 
> > wrote:
> >
> >> +1
> >>
> >> this is a lot of interesting stuff - do we already have some
> >> documentation/sample project for this?
> >>
> > We have some docu on the junit rules [0] - the entrypoint for writing a
> > test, some docu on the clients [1] (the FAQ at the end also provides some
> > insight into some design choices).
> >
> > I've also adapted the old SlingTestBase from sling.testing.tools in
> > serversetup [2] in order to use those in the sling tests, using the
> > existing mechanism to start a new sling instance for tests, as part of
> the
> > maven build. It's used in the SlingInstanceRule [3] which I used to adapt
> > some sample tests like [4] (I didn't want to touch launchpad tests or
> > anything like that, but I'm willing to put in some work if needed). I see
> > Bertrand also adapted some tests there, in samples/ lately.
> >
> > That's mostly what we have, no wholesome documentation, unfortunately.
> Ah,
> > another helpful thing to have a look at is the unit tests for the
> clients,
> > like AbstractSlingClientGetUrlTest [5] which makes sure there are no
> > regressions in terms of how URIs are dealt with.
> >
> > HTH,
> > - Andrei
> >
> > ---
> > [0] https://github.com/apache/sling/tree/trunk/testing/junit/rules
> > [1] https://github.com/apache/sling/tree/trunk/testing/http/clients
> > [2]
> >
> https://github.com/apache/sling/blob/trunk/testing/serversetup/src/main/java/org/apache/sling/testing/serversetup/instance/SlingTestBase.java
> > [3]
> >
> https://github.com/apache/sling/blob/trunk/testing/junit/rules/src/main/java/org/apache/sling/testing/junit/rules/SlingInstanceRule.java
> > [4]
> >
> https://github.com/apache/sling/blob/b0debb458d0ac7098ded772412adc11163865d2c/testing/samples/bundle-with-it/src/test/java/org/apache/sling/testing/samples/bundlewit/OsgiConsoleHttpIT.java
> > [5]
> >
> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/AbstractSlingClientGetUrlTest.java
>
>

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> 
> 
> On 21.9.16 9:14 , Carsten Ziegeler wrote:
>>>
>>>
>>> On 21.9.16 8:50 , Carsten Ziegeler wrote:
>
>
> On 21.9.16 8:33 , Carsten Ziegeler wrote:
>>> Pushing filters as much into Oak has many performance advantages
>>> though
 compared to filter messages after delivery. Also Oak would easily
 able
 to support the delete use case described above.

>> In all cases, always, guaranteed?
>
> For some definition of "all cases, always, guaranteed": yes ;-)

 :) So there is no compaction, never?
>>>
>>> There isn't if you configure it that way. It's up to you.
>>>
>>> But this is completely irrelevant here. If compaction would cause events
>>> to get lost, there is nothing you could do about it in Sling. Regardless
>>> whether you implement an ad-hoc DYI filter in Sling or use Oak filters.
>>>
>> I agree.
>>
>> Just to clarify, if I delete "/libs/foo" I get oak observation events
>> for all nodes that where under /foo with the removed properties of each
>> node, right?
> 
> No, just for the root of the removed tree.
> 
> See
> https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=13911484=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13911484
> 
> 
ah..memories :)

ok, but that proves my point that glob filtering does not work for remove

Carsten

> ;-)
> 
> Michael
> 
>>
>> Carsten
>>
>>
>>
> 


 

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

[jira] [Updated] (SLING-6063) plumber servlet doesn't persist changes anymore

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6063:
---
Component/s: Extensions

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Pipes 1.0.0
>Reporter: Nicolas Peltier
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

[jira] [Updated] (SLING-6063) plumber servlet doesn't persist changes anymore

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6063:
---
Affects Version/s: Pipes 1.0.0

> plumber servlet doesn't persist changes anymore
> ---
>
> Key: SLING-6063
> URL: https://issues.apache.org/jira/browse/SLING-6063
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Pipes 1.0.0
>Reporter: Nicolas Peltier
> Attachments: SLING-6063.patch
>
>
> since the writer enhancement, plumber's commit had disappeared, resulting in 
> systematic unchanged resources



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

Re: [VOTE] Release Apache Sling Testing Clients 1.0.0, Apache Sling Server Setup Tools 1.0.0 and Apache Sling Testing Rules 1.0.0

[Konrad Windszus]

Hey Andrei, could you briefly mention those new bundles in 
https://sling.apache.org/documentation/development/sling-testing-tools.html 
and/or 
https://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html
 just to have the complete picture on those pages?

To me the difference to the Teleporter approach is not that obvious. Maybe you 
can write some sentences on when it is recommended to choose which approach.

Thanks,
Konrad

> Am 21.09.2016 um 10:11 schrieb Andrei Dulvac :
> 
> Hi Stefan.
> Thanks for the +1.
> On Tue, Sep 20, 2016 at 6:20 PM Stefan Seifert 
> wrote:
> 
>> +1
>> 
>> this is a lot of interesting stuff - do we already have some
>> documentation/sample project for this?
>> 
> We have some docu on the junit rules [0] - the entrypoint for writing a
> test, some docu on the clients [1] (the FAQ at the end also provides some
> insight into some design choices).
> 
> I've also adapted the old SlingTestBase from sling.testing.tools in
> serversetup [2] in order to use those in the sling tests, using the
> existing mechanism to start a new sling instance for tests, as part of the
> maven build. It's used in the SlingInstanceRule [3] which I used to adapt
> some sample tests like [4] (I didn't want to touch launchpad tests or
> anything like that, but I'm willing to put in some work if needed). I see
> Bertrand also adapted some tests there, in samples/ lately.
> 
> That's mostly what we have, no wholesome documentation, unfortunately. Ah,
> another helpful thing to have a look at is the unit tests for the clients,
> like AbstractSlingClientGetUrlTest [5] which makes sure there are no
> regressions in terms of how URIs are dealt with.
> 
> HTH,
> - Andrei
> 
> ---
> [0] https://github.com/apache/sling/tree/trunk/testing/junit/rules
> [1] https://github.com/apache/sling/tree/trunk/testing/http/clients
> [2]
> https://github.com/apache/sling/blob/trunk/testing/serversetup/src/main/java/org/apache/sling/testing/serversetup/instance/SlingTestBase.java
> [3]
> https://github.com/apache/sling/blob/trunk/testing/junit/rules/src/main/java/org/apache/sling/testing/junit/rules/SlingInstanceRule.java
> [4]
> https://github.com/apache/sling/blob/b0debb458d0ac7098ded772412adc11163865d2c/testing/samples/bundle-with-it/src/test/java/org/apache/sling/testing/samples/bundlewit/OsgiConsoleHttpIT.java
> [5]
> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/AbstractSlingClientGetUrlTest.java

Re: [VOTE] Release Apache Sling Testing Clients 1.0.0, Apache Sling Server Setup Tools 1.0.0 and Apache Sling Testing Rules 1.0.0

[Andrei Dulvac]

Hi Stefan.
Thanks for the +1.
On Tue, Sep 20, 2016 at 6:20 PM Stefan Seifert 
wrote:

> +1
>
> this is a lot of interesting stuff - do we already have some
> documentation/sample project for this?
>
We have some docu on the junit rules [0] - the entrypoint for writing a
test, some docu on the clients [1] (the FAQ at the end also provides some
insight into some design choices).

I've also adapted the old SlingTestBase from sling.testing.tools in
serversetup [2] in order to use those in the sling tests, using the
existing mechanism to start a new sling instance for tests, as part of the
maven build. It's used in the SlingInstanceRule [3] which I used to adapt
some sample tests like [4] (I didn't want to touch launchpad tests or
anything like that, but I'm willing to put in some work if needed). I see
Bertrand also adapted some tests there, in samples/ lately.

That's mostly what we have, no wholesome documentation, unfortunately. Ah,
another helpful thing to have a look at is the unit tests for the clients,
like AbstractSlingClientGetUrlTest [5] which makes sure there are no
regressions in terms of how URIs are dealt with.

HTH,
- Andrei

---
[0] https://github.com/apache/sling/tree/trunk/testing/junit/rules
[1] https://github.com/apache/sling/tree/trunk/testing/http/clients
[2]
https://github.com/apache/sling/blob/trunk/testing/serversetup/src/main/java/org/apache/sling/testing/serversetup/instance/SlingTestBase.java
[3]
https://github.com/apache/sling/blob/trunk/testing/junit/rules/src/main/java/org/apache/sling/testing/junit/rules/SlingInstanceRule.java
[4]
https://github.com/apache/sling/blob/b0debb458d0ac7098ded772412adc11163865d2c/testing/samples/bundle-with-it/src/test/java/org/apache/sling/testing/samples/bundlewit/OsgiConsoleHttpIT.java
[5]
https://github.com/apache/sling/blob/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/AbstractSlingClientGetUrlTest.java

Re: Observation with the ResourceChangeListener

[Michael Dürig]

On 21.9.16 9:14 , Carsten Ziegeler wrote:



On 21.9.16 8:50 , Carsten Ziegeler wrote:



On 21.9.16 8:33 , Carsten Ziegeler wrote:

Pushing filters as much into Oak has many performance advantages
though

compared to filter messages after delivery. Also Oak would easily
able
to support the delete use case described above.


In all cases, always, guaranteed?


For some definition of "all cases, always, guaranteed": yes ;-)


:) So there is no compaction, never?


There isn't if you configure it that way. It's up to you.

But this is completely irrelevant here. If compaction would cause events
to get lost, there is nothing you could do about it in Sling. Regardless
whether you implement an ad-hoc DYI filter in Sling or use Oak filters.


I agree.

Just to clarify, if I delete "/libs/foo" I get oak observation events
for all nodes that where under /foo with the removed properties of each
node, right?


No, just for the root of the removed tree.

See 
https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=13911484=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13911484


;-)

Michael



Carsten

RE: Observation with the ResourceChangeListener

[Stefan Seifert]

>But we have to think about other providers as well, what if I use the
>mongo resource provider? Can we make the same guarantees? We have an
>abstraction and have to come up with a solution that always works
>without exceptions.

when speaking oft he nosql resource providers based on the generic abstraction 
[1] - this is not possible today, but would be possible to implement in a 
generic way with only a little help from the implementations per nosql database.
but it would have a performance impact, because currently all resources in a 
subtree are removed using a pattern query, not caring how many with which 
properties.

but same as oak with compacting - with this implementation it would not be 
possible for the application listener to implement the filtering on their side, 
because only one delete event for the root node is sent.

stefan

[1] http://sling.apache.org/documentation/bundles/nosql-resource-providers.html

[jira] [Assigned] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-5995:
---

Assignee: Stefan Egli

[~egli] Could you please look into this one?

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Assigned] (SLING-5996) DistributedEventSender should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-5996:
---

Assignee: Carsten Ziegeler

> DistributedEventSender should move to new ResourceChangeListener API
> 
>
> Key: SLING-5996
> URL: https://issues.apache.org/jira/browse/SLING-5996
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
>
> org.apache.sling.event.dea.impl.DistributedEventSender currently implements 
> org.osgi.service.event.EventHandler Interface. We should start using the new 
> ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Commented] (SLING-6000) MapEntries should move to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6000:
-

This is a tricky one as it is listening to changes about properties in the 
whole tree. I started a discussion thread in the dev list

> MapEntries should move to new ResourceChangeListener API  
> -
>
> Key: SLING-6000
> URL: https://issues.apache.org/jira/browse/SLING-6000
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Reporter: Hanish Bansal
>
> org.apache.sling.resourceresolver.impl.mapping.MapEntries currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> 
> 
> On 21.9.16 8:50 , Carsten Ziegeler wrote:
>>>
>>>
>>> On 21.9.16 8:33 , Carsten Ziegeler wrote:
> Pushing filters as much into Oak has many performance advantages
> though
>> compared to filter messages after delivery. Also Oak would easily
>> able
>> to support the delete use case described above.
>>
 In all cases, always, guaranteed?
>>>
>>> For some definition of "all cases, always, guaranteed": yes ;-)
>>
>> :) So there is no compaction, never?
> 
> There isn't if you configure it that way. It's up to you.
> 
> But this is completely irrelevant here. If compaction would cause events
> to get lost, there is nothing you could do about it in Sling. Regardless
> whether you implement an ad-hoc DYI filter in Sling or use Oak filters.
> 
I agree.

Just to clarify, if I delete "/libs/foo" I get oak observation events
for all nodes that where under /foo with the removed properties of each
node, right?

Carsten

 

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

Re: Observation with the ResourceChangeListener

[Michael Dürig]

On 21.9.16 8:50 , Carsten Ziegeler wrote:



On 21.9.16 8:33 , Carsten Ziegeler wrote:

Pushing filters as much into Oak has many performance advantages though

compared to filter messages after delivery. Also Oak would easily able
to support the delete use case described above.


In all cases, always, guaranteed?


For some definition of "all cases, always, guaranteed": yes ;-)


:) So there is no compaction, never?


There isn't if you configure it that way. It's up to you.

But this is completely irrelevant here. If compaction would cause events 
to get lost, there is nothing you could do about it in Sling. Regardless 
whether you implement an ad-hoc DYI filter in Sling or use Oak filters.


Michael




Carsten



Obviously I'm only speaking for Oak here. Meaning, if you want to cover
deletes in the way described Oak would support that. Obviously there is
nothing Oak can do if other resource providers can't cover the delete
case. At this point it is - as you say - up to Sling to define how to
deal with it at a higher level of abstraction.

Michael

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> 
> 
> On 21.9.16 8:33 , Carsten Ziegeler wrote:
>>> Pushing filters as much into Oak has many performance advantages though
>>> > compared to filter messages after delivery. Also Oak would easily able
>>> > to support the delete use case described above.
>>> >
>> In all cases, always, guaranteed?
> 
> For some definition of "all cases, always, guaranteed": yes ;-)

:) So there is no compaction, never?

Carsten

> 
> Obviously I'm only speaking for Oak here. Meaning, if you want to cover
> deletes in the way described Oak would support that. Obviously there is
> nothing Oak can do if other resource providers can't cover the delete
> case. At this point it is - as you say - up to Sling to define how to
> deal with it at a higher level of abstraction.
> 
> Michael
> 
> 


 

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

Sling JMS Based Job Support - Difference between queue name and job type

[Chetan Mehrotra]

I was looking at the Sling JMS based Job SLING-5645 and trying to
understand the api flow.

Sender side submits a job for a given queue and job type

--
Job job = jobManager.newJobBuilder(Types.jobQueue(TOPIC),
Types.jobType(AsyncJobConsumer.JOB_TYPE)).addProperties(
ImmutableMap.of("jobtest", (Object) "jobtest")).add();
--

While on consumer side we specify only job type

---
@Component(immediate = true)
@Properties({
@Property(name = JobConsumer.JOB_TYPES, cardinality =
Integer.MAX_VALUE, value = {
AsyncJobConsumer.JOB_TYPE
})
})
@Service(value = JobConsumer.class)
public class AsyncJobConsumer implements JobConsumer
---

So whats the purpose of queue name here?

Chetan Mehrotra

Re: Observation with the ResourceChangeListener

[Michael Dürig]

On 21.9.16 8:33 , Carsten Ziegeler wrote:

Pushing filters as much into Oak has many performance advantages though
> compared to filter messages after delivery. Also Oak would easily able
> to support the delete use case described above.
>

In all cases, always, guaranteed?


For some definition of "all cases, always, guaranteed": yes ;-)

Obviously I'm only speaking for Oak here. Meaning, if you want to cover 
deletes in the way described Oak would support that. Obviously there is 
nothing Oak can do if other resource providers can't cover the delete 
case. At this point it is - as you say - up to Sling to define how to 
deal with it at a higher level of abstraction.


Michael

Re: Observation with the ResourceChangeListener

[Carsten Ziegeler]

> 
> 
> On 21.9.16 8:13 , Carsten Ziegeler wrote:
>> Finally, recently some people suggested that we support all of Oaks
>> filtering possibilities for the ResourceChangeListener. I'm not a fan of
>> that - first of all, we should only support what is really needed.
>> Second, as soon as we support it, it means that every resource provider
>> needs to support it which might but a high burden for nothing on the
>> implementations. And finally, as we already see with the globbing,
>> filtering is nice but we have to be careful for remove events and
>> clearly specifiy how this works - and specify it in a way that it really
>> works for the listeners.
> 
> Not so recently actually: http://markmail.org/message/zmwhp7a7tshtfvob

Well, it has been added to Sling recently :)

> 
> I don't think you have to support all of Oak's filtering possibilities.
> You can still just use the ones you need. Mind you that Oak also has
> support for glob filters.
Sure, that's what we do.

> Pushing filters as much into Oak has many performance advantages though
> compared to filter messages after delivery. Also Oak would easily able
> to support the delete use case described above.
> 

In all cases, always, guaranteed?

But we have to think about other providers as well, what if I use the
mongo resource provider? Can we make the same guarantees? We have an
abstraction and have to come up with a solution that always works
without exceptions.

Carsten

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

Re: Observation with the ResourceChangeListener

[Michael Dürig]

On 21.9.16 8:13 , Carsten Ziegeler wrote:

Finally, recently some people suggested that we support all of Oaks
filtering possibilities for the ResourceChangeListener. I'm not a fan of
that - first of all, we should only support what is really needed.
Second, as soon as we support it, it means that every resource provider
needs to support it which might but a high burden for nothing on the
implementations. And finally, as we already see with the globbing,
filtering is nice but we have to be careful for remove events and
clearly specifiy how this works - and specify it in a way that it really
works for the listeners.


Not so recently actually: http://markmail.org/message/zmwhp7a7tshtfvob

I don't think you have to support all of Oak's filtering possibilities. 
You can still just use the ones you need. Mind you that Oak also has 
support for glob filters.
Pushing filters as much into Oak has many performance advantages though 
compared to filter messages after delivery. Also Oak would easily able 
to support the delete use case described above.


Michael

Re: [i18n] IT Tests failing in reactor build

[Carsten Ziegeler]

It seems the problem on Jenkins was related to the latest failsafe
plugin, 2.19.1 - I ran into the exact same problem yesterday while
updating the event IT tests to Oak. Downgrading to 2.18.1 solved the
problem. So I downgraded i18n to use that version as well and now it
seems that the project is built fine on Jenkins as well.


 Carsten

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

Observation with the ResourceChangeListener

[Carsten Ziegeler]

Hi,

as you know we're currently in the process of moving away from the OSGi
event based observation to the ResourceChangeListener interfaces. Main
reason is moving to a more scalable/better performing solution.

We started very simple with the ResourceChangeListener: listeners
register themselves with the three where they are interested in changes.
They can also specify whether they are interested in adds, removes,
and/or updates. This is basic functionality.

Recently, support for a glob pattern was added, for example scripting
engines like jsp are only interested in changes of "*.jsp" files. While
this sounds like a great idea, this only works reliable for adds and
updates. However it does not work for removes, if e.g. only the parent
resource of a jsp (or any parent) is removed, then usually you only get
a resource removal event for that parent. As the listener is registered
with the *.jsp pattern and the parent name usually does not match this,
the listener does not get this event at all.

I guess a good compromise would be to do the filtering for add and
update but send all remove events for the relevant tree to the listener.

For resource mapping we currently register a listener that listens to
all events that deal with certain properties. So if a specific property
is added, removed, or updated this listener should be triggered. Again
for add and update this might be solvable, but for a delete it is not.
Furthermore the information about properties for a change event is
currently specified as optional, so the listener can't rely that this
information is send. And I don't think that it makes sense to send this
information for each and every event we have, as usually listeners do
not care about specific properties.

I tend to move this special filtering to the listener. However this
leaves us still with the problem that the listener is mounted at /. I
think we should narrow down the support for resource mappings to
specific paths. We can make this configurable of course.

Finally, recently some people suggested that we support all of Oaks
filtering possibilities for the ResourceChangeListener. I'm not a fan of
that - first of all, we should only support what is really needed.
Second, as soon as we support it, it means that every resource provider
needs to support it which might but a high burden for nothing on the
implementations. And finally, as we already see with the globbing,
filtering is nice but we have to be careful for remove events and
clearly specifiy how this works - and specify it in a way that it really
works for the listeners.

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

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6056:
-

I think this is a separate issue and we have to be careful here as Oak is only 
one resource provider. I'll start a discussion on the mailing list

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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