Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Emily Jiang
    @Emily-Jiang
    By the way, what Java EE spec does Open API depends? I did not spot much
    Josejulio Martínez
    @josejulio

    Hello I have question regarding the use of the annotations @Parameter and @APIResponse:

    Suppose I create some Pagination patterns that I'm going to apply to several methods, is there a way to group many @Parameter and @APIResponse into a single annotation?

    I though of making a new annotation and apply the annotation there, but it didn't allow me, as @Parameter and @APIResponse don't have @Target(ANNOTATION_TYPE).

    Would it make sense to add it?
    Is there other way to accomplish what I want to do (group multiple @Parameter into one to avoid repeating and if i need to change the API i only have to do that in one place)?.

    Please let me know if I should ask this elsewhere.

    Michael Edgar
    @MikeEdgar
    @josejulio - there is no way to group them that I am aware of, but you might look at defining them under @Components and referencing them using @Parameter(ref = "the name in components"). Additionally, if you're using the SmallRye implementation, you can declare your parameters as fields in the JAX-RS resource class and they will apply to all @Path-annotated methods in the class (just like fields annotated with @QueryParam etc. in JAX-RS). That is implementation-specific behavior, however, and it may not be fully portable.
    Josejulio Martínez
    @josejulio
    Thanks, I'll check that.
    Arthur De Magalhaes
    @arthurdm
    hey @EricWittmann / @MikeEdgar / @msavy / @lamtrhieu - sorry for the late notice, but today I will be presenting at a customer workshop so won't be able to join the hangout. I will check the items tomorrow to add input.
    Eric Wittmann
    @EricWittmann
    OK thanks @arthurdm good luck
    Arthur De Magalhaes
    @arthurdm
    congratulations on becoming a MicroProfile committer @MikeEdgar !!🍺
    Michael Edgar
    @MikeEdgar
    Thank you @arthurdm! :thumbsup: :beer:
    Arthur De Magalhaes
    @arthurdm
    sorry guys, just realized I have a conflict with the hangout today. :/
    Skylar Smith
    @SavvySkylark
    Does a generator exist that can take an openapi spec and generate jax-rs server stub with microprofile-open-api annotations? I have not found anything like that in my searches but before I give up I wanted to ask.
    Eric Wittmann
    @EricWittmann
    @SavvySkylark Nothing I'm aware of does that, specifically. However, if you are starting with OpenAPI (design first) then you could use an existing generator to generate the jax-rs and then include the original OpenAPI doc in your META-INF directory. That design-first use case is specifically why section 4.2 of the spec exists.
    I would argue that the extra annotations aren't needed if you are doing design-first because the canonical source of truth would be the openapi file that you would bundle with your app.
    Marc Magon
    @GedMarc

    This may be a bit of a strange question :)
    Can't seem to find documents related or my googling capabilities are not up to scratch xD,

    Is it possible to simply hook up the microprofile servlet in a similar manner that a few of the other providers do? Simply set a servlet and listener if needed, without the entire microprofile suite behind it?

    In CXF for example, you can hook up the servlet and ignore everything else that comes with it, allowing you to port it across any servlet capable service?
    http://ronhks.hu/2019/06/07/apache-cxf-without-spring/

    What I'm trying to do is only expose metrics+health, and not pull in any of the other stuff like CDI, config, and the rest

    Phillip Krüger
    @phillip-kruger
    Hi @GedMarc - not sure if this is the right room, try asking in the microprofile google group. Servlet itself is not part of microprofile, and as far as I know, metrics and health depends on CDI. (You can also ask the question in Health and Metrics rooms maybe)
    Marc Magon
    @GedMarc

    Hmm that's concerning, lots of projects have stepped away from CDI.
    As in its core it's just a prometheus end point, don't think that it is worth the effort to chase this up.

    Thanks for the timely response!

    Phillip Krüger
    @phillip-kruger
    I did not know that. What projects has stepped away from CDI ?
    Marc Magon
    @GedMarc
    Everything Spring, guice, dagger, mr bean, and all the other many many options, Spring has over 50% of the market share already so it's surprising that this is unknown in this circle -
    How is it that something so important is not known? This feels like a really huge miss.
    Phillip Krüger
    @phillip-kruger
    So they never moved away from CDI, they never supported it. But Websphere, OpenLiberty, WildFly, JBoss, Thorntail, Quarkus, TomEE, Payara and more support it.
    Eric Wittmann
    @EricWittmann
    @GedMarc The other thing you can check on is if you can just use the SmallRye implementation directly. As Phillip mentioned, this is the microprofile-open-api room and so you might have better luck asking in the health and metrics rooms. That said, you could check out these:
    I don't know anything about those impls - but those are what e.g. WildFly and Quarkus use for implementations and they might be easily consumable without pulling in CDI.
    I know that the SmallRye OpenAPI implementation can be used without CDI.
    Marc Magon
    @GedMarc
    That is actually the exact thing I was looking for! I understand now thank you -
    We are going full Java Modular Services, so unfortunately the default suites is out of our bounds :)
    oh noo, it has a reference to @ApplicationScoped in the cdi-jar
    darn
    Phillip Krüger
    @phillip-kruger
    Personally I would suggest just embracing CDI. It will make your life easier. Not just because of the libs you can use, but having the ability to @Inject a scoped bean in your own code makes your code much cleaner.
    Marc Magon
    @GedMarc

    Not at all @phillip-kruger , I would definitely like to see a remove dependency on CDI, and use the JSR-330 and JSR-299 instead (@Inject, @Singleton,) - There doesn't seem to be any reason to lock down to CDI in the code base at all. Everything that is used is already supplied in javax.inject package (now jakarta.inject)

    I do still believe this is a big miss, having no support to override the bean fetching mechanism to a custom, and deciding that no interface will allow any external's not using CDI can consume this project, removing a very large portion of the developing base from being able to consume/use these capabilities

    Remember, the reason why all the other options came about is because CDI isn't doing the job, or is doing it in a way we don't like.
    CDI was first, everything that came after was to fill a missing gap - it's why the other options are gaining so much more traction in the market.

    Personally I will never touch CDI again, so I'm not sure the answer of "just embrace CDI" is valid. we have embraced it, then threw it out for something else xD :)

    Please think about making the project portable, and remove such lock-in technologies

    Phillip Krüger
    @phillip-kruger
    CDI is the portable option. It exist to not have lock in.
    @Inject still needs a Dependency Injection framework to do the actual injecttion
    On it's own it's just an annotation.
    Also, if you want to use MicroProfile, then CDI is a given. MicroProfile use CDI. It's one of the platform specs. If this is not what you want, find another metrics / heath library.
    Marc Magon
    @GedMarc

    i'm sure java.enterprise.cdi package is "locked in", to the other 5 dependencies that come with it.
    You can swop them all out for the standalone javax.inject package, CDI supports it fully, as does every other injection library
    You are using a much lower-level annotations that lock into the java.enterprise package, that comes with a suite of jakarta dependencies. It is most definitely a lock in.

    Using javax.inject you will enable cross-portability, no lock in to EE dependencies and modules, you would free the application to be used across the entire landscape.

    As it is, this is only usable if you are in the JavaEE space. More than 50% of the globe are not, and that space is growing and growing, not going smaller.

    Please give it some thought, pull the injection markers up to javax.inject, and make the implementor switchable. Whether you want to use CDI, Spring, Guice, anything, they all work on JSR300 and can switch between them with ease.

    It's a decision you've made to lock this into JavaEE, nothing else will be able to use it.
    My original request is to swallow Health and Metrics, nothing else.

    If it is the decision that's fine, but then we simply walk away and mark it off as an "EE Framework"

    Phillip Krüger
    @phillip-kruger
    Any lib that you use has a package, so with that argument, you are always locked in. The reason why you can using java.enterprise.cdi is that that is just a specification. So you can move between implementations. Hence - no lock in. However, if you use Spring for example, you are locked in to Spring, there can not be, and there is no other, implementation.
    It's not a EE Framework, it's build on CDI. Same way that most Spring libs it build on Spring DI
    Marc Magon
    @GedMarc

    the implementation yes, must HAS TO be portable, I must be able to run this on anything. SOLID principles.
    Look I see you are not even interested in being swayed, so at this point it's just banter back and forth

    Im' just going to fork, make the changes and split it out :)

    Thanks though

    Phillip Krüger
    @phillip-kruger
    It's not for me to decide, like I said you have the wrong chat room anyway, go ask in metrics and health and see if they are willing to remove CDI.
    "Like its previous version, MicroProfile 3.3 continues to align itself with CDI, JAX-RS, JSON-P, and JSON-B as the foundational programming model for the development of Java microservices."
    Eric Wittmann
    @EricWittmann
    Yeah @GedMarc it seems to me that you have a disagreement with two groups: the Microprofile spec and the Health/Metrics SmallRye implementations. This is the OpenAPI chat room. Before forking someone else's repository, you should at least try reaching out in the correct chat room/repository. https://smallrye.io/community/
    Maybe it's trivial to change the annotations in those repos and they would be happy to have a PR.
    I know that if openapi had a dependency that was not critical I'd be happy to accept a PR that made it optional.
    Marc Magon
    @GedMarc

    Sorry for causing what seems to be a stir - Indeed the microprofile group itself has aligned itself, not quite the same levels though - Don't believe I'm going to go through the effort of that -
    Would like some clarity though -
    CDI is an implementation of JSR300
    JAXRS is a JSR
    JSON-P is a JSR
    JASON-B is a JSR

    Only CDI is an actual implementation :)
    I think this can close now, you are sticking to your MP3.3 chosen stack,

    Eric Wittmann
    @EricWittmann
    Not a stir as far as I'm concerned. Just trying to reinforce that you're in the wrong room to try and get what you're after (which is an implementation of health/metrics that is not bound to CDI). I'd just hate to see you fork the smallrye repo when it's possible they will be happy to accommodate your request.
    I also understand your larger point about CDI and Microprofile. And that is also far beyond the scope of this room (which, again, is the OpenAPI sub-specification chat room).
    Marc Magon
    @GedMarc

    well, can also do the pull request from the fork, and see if there is any entertaining it. Either way I have to do the work, mine-as-well just get down to it.
    I was under the impression this group was the "coverall" for MicroProfile, which is where the CDI dependency comes from:)
    I'll be more meticulate in my room choosing.

    Thanks guys

    Eric Wittmann
    @EricWittmann
    Good luck.
    Phillip Krüger
    @phillip-kruger
    CDI is a JSR (JSR 365)