[jira] [Created] (SLING-7305) The org.apache.sling.scripting.javascript bundle should add more specific information about the Script Engine it provides

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7305:
---

 Summary: The org.apache.sling.scripting.javascript bundle should 
add more specific information about the Script Engine it provides
 Key: SLING-7305
 URL: https://issues.apache.org/jira/browse/SLING-7305
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting JavaScript 3.0.0
Reporter: Radu Cotescu
 Fix For: Scripting JavaScript 3.0.4


Since SLING-7134 all accessible Script Engines are loaded by Apache Sling (Java 
platform engine, SPI bundles engines and explicitly registered Script Engines). 
Therefore, the Script Engine provided by the 
{{org.apache.sling.scripting.javascript}} bundle should provide more specific 
information, in case a script should target this engine and not Nashorn.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7305) The org.apache.sling.scripting.javascript bundle should add more specific information about the Script Engine it provides

[Radu Cotescu (JIRA)]

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

Radu Cotescu reassigned SLING-7305:
---

Assignee: Radu Cotescu

> The org.apache.sling.scripting.javascript bundle should add more specific 
> information about the Script Engine it provides
> -
>
> Key: SLING-7305
> URL: https://issues.apache.org/jira/browse/SLING-7305
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JavaScript 3.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting JavaScript 3.0.4
>
>
> Since SLING-7134 all accessible Script Engines are loaded by Apache Sling 
> (Java platform engine, SPI bundles engines and explicitly registered Script 
> Engines). Therefore, the Script Engine provided by the 
> {{org.apache.sling.scripting.javascript}} bundle should provide more specific 
> information, in case a script should target this engine and not Nashorn.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7304) Add support for primitive arrays in ObjectModel#toString and ObjectModel#toCollection

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7304:
---

 Summary: Add support for primitive arrays in ObjectModel#toString 
and ObjectModel#toCollection
 Key: SLING-7304
 URL: https://issues.apache.org/jira/browse/SLING-7304
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL Compiler 1.0.16


{{org.apache.sling.scripting.sightly.compiler.util.ObjectModel#toCollection}} 
and {{org.apache.sling.scripting.sightly.compiler.util.ObjectModel#toString}} 
should be extended to be able to convert primitive arrays, the same way they 
support {{Object}} arrays.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7300) CPU spike in i18n job

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-7300:
--

All 3 dumps are inside the logging. Maybe there is a problem there. Do you see 
a lot of log output by the i18n? If yes, maybe it's set to a higher log level, 
outputting too much for an overloaded logging system (just guessing here) and a 
workaround is to limit logging for {{org.apache.sling.i18n}} to ERROR or the 
like. HTH

> CPU spike in i18n job
> -
>
> Key: SLING-7300
> URL: https://issues.apache.org/jira/browse/SLING-7300
> Project: Sling
>  Issue Type: Bug
>  Components: i18n, Karaf
>Affects Versions: i18n 2.5.10
> Environment: Linux, jdk1.8 latest version, Karaf 4.1.3
>Reporter: Ivo Leitão
>Priority: Critical
> Attachments: 1.tdump, 2.tdump, 3.tdump, cpuspike.png
>
>
> Hi,
> I'm experiencing severe CPU spikes caused by the reload job in the i18n 
> bundle. I've uploaded 3 threadumps which I analysed in http://fastthread.io. 
> The analysis identified a cpu spike in the method scheduleReloadBundles of 
> the class 
> https://github.com/apache/sling-org-apache-sling-i18n/blob/master/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java.
> This does not happen every time only on some situations. I've experienced 
> this problem at least on the previous i18n bundle versions. Since there was 
> changes on the mentioned class I've updated it hopping to get rid of this 
> problem. Unfortunately I'm experiencing it again :-(
> Thread dump bellow:
> sling-default-1-JcrResourceBundleProvider: reload all resource bundles - 
> priority:5 - threadId:0x7f2ec851e800 - nativeId:0x1f72 - state:RUNNABLE
> stackTrace:
> java.lang.Thread.State: RUNNABLE
> at 
> java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss(ThreadLocal.java:444)
> at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:419)
> at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:298)
> at java.lang.ThreadLocal.get(ThreadLocal.java:163)
> at 
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.getByteBuffer(StringBuilderEncoder.java:115)
> at 
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:54)
> at 
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:32)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:219)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:57)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:177)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:170)
> at 
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:161)
> at 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:218)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403)
> at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:151)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:144)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.inform(PaxLoggerImpl.java:176)
> at 
> org.ops4j.pax.logging.internal.TrackingLogger.inform(TrackingLogger.java:86)
> at org.ops4j.pax.logging.slf4j.Slf4jLogger.info(Slf4jLogger.java:476)
> at 
> org.apache.sling.i18n.impl.JcrResourceBundleProvider$1.run(JcrResourceBundleProvider.java:319)
> at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:347)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at 
> 

