Re: [VOTE] - Accept donation of replication module to Apache Sling

[Tommaso Teofili]

as far as I know there's usually a vote on the dev@ list for first
acceptance (and then it's referenced in the IP Clearance file), then the IP
Clearance is done (including SGA, lazy consensus vote on general@incubator,
etc.), and then finally code is committed if everything is fine.
That's why I started this at first, and I think there's consensus around
the need of an IP Clearance.

Tommaso


2013/11/13 Tobias Bocanegra 

> -1 (non binding) as no http://incubator.apache.org/ip-clearance/ is
> filed. this has to be done before voting for contribution. also, we
> (Adobe) should also provide a software grant prior to this.
>
> Regards, Toby
>
> On Tue, Nov 12, 2013 at 5:07 AM, Justin Edelson
>  wrote:
> > +1
> >
> > Agree with Bertrand and Dominik's comments 100%.
> >
> > On Tue, Nov 12, 2013 at 5:20 AM, Bertrand Delacretaz
> >  wrote:
> >> Hi,
> >> On Mon, Nov 11, 2013 at 3:02 PM, Tommaso Teofili
> >>  wrote:
> >>
> >>> ...as per discussions on SLING-3223 [1] I'm opening the vote for
> accepting the
> >>> Sling replication module for inclusion in Apache Sling project...
> >>
> >> +1, conditional to doing an IP clearance as per
> >> http://incubator.apache.org/ip-clearance/
> >>
> >> There's room for some improvements as discussed in SLING-3223, but I
> >> think we should import the module once the IP clearance is done, and
> >> work from that.
> >>
> >> BTW the digest of the patch is:
> >>
> >> SHA1(SLING-3223.patch.txt)= ee628f4556c71c19fa09ae4e58fc7b32182da11b
> >>
> >> -Bertrand
>

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

[Apache Jenkins Server]

See 


--
[INFO] Deleting 

[INFO] Deleting 

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [ANN] New committer: Amit Gupta

[Chetan Mehrotra]

Congratulations and Welcome Amit !

Chetan Mehrotra


On Thu, Nov 14, 2013 at 8:56 AM, Felix Meschberger  wrote:
> Hi all
>
> This is a message long overdue. Sorry for the delay !
>
> Based on his ongoing and valuable contributions to the project, the Sling PMC 
> has elected Amit Gupta (amitgupt) as a Sling committer, and he has accepted 
> the invitation. Please join me in welcoming him!
>
> Amit, if you want to honor the old tradition of new committers briefly 
> introducing themselves to the list, feel free. I assume you got this info 
> already, but just in case the new committers info is at 
> http://www.apache.org/dev/new-committers-guide.html and generally under 
> http://www.apache.org/dev/ - and feel free to ask if you have any questions.
>
> Regards
> Felix

[ANN] New committer: Amit Gupta

[Felix Meschberger]

Hi all

This is a message long overdue. Sorry for the delay !

Based on his ongoing and valuable contributions to the project, the Sling PMC 
has elected Amit Gupta (amitgupt) as a Sling committer, and he has accepted the 
invitation. Please join me in welcoming him!

Amit, if you want to honor the old tradition of new committers briefly 
introducing themselves to the list, feel free. I assume you got this info 
already, but just in case the new committers info is at 
http://www.apache.org/dev/new-committers-guide.html and generally under 
http://www.apache.org/dev/ - and feel free to ask if you have any questions.

Regards
Felix

Re: FYI: feature flags prototype

[Felix Meschberger]

Hi

I agree that it would be cool to also select resources based on features. But I 
think the access gate is the wrong mechanism: Access Control and Feature 
Selection are different beasts and should not be mixed.

Rather I could imagine backing this into the ResourceResolver itself: before 
returning a Resource it is checked for a feature flag property  (e.g. 
sling:feature ?) and this being checked against the Feature service. If not 
enabled, that resource is „hidden“ and not returned.

WDYT ?

Regards
Felix

—
Felix Meschberger  |  Principal Scientist  |  Adobe



Am 14.11.2013 um 02:21 schrieb Dominik Süß :

> Hi Ruben,
> 
> the intention is to disable features that are not should not be globally
> available but might be activated under certain conditions. This reduces the
> need to branch non-production ready features away and merge them in later
> and opens the option to have something like a "Friendly user Test" or
> softlaunch of a feature. Therefore this can be something big or something
> small. I think a solution should be capable of dealing with both. The java
> API would allow to hook in at any granularity level of the application so
> this already fullfills the requirements I'd have. Adding a corresponding
> declarative logic to filter the resourcetree would give the same coarse
> and/or finegrained filtermechanism to the resolutionprocess.
> 
> What still would be missing is controlling updates and not just additions.
> e.g. when a resource should be rendered by a new version of a resourceType
> - in such case it might be an option to extend the searchpath from
> /libs/../myresourcetype, /apps/../myresourcetype by featurespecific
> overlaypaths that would either be searched when a feature is activated or
> hidden if the feature is deactivated. This would require refactoring later
> on but would allow parallel existance of multiple versions of a
> resourceType.
> 
> Best regards,
> Dominik
> 
> 
> 
> 
> On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser  wrote:
> 
>> Bertrand, Dominik,
>> 
>> the feature flag may also have an impact on the nodes/properties that you
>> need to render the feature. Being able to handle this in the resource tree
>> directly without having to handle it in component code would be great.
>> However, I am not sure if the intention of the feature flag was more to
>> enable/change little features (code fragment) and not really change big
>> things (leave that to test&target or other products?)
>> 
>> Ruben
>> 
>> 
>> On 11/13/2013 6:32 AM, Dominik Süß wrote:
>> 
>>> Hi Bertrand,
>>> 
>>> the UI of an application based on Sling are often composed of existing
>>> resourceTypes so you cannot just decide in the code to display or not to
>>> display so you have to "annotate"/"flag" the resources and then have some
>>> code deciding if this resource should be rendered or not. For sure you
>>> could add code to each resource to check if it is to be rendered but this
>>> is a lot of repetive code. Another option would be a Servlet filter to
>>> skip
>>> inclusion at that Point. But this all fails in some situations like
>>> whenyou
>>> consume an aggregated json dump and use this on client side. Therefore the
>>> only shared location that all code should act on when looking at the
>>> persistance is the resourcetree, and as already existing API the Access
>>> Gate API seems to be capable of doing exactly what is required - masking
>>> the resourcetree based on custom logic.
>>> 
>>> Best regards
>>> Dominik
>>> 
>>> 
>>> On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz <
>>> bdelacre...@apache.org> wrote:
>>> 
>>> Hi Dominik,
 
 On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß 
 wrote:
 
> ...as far as I can see the API is just covering the java aspect of
> 
 this...
 
 Nothing prevents you from using the FeatureFlags service in scripted
 code.
 
 you could have a gate looking for a marker at a resource
> which indicates it to be part of a specific feature and therefore
> 
 disables
 
> access to it
> 
 Do we need any changes to Sling or to this new API to enable that?
 
 The problem IMO is that this makes the whole thing less transparent
 than using feature flags in the rendering code. OTOH if people can
 implement it themselves (and add the corresponding info to
 RequestProgressTracker) for transparency, I don't mind.
 
 -Bertrand
 
 
>> 

[jira] [Commented] (SLING-3148) Implement support for Feature Flags/Toggles in Sling

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-3148:
--

... archived here: http://sling.markmail.org/thread/ldrvfd2elo53ta6b

> Implement support for Feature Flags/Toggles in Sling
> 
>
> Key: SLING-3148
> URL: https://issues.apache.org/jira/browse/SLING-3148
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Henry Saginor
>Priority: Minor
>
> It would be nice if sling provide support for feature flags (also called 
> toggles) pattern [1].
> I am thinking the implementation could provide the following.
> 1) Integrate an existing framework such as togglz [2] or implement something 
> similar with UI/Configuration to toggle features.
> 2) Create a jcr property (sling:Feature) which can be added to resource type 
> nodes. Then some conditional logic in , and get and post 
> servlets determines if the resource should be rendered if its resource type 
> contains such property.
> [1] http://en.wikipedia.org/wiki/Feature_toggle
> [2] http://www.togglz.org/



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

