date:20150325

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

Alexander Klimetschek updated SLING-4543:
-
Description:
Support json dictionaries as alternative to individual sling:Message nodes.

The fine grained JCR sling:Message node approach does not scale very well when
dictionaries contain thousands of entries, at least installation of such a
dictionary is slow, but also reading can be affected (even if this is cached),
especially viewing in a tree browser becomes impossible.

The individual string overlay mechanism (/apps string overlays same /libs
string) must still work.

In our case (AEM) this can save more than a minute during installation time.

was:
Support json dictionaries as alternative to individual sling:Message nodes.

The individual string overlay mechanism (/apps string overlays same /libs
string) must still work.

i18n: support for json dictionaries
---

Key: SLING-4543
URL: https://issues.apache.org/jira/browse/SLING-4543
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Alexander Klimetschek
Attachments: SLING-4543.patch

Support json dictionaries as alternative to individual sling:Message nodes.
The fine grained JCR sling:Message node approach does not scale very well
when dictionaries contain thousands of entries, at least installation of such
a dictionary is slow, but also reading can be affected (even if this is
cached), especially viewing in a tree browser becomes impossible.
The individual string overlay mechanism (/apps string overlays same /libs
string) must still work.
In our case (AEM) this can save more than a minute during installation time.

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

[jira] [Updated] (SLING-4494) Performance: update performance test framework to allow comparison of results


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

Radu Cotescu updated SLING-4494:

Component/s: Testing

 Performance: update performance test framework to allow comparison of results
 -

 Key: SLING-4494
 URL: https://issues.apache.org/jira/browse/SLING-4494
 Project: Sling
  Issue Type: Test
  Components: Testing
Reporter: Vlad Bailescu
Assignee: Radu Cotescu
Priority: Minor

 Update the Sling performance test framework to allow comparison of test 
 results. Specifically, add:
 - possibility to define a reference test and have the results of other 
 tests compared to it
 - possibility to log results as a ratio compared to the reference test
 - possibility to define a maximum threshold and have the framework fail a 
 test if it's ratio against the reference test exceeds this threshold



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

[jira] [Updated] (SLING-4494) Performance: update performance test framework to allow comparison of results


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

Radu Cotescu updated SLING-4494:

Component/s: Scripting

 Performance: update performance test framework to allow comparison of results
 -

 Key: SLING-4494
 URL: https://issues.apache.org/jira/browse/SLING-4494
 Project: Sling
  Issue Type: Test
  Components: Testing
Reporter: Vlad Bailescu
Assignee: Radu Cotescu
Priority: Minor

 Update the Sling performance test framework to allow comparison of test 
 results. Specifically, add:
 - possibility to define a reference test and have the results of other 
 tests compared to it
 - possibility to log results as a ratio compared to the reference test
 - possibility to define a maximum threshold and have the framework fail a 
 test if it's ratio against the reference test exceeds this threshold



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

[jira] [Commented] (SLING-2920) Wrong handling of Sling Filter ordering

2015-03-25 Thread Carsten Ziegeler (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379535#comment-14379535
 ] 

Carsten Ziegeler commented on SLING-2920:
-

I don't think such a flag really helps - as soon as you have two bundles, one 
expecting the correct and the other one the wrong order, it fails.

I think, if you upgrade from a bundle version with the old behaviour to a 
version with the new behaviour, you can check the service registrations and 
change the filter settings by multiplying with -1.

 Wrong handling of Sling Filter ordering
 ---

 Key: SLING-2920
 URL: https://issues.apache.org/jira/browse/SLING-2920
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Engine 2.2.8
Reporter: Felix Meschberger
Assignee: Carsten Ziegeler
 Fix For: Engine 2.3.4

 Attachments: SLING-2920.patch


 It looks like the ordering of Sling Filters is not implemented as it is 
 documented on [1].
 The documented intent is:
 * service.ranking ordering with higher numbers being higher preference over 
 lower numbers
 * filter.order ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order is ignored if service.ranking is defined
 * higher preferenced filters called before lower preferenced filters
 Actual implementation:
 * service.ranking ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order is ignored if service.ranking is defined
 * higher preferenced filters called before lower preferenced filters
 As one can see, the service.ranking ordering is not properly implemented. It 
 looks like this has been wrong since the first implementation as of 
 SLING-1735 (Jan 2011).
 We can either live with this actual implementation and fix the documentation 
 or fix the implementation at the cost of having to also fix any down-stream 
 filter providers using service.ranking values as implemented (and not as 
 documented).
 Discussion at http://sling.markmail.org/thread/h6uiveb2udw6y46q
 [1] http://sling.apache.org/documentation/the-sling-engine/filters.html



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

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

On Wed, Mar 25, 2015 at 10:16 AM, Radu Cotescu r...@apache.org wrote:
 ...let's be lazy developers and start with 1.0.2,...

That kind of lazyness is a virtue - we have better things to do with
our time ;-)

-Bertrand

[jira] [Updated] (SLING-4493) Sightly: Create performance tests


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

Radu Cotescu updated SLING-4493:

Component/s: (was: Testing)

 Sightly: Create performance tests
 -

 Key: SLING-4493
 URL: https://issues.apache.org/jira/browse/SLING-4493
 Project: Sling
  Issue Type: Test
  Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.0
Reporter: Vlad Bailescu
Assignee: Radu Cotescu
Priority: Minor
 Fix For: Scripting Sightly Engine 1.0.0


 Create performance tests for Sightly to evaluate current status and 
 performance impact of changes:
 - Create test content covering major Sightly features
 - Test both Java and JS Use API against equivalent JSP scripts
 - Create tests and set relative thresholds for performance ratio between 
 Sightly and JSP



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

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