Re: Git repo for sling testing tools?

[Robert Munteanu]

Hi Konrad,

On Fri, 2017-12-08 at 16:35 +0100, Konrad Windszus wrote:
> Created https://issues.apache.org/jira/browse/SLING-7293  ues.apache.org/jira/browse/SLING-7293> to track that.
> @Robert: Can you have a look?

As you correctly noted in Jira

> this module was supposed to be deprecated and therefore also supposed
to be moved to contrib (in SLING-5704)

Now, the thing is I don't remember whether I intentionally skipped this
module or it was a mistake ( apparently my scripts missed a number of
modules ). I have no strong opinion on moving the module, but we should
make sure we actually plan on working on it/releasing it, otherwise we
should move it to a new GitHub attic instead.

Robert

Re: [RESULT][VOTE] Release Apache Sling Testing Clients version 1.1.12 and Apache Sling Testing Rules 1.0.6

[Robert Munteanu]

On Mon, 2017-12-11 at 12:54 +, Andrei Dulvac wrote:
> 
> Can a member of the PMC help with copying the releases to the Sling
> dist directory and promoting to Maven Central?

Done.

I copied the release to dist, you should be able to handle all the
remaining steps, including promoting to Maven Central.

Robert

Re: NPE in Oak with PaxExam IT

[Robert Munteanu]

Hi Konrad,

On Fri, 2017-12-08 at 17:28 +0100, Konrad Windszus wrote:
> I see the following error when executing a test with paxexam
> 
> org.ops4j.pax.exam.TestContainerException: There are unresolved
> bundles. See previous ERROR log messages for details.
> 
> The testing.log exposes only one error, namely
> 
> 2017-12-08 17:20:00,138 ERROR [Apache Sling Repository Startup
> Thread] o.a.s.j.o.s.i.OakSlingRepositoryManager
> [AbstractSlingRepositoryManager.java : 499] start: Uncaught Throwable
> trying to access Repository, calling stopRepository()
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.property.Multiplexers.getStra
> tegies(Multiplexers.java:75)
> at
> org.apache.jackrabbit.oak.plugins.index.property.Multiplexers.getStra
> tegies(Multiplexers.java:62)
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.
> getStrategies(PropertyIndexEditor.java:220)
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.
> updateIndex(PropertyIndexEditor.java:286)
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.
> leave(PropertyIndexEditor.java:239)

What version of Oak were you using for the test? Looks like somewhere
along the line a null MountInfoProvider was passed.

Robert

Re: Java 9 support, Sling 10 release

[Robert Munteanu]

On Wed, 2017-12-06 at 14:16 +0100, Konrad Windszus wrote:
> > On 6. Dec 2017, at 14:15, Robert Munteanu 
> > wrote:
> > 
> > On Wed, 2017-12-06 at 14:02 +0100, Konrad Windszus wrote:
> > > > The way out would be to either:
> > > > 
> > > > 1. adjust the exported package lists for Java 8
> > > > 2. deploy new bundles only for Java 9
> > > > 
> > > > 1. is a risky proposition, especially since it can affect
> > > > backwards
> > > > compatibility
> > > > 2. requires further work in the provisioning model, and maybe a
> > > > bad
> > > > idea to invest in since the feature model is hopefully close to
> > > > complete.
> > > > 
> > > 
> > > I would propose not tweak the actual deployment but rather
> > > leverage
> > > OSGi execution environments (OSGi Core Spec 3.4). That should
> > > lead to
> > > the fact that
> > > ...
> > > A bundle can only resolve if the framework is running on a VM
> > > which
> > > implements one of the listed
> > > required execution environments.
> > > ... 
> > 
> > Does that mean we get bundles that fail to resolve by default on
> > Java
> > 8? That would not be good IMO.
> 
> Yes, exactly. 
> IMHO that should not do any harm (maybe except for some failing
> healthchecks which need to be adjusted)

