This repository has been archived by the owner on Nov 11, 2017. It is now read-only.
REST method return type overriding (solves not generating models for javax.ws.rs.core.Response) #71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
This change addresses a problem where there's no model information generated if the return type of a REST method is wrapped inside javax.ws.rs.core.Response object (often the case).
http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.html
Current situation
Currently model generation from javax.ws.rs.core.Response is not supported at all because packages starting with "javax." are excluded from model documentation by this tool. Even if it wasn't excluded, it's impossible to find out which object is wrapped by javax.ws.rs.core.Response since its type is not known at compilation time - it's kept as Object
http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.html#ok(java.lang.Object)
Proposed solution
An additional, optional doclet parameter, that points to a conf file (standard java properties file) with mapping:
qualified method name -> java type that should be used for model generation
e.g.
fixtures.sample.Service.getSubResourceWrappedInResponse(java.lang.String,java.lang.String)=fixtures.sample.SubResource
Other solutions
Instead of using a mapping in a separate configuration file, it is be possible to use an annotation (an approach used by enunciate project: @org.codehaus.enunciate.jaxrs.TypeHint)
In this approach however, non-standard annotations have to be added to the code.