Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    James Carman
    @jwcarman
    Have we thought of using the maven-bundle-plugin from the Apache Felix project for generating the OSGi information?
    I guess if you’re wanting to assign specific versions to each package, that might not work as well, though
    Ken Finnigan
    @kenfinnigan
    @andymc12 question for you. With @ClientHeaderParam if value contains a method, are we expecting the method to interact with things other than the header name?
    I'm curious as I was wondering if an implementation could pre compute the return value from the method if it wanted
    Andy McCright
    @andymc12
    @kenfinnigan Yes, the compute method for a @ClientHeaderParam annotation is really intended only to provide the header value to be sent, but I don't think there is anything in the spec/javadoc that would prevent a user from interacting with other things.
    In the idea of pre-computing the return value - do you mean the return value of the rest client interface method?
    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