Re: Update the Slf4j API bundle to 1.7.5

[Felix Meschberger]

Hi

That worries me.

We have long refused to update the JCR API reference in the parent POM on the 
grounds to not have a global requirement for JCR 2 API enforced upon all 
bundles.

So, if we can configure the parent POM such, that it also presets the org.slf4j 
package imports appropriately, I am fine. If we cannot do that, I would not 
update the parent POM. Otherwise I am even inclined to say that we should 
remove the slf4j-api from the parent pom’s dependency management.

Regards
Felix

—
Felix Meschberger  |  Principal Scientist  |  Adobe



Am 14.11.2013 um 02:58 schrieb Chetan Mehrotra :

> I have done the required changes as part of SLING-3243. However one
> area is pending
> 
> The Sling Parent pom.xml pins the slf4j-api bundle at 1.5.2. To make
> use of new varargs support as part of slf4j api 1.7.5 (it now uses JDK
> 1.5) we would need to update this version. Note that at binary level
> usage of new vararg support does not cause any change. Quoting from
> Slf4j site
> 
> ---
> Printing methods in the Logger interface now offers variants accepting
> varargs instead of Object[]. Given that under the hood, the Java
> compiler transforms varargs into an array, this change is totally 100%
> no-ifs-or-buts backward compatible with all existing client code.
> ---
> 
> However if I change the version in parent then bnd would change the
> version range for slf4j api to [1.7,2) from [1.6,2).
> 
> So if any bundle wants to make use of new API and still wants to be
> deployed on Sling based system where slf4j API is 1.6.4 then best way
> would be to use version macro
> 
> org.osgi.framework;version="[${version;=-;${@}},${version;+;${@}})"
> 
> OR
> 
> org.osgi.framework;version="$"
> 
> Note usage of "=-" instead of "==" to decrement the minor version
> 
> Would this be the right way to tackle that or one should use a different way?
> 
> Chetan Mehrotra
> 
> 
> On Wed, Nov 13, 2013 at 6:42 PM, Felix Meschberger  wrote:
>> Sounds reasonable to me.
>> 
>> Regards
>> Felix
>> 
>> —
>> Felix Meschberger  |  Principal Scientist  |  Adobe
>> 
>> 
>> 
>> Am 13.11.2013 um 21:17 schrieb Chetan Mehrotra :
>> 
>>> Currently Sling is packaging 1.6.4 for the slf4j-api. Most recent
>>> release is 1.7.5 and has some noteworthy changes [1] including
>>> performance, usage of varargs etc. The core API bundle has no
>>> compatibility breaking change.
>>> 
>>> Slf4j bundle maps the package exports to bundle version. So with 1.7.5
>>> the packages are exported at 1.7.5
>>> 
>>> I checked the Import-Package directive of most Sling bundle and all of
>>> them have import range from [1.5,2). So should we move to 1.7.5?
>>> 
>>> The steps I see is
>>> - Update the slf4j-api, jcl-over-slf4j, log4j-over-slf4j bundle
>>> - Ensure that commons log work with both
>>> 
>>> WDYT?
>>> 
>>> Chetan Mehrotra
>>> [1] http://www.slf4j.org/news.html
>> 

Re: [VOTE] - Accept donation of replication module to Apache Sling

[Tobias Bocanegra]

-1 (non binding) as no http://incubator.apache.org/ip-clearance/ is
filed. this has to be done before voting for contribution. also, we
(Adobe) should also provide a software grant prior to this.

Regards, Toby

On Tue, Nov 12, 2013 at 5:07 AM, Justin Edelson
 wrote:
> +1
>
> Agree with Bertrand and Dominik's comments 100%.
>
> On Tue, Nov 12, 2013 at 5:20 AM, Bertrand Delacretaz
>  wrote:
>> Hi,
>> On Mon, Nov 11, 2013 at 3:02 PM, Tommaso Teofili
>>  wrote:
>>
>>> ...as per discussions on SLING-3223 [1] I'm opening the vote for accepting 
>>> the
>>> Sling replication module for inclusion in Apache Sling project...
>>
>> +1, conditional to doing an IP clearance as per
>> http://incubator.apache.org/ip-clearance/
>>
>> There's room for some improvements as discussed in SLING-3223, but I
>> think we should import the module once the IP clearance is done, and
>> work from that.
>>
>> BTW the digest of the patch is:
>>
>> SHA1(SLING-3223.patch.txt)= ee628f4556c71c19fa09ae4e58fc7b32182da11b
>>
>> -Bertrand

Re: buildbot failure in ASF Buildbot on sling-trunk

[Bertrand Delacretaz]

On Wednesday, November 13, 2013, Chetan Mehrotra wrote:

> ...Failed tests:
>
testDeferredConfigInstall(org.apache.sling.installer.it.ConfigInstallTest):
> Config must be removed once ConfigurationAdmin restarts: Configuration
>  is still present (ConfigInstallTest.deferred.1384357592923)...

I have reopened SLING-1794 which is about this, looks like a rare
intermittent issue.
>
>
-Bertrand

[jira] [Updated] (SLING-1794) ConfigInstallTest fails: Config must be removed once ConfigurationAdmin restarts: Configuration is still present

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-1794:
---

Attachment: stdio.txt

> ConfigInstallTest fails: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present
> 
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Bertrand Delacretaz
>  Labels: it,intermittent
> Attachments: stdio.txt
>
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



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

[jira] [Comment Edited] (SLING-1794) ConfigInstallTest fails: Config must be removed once ConfigurationAdmin restarts: Configuration is still present

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-1794 at 11/13/13 4:43 PM:
--

Just saw this again on a buildbot build: 
http://ci.apache.org/builders/sling-trunk/builds/5/steps/compile/logs/stdio

I'll attach the logs, which indicate that the config is indeed deleted 
(15:46:34.982), but the test still times out after 5 seconds (15:46:39.995) 
thinking the config still exists. No idea why, and it looks like this happens 
quite rarely now.




was (Author: bdelacretaz):
Just saw this again on a buildbot build: 
http://ci.apache.org/builders/sling-trunk/builds/5/steps/compile/logs/stdio

I'll attach the logs, which indicate that the config is indeed deleted, but the 
test still times out after 5 seconds thinking the config still exists. No idea 
why, and it looks like this happens quite rarely now.



> ConfigInstallTest fails: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present
> 
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Bertrand Delacretaz
>  Labels: it,intermittent
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



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

[jira] [Reopened] (SLING-1794) ConfigInstallTest fails: Config must be removed once ConfigurationAdmin restarts: Configuration is still present

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reopened SLING-1794:


  Assignee: Bertrand Delacretaz  (was: Robert Munteanu)

Just saw this again on a buildbot build: 
http://ci.apache.org/builders/sling-trunk/builds/5/steps/compile/logs/stdio

I'll attach the logs, which indicate that the config is indeed deleted, but the 
test still times out after 5 seconds thinking the config still exists. No idea 
why, and it looks like this happens quite rarely now.



