Hello I have question regarding the use of the annotations
Suppose I create some Pagination patterns that I'm going to apply to several methods, is there a way to group many
@APIResponse into a single annotation?
I though of making a new annotation and apply the annotation there, but it didn't allow me, as
@APIResponse don't have
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.
@Componentsand 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
@QueryParametc. in JAX-RS). That is implementation-specific behavior, however, and it may not be fully portable.
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?
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
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
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"
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 :)
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,
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.