Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    YK Chang
    @yeekangc
    @aguibert, see if this works for you. We can then share with the community.
    Andrew Guibert
    @aguibert
    works for me, thanks for setting this up YK!
    Andrew Guibert
    @aguibert
    Rudy regarding your comment "add detection for MP Health 1.X API", I'm not sure how well this would work out as I think through it more. With Liberty MP Health 1.X was basically unusable as a readiness check because in some cases the /health endpoint would return HTTP 200 before the app endpoints were publicly exposed (just for a tiny race condition window of ~50ms). In MP 2.0 this was fixed in the spec when the /health/ready endpoint was defined
    perhaps Payara works OK using MP Health 1.X as a readiness check, but Liberty will not (not sure about other app servers)
    Rudy De Busscher
    @rdebusscher
    Hi @aguibert, yes with Payara the /health endpoint returns only 200 when the app is ready (We had also an issue in the beginning but since a few releases it is fixed)
    In combination with the addition of the withReadinessPath to the ServerAdapter this can be solved since you define the path then for the server.
    For the moment, the examples doesn't work for Payara due to the usage of withReadinessPath in the examples. This means also that you always need to change the defined readiness path when switching Implementations (maybe not a big hurdle for developers as they don't switch).
    But now when the implementation doesn't support Health 2.0, or when developers are still using MP 1.x or 2.x, they always need to specify the readiness path over and over again.
    Also because / return 404 for a JAX-RS application, so that doesn't work at all.
    Rudy De Busscher
    @rdebusscher
    Adding it into the ServerAdapter fixes this problem already, so the check for Health 1.x is not really necessary. But since you already added the Health 2.0 check, it seems reasonable to add it also for Health 1.x
    Andrew Guibert
    @aguibert
    yea I think it would be more appropriate for the samples to define readiness paths that are inside of the app, such as /app/people or something
    I was kind of being lazy adding all of EE8 + MP 3.0 dependencies as provided to the build path of the samples, even though runtimes may not "provide" implementations for all of that. What would Payara users typically add for their dependencies if they wanted to write a JEE+MP app?
    Rudy De Busscher
    @rdebusscher
    What would Payara users typically add for their dependencies if they wanted to write a JEE+MP app?
    The Java/Jakarta EE (api) and MP dependencies with scope provided.
    But since the server contains the Health endpoints, it sounds reasonable to use them so that developer does need to specify any path for the readiness check.
    Scott Kurz
    @scottkurz
    Hi.. time for a friendly update from an "I'm not a lawyer" guy... I'm planning on enabling the "DCO app" which adds a check that commits have been "signed-off" before PR merge. Still needed perhaps may be some kind of CONTRIBUTING doc at the level of individual repos and/or the MicroShed org. level at a whole... won't worry about that just yet (though I'm adding one for MicroShed Boost). Can't see that anyone will object but just FYI noting publicly here..
    Actually let me correct myself.. I added the DCO app.. but now I think it may be up to each repo to choose whether to enable branch protection (such that the app check has to pass before a PR can merge cleanly). So app enabled.. but I'm not going to set up branch protection right now.