> ConfigInstallTest fails: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present
> 
>
> Key: SLING-1794
> URL: https://issues.apache.org/jira/browse/SLING-1794
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Andreas Kuckartz
>Assignee: Bertrand Delacretaz
>  Labels: it,intermittent
>
> ---
> Test set: org.apache.sling.installer.it.ConfigInstallTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec 
> <<< FAILURE!
> testDeferredConfigInstall 
> [felix](org.apache.sling.installer.it.ConfigInstallTest)  Time elapsed: 
> 10.072 sec  <<< FAILURE!
> java.lang.AssertionError: Config must be removed once ConfigurationAdmin 
> restarts: Configuration is still present 
> (ConfigInstallTest.deferred.1285097628299)
> at org.junit.Assert.fail(Assert.java:74)
> at 
> org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246)
> at 
> org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> at 
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



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

Re: Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra]

I have done the required changes as part of SLING-3243. However one
area is pending

The Sling Parent pom.xml pins the slf4j-api bundle at 1.5.2. To make
use of new varargs support as part of slf4j api 1.7.5 (it now uses JDK
1.5) we would need to update this version. Note that at binary level
usage of new vararg support does not cause any change. Quoting from
Slf4j site

---
Printing methods in the Logger interface now offers variants accepting
varargs instead of Object[]. Given that under the hood, the Java
compiler transforms varargs into an array, this change is totally 100%
no-ifs-or-buts backward compatible with all existing client code.
---

However if I change the version in parent then bnd would change the
version range for slf4j api to [1.7,2) from [1.6,2).

So if any bundle wants to make use of new API and still wants to be
deployed on Sling based system where slf4j API is 1.6.4 then best way
would be to use version macro

org.osgi.framework;version="[${version;=-;${@}},${version;+;${@}})"

OR

org.osgi.framework;version="$"

Note usage of "=-" instead of "==" to decrement the minor version

Would this be the right way to tackle that or one should use a different way?

Chetan Mehrotra


On Wed, Nov 13, 2013 at 6:42 PM, Felix Meschberger  wrote:
> Sounds reasonable to me.
>
> Regards
> Felix
>
> —
> Felix Meschberger  |  Principal Scientist  |  Adobe
>
>
>
> Am 13.11.2013 um 21:17 schrieb Chetan Mehrotra :
>
>> Currently Sling is packaging 1.6.4 for the slf4j-api. Most recent
>> release is 1.7.5 and has some noteworthy changes [1] including
>> performance, usage of varargs etc. The core API bundle has no
>> compatibility breaking change.
>>
>> Slf4j bundle maps the package exports to bundle version. So with 1.7.5
>> the packages are exported at 1.7.5
>>
>> I checked the Import-Package directive of most Sling bundle and all of
>> them have import range from [1.5,2). So should we move to 1.7.5?
>>
>> The steps I see is
>> - Update the slf4j-api, jcl-over-slf4j, log4j-over-slf4j bundle
>> - Ensure that commons log work with both
>>
>> WDYT?
>>
>> Chetan Mehrotra
>> [1] http://www.slf4j.org/news.html
>

Re: buildbot failure in ASF Buildbot on sling-trunk

[Chetan Mehrotra]

Build failed due to following reason

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.195 sec

Results :

Failed tests:
testDeferredConfigInstall(org.apache.sling.installer.it.ConfigInstallTest):
Config must be removed once ConfigurationAdmin restarts: Configuration
is still present (ConfigInstallTest.deferred.1384357592923)

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

So probably not related to the change in Slf4j API. Would see further
on why it got failed
Chetan Mehrotra


On Wed, Nov 13, 2013 at 9:16 PM,   wrote:
> The Buildbot has detected a new failure on builder sling-trunk while building 
> ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/sling-trunk/builds/5
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: osiris_ubuntu
>
> Build Reason: forced: by IRC user  (privmsg): do we still have 
> semi-random failures?
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed compile
>
> sincerely,
>  -The Buildbot
>
>
>

buildbot failure in ASF Buildbot on sling-trunk

[buildbot]

The Buildbot has detected a new failure on builder sling-trunk while building 
ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/sling-trunk/builds/5

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: osiris_ubuntu

Build Reason: forced: by IRC user  (privmsg): do we still have semi-random 
failures?
Build Source Stamp: HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

Re: Failure while running integration test

[Chetan Mehrotra]

If I build 'sling/launchpad/integration-tests' then it fixes the
issue. So problem resolved for now. Looks like I was having a stale
snapshot
Chetan Mehrotra


On Wed, Nov 13, 2013 at 8:48 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Wed, Nov 13, 2013 at 3:39 PM, Chetan Mehrotra
>  wrote:
>>> [ERROR] Caused by: java.lang.ClassNotFoundException:
>>> org.apache.sling.commons.testing.junit.categories.OakOnly
>>
>> Adding org.apache.sling.commons.testing as a dependency in the
>> integrationTesting profile seems to resolve the issue...
>
> Yes, makes sense - for now the integration tests are using a snapshot
> of commons.testing, so maybe building that one by hand before running
> the tests would have helped as well.
>
> Radu asked for a release of commons.testing as well, I'll try to
> prepare that release tomorrow to solve this in a cleaner way.
> -Bertrand

[jira] [Commented] (SLING-3148) Implement support for Feature Flags/Toggles in Sling

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3148:


Let's continue the discussion on the dev list for now, see the "FYI: feature 
flags prototype" thread there.

> Implement support for Feature Flags/Toggles in Sling
> 
>
> Key: SLING-3148
> URL: https://issues.apache.org/jira/browse/SLING-3148
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Henry Saginor
>Priority: Minor
>
> It would be nice if sling provide support for feature flags (also called 
> toggles) pattern [1].
> I am thinking the implementation could provide the following.
> 1) Integrate an existing framework such as togglz [2] or implement something 
> similar with UI/Configuration to toggle features.
> 2) Create a jcr property (sling:Feature) which can be added to resource type 
> nodes. Then some conditional logic in , and get and post 
> servlets determines if the resource should be rendered if its resource type 
> contains such property.
> [1] http://en.wikipedia.org/wiki/Feature_toggle
> [2] http://www.togglz.org/



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

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Ruben,

the intention is to disable features that are not should not be globally
available but might be activated under certain conditions. This reduces the
need to branch non-production ready features away and merge them in later
and opens the option to have something like a "Friendly user Test" or
softlaunch of a feature. Therefore this can be something big or something
small. I think a solution should be capable of dealing with both. The java
API would allow to hook in at any granularity level of the application so
this already fullfills the requirements I'd have. Adding a corresponding
declarative logic to filter the resourcetree would give the same coarse
and/or finegrained filtermechanism to the resolutionprocess.

What still would be missing is controlling updates and not just additions.
e.g. when a resource should be rendered by a new version of a resourceType
- in such case it might be an option to extend the searchpath from
/libs/../myresourcetype, /apps/../myresourcetype by featurespecific
overlaypaths that would either be searched when a feature is activated or
hidden if the feature is deactivated. This would require refactoring later
on but would allow parallel existance of multiple versions of a
resourceType.

Best regards,
Dominik




On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser  wrote:

