hi Raymond, One of he reason i want to use healthcheck is to be able to look at /system/health, it should response even if other components being checked are not ready. Thus, /system/health should be excluded from ServiceUnavailableFilter. I dont have webconsole installed on my dev env at the moment.
Thai On Tue, Aug 20, 2019 at 9:53 AM Raymond Auge <[email protected]> wrote: > By /system/ I guess you are referring to Felix webconsole? > > The section of the Http Whiteboard spec that seems relevant is this one [1] > > The issue is that the webconsole servlet is added via the legacy > HttpService API. If you wish to filter such paths using Http Whiteboard you > need to look into Felix's proprietary support for mapping Http Whiteboard > Services to legacy Http Service contexts. I do believe Felix supports this > but not sure it's documented. > > But Carsten would know! > > - Ray > > [1] > > https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.httpservice.integration > > On Tue, Aug 20, 2019 at 9:37 AM Nhut Thai Le <[email protected]> wrote: > > > I am using filter.pattern in the mean time but the annoying is that it > does > > not allow me to exclude requests for /system/ > > > > I posted a question on paxweb , waiting for answer, will update this > email > > thread when i have some news > > > > Thanks you for the tips > > > > Thai > > > > On Fri, Aug 16, 2019 at 2:20 AM Georg Henzler <[email protected]> wrote: > > > > > Hi Thai, > > > > > > > As far as I know, standard servlet filter does not allow using regex > > > > to match path so my guess is that the value of > > > > osgi.http.whiteboard.filter.regex service property from OSGI http > > > > whiteboard spec need to be converted into path specs by the > whiteboard > > > > implementation (paxweb in my case) before passing it to jetty to > check > > > > if the filter should process the request. Am i right? > > > > > > so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in > > > the > > > whiteboard implementation paxweb then? > > > > > > you could also try to leave osgi.http.whiteboard.filter.regex out (as > > > you > > > select a specific context via osgi.http.whiteboard.context.select) or > > > use osgi.http.whiteboard.filter.pattern instead (the properties of > > > ServiceUnavailableFilter are passed one to one to > > > ServiceUnavailableFilter, > > > even if there will be a new one in the future you can just use it). > > > > > > -Georg > > > > > > > > > [1] > > > > > > > > > https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055 > > > > > > On 2019-08-15 00:23, Nhut Thai Le wrote: > > > > Hi Georg, > > > > > > > > Some more debug showed me that the cause for ServiceUnavailableFilter > > > > not picking up is due to the osgi.http.whiteboard.filter.regex that I > > > > use. At some point, jetty is building the filter chain to process the > > > > request and the ServiceUnavailableFilter is drop from the chain > > > > because the regex is pass as is to jetty's FilterMapping as a pattern > > > > to compare with the request path, but the compare does not use regex > > > > to match the pattern with the path. Here is the screenshot: > > > > > > > > > > > > > > > Thai > > > > > > > > On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <[email protected]> > > > > wrote: > > > > > > > >> Thank you for your suggestion Georg, > > > >> To address the issue of healthcheck start at level 4 instead of 3 as > > > >> desired, here are what i have tried: > > > >> Make sure the autoDisableFilter is false > > > >> > > > > > > > > > > osgi.http.whiteboard.filter.regex=(?!/system/).*osgi.http.whiteboard.context.select=( > > > osgi.http.whiteboard.context.name > > > >> [1]=WebviewerServletContextHelper) > > > >> tags=systemalive > > > >> responseTextFor503=Service Unavailable, wait.. wait... wait.... > > > >> service.ranking=1 > > > >> avoid404DuringStartup=true > > > >> autoDisableFilter=false > > > >> > > > >> I also tried setting service.ranking to 10000, but it does not > > > >> change anything > > > >> > > > >> Enabling debug log show me these lines: > > > >> 12:19:02.697 [ConfigurationListener Event Queue] DEBUG > > > >> o.a.f.h.c.i.f.ServiceUnavailableFilter - Reloading HC references for > > > >> tags [systemalive] > > > >> 12:19:02.699 [ConfigurationListener Event Queue] DEBUG > > > >> o.a.f.h.c.i.f.ServiceUnavailableFilter - Found 2 health check > > > >> service references for tags [systemalive] > > > >> 12:19:02.700 [ConfigurationListener Event Queue] DEBUG > > > >> o.a.f.h.c.i.f.ServiceUnavailableFilter - Registered > > > >> ServiceUnavailableFilter for tags [systemalive] > > > >> 12:19:02.701 [ConfigurationListener Event Queue] INFO > > > >> o.a.f.h.c.i.f.ServiceUnavailableFilter - ServiceUnavailableFilter > > > >> active (start level 4) > > > >> > > > >> There is no other log from ServiceUnavailableFilter, and my > > > >> breakpoint in the doFilter of this servlet was never got hit. > > > >> Checking the imports of the healthcheck bundles, i found they > > > >> require some packages from slf4j, lang3, pax-web-api, javax.servlet > > > >> and osgi.service.component so i also changed the start level of > > > >> these bundles to the same level as healthcheck but > > > >> ServiceUnavailableFilter still report start level 4. One question > > > >> here is that once i start playing around with start level i realize > > > >> that I may need to set start level for a lot of infrastructure > > > >> bundles (jetty, paxweb, logging, ...) to be earlier than business > > > >> logic bundles, is it normal since i remember reading somewhere that > > > >> i should let the framework resolve the bundle dependencies through > > > >> their manifest ? > > > >> > > > >> Thai > > > >> > > > >> On Tue, Aug 13, 2019 at 6:44 PM Georg Henzler <[email protected]> > > > >> wrote: > > > >> > > > >>> Hi Thai, > > > >>> > > > >>> it's not easy to see what your problem is here, you will have to > > > >>> do some > > > >>> more debugging. I have some pointers though... > > > >>> > > > >>>> I set service.ranking=1 because i'm running pax-web and it seems > > > >>> to > > > >>>> execute > > > >>>> filters in ascending ranking. > > > >>> > > > >>> "Higher rankings will be placed first in the chain, that is, > > > >>> filter > > > >>> chains are sorted in descending order." > > > >>> from [1] > > > >>> > > > >>>> ... I also set avoid404DuringStartup=true and > > > >>>> start level of healthcheck.core to level 3 (default is 4) > > > >>> because I > > > >>>> want > > > >>>> this filter to be up before my servlets and filters (default > > > >>> level 4). > > > >>>> However, I always see "INFO > > > >>> o.a.f.h.c.i.f.ServiceUnavailableFilter - > > > >>>> ServiceUnavailableFilter active (start level 4)" > > > >>> > > > >>> the log says it started at start level 4, so somehow the > > > >>> configuration > > > >>> you made for start level 3 did not work > > > >>> > > > >>>> 1. In a dynamic env like osgi container, how can we be sure that > > > >>> a > > > >>>> request > > > >>>> always be processed by a filter before arriving at the servlet? > > > >>> Bundles > > > >>>> do > > > >>>> not always start in the same order thus a filter may be > > > >>> registered > > > >>>> after > > > >>>> the servlet it supposed to protect > > > >>> > > > >>> use start levels to ensure filters are started before the servlets > > > >>> (I > > > >>> think you are already trying to do this) > > > >>> > > > >>>> 2. Even when i waited for a long period after starting my server > > > >>> and > > > >>>> healthcheck return OK for all of my checks, why does > > > >>>> ServiceUnavailableFilter not handle any request? > > > >>> > > > >>> If the health check returns OK the ServiceUnavailableFilter is not > > > >>> meant > > > >>> to kick in. Activate debug logging [2] to see if the filter is > > > >>> doing > > > >>> anything. Also ensure you left config property 'autoDisableFilter' > > > >>> to > > > >>> default 'false'. > > > >>> > > > >>> -Georg > > > >>> > > > >>> [1] > > > >>> > > > >> > > > > > > > > > > https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#filter-service-properties > > > >>> [2] > > > >>> > > > >> > > > > > > > > > > https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L288 > > > >>> > > > >> > > > > > > > > > > https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L264 > > > >> > > > >> -- > > > >> > > > >> Castor Technologies Inc > > > >> 460 rue St-Catherine St Ouest, Suite 613 > > > >> Montréal, Québec H3B-1A7 > > > >> (514) 360-7208 o > > > >> (514) 798-2044 f > > > >> [email protected] > > > >> www.castortech.com [2] > > > >> > > > >> CONFIDENTIALITY NOTICE: The information contained in this e-mail is > > > >> confidential and may be proprietary information intended only for > > > >> the use of the individual or entity to whom it is addressed. If the > > > >> reader of this message is not the intended recipient, you are hereby > > > >> notified that any viewing, dissemination, distribution, disclosure, > > > >> copy or use of the information contained in this e-mail message is > > > >> strictly prohibited. If you have received and/or are viewing this > > > >> e-mail in error, please immediately notify the sender by reply > > > >> e-mail, and delete it from your system without reading, forwarding, > > > >> copying or saving in any manner. Thank you. > > > >> AVIS DE CONFIDENTIALITE: L’information contenue dans ce message > > > >> est confidentiel, peut être protégé par le secret professionnel > > > >> et est réservé à l'usage exclusif du destinataire. Toute autre > > > >> personne est par les présentes avisée qu'il lui est strictement > > > >> interdit de diffuser, distribuer ou reproduire ce message. Si vous > > > >> avez reçu cette communication par erreur, veuillez la détruire > > > >> immédiatement et en aviser l'expéditeur. Merci. > > > > > > > > -- > > > > > > > > Castor Technologies Inc > > > > 460 rue St-Catherine St Ouest, Suite 613 > > > > Montréal, Québec H3B-1A7 > > > > (514) 360-7208 o > > > > (514) 798-2044 f > > > > [email protected] > > > > www.castortech.com [2] > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this e-mail is > > > > confidential and may be proprietary information intended only for the > > > > use of the individual or entity to whom it is addressed. If the > reader > > > > of this message is not the intended recipient, you are hereby > notified > > > > that any viewing, dissemination, distribution, disclosure, copy or > use > > > > of the information contained in this e-mail message is strictly > > > > prohibited. If you have received and/or are viewing this e-mail in > > > > error, please immediately notify the sender by reply e-mail, and > > > > delete it from your system without reading, forwarding, copying or > > > > saving in any manner. Thank you. > > > > AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est > > > > confidentiel, peut être protégé par le secret professionnel et est > > > > réservé à l'usage exclusif du destinataire. Toute autre personne > > > > est par les présentes avisée qu'il lui est strictement interdit de > > > > diffuser, distribuer ou reproduire ce message. Si vous avez reçu > > > > cette communication par erreur, veuillez la détruire immédiatement > > > > et en aviser l'expéditeur. Merci. > > > > > > > > Links: > > > > ------ > > > > [1] http://osgi.http.whiteboard.context.name > > > > [2] http://www.castortech.com > > > > > > > > > -- > > Castor Technologies Inc > > 460 rue St-Catherine St Ouest, Suite 613 > > Montréal, Québec H3B-1A7 > > (514) 360-7208 o > > (514) 798-2044 f > > [email protected] > > www.castortech.com > > > > CONFIDENTIALITY NOTICE: The information contained in this e-mail is > > confidential and may be proprietary information intended only for the use > > of the individual or entity to whom it is addressed. If the reader of > this > > message is not the intended recipient, you are hereby notified that any > > viewing, dissemination, distribution, disclosure, copy or use of the > > information contained in this e-mail message is strictly prohibited. If > you > > have received and/or are viewing this e-mail in error, please immediately > > notify the sender by reply e-mail, and delete it from your system without > > reading, forwarding, copying or saving in any manner. Thank you. > > AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est > > confidentiel, peut être protégé par le secret professionnel et est > réservé > > à l'usage exclusif du destinataire. Toute autre personne est par les > > présentes avisée qu'il lui est strictement interdit de diffuser, > distribuer > > ou reproduire ce message. Si vous avez reçu cette communication par > erreur, > > veuillez la détruire immédiatement et en aviser l'expéditeur. Merci. > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > -- Castor Technologies Inc 460 rue St-Catherine St Ouest, Suite 613 Montréal, Québec H3B-1A7 (514) 360-7208 o (514) 798-2044 f [email protected] www.castortech.com CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you. AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