On Wed, Mar 25, 2015 at 9:41 AM, Radu Cotescu r...@apache.org wrote:
 ...IMHO the nicest way to release something is to start from 1.0.0 (x.2 is
 Oracle's style)

Releasing 1.0.0 is cute of course, but version numbers are cheap - as
long as we follow the semantic versioning rules I don't really care
about the exact version numbers used, or if there are version number
gaps between releases etc.

-Bertrand

[jira] [Commented] (SLING-2920) Wrong handling of Sling Filter ordering

2015-03-25 Thread Bertrand Delacretaz (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379455#comment-14379455
 ] 

Bertrand Delacretaz commented on SLING-2920:


I'm wondering if we should implement a configurable flag to revert to the old 
behavior - this is rather annoying in existing applications.

 Wrong handling of Sling Filter ordering
 ---

 Key: SLING-2920
 URL: https://issues.apache.org/jira/browse/SLING-2920
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Engine 2.2.8
Reporter: Felix Meschberger
Assignee: Carsten Ziegeler
 Fix For: Engine 2.3.4

 Attachments: SLING-2920.patch


 It looks like the ordering of Sling Filters is not implemented as it is 
 documented on [1].
 The documented intent is:
 * service.ranking ordering with higher numbers being higher preference over 
 lower numbers
 * filter.order ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order is ignored if service.ranking is defined
 * higher preferenced filters called before lower preferenced filters
 Actual implementation:
 * service.ranking ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order ordering with lower numbers being higher preference over 
 higher numbers
 * filter.order is ignored if service.ranking is defined
 * higher preferenced filters called before lower preferenced filters
 As one can see, the service.ranking ordering is not properly implemented. It 
 looks like this has been wrong since the first implementation as of 
 SLING-1735 (Jan 2011).
 We can either live with this actual implementation and fix the documentation 
 or fix the implementation at the cost of having to also fix any down-stream 
 filter providers using service.ranking values as implemented (and not as 
 documented).
 Discussion at http://sling.markmail.org/thread/h6uiveb2udw6y46q
 [1] http://sling.apache.org/documentation/the-sling-engine/filters.html



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

Re: resource.adaptTo(Reader.class)

On Wed, Mar 25, 2015 at 2:49 AM, Alexander Klimetschek
aklim...@adobe.com wrote:
 ...when reading text files (nt:files) via the resource API, it would be useful
 to be able to adapt to a Reader, that is set up with the right charset

Sounds good to me but how do you define text file in this context?

Mime type, filename, sniffing? A pluggable way of doing that would be best.

-Bertrand

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

2015-03-25 Thread Radu Cotescu

Hi Olli,

IMHO the nicest way to release something is to start from 1.0.0 (x.2 is
Oracle's style). But the least work, given the circumstances, is option 3
since that's what has been set in JIRA previously. Let's see what other
people think. I'm fine either way.

I haven't yet started to think about adaptTo(), but this utility bundle is
used for Sightly's performance tests (see SLING-4493 [0]).

Cheers,
Radu

[0] - https://issues.apache.org/jira/browse/SLING-4493

On 25 March 2015 at 10:33, Oliver Lietz apa...@oliverlietz.de wrote:

 On Tuesday 24 March 2015 11:09:41 Radu Cotescu wrote:
  Hi Olli,

 Hi Radu,

  I've mistakenly released 0.0.2 when the JIRA component for this bundle
  indicated a 1.0.2 version of the first release. We could do either one
 of:
 
  1. change the JIRA version to 0.0.2 for the initial release, drop tags,
  restart the voting thread
  2. change the JIRA version to 1.0.0 for the initial release, restart the
  voting thread
  3. use 1.0.2 as the first release

 I would go for 1.

 Are you planning to show some results at adaptTo()?

 Regards,
 O.

  Cheers,
  Radu
 
  On 24 March 2015 at 10:41, Oliver Lietz apa...@oliverlietz.de wrote:
   On Monday 23 March 2015 22:47:52 Radu Cotescu wrote:
Hi,
  
   hi Radu,
  
We solved 7 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12327378
  
   what's the point in tagging 0.0.2 and 1.0.2 (same code)?
  
   0.0.2 as initial version is fine (as we don't sell a product and don't
   need a
   big number for marketing) and if you really need a major 1 why not
 going
   for
   1.0.0?
  
   Regards,
   O.
  
Staging repository:
   
 https://repository.apache.org/content/repositories/orgapachesling-1218
   
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 1218 /tmp/sling-staging
   
Please vote to approve this release:
  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...
   
This majority vote is open for at least 72 hours.
   
Thanks,
Radu

[jira] [Updated] (SLING-4494) Performance: update performance test framework to allow comparison of results


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

Radu Cotescu updated SLING-4494:

Fix Version/s: Sling JUnit Performance 1.0.2

 Performance: update performance test framework to allow comparison of results
 -

 Key: SLING-4494
 URL: https://issues.apache.org/jira/browse/SLING-4494
 Project: Sling
  Issue Type: Test
  Components: Testing
Reporter: Vlad Bailescu
Assignee: Radu Cotescu
Priority: Minor
 Fix For: Sling JUnit Performance 1.0.2


 Update the Sling performance test framework to allow comparison of test 
 results. Specifically, add:
 - possibility to define a reference test and have the results of other 
 tests compared to it
 - possibility to log results as a ratio compared to the reference test
 - possibility to define a maximum threshold and have the framework fail a 
 test if it's ratio against the reference test exceeds this threshold



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

[jira] [Updated] (SLING-4494) Performance: update performance test framework to allow comparison of results


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

Radu Cotescu updated SLING-4494:

Component/s: (was: Scripting)

 Performance: update performance test framework to allow comparison of results
 -

 Key: SLING-4494
 URL: https://issues.apache.org/jira/browse/SLING-4494
 Project: Sling
  Issue Type: Test
  Components: Testing
Reporter: Vlad Bailescu
Assignee: Radu Cotescu
Priority: Minor

 Update the Sling performance test framework to allow comparison of test 
 results. Specifically, add:
 - possibility to define a reference test and have the results of other 
 tests compared to it
 - possibility to log results as a ratio compared to the reference test
 - possibility to define a maximum threshold and have the framework fail a 
 test if it's ratio against the reference test exceeds this threshold



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

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

2015-03-25 Thread Oliver Lietz

On Tuesday 24 March 2015 11:09:41 Radu Cotescu wrote:
 Hi Olli,

Hi Radu,

 I've mistakenly released 0.0.2 when the JIRA component for this bundle
 indicated a 1.0.2 version of the first release. We could do either one of:
 
 1. change the JIRA version to 0.0.2 for the initial release, drop tags,
 restart the voting thread
 2. change the JIRA version to 1.0.0 for the initial release, restart the
 voting thread
 3. use 1.0.2 as the first release

I would go for 1.

Are you planning to show some results at adaptTo()?

Regards,
O.

 Cheers,
 Radu
 
 On 24 March 2015 at 10:41, Oliver Lietz apa...@oliverlietz.de wrote:
  On Monday 23 March 2015 22:47:52 Radu Cotescu wrote:
   Hi,
  
  hi Radu,
  
   We solved 7 issues in this release:
   https://issues.apache.org/jira/browse/SLING/fixforversion/12327378
  
  what's the point in tagging 0.0.2 and 1.0.2 (same code)?
  
  0.0.2 as initial version is fine (as we don't sell a product and don't
  need a
  big number for marketing) and if you really need a major 1 why not going
  for
  1.0.0?
  
  Regards,
  O.
  
   Staging repository:
   https://repository.apache.org/content/repositories/orgapachesling-1218
   
   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 1218 /tmp/sling-staging
   
   Please vote to approve this release:
 [ ] +1 Approve the release
 [ ]  0 Don't care
 [ ] -1 Don't release, because ...
   
   This majority vote is open for at least 72 hours.
   
   Thanks,
   Radu

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

2015-03-25 Thread Radu Cotescu

Then let's be lazy developers and start with 1.0.2, since JIRA was already
set up like this.

On 25 March 2015 at 11:15, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 I don't really care
 about the exact version numbers used, or if there are version number
 gaps between releases etc.

[jira] [Reopened] (SLING-4517) Update debian packaging to use crankstart.

2015-03-25 Thread Robert Munteanu (JIRA)


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

Robert Munteanu reopened SLING-4517:


Reopening, we only resolve when the code is actually comitted

 Update debian packaging to use crankstart.
 --

 Key: SLING-4517
 URL: https://issues.apache.org/jira/browse/SLING-4517
 Project: Sling
  Issue Type: Bug
  Components: Crankstart
Affects Versions: Launchpad Builder 8
Reporter: Bruce Edge
Priority: Minor
 Attachments: sling-patch.diff


 The current debian packaging is launchpad based. This is OK for simple 
 getting started configurations, but falls short of an end-user customizable 
 solution that allows full configurability within the bounds of a pre-packaged 
 env.



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

[jira] [Updated] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker

2015-03-25 Thread Joel Richard (JIRA)


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

Joel Richard updated SLING-4544:

Attachment: Screen Shot 2015-03-25 at 10.42.05.png

 Performance: MessageFormat shouldn't be used for logging in 
 SlingRequestProgressTracker
 ---

 Key: SLING-4544
 URL: https://issues.apache.org/jira/browse/SLING-4544
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
  Labels: performance
 Attachments: Screen Shot 2015-03-25 at 10.42.05.png


 I am profiling an application where up to 5% of the rendering time is spent 
 in MessageFormat.format for SlingRequestProgressTracker.log (see attached 
 screenshot). Since the advanced capabilities of MessageFormat are not 
 required here, it should be rather easy to implement a utility which supports 
 \{x} as well but is much faster.



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

Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.0

2015-03-25 Thread Robert Munteanu

On Tue, 2015-03-24 at 22:48 +0200, Radu Cotescu wrote:
 Hi Robert,
 
 I'm fine with dropping the o.a.s.scripting.sightly.testing artifact from
 this release, in which case the vote should still go on for the artifacts
 from 1216.

Agreed, thanks for your patience with the process :-)

Here's my +1, based on the current state from the 1216 staging repo.

Robert

 
 I'll start a new release thread for o.a.s.scripting.sightly.testing once
 the o.a.s.performance.base artifact is released.
 
 Cheers,
 Radu
 
 On 24 March 2015 at 22:04, Robert Munteanu romb...@apache.org wrote:
 
  IMO you should either drop org.apache.sling.scripting.sightly.testing
  completely from this release or cancel the whole release and restart the
  process once org.apache.sling.performance.base has been released.

[jira] [Created] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker

2015-03-25 Thread Joel Richard (JIRA)

Joel Richard created SLING-4544:
---

 Summary: Performance: MessageFormat shouldn't be used for logging 
in SlingRequestProgressTracker
 Key: SLING-4544
 URL: https://issues.apache.org/jira/browse/SLING-4544
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard


I am profiling an application where up to 5% of the rendering time is spent in 
MessageFormat.format for SlingRequestProgressTracker.log (see attached 
screenshot). Since the advanced capabilities of MessageFormat are not required 
here, it should be rather easy to implement a utility which supports {x} as 
well but is much faster.



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

[jira] [Updated] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker

2015-03-25 Thread Joel Richard (JIRA)


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

Joel Richard updated SLING-4544:

Description: I am profiling an application where up to 5% of the rendering 
time is spent in MessageFormat.format for SlingRequestProgressTracker.log (see 
attached screenshot). Since the advanced capabilities of MessageFormat are not 
required here, it should be rather easy to implement a utility which supports 
\{x} as well but is much faster.  (was: I am profiling an application where up 
to 5% of the rendering time is spent in MessageFormat.format for 
SlingRequestProgressTracker.log (see attached screenshot). Since the advanced 
capabilities of MessageFormat are not required here, it should be rather easy 
to implement a utility which supports {x} as well but is much faster.)

 Performance: MessageFormat shouldn't be used for logging in 
 SlingRequestProgressTracker
 ---

 Key: SLING-4544
 URL: https://issues.apache.org/jira/browse/SLING-4544
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
  Labels: performance

 I am profiling an application where up to 5% of the rendering time is spent 
 in MessageFormat.format for SlingRequestProgressTracker.log (see attached 
 screenshot). Since the advanced capabilities of MessageFormat are not 
 required here, it should be rather easy to implement a utility which supports 
 \{x} as well but is much faster.



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

[jira] [Commented] (SLING-4533) OakResourceListener does not allow to configure the OAK observation queue length

2015-03-25 Thread Marc Pfaff (JIRA)

[
https://issues.apache.org/jira/browse/SLING-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379612#comment-14379612
]

Marc Pfaff commented on SLING-4533:
---

bq. Am I correct that increasing the queue size will only move the threshold at
which the problem occurs?
I would say so, yes. I don't necessarily see increasing the queue size as the
solution to the problem. But it's IMHO still useful to have this possibility
for troubleshooting and as an additional option for tuning. Especially as the
Oak default size is only 1000.

bq. Is there a loud warning from Oak when that threshold is hit?
Yes and no. There is the following warning in the log:

{code}
24.03.2015 12:22:03.977 *WARN* [qtp699308246-690]
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor Revision queue is
full. Further revisions will be compacted.
{code}

But that is coming from the Oak ChangeProcessor and AFAIK this one can have a
different, as well configurable, queue size as per
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl. So I would say yes
there is a warning, but IMO that only makes sense if both, the Oak
ChangeProcessor and the Sling OakResourceListener use the same queue length
value.

OakResourceListener does not allow to configure the OAK observation queue
length

Key: SLING-4533
URL: https://issues.apache.org/jira/browse/SLING-4533
Project: Sling
Issue Type: Bug
Components: JCR, Oak
Affects Versions: JCR Resource 2.5.0
Reporter: Marc Pfaff

Currently the OakResourceListener does not allow to configure the OAK
observation queue length when instantiating the OAK BackgroundObserver. Thus
the default queue size of 1000 is used.
If the max queue size is reached, OAK seem's to turn the observation in a
'graceful degratation' mode, which leads to a compacted view of observations.
Means, not every single observation makes it to the observer no more. From
the point of view of the Sling resource changed events, this looks like some
events are missing.
I would propose to make the OAK observation queue size configurable in order
to have the possibility to avoid 'graceful degratation'.

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

Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2

2015-03-25 Thread Robert Munteanu

+1

Robert

On Mon, Mar 23, 2015 at 10:47 PM, Radu Cotescu r...@apache.org wrote:
 Hi,

 We solved 7 issues in this release:
 https://issues.apache.org/jira/browse/SLING/fixforversion/12327378

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

 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 1218 /tmp/sling-staging

 Please vote to approve this release:

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

 This majority vote is open for at least 72 hours.

 Thanks,
 Radu

[jira] [Commented] (SLING-4223) Make Content Loader extensible to support new import formats

2015-03-25 Thread Bruce Edge (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379774#comment-14379774
 ] 

Bruce Edge commented on SLING-4223:
---

Either approach works for me. I'm all for KISS in theory, so I assume there's 
some use case addressed by the additional inheritance in the BaseContentReader 
as opposed to the original whiteboard approach.

 Make Content Loader extensible to support new import formats
 

 Key: SLING-4223
 URL: https://issues.apache.org/jira/browse/SLING-4223
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR ContentLoader 2.1.10
Reporter: Oliver Lietz
Assignee: Tomek Rękawek
 Fix For: JCR ContentLoader 2.2.0

 Attachments: SLING-4223.patch


 The current Content Loader supports a basic set of import formats which are 
 identified by extension: {{.xml}}, {{.jcr.xml}}, {{.json}}, {{.jar}} and 
 {{.zip}}.
 There is a [user 
 request|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3cd0a6198c.20fbeb%25bruce.e...@nextissuemedia.com%3e]
  to support custom formats like Adobe Folio and [some ideas how to 
 implement|http://mail-archives.apache.org/mod_mbox/sling-users/201412.mbox/%3ca2ab572f-fa83-4ae2-806e-49cce87b9...@adobe.com%3e]:
 * we create a new org.apache.sling.contentloader.reader package to be 
 exported at version 1.0
 * move the ContentCreator (@ProviderType) and ContentReader (@ConsumerType) 
 to that new package
 * convert the BaseImportLoader into a standalone ContentReader service holder 
 used by the DefaultContentImporter and ContentLoaderService components.
 * For the ContentReader service interface we define service registration 
 properties for the service to expose the file name extension (and maybe 
 content type) the reader supports.



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

Jenkins build became unstable: sling-trunk-1.7 #1612

2015-03-25 Thread Apache Jenkins Server

See https://builds.apache.org/job/sling-trunk-1.7/1612/changes

[jira] [Updated] (SLING-4533) OakResourceListener does not allow to configure the OAK observation queue length

2015-03-25 Thread Marc Pfaff (JIRA)


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

Marc Pfaff updated SLING-4533:
--
Attachment: SLING-4533.patch

Please find attached a patch proposal for adding a configurable queue length.

 OakResourceListener does not allow to configure the OAK observation queue 
 length
 

 Key: SLING-4533
 URL: https://issues.apache.org/jira/browse/SLING-4533
 Project: Sling
  Issue Type: Bug
  Components: JCR, Oak
Affects Versions: JCR Resource 2.5.0
Reporter: Marc Pfaff
 Attachments: SLING-4533.patch


 Currently the OakResourceListener does not allow to configure the OAK 
 observation queue length when instantiating the OAK BackgroundObserver.  Thus 
 the default queue size of 1000 is used.
 If the max queue size is reached, OAK seem's to turn the observation in a 
 'graceful degratation' mode, which leads to a compacted view of observations. 
 Means, not every single observation makes it to the observer no more.  From 
 the point of view of the Sling resource changed events, this looks like some 
 events are missing.
 I would propose to make the OAK observation queue size configurable in order 
 to have the possibility to avoid 'graceful degratation'. 



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

[jira] [Updated] (SLING-4462) Resource Editor :: Integrate Node.js, Grunt and npm for frontend libraries

2015-03-25 Thread Sandro Boehme (JIRA)


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

Sandro Boehme updated SLING-4462:
-
Description: 
The goal is to configure the Resource Editor for frontend tests (Jasmine, 
Karma, end to end via Webdriver) and to optimize its frontend build 
configuration. To accomplish that the Frontend Maven Plugin 
(https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
Node.js, Grunt and npm locally within in the project and makes it available in 
a Maven build.

Contra:
o The npm repository that needs to be ignored for SVN is generated within the 
project folder.
o The build takes longer initially as the repository needs to be filled with 
the dependencies (5min on my box).

Pro:
o Avoids that I have to check in the frontend libraries and Bootstrap Less 
sources to SVN as they can be copied from the local npm repo during the build 
process.
o Eases the listing of the 3rd party licenses of used npm package as the npm 
package 'nlf' for example can be used to list the licenses in a specific depth 
of transitive dependencies. It allows a good fix for SLING-4205.
o Better supported libraries:
- BDD Unit Tests with different browsers
Via Maven:
https://github.com/karma-runner/maven-karma-plugin (31 Stars)
Via npm:
https://github.com/karma-runner/karma (4760 Stars)

- Less CSS compiler and watch functionality
Via Maven:
https://github.com/marceloverdijk/lesscss-maven-plugin (155 Stars, not 
supported anymore)
https://github.com/marceloverdijk/lesscss-java (151 Stars, not supported 
anymore)

Via npm:
https://github.com/gruntjs/grunt-contrib-watch (1380 Stars)
https://github.com/gruntjs/grunt-contrib-less (519 Stars)

- Minification:
Via Maven:
https://github.com/davidB/yuicompressor-maven-plugin (80 Stars)
Via npm:
https://github.com/gruntjs/grunt-contrib-uglify (850 Stars)
https://github.com/gruntjs/grunt-contrib-cssmin (513 Stars)

- BDD (Jasmine) End to End Tests are not available via Maven

  was:
The goal is to configure the Resource Editor for frontend tests (Jasmine, 
Karma, end to end via Webdriver) and to optimize its frontend build 
configuration. To accomplish that the Frontend Maven Plugin 
(https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
Node.js, Grunt and npm locally within in the project and makes it available in 
a Maven build.

Contra:
The npm repository that needs to be ignored for SVN is generated within the 
project folder.

Pro:
o Avoids that I have to check in the frontend libraries and Bootstrap Less 
sources to SVN as they can be copied from the local npm repo during the build 
process.
o Eases the listing of the 3rd party licenses of used npm package as the npm 
package 'nlf' for example can be used to list the licenses in a specific depth 
of transitive dependencies. It allows a good fix for SLING-4205.
o Better supported libraries:
- BDD Unit Tests with different browsers
Via Maven:
https://github.com/karma-runner/maven-karma-plugin (31 Stars)
Via npm:
https://github.com/karma-runner/karma (4760 Stars)

- Less CSS compiler and watch functionality
Via Maven:
https://github.com/marceloverdijk/lesscss-maven-plugin (155 Stars, not 
supported anymore)
https://github.com/marceloverdijk/lesscss-java (151 Stars, not supported 
anymore)

