I am trying to create a project with one spring configuration file. but inside the configuration file all beans are interfaces without any implementations. i would create one more project with all implementations. Also can i use abstract = true for all the beans(interfaces) of first project, so that user cannot use them.
Thanks!
I can't imagine a situation where you want to specify interfaces in the spring config file. So I think it is unnecessary for you as well. You can use abstract=true to create reusable or partial bean definitions.
You cannot specify interfaces in in your spring config, since they cannot be instantiated. What exactly are you trying to archive?
Related
I encountered handful of guides to creating spring data jpa projects and people configured persistence layer using properties file and javaconfig both. If we one uses javaconfig why would they even bother to create another properties file to include configurations? If one strategy is used(i.e. JavaConfig) to configure project , what is the use of the other (i.e. properties file) strategy? Do I have a misunderstanding as to how to configure projects?
JavaConfig was mostly used for old version of Java or legacy projects. It is a helper library used to avoid the boiler plate needed to write a code to open the properties file and map the values directly to a class that can represent your properties in memory.
With JavaConfig your code will looks like this and without it, your code will look like this.
If one strategy is used(i.e. JavaConfig) to configure project , what
is the use of the other (i.e. properties file) strategy? Do I have a
misunderstanding as to how to configure projects?
Properties file, is the standard used in Java to store external configuration values. It is a key/value file, example: application.properties or application.yml are used in modern framework such as Spring, that offer a simple way to manage your properties file.
I love the Spring properties loading mechanism. The fact that you can define several profiles and override or extend properties with other profiles, that you can use different file types (.properties, XML, JSON, ...) to store your properties, that you can use the value of other properties to resolve its own value, aso.
But to use the properties, you have to somehow initialize the Spring context (#SpringBootApplication or #SpringBootTest). And I would like to use this property loading mechanism in some libraries, where I cannot guarantee that the context is loaded (and I do not want to load it).
So, my question:
Can I somehow create a class that uses the Spring libraries to load the properties (on demand) in the same way Spring loads its properties?
Other classes will then use this class to access the properties. No need to load with annotations.
I was searching for this for some time, but I haven't found a solution, yet.
Would be great if so. knows a solution for that.
Regards, stay healthy and merry X-Mas!
The property lookup mechanism is defined by interface PropertyResolver, extended by interface Environment to support profiles, further extended by interface ConfigurableEnvironment to support PropertySources, i.e. the concept of searching through a set of property sources to find a property.
It is implemented e.g. by class StandardEnvironment, which defines property source for:
system properties
system environment variables
All the above are part of package org.springframework.core.env, i.e. part of the spring-core-XXX.jar file.
Support for application.properties files is added by class ConfigFileApplicationListener in package org.springframework.boot.context.config.
The class needs an instance of SpringApplication in package org.springframework.boot.
They are part of the spring-boot-XXX.jar file.
So, getting basic Spring property support is easy, just create a StandardEnvironment object.
Getting application.properties files loaded is deeply embedded in the Spring Boot code, and would be really difficult to do without initializing the Spring context.
I'm creating a JavaModule with some utilities class.
This module will used from some different Java Applications (these projects will be have the dependency into their pom files).
Into my JavaModule I would like to use some properties files to store the settings values. I con't use Spring int this module.
What's the best practice to use the properties files into a JavaModule without using Spring annotations?
Is it the correct way as reported in this example?
What's the correct place where I have to put the properties files? Can I use a dedicated folder?
Is there a way to override a specific value that it's contained into my Java Module's properties file from a Java Application that use my module?
I would use that logic, and afaik is the most common. But I was also in a project in which we used ResourceBundle even though it should be used to retrieve locale specific data, because it was less verbose.
In that case was just:
ResourceBundle.getBundle("properties").getString("my.property");
Once again. The example from mkyong would be my first choice for anything but a POC.
I'm working in a webapp and this is the first time that I'm using Java based configuration. I have a bunch of class to configure all:
ApplicationContext
PersistenceContext
SecurityContext
WebAppInitializer
WebMvcContext
Now I'm defining Spring Data repositories and the service layer so I need to inject the repositories there. Normally I would use Autowired but I've read that it is preferable to define the injections manually so the question is, where?
Maybe neither of the previous configuration classes is suitable for such task but, do I have to create a single class to define all the injections or is better to have on for each function? What happens if the project grows too much?
I think that the main question would be what is best way to organize dependencies in a Spring project. What do you do?
I add here an image of the structure of the project as a petition. I'm trying to decouple layers and now I need to inject UserRepository to UserService.
No, I would not define a single class to do all the injections. All your classes are coupled that way.
I don't understand what "define the injections manually" means. You have to specify them in either XML or annotations. There's no other way that I know of.
You don't say if you're using XML or annotation configuration. I find myself using the latter more of the time, with only enough XML configuration to tell the Spring app context to scan for annotations.
The Spring idiom would have you specify your configuration in layers if you're using XML. It's a moot point for annotations, because they go into your source code.
Your application will read the Spring context on start up, instantiate all the beans, and wire together the necessary dependencies. You're good to go from then on.
I disagree with the link you provided. Avoid autowiring? No.
The article said that he recommends using XML configuration for large projects. This is a very small project at this point. It seems to me that auto wiring with annotations would be fine even by the article's author's words.
I have an application structured as follows:
dao
domain
main
services
utils
I've made a class that reads the application configuration from an XML file. The question is where should it be placed?
By reflex, I'd have placed it in utilities but utility classes have static methods and are stateless whereas this class uses an instance of Apache Commons XMLConfiguration. Should I just adapt the methods so this instance is limited to the scopes of the methods in this class?
I assume the items are packages, so I'd go with the main package.
dao
domain
main contains the application and its configuration readers
config
log
services
utils
Why? The configuration of an application, whether it be in XML or not and whether it is based on an application framework such as Spring or not, is part of its main functionality. Booting up an application is the main responsibility of the application. All the business functionality, all the shiny features it provides are implemented in the domain and service layers.
You're right, utils is all about static or similar tools. As the configuration of an application is very important, I wouldn't declare it a utility. A utility is something which can be easily replaced by another utility of same type (e.g. StringUtil vs. StringUtils vs. IOUtils etc. they all have very similar functionality)
This depends on the build system and application type you use i.g. maven would suggest to place configfiles in src/main/resources
In WAR file you could place them in WEB-INF or WEB-INF/config
According to your project structure I would suggest to introduce a folder config or resources, since almost everybody would expect them there.
If you are working with Spring, take a look at Configuration Placeholders. You can use a simple java properties file for your configuration properties and place it on your class path (or any other location). Alsou you could create your own implementation to use a different form of keeping your configuration values (XML, Database etc.)
As configuration is a cross-cutting aspect it doesn't map exclusively to one of these layers. Place the configuration files (XML or properties) into the classpath and use it via Spring to configure your beans.
For properties based configuration data the PropertyPlaceholderConfigurer is a good solution.
I urge you to have a look at Spring. Might seem like overkill for you in the first place, but you wil love it.