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

Georg Henzler commented on SLING-4417:
--------------------------------------

@[~cziegeler] I am aware that state is lost when bundles restart... there is 
quite a few cases in health checks when the recent history can be nice to have 
(and if there is no "negative history" after a bundle restart, it's fine to be 
green :)).

I personally would not have a concern making the immediate the default and I 
think it will be a lot better understandable for developers writing checks (as 
then the behaviour is in line with servlets, and developers are also aware that 
after a bundle restart servlet state is lost). Also from a backward 
compatibility perspective there should not be a problem (who would have written 
checks that rely on instance variables being reset after each run?).  I agree 
with [~cziegeler] for "it's not the task of the HC core to provide a way for 
implementations to keep state".



> HC Annotation should allow to configure "immediate" SCR property
> ----------------------------------------------------------------
>
>                 Key: SLING-4417
>                 URL: https://issues.apache.org/jira/browse/SLING-4417
>             Project: Sling
>          Issue Type: New Feature
>          Components: Health Check
>            Reporter: Georg Henzler
>         Attachments: SLING-4417-HC-Annotation-with-immediate-setting.patch
>
>
> When using @SlingHealthCheck at the moment, the "immediate" property is left 
> to "false" in the SCR descriptor which causes the component object to be 
> created on every call of the health check (making it impossible to keep some 
> state in a private member variable if desired). 
> Let's make the immediate property configurable (the same way it would be 
> provided in the @Component annotation) and make immediate="true" the default 
> (this is a slight change in the behaviour that will not break existing code) 
> for the following reasons:
> - It's more intuitive to think of a HC as singleton (and hence be able to 
> keep some instance variables)
> - It's a tiny little bit better from a performance perspective (the instance 
> does not have to be created on each execution)
> The attached patch includes the (fairly simple) change to 
> annotation(-processor) and the change for two sample components that were 
> using @Component because of this issue.



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

Reply via email to