Via npm:
https://github.com/gruntjs/grunt-contrib-watch (1380 Stars)
https://github.com/gruntjs/grunt-contrib-less (519 Stars)

- Minification:
Via Maven:
https://github.com/davidB/yuicompressor-maven-plugin (80 Stars)
Via npm:
https://github.com/gruntjs/grunt-contrib-uglify (850 Stars)
https://github.com/gruntjs/grunt-contrib-cssmin (513 Stars)

- BDD (Jasmine) End to End Tests are not available via Maven


 Resource Editor :: Integrate Node.js, Grunt and npm for frontend libraries
 --

 Key: SLING-4462
 URL: https://issues.apache.org/jira/browse/SLING-4462
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Resource Editor 1.0.2
Reporter: Sandro Boehme
Assignee: Sandro Boehme

 The goal is to configure the Resource Editor for frontend tests (Jasmine, 
 Karma, end to end via Webdriver) and to optimize its frontend build 
 configuration. To accomplish that the Frontend Maven Plugin 
 (https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
 Node.js, Grunt and npm locally within in the project and makes it available 
 in a Maven build.
 Contra:
 o The npm repository that needs to be ignored for SVN is generated within the 
 project folder.
 o The build takes longer initially as the repository needs to be filled with 
 the dependencies (5min on my box).
 Pro:
 o Avoids that I have to check in the frontend libraries and Bootstrap Less 
 sources to SVN as they can be copied from the local npm repo during the build

[jira] [Created] (SLING-4546) Sightly: Improper handling of extension and selectors by data-sly-resource

2015-03-25 Thread Vlad Bailescu (JIRA)

Vlad Bailescu created SLING-4546:


 Summary: Sightly: Improper handling of extension and selectors by 
data-sly-resource
 Key: SLING-4546
 URL: https://issues.apache.org/jira/browse/SLING-4546
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Vlad Bailescu
 Fix For: Scripting Sightly Engine 1.0.2


Sightly is not handling extensions and selectors properly in 
{{data-sly-resource}}:
1. Selectors included in path or parent resource are ignored if no 
selector-related option is specified
2. Extensions are ignored completely, Sightly assumes anything preceded by a 
dot is a selector

This leads to:
* {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of 
{{'resource.html' @ selectors=\['selector'\]}}
* {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to 
{{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of 
{{'resource.html' @ selectors=\['selector', 'other'\]}}





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

Jenkins build is back to stable : sling-trunk-1.7 #1613

2015-03-25 Thread Apache Jenkins Server

See https://builds.apache.org/job/sling-trunk-1.7/1613/changes

[jira] [Updated] (SLING-4513) Donation proposal of HApi tools

2015-03-25 Thread Andrei Dulvac (JIRA)


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

Andrei Dulvac updated SLING-4513:
-
Attachment: hapi.tar.gz

Attached hapi.tar.gz.
MD5 (hapi.tar.gz) = 5be02d98378d6dc177f6345887d6992d

 Donation proposal of HApi tools 
 

 Key: SLING-4513
 URL: https://issues.apache.org/jira/browse/SLING-4513
 Project: Sling
  Issue Type: Task
  Components: Scripting
Reporter: Andrei Dulvac
  Labels: hapi, scripting
 Attachments: hapi.tar.gz


 Tracks the donation of HApi tools from https://github.com/dulvac/hapi



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

[jira] [Updated] (SLING-4462) Resource Editor :: Integrate Node.js, Grunt and npm for frontend libraries

2015-03-25 Thread Sandro Boehme (JIRA)


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

Sandro Boehme updated SLING-4462:
-
Description: 
The goal is to configure the Resource Editor for frontend tests (Jasmine, 
Karma, end to end via Webdriver) and to optimize its frontend build 
configuration. To accomplish that the Frontend Maven Plugin 
(https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
Node.js, Grunt and npm locally within in the project and makes it available in 
a Maven build.

Con:
o The npm repository that needs to be ignored for SVN is generated within the 
project folder.
o The build takes longer initially as the npm repository needs to be filled 
with the dependencies (5min on my box).
o a ~/.npm folder is created and filled with repository data

Pro:
o Avoids that I have to check in the frontend libraries and Bootstrap Less 
sources to SVN as they can be copied from the local npm repo during the build 
process.
o Eases the listing of the 3rd party licenses of used npm package as the npm 
package 'nlf' for example can be used to list the licenses in a specific depth 
of transitive dependencies. It allows a good fix for SLING-4205.
o Better supported libraries:
- BDD Unit Tests with different browsers
Via Maven:
https://github.com/karma-runner/maven-karma-plugin (31 Stars)
Via npm:
https://github.com/karma-runner/karma (4760 Stars)

- Less CSS compiler and watch functionality
Via Maven:
https://github.com/marceloverdijk/lesscss-maven-plugin (155 Stars, not 
supported anymore)
https://github.com/marceloverdijk/lesscss-java (151 Stars, not supported 
anymore)

Via npm:
https://github.com/gruntjs/grunt-contrib-watch (1380 Stars)
https://github.com/gruntjs/grunt-contrib-less (519 Stars)

- Minification:
Via Maven:
https://github.com/davidB/yuicompressor-maven-plugin (80 Stars)
Via npm:
https://github.com/gruntjs/grunt-contrib-uglify (850 Stars)
https://github.com/gruntjs/grunt-contrib-cssmin (513 Stars)

- BDD (Jasmine) End to End Tests are not available via Maven

  was:
The goal is to configure the Resource Editor for frontend tests (Jasmine, 
Karma, end to end via Webdriver) and to optimize its frontend build 
configuration. To accomplish that the Frontend Maven Plugin 
(https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
Node.js, Grunt and npm locally within in the project and makes it available in 
a Maven build.

Contra:
o The npm repository that needs to be ignored for SVN is generated within the 
project folder.
o The build takes longer initially as the repository needs to be filled with 
the dependencies (5min on my box).

Pro:
o Avoids that I have to check in the frontend libraries and Bootstrap Less 
sources to SVN as they can be copied from the local npm repo during the build 
process.
o Eases the listing of the 3rd party licenses of used npm package as the npm 
package 'nlf' for example can be used to list the licenses in a specific depth 
of transitive dependencies. It allows a good fix for SLING-4205.
o Better supported libraries:
- BDD Unit Tests with different browsers
Via Maven:
https://github.com/karma-runner/maven-karma-plugin (31 Stars)
Via npm:
https://github.com/karma-runner/karma (4760 Stars)

- Less CSS compiler and watch functionality
Via Maven:
https://github.com/marceloverdijk/lesscss-maven-plugin (155 Stars, not 
supported anymore)
https://github.com/marceloverdijk/lesscss-java (151 Stars, not supported 
anymore)

Via npm:
https://github.com/gruntjs/grunt-contrib-watch (1380 Stars)
https://github.com/gruntjs/grunt-contrib-less (519 Stars)

- Minification:
Via Maven:
https://github.com/davidB/yuicompressor-maven-plugin (80 Stars)
Via npm:
https://github.com/gruntjs/grunt-contrib-uglify (850 Stars)
https://github.com/gruntjs/grunt-contrib-cssmin (513 Stars)

- BDD (Jasmine) End to End Tests are not available via Maven


 Resource Editor :: Integrate Node.js, Grunt and npm for frontend libraries
 --

 Key: SLING-4462
 URL: https://issues.apache.org/jira/browse/SLING-4462
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Resource Editor 1.0.2
Reporter: Sandro Boehme
Assignee: Sandro Boehme

 The goal is to configure the Resource Editor for frontend tests (Jasmine, 
 Karma, end to end via Webdriver) and to optimize its frontend build 
 configuration. To accomplish that the Frontend Maven Plugin 
 (https://github.com/eirslett/frontend-maven-plugin) is used. It installs 
 Node.js, Grunt and npm locally within in the project and makes it available 
 in a Maven build.
 Con:
 o The npm repository that needs to be ignored for SVN is generated within the 
 project folder.
 o The build takes longer initially as the npm repository needs to be filled 
 with the dependencies

[jira] [Updated] (SLING-4546) Sightly: Improper handling of extension and selectors by data-sly-resource

2015-03-25 Thread Vlad Bailescu (JIRA)


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

Vlad Bailescu updated SLING-4546:
-
Description: 
Sightly is not handling extensions and selectors properly in 
{{data-sly-resource}}:
# Selectors included in path or parent resource are ignored if no 
selector-related option is specified
# Extensions are ignored completely, Sightly assumes anything preceded by a dot 
is a selector

This leads to:
* {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of 
{{'resource.html' @ selectors=\['selector'\]}}
* {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to 
{{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of 
{{'resource.html' @ selectors=\['selector', 'other'\]}}



  was:
Sightly is not handling extensions and selectors properly in 
{{data-sly-resource}}:
1. Selectors included in path or parent resource are ignored if no 
selector-related option is specified
2. Extensions are ignored completely, Sightly assumes anything preceded by a 
dot is a selector

This leads to:
* {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of 
{{'resource.html' @ selectors=\['selector'\]}}
* {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to 
{{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of 
{{'resource.html' @ selectors=\['selector', 'other'\]}}




 Sightly: Improper handling of extension and selectors by data-sly-resource
 --

 Key: SLING-4546
 URL: https://issues.apache.org/jira/browse/SLING-4546
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Vlad Bailescu
 Fix For: Scripting Sightly Engine 1.0.2


 Sightly is not handling extensions and selectors properly in 
 {{data-sly-resource}}:
 # Selectors included in path or parent resource are ignored if no 
 selector-related option is specified
 # Extensions are ignored completely, Sightly assumes anything preceded by a 
 dot is a selector
 This leads to:
 * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of 
 {{'resource.html' @ selectors=\['selector'\]}}
 * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to 
 {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of 
 {{'resource.html' @ selectors=\['selector', 'other'\]}}



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

[VOTE] Accept the donation of the Hypermedia API Tools via SLING-4513

2015-03-25 Thread Andrei Dulvac

Hello,

Following a recent discussion on this list, I'm starting a [VOTE] thread
regarding the donation of HApi (Hypermedia API tools).

Issue: SLING-4513
Github repo: https://github.com/dulvac/hapi
MD5 of archive: MD5 (hapi.tar.gz) = 5be02d98378d6dc177f6345887d6992d

Please cast your votes.

Thank you,
Andrei

[jira] [Updated] (SLING-4513) Donation proposal of HApi tools

2015-03-25 Thread Andrei Dulvac (JIRA)


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

Andrei Dulvac updated SLING-4513:
-
Labels: PatchAvailable hapi scripting  (was: hapi scripting)

 Donation proposal of HApi tools 
 

 Key: SLING-4513
 URL: https://issues.apache.org/jira/browse/SLING-4513
 Project: Sling
  Issue Type: Task
  Components: Scripting
Reporter: Andrei Dulvac
  Labels: PatchAvailable, hapi, scripting
 Attachments: hapi.tar.gz


 Tracks the donation of HApi tools from https://github.com/dulvac/hapi



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

[jira] [Commented] (SLING-4546) Sightly: Improper handling of extension and selectors by data-sly-resource

2015-03-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1437#comment-1437
 ] 

ASF GitHub Bot commented on SLING-4546:
---

GitHub user vladbailescu opened a pull request:

https://github.com/apache/sling/pull/77

SLING-4546 - Sightly: Improper handling of extension and selectors by 
data-sly-resource

- Improved selector extraction for resource path (taking extensions into 
consideration)
- Added selectors from path or parent to dispatcher options so they will no 
longer be ignored
- Updated testing content and integration tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vladbailescu/sling 
SLING-4546_improper_extension_selectors_in_data-sly-resource

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/77.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #77


commit 6b4e0ec1ab1a38c771e0da3e8e86e3e4bcdca1f5
Author: vladbailescu baile...@adobe.com
Date:   2015-03-25T14:55:19Z

SLING-4546 - Sightly: Improper handling of extension and selectors by 
data-sly-resource

- Improved selector extraction for resource path (taking extensions into 
consideration)
- Added selectors from path or parent to dispatcher options so they will no 
longer be ignored
- Updated testing content and integration tests




 Sightly: Improper handling of extension and selectors by data-sly-resource
 --

 Key: SLING-4546
 URL: https://issues.apache.org/jira/browse/SLING-4546
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Vlad Bailescu
 Fix For: Scripting Sightly Engine 1.0.2


 Sightly is not handling extensions and selectors properly in 
 {{data-sly-resource}}:
 # Selectors included in path or parent resource are ignored if no 
 selector-related option is specified
 # Extensions are ignored completely, Sightly assumes anything preceded by a 
 dot is a selector
 This leads to:
 * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of 
 {{'resource.html' @ selectors=\['selector'\]}}
 * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to 
 {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of 
 {{'resource.html' @ selectors=\['selector', 'other'\]}}



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

[GitHub] sling pull request: SLING-4546 - Sightly: Improper handling of ext...

2015-03-25 Thread vladbailescu

GitHub user vladbailescu opened a pull request:

https://github.com/apache/sling/pull/77

SLING-4546 - Sightly: Improper handling of extension and selectors by 
data-sly-resource

- Improved selector extraction for resource path (taking extensions into 
consideration)
- Added selectors from path or parent to dispatcher options so they will no 
longer be ignored
- Updated testing content and integration tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vladbailescu/sling 
SLING-4546_improper_extension_selectors_in_data-sly-resource

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/77.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #77


commit 6b4e0ec1ab1a38c771e0da3e8e86e3e4bcdca1f5
Author: vladbailescu baile...@adobe.com
Date:   2015-03-25T14:55:19Z

SLING-4546 - Sightly: Improper handling of extension and selectors by 
data-sly-resource

- Improved selector extraction for resource path (taking extensions into 
consideration)
- Added selectors from path or parent to dispatcher options so they will no 
longer be ignored
- Updated testing content and integration tests




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-4533) OakResourceListener does not allow to configure the OAK observation queue length

2015-03-25 Thread Marc Pfaff (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379979#comment-14379979
 ] 

Marc Pfaff commented on SLING-4533:
---

bq. If you have ideas about how that can be implemented it would be good to 
create an Oak ticket.

I created OAK-2680 accordingly. 

 OakResourceListener does not allow to configure the OAK observation queue 
 length
 

 Key: SLING-4533
 URL: https://issues.apache.org/jira/browse/SLING-4533
 Project: Sling
  Issue Type: Bug
  Components: JCR, Oak
Affects Versions: JCR Resource 2.5.0
Reporter: Marc Pfaff
 Attachments: SLING-4533.patch


 Currently the OakResourceListener does not allow to configure the OAK 
 observation queue length when instantiating the OAK BackgroundObserver.  Thus 
 the default queue size of 1000 is used.
 If the max queue size is reached, OAK seem's to turn the observation in a 
 'graceful degratation' mode, which leads to a compacted view of observations. 
 Means, not every single observation makes it to the observer no more.  From 
 the point of view of the Sling resource changed events, this looks like some 
 events are missing.
 I would propose to make the OAK observation queue size configurable in order 
 to have the possibility to avoid 'graceful degratation'. 



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

[jira] [Commented] (SLING-4517) Update debian packaging to use crankstart.

2015-03-25 Thread Bruce Edge (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380317#comment-14380317
 ] 

Bruce Edge commented on SLING-4517:
---

OK, thanks.

Ignore the patch, will resubmit as a pull request.

 Update debian packaging to use crankstart.
 --

 Key: SLING-4517
 URL: https://issues.apache.org/jira/browse/SLING-4517
 Project: Sling
  Issue Type: Bug
  Components: Crankstart
Affects Versions: Launchpad Builder 8
Reporter: Bruce Edge
Priority: Minor
 Attachments: sling-patch.diff


 The current debian packaging is launchpad based. This is OK for simple 
 getting started configurations, but falls short of an end-user customizable 
 solution that allows full configurability within the bounds of a pre-packaged 
 env.



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

Re: [VOTE] Accept the donation of the Hypermedia API Tools via SLING-4513

On Wed, Mar 25, 2015 at 4:53 PM, Andrei Dulvac andrei.dul...@gmail.com wrote:
 ..Following a recent discussion on this list, I'm starting a [VOTE] thread
 regarding the donation of HApi (Hypermedia API tools)...

+1, as a contrib I suppose.

-Bertrand

Re: [VOTE] Release Apache Sling Content Distribution (api, core, sample, it) 0.1.0

2015-03-25 Thread Tommaso Teofili

+1 (non-binding)

Tommaso

2015-03-24 16:24 GMT+01:00 Tommaso Teofili tommaso.teof...@gmail.com:

 Hi all,

 This is the vote for the first Sling Content Distribution [1] release
 (version 0.1.0) which includes 4 modules
 (org.apache.sling.distribution.[api,core,sample,it])

 We solved 101 issues there:
 https://issues.apache.org/jira/browse/SLING/fixforversion/12328962

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

 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 1220 /tmp/sling-staging

 Please cast your vote to approve this release:

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

 The vote is open for the next 72 hours.

 Thanks and regards,
 Tommaso

 [1] :
 https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/README.md

[jira] [Updated] (SLING-4513) Donation proposal of HApi tools

2015-03-25 Thread Andrei Dulvac (JIRA)


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

Andrei Dulvac updated SLING-4513:
-
Description: 
Tracks the donation of HApi tools from https://github.com/dulvac/hapi as a 
contrib


  was:
Tracks the donation of HApi tools from https://github.com/dulvac/hapi



 Donation proposal of HApi tools 
 

 Key: SLING-4513
 URL: https://issues.apache.org/jira/browse/SLING-4513
 Project: Sling
  Issue Type: Task
  Components: Scripting
Reporter: Andrei Dulvac
  Labels: PatchAvailable, hapi, scripting
 Attachments: hapi.tar.gz


 Tracks the donation of HApi tools from https://github.com/dulvac/hapi as a 
 contrib



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

Re: [VOTE] Accept the donation of the Hypermedia API Tools via SLING-4513

2015-03-25 Thread Tommaso Teofili

+1

Tommaso

2015-03-25 16:53 GMT+01:00 Andrei Dulvac andrei.dul...@gmail.com:

 Hello,

 Following a recent discussion on this list, I'm starting a [VOTE] thread
 regarding the donation of HApi (Hypermedia API tools).

 Issue: SLING-4513
 Github repo: https://github.com/dulvac/hapi
 MD5 of archive: MD5 (hapi.tar.gz) = 5be02d98378d6dc177f6345887d6992d

 Please cast your votes.

 Thank you,
 Andrei

[GitHub] sling pull request: SLING-4517 Update debian packaging to use cran...

2015-03-25 Thread bedge

GitHub user bedge opened a pull request:

https://github.com/apache/sling/pull/78

SLING-4517 Update debian packaging to use crankstart.

Patch switches debian packaging over to using crankstart and sling-s3 
contrib projects.
Allows user to install a generic sling server, then edit one config file to 
select one of:
tar files for nodes and data
tar files for nodes, s3 for data
mongo for nodes and data
mongo for nodes, s3 for data

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bedge/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/78.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #78


commit 61d7108326705c70b9838f27fc30490091bf6ae7
Author: Bruce Edge bruce.e...@nextissuemedia.com
Date:   2015-03-25T17:43:40Z

SLING-4517 Update debian packaging to use crankstart.

Patch switches debian packaging over to using crankstart and sling-s3 
contrib projects.
Allows user to install a generic sling server, then edit one config file to 
select one of:
tar files for nodes and data
tar files for nodes, s3 for data
mongo for nodes and data
mongo for nodes, s3 for data




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-4517) Update debian packaging to use crankstart.

2015-03-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14380337#comment-14380337
 ] 

ASF GitHub Bot commented on SLING-4517:
---

GitHub user bedge opened a pull request:

https://github.com/apache/sling/pull/78

SLING-4517 Update debian packaging to use crankstart.

Patch switches debian packaging over to using crankstart and sling-s3 
contrib projects.
Allows user to install a generic sling server, then edit one config file to 
select one of:
tar files for nodes and data
tar files for nodes, s3 for data
mongo for nodes and data
mongo for nodes, s3 for data

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bedge/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/78.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #78


commit 61d7108326705c70b9838f27fc30490091bf6ae7
Author: Bruce Edge bruce.e...@nextissuemedia.com
Date:   2015-03-25T17:43:40Z

SLING-4517 Update debian packaging to use crankstart.

Patch switches debian packaging over to using crankstart and sling-s3 
contrib projects.
Allows user to install a generic sling server, then edit one config file to 
select one of:
tar files for nodes and data
tar files for nodes, s3 for data
mongo for nodes and data
mongo for nodes, s3 for data




 Update debian packaging to use crankstart.
 --

 Key: SLING-4517
 URL: https://issues.apache.org/jira/browse/SLING-4517
 Project: Sling
  Issue Type: Bug
  Components: Crankstart
Affects Versions: Launchpad Builder 8
Reporter: Bruce Edge
Priority: Minor
 Attachments: sling-patch.diff


 The current debian packaging is launchpad based. This is OK for simple 
 getting started configurations, but falls short of an end-user customizable 
 solution that allows full configurability within the bounds of a pre-packaged 
 env.



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

Re: resource.adaptTo(Reader.class)

2015-03-25 Thread Alexander Klimetschek

On 25.03.2015, at 01:26, Bertrand Delacretaz bdelacre...@apache.org wrote:
 Sounds good to me but how do you define text file in this context?
 
 Mime type, filename, sniffing? A pluggable way of doing that would be best.

No need for detecting a text file, the application requests it with 
adaptTo(Reader.class), if that provides a broken stream because the binary is 
not a text file, then it's a problem of the application. Just a little utility 
helper here.

Cheers,
Alex

[jira] [Updated] (SLING-4543) i18n: support for json dictionaries


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

Alexander Klimetschek updated SLING-4543:
-
Attachment: SLING-4543.patch

Updated patch with better logging - now info instead of debug logging for the 
dictionary loading parts and measurements, useful to monitor what dictionaries 
are which format and how long it takes to load them.

 i18n: support for json dictionaries
 ---

 Key: SLING-4543
 URL: https://issues.apache.org/jira/browse/SLING-4543
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Alexander Klimetschek
 Attachments: SLING-4543.patch, SLING-4543.patch


 Support json dictionaries as alternative to individual sling:Message nodes.
 The fine grained JCR sling:Message node approach does not scale very well 
 when dictionaries contain thousands of entries, at least installation of such 
 a dictionary is slow, but also reading can be affected (even if this is 
 cached), especially viewing in a tree browser becomes impossible.
 The individual string overlay mechanism (/apps string overlays same /libs 
 string) must still work.
 In our case (AEM) this can save more than a minute during installation time.



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

[jira] [Comment Edited] (SLING-4543) i18n: support for json dictionaries


[ 
https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379197#comment-14379197
 ] 

Alexander Klimetschek edited comment on SLING-4543 at 3/25/15 8:51 PM:
---

Attached patch which adds json dictionary support: [^SLING-4543.patch]

If the mix:language dictionary node has a name like {{*.json}} and is an 
nt:file, it will try to load this json, if not it will use the existing 
sling:Message node.

The json format is straightforward: the parser will take _any_ key:value 
pair in the dictionary, including in nested objects or arrays. Normally, a 
dictionary will be just a single json object = hash map though.

For parsing, I used a streaming json parser from jackrabbit commons (already a 
dependency) which is very fast.

I took the liberty to clean up the complex logic (rest, res0, etc. maps) - 
which was obsolete with the previous changes that already load the dictionary 
one by one (instead of a query across the repo, where each entry could come 
from a different search path, each dictionary is loaded one by one and is 
already beneath a certain search path or outside).

I also adapted the tests (some parts taken from Amit's patch over in 
SLING-4512) and added one test case for json dictionaries and one that tests 
that dictionaries outside the search path are overlayed by dictionaries within 
a search path.


was (Author: alexander.klimetschek):
Attached patch which adds json dictionary support: [^SLING-4543.patch]

If the mix:language dictionary node has a name like {{*.json}} and is an 
nt:file, it will try to load this json, if not it will use the existing 
sling:Message node.

I took the liberty to clean up the complex logic (rest, res0, etc. maps) - 
which was obsolete with the previous changes that already load the dictionary 
one by one (instead of a query across the repo, where each entry could come 
from a different search path, each dictionary is loaded one by one and is 
already beneath a certain search path or outside).

I also adapted the tests (some parts taken from Amit's patch over in 
SLING-4512) and added one test case for json dictionaries and one that tests 
that dictionaries outside the search path are overlayed by dictionaries within 
a search path.

 i18n: support for json dictionaries
 ---

 Key: SLING-4543
 URL: https://issues.apache.org/jira/browse/SLING-4543
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Alexander Klimetschek
 Attachments: SLING-4543.patch


 Support json dictionaries as alternative to individual sling:Message nodes.
 The fine grained JCR sling:Message node approach does not scale very well 
 when dictionaries contain thousands of entries, at least installation of such 
 a dictionary is slow, but also reading can be affected (even if this is 
 cached), especially viewing in a tree browser becomes impossible.
 The individual string overlay mechanism (/apps string overlays same /libs 
 string) must still work.
 In our case (AEM) this can save more than a minute during installation time.



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

[jira] [Comment Edited] (SLING-4543) i18n: support for json dictionaries

[
https://issues.apache.org/jira/browse/SLING-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379197#comment-14379197
]

Alexander Klimetschek edited comment on SLING-4543 at 3/25/15 8:51 PM:
---

Attached patch which adds json dictionary support: [^SLING-4543.patch]

If the mix:language dictionary node has a name like {{*.json}} and is an
nt:file, it will try to load this json, if not it will use the existing
sling:Message node.

The json format is straightforward: the parser will take _any_ key:value
pair in the dictionary, including in nested objects or arrays. Normally, a
dictionary will be just a single json object = hash map though.

For parsing, I used a streaming json parser from jackrabbit commons (already a
dependency) which is very fast. Loads 17000 strings across 3 json dictionaries
in 44ms on my machine.

I took the liberty to clean up the complex logic (rest, res0, etc. maps) -
which was obsolete with the previous changes that already load the dictionary
one by one (instead of a query across the repo, where each entry could come
from a different search path, each dictionary is loaded one by one and is
already beneath a certain search path or outside).

I also adapted the tests (some parts taken from Amit's patch over in
SLING-4512) and added one test case for json dictionaries and one that tests
that dictionaries outside the search path are overlayed by dictionaries within
a search path.

was (Author: alexander.klimetschek):
Attached patch which adds json dictionary support: [^SLING-4543.patch]

If the mix:language dictionary node has a name like {{*.json}} and is an
nt:file, it will try to load this json, if not it will use the existing
sling:Message node.

For parsing, I used a streaming json parser from jackrabbit commons (already a
dependency) which is very fast.

i18n: support for json dictionaries
---

Key: SLING-4543
URL: https://issues.apache.org/jira/browse/SLING-4543
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Alexander Klimetschek
Attachments: SLING-4543.patch

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

[jira] [Updated] (SLING-4543) i18n: support for json dictionaries