I think it's a bad impression at least to have bundles that can't
resolve at startup. We have no idea what the impact will be for
consumers and it's tricky to make sure all health checks are done
right, and presumably anyone using the web console will start looking
for clues when they see bundles that don't start. We can document it,
but I am sure not that many people read the documentation :-)

What we can try - not sure if feasible - is to add a run mode named
'java9' and activate it from a special bootstrap bundle if we detect
that Java 9 is used to run Sling. Then in the provisioning model the
Java 9-specific bundles are attached to this 'java9' runmode, which
would mean:

- Java 8 is untouched
- Java 9 no longer requires adding the '--add-modules' flag

Again, note that this is completely untested but just might work.

Robert

Jackrabbit FileVault Package Manager Maven Plugin Issue

[Andreas Schaefer]

Hi

JFYI eventually me and Stefan figured out that the issue with the plugin was 
that I configured it in the execution/configuration section but should be in 
the configuration section.

That said I reported an issue with the Jackrabbit team:

https://issues.apache.org/jira/browse/JCRVLT-253 


Thanks - Andreas Schaefer Sr.

[jira] [Comment Edited] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-7303 at 12/11/17 3:31 PM:
---

2) The issue with facets might (in my case) be related to OAK-6750.


was (Author: diru):
The issue with facets might (in my case) be related to OAK-6750.

> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> don't take those into account at all, as the colNames are not iterated, only 
> the values which only expose stored fields. See the following for all the 
> cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-7303 at 12/11/17 3:31 PM:
---

The issue with facets might (in my case) be related to OAK-6750.


was (Author: diru):
The issue with facets might be related to OAK-6750.

> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> don't take those into account at all, as the colNames are not iterated, only 
> the values which only expose stored fields. See the following for all the 
> cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-7303:
-

The issue with facets might be related to OAK-6750.

> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> don't take those into account at all, as the colNames are not iterated, only 
> the values which only expose stored fields. See the following for all the 
> cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7277) Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer commented on SLING-7277:
-

Thanks Stefan. I started working on a test and with that I also discovered that 
issue of my using the . I merged and tested your 
changes and everything looks fine now.

> Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle
> -
>
> Key: SLING-7277
> URL: https://issues.apache.org/jira/browse/SLING-7277
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
> Environment: Sling 9
>Reporter: Andreas Schaefer
>  Labels: Archetype, Maven
> Attachments: pom.xml
>
>
> This Maven Archetype creates a wrapper Content Package (all) that contains an 
> OSGi Bundle (core) and a Content Package (ui.apps).
> This does the same thing if there is only one content package but for bigger 
> projects containing multiple content packages and bundles this can make sure 
> that everything is deployed as an atomic file preventing issues with 
> dependencies and out of sync content.
> The Git Repository for this is here:
> https://github.com/headwirecom/sling-project-all-archetype



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7276) Sling Maven Archetype for a Bundle / Content Package project

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer commented on SLING-7276:
-

Thanks to Stefan the build for All is not working as expected with the 
Jackrabbit Filevault Package Manager.

> Sling Maven Archetype for a Bundle / Content Package project
> 
>
> Key: SLING-7276
> URL: https://issues.apache.org/jira/browse/SLING-7276
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
> Environment: Sling 9
>Reporter: Andreas Schaefer
>  Labels: Archetype, Maven, Tooling
>
> I created a Maven Archetype for Ruben that creates a Sling project composed 
> of a Bundle (core) and a Content Package (ui.apps) which contains the Bundle 
> as embedded object.
> It is deployed using the latest WCMIO Content Package Maven Plugin to deploy 
> to Sling using Composum.
> The generated contains a shadow module for the core and ui.apps with the 
> extension '.example' that is not part of the build but can be copied into the 
> active module when desired or deleted by just deleting these folders.
> The Git Repository of that can be found here:
> https://github.com/headwirecom/sling-project-archetype



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7245) Validate pull requests using Jenkins

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7245:


[~kwin] - that looks interesting. I'll still stuck on the task of not having to 
add a Jenkinsfile per repo. Does this plugin help with that task?

> Validate pull requests using Jenkins
> 
>
> Key: SLING-7245
> URL: https://issues.apache.org/jira/browse/SLING-7245
> Project: Sling
>  Issue Type: Improvement
>  Components: Best practices
>Reporter: Robert Munteanu
>
> We should refine the work done in SLING-7163 and validate PRs using Jenkins.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7303:

Description: 
The method named above iterates over the values returned from the row using 
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
oak into account. To name just a few:

1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
open 
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].

2) Advanced query functionalities: Queries containing for example rep:facet() 
don't take those into account at all, as the colNames are not iterated, only 
the values which only expose stored fields. See the following for all the 
cases: 
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]

Along with this bug the unit tests for a couple of scenarios should be added to 
cover what BasicQueryLanguageProvider is doing.

  was:
The method named above iterates over the values returned from the row using 
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
oak into account. To name just a few:

1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
open 
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].

2) Advanced query functionalities: Queries containing for example rep:facet() 
dobn't take those into account at all, as the colNames are not iterated, only 
the values which only expose stored fields. See the following for all the 
cases: 
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]

Along with this bug the unit tests for a couple of scenarios should be added to 
cover what BasicQueryLanguageProvider is doing.


> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> don't take those into account at all, as the colNames are not iterated, only 
> the values which only expose stored fields. See the following for all the 
> cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7303:

Description: 
The method named above iterates over the values returned from the row using 
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
oak into account. To name just a few:

1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
open 
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].

2) Advanced query functionalities: Queries containing for example rep:facet() 
dobn't take those into account at all, as the colNames are not iterated, only 
the values which only expose stored fields. See the following for all the 
cases: 
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]

Along with this bug the unit tests for a couple of scenarios should be added to 
cover what BasicQueryLanguageProvider is doing.

  was:
The method named above iterates over the values returned from the row using 
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
oak into account. To name just a few:

1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
open 
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].

2) Advanced query functionalities: Queries containing for example rep:facet() 
are not taken into account at all, as the colNames are not iterated, only the 
values which only expose stored fields. See the following for all the cases: 
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]

Along with this bug the unit tests for a couple of scenarios should be added to 
cover what BasicQueryLanguageProvider is doing.


> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> dobn't take those into account at all, as the colNames are not iterated, only 
> the values which only expose stored fields. See the following for all the 
> cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-7303:

Affects Version/s: JCR Resource 3.0.8

> BasicQueryLanguageProvider#queryResources does not return all selected fields
> -
>
> Key: SLING-7303
> URL: https://issues.apache.org/jira/browse/SLING-7303
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.9.2, JCR Resource 3.0.8
>Reporter: Dirk Rudolph
>
> The method named above iterates over the values returned from the row using 
> {{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
> oak into account. To name just a few:
> 1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
> \[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
> because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
> open 
> todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].
> 2) Advanced query functionalities: Queries containing for example rep:facet() 
> are not taken into account at all, as the colNames are not iterated, only the 
> values which only expose stored fields. See the following for all the cases: 
> [LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]
> Along with this bug the unit tests for a couple of scenarios should be added 
> to cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7303) BasicQueryLanguageProvider#queryResources does not return all selected fields

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-7303:
---

 Summary: BasicQueryLanguageProvider#queryResources does not return 
all selected fields
 Key: SLING-7303
 URL: https://issues.apache.org/jira/browse/SLING-7303
 Project: Sling
  Issue Type: Bug
  Components: JCR
Affects Versions: JCR Resource 2.9.2
Reporter: Dirk Rudolph