> Bertrand, Dominik,
>
> the feature flag may also have an impact on the nodes/properties that you
> need to render the feature. Being able to handle this in the resource tree
> directly without having to handle it in component code would be great.
> However, I am not sure if the intention of the feature flag was more to
> enable/change little features (code fragment) and not really change big
> things (leave that to test&target or other products?)
>
> Ruben
>
>
> On 11/13/2013 6:32 AM, Dominik Süß wrote:
>
>> Hi Bertrand,
>>
>> the UI of an application based on Sling are often composed of existing
>> resourceTypes so you cannot just decide in the code to display or not to
>> display so you have to "annotate"/"flag" the resources and then have some
>> code deciding if this resource should be rendered or not. For sure you
>> could add code to each resource to check if it is to be rendered but this
>> is a lot of repetive code. Another option would be a Servlet filter to
>> skip
>> inclusion at that Point. But this all fails in some situations like
>> whenyou
>> consume an aggregated json dump and use this on client side. Therefore the
>> only shared location that all code should act on when looking at the
>> persistance is the resourcetree, and as already existing API the Access
>> Gate API seems to be capable of doing exactly what is required - masking
>> the resourcetree based on custom logic.
>>
>> Best regards
>> Dominik
>>
>>
>> On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz <
>> bdelacre...@apache.org> wrote:
>>
>>  Hi Dominik,
>>>
>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß 
>>> wrote:
>>>
 ...as far as I can see the API is just covering the java aspect of

>>> this...
>>>
>>> Nothing prevents you from using the FeatureFlags service in scripted
>>> code.
>>>
>>>  you could have a gate looking for a marker at a resource
 which indicates it to be part of a specific feature and therefore

>>> disables
>>>
 access to it

>>> Do we need any changes to Sling or to this new API to enable that?
>>>
>>> The problem IMO is that this makes the whole thing less transparent
>>> than using feature flags in the rendering code. OTOH if people can
>>> implement it themselves (and add the corresponding info to
>>> RequestProgressTracker) for transparency, I don't mind.
>>>
>>> -Bertrand
>>>
>>>
>

Re: Failure while running integration test

[Bertrand Delacretaz]

Hi,

On Wed, Nov 13, 2013 at 3:39 PM, Chetan Mehrotra
 wrote:
>> [ERROR] Caused by: java.lang.ClassNotFoundException:
>> org.apache.sling.commons.testing.junit.categories.OakOnly
>
> Adding org.apache.sling.commons.testing as a dependency in the
> integrationTesting profile seems to resolve the issue...

Yes, makes sense - for now the integration tests are using a snapshot
of commons.testing, so maybe building that one by hand before running
the tests would have helped as well.

Radu asked for a release of commons.testing as well, I'll try to
prepare that release tomorrow to solve this in a cleaner way.
-Bertrand

Re: FYI: feature flags prototype

[Ruben Reusser]

Bertrand, Dominik,

the feature flag may also have an impact on the nodes/properties that 
you need to render the feature. Being able to handle this in the 
resource tree directly without having to handle it in component code 
would be great. However, I am not sure if the intention of the feature 
flag was more to enable/change little features (code fragment) and not 
really change big things (leave that to test&target or other products?)


Ruben

On 11/13/2013 6:32 AM, Dominik Süß wrote:

Hi Bertrand,

the UI of an application based on Sling are often composed of existing
resourceTypes so you cannot just decide in the code to display or not to
display so you have to "annotate"/"flag" the resources and then have some
code deciding if this resource should be rendered or not. For sure you
could add code to each resource to check if it is to be rendered but this
is a lot of repetive code. Another option would be a Servlet filter to skip
inclusion at that Point. But this all fails in some situations like whenyou
consume an aggregated json dump and use this on client side. Therefore the
only shared location that all code should act on when looking at the
persistance is the resourcetree, and as already existing API the Access
Gate API seems to be capable of doing exactly what is required - masking
the resourcetree based on custom logic.

Best regards
Dominik


On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:


Hi Dominik,

On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß 
wrote:

...as far as I can see the API is just covering the java aspect of

this...

Nothing prevents you from using the FeatureFlags service in scripted code.


you could have a gate looking for a marker at a resource
which indicates it to be part of a specific feature and therefore

disables

access to it

Do we need any changes to Sling or to this new API to enable that?

The problem IMO is that this makes the whole thing less transparent
than using feature flags in the rendering code. OTOH if people can
implement it themselves (and add the corresponding info to
RequestProgressTracker) for transparency, I don't mind.

-Bertrand

[jira] [Comment Edited] (SLING-3243) Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra edited comment on SLING-3243 at 11/13/13 2:49 PM:
--

Did the required changes in rev 1541534 and 1541535. The common.log imports 
org.slf4j packages in version range [1.6,1.8)

All testcase seem to pass

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



was (Author: chetanm):
Did the required changes in rev 1541534 and 1541535. The common.log imports 
org.slf4j packages in version range [1.6,1.8)

> Update the Slf4j API bundle to 1.7.5
> 
>
> Key: SLING-3243
> URL: https://issues.apache.org/jira/browse/SLING-3243
> Project: Sling
>  Issue Type: Task
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> We should update the Slf4j API bundle and other slf4j bundle to there latest 
> release of 1.7.5 [1]. 
> One problem with Slf4j is that it exports package with version matching the 
> jar version. So with 1.7.5 the packages are also exported at 1.7.5. So it 
> might pose problem for bundle which import with smaller range like [1.6.0,1.7)
> See http://markmail.org/thread/vu4uoiln4z4f3mms



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

[jira] [Commented] (SLING-3243) Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-3243:


Did the required changes in rev 1541534 and 1541535. The common.log imports 
org.slf4j packages in version range [1.6,1.8)

> Update the Slf4j API bundle to 1.7.5
> 
>
> Key: SLING-3243
> URL: https://issues.apache.org/jira/browse/SLING-3243
> Project: Sling
>  Issue Type: Task
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> We should update the Slf4j API bundle and other slf4j bundle to there latest 
> release of 1.7.5 [1]. 
> One problem with Slf4j is that it exports package with version matching the 
> jar version. So with 1.7.5 the packages are also exported at 1.7.5. So it 
> might pose problem for bundle which import with smaller range like [1.6.0,1.7)
> See http://markmail.org/thread/vu4uoiln4z4f3mms



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

Re: Failure while running integration test

[Chetan Mehrotra]

> [ERROR] Caused by: java.lang.ClassNotFoundException:
> org.apache.sling.commons.testing.junit.categories.OakOnly

Adding org.apache.sling.commons.testing as a dependency in the
integrationTesting profile seems to resolve the issue
Chetan Mehrotra


On Wed, Nov 13, 2013 at 7:24 PM, Chetan Mehrotra
 wrote:
> Hi,
>
> I am try to run integration test by executing following command at
> launchpad/testing
>
> mvn clean install
>
> However it results in following exception. Is this the right way to
> test or I need to follow some other steps
>
> [INFO] 
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
> (default) on project org.apache.sling.launchpad.testing: Execution
> default of goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
> failed: There was an error in the forked process
> [ERROR] java.lang.RuntimeException: Unable to load category:
> org.apache.sling.commons.testing.junit.categories.OakOnly
> [ERROR] at 
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> [ERROR] at 
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:94)
> [ERROR] at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:177)
> [ERROR] at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:113)
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> [ERROR] Caused by: java.lang.ClassNotFoundException:
> org.apache.sling.commons.testing.junit.categories.OakOnly
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> [ERROR] at java.security.AccessController.doPrivileged(Native Method)
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> [ERROR] at 
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> [ERROR] ... 6 more
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>
> Chetan Mehrotra

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Bertrand,

the UI of an application based on Sling are often composed of existing
resourceTypes so you cannot just decide in the code to display or not to
display so you have to "annotate"/"flag" the resources and then have some
code deciding if this resource should be rendered or not. For sure you
could add code to each resource to check if it is to be rendered but this
is a lot of repetive code. Another option would be a Servlet filter to skip
inclusion at that Point. But this all fails in some situations like whenyou
consume an aggregated json dump and use this on client side. Therefore the
only shared location that all code should act on when looking at the
persistance is the resourcetree, and as already existing API the Access
Gate API seems to be capable of doing exactly what is required - masking
the resourcetree based on custom logic.

