Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ken Finnigan
    @kenfinnigan
    but it would only be interact with things statically right?
    no, pre-compute the value from the @ClientHeaderParam value method
    ignore me, it could have things on the class that we instantiate
    never mind, thanks
    Andy McCright
    @andymc12
    oh - I think I understand your question now. No, I think it is possible that the return value could be dynamic (e.g. pulling a JWT authorization header off of a servlet request, using a thread-local, etc.)
    Ken Finnigan
    @kenfinnigan
    right, that's what I just realized
    James Carman
    @jwcarman
    Would it be possible to develop a distribution-agnostic RestClientBuilder using nothing but Client APIs? Or is the intimacy needed for performance reasons (or other SPI concerns)?
    Ken Finnigan
    @kenfinnigan
    @jwcarman not sure what you mean. I don’t think an implementation utilizing just apis would be able to do anything, as there’s no impl under it
    James Carman
    @jwcarman
    I mean, if I just coded to existing JAX-RS APIs.
    Or if “one” coded
    You still need a distro
    Ken Finnigan
    @kenfinnigan
    Interesting question. For the pure builder api it would mostly be possible, but there are some pieces that are built on top of Jax-Rs client builder, so likely would need an impl for them
    James Carman
    @jwcarman
    The distro would have a ClientBuilder already. Could maybe delegate to it
    Was just thinking about this last night. I don’t know the spec inside and out yet, so I thought I’d as the experts if it’s a crazy idea before I tried some coding
    Ken Finnigan
    @kenfinnigan
    But there are things the spec client builder does which aren’t part of jaxrs client builder, so nothing to delegate to
    James Carman
    @jwcarman
    Right, delegate what you can and augment with what’s specific to doing the method call semantics
    Basically it’s just a wrapper around a regular JAX-RS client
    Just treat Client as a replacement for something like HttpClient, but you get all the Provider stuff for free, other than what’s specific to MP.
    Andy McCright
    @andymc12

    @kenfinnigan @michalszynkiewicz I chatted with Kevin - he said that the main MP google calendar has the release schedule: https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl88nkc3r4@group.calendar.google.com&pli=1

    We need to be completely released by May 15 - so I think we should consider a release candidate next week.

    Michał Szynkiewicz
    @michalszynkiewicz
    thanks for info
    Ken Finnigan
    @kenfinnigan
    @andymc12 just pulling the latest git repo and there are a lot of branches. Do you know if we still need most of them?
    Andy McCright
    @andymc12
    @kenfinnigan - I think we can get rid of most of them. We should keep the "*-service" branches (and master, of course). The rest of them look like they were created by John or Ondro back in 2017. We can probably delete those.
    Ken Finnigan
    @kenfinnigan
    What are the "*-service" branches for?
    Andy McCright
    @andymc12
    they are for the previous releases - basically to handle things like challenges to previously released specs/TCKs, etc.
    Ken Finnigan
    @kenfinnigan
    are they created automatically by the release?
    i cleared up the other branches
    Andy McCright
    @andymc12
    cool. no, I create them after the release.
    Ken Finnigan
    @kenfinnigan
    do we need all of them or just the last two, or one?
    ah ok
    an alternative is to create the branch from the tag only if needed
    Andy McCright
    @andymc12
    true - the release process does create the tag.
    but I think some of the streams have changes that are different from master
    Ken Finnigan
    @kenfinnigan
    oh?
    Andy McCright
    @andymc12
    I'd have to go back and look, but I think we had a case where we changed a TCK test after we'd already made changes to that same test (for different reasons) in master
    Ken Finnigan
    @kenfinnigan
    ok
    Andy McCright
    @andymc12
    @kenfinnigan thanks for opening issue #186. Should we plan on this being part of 1.3 or a future release?
    Ken Finnigan
    @kenfinnigan
    If possible 1.3, but depends on whether my ideas around how to test it are accurate or not
    If they are, then shouldn't be too hard to adjust
    if not, would likely take longer
    Andy McCright
    @andymc12
    cool, that sounds good. I'll go ahead and tag it for 1.3 for now
    Ken Finnigan
    @kenfinnigan
    @andymc12 can you recall what the use case was for adding the AsyncInvocationInterceptor?
    Ken Finnigan
    @kenfinnigan
    nevermind, modified the text in spec around it how I thought made sense
    Michał Szynkiewicz
    @michalszynkiewicz
    @andymc12 @kenfinnigan thank you guys for the review! I will do a rework tomorrow
    Michał Szynkiewicz
    @michalszynkiewicz
    reworked
    Andy McCright
    @andymc12
    @michalszynkiewicz looks good to me. @kenfinnigan do you want to take another look at the SSL changes? #187
    Ken Finnigan
    @kenfinnigan
    Looks fine
    Michał Szynkiewicz
    @michalszynkiewicz
    @andymc12 @kenfinnigan hi, we have a public holiday tomorrow and I won't be able to make the meeting
    Andy McCright
    @andymc12

    @michalszynkiewicz no worries - enjoy your time off!

    @kenfinnigan do you still want to meet tomorrow?

    I'm thinking that if we can merge #187 today, then I can produce a release candidate. we probably won't need the meeting then since the RC will not yet be in Maven Central (it usually takes a day or two). once in the Maven servers, then we'll likely have more to discuss as we run into issues with compatible implementations of the RC. What do you think?

    Ken Finnigan
    @kenfinnigan
    I’m fine with no meeting
    Andy McCright
    @andymc12
    sounds good - I'll go ahead and cancel. are you ok with my proposed changes to #187? (changing .addAsManifestResource(new StringAsset(config), "microprofile-config.properties") to .addAsWebInfResource(new StringAsset(config), "classes/META-INF/microprofile-config.properties") ? If so, I can do that in a separate PR