The method named above iterates over the values returned from the row using 
{{jcrRow.getValues()}} - this unfortunately doesn't take all capabilities of 
oak into account. To name just a few:

1) Selectors: Querying with selector like {{select p.\[jcr:score] from 
\[cq:Page] as p where contains(p.\[*], 'some text')}} returns 0.01 as score 
because the actual score is stored in {{p.jcr:score}} and the fallback is [an 
open 
todo|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java#L82].

2) Advanced query functionalities: Queries containing for example rep:facet() 
are not taken into account at all, as the colNames are not iterated, only the 
values which only expose stored fields. See the following for all the cases: 
[LucenePropertyIndex.java#L1628|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.1/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1628]

Along with this bug the unit tests for a couple of scenarios should be added to 
cover what BasicQueryLanguageProvider is doing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[RESULT][VOTE] Release Apache Sling Testing Clients version 1.1.12 and Apache Sling Testing Rules 1.0.6

[Andrei Dulvac]

Hi,

The vote has passed with 3 binding votes

+1 (binding): Robert, Stefan, Konrad
+1 (non binding): Andrei Dulvac

Can a member of the PMC help with copying the releases to the Sling
dist directory and promoting to Maven Central?

Thanks,

Andrei

[jira] [Closed] (SLING-7233) MockConfigurationAdmin ignores configuration PID

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-7233.
-

> MockConfigurationAdmin ignores configuration PID
> 
>
> Key: SLING-7233
> URL: https://issues.apache.org/jira/browse/SLING-7233
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.4
>Reporter: Marcel Reutegger
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Testing OSGi Mock 2.3.6
>
>
> The class currently assumes the configuration PID is always the service PID. 
> It ignores a potentially different configuration PID on the component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-7285) Add support for Service Reference + Interface

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-7285.
-

> Add support for Service Reference + Interface
> -
>
> Key: SLING-7285
> URL: https://issues.apache.org/jira/browse/SLING-7285
> Project: Sling
>  Issue Type: Sub-task
>  Components: Testing
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Testing OSGi Mock 2.3.6
>
>
> The {{bind*}} / {{unbind*}} methods should support Service Reference + 
> Interface parameters.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-7134) Script execution order is not deterministic on Java 9 and nashorn engine is missing in java8

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-7134.
-

> Script execution order is not deterministic on Java 9 and nashorn engine is 
> missing in java8
> 
>
> Key: SLING-7134
> URL: https://issues.apache.org/jira/browse/SLING-7134
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting, Servlets
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
> Fix For: Scripting Core 2.0.52, Servlets Resolver 2.4.20
>
> Attachments: scripting-engines-java-9.png
>
>
> When starting up the Sling launchpad with Java 9 and accessing 
> http://localhost:8080/bin/browser.html I get an empty page and the following 
> stack trace in the error log
> {noformat}18.09.2017 23:50:44.656 *ERROR* [127.0.0.1 [1505767840754] GET 
> /bin/browser.html HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcesso
> rImpl service: Uncaught SlingException
> jdk.nashorn.internal.runtime.ECMAException: ReferenceError: "window" is not 
> defined
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:319)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:291)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.objects.Global.__noSuchProperty__(Global.java:1615)
> at 
> jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1$\^eval\_.:program(:5)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:652)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
> at 
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517)
> at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:420)
> at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:72)
> at 
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:513)
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> at 
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
> at 
> org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
> at 
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:77)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:282)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.dispatchRequest(SlingRequestProcessorImpl.java:322)
> at 
> org.apache.sling.engine.impl.request.SlingRequestDispatcher.dispatch(SlingRequestDispatcher.java:211)
> at 
> org.apache.sling.engine.impl.request.SlingRequestDispatcher.include(SlingRequestDispatcher.java:104)
> at 
> org.apache.sling.scripting.jsp.taglib.IncludeTagHandler.dispatch(IncludeTagHandler.java:54)
> at 
> org.apache.sling.scripting.jsp.taglib.AbstractDispatcherTagHandler.doEndTag(AbstractDispatcherTagHandler.java:129)
> at 
> org.apache.jsp.libs.composum.nodes.console.components.codeeditor.editdialog.editdialog_jsp._jspx_meth_sling_005finclude_005f0(edi
> tdialog_jsp.java:128)
> at 
> org.apache.jsp.libs.composum.nodes.console.components.codeeditor.editdialog.editdialog_jsp._jspService(editdialog_jsp.java:99)
> at 
> org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at 
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:502)
> at 
> org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:449)
> at 
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:342)
> at 
> org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:97)
> at 
> org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine.eval(JspScriptEngineFactory.java:603)
> at 
> 