Best regards
Dominik


On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:

> Hi Dominik,
>
> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß 
> wrote:
> > ...as far as I can see the API is just covering the java aspect of
> this...
>
> Nothing prevents you from using the FeatureFlags service in scripted code.
>
> > you could have a gate looking for a marker at a resource
> > which indicates it to be part of a specific feature and therefore
> disables
> > access to it
>
> Do we need any changes to Sling or to this new API to enable that?
>
> The problem IMO is that this makes the whole thing less transparent
> than using feature flags in the rendering code. OTOH if people can
> implement it themselves (and add the corresponding info to
> RequestProgressTracker) for transparency, I don't mind.
>
> -Bertrand
>

Failure while running integration test

[Chetan Mehrotra]

Hi,

I am try to run integration test by executing following command at
launchpad/testing

mvn clean install

However it results in following exception. Is this the right way to
test or I need to follow some other steps

[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
(default) on project org.apache.sling.launchpad.testing: Execution
default of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.16:integration-test
failed: There was an error in the forked process
[ERROR] java.lang.RuntimeException: Unable to load category:
org.apache.sling.commons.testing.junit.categories.OakOnly
[ERROR] at 
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
[ERROR] at 
org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:94)
[ERROR] at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:177)
[ERROR] at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:113)
[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
[ERROR] Caused by: java.lang.ClassNotFoundException:
org.apache.sling.commons.testing.junit.categories.OakOnly
[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
[ERROR] at java.security.AccessController.doPrivileged(Native Method)
[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[ERROR] at 
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
[ERROR] ... 6 more
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException

Chetan Mehrotra

Re: Update the Slf4j API bundle to 1.7.5

[Felix Meschberger]

Sounds reasonable to me.

Regards
Felix

—
Felix Meschberger  |  Principal Scientist  |  Adobe



Am 13.11.2013 um 21:17 schrieb Chetan Mehrotra :

> Currently Sling is packaging 1.6.4 for the slf4j-api. Most recent
> release is 1.7.5 and has some noteworthy changes [1] including
> performance, usage of varargs etc. The core API bundle has no
> compatibility breaking change.
> 
> Slf4j bundle maps the package exports to bundle version. So with 1.7.5
> the packages are exported at 1.7.5
> 
> I checked the Import-Package directive of most Sling bundle and all of
> them have import range from [1.5,2). So should we move to 1.7.5?
> 
> The steps I see is
> - Update the slf4j-api, jcl-over-slf4j, log4j-over-slf4j bundle
> - Ensure that commons log work with both
> 
> WDYT?
> 
> Chetan Mehrotra
> [1] http://www.slf4j.org/news.html

Re: FYI: feature flags prototype

[Felix Meschberger]

Hi


Am 13.11.2013 um 23:12 schrieb Felix Meschberger :

> Hi Bertrand
> 
> Thanks. This looks like a promising start.
> 
> I have some comments, though ;-)
> 
> 1. My first reaction to the SlingHttpServletRequest argument was: Why an 
> argument ? Why not a ThreadLocal managed by the actual service with the help 
> of a request filter ? (ok, what to do with non-request services).
> 
> 2. I think the Providers should just register their known feature names as 
> string-service properties. Could there be more than one supported feature 
> actually ? Or is it really just a single one ? When using a service 
> registration property we can start with single-string and switch to 
> multi-value later without changing the API.
> 
> 3. Configuration: This is a good point brought up by Dominik: We want to have 
> central/singular configuration for the feature flags not spread them amongst 
> tons of providers. And we have configuration which is global (static) and we 
> have configuration which is per-user/group/time-of-day/random/whatever.
> 
> 4. Thinking about it: these providers actually just evaluate an expression 
> based on some configuration and some comparison object. Maybe there is a 
> better term than „Provider“ for these things.
> 
> 5. I understand FeatureFlags is actually the service we are interested in:
>  - How about calling that just Feature with then call 
> „Feature.isEnabled(FeatureX)“ then ?
>  - We should expose the Feature Service in the SlingBindings
>  - We should expose the Feature Service in the sling:defineObjects tag
>  - we should probably expose the Feature Service in some sling:feature JSP 
> tag 
> 
> 6. Re. Enums: On first sight this looks like a good idea. But it has the 
> drawback that it generates a package wiring dependency and requires the ENUMs 
> to be exported as API. What is the worst case szenarion of mis-typing a 
> feature ? I think, the feature will just never be enabled. (ok, another one 
> is that another unrelated feature might be enabled due to the typo — which 
> could be mitigated by stipulating features to have reasonably distinct names).

I forgot

7. FeatureFlagsProvider (or however it will be called) should just return 
boolean (scalar) not a wrapper. If the provider is called with an 
unsupported/unknown feature, it should just return false. This makes the code 
simpler, I think.

Regards
Felix

> 
> Regards
> Felix
> 
> —
> Felix Meschberger  |  Principal Scientist  |  Adobe
> 
> 
> 
> Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz :
> 
>> Hi,
>> 
>> FYI I have created a minimal prototype [2] of how I'd see feature
>> flags in Sling, as suggested a while ago by Henry Saginor in
>> SLING-3148.
>> 
>> The slides at [1], that Tommaso tweeted today, are full of good ideas
>> about this.
>> 
>> -Bertrand
>> 
>> [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf
>> 
>> [2] 
>> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
> 

Re: FYI: feature flags prototype

[Felix Meschberger]

Hi

Just a stupid idea:

> public final class Context {
> 
>public static Context from(SlingHttpServletRequest req) {
>   return new Context(req, ...);
>}
>...
>final SlingHttpServletRequest req;
>private Context(SlingHttpServletRequest req, ...) {
>   this.req = req;
>}
>public SlingHttpServletRequest getRequest() {
>   return this.req;
>}
>...
> }

And 

> isEnabled(String name, Context);

Or 

>public interface FeatureServer {
>   Features getFeatures(Context);
>}
>public interface Features {
>   boolean isEnabled(String name);
>}

(and the thing exposed in the SlingBindings (and thus the feature tag and the 
defineObjects tag) would be the Features object retrieved from the 
FeatureServer using the current request context.

Regards
Felix

Am 13.11.2013 um 22:13 schrieb Bertrand Delacretaz :

> Hi Tommaso,
> 
> On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili
>  wrote:
>> ...I agree it'd be nice to enable feature flags also on the resource (even if
>> I'm not too much convinced access gates are a good fit for it) and service
>> level, and design the API for that too
> 
> I thought about that (and Robert has a similar question above) and I'm
> not sure what the best option is.
> 
> We might go for three isEnabled methods:
> 
>  isEnabled(T featureFlagID, SlingHttpServletRequest request)
>  isEnabled(T featureFlagID, Resource resource)
>  isEnabled(T featureFlagID)
> 
> But that means all FeatureFlagsProviders need to implement all three
> methods, and some of them might not be relevant. Or create three
> provider interfaces, one for each signature above, and the
> FeatureFlags service sorts the providers according to which interfaces
> they implement.
> 
> Another option is
> 
>  /** @param context can be null */
>  isEnabled(T featureFlagID, Object context)
> 
> Which requires FeatureFlagsProviders to use downcasting, not fantastic either.
> 
> I agree with the need for feature flag providers to react to different
> types of contexts, not sure how to implement that...any suggestions?
> 
> -Bertrand

[jira] [Commented] (SLING-3148) Implement support for Feature Flags/Toggles in Sling

[JIRA]

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

Jörg Hoh commented on SLING-3148:
-

@Carsten: I currently see a problem, when I have 2 services A and B 
implementing the same interface, and I want to use service B in some cases, 
based on a feature flag. Or a service in 2 different versions, and I want to 
switch to the new version for some users/requests using a feature flag

AFAIK this is currently not possible.

> Implement support for Feature Flags/Toggles in Sling
> 
>
> Key: SLING-3148
> URL: https://issues.apache.org/jira/browse/SLING-3148
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Henry Saginor
>Priority: Minor
>
> It would be nice if sling provide support for feature flags (also called 
> toggles) pattern [1].
> I am thinking the implementation could provide the following.
> 1) Integrate an existing framework such as togglz [2] or implement something 
> similar with UI/Configuration to toggle features.
> 2) Create a jcr property (sling:Feature) which can be added to resource type 
> nodes. Then some conditional logic in , and get and post 
> servlets determines if the resource should be rendered if its resource type 
> contains such property.
> [1] http://en.wikipedia.org/wiki/Feature_toggle
> [2] http://www.togglz.org/



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

Re: FYI: feature flags prototype

[Felix Meschberger]

Hi Bertrand

Thanks. This looks like a promising start.

I have some comments, though ;-)

1. My first reaction to the SlingHttpServletRequest argument was: Why an 
argument ? Why not a ThreadLocal managed by the actual service with the help of 
a request filter ? (ok, what to do with non-request services).

2. I think the Providers should just register their known feature names as 
string-service properties. Could there be more than one supported feature 
actually ? Or is it really just a single one ? When using a service 
registration property we can start with single-string and switch to multi-value 
later without changing the API.

3. Configuration: This is a good point brought up by Dominik: We want to have 
central/singular configuration for the feature flags not spread them amongst 
tons of providers. And we have configuration which is global (static) and we 
have configuration which is per-user/group/time-of-day/random/whatever.

4. Thinking about it: these providers actually just evaluate an expression 
based on some configuration and some comparison object. Maybe there is a better 
term than „Provider“ for these things.

5. I understand FeatureFlags is actually the service we are interested in:
  - How about calling that just Feature with then call 
„Feature.isEnabled(FeatureX)“ then ?
  - We should expose the Feature Service in the SlingBindings
  - We should expose the Feature Service in the sling:defineObjects tag
  - we should probably expose the Feature Service in some sling:feature JSP tag 

6. Re. Enums: On first sight this looks like a good idea. But it has the 
drawback that it generates a package wiring dependency and requires the ENUMs 
to be exported as API. What is the worst case szenarion of mis-typing a feature 
? I think, the feature will just never be enabled. (ok, another one is that 
another unrelated feature might be enabled due to the typo — which could be 
mitigated by stipulating features to have reasonably distinct names).

Regards
Felix

—
Felix Meschberger  |  Principal Scientist  |  Adobe



Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz :

> Hi,
> 
> FYI I have created a minimal prototype [2] of how I'd see feature
> flags in Sling, as suggested a while ago by Henry Saginor in
> SLING-3148.
> 
> The slides at [1], that Tommaso tweeted today, are full of good ideas
> about this.
> 
> -Bertrand
> 
> [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf
> 
> [2] 
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags

Re: [jira] [Created] (SLING-3244) Upgrade sling.api in commons/testing

[Radu Cotescu]

Hi,

Since SLING-3244 was fixed could we also get a 2.0.16 release
for org.apache.sling.commons.testing?

Thanks,
Radu


On Wed, Nov 13, 2013 at 12:57 PM, Bertrand Delacretaz (JIRA) <
j...@apache.org> wrote:

> Bertrand Delacretaz created SLING-3244:
> --
>
>  Summary: Upgrade sling.api in commons/testing
>  Key: SLING-3244
>  URL: https://issues.apache.org/jira/browse/SLING-3244
>  Project: Sling
>   Issue Type: Bug
>   Components: Testing
> Affects Versions: Commons Testing 2.0.14
> Reporter: Bertrand Delacretaz
> Priority: Minor
>
>
> The commons/testing module still refers to org.apache.sling.api 2.1.0, so
> its mock classes are not compatible with later versions, which is
> troublesome when testing more modern code.
>
> The module should be updated to the latest sling.api, and mock classes
> adapted accordingly.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)
>

[jira] [Resolved] (SLING-3231) Not able to set multiple framework property via command line args

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-3231.


   Resolution: Fixed
Fix Version/s: Launchpad Base 2.5.2
 Assignee: Chetan Mehrotra

Fixed the issue with [r1541482|http://svn.apache.org/r1541482]

Following formats are supported
*  -Da1=b1 -Da2=b2
* -D a1=b1 -D a2=b2
 

> Not able to set multiple framework property via command line args
> -
>
> Key: SLING-3231
> URL: https://issues.apache.org/jira/browse/SLING-3231
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.5.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Launchpad Base 2.5.2
>
> Attachments: SLING-3231.patch
>
>
> Sling launchpad doc [1] mentions that multiple framework properties can be 
> specified via command line like "-D n=v". For current implementation this 
> leads to saving of last pair only.
> This appears to be a bug in parsing logic [2]. Patch to follow
> [1] 
> http://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html
> [2] http://markmail.org/thread/dtlzmnrcid4v3esy



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

Should ValueMapDecorator implement javax.jcr.Value semantics?

[Jeff Young]

I assume yes, but it doesn't for dates.

In particular, org.apache.jackrabbit.value.DateValue converts to ISO8601 when 
asked for a string, while ValueMapDecorator gives you the string format of the 
Calendar object.

Is this a bug, or should I interpret the "Value" in ValueMapDecorator more 
generically than a javax.jcr.Value?

Cheers,
Jeff.

PS: please cc: me on replies; I can't remember if I'm subscribed to the list or 
not

[jira] [Resolved] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-3049.


   Resolution: Fixed
Fix Version/s: Commons Log 4.0.0

Applied the patch and also added a testcase at rev r1541471

> Make Logback Stacktrace Packaging data support OSGi aware
> -
>
> Key: SLING-3049
> URL: https://issues.apache.org/jira/browse/SLING-3049
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>  Labels: logback
> Fix For: Commons Log 4.0.0
>
> Attachments: SLING-3049.patch
>
>
> Logback provides a useful feature where it dumps the Class packaging Data 
> along with the stacktrace [1]. This provides a quick view of the location 
> from where classes in a given stacktrace are coming. Its default logic does 
> not work properly in OSGi env. Hence it would be useful to patch its logic to 
> become OSGi aware
> [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData



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

Re: FYI: feature flags prototype

[Bertrand Delacretaz]

Hi Tommaso,

On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili
 wrote:
> ...I agree it'd be nice to enable feature flags also on the resource (even if
> I'm not too much convinced access gates are a good fit for it) and service
> level, and design the API for that too

I thought about that (and Robert has a similar question above) and I'm
not sure what the best option is.

We might go for three isEnabled methods:

  isEnabled(T featureFlagID, SlingHttpServletRequest request)
  isEnabled(T featureFlagID, Resource resource)
  isEnabled(T featureFlagID)

But that means all FeatureFlagsProviders need to implement all three
methods, and some of them might not be relevant. Or create three
provider interfaces, one for each signature above, and the
FeatureFlags service sorts the providers according to which interfaces
they implement.

Another option is

  /** @param context can be null */
  isEnabled(T featureFlagID, Object context)

Which requires FeatureFlagsProviders to use downcasting, not fantastic either.

I agree with the need for feature flag providers to react to different
types of contexts, not sure how to implement that...any suggestions?

-Bertrand

Re: FYI: feature flags prototype

[Bertrand Delacretaz]

Hi Robert,

On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu  wrote:
> ...1. I am typically wary of using Strings and am thinking that Enums
> would be a nice fit for feature flags...

I see your point, what's the reason? Performance? Risk of typos?

> ...how about having a FeatureFlag marker interface and them enums can
> implement it?...

The problem (and this isn't visible in my too contrived examples for
now) is that the feature flag names will mostly be defined by
configurations IMO.

For example, if you have a feature flag set by a cookie with a
specific value, the config would be:

  cookie name=foo
  value=bar
  feature flag name=foobar.cookie

And another instance of the same service would have different config
values and needs a unique feature flag ID.

Do you see a way of generating enums with unique and discoverable
values for such a case?

> ...2. Background services don't have access to a request but would
> probably still use feature flags. What would be a way around that?...

I'll reply to Tommaso's similar question.

-Bertrand

[jira] [Resolved] (SLING-3244) Upgrade sling.api in commons/testing

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-3244.


Resolution: Fixed

Changes committed in revision 1541469

> Upgrade sling.api in commons/testing 
> -
>
> Key: SLING-3244
> URL: https://issues.apache.org/jira/browse/SLING-3244
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Commons Testing 2.0.14
>Reporter: Bertrand Delacretaz
>Priority: Minor
>
> The commons/testing module still refers to org.apache.sling.api 2.1.0, so its 
> mock classes are not compatible with later versions, which is troublesome 
> when testing more modern code.
> The module should be updated to the latest sling.api, and mock classes 
> adapted accordingly.



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

Re: FYI: feature flags prototype

[Bertrand Delacretaz]

Hi Dominik,

On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß  wrote:
> ...as far as I can see the API is just covering the java aspect of this...

Nothing prevents you from using the FeatureFlags service in scripted code.

> you could have a gate looking for a marker at a resource
> which indicates it to be part of a specific feature and therefore disables
> access to it

Do we need any changes to Sling or to this new API to enable that?

The problem IMO is that this makes the whole thing less transparent
than using feature flags in the rendering code. OTOH if people can
implement it themselves (and add the corresponding info to
RequestProgressTracker) for transparency, I don't mind.

-Bertrand

[jira] [Created] (SLING-3244) Upgrade sling.api in commons/testing

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3244:
--

 Summary: Upgrade sling.api in commons/testing 
 Key: SLING-3244
 URL: https://issues.apache.org/jira/browse/SLING-3244
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Commons Testing 2.0.14
Reporter: Bertrand Delacretaz
Priority: Minor


The commons/testing module still refers to org.apache.sling.api 2.1.0, so its 
mock classes are not compatible with later versions, which is troublesome when 
testing more modern code.

The module should be updated to the latest sling.api, and mock classes adapted 
accordingly.



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

[jira] [Commented] (SLING-3231) Not able to set multiple framework property via command line args

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3231:


I don't have a very strong opinion about -D or -F, as long as those who vote 
for -D take the burden of explaining that when people get in trouble with "java 
-Da=b -jar some.jar -Da=c" ;-)

> Not able to set multiple framework property via command line args
> -
>
> Key: SLING-3231
> URL: https://issues.apache.org/jira/browse/SLING-3231
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.5.0
>Reporter: Chetan Mehrotra
>Priority: Minor
> Attachments: SLING-3231.patch
>
>
> Sling launchpad doc [1] mentions that multiple framework properties can be 
> specified via command line like "-D n=v". For current implementation this 
> leads to saving of last pair only.
> This appears to be a bug in parsing logic [2]. Patch to follow
> [1] 
> http://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html
> [2] http://markmail.org/thread/dtlzmnrcid4v3esy



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

Re: Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra]

Yup would run the integration tests.

I have created SLING-3243 to track this.

Chetan Mehrotra
[1] https://issues.apache.org/jira/browse/SLING-3243

[jira] [Commented] (SLING-3243) Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-3243:


Based on above we need to take care of following bundle

Update to 1.7.5 release from Slf4j distribution
* jcl.over.slf4j - 
* slf4j.api 
* log4j.over.slf4j

Fix the package import directive
* org.apache.sling.commons.log


> Update the Slf4j API bundle to 1.7.5
> 
>
> Key: SLING-3243
> URL: https://issues.apache.org/jira/browse/SLING-3243
> Project: Sling
>  Issue Type: Task
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> We should update the Slf4j API bundle and other slf4j bundle to there latest 
> release of 1.7.5 [1]. 
> One problem with Slf4j is that it exports package with version matching the 
> jar version. So with 1.7.5 the packages are also exported at 1.7.5. So it 
> might pose problem for bundle which import with smaller range like [1.6.0,1.7)
> See http://markmail.org/thread/vu4uoiln4z4f3mms



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

[jira] [Commented] (SLING-3243) Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-3243:


Checking for the {{Import-Package}} directives of various bundles in Sling 
using [1] yields following result

|| Bundle Name || Package Name || Version ||
| org.apache.sling.settings | org.slf4j | [1.5,2) |
| org.apache.sling.installer.core | org.slf4j | [1.5,2) |
| jcl.over.slf4j | org.slf4j | 1.6.4 |
| jcl.over.slf4j | org.slf4j.spi | 1.6.4 |
| org.apache.sling.launchpad.installer | org.slf4j | [1.5,2) |
| slf4j.api | org.slf4j.impl | 1.6.0 |
| org.apache.sling.commons.logservice | org.slf4j | [1.5,2) |
| log4j.over.slf4j | org.slf4j | 1.6.0 |
| log4j.over.slf4j | org.slf4j.helpers | 1.6.0 |
| log4j.over.slf4j | org.slf4j.spi | 1.6.0 |
| org.apache.sling.commons.log | org.slf4j | [1.6,1.7) |
| org.apache.sling.commons.log | org.slf4j.spi | [1.6,1.7) |
| org.apache.sling.commons.log | org.slf4j.helpers | [1.6,2) |
| org.apache.sling.installer.provider.file | org.slf4j | 1.5 |
| org.apache.sling.javax.activation | org.slf4j | [1.5,2) |
| org.apache.felix.http.jetty | org.slf4j | null |
| org.apache.aries.jmx.whiteboard | org.slf4j | [1.5,2) |
| org.apache.sling.extensions.threaddump | org.slf4j | 1.5 |
| org.apache.sling.extensions.webconsolesecurityprovider | org.slf4j | 1.5 |
| org.apache.tika.bundle | org.slf4j | null |
| org.apache.sling.jcr.jackrabbit.server | org.slf4j | [1.5,2) |
| org.apache.jackrabbit.oak-core | org.slf4j | [1.6,2) |
| org.apache.jackrabbit.oak-lucene | org.slf4j | [1.6,2) |
| org.apache.jackrabbit.oak-mk | org.slf4j | [1.6,2) |
| org.apache.sling.jcr.oak.server | org.slf4j | [1.5,2) |
| org.apache.jackrabbit.jackrabbit-jcr-rmi | org.slf4j | [1.6,2) |
| org.apache.jackrabbit.jackrabbit-spi-commons | org.slf4j | [1.6,2) |
| org.apache.jackrabbit.jackrabbit-webdav | org.slf4j | [1.6,2) |
| org.apache.sling.jcr.base | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.davex | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.jackrabbit.accessmanager | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.jackrabbit.usermanager | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.registration | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.webdav | org.slf4j | [1.5,2) |
| org.apache.sling.adapter | org.slf4j | [1.5,2) |
| org.apache.sling.api | org.slf4j | [1.5,2) |
| org.apache.sling.auth.core | org.slf4j | [1.5,2) |
| org.apache.sling.auth.form | org.slf4j | [1.5,2) |
| org.apache.sling.auth.openid | org.slf4j | [1.5,2) |
| org.apache.sling.auth.selector | org.slf4j | [1.5,2) |
| org.apache.sling.bundleresource.impl | org.slf4j | [1.5,2) |
| org.apache.sling.commons.classloader | org.slf4j | 1.5 |
| org.apache.sling.commons.scheduler | org.slf4j | [1.5,2) |
| org.apache.sling.commons.threads | org.slf4j | [1.5,2) |
| org.apache.sling.discovery.impl | org.slf4j | [1.5,2) |
| org.apache.sling.engine | org.slf4j | [1.5,2) |
| org.apache.sling.event | org.slf4j | [1.5,2) |
| org.apache.sling.fsresource | org.slf4j | [1.5,2) |
| org.apache.sling.installer.factory.configuration | org.slf4j | [1.5,2) |
| org.apache.sling.installer.provider.jcr | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.classloader | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.contentloader | org.slf4j | [1.5,2) |
| org.apache.sling.jcr.ocm | org.slf4j | null |
| org.apache.sling.jcr.resource | org.slf4j | [1.5,2) |
| org.apache.sling.resourceresolver | org.slf4j | [1.5,2) |
| org.apache.sling.scripting.core | org.slf4j | [1.5,2) |
| org.apache.sling.scripting.javascript | org.slf4j | 1.5 |
| org.apache.sling.scripting.jsp | org.slf4j | [1.5,2) |
| org.apache.sling.scripting.jsp.taglib | org.slf4j | [1.5,2) |
| org.apache.sling.serviceusermapper | org.slf4j | [1.5,2) |
| org.apache.sling.servlets.get | org.slf4j | [1.5,2) |
| org.apache.sling.servlets.post | org.slf4j | [1.5,2) |
| org.apache.sling.servlets.resolver | org.slf4j | [1.5,2) |

[1] https://gist.github.com/chetanmeh/3748614#file-checkbundleforheader-groovy

> Update the Slf4j API bundle to 1.7.5
> 
>
> Key: SLING-3243
> URL: https://issues.apache.org/jira/browse/SLING-3243
> Project: Sling
>  Issue Type: Task
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> We should update the Slf4j API bundle and other slf4j bundle to there latest 
> release of 1.7.5 [1]. 
> One problem with Slf4j is that it exports package with version matching the 
> jar version. So with 1.7.5 the packages are also exported at 1.7.5. So it 
> might pose problem for bundle which import with smaller range like [1.6.0,1.7)
> See http://markmail.org/thread/vu4uoiln4z4f3mms



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

[jira] [Created] (SLING-3243) Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-3243:
--

 Summary: Update the Slf4j API bundle to 1.7.5
 Key: SLING-3243
 URL: https://issues.apache.org/jira/browse/SLING-3243
 Project: Sling
  Issue Type: Task
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra


We should update the Slf4j API bundle and other slf4j bundle to there latest 
release of 1.7.5 [1]. 

One problem with Slf4j is that it exports package with version matching the jar 
version. So with 1.7.5 the packages are also exported at 1.7.5. So it might 
pose problem for bundle which import with smaller range like [1.6.0,1.7)

See http://markmail.org/thread/vu4uoiln4z4f3mms





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

Re: Update the Slf4j API bundle to 1.7.5

[Bertrand Delacretaz]

On Wed, Nov 13, 2013 at 11:17 AM, Chetan Mehrotra
 wrote:
> ...The core API bundle has no
> compatibility breaking change...

>... I checked the Import-Package directive of most Sling bundle and all of
> them have import range from [1.5,2). So should we move to 1.7.5?...

I'd say yes, given the above there shouldn't be any problems. Please
check that our integration tests still run fine after your changes
(there's still some semi-random failures in them but it's getting much
better).

-Bertrand

Update the Slf4j API bundle to 1.7.5

[Chetan Mehrotra]

Currently Sling is packaging 1.6.4 for the slf4j-api. Most recent
release is 1.7.5 and has some noteworthy changes [1] including
performance, usage of varargs etc. The core API bundle has no
compatibility breaking change.

Slf4j bundle maps the package exports to bundle version. So with 1.7.5
the packages are exported at 1.7.5

I checked the Import-Package directive of most Sling bundle and all of
them have import range from [1.5,2). So should we move to 1.7.5?

The steps I see is
- Update the slf4j-api, jcl-over-slf4j, log4j-over-slf4j bundle
- Ensure that commons log work with both

WDYT?

Chetan Mehrotra
[1] http://www.slf4j.org/news.html

Re: FYI: feature flags prototype

[Tommaso Teofili]

Hi Bertrand,

it looks cool indeed!
I agree it'd be nice to enable feature flags also on the resource (even if
I'm not too much convinced access gates are a good fit for it) and service
level, and design the API for that too.
However I'm not sure how that could be done for services in general, maybe
it's overkill at this stage ?

My 2 cents,
Tommaso




2013/11/12 Bertrand Delacretaz 

> Hi,
>
> FYI I have created a minimal prototype [2] of how I'd see feature
> flags in Sling, as suggested a while ago by Henry Saginor in
> SLING-3148.
>
> The slides at [1], that Tommaso tweeted today, are full of good ideas
> about this.
>
> -Bertrand
>
> [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf
>
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags
>

[jira] [Resolved] (SLING-3047) Log message from other loggers get added to error.log

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-3047.


   Resolution: Fixed
Fix Version/s: Commons Log 4.0.0

> Log message from other loggers get added to error.log
> -
>
> Key: SLING-3047
> URL: https://issues.apache.org/jira/browse/SLING-3047
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Log 4.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
>  Labels: logback
> Fix For: Commons Log 4.0.0
>
> Attachments: SLING-3047.patch
>
>
> With new Logback based Log the error message for other categories like 
> "log.request" get added to error.log. This is happening because by default 
> Logback Loggers have additivity [1] set to true. For compatibility purpose 
> the additivity for Loggers configured vis OSGi config must be set to false
> [1] http://logback.qos.ch/manual/architecture.html#additivity



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

[jira] [Resolved] (SLING-3242) Allow refering to OSGi appenders from within Logback config

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-3242.


Resolution: Fixed

Added support in rev r1541422

It can be used in following manner

{code:xml}

  
  
  

  

  

...

{code}

In brief 
* Define a new action and map it to {{appender-ref-osgi ref}}
* Refer to the name of the OSGi based Appender using {{appender-ref-osgi ref}}

The implementation takes care of the OSGi service dynamics also i.e. when 
config is read then service might not be registered. So it would take care that 
when the service is registered then it is attached to appropriate loggers

> Allow refering to OSGi appenders from within Logback config
> ---
>
> Key: SLING-3242
> URL: https://issues.apache.org/jira/browse/SLING-3242
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Log 3.0.0
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 4.0.0
>
>
> Default Logback config only allows referring to appenders defined within the 
> config file. To enable better integration with OSGi it would be better if one 
> can refer to an appender which is implemented as an OSGi service from within 
> the config.
> In such case logging system must attach the appender to the logger whenever 
> the appender service is registered



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

[jira] [Created] (SLING-3242) Allow refering to OSGi appenders from within Logback config

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-3242:
--

 Summary: Allow refering to OSGi appenders from within Logback 
config
 Key: SLING-3242
 URL: https://issues.apache.org/jira/browse/SLING-3242
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 3.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Commons Log 4.0.0


Default Logback config only allows referring to appenders defined within the 
config file. To enable better integration with OSGi it would be better if one 
can refer to an appender which is implemented as an OSGi service from within 
the config.

In such case logging system must attach the appender to the logger whenever the 
appender service is registered



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