IllegalArgumentException when resolving model on Jersey 2

[Oliver Weise]

I'm trying to integrate Swagger (1.5.0) documentation into an existing Jersey (2.19) web service. My problem is that my resource classes, besides having methods to serve REST requests, also have other public methods for internal use that are not annotated with JAX-RS annotations. 

For example take this simplified resource:

@Path("/v1")
@Api(value="root")
@XmlRootElement(name=RootResource.RESOURCE_TYPE)
@XmlDiscriminatorValue(RootResource.RESOURCE_TYPE)
public class RootResource  {


    @Path(REFLIST_DBS + "/{dbkey}")
    @ApiOperation(value="Retrieve a database resource")
    public DatabaseResource getDatabase(@ApiParam(name="dbkey",value="Database key") @PathParam("dbkey") String dbKey) throws WGException {
        return new DatabaseResource(this, dbKey);
    }


    public RestApplication getApplication() {
        return _application;
    }


}

While the getDatabase method is annotated to serve resources under a given path the getApplication method is not annotated and just for internal use. However, upon scanning the API Swagger still seems to resolve this method and by descending on it approaches some classes that it cannot parse as they never where meant as REST resources. This leads to exceptions like the following, which has problems with a Logger object:

java.lang.IllegalArgumentException: Conflicting setter definitions for property "threshold": org.apache.log4j.spi.LoggerRepository#setThreshold(1 params) vs org.apache.log4j.spi.LoggerRepository#setThreshold(1 params)
 at com.fasterxml.jackson.databind.introspect.POJOPropertyBuilder.getSetter(POJOPropertyBuilder.java:293)
 at io.swagger.jackson.ModelResolver.resolve(ModelResolver.java:264)
 at io.swagger.jackson.ModelResolver.resolve(ModelResolver.java:151)
 ...

 at io.swagger.jaxrs.Reader.read(Reader.java:146)
 at io.swagger.jaxrs.config.BeanConfig.setScan(BeanConfig.java:170)
 at de.innovationgate.wga.services.rest.RestApplication.<init>(RestApplication.java:267)

So my question is:

- Why does swagger care about methods that are not annotated to be REST methods?

- Can I somehow prevent Swagger from descending onto these methods? I already tried @XmlTransient (on methods) and @JsonIgnoreProperties (on the class) but none seem to work in all situations.

I'm well aware that I might be missing something important about Swagger and/or JAX-RS, so any insight very welcome, and thanks for your help!

[Ron Ratovsky]

This may actually be due to a bug. Can you try 1.5.2?

--
You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----------------------------------------

http://swagger.io
https://twitter.com/SwaggerApi
-----------------------------------------

[Oliver Weise]

Am Mittwoch, 5. August 2015 15:17:48 UTC+2 schrieb Ron:

This may actually be due to a bug. Can you try 1.5.2?

Tried with 1.5.2. Still the same, I'm afraid. 

[Ron Ratovsky]

I take it the threshold property is found in whatever class is behind _application?

​

--

You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Weise]

Am Mittwoch, 5. August 2015 18:18:34 UTC+2 schrieb Ron:

I take it the threshold property is found in whatever class is behind _application?

​

Yes, but deep down the call stack. I debugged the throwing of the exception to be sure. On the stack I can tell by the values of the local variables that it descends onto getApplication() and even deeper until it reaches a Logger class whose property this is. 

So, I assume that the descending upon unannotated methods is unexpected behaviour? I'm a bit confused that I should be the first one to hit that issue for having additional public Non-REST methods on resources. That's why I thought I must be doing something wrong. Maybe it is uncommon for classes to be not parseable.

Just for sure, this is how I initialize on the Application class constructor via BeanConfig:

BeanConfig cfg = new BeanConfig();
cfg.setVersion("1.0");
cfg.setSchemes(new String[] {"http", "https"});
cfg.setHost("myhost");
cfg.setBasePath("/services/rest/");
cfg.setResourcePackage("...my resource packages comma separated...");
cfg.setScan(true);

[Ron Ratovsky]

There is a potential bug here, yes.

I'm not too surprised you may be the first to hit this issue as it's a bit uncommon. Normally, the REST layer doesn't contain business logic, so I wouldn't expect it to have non-REST methods there.

However, that doesn't mean it shouldn't be solved, and you're correct to expect those methods to not be scanned.

Can you please open an issue for it on swagger-core?

--
You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Weise]

Am Donnerstag, 6. August 2015 17:24:52 UTC+2 schrieb Ron:

Can you please open an issue for it on swagger-core?

Done. Thanks for your help! 

[emmanuel twizeyimna]

I'm having a similar issue. I have a method with JAX-RS annotations but without Swagger annotations. BeanConfig.setScan throws an expression because a parameter to that method can't be parsed to JSON (it's a class within a third party JAR that has overloaded setter methods).  I expect swagger to skip scanning resource methods without @ApiOperation, but it's not the case. @Oliver, have you found any solution yet? If not, can you give me the issue number?

[Oliver Weise]

Here's the issue. I don't have a workaround yet but the bug is already scheduled to be fixed with 1.5.3.

[Ron Ratovsky]

I want to clarify something about our milestone management - while an issue may be assigned a milestone, it does not mean it's going to be included in that milestone. It's a best effort process, and we cannot guarantee specific delivery dates. We do try to clear out P1s as soon as we can, but even that's not always the case.

And as usual, PRs are welcome.

--

You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tony tam]

Hi, I'll be looking into this, and responding in the github issue.

On Tuesday, August 11, 2015 at 9:31:40 AM UTC-7, Ron wrote:

I want to clarify something about our milestone management - while an issue may be assigned a milestone, it does not mean it's going to be included in that milestone. It's a best effort process, and we cannot guarantee specific delivery dates. We do try to clear out P1s as soon as we can, but even that's not always the case.

And as usual, PRs are welcome.

On Tue, Aug 11, 2015 at 12:27 AM, Oliver Weise <kis...@googlemail.com> wrote:

Here's the issue. I don't have a workaround yet but the bug is already scheduled to be fixed with 1.5.3.

Am Montag, 10. August 2015 23:58:23 UTC+2 schrieb emmanuel twizeyimna:

I'm having a similar issue. I have a method with JAX-RS annotations but without Swagger annotations. BeanConfig.setScan throws an expression because a parameter to that method can't be parsed to JSON (it's a class within a third party JAR that has overloaded setter methods).  I expect swagger to skip scanning resource methods without @ApiOperation, but it's not the case. @Oliver, have you found any solution yet? If not, can you give me the issue number?

On Monday, August 10, 2015 at 6:20:32 AM UTC-5, Oliver Weise wrote:

Am Donnerstag, 6. August 2015 17:24:52 UTC+2 schrieb Ron:

Can you please open an issue for it on swagger-core?

Done. Thanks for your help! 

--
You received this message because you are subscribed to the Google Groups "Swagger" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggersocket+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Oliver Weise]

I'm sorry, I was indeed referring to the milestone 1.5.2, by which the issue is tagged. Unfortunately my time account for Swagger integration is exhausted for now, otherwise I would try to fix the problem myself.  But it is also not time critical on our side, as the integration test was just experimental.