[jira] [Closed] (SLING-7265) NPE on activation of SlingServletResolver

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-7265.
-

> NPE on activation of SlingServletResolver
> -
>
> Key: SLING-7265
> URL: https://issues.apache.org/jira/browse/SLING-7265
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.4.14
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.4.20
>
>
> The following happens when SCR is restarted:
> This might be a timing issue as the reference gets stale while the resolver 
> is activating, or for some reason the stale reference did not get removed 
> from the list
> 24.11.2017 15:49:21.348 *ERROR* [pool-4-thread-1] 
> org.apache.sling.servlets.resolver bundle 
> org.apache.sling.servlets.resolver:2.4.14 
> (538)[org.apache.sling.servlets.resolver.SlingServletResolver(3037)] : The 
> activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
>   at 
> org.apache.sling.servlets.resolver.internal.SlingServletResolver.createServlet(SlingServletResolver.java:1010)
>   at 
> org.apache.sling.servlets.resolver.internal.SlingServletResolver.createAllServlets(SlingServletResolver.java:982)
>   at 
> org.apache.sling.servlets.resolver.internal.SlingServletResolver.activate(SlingServletResolver.java:819)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RESULT] [VOTE] Release Apache Servlets Resolver 2.4.20

[Karl Pauls]

Time to call the vote on the Apache Sling Servlets Resolver 2.4.20 release.

* +1 votes from Carsten Ziegeler, Robert Munteanu, Radu Cotescu, and Karl Pauls.

* No other votes.

The vote is successful. I will make the artifacts available as soon as possible.

Re: [VOTE] Release Apache Sling Testing Clients version 1.1.12 and Apache Sling Testing Rules 1.0.6

[Konrad Windszus]

+1
Konrad

> On 11. Dec 2017, at 11:30, Andrei Dulvac  wrote:
> 
> Hi,
> 
> Thanks guys.
> I think this needs one more +1.
> 
> Can anybody else have a look?
> 
> - Andrei
> 
> 
> On Thu, Dec 7, 2017 at 5:28 PM Stefan Seifert 
> wrote:
> 
>> +1
>> 

Re: [VOTE] Release Apache Servlets Resolver 2.4.20

[Karl Pauls]

+1

regards,

Karl

On Wed, Dec 6, 2017 at 5:49 PM, Radu Cotescu  wrote:
> +1
>
> On Tue, 5 Dec 2017 at 22:30, Karl Pauls  wrote:
>
>>
>> Please vote to approve these releases:
>>
>>   [ ] +1 Approve the releases
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>>



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

Re: [RESULT][VOTE] Release Apache Sling Testing OSGi Mock 2.3.6, Scripting Core 2.0.52

[Karl Pauls]

Time to call the vote on the Apache Sling Testing OSGi Mock 2.3.6 and
Scripting Core 2.0.52 releases.

* +1 votes from Robert Munteanu, Stefan Seifert, Radu Cotescu, and Karl Pauls.

* No other votes.

The vote is successful. I will make the artifacts available as soon as possible.

Re: [RESULT][VOTE] Release Apache Sling Testing OSGi Mock 2.3.6, Scripting Core 2.0.52

[Karl Pauls]

+1

regards,

Karl

[jira] [Resolved] (SLING-7277) Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-7277.
---
Resolution: Duplicate

setting this ticket to "duplicate", discussion can continue on SLING-7276

> Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle
> -
>
> Key: SLING-7277
> URL: https://issues.apache.org/jira/browse/SLING-7277
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
> Environment: Sling 9
>Reporter: Andreas Schaefer
>  Labels: Archetype, Maven
> Attachments: pom.xml
>
>
> This Maven Archetype creates a wrapper Content Package (all) that contains an 
> OSGi Bundle (core) and a Content Package (ui.apps).
> This does the same thing if there is only one content package but for bigger 
> projects containing multiple content packages and bundles this can make sure 
> that everything is deployed as an atomic file preventing issues with 
> dependencies and out of sync content.
> The Git Repository for this is here:
> https://github.com/headwirecom/sling-project-all-archetype



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7277) Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-7277:
---

bq. There is an issue with the Jackrabbit Filevault Package maven plugin. In 
the 'all' module I create an "empty" JCR Package that is only containing 
embedded Bundles and JCR Package as sub packages. Both have a 
true settings but that seems to be ignored if there is no 
existing filter.xml.
this can be fixed with this PR: 
https://github.com/headwirecom/sling-project-archetype/pull/1

> Sling Maven Archetype for a Wrapper Content Package with a Content and Bundle
> -
>
> Key: SLING-7277
> URL: https://issues.apache.org/jira/browse/SLING-7277
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
> Environment: Sling 9
>Reporter: Andreas Schaefer
>  Labels: Archetype, Maven
> Attachments: pom.xml
>
>
> This Maven Archetype creates a wrapper Content Package (all) that contains an 
> OSGi Bundle (core) and a Content Package (ui.apps).
> This does the same thing if there is only one content package but for bigger 
> projects containing multiple content packages and bundles this can make sure 
> that everything is deployed as an atomic file preventing issues with 
> dependencies and out of sync content.
> The Git Repository for this is here:
> https://github.com/headwirecom/sling-project-all-archetype



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Testing Clients version 1.1.12 and Apache Sling Testing Rules 1.0.6

[Andrei Dulvac]

Hi,

Thanks guys.
I think this needs one more +1.

Can anybody else have a look?

- Andrei


On Thu, Dec 7, 2017 at 5:28 PM Stefan Seifert 
wrote:

> +1
>

[jira] [Commented] (SLING-7194) AdapterManager sorts AdapterFactory implementations lowest ranking first

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-7194:
---

yes, that's why i was a bit reluctant to fix this right away. i assume the 
impact of such a change here would be much, much smaller than that of the 
filter change, but still it might cause trouble difficult to detect.

the alternative would be to explicitly document the behavior in both 
[apidocs|https://sling.apache.org/apidocs/sling9/org/apache/sling/api/adapter/AdapterFactory.html]
 and 
[documentation|https://sling.apache.org/documentation/the-sling-engine/adapters.html].

> AdapterManager sorts AdapterFactory implementations lowest ranking first
> 
>
> Key: SLING-7194
> URL: https://issues.apache.org/jira/browse/SLING-7194
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Adapter 2.1.10
>Reporter: Stefan Seifert
>
> the current implementation of AdapterManager uses a 
> AdapterFactoryDescriptorMap to sort the AdapterFactory implementations found.
> this is done using a TreeMap with the ServiceReference as key. 
> ServiceReference implements a compareTo.
> according to its documentation the default implementation sorts with 
> service-ranking lowest-first/service id highest-first:
> https://osgi.org/javadoc/r6/core/org/osgi/framework/ServiceReference.html#compareTo(java.lang.Object)
> when picking a service from multiple ones using BundleContext.getService, the 
> service with hightest service ranking/lowest service id is returned.
> i would expect the same from the AdapterManager implementation - if multiple 
> implementations match pick that one with highest ranking/lowest service id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7194) AdapterManager sorts AdapterFactory implementations lowest ranking first

[Julian Sedding (JIRA)]

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

Julian Sedding edited comment on SLING-7194 at 12/11/17 8:51 AM:
-

The current ordering (call it reversed if you like) is in effect for 
{{AdapterFactories}} since 2012 (see SLING-2630) and has not caused any 
problems since then. Even the ticket description does not mention a problem, 
only an (academic - sorry ;)) expectation.

Therefore I am against this backwards incompatible change.

