Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Jersey not comparing the right parameter annotation when multiple ones available #3632

Closed
jerseyrobot opened this issue Aug 3, 2017 · 9 comments · Fixed by #5639
Closed

Jersey not comparing the right parameter annotation when multiple ones available #3632

jerseyrobot opened this issue Aug 3, 2017 · 9 comments · Fixed by #5639

Comments

@jerseyrobot
Copy link
Contributor

Hi!

I'm upgrading our services from Jersey 1.19 to Jersey 2.25.1 (using Dropwizard 1.11.1).
Some of our resources consume MULTIPART_FORM_DATA. At first, I followed the dropwizard documentation (http://dropwizard.readthedocs.io/en/latest/manual/forms.html) to register the MultipartFeature, but I was still getting errors:

! org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization.
! [[FATAL] No injection source found for a parameter of type ...

After a lot of search I found out that if you have multiple annotations for your resource (for example a swagger annotation), on this line parameter.getSourceAnnotation() will return the right-most one:
https://github.com/jersey/jersey/blob/master/media/multipart/src/main/java/org/glassfish/jersey/media/multipart/internal/FormDataParamValueParamProvider.java#L384

So if you have a resource like:

@Path("test")
public class TestResource {
    @POST
    @Consumes(MediaType.MULTIPART_FORM_DATA)
    public void post(@FormDataParam(FILE) @ApiParam(required = true) InputStream fileInputStream,
                     @FormDataParam(FILE) @ApiParam(hidden = true) FormDataContentDisposition fileDetail) {
        ...
    }
}

The validation will always fail since it compares with the annotation ApiParam instead of FormDataParam, but if you switch them, it works...

I have not investigated more than that, but I wanted to let people know so they don't lose time until this is fixed.

Thanks!
@jerseyrobot
Copy link
Contributor Author

@Sytten Commented
Not sure if this bug has been acknowledged by the team?

@jerseyrobot
Copy link
Contributor Author

@etay2000 Commented
I dont think the "team" has acknowledged much of anything lately. In fact, I dont think a "team" even exists, I'm pretty sure most of the "team" that did exist is no longer with Oracle or contributing. Welcome to Java EE7 all over again! Yay!

@jerseyrobot
Copy link
Contributor Author

@jansupol Commented
Please be patient! There are big changes going on currently that make us really busy. Follow the news and stay tuned!

@jerseyrobot
Copy link
Contributor Author

@etay2000 Commented
Why is it that the only way to get a response from anyone around here is to call out the lack of a response from anyone around here?
Thanks for the link from Sept 12, but that doesn't mean much to the people that have been reporting issues with little to no feedback in the meantime. The Jersey spec doesn't seem to be the only Java EE8 spec to suffer from this minimal to non-existent support offered by Oracle. IMO, the "big changes" seem to amount to Oracle dumping EE8 (bugs and all) on the Eclipse Foundation and saying "Good luck!" after talking up their commitment to open source technologies. What did I miss?

@jerseyrobot
Copy link
Contributor Author

@OndrejM Commented
It seems to me that you missed a lot. Here some explanation from a long-time contributor to Jersey and JAX-RS: http://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00725.html

Please remember that supporting opensource for free is not easy. And in times like this when the source code is being migrated to the Eclipse foundation, any code change would be counterproductive and costly therefore we need to be patient.

You may fork the code and ask the community to send a PR with a fix or even fix it yourself. If you ask me I'd get someone to look at this issue and possibly provide a fix. If you have a support contract I'm sure Oracle or any other company providing that support would provide a patched version of Jersey for you.

@jerseyrobot
Copy link
Contributor Author

@etay2000 Commented
Ondrej,

It seems to me that you are late to the party. Thanks for providing a link to the conversation thread that I STARTED, and you realize that was from December 4th right? Do you have any other links to specific information about Jersey maintenance being deferred until after the migration prior to me asking the question?

My whole point was that me and other people are asking someone to look at the their issues and possibly provide a fix, through the official Issue Tracker. How many of those issues have been resolved recently or had their questions answered? I was attempting to fix my issue myself by asking questions to the issue tracker. If I could answer my own question I wouldn't have asked it in the first place. I would love to contribute, but that works both ways. My issue was minor, maybe not even a bug, and certainly not the point. Honestly I didn't ask you, but out of curiosity since you mentioned it, who would you get to look into and possibly provide a fix? Let me guess, you sell support contracts for Oracle?

Thanks for the lecture on open source but you missed my point. If you had read further into the conversation thread of the link you posted, you would have seen that I am now fully aware of the groups priorities moving forward. Until the migration is completed, the answer to any question is pretty much "Be Patient!".

@jerseyrobot
Copy link
Contributor Author

@t-beckmann
Copy link

Just ran into this, coming from https://stackoverflow.com/a/54287707/9568167. Oh my, it’s been awhile.

@t-beckmann
Copy link

This is an issue, still. The code mentioned in the description by now moved to

jersey/media/multipart/src/main/java/org/glassfish/jersey/media/multipart/internal/FormDataParamValueParamProvider.java

Line 360 in 9d096a8

} else if (parameter.getSourceAnnotation().annotationType() == FormDataParam.class) {

@jansupol jansupol linked a pull request May 3, 2024 that will close this issue
Allow having multiple annotations for multipart endpoint with @FormDataParam in any order #5639
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@jerseyrobot @t-beckmann