2011-12-27 4 views
1

Был найден метод setWrappedInstance в org.springframework.beans.BeanWrapper в 2.5.6 и удален в 3.0.0. Поскольку я в процессе миграции моего проекта с 2,5 до 3,0, я получаю ошибки. Я исследовал, и класс реализации org.springframework.beans.BeanWrapperImpl по-прежнему имеет метод setWrappedInstance.Переход от весны 2.5 к весне 3.0.5

Ниже приведен фрагмент кода моего проекта, который вызывает проблемы.

public FieldComparator(String fieldName, Class clazz) { 
    _fieldName = fieldName; 
    _bw = new BeanWrapperImpl(clazz); 
}  

public int compare(Object o1, Object o2) { 
    if (o1 == null && o2 == null) return 0; 
    else if (o1 == null) return -1; 
    else if (o2 == null) return 1; 
    // otherwise 
    _bw.setWrappedInstance(o1); 
    Comparable v1 = (Comparable) _bw.getPropertyValue(_fieldName); 

    _bw.setWrappedInstance(o2); 
    Comparable v2 = (Comparable) _bw.getPropertyValue(_fieldName); 
    return NullsLowComparator.INSTANCE.compare(v1, v2); 
} 

Так было бы хорошо, если я просто заменить _bw реализацию с BeanWrapperImpl. Я нахожусь в стадии обучения, и я считаю, что весна настоятельно предлагает использовать интерфейсы, а не сами классы реализации.

Является ли это изменение стандартными методами или я могу просто перейти к простому изменению?

ответ

4

Метод BeanWrapper.setWrappedInstance был отмечен как устаревший весной 2.5 и полностью удален в 3.0. В отличие от устаревших в JRE (которые никогда не удаляются), устаревшие API в Spring удаляются, поэтому вам рекомендуется избегать их.

2.5.6 Javadoc для setWrappedInstance говорит:

осуждается. от Spring 2.5, в пользу воссоздания BeanWrapper за целевой экземпляр

Другими словами, вместо того, чтобы повторно использовать экземплярам BeanWrapper, вы должны создать новые BeanWrapperImpl экземпляры по мере необходимости. Для этого нет штрафа за производительность - BeanWrapperImpljavadoc говорит, что он «кэширует результаты самоанализа для эффективности».

Так заменить это:

_bw.setWrappedInstance(o1); 
Comparable v1 = (Comparable) _bw.getPropertyValue(_fieldName); 

с этим:

Comparable v1 = (Comparable) new BeanWrapperImpl(o1).getPropertyValue(_fieldName); 

и избавиться от _bw области в целом.

Я считаю, что весной настоятельно рекомендую использовать интерфейсы, а не классы реализации самой

Как общее правило, да. Однако постарайтесь применить к этому некоторую практичность. Ваше использование BeanWrapperImpl полностью ограничено внутренней детализацией реализации вашего компаратора, поэтому нет никакого реального вреда в использовании его напрямую. По какой-то причине ваш компаратор должен был разоблачить BeanWrapper в общедоступной сигнатуре метода, тогда это лучше всего сделать с использованием интерфейса, а не реализации.

+0

+1 для хорошего объяснения. Я бы предпочел использовать PropertyAccessorFactory, как это было предложено javadoc. Ваш ответ был бы совершенным, если бы он упомянул об этом. Если вы его отредактируете, я удалю мою. –

1

Учитывая, что это ваш код, который создает экземпляр боб обертку, и что это экземпляр с помощью new BeanWrapperImpl(), я не вижу, как это может не сработать, если поле типа BeanWrapperImpl, а не BeanWrapper.

Однако the javadoc состояния:

ПРИМЕЧАНИЕ: Весна 2.5, это - почти для всех целей - внутренний класс . Он просто общедоступен, чтобы разрешить доступ к другим пакетам инфраструктуры от . Для целей стандартного применения, используйте вместо этого заводской метод PropertyAccessorFactory.forBeanPropertyAccess (java.lang.Object).

Я использовал бы то, что предлагает использовать javadoc.

Смежные вопросы