Wiosna 3,1 PropertySourcesPlaceholderConfigurer i import warunkowy

Question

Patrząc na nowego wsparcia własności wiosna w 3,1 (http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/), wygląda to tak powinno być możliwe:

<context:property-placeholder location="/WEB-INF/application-customer-dev.properties,classpath:application-customer.properties" ignore-resource-not-found="true"/> 

<import resource="classpath*:com/x/core/security/security-${login.security}.xml"/> 

gdzie login.security jest w application-customer-dev.properties jako:

login.security=dev 

(a security-dev.xml istnieje w odpowiednim miejscu). Brakuje mi czegoś, ponieważ login.security nie może zostać rozwiązany. Spodziewam się takiego zachowania w wersjach wcześniejszych niż 3.1, ale wygląda na to, że powinno to być poprawne z 3.1 (którego używamy)?

Answer 1

Przypis [2] z linku:

[2]: Ponieważ przetwarzanie <import/> elementów niekoniecznie występuje przed BeanFactoryPostProcessors są wywoływane, co oznacza, że ​​nawet PropertyPlaceholderConfigurer nie mógł pomóc tutaj. Ponieważ środowisko i jego zestaw zasobów PropertySources są skonfigurowane przed odświeżeniem kontenera, elementy zastępcze w elementach mogą być rozwiązywane w środowisku bez żadnych problemów związanych z cyklem życia.

UPDATE:

Według javadoc for PropertySourcesPlaceholderConfigurer, PropertySourcesPlaceholderConfigurer jest BeanFactoryPostProcessor, więc co przypis naprawdę mówi to, że import został rozwiązany przed na PropertySourcesPlaceholderConfigurer jest zainstalowany, więc nie zadziała albo (w rzeczywistości, w czasie, gdy rozwiązano <import/>, konfigurator może jeszcze nie istnieć!) Tak, po zainstalowaniu będzie wyglądał na Environment, ale nie można go użyć do rozstrzygnięcia wewnątrz <import/>, ponieważ w tym czasie nie postprocesory działają. A to obejmuje PropertySourcesPlaceholderConfigurer.

Zasadniczo konfiguracja XML kontekst Wiosna idzie mniej więcej tak:

1. Kontekst jest tworzony.
2. Environment jest ustawiony.
3. Odczytuje się XML (wszystkie XML, w razie potrzeby rozdzielając import). Definicje fasoli są tworzone.
4. BeanFactoryPostProcessor s są instalowane i wywoływane, przetwarzanie definicji komponentów bean.
5. BeanPostProcessor s są zainstalowane.
6. Fasolki są tworzone zgodnie z definicjami fasoli. BeanPostProcessors są stosowane.

To jest podobny problem jak ten, który powoduje, że nie można użyć właściwości wielu postprocesorów order zastosować BeanPostProccesor przed BeanFactoryPostProcessor (coś jak zarobić PropertyPlaceholderConfigurer rozwiązywaniu zastępcze od A @PersistenceContext): zachowanie jest zakodowane w kontekście aplikacji Spring, więc musisz obejść go, specjalizując się w niektórych wiosennych zajęciach.

Answer 2

Myślę, że źle czytasz bloga trochę @Kurt - To powinno być rozwiązane, jeśli źródło właściwości zawierające właściwość jest obecne przed rozpoczęciem tworzenia definicji fasoli.

Więc sposób, aby uzyskać import będzie rozwiązać te dwa sposoby: 1. ustawić zmienną środowiskową z tego parametru (-Dlogin.security=dev) która zostanie zarejestrowana jako źródło własności domyślnie
2. zarejestrować plik jako własność źródło programowo, o których mowa w artykule blogu pisząc zwyczaj ApplicationContextInitializer aby zarejestrować swoje źródło własności - powinieneś być w stanie korzystać z ResourcePropertySource zarejestrować plik oparty źródło nieruchomość

Answer 3

powinno być o wiele łatwiej, co trzeba teraz przez @Inject Environment i za pomocą profili. Nie trzeba wymieniać części nazwy pliku.