I have a properties file for messages in my Spring application.I want to access these value directly in controller.How can i do this ?.
Note: I don't want to use #Value annotation to store data in another variable.
You can reference this question and answer regarding accessing files directly within controller.
It is what i used to implement mine.
Accessing multiple property files with #PropertyResource in spring
As M.Deinum suggested already, you should have a MessageSource bean definition if the purpose of the properties file is to externalize messages. A message source is automatically picked by the application context, meaning it is available for injection in every other bean. You can autowire it for example in your controller:
#Autowired
private MessageSource messageSource;
and then use its methods to access any message in any locale
Related
I am developing a sample application that Spring Batch with Spring Boot. My requirement is:
Have my own implementation of BasicBatchConfigurer so that I can configure AsyncTaskExecutor and my own dataSource as I am using SAP HANA as DB for which databaseType is not supported.
I want to use #EnableBatchProcessing(modular=true) so that I can register multiple jobs and launch them with separate Child Context
I have added all the required configurations. Without setting modular=true the Job is Launched and works as expected. It initializes the beans defined from my implementation of BasicBatchConfigurer.
However, once modular=true is set, the beans from my implementation are not initialized.
The code is hosted here: https://github.com/VKJEY/spring-framework-evaluation
I debugged further into the issue:
Looks like, When we set modular=true, BatchConfigurationSelector uses ModularBatchConfiguration
In ModularBatchConfiguration, there's a field Collection<BatchConfigurer> configurers. This has been annotated as #autowired.
I assume that this field is auto initialized if I provided a implementation
of BatchConfigurer as it has been mentioned in the comments of ModularBatchConfiguration class as well
However, While debugging I realized that the above field is still null beacuse of which, It loads DefaultBatchConfigurer and follows the default flow.
My question is why is that field configurers not being initialized in ModularBatchConfiguration? Am I missing something?
I am using Spring boot 2.1.2.
My question is why is that field configurers not being initialized in ModularBatchConfiguration? Am I missing something?
You are hitting a lifecycle issue between Spring Boot custom auto-configuration that you defined in the META-INF/spring.factories file and Spring Batch configuration.
I debugged your code and here is how to fix the issue:
remove org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.job.data.persistence.config.AsyncBatchConfigurer
from META-INF/spring.factories file. This is not needed as Spring Batch
will detect the AsyncBatchConfigurer when it is declared as a bean.
You can even remove this spring.factories file
remove #ConditionalOnMissingBean(BatchConfigurer.class) from AsyncBatchConfigurer:
Since you declared this class as a #Configuration class, it will also be defined as a bean of type BatchConfigurer and will be detected by ModularBatchConfiguration
With these two changes, the field configurers in ModularBatchConfiguration is correctly autowired with your AsyncBatchConfigurer.
As a side note, you don't need the AsyncBatchConfigurer#configurers method as Spring will do the work of injecting all BatchConfigurer beans in ModularBatchConfiguration.
Hope this helps.
I found an spring boot sample code in which properties are being injected directly with #Value.
The point is that those properties come from a bean which is not present actually in the code.
The annotations have this aspect:
#Value ("#{envPC['desktop.url']}")
private String url = "";
So I have a couple of questions:
1-how can I define env bean?
2-when defining the env bean, how can I modelate the correct structure for references like: desktop.url, desktop.port....
I hope the questions are clear.
Thanks in advance
Environment bean is implicitly defined within Spring context. Spring collects properties from multiple sources into this bean: JVM options, property files added via #PropertySource, etc.
Also it can be injected like any other bean:
#Autowired
private org.springframework.core.env.Environment environment;
More details can be found at https://docs.spring.io/ or in this nice article: http://www.baeldung.com/properties-with-spring
Let's ignore for a moment whether doing this is a great idea, but I'm creating Spring Boot AutoConfiguration for an internal library and as part of this I want to auto-register a Controller that accepts GET/POST/DELETE requests (it is responsible for setting/clearing a cookie value for application testing purposes)
The issue is that I would like the request mapping path to be configurable by the end user. I have a #ConfigurationProperties(prefix = "my.configs") class that contains all the configuration values with their defaults for example: private String path = "default-path"
Ideally i'd be able to reference this in my controller like so: #RequestMapping(path=${my.configs.path}) but this does not work, Spring reports that it is unable to find that configuration parameter, if I place it into a properties file instead of into a the type-safe #ConfigurationProperties it works as expected.
I know I could get around this by putting a default value into the Request mapping, but I'd like to understand just what is happening here, and why I cannot statically refer environment variables read / defaulted into #ConfigurationProperties in the way that I can those defined in files.
#RequestMapping is a Spring MVC annotation and it gets processed by Spring MVC - no matter if it is all wrapped in Spring Boot app or not.
#ConfiguationProperties is on the other hand 100% Spring Boot code and to my knowledge both types of properties are processed at different moments during Spring Context startup lifecycle.
In XML file in spring we have two bean with different id but same class. They have the same properties offcourse. Now I have InitializingBean interface and in afterPropertySet() I am just printing the value of properties.
Its printing the values two times for me?
According Spring Documentation:
afterPropertySet()
Invoked by a BeanFactory after it has set all bean properties supplied (and satisfied BeanFactoryAware and ApplicationContextAware).
So the short answer on your question is: yes
Spring doesn't manipulate classes or object. Spring manipulates Bean Entity. It is the simplest object manipulated by Spring IOC. Bean has additional behaivior rules introduced by Spring.
If you create two beans for example with Singleton scope and not Lazy initializated Spring creates two instances of your class.
Probably you are calling this Class also invoking a Test or by launching a Integration test like this . check the breakpoints , if you are using SpringRunner, try to mock the component
I want to clear some moments about integrating spring and struts. I have only one action class per application extended from MappingDispatchAction. So, actually my app when doing something uses not Action objects, but methods from my action. All I want from spring is to initialize this action and all for now. Just simply set DAO object. I looked through documentation, but I don't understand following:
We use action path from struts-config.xml as a name of bean in action-servlet.xml. Okay, but am I supposed to write beans in action-servlet.xml for every path name and set this poor DAO ref or what ?
The Struts 1 config file will use the DelegatingActionProxy class as the type attribute for all action configurations.
The Spring config file will contain the bean definitions of each action implementation. I don't know what DAO you're talking about, but actions that require DAO or service injection need to have them listed, yes--that's what Spring configuration is.
You may also be able to use annotations if you're not interested in using XML configuration, or use bean inheritance if many beans share the same DAO/service/etc. property values.