Re: [contribution] a Logback integration with OSGi Log 1.4

@Karl, regarding the vote! I'm ready if you are. :) - Ray On Tue, Apr 17, 2018 at 11:01 AM, Raymond Auge wrote: > You're right Simon. Fixed! > > I was using this mostly with Equinox on the framework classpath (via it's > embedded Eclipse Hook). > > But I fixed it

Re: Proposal to donate the system readiness check framework to Apache Felix

I agree with Richard's point about improving after contribution, so that means +1 from me for the contribution of this project as it stands. Regarding your points in relation to AEM, I think the overall concept can be split into the following three concerns that can be decoupled: 1. A part that

Re: [contribution] a Logback integration with OSGi Log 1.4

You're right Simon. Fixed! I was using this mostly with Equinox on the framework classpath (via it's embedded Eclipse Hook). But I fixed it because I do want this to work in any framework with any 1.4 Log impl. Hopefully when felix gets a 1.4 Log impl, we can do the same early binding. - Ray

Re: Proposal to donate the system readiness check framework to Apache Felix

Good point :-) Christian 2018-04-17 16:51 GMT+02:00 Richard S. Hall : > The question to answer is whether it would be worthwhile "as is" to be > donated to Apache Felix as a starting point? If so, figuring out ways to > improve it can happen after the fact. If not, then

Re: Proposal to donate the system readiness check framework to Apache Felix

The question to answer is whether it would be worthwhile "as is" to be donated to Apache Felix as a starting point? If so, figuring out ways to improve it can happen after the fact. If not, then there isn't much else to discuss. -> richard On 4/17/18 08:53 , Neil Bartlett wrote: I like the

Re: Proposal to donate the system readiness check framework to Apache Felix

The problem we face in our environment (AEM) is that the system is highly configurable. So the checks can not be defined statically for all AEM based systems. This is why we came up with the check services that can each solve a part fo the problem and then be combined to show the aggregated state.

Re: Proposal to donate the system readiness check framework to Apache Felix

Hi Guillaume, it can indeed be a problem when checks arrive late as the ready state of the system can then be green too early. So one approach is to configure a list of expected checks. This is easy to implement but requires manual config. Another approach I thought about is to use the

Re: Proposal to donate the system readiness check framework to Apache Felix

I like the general idea but, like Guillaume, I feel maybe this should be implemented at a lower level. The core `SystemReadinessMonitorImpl` and the rootcause command are implemented as DS components and configured via Config Admin... but what if SCR and/or ConfigAdmin are unavailable or not

Re: Proposal to donate the system readiness check framework to Apache Felix

Hi Guillaume. Thanks! There's the OOTB ServicesCheck check that can be configured with a list of services [0]. We were thinking we could add the mandatory checks there through configuration. The fact that the system can initially green, because no checks are present is VERY valid. We try to

Re: Proposal to donate the system readiness check framework to Apache Felix

I like it a lot, the API is simple and extensible enough. Really nice work ! I'm just a bit nervous about having such a low-level component depend on an external extender... I think it's missing one bit though: some kind of expectations. I.e. it checks existing stuff, but it does not cover

Re: Proposal to donate the system readiness check framework to Apache Felix

Hi Karl. Thanks for the support! I'd love to have a role in maintaining it further and get more involved with the Felix community in general. - Andrei On Tue, Apr 17, 2018 at 1:36 PM Karl Pauls wrote: > Hi Christian and Andrei, > > as I said out of band already

Re: [contribution] a Logback integration with OSGi Log 1.4

Ray, Great! It seems this bundle has to be started before the OSGi LogService implementation bundle? I'd expect the Activator to use a service tracker? Simon Raymond Auge a écrit le 12/04/2018 à 16:44 : > As promised here's the repo https://github.com/rotty3000/osgi.to.logback > > - Ray > >

Re: [contribution] a Logback integration with OSGi Log 1.4

Hi Ray, looks good to me. As there doesn't seem to be any concerns I would like to get this to a vote. Do you want me to call it or do you want to do that yourself? regards, Karl On Thu, Apr 12, 2018 at 4:44 PM, Raymond Auge wrote: > As promised here's the repo

Re: Proposal to donate the system readiness check framework to Apache Felix

Hi Christian and Andrei, as I said out of band already previously, I think this looks interesting and I agree that it seems generic enough to be at Felix. I assume you would be willing to maintain it going forward (assuming we choose to accept it)? Let's see what others think. regards, Karl

[GitHub] felix pull request #133: FELIX-5831: Use config instead of bundleContext to ...

Github user asfgit closed the pull request at: https://github.com/apache/felix/pull/133 ---

Proposal to donate the system readiness check framework to Apache Felix

Dear Felix community, during the last weeks Andrei Dulvac and I worked on a small framework to check if an OSGi based system is fully up. Our work originated in testing sling modules and whole sling instances. We soon found though that the concept is more general than sling and can be applied to

[jira] [Commented] (FELIX-5831) Async/sync Thread Pool Ratio is not changeable at runtime

[ https://issues.apache.org/jira/browse/FELIX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440439#comment-16440439 ] ASF GitHub Bot commented on FELIX-5831: --- Github user asfgit closed the pull request at:

[jira] [Resolved] (FELIX-5831) Async/sync Thread Pool Ratio is not changeable at runtime

[ https://issues.apache.org/jira/browse/FELIX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5831. - Resolution: Fixed Thanks for your patch [~graben] . Good catch! I've applied the patch