RE: [VOTE] Release Apache Sling Commons Log 4.0.0
+1 -Original Message- From: Chetan Mehrotra [mailto:chetan.mehro...@gmail.com] Sent: 18 November 2013 15:16 To: dev Subject: Re: [VOTE] Release Apache Sling Commons Log 4.0.0 +1 Chetan Mehrotra On Mon, Nov 18, 2013 at 3:14 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Hi, This is to vote for the Apache Sling Commons Log 4.0.0 release. This is the first release which uses Logback as the logging backend. The docs are up to date at http://sling.apache.org/documentation/development/logging.html Issues fixed https://issues.apache.org/jira/browse/SLING/fixforversion/12324947 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-150/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 150 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Chetan Mehrotra
[jira] [Updated] (SLING-3223) Donation of a replication module for Sling
[ https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3223: --- Description: Issue to track donation of a replication module for Sling. Discussion thread: http://markmail.org/thread/ic62k5pc34ppb5ko Vote on dev@sling thread: http://markmail.org/thread/scz5arlfs5rgowg2 was:Issue to track donation of a replication module for Sling, see thread at http://markmail.org/thread/ic62k5pc34ppb5ko Donation of a replication module for Sling -- Key: SLING-3223 URL: https://issues.apache.org/jira/browse/SLING-3223 Project: Sling Issue Type: Task Components: Extensions Reporter: Tommaso Teofili Attachments: SLING-3223.patch Issue to track donation of a replication module for Sling. Discussion thread: http://markmail.org/thread/ic62k5pc34ppb5ko Vote on dev@sling thread: http://markmail.org/thread/scz5arlfs5rgowg2 -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: New way of configuring Logging in Sling
Hi Justin, On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson jus...@justinedelson.com wrote: I don't see why logging requires going outside this practice. It didn't before Logback. Looks like there is some confusion around various ways with which logging can be configured with Logback. Logging with Logback is supporting all the following configuration modes 1. Configures itself with a pre packaged config file within the Bundle 2. Can be configured to configure Logback from a file on file system. This would allow one to customize it on a per Sling instance basis 3. Can be further extended via OSGi based config as has been supported by previous Logging impl [1] 4. Can be further extended via Config Fragments [2]. It supports an extension point to provide xml fragments from different source. Later we can add an impl which can look up config fragments in JCR repo and provide it to Common Log 5. Can be further extended via Appender/Filter registered as OSGi service What I was proposing that we modify the Launchpad support to dump an xml at pre defined location and allow users to customize it. However all other modes of configuring Logback would continue to work Chetan Mehrotra [1] http://sling.apache.org/documentation/development/logging.html#user-configuration-osgi-based [2] http://sling.apache.org/documentation/development/logging.html#logback-config-fragment-support
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Henry, the way understand Feature Flags as well as the comment from Roy is quite different: - Features can be content, java code, configuration or anything else that you would touch to introduce a new feature - Therefore the when a feature is turned off ist must be granted that (as far as technically possible) the feature has no impact on the behavior of the system (this might not be achivable since the only way of total removal of impact is not to release it, but the goal is to get as close as possible to this state) - Pure highlevel application checks cannot accomplish this since the plattform API would anyway call different logic and has to rely on the high level API to produce the same result (e.g. the resolutionprocess would be different between (a) the feature not being present at all (since there is no resource found) (b) the feature is disabled and a third logic (like a filter) needs to take care of this. I read Roy's comment that this is something required, but there is even more than that, like configuration which needs to be taken into account. But when looking at the area of resource resolving filtering the resourcetree in first place is as close as we can get to a similar behavior like non-existance. Best regards Dominik P.S. Isolation of JS logic isn't that hard, you just make sure that all plugins of a feature are included as one JS file. The hard part is request optimization where you might want to aggregate the plugins. This might be achivable by aggregations that have generated featurehashes in their URL (this way all users consuming the same featureset get the same aggregation so you still can cache). On Mon, Nov 18, 2013 at 11:43 PM, Henry Saginor hsagi...@gmail.com wrote: This is what I derive from your Roy's comments. It is not possible to predict all of the changes that might be conditioned via a flag. The context is really up to the application developers and their requirements. Applying feature flags at the resource level would only cover a particular set of changes. So, fundamentally all that the framework can do is provide a way to define flags, provide a switch panel and a way to extend it, and API to check flags in condition statements. How and where each flag is used is up to the developer of a specific application feature. Also, API for flag checking needs to be made available on both client and server without them calling each other. This can get tricky when we consider caching. On Nov 15, 2013, at 6:00 PM, Roy T. Fielding field...@gbiv.com wrote: On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote: You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Ack. IMO feature flags are clearly a high-level application, not infrastructure, aspect. Feature flags are a mechanism for isolating changes within a deployed system. Any part of that system. That means a feature flag needs to be able to condition any change that might be made to a system, including any change to the configuration files/data, any change to code monitoring the system, any change to the selection of data sources, any change to content (including everything as content), any change to a layout within any page or component, any change to the order in which things are done, any change to a report about what was done, and any change I haven't mentioned yet short of physically walking up to the server rack and unplugging the power by hand. In short, if it is content, it can be made conditional on the basis of a feature flag. That is the granularity of feature flag use. Separate from that is the feature flag flip switch (i.e., the set of ways that a given feature can be turned on) and the extent to which a feature becomes sticky per user once enabled for that user. You should expect a typical deployed site to have on the order of 1024 active feature flags. Hence, think carefully before choosing a verbose (or linear) mechanism for checking or remembering flags. Likewise, you should expect to have both a global setting for each flag and a per-user mask, and the person running the flip switch control panel needs to be able to choose from a) off for all users b) off for unassigned users c) proportional assignment to on (X out of N users, max M) d) logical (custom code) assignment to on e) on for unassigned users f) on for all users and be able to remember assignments per user, without requiring the user to login, and without assigning more
Re: [VOTE] - Accept donation of replication module to Apache Sling
+1 As with others, conditional on the correct process for IP clearance and grant being followed. Ian On 15 November 2013 09:30, Tommaso Teofili tommaso.teof...@gmail.com wrote: ok thanks, so we need one more binding vote (from a PMC member) to close this. Regards, Tommaso 2013/11/15 Tobias Bocanegra tri...@apache.org Hi Tommaso, thanks for the explanation - I didn't realize that you are in that early stage :-) I thought that the PMC already gave their OK to go forward with the donation. here's my non binding +1 then :-) Regards, Toby On Thu, Nov 14, 2013 at 1:48 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 8:37 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: 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... That's how I see it as well, hence my +1 conditional on doing the IP clearance. -Bertrand
[jira] [Updated] (SLING-3151) Add Junit JackrabbitOnly and OakOnly JUnit test categories
[ https://issues.apache.org/jira/browse/SLING-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3151: --- Affects Version/s: Commons Testing 2.0.14 Add Junit JackrabbitOnly and OakOnly JUnit test categories -- Key: SLING-3151 URL: https://issues.apache.org/jira/browse/SLING-3151 Project: Sling Issue Type: Sub-task Components: Testing Affects Versions: Commons Testing 2.0.14 Reporter: Antonio Sanso Assignee: Bertrand Delacretaz Fix For: Commons Testing 2.0.16 It would be nice to have a Junit JackrabbitOnly category in order to differentiate those tests that makes sense to be executed only in Sling running on Jackrabbit (and do not makes sense to run for Sling on Oak) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-3151) Add Junit JackrabbitOnly and OakOnly JUnit test categories
[ https://issues.apache.org/jira/browse/SLING-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3151: --- Fix Version/s: Commons Testing 2.0.16 Add Junit JackrabbitOnly and OakOnly JUnit test categories -- Key: SLING-3151 URL: https://issues.apache.org/jira/browse/SLING-3151 Project: Sling Issue Type: Sub-task Components: Testing Affects Versions: Commons Testing 2.0.14 Reporter: Antonio Sanso Assignee: Bertrand Delacretaz Fix For: Commons Testing 2.0.16 It would be nice to have a Junit JackrabbitOnly category in order to differentiate those tests that makes sense to be executed only in Sling running on Jackrabbit (and do not makes sense to run for Sling on Oak) -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: New way of configuring Logging in Sling
Hi Chetan, Thanks for this summary. Very helpful to understand the issues. Comments inline... On Tue, Nov 19, 2013 at 8:41 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Hi Justin, On Tue, Nov 19, 2013 at 5:55 PM, Justin Edelson jus...@justinedelson.com wrote: I don't see why logging requires going outside this practice. It didn't before Logback. Looks like there is some confusion around various ways with which logging can be configured with Logback. Logging with Logback is supporting all the following configuration modes 1. Configures itself with a pre packaged config file within the Bundle To which bundle is this referring? The Logback integration bundle? If so, when would this file be used? 2. Can be configured to configure Logback from a file on file system. This would allow one to customize it on a per Sling instance basis I think this functionality needs to be removed as it isn't consistent with the rest of Sling. 3. Can be further extended via OSGi based config as has been supported by previous Logging impl [1] 4. Can be further extended via Config Fragments [2]. It supports an extension point to provide xml fragments from different source. Later we can add an impl which can look up config fragments in JCR repo and provide it to Common Log This needs to be done against the resource resolver, not the JCR directly. And if you do that, then #2 isn't necessary as you can use the File System Resource Provider to point the configured resource path to a file system resource. In my opinion, these are showstoppers and warrant cancelling the release. Otherwise, we are stuck with a backwards compatibility issue. Regards, Justin 5. Can be further extended via Appender/Filter registered as OSGi service What I was proposing that we modify the Launchpad support to dump an xml at pre defined location and allow users to customize it. However all other modes of configuring Logback would continue to work Chetan Mehrotra [1] http://sling.apache.org/documentation/development/logging.html#user-configuration-osgi-based [2] http://sling.apache.org/documentation/development/logging.html#logback-config-fragment-support
Re: [VOTE] Release Apache Sling Commons Log 4.0.0
Hi On Mon, Nov 18, 2013 at 10:44 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: ...This is to vote for the Apache Sling Commons Log 4.0.0 release... I am -1 on this release, until we clarify the status of source code that's EPL-licensed in there. Will do that in a separate thread. -Bertrand
Re: New way of configuring Logging in Sling
1. Configures itself with a pre packaged config file within the Bundle To which bundle is this referring? The Logback integration bundle? If so, when would this file be used? It refers to the org.apache.sling.commons.log-4.0.0 bundle which packages a default logback.xml as part of bundle classpath. This file is used to bootstrap Logback 2. Can be configured to configure Logback from a file on file system. This would allow one to customize it on a per Sling instance basis I think this functionality needs to be removed as it isn't consistent with the rest of Sling. I disagree. This functionality proves to be quite useful in configuring Logging and I would not like that Logging system depends completely on any other system for configuration. At very minimum it should be possible to configure Logging without depending on any other support. One use would be in cluster deployment where to troubleshoot issue on a particular node an admin can start the system with specific logback.xml. It can use those Logback features which are not possible to configure via OSGi. This is similar to how so far JR2 configuration was handled via repository.xml and Repository bundle provided an option to provide a custom repository.xml for first startup. 4. Can be further extended via Config Fragments [2]. It supports an extension point to provide xml fragments from different source. Later we can add an impl which can look up config fragments in JCR repo and provide it to Common Log This needs to be done against the resource resolver, not the JCR directly. And if you do that, then #2 isn't necessary as you can use the File System Resource Provider to point the configured resource path to a file system resource. Commons Log bundle exposes an extension point and that can be implemented using any possible means. In Sling one can implement it against ResourceProvider also. However it would always be *one* of the option. In my opinion, these are showstoppers and warrant cancelling the release. Otherwise, we are stuck with a backwards compatibility issue. I still do not get the concern here. The Log bundle provides various means to configure Logback and users are free to use any of the means. Currently the Log bundle can has no dependency on Sling API and can easily be used in non Sling containers also. All these options are fully supported and well documented with backing testcase. regards Chetan
Re: New way of configuring Logging in Sling
Hi Chetan, On Tue, Nov 19, 2013 at 12:12 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: 1. Configures itself with a pre packaged config file within the Bundle To which bundle is this referring? The Logback integration bundle? If so, when would this file be used? It refers to the org.apache.sling.commons.log-4.0.0 bundle which packages a default logback.xml as part of bundle classpath. This file is used to bootstrap Logback 2. Can be configured to configure Logback from a file on file system. This would allow one to customize it on a per Sling instance basis I think this functionality needs to be removed as it isn't consistent with the rest of Sling. I disagree. This functionality proves to be quite useful in configuring Logging and I would not like that Logging system depends completely on any other system for configuration. At very minimum it should be possible to configure Logging without depending on any other support. One use would be in cluster deployment where to troubleshoot issue on a particular node an admin can start the system with specific logback.xml. It can use those Logback features which are not possible to configure via OSGi. As I said, if you want to configure logging using a file, you can do this with the File System Resource Provider. If you want to support directly loading from a file for bootstrapping purposes, i.e. there's a path in a framework property which is used until the ResourceResolverFactory is available, that's fine with me, but IMHO overkill as we already have the org.apache.sling.commons.log.level property which is there to help troubleshoot issues during bootstrapping. This is similar to how so far JR2 configuration was handled via repository.xml and Repository bundle provided an option to provide a custom repository.xml for first startup. 4. Can be further extended via Config Fragments [2]. It supports an extension point to provide xml fragments from different source. Later we can add an impl which can look up config fragments in JCR repo and provide it to Common Log This needs to be done against the resource resolver, not the JCR directly. And if you do that, then #2 isn't necessary as you can use the File System Resource Provider to point the configured resource path to a file system resource. Commons Log bundle exposes an extension point and that can be implemented using any possible means. In Sling one can implement it against ResourceProvider also. However it would always be *one* of the option. My point is that one shouldn't need to implement this. It needs to be a standard feature. And it should be documented as the secondary way to configure Logback, with ConfigAdmin being the primary way. In my opinion, these are showstoppers and warrant cancelling the release. Otherwise, we are stuck with a backwards compatibility issue. I still do not get the concern here. The Log bundle provides various means to configure Logback and users are free to use any of the means. Currently the Log bundle can has no dependency on Sling API and can easily be used in non Sling containers also. All these options are fully supported and well documented with backing testcase. As I said, my concern is one of consistency. The first goal of Sling log support should be to support Sling-based applications. If it can work outside of Sling, that would be nice to have, but IMHO is a non-goal, especially if it results in an inconsistency. Justin regards Chetan
Re: [VOTE] - Accept donation of replication module to Apache Sling
+1 Conditional on the IP process. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 12.11.2013 um 01:02 schrieb Tommaso Teofili tommaso.teof...@gmail.com: Hi all, 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 : accept its donation to Apache Sling [ ] +0 : don't care [ ] -1 : don't accept it because ... Vote is open for the next 72 hours. Looking forward to your votes. Regards, Tommaso [1] : https://issues.apache.org/jira/browse/SLING-3223
Re: New way of configuring Logging in Sling
Hi Justin, The point I am try to emphasize is that Log bundle sits at the lowest level of the bundle stack. At that level it cannot have a direct dependency on a layer (like ResourceResolver API) which is higher in the stack. It should only be dependent on OSGi Framework API. And having an xml based mechanism (completely optional) to configure Logback without depending on any other sub system would allow me to use its full feature set in troubleshooting issues. If Log system has to rely on a component like FileSystemResourceProvider (Sling API starts at Level 20) then that would make it much harder to debug startup issues say issues which occur when repository starts (start level 15). IMHO Log bundle must be robust and hence should not depend on external systems for core feature set. Further answers inline. On Tue, Nov 19, 2013 at 11:20 PM, Justin Edelson jus...@justinedelson.com wrote: Hi Chetan, As I said, if you want to configure logging using a file, you can do this with the File System Resource Provider. If you want to support directly loading from a file for bootstrapping purposes, i.e. there's a path in a framework property which is used until the ResourceResolverFactory is available, that's fine with me, but IMHO overkill as we already have the org.apache.sling.commons.log.level property which is there to help troubleshoot issues during bootstrapping. Tweaking the Log level to debug is just one of the various features. With Logback I can also enable logging of caller stack, MDC data, in line event evaluation etc which prove to be very useful for me in troubleshooting. And you never know what you might require to troubleshoot bootstrapping which in env like OSGi might be quite involved. And as explained above relying till the time File System Resource Provider comes up would not be good as it comes too late in the startup cycle. My point is that one shouldn't need to implement this. It needs to be a standard feature. And it should be documented as the secondary way to configure Logback, with ConfigAdmin being the primary way. As mentioned in starting Log bundle cannot directly depend on the Sling API. It can expose extension points which can be implemented by components which come later in startup. Having a bundle which collects Logback config fragments from JCR is on my ToDo list and would later be provided as part of Sling. ConfigAdmin is already supported directly. As I said, my concern is one of consistency. The first goal of Sling log support should be to support Sling-based applications. If it can work outside of Sling, that would be nice to have, but IMHO is a non-goal, especially if it results in an inconsistency. I still do not see the inconsistency. As mentioned earlier the logback.xml usage pattern is similar to how JR2 used to use repository.xml. Further in Log bundle case it supports various others modes of configuration and does not limit/force the user to use the xml route to configure it which was not the case with JR2. regards Chetan
Jenkins build is back to normal : sling-healthcheck-1.6 #194
See https://builds.apache.org/job/sling-healthcheck-1.6/194/
