Thanks for that. Sorry for the late response, but I got pulled into 
something else at work.

I'm trying to parse through the logger statements, and is there anything 
that I should be particularly looking out for? The particular class that is 
having the missing properties issue appears multiple times throughout the 
logging...


On Friday, June 2, 2017 at 8:21:21 AM UTC-7, tony tam wrote:
>
> Typically using slf4j in logback.xml:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration>
>     <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
>         <layout class="ch.qos.logback.classic.PatternLayout">
>             <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - 
> %msg%n</Pattern>
>         </layout>
>     </appender>
>     <logger name*=**“**io.swagger" *level="DEBUG"/>
>     <root level="error">
>         <appender-ref ref="STDOUT"/>
>     </root>
> </configuration>
>
>
>
> On Jun 2, 2017, at 3:36 AM, Ed Wang <edx....@gmail.com <javascript:>> 
> wrote:
>
> How does one set the debug level?
>
> On Wed, May 31, 2017 at 6:19 PM, tony tam <feh...@gmail.com <javascript:>> 
> wrote:
>
>> Setting the debug level will show you pretty much everything that happens 
>> during the scanning process.  I’d start there, and feel free to post your 
>> findings back here for help.
>>
>> On May 31, 2017, at 4:45 PM, Ed Wang <edx....@gmail.com <javascript:>> 
>> wrote:
>>
>> That was my first suspicion as well. I'm not sure that I see any other 
>> models with the same name, but is there a way for me to find what models 
>> are actually scanned by swagger, just to confirm?
>>
>> On Wednesday, May 31, 2017 at 4:13:54 PM UTC-7, tony tam wrote:
>>>
>>> Usually this happens when you have multiple models with the same name, 
>>> but different definitions.  The “randomness” has to do with which one is 
>>> loaded first.
>>>
>>> On May 31, 2017, at 3:46 PM, Ron Ratovsky <r...@swagger.io> wrote:
>>>
>>> If you’re using Spring as your REST framework, then you probably use 
>>> Springfox.
>>> Swagger-jaxrs is used with old jax-rs libraries such as Jersey 1.x.
>>>  
>>> Can you check again please?
>>>  
>>>  
>>>  
>>> *From: *<swagger-sw...@googlegroups.com> on behalf of Ed Wang <edx....@
>>> gmail.com>
>>> *Reply-To: *"swagger- <javascript:>swaggersoc...@googlegroups.com 
>>> <javascript:>" <swagger-sw...@googlegroups.com>
>>> *Date: *Wednesday, 31 May 2017 at 11:37
>>> *To: *Swagger <swagger-sw...@googlegroups.com>
>>> *Subject: *Re: Intermittent missing property from Swagger spec 
>>> definition
>>>  
>>> We're using Spring as our REST framework and I believe we're using 
>>> swagger-jaxrs-1.5.5
>>>
>>> On Tuesday, May 30, 2017 at 8:39:27 PM UTC-7, Ron wrote: 
>>>
>>> Interesting. Can you give us some more information as to which REST 
>>> framework you use, which swagger project, and which versions?
>>>  
>>>  
>>>  
>>> *From: *<swagger-sw...@googlegroups.com> on behalf of Ed Wang <
>>> edx....@gmail.com>
>>> *Reply-To: *"swagger-sw...@googlegroups.com" <
>>> swagger-sw...@googlegroups.com>
>>> *Date: *Tuesday, 30 May 2017 at 10:38
>>> *To: *Swagger <swagger-sw...@googlegroups.com>
>>> *Subject: *Intermittent missing property from Swagger spec definition
>>>  
>>> I'm trying to debug a strange situation where there is an intermittent 
>>> absence of properties from a single definition in the swagger spec 
>>> generated in a Java service. When I say intermittent, I mean that whenever 
>>> I start my service, there is a chance that there are no properties in that 
>>> particular definition; this is causing our compatibility tests (which use 
>>> Swagger spec to detect potentially breaking changes) to frequently fail.
>>>  
>>>  
>>> For example if I were to expect a definition like:
>>>  
>>> "ExampleClass":{
>>>     "allOf":[
>>>         {"$ref":"#/definitions/ParentClass"},
>>>         {
>>>             "type":"object",
>>>             "properties":{
>>>                 "key1":{"type":"string"},
>>>                 "key2":{"type":"string"},
>>>                 "key3":{"type":"string"}
>>>             }
>>>         }
>>>     ]
>>> }
>>>
>>>  
>>>
>>> Sometimes, we would get:
>>>
>>>  
>>>
>>> "ExampleClass":{
>>>     "allOf":[
>>>         {"$ref":"#/definitions/ParentClass"},
>>>         {
>>>             "type":"object",
>>>             "properties":{}
>>>         }
>>>     ]
>>> }
>>>
>>>  
>>>
>>> Does anyone have any ideas on why this might be happening? For some reason 
>>> this seems to be the only class that has this issue, out of over 100 other 
>>> definitions generated...And I can't seem to find a difference between the 
>>> classes that work and this one that does not.
>>>
>>> -- 
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> -- 
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>> -- 
>> 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+unsubscr...@googlegroups.com <javascript:>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> -- 
>> 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+unsubscr...@googlegroups.com <javascript:>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> 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+unsubscr...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to