On 1/6/2018 11:36 AM, Lukasz Lenart wrote:
> Just one note: if you do plan a large refactoring I would suggest to
> split it into two steps. In first step remove the @deprecated flag and
> push changes, then we can easily release 2.5.15. And postpone the
> second step (the refactoring) till 2.6.
> 
> I do not expect large changes in 2.5.x codebase
> 
> 
> Regards
> -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2018-01-04 11:56 
> GMT+01:00 Yasser Zamani <[email protected]>:
>>
>> On 1/4/2018 10:58 AM, Lukasz Lenart wrote:
>>> As far I understand these annotations are representation of the same
>>> properties which can be used in XXX-conversion.properties files
>>> https://struts.apache.org/core-developers/type-conversion.html#collection-and-map-support
>> Thanks Łukasz! With further investigation following above link, I
>> discovered those codes are copied from `DefaultConversionFileProcessor`.
>> Then I saw in it ...
>>
>>>                      //for properties of classes
>>>                      else if 
>>> (!(key.startsWith(DefaultObjectTypeDeterminer.ELEMENT_PREFIX) ||
>>>                              
>>> key.startsWith(DefaultObjectTypeDeterminer.KEY_PREFIX) ||
>>>                              
>>> key.startsWith(DefaultObjectTypeDeterminer.DEPRECATED_ELEMENT_PREFIX))
>>>                              ) {
>> i.e. all ORs are NOTed. Now I understand what's the problem with
>> `DefaultConversionAnnotationProcessor`:)  Copier of those codes wished
>> to remove NOT but wrongly just applied on first condition and rewrote it
>> as tc.rule() != ConversionRule.ELEMENT while `NOT` should be refactored
>> to all inside () i.e. tc.rule() != ConversionRule.ELEMENT && tc.rule()
>> != ConversionRule.KEY && tc.rule() != ConversionRule.COLLECTION.
>>
>> Also I found a lot of XXX-conversion.properties inside test resources
>> and now, I could coveralls my PR DefaultConversionAnnotationProcessor
>> without knowing underlying details via copying current tests;)

I just planned to fix above wrong if-else statement via inspiring from 
DefaultConversionFileProcessor.java which is a small fix by itself but 
also planned to add unit tests which currently does not exist but I knew 
how via current tests. I conclude they're nice and not complex changes I 
think ...

... But unfortunately I was and am busy and overloaded here these few 
days (to make some money) ;) but I think I can finish this at end of 
tomorrow then will review PR#196(WW-4905) next day and I think I'm ready 
for 2.5.15 at another next day :)

Do you still prefer just nu-deprecating and leaving the bug as is? If 
you confirm, then it's also ok at my side :)

Thanks for your attention,
Regards.

Reply via email to