We have a precedent with a change of the very same nature: reversal of the 
order of {{Filter}}s in Sling's servlet filter chain (see SLING-2920, 
http://sling.markmail.org/thread/h6uiveb2udw6y46q). This change caused numerous 
subtle issues due to incorrectly ordered filters. It took several years (\!) 
until these issues were fully fixed in Adobe's upstream project. And then this 
fix likely caused issues for some customers again, because they had started 
relying on the "fixed" filter order.

Is "correcting" the order for {{AdapterFactories}} really worth repeating such 
a scenario? If you think so, can you please explain where this fix brings any 
business value? Thanks.


was (Author: jsedding):
The current ordering (call it reversed if you like) is in effect for 
{{AdapterFactories}} since 2012 (see SLING-2630) and has not caused any 
problems since then. Even the ticket description does not mention a problem, 
only an (academic - sorry ;)) expectation.

Therefore I am against this backwards incompatible change.

We have a precedent with a change of the very same nature: reversal of the 
order of {{Filter}}s in Sling's servlet filter chain (see SLING-2920). This 
change caused numerous subtle issues due to incorrectly ordered filters. It 
took several years (!) until these issues were fully fixed in Adobe's upstream 
project. And then this fix likely caused issues for some customers again, 
because they had started relying on the "fixed" filter order.

Is "correcting" the order for {{AdapterFactories}} really worth repeating such 
a scenario? If you think so, can you please explain where this fix brings any 
business value? Thanks.

> AdapterManager sorts AdapterFactory implementations lowest ranking first
> 
>
> Key: SLING-7194
> URL: https://issues.apache.org/jira/browse/SLING-7194
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Adapter 2.1.10
>Reporter: Stefan Seifert
>
> the current implementation of AdapterManager uses a 
> AdapterFactoryDescriptorMap to sort the AdapterFactory implementations found.
> this is done using a TreeMap with the ServiceReference as key. 
> ServiceReference implements a compareTo.
> according to its documentation the default implementation sorts with 
> service-ranking lowest-first/service id highest-first:
> https://osgi.org/javadoc/r6/core/org/osgi/framework/ServiceReference.html#compareTo(java.lang.Object)
> when picking a service from multiple ones using BundleContext.getService, the 
> service with hightest service ranking/lowest service id is returned.
> i would expect the same from the AdapterManager implementation - if multiple 
> implementations match pick that one with highest ranking/lowest service id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7194) AdapterManager sorts AdapterFactory implementations lowest ranking first

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-7194:
---

The current ordering (call it reversed if you like) is in effect for 
{{AdapterFactories}} since 2012 (see SLING-2630) and has not caused any 
problems since then. Even the ticket description does not mention a problem, 
only an (academic - sorry ;)) expectation.

Therefore I am against this backwards incompatible change.

We have a precedent with a change of the very same nature: reversal of the 
order of {{Filter}}s in Sling's servlet filter chain (see SLING-2920). This 
change caused numerous subtle issues due to incorrectly ordered filters. It 
took several years (!) until these issues were fully fixed in Adobe's upstream 
project. And then this fix likely caused issues for some customers again, 
because they had started relying on the "fixed" filter order.

Is "correcting" the order for {{AdapterFactories}} really worth repeating such 
a scenario? If you think so, can you please explain where this fix brings any 
business value? Thanks.

> AdapterManager sorts AdapterFactory implementations lowest ranking first
> 
>
> Key: SLING-7194
> URL: https://issues.apache.org/jira/browse/SLING-7194
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Adapter 2.1.10
>Reporter: Stefan Seifert
>
> the current implementation of AdapterManager uses a 
> AdapterFactoryDescriptorMap to sort the AdapterFactory implementations found.
> this is done using a TreeMap with the ServiceReference as key. 
> ServiceReference implements a compareTo.
> according to its documentation the default implementation sorts with 
> service-ranking lowest-first/service id highest-first:
> https://osgi.org/javadoc/r6/core/org/osgi/framework/ServiceReference.html#compareTo(java.lang.Object)
> when picking a service from multiple ones using BundleContext.getService, the 
> service with hightest service ranking/lowest service id is returned.
> i would expect the same from the AdapterManager implementation - if multiple 
> implementations match pick that one with highest ranking/lowest service id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)