Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Benjamin Marwell
    @bmarwell
    I only have http://cxf.apache.org/docs/jax-rs-client-api.html in mind (see chapter: proxies). But maybe generating a client from the mpOpenAPI feature would be more beneficial?
    James Carman
    @jwcarman
    I just added a call to RestClientBuilder in one of my service methods and it was able to actually construct one using an interface with no @Path annotation on it.
    Benjamin Marwell
    @bmarwell
    great and good to know!
    So maybe only the resource class annotation has to be repeated then
    James Carman
    @jwcarman
    I am asking on the microprofile-rest-client channel about this too
    Well, you don't have to really "repeat" anything and only configure your baseUri for your client to include that path segment
    But, you do need to make sure all that stuff matches up, but at that point it's a configuration issue, not code
    Benjamin Marwell
    @bmarwell
    But that would be client knowledge the client would need to gather
    James Carman
    @jwcarman
    Yeah, I think it's simpler to use @Path to keep things consistent, but I suppose I could live with it the way it is
    Folks shouldn't really be changing their paths all the time anyway, because that'd break their APIs.
    Benjamin Marwell
    @bmarwell
    The best solution really would be to enhance the next spec
    Maybe @WhiteCat22 can hint us where to write to?
    James Carman
    @jwcarman
    But, your point is still valid, that instead of saying "the service lives here" and all of the resources branch off from one baseUri
    With the current way, I need to figure out what the implementation classes all have for their @Path annotations and update my baseUris accordingly
    Benjamin Marwell
    @bmarwell
    If you repeat the @Path annotation in the interface, you would never need to update your client manually, just set the base URI. You can check via tests if the @Path annotation matches from the interface.
    James Carman
    @jwcarman
    Yeah, I know. I just don't like that repetition. I wonder if I could make an ArchUnit rule for that.
    Benjamin Marwell
    @bmarwell
    Liberty seems to handle URL parameter encoding different than other servers. Jenkins will always show "your container does not support UTF-8 in URLs", which is not true. I opened an issue (https://issues.jenkins-ci.org/browse/JENKINS-62987). They need either to include a Content-Type: text/plain;charset=UTF-8 header, which seems wrong somehow for a GET request. Or use request.setCharacterEncoding(). But that method's javadoc also states it is to be used with POST requests. The third option is -Dclient.encoding.override=UTF-8. Which of those three options is a sane choice?
    Andy McCright
    @andymc12

    Hi @jwcarman - hopefully you saw my response in the MP Rest Client gitter too - putting on my Open Liberty hat... I think there are a few reasons why @Path is required on the resource class:
    1) it makes it clear that it is a root resource class
    2) it is a bean-defining annotation when used with CDI
    3) it avoids complexity when multiple inheritance (i.e. multiple interfaces) is in play

    As mentioned in the other thread, you should only need to duplicate the @Path annotation (or work around it by using baseUri) - the method- and parameter-level annotations are inherited as per the spec.

    James Carman
    @jwcarman
    @andymc12 just saw this. Thanks!
    Now I'm having trouble with constructor-based injection.
    I can't inject a dependency into my root resource class via adding @Inject onto the ctor, but if I put it on the field, everything works just fine
    I would much rather use constructor-based injection, as that makes it easier to test my stuff
    and I hate setters for that type of stuff
    Andy McCright
    @andymc12

    @jwcarman that's another optional requirement in the spec:

    The following additional requirements apply when using Managed Beans, CDI-style Beans or EJBs as resource classes, providers or Application subclasses:
    ...
    Support for constructor injection of JAX-RS resources is OPTIONAL. Portable applications MUST instead use fields or bean properties in conjunction with a @PostConstruct annotated method. Im- plementations SHOULD warn users about use of non-portable constructor injection.

    I think we have a feature request work item to support constructor injection - let me see if I can find it.

    James Carman
    @jwcarman
    Andy McCright
    @andymc12
    hmm... actually, it might work today as long as you have a public no-arg constructor too: OpenLiberty/open-liberty#7010
    James Carman
    @jwcarman
    Then I can't make my fields final (unless I set them to null)
    That seemed to work, but man that's ugly
    Andy McCright
    @andymc12
    could your public no-arg constructor call one of the other constructors but pass in null? or is that what you mean by ugly?
    James Carman
    @jwcarman
    @Path("persons")
    public class PersonResource {
    
        private final PersonRepository repository;
    
        public PersonResource() {
            this(null);
        }
    
        @Inject
        public PersonResource(PersonRepository repository) {
            this.repository = repository;
        }
    
        @GET
        @Produces(MediaType.APPLICATION_JSON)
        @Path("{id}")
        public Person getPerson(@PathParam("id") String id) {
            return repository.findById(id);
        }
    }
    yeah, that's kinda ugly, wouldn't you agree?
    JAX-RS is supposed to pick the "longest" constructor, isn't it? I don't know what CDI is supposed to do here.
    Andy McCright
    @andymc12
    it's all relative. :) but the more parameters in the constructor, the uglier it gets.
    James Carman
    @jwcarman
    I'm okay with the 1 I have here :)
    So, is this just a "work around" for a bug in OL?
    or is this per the spec and how things are supposed to work?
    Oh, and now I have to test this no-arg constructor or else it jacks up my coverage numbers :(
    Andy McCright
    @andymc12
    I think it is a requirement for CDI - I'm not a CDI expert, but I think RequestScoped beans need to have a public, no-arg constructor. I wonder if you could change the scope (try @ApplicationScoped or maybe @Dependent) if it would work without the no-arg constructor
    James Carman
    @jwcarman
    @ApplicationScoped didn't work...
    but, for some reason, @Dependent does
    I really need to get better with CDI. I've been in "Spring Boot Land" for so long.
    Andy McCright
    @andymc12
    @Azquelt or @tevans78 might know more, but I think @Dependent doesn't produce a Java proxy, so it doesn't need the no-arg constructor. That might explain the requirement.
    James Carman
    @jwcarman
    Yeah, this is where things start to get really fuzzy for me with CDI.
    They seem a bit overzealous with the proxies
    I get why they're needed in certain cases, but CDI seems to have gone overboard.
    Andy McCright
    @andymc12
    yeah, as a user, I really like CDI - for the most part it simplifies code and "just works", but (like many things) there are a few "gotchas" that don't seem to make a lot of sense.
    James Carman
    @jwcarman
    I'm sure it's just growing pains for me and I'll get used to it eventually, after I bump my head against the wall enough times.
    There are gotchas in Spring too, but I have hit them so many times that I just naturally shy away from those approaches to avoid it
    James Carman
    @jwcarman
    Thanks, as usual, for the convo, @andymc12. If we ever get to have conferences again, it'd be good to meet you face-to-face and buy you a beer for how helpful you've been to me.
    Andy McCright
    @andymc12
    no problem - until then, virtual cheers! :)