Как программно разрешить заполнитель свойства в Spring - PullRequest
Новая
       39

Как программно разрешить заполнитель свойства в Spring

36 голосов
/ 02 марта 2011

В настоящее время я работаю над веб-приложением на основе Spring 3.1.0.M1, на основе аннотаций, и у меня возникла проблема с разрешением заполнителей свойств в одном конкретном месте моего приложения.

Вот история.

1) В контексте моего веб-приложения (загруженного DispatcherServlet) у меня есть

MVC-config.xml: 

<!-- Handles HTTP GET requests for /resources/version/**  -->
<resources mapping="/${app.resources.path}/**" location="/static/" cache-period="31556926"/> 

...

<!-- Web properties -->
<context:property-placeholder location="
    classpath:app.properties
    "/>

2) Внутри app.properties есть 2 свойства, среди прочих:

app.properties: 

# Properties provided (filtered) by Maven itself
app.version: 0.1-SNAPSHOT
...

# Static resources mapping
app.resources.path: resources/${app.version}

3) У меня есть пользовательский тег JSP в моих шаблонах JSP 2.1. Этот тег отвечает за создание полного пути ресурса в зависимости от настроек среды, версии приложения, выбора темы Spring и т. Д. Пользовательский класс тега расширяет класс реализации spring: url, поэтому его можно считать обычным URL-тегом, но с некоторыми дополнительными знаниями о правильном пути.

Моя проблема в том, что я не могу правильно решить $ {app.resources.path} в моей реализации пользовательского тега JSP. Пользовательские теги JSP управляются контейнером сервлета, а не Spring, и поэтому не участвуют в DI. Поэтому я не могу просто использовать обычное @Value ("$ {app.resources.path}") и автоматически разрешить его в Spring.

Все, что у меня есть, это экземпляр контекста веб-приложения, поэтому я должен разрешить свое свойство программно.

Пока я пробовал:

ResourceTag.java: 

// returns null
PropertyResolver resolver = getRequestContext().getWebApplicationContext().getBean(PropertyResolver.class);
resolver.getProperty("app.resources.path");


// returns null, its the same web context instance (as expected)
PropertyResolver resolver2 = WebApplicationContextUtils.getRequiredWebApplicationContext(pageContext.getServletContext()).getBean(PropertyResolver.class);
resolver2.getProperty("app.resources.path");


// throws NPE, resolver3 is null as StringValueResolver is not bound
StringValueResolver resolver3 = getRequestContext().getWebApplicationContext().getBean(StringValueResolver.class);
resolver3.resolveStringValue("app.resources.path");


// null, since context: property-placeholder does not register itself as PropertySource
Environment env = getRequestContext().getWebApplicationContext().getEnvironment();
env.getProperty("app.resources.path");

Так что теперь я застрял с этим. Я знаю, что возможность определения моего заполнителя находится где-то в контексте, я просто не знаю, как это сделать.
Любая помощь или идеи для проверки высоко ценятся.

Ответы [ 5 ]

36 голосов
/ 19 апреля 2013

Начиная с Spring 3.0.3, есть EmbeddedValueResolverAware, который будет работать так же, как упомянуто в другом посте, использующем вызов appContext.getBeanFactory().resolveEmbeddedValue("${prop}").

Чтобы решить эту проблему:

  1. Сделайте ваш класс для реализации интерфейса EmbeddedValueResolverAware, и вы получите инъекционный преобразователь для вас

  2. Тогда вы сможете получить свойства, как показано во фрагменте кода: 

    String propertyValue = resolver.resolveStringValue("${your.property.name}");

Тогда вашему компоненту не нужно полагаться на ApplicationContext для получения необходимых вам свойств.

23 голосов
/ 25 января 2013

Начиная с версии 3.0, Spring хранит список распознавателя строк в beanFactory. Вы можете использовать это так: 

String value = appContext.getBeanFactory().resolveEmbeddedValue("${prop}");

Javadoc заявляет этот метод для разрешения встроенных значений, таких как атрибуты аннотаций , поэтому, возможно, мы обходим его использование, но он работает.

15 голосов
/ 03 марта 2011

Я думаю, что вместо того, чтобы сосредоточиться на внутренней работе заполнителя контекста, вы можете просто определить новую утилиту: свойства, подобные этим: 

<util:properties id="appProperties" location="classpath:app.properties" />

и в вашем коде используйте его так: 

Properties props = appContext.getBean("appProperties", Properties.class);

ИЛИ как это, где вы можете сделать DI: 

@Value("#{appProperties['app.resources.path']}")
5 голосов
/ 21 января 2015

Один из вариантов - добавить PropertySource (здесь MapPropertySource в качестве примера конфигурации в памяти) к ConfigurableEnvironment и попросить разрешить свойства для вас. 

public class Foo {

    @Autowired
    private ConfigurableEnvironment env;

    @PostConstruct
    public void setup() {
        env.getPropertySources()
           .addFirst(new MapPropertySource("my-propertysource", 
               ImmutableMap.<String, Object>of("your.property.name", "the value")));
        env.resolvePlaceholders("your.property.name");
    }
}

При желании можно пометить класс Foo с помощью @Configuration, чтобы использовать возможности программной конфигурации в пользу XML.

1 голос
/ 04 марта 2011

Существует еще одно возможное решение: сделать классы тегов @Configurable через AspectJ и включить ткачество во время компиляции или во время загрузки.Затем я мог использовать обычные аннотации Spring @Value в своих пользовательских тегах.Но на самом деле я не хочу создавать ткацкую инфраструктуру только из-за пары занятий.Все еще ищем способ разрешения местозаполнителя через ApplicationContext.

...