[jira] [Commented] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-3203:
--

Looks good to me. A request to /tmp/test.other/nothing doesn't really make 
sense in the first place if the (full) path does not exist.

Does the same issue apply to these cases?
- a DELETE request (don't know if that shares use of the DeleteOperation)
- a request using a @Delete addressing the local node (not sure if that works):
{code}
POST /tmp/test.other/nothing
with param: ".@Delete" = "true"
{code}
- (are these all ways to delete something?)

Also could the same issue be present for other operations such as move, copy 
etc.?


> Post servlet's delete operation deletes parent of nonexisting node
> --
>
> Key: SLING-3203
> URL: https://issues.apache.org/jira/browse/SLING-3203
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.2
>Reporter: Bertrand Delacretaz
> Attachments: SLING-3203.patch
>
>
> In the below scenario, /tmp/test is gone after the delete operation - the 
> resource resolver goes up the path of the nonexisting node, and it's 
> /tmp/test that's provided to the DeleteOperation.
> I think we should change this (maybe with a backwards compatibility switch), 
> as it's clear that the user's intention in this case is not to delete 
> /tmp/test. Maybe just reject :delete operations if the request has any 
> selector or extensions.
> curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
> curl -u admin:admin -F:operation=delete 
> http://localhost:8080/tmp/test.other/nothing
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: sling-trunk-1.7 #377

[Apache Jenkins Server]

See 

Changes:

[bdelacretaz] SLING-3155 - define run modes for this module

[bdelacretaz] SLING-3155 - more precise repository name check

--
[...truncated 16504 lines...]
Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Reactor Summary:
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JAR Resource Bundle .. SUCCESS [19.439s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling (Parent) . SUCCESS [12.577s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Adapter Annotations . SUCCESS [18.606s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin to create Jackrabbit OCM descriptors  SUCCESS 
[14.841s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Compiling JSP Sources into Bundles  SUCCESS 
[18.466s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Supporting Bundle Development  SUCCESS 
[14.767s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Launchpad Maven Plugin ... SUCCESS [33.497s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Standalone Archetype .. SUCCESS [19.998s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Webapp Archetype .. SUCCESS [17.708s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Initial Content Archetype ... SUCCESS [16.933s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Servlet Archetype ... SUCCESS [17.859s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Bundle Archetype  SUCCESS [13.036s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling JCRInstall Bundle Archetype . SUCCESS [25.385s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Taglib Archetype  SUCCESS [12.273s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling API .. SUCCESS [22.304s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Service User Mapper .. SUCCESS [14.894s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Resource Resolver  SUCCESS [28.991s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[16.986s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: XML APIs  SUCCESS [19.938s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Activation API  SUCCESS [12.105s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: WS APIs . SUCCESS [13.111s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Dynamic Class Loader Support . SUCCESS [18.826s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JSON Library . SUCCESS [14.039s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling SLF4J Implementation (Logback) ... SUCCESS [1:02.351s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling OSGi LogService Implementation ... SUCCESS [13.571s]
Oct 23, 2013 6:04:38 PM org.apache.maven.cli.event.Executi

Jenkins build became unstable: sling-oak-it-1.6 #2

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-oak-it-1.6 » Apache Sling Launchpad Testing #2

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.6 #2011

[Apache Jenkins Server]

See 

Changes:

[bdelacretaz] SLING-3155 - define run modes for this module

[bdelacretaz] SLING-3155 - more precise repository name check

--
[...truncated 14318 lines...]
INFO: 
Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
org.apache.sling.scripting.core ---
[INFO] Checking legal files in: 
org.apache.sling.scripting.core-2.0.25-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.scripting.core-2.0.25-SNAPSHOT-sources.jar
Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-failsafe-plugin:2.12.4:verify (default) @ 
org.apache.sling.scripting.core ---
[INFO] Failsafe report directory: 

[WARNING] File encoding has not been set, using platform encoding 
ANSI_X3.4-1968, i.e. build is platform dependent!
[JENKINS] Recording test resultsOct 23, 2013 3:33:32 PM 
org.apache.maven.cli.event.ExecutionEventLogger mojoStarted
INFO: 
Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-install-plugin:2.3.1:install (default-install) @ 
org.apache.sling.scripting.core ---
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.scripting.core/2.0.25-SNAPSHOT/org.apache.sling.scripting.core-2.0.25-SNAPSHOT.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.scripting.core/2.0.25-SNAPSHOT/org.apache.sling.scripting.core-2.0.25-SNAPSHOT.pom
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.scripting.core/2.0.25-SNAPSHOT/org.apache.sling.scripting.core-2.0.25-SNAPSHOT-sources.jar

Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:32 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-bundle-plugin:2.4.0:install (default-install) @ 
org.apache.sling.scripting.core ---
[INFO] Local OBR update disabled (enable with -DobrRepository)
Oct 23, 2013 3:33:52 PM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 23, 2013 3:33:52 PM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 23, 2013 3:33:52 PM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: Building Apache Sling Scripting JavaScript Support 2.0.13-SNAPSHOT
Oct 23, 2013 3:33:52 PM org.apache.maven.cli.event.ExecutionEventLogger 
projectStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-clean-plugin:2.5:clean (default-clean) @ 
org.apache.sling.scripting.javascript ---
[INFO] Deleting 

Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ 
org.apache.sling.scripting.javascript ---
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-antrun-plugin:1.7:run 
(set-bundle-required-execution-environment) @ 
org.apache.sling.scripting.javascript ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-remote-resources-plugin:1.4:process (default) @ 
org.apache.sling.scripting.javascript ---
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: 
Oct 23, 2013 3:33:53 PM org.apache.maven.cli.event.ExecutionEventLogger 
mojoStarted
INFO: --- maven-resources-plugin:2.6:resources (default-resource

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

On Wed, Oct 23, 2013 at 4:42 PM, Dominik Süß  wrote:
> ...Regarding the options you were stating:
> - service properties: my initial thought, but static and can therefore not
> adress all scenarios...

Service properties for a given service are static, but a service that
has specific properties can come and go.

IMO we need to work on concrete use cases to decide on the best option.

-Bertrand

Is maven-launchpad-plugin:run supposed to support run modes?

[Bertrand Delacretaz]

Hi,

This is not working in launchpad/testing so far, if I start with "mvn
clean launchpad:run" all bundles are installed, from both jackrabbit
and oak run modes, although the run mode is correctly set to
"jackrabbit". Starting the standalone jar from launchpad/builder works
fine.

AFAICS the build is using the correct bundles list from
launchpad/builder which includes .

I tried adding these options to maven-launchpad-plugin but that doesn't help:

  install
  bundles

Before I dig deeper, is this supposed to work?

-Bertrand

Re: Scalabilty of EventListener

[Dominik Süß]

Hi Bertrand,

I'm not so sure about the seldom changes - it is not about the amound of
changes but about the amount of changes in a specific timeframe. The
initial discussion started with the asumtion to have to deal with tons of
changes within a second, e.g. for huge imports.  In some cases those
imports are real imports (so new creation) so postponing the processing and
delegating to some postprocessing might work - but in case of updates this
is not so easy (and I know such cases from the automotive area where masses
of technical data is synched to all markets).

Regarding the options you were stating:
- service properties: my initial thought, but static and can therefore not
adress all scenarios
- registring for certain types: same problem, a bit more possibilities but
restricted to the capabilities of the registry

Therefore I thought of a filterlike behavior where the listeners can
implement their own logic. Including measuring the time such a call takes
and having a healthcheck announcing such a logic not to be performing well
would be a good way to give developers the tooling to identify where they
lose performance in this area.

---
Dominik


On Wed, Oct 23, 2013 at 4:19 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Wed, Oct 23, 2013 at 4:01 PM, Dominik Süß 
> wrote:
> > ...This might not apply to the whole
> > tree, but does this really matter when the tree that needs to be watched
> > contains over 90% of the data?...
>
> What's important is the frequency of observation events - if that 90%
> seldom changes, scaling won't be a problem.
>
> > ...If I got the problem right the overhead is created by the fact that an
> > event object is created and sent regardles if a consumer cares about it
> or
> > not. So it might be worth to add something that "asks" the listeners if
> > there is one that would consume this event...
>
> That's what I meant above:
>
> > ...A simple way of making our wide observation more specific is to
> > require users of our rebroadcast OSGi events to indicate more
> > specifically what they're interested in...
>
> There's various ways of doing that: service properties, calling a
> service to register your interest in certain types of events etc.
>
> -Bertrand
>

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

Hi,

On Wed, Oct 23, 2013 at 4:01 PM, Dominik Süß  wrote:
> ...This might not apply to the whole
> tree, but does this really matter when the tree that needs to be watched
> contains over 90% of the data?...

What's important is the frequency of observation events - if that 90%
seldom changes, scaling won't be a problem.

> ...If I got the problem right the overhead is created by the fact that an
> event object is created and sent regardles if a consumer cares about it or
> not. So it might be worth to add something that "asks" the listeners if
> there is one that would consume this event...

That's what I meant above:

> ...A simple way of making our wide observation more specific is to
> require users of our rebroadcast OSGi events to indicate more
> specifically what they're interested in...

There's various ways of doing that: service properties, calling a
service to register your interest in certain types of events etc.

-Bertrand

Re: Scalabilty of EventListener

[Dominik Süß]

The analysis looks pretty good to me but does not provide answers of how to
solve this. The first two topics "Cached Content" and "Content Export,
Replication to Remote Systems" are the ones where I don't see an option to
get rid of the content change triggers. This might not apply to the whole
tree, but does this really matter when the tree that needs to be watched
contains over 90% of the data?

If I got the problem right the overhead is created by the fact that an
event object is created and sent regardles if a consumer cares about it or
not. So it might be worth to add something that "asks" the listeners if
there is one that would consume this event and (something like an
"accepts()" Method handing over raw metadata without generating the event
object itself - more like a filter) and send the event then to be consumed
by this and potential other consumers.

Or did i get something completely wrong?

Cheers
Dominik


On Wed, Oct 23, 2013 at 2:30 PM, Bertrand Delacretaz  wrote:

> On Wed, Oct 23, 2013 at 2:10 PM, Carsten Ziegeler 
> wrote:
> > So far, I heard that the global listener which translates jcr events
> into
> > OSGi events is a problem - however as far as I followed the discussion,
> > this isn't a problem right now but might lead to problems in some time if
> > huge Oak based clustered repositories are used...
>
> Agreed.
>
> > ...In the same category fall the global listeners we have in the resource
> > resolver for the mapping and the i18n one..
> > Is there more?...
>
> I looked at an analysis the we did earlier this year on our
> Sling-based app and I don't have more than that.
>
> -Bertrand
>

Delete via post servlet - reject requests that have selectors, extension or a suffix?

[Bertrand Delacretaz]

Hi,

See SLING-3203, I'm suggesting a patch that does this to avoid
deleting the parent node of non-existent nodes in some cases.

This causes the :delete post servlet operation to work slightly
differently than before.

Assuming we want to implement this, do we need to make it switchable
for backwards compatibility? Such requests make no sense in general,
so I'd at least enable it by default, but there might be edge cases.

-Bertrand

Re: JARs in SVN

[Felix Meschberger]

Thanks
Regards
Felix

Am 23.10.2013 um 13:29 schrieb Robert Munteanu:

> On Wed, Oct 23, 2013 at 11:05 AM, Stefan Egli  wrote:
>> Afaik this was necessary due to a snapshot dependency on vault while it
>> was not yet released.
>> 
>> @Robert, we could get rid of this now, right?
> 
> Yes, it should be possible. IIRC at the time I needed that setup for a
> smooth import into Eclipse.
> 
> SLING-3204: Remove all jars from SVN
> https://issues.apache.org/jira/browse/SLING-3204
> 
> Robert
> 
>> 
>> Cheers,
>> Stefan
>> 
>> On 10/23/13 1:29 AM, "Felix Meschberger"  wrote:
>> 
>>> Hi
>>> 
>>> I just realized that the tooling/ide/vlt-wrapper project stores libraries
>>> in SVN. I think this is not a good idea (read it is a bad idea). I
>>> suggest these JARs to be removed from SVN and build tooling to be used to
>>> get them form Maven Repositories.
>>> 
>>> Thanks
>>> Felix
>> 



smime.p7s
Description: S/MIME cryptographic signature

[jira] [Updated] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-3203:
---

Attachment: SLING-3203.patch

Suggested patch - causes the above scenario to return a 400 BAD REQUEST status 
for any :delete operation that has selectors, extension or a suffix.

> Post servlet's delete operation deletes parent of nonexisting node
> --
>
> Key: SLING-3203
> URL: https://issues.apache.org/jira/browse/SLING-3203
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.2
>Reporter: Bertrand Delacretaz
> Attachments: SLING-3203.patch
>
>
> In the below scenario, /tmp/test is gone after the delete operation - the 
> resource resolver goes up the path of the nonexisting node, and it's 
> /tmp/test that's provided to the DeleteOperation.
> I think we should change this (maybe with a backwards compatibility switch), 
> as it's clear that the user's intention in this case is not to delete 
> /tmp/test. Maybe just reject :delete operations if the request has any 
> selector or extensions.
> curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
> curl -u admin:admin -F:operation=delete 
> http://localhost:8080/tmp/test.other/nothing
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

On Wed, Oct 23, 2013 at 2:10 PM, Carsten Ziegeler  wrote:
> So far, I heard that the global listener which translates jcr events into
> OSGi events is a problem - however as far as I followed the discussion,
> this isn't a problem right now but might lead to problems in some time if
> huge Oak based clustered repositories are used...

Agreed.

> ...In the same category fall the global listeners we have in the resource
> resolver for the mapping and the i18n one..
> Is there more?...

I looked at an analysis the we did earlier this year on our
Sling-based app and I don't have more than that.

-Bertrand

[jira] [Created] (SLING-3204) Remove all jars from SVN

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-3204:
--

 Summary: Remove all jars from SVN
 Key: SLING-3204
 URL: https://issues.apache.org/jira/browse/SLING-3204
 Project: Sling
  Issue Type: Task
  Components: IDE
Reporter: Robert Munteanu
 Fix For: Sling Eclipse IDE 1.0.0


Some jars are still checked in SVN and must be removed and brought in via Maven 
whenever needed.

See http://markmail.org/thread/3xi5j7ba7iqirb7c



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: JARs in SVN

[Robert Munteanu]

On Wed, Oct 23, 2013 at 11:05 AM, Stefan Egli  wrote:
> Afaik this was necessary due to a snapshot dependency on vault while it
> was not yet released.
>
> @Robert, we could get rid of this now, right?

Yes, it should be possible. IIRC at the time I needed that setup for a
smooth import into Eclipse.

SLING-3204: Remove all jars from SVN
https://issues.apache.org/jira/browse/SLING-3204

Robert

>
> Cheers,
> Stefan
>
> On 10/23/13 1:29 AM, "Felix Meschberger"  wrote:
>
>>Hi
>>
>>I just realized that the tooling/ide/vlt-wrapper project stores libraries
>>in SVN. I think this is not a good idea (read it is a bad idea). I
>>suggest these JARs to be removed from SVN and build tooling to be used to
>>get them form Maven Repositories.
>>
>>Thanks
>>Felix
>

[jira] [Updated] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-3203:
---

Summary: Post servlet's delete operation deletes parent of nonexisting node 
 (was: Post servlet's :delete operation deletes parent of nonexisting node)

> Post servlet's delete operation deletes parent of nonexisting node
> --
>
> Key: SLING-3203
> URL: https://issues.apache.org/jira/browse/SLING-3203
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.2
>Reporter: Bertrand Delacretaz
>
> In the below scenario, /tmp/test is gone after the delete operation - the 
> resource resolver goes up the path of the nonexisting node, and it's 
> /tmp/test that's provided to the DeleteOperation.
> I think we should change this (maybe with a backwards compatibility switch), 
> as it's clear that the user's intention in this case is not to delete 
> /tmp/test. Maybe just reject :delete operations if the request has any 
> selector or extensions.
> curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
> curl -u admin:admin -F:operation=delete 
> http://localhost:8080/tmp/test.other/nothing
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3203) Post servlet's :delete operation deletes parent of nonexisting node

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3203:
--

 Summary: Post servlet's :delete operation deletes parent of 
nonexisting node
 Key: SLING-3203
 URL: https://issues.apache.org/jira/browse/SLING-3203
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Post 2.3.2
Reporter: Bertrand Delacretaz


In the below scenario, /tmp/test is gone after the delete operation - the 
resource resolver goes up the path of the nonexisting node, and it's /tmp/test 
that's provided to the DeleteOperation.

I think we should change this (maybe with a backwards compatibility switch), as 
it's clear that the user's intention in this case is not to delete /tmp/test. 
Maybe just reject :delete operations if the request has any selector or 
extensions.

curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
curl -u admin:admin -F:operation=delete 
http://localhost:8080/tmp/test.other/nothing
curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Scalabilty of EventListener

[Carsten Ziegeler]

Ok, so I suggest we identify these parts then first concretely before we
speculate that there is a problem and replace it with something where we
don't know the real impact.

So far, I heard that the global listener which translates jcr events into
OSGi events is a problem - however as far as I followed the discussion,
this isn't a problem right now but might lead to problems in some time if
huge Oak based clustered repositories are used. But we don't have concrete
numbers yet, so we could only fix this in a theoretical level.
In the same category fall the global listeners we have in the resource
resolver for the mapping and the i18n one.

Is there more?

Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-2986) Merged Resource Provider

[Gilles Knobloch (JIRA)]

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

Gilles Knobloch commented on SLING-2986:


[~cziegeler], just realized I didn't answer your first questions.

On why introducting a new API:
* Where I am using it (outside of that package), I need to know if the resource 
is a "real" resource or a merged one, reason for 
{{org.apache.sling.resourcemerger.api.MergedResource}}
* The constants of 
{{org.apache.sling.resourcemerger.api.MergedResourceConstants}} could stay 
private. On the other hand, people overriding resources anyway need to know 
which properties to use to achieve it, so why hiding them?
* The service is aimed to be extended and available through OSGi references in 
JSPs, other classes, etc.

Could we at least agree on the main concepts?
# How to add/override a property
** Create the corresponding property within {{/apps}} (the property will have 
priority based on Sling Resource Resolver configuration)
** Changing the type of the property is supported
# How to delete one or more properties
** Create the corresponding node within {{/apps}}, and set 
{{sling:hideProperties}} to the list of properties to delete ({{String[]}})
** {{*}} can be used to delete all the properties
# How to delete a node (and its children)
** Create the corresponding node within {{/apps}}, and set 
{{sling:hideResource}} to {{true}} ({{Boolean}})
# How to delete children of a node (but keep the properties of the node)
** Create the corresponding node within {{/apps}}, and set 
{{sling:hideChildren}} to {{true}} ({{Boolean}})
# How to reorder nodes
** Create the corresponding node within {{/apps}}, and set 
{{sling:orderBefore}} to the name of the sibling where that node should be 
reordered before ({{String}})
** TODO: support redefining the whole list of children

> Merged Resource Provider
> 
>
> Key: SLING-2986
> URL: https://issues.apache.org/jira/browse/SLING-2986
> Project: Sling
>  Issue Type: New Feature
>  Components: ResourceResolver
>Reporter: Gilles Knobloch
>
> As exchanged once with Felix Meschberger, the idea is to implement a custom 
> resource provider, with ability to merge multiple resources based on your 
> search paths.
> For instance, if your search paths are
> /apps
> /libs
> Hitting /merge/my/resource/is/here will check
> /apps/my/resource/is/here
> /libs/my/resource/is/here
> There are some options like:
> - add/override property
> - delete a property of the resource under /libs
> - reorder nodes if available
> I intend to submit this patch as soon as possible.
> Code is currently located at https://github.com/gknob/sling-resourcemerger



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

On Wed, Oct 23, 2013 at 1:37 PM, Carsten Ziegeler  wrote:
> ...I get this with global observation, but we're now talking about observation
> usage patterns and replacing them with queries. And these usage patterns
> are usually only observing partial parts of the repository

I'm not saying we need to get rid of all observation, but to make sure
Sling itself does not limit scalability we might need to change parts
of our code to use alternatives, or at least make alternatives
possible.

-Bertrand

Build failed in Jenkins: sling-trunk-1.6 #2010

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-3200 : Avoid duplicated requests to mbeans when creating 
resources

[cziegeler] SLING-3200 : Avoid duplicated requests to mbeans when creating 
resources

--
[...truncated 16684 lines...]
Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Reactor Summary:
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JAR Resource Bundle .. SUCCESS [18.145s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling (Parent) . SUCCESS [22.364s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Adapter Annotations . SUCCESS [20.071s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin to create Jackrabbit OCM descriptors  SUCCESS 
[18.526s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Compiling JSP Sources into Bundles  SUCCESS 
[25.132s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Supporting Bundle Development  SUCCESS 
[17.937s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Launchpad Maven Plugin ... SUCCESS [24.900s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Standalone Archetype .. SUCCESS [17.032s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Webapp Archetype .. SUCCESS [15.743s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Initial Content Archetype ... SUCCESS [13.578s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Servlet Archetype ... SUCCESS [21.833s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Bundle Archetype  SUCCESS [15.285s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling JCRInstall Bundle Archetype . SUCCESS [15.791s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Taglib Archetype  SUCCESS [15.391s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling API .. SUCCESS [19.299s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Service User Mapper .. SUCCESS [11.666s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Resource Resolver  SUCCESS [18.049s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[15.805s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: XML APIs  SUCCESS [16.178s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Activation API  SUCCESS [23.146s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: WS APIs . SUCCESS [41.262s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Dynamic Class Loader Support . SUCCESS [27.883s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JSON Library . SUCCESS [16.622s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling SLF4J Implementation (Logback) ... SUCCESS [1:24.725s]
Oct 23, 2013 11:39:44 AM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling OSGi LogService Implementation .

Re: Scalabilty of EventListener

[Carsten Ziegeler]

I get this with global observation, but we're now talking about observation
usage patterns and replacing them with queries. And these usage patterns
are usually only observing partial parts of the repository.

Carsten


2013/10/23 Ian Boston 

> On 23 October 2013 11:25, Carsten Ziegeler  wrote:
> > So you mean instead of doing observation, doing a query periodically?
> > This would mean that we basically say, one of the main features of JCR,
> > observation, is not usable.
>
> Past experience says that global observation of all changes in a
> cluster is not usable, and is best replaced by application specific
> messaging over a channel designed to scale.
>
> JCR Observation works just fine in the same memory space but beyond
> that it is far too noisy for a repository performing write operations.
>
> Ian
>
>
> >
> > Carsten
> >
> >
> > 2013/10/23 Bertrand Delacretaz 
> >
> >> Hi,
> >>
> >> On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler  >
> >> wrote:
> >> > ...The mapping handler in the resource resolver is probably the most
> >> > interesting one as it changes for nodes with some well defined
> >> properties,
> >> > basically scanning the whole repository...
> >>
> >> This is one example where latency is not a problem, so periodic
> >> queries could be used instead of observation if that's more scalable.
> >> We're basically interested in whether anything changed in the results
> >> of a query since we last ran it, a pattern which might be optimized in
> >> Oak by taking advantage of the underlying MVCC storage.
> >>
> >> -Bertrand
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: Scalabilty of EventListener

[Ian Boston]

On 23 October 2013 11:25, Carsten Ziegeler  wrote:
> So you mean instead of doing observation, doing a query periodically?
> This would mean that we basically say, one of the main features of JCR,
> observation, is not usable.

Past experience says that global observation of all changes in a
cluster is not usable, and is best replaced by application specific
messaging over a channel designed to scale.

JCR Observation works just fine in the same memory space but beyond
that it is far too noisy for a repository performing write operations.

Ian


>
> Carsten
>
>
> 2013/10/23 Bertrand Delacretaz 
>
>> Hi,
>>
>> On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler 
>> wrote:
>> > ...The mapping handler in the resource resolver is probably the most
>> > interesting one as it changes for nodes with some well defined
>> properties,
>> > basically scanning the whole repository...
>>
>> This is one example where latency is not a problem, so periodic
>> queries could be used instead of observation if that's more scalable.
>> We're basically interested in whether anything changed in the results
>> of a query since we last ran it, a pattern which might be optimized in
>> Oak by taking advantage of the underlying MVCC storage.
>>
>> -Bertrand
>>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org

Re: Scalabilty of EventListener

[Carsten Ziegeler]

So you mean instead of doing observation, doing a query periodically?
This would mean that we basically say, one of the main features of JCR,
observation, is not usable.

Carsten


2013/10/23 Bertrand Delacretaz 

> Hi,
>
> On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler 
> wrote:
> > ...The mapping handler in the resource resolver is probably the most
> > interesting one as it changes for nodes with some well defined
> properties,
> > basically scanning the whole repository...
>
> This is one example where latency is not a problem, so periodic
> queries could be used instead of observation if that's more scalable.
> We're basically interested in whether anything changed in the results
> of a query since we last ran it, a pattern which might be optimized in
> Oak by taking advantage of the underlying MVCC storage.
>
> -Bertrand
>



-- 
Carsten Ziegeler
cziege...@apache.org

Build failed in Jenkins: sling-trunk-1.7 #376

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-3200 : Avoid duplicated requests to mbeans when creating 
resources

[cziegeler] SLING-3200 : Avoid duplicated requests to mbeans when creating 
resources

--
[...truncated 39814 lines...]
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-7-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-7-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT.pom
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT-bundlelist.xml
[INFO] Deleting 

[INFO] Deleting 
 
(includes = [derby.log, cachedir, sling, jackrabbit], excludes = [])
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] Using bundle list file from 

[INFO] Merging partial bundle list 
org.apache.sling:org.apache.sling.launchpad.test-bundles:0.0.1-SNAPSHOT
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/org.apache.sling.launchpad.test-bundles-0.0.1-SNAPSHOT-bundlelistconfig.zip
[INFO] Copying base artifact from 

 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4.jar
 to 

[INFO] Copying bundle from 

 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.commons.logservice/1.0.2/org.apache.sling.commons.logservice-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/jcl-over-slf4j/1.6.4/jcl-over-slf4j-1.6.4.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/log4j-over-slf4j/1.6.4/log4j-over-slf4j-1.6.4.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.settings/1.3.0/org.apache.sling.settings-1.3.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.fragment.xml/1.0.2/org.apache.sling.fragment.xml-1.0.2.jar
 to 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #376

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #376

[Apache Jenkins Server]

See 


--
[INFO] Deleting 

[INFO] Deleting 

 (includes = [derby.log, cachedir, sling, jackrabbit], excludes = [])
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] Using bundle list file from 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.7/trunk/launchpad/builder/target/bundleList.xml
[INFO] Merging partial bundle list 
org.apache.sling:org.apache.sling.launchpad.test-bundles:0.0.1-SNAPSHOT
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/org.apache.sling.launchpad.test-bundles-0.0.1-SNAPSHOT-bundlelistconfig.zip
[INFO] Copying base artifact from 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.7/trunk/launchpad/base/target/org.apache.sling.launchpad.base-2.5.1-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.7/trunk/bundles/commons/log/target/org.apache.sling.commons.log-3.0.3-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.commons.logservice/1.0.2/org.apache.sling.commons.logservice-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/jcl-over-slf4j/1.6.4/jcl-over-slf4j-1.6.4.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/slf4j/log4j-over-slf4j/1.6.4/log4j-over-slf4j-1.6.4.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.settings/1.3.0/org.apache.sling.settings-1.3.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.fragment.xml/1.0.2/org.apache.sling.fragment.xml-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.fragment.transaction/1.0.0/org.apache.sling.fragment.transaction-1.0.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.javax.activation/0.1.0/org.apache.sling.javax.activation-0.1.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.fragment.ws/1.0.2/org.apache.sling.fragment.ws-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/sling/org.apache.sling.launchpad.

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

Hi,

On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler  wrote:
> ...The mapping handler in the resource resolver is probably the most
> interesting one as it changes for nodes with some well defined properties,
> basically scanning the whole repository...

This is one example where latency is not a problem, so periodic
queries could be used instead of observation if that's more scalable.
We're basically interested in whether anything changed in the results
of a query since we last ran it, a pattern which might be optimized in
Oak by taking advantage of the underlying MVCC storage.

-Bertrand

Re: Scalabilty of EventListener

[Bertrand Delacretaz]

Hi,

On Wed, Oct 23, 2013 at 11:30 AM, Dominik Süß  wrote:
> ...I have at least 2 cases in mind where the paths cannot be
> determined at deployment time...

We studied observation usage patterns [1] earlier this year on a few
Sling-based apps and it turns out that a lot of that can be done
without observation, which might help scalability.

So I'd say let's concentrate on Sling itself, and provide a way to be
more specific in how observation is used, for the cases where that
matters. And/or replace observation with other mechanisms where
appropriate.

A simple way of making our wide observation more specific is to
require users of our rebroadcast OSGi events to indicate more
specifically what they're interested in. This can be enabled by a
configuration switch, so that small apps that don't care require no
changes, and larger systems that require scalability can turn on that
switch and have to do a bit of work to provide more details. Large
scalable systems require work anyway, so this is not too much to ask
for IMO.

-Bertrand

[1] https://cwiki.apache.org/confluence/display/SLING/Observation+usage+patterns

Jenkins build is back to stable : sling-contrib-1.6 » Apache Sling Launchpad Contrib Testing #1095

[Apache Jenkins Server]

See 

Re: Scalabilty of EventListener

[Dominik Süß]

I just realized that there might be the need to dynamicaly add paths to the
Listener. I have at least 2 cases in mind where the paths cannot be
determined at deployment time which is the workflow launcher in CQ (where a
user does define a ruleset at runtime) which might be changed to individual
listeners being registerd, and the other case is when you have the
temporary need to watch for changes of specific nodes (e.g. when a cache
needs to be invalidated based on contentchanges - so the listener just
needs to react on changes of resources relevant to the invalidation logic).

During writing that I just came up with the question, what about such
global listeners as the replication agent of CQ which potentially nees to
act on all paths. The restrictions I have in mind is the path /content and
that it would be sufficient to have one aggregated event for a page
(substructure containing all resource to be used for rendering one
request)  which needs to be touched on subcontentchanges anyway
(lastmodified).

--
Dominik


On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler wrote:

> From the use cases I know, the listeners register for a specific path and
> are rarely interested in anything else. Some do check the resource type as
> well.
> For example the script engines check for changes under /libs and /apps (the
> resource paths actually) for changes to scripts, the job engine checks for
> new jobs somewhere under /var/jobs and checks the resource type as well
> etc.
> Many use cases check for changes (resource added, resource removed,
> resource changed) and then re-read the sub tree based on the changes.
>
> The mapping handler in the resource resolver is probably the most
> interesting one as it changes for nodes with some well defined properties,
> basically scanning the whole repository. And I think the i18n stuff does
> something similar (but this one might still be using jcr observation).
>
> This list is by no means exhaustive for Sling, but we see that we already
> have two listeners scanning the whole repository and require access to
> properties.
>
> Carsten
>
>
> 2013/10/22 Dominik Süß 
>
> > In a discussion [0] within the Oak mailinglist it became clear that the
> way
> > Sling listens zu JCR Repository Changes and transforms all of them to
> > events will not scale well in some big scale scenarios that oak is aiming
> > to enable. Therefore the question was posted if it would be feasible
> and/or
> > even necessary to refactor the API and deprecate (or at least discurrage)
> > registration in a global scope as currently done.
> >
> > Since I do not want to copy & paste parts of the discussion I do hope
> that
> > the participants of the oak discussion add the remaining options with
> some
> > more detail about consequences than can be found in the linked
> discussion.
> >
> > It would be great to also get some feedbacks of consumers of the existing
> > API about the usage to identify how finegrained a potential
> > registrationlogic with paths/properties might need to be.
> >
> > Best regards
> > Dominik
> >
> > [0] http://markmail.org/message/n5vllhjoawypteck
> >
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

[jira] [Created] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3202:
--

 Summary:  org.apache.sling.event.it.ClassloadingTest deadlock
 Key: SLING-3202
 URL: https://issues.apache.org/jira/browse/SLING-3202
 Project: Sling
  Issue Type: Bug
  Components: Extensions
 Environment: java version "1.6.0_51"
macosx 10.7.5
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: SLING-3194-stacktrace.txt, testlog.txt

This doesn't happen all the time but I just got a deadlock while running a full 
Sling build of svn revision 1534947

I'll attach a stack trace + console log.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3194) failure running sling.extensions.event unit/integraiton tests on windows?

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3194:


This doesn't look related but FWIW I just found an issue in ClassloadingTest, 
see SLING-3202

> failure running sling.extensions.event unit/integraiton tests on windows?
> -
>
> Key: SLING-3194
> URL: https://issues.apache.org/jira/browse/SLING-3194
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Event 3.3.0
> Environment: Win 7 64bit, JDK 1.7.0_17
>Reporter: Stefan Seifert
>Priority: Minor
> Attachments: 131021_failsafe-reports.zip, 131021_maven_full_output.zip
>
>
> this is a follow up of this mail thread
> http://apache-sling.73963.n3.nabble.com/failure-running-sling-extensions-event-unit-integraiton-tests-on-windows-tt4027989.html#none
> with current revision in trunk (rev. 1533892) it is still happening - or 
> happening again. the problem is that it sometimes work, most times does not 
> work.
> last comment from carsten:
> {quote}
> I fixed one thing in the Classloading test which removes the started job
> from the history...this shouldn't have an impact though
> Could you please comment out line 222 in the Classloading test and retun
> the tests, so hopefully this gives us a clue about what is going on.
> Carsten 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-3202:
---

Attachment: testlog.txt

>  org.apache.sling.event.it.ClassloadingTest deadlock
> 
>
> Key: SLING-3202
> URL: https://issues.apache.org/jira/browse/SLING-3202
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: java version "1.6.0_51"
> macosx 10.7.5
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3194-stacktrace.txt, testlog.txt
>
>
> This doesn't happen all the time but I just got a deadlock while running a 
> full Sling build of svn revision 1534947
> I'll attach a stack trace + console log.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-3202:
---

Attachment: SLING-3194-stacktrace.txt

>  org.apache.sling.event.it.ClassloadingTest deadlock
> 
>
> Key: SLING-3202
> URL: https://issues.apache.org/jira/browse/SLING-3202
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
> Environment: java version "1.6.0_51"
> macosx 10.7.5
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3194-stacktrace.txt, testlog.txt
>
>
> This doesn't happen all the time but I just got a deadlock while running a 
> full Sling build of svn revision 1534947
> I'll attach a stack trace + console log.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3194) failure running sling.extensions.event unit/integraiton tests on windows?

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-3194:
---

i tested it 6 times, and it succeeded in 4 cases, failed in 2 cases.
so - unfortunately - its still seems to be unstable.

> failure running sling.extensions.event unit/integraiton tests on windows?
> -
>
> Key: SLING-3194
> URL: https://issues.apache.org/jira/browse/SLING-3194
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Event 3.3.0
> Environment: Win 7 64bit, JDK 1.7.0_17
>Reporter: Stefan Seifert
>Priority: Minor
> Attachments: 131021_failsafe-reports.zip, 131021_maven_full_output.zip
>
>
> this is a follow up of this mail thread
> http://apache-sling.73963.n3.nabble.com/failure-running-sling-extensions-event-unit-integraiton-tests-on-windows-tt4027989.html#none
> with current revision in trunk (rev. 1533892) it is still happening - or 
> happening again. the problem is that it sometimes work, most times does not 
> work.
> last comment from carsten:
> {quote}
> I fixed one thing in the Classloading test which removes the started job
> from the history...this shouldn't have an impact though
> Could you please comment out line 222 in the Classloading test and retun
> the tests, so hopefully this gives us a clue about what is going on.
> Carsten 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: JARs in SVN

[Stefan Egli]

Afaik this was necessary due to a snapshot dependency on vault while it
was not yet released.

@Robert, we could get rid of this now, right?

Cheers,
Stefan

On 10/23/13 1:29 AM, "Felix Meschberger"  wrote:

>Hi
>
>I just realized that the tooling/ide/vlt-wrapper project stores libraries
>in SVN. I think this is not a good idea (read it is a bad idea). I
>suggest these JARs to be removed from SVN and build tooling to be used to
>get them form Maven Repositories.
>
>Thanks
>Felix

[jira] [Commented] (SLING-3153) Sling project overlay conflicts with the version control overlay

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-3153:


bq. I suggest making this decorator optional and disabled by default.

Ok, agreed. Then again, we might also just get rid of it? Who would try to find 
this option anyway..?

> Sling project overlay conflicts with the version control overlay
> 
>
> Key: SLING-3153
> URL: https://issues.apache.org/jira/browse/SLING-3153
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.0.0
>
> Attachments: java-faceted-project-decoration.png, screenshot.png
>
>
> The 'S' overlay which is present on Sling projects conflicts with the Version 
> control overlay, as defined in the [Eclipse UI 
> guidelines|http://wiki.eclipse.org/User_Interface_Guidelines] - search for 
> 'Version Control'.
> As such , I think we should find a different way of decorating Sling 
> projects, or even remove the decorator altogether.



--
This message was sent by Atlassian JIRA
(v6.1#6144)