Help - Search - Members - Calendar
Full Version: Spring Dependency Injection та static поля класу
DEV UA > Java > Бібліотеки та інструменти від сторонніх розробників
TIGER
Сьогодні потрібно було присвоїти значення static полю класу через Spring DI. Як завжди з першого разу воно не вийшло, і, як виявилось, Spring не дозволяє присвоїти значення static полю класу напряму.

В результаті знайшов два рішення:

1) Зробити поле не static - що не завжди є тим, що потрібно.
2) Обходиться таке обмеження наступним чином:

Є клас:

КОД
package com.devua;

public class Roots {
    private static boolean inTerracottaMode = false;

...

    /**
     * @return the inTerracottaMode
     */
    public static boolean isInTerracottaMode() {
        boolean result;

        readWriteLock.readLock().lock();
        result = inTerracottaMode;
        readWriteLock.readLock().unlock();

        return result;
    }

    /**
     * @param inTerracottaMode
     *            the inTerracottaMode to set
     */
    public static void setInTerracottaMode(boolean inTerracottaMode) {
        readWriteLock.writeLock().lock();
        Roots.inTerracottaMode = inTerracottaMode;
        readWriteLock.writeLock().unlock();
    }
}


Тепер пишемо наступну штуку в конфігураційному файлі:

КОД
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/aop
           http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
          
    <bean id="roots" class="com.devua.Roots"/>

    <bean id="terracottaModeInitializer" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property name="targetClass" value="com.devua.Roots"/>
        <property name="targetMethod" value="setInTerracottaMode"/>
        <property name="arguments">
            <list>
                <value>true</value>
            </list>
        </property>
    </bean>

</beans>


Я скористався рішенням № 2.
Pegasus
Не знаю, яка там в тебе конкретна ситуація, але DI якось не корелює з static полями. Якщо в тебе static поле, то який би ти об"єкти не створював, в них то поле у всіх однакове буде і різним об"єктам різну імплементацію підсунути не вдасться. ІМХО DI і static поля - це логічно несумісні речі.
TIGER
Поперше. Замість того щоб не створювати зайві properties файли і писати купу зайвого, як на мене, коду - я використав DI.
По друге. Якщо йдеться про кластеризований об'єкт на різних JVM?
Pegasus
1. А чим проперті файли гірші? Як на мене навіть кращі, тому що потім, якщо хтось сторонній захоче щось переконфігурувати, йому не прийдеться ритись в коді, а можна просто поредагувати конфігураційний файл.
2. Про кластеризований об"єкт на різних машинах....Terracotta(яку ти використовував для) добре інтегрується з Spring(і не тільки) з використанням DI, не бачу проблеми...І не бачу потреби через то що ти використовуєш кластеризовану JVM використовувати static філди.
П.С. в топіку про Terracotta я запостав лінк на books.google в якій то все гарно і популярно описано.
TIGER
1) А applicationContext.xml - хіба не можна розглядати як конфіг файл - не бачу різниці де міняти true на false: в проперті файлі чи в applicationContext.
2) Така книжка в мене вдома валяється - майже всю прочитав. Уточнюю - я кластеризую не весь об'єкт, а тільки його окремі поля (root-field). Це поле мені захотілось зробити статичним, бо його значення присвоюється лише один раз і ніколи не міняється + воно якраз і не є кластеризованим. Щодо книжки, то вона має свої недоліки. Наразі нема необхідності кластеризувати Spring біни, а лише певні поля об'єктів.
TIGER
Підхід з properties файлами нагадує мені іспанців і роботу з ATG Dynamo сервером. Вони теж любили використовувати на кожен крас по properties файлу. В результаті коли проект розрісся і підтримується та розширюється вже понад 10 років - тих properties файлів стало дуже багато, крім того, половина з них використовується - а які саме - визначити неможливо. От буває сидиш і розгрібаєш увесь день: звідки воно ті параметри тягне...?
Pegasus
панацеї нема. Я не говорю, що потрібно створювати сотні проперті файлів, це крайність, але така сама крайність не використовувати їх, а все робити static полями в класах. Потрібен зважений підхід. Але проперті файли мають одну дуже велику перевагу...Їх можне переконфігувати БЕЗ перебилдування апплікухи! Тобто навіть клієнт може собі їх перебилдати, не сіпаючи лишній раз девелоперів. В мене на проекті зараз якраз така ситуація. А скажи мені будьласка, яка перевага класів над проперті файлами?????
П.С. Як не дивно в мене цей проект теж з іспанцями, і їхня національна любов до великих проперті файлів помітна))) Але якщо чесно - то тільки плюсь, в них в файлі під сто пропертів, я їм проект білдаю, а вони собі хай там конфігають(і навіть значення які впливають на бізнес логіку!!!!) як хочуть, зі страхом уявляю, що було б, якби мені кожну зміну в конфігурації приходилось вписувати в код і перебілдувати...
TIGER
Тут не йдеться про те, щоб кожну зміну конфігурації кидати в статичне поле класу. Звичайно, що все робити static полями в класах - це повний маразм і я такого не роблю, та й іншим не рекомендую.

Просто створювати для одного поля класу properties файл, який ще потребує купу коду - не найкращий підхід, плюс я знаю, що інших таких полів не буде.

Крім того, зміна значення проперті в applicationContext.xml вимагає лише передеплоїти проект, а не перебілдувати його.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Форум IP.Board © 2001-2010 IPS, Inc.