Extract application properties without controlling loading of properties files - java

I'm looking for a way to extract application properties. Most thread I found on this topic suggest inheriting PropertyPlaceholderConfigurer. But that is not an option as the loading of properties is done outside the application in a third party framework. Is there an other way to get the properties that does not involve overridden spring methods?

May be you can use jndi with spring application parameters?
For instance ->
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mock-objects-jndi

Related

How to modify properties resolved by Spring before their injection into beans

I need to provide support for external preperties decryption in Spring application. I planned to use a mechanism from spring-cloud-config, which is triggered after the Environment is ready and add decrypted properties with higher precedence. Unfortunately it heavily relies on Spring Boot bootstrap mechanism which emits ApplicationEnvironmentPreparedEvent. Looking into the Spring Framework code the environment and context creation is highly coupled and it would be rather hard to run my own code between that. The application I am working with is a large, multi module "standard" Spring MVC application and I would not like to convert it into Spring boot application right now.
Question:
How could I execute my code after the environment was created and before the context creation (to modify properties before they will be injected into "normal" beans) in Spring (not Spring Boot) application?
Alternative question:
Is there any other way to get control over properties being injected into beans (for modify values originally resolved by Spring)?
You can create a custom ApplicationContextInitializer which adds decryption or whatever to the PropertySources of your choice.
We do something similair in one of the application I currently develop. After loading some custom properties from files and databases we wrap all the available PropertySources in a EncryptablePropertySource because several properties are encrypted (We use the Jasypt library for that).
Use #Value("${propname}") annotation on a setter method, instead of using on the field.
You can write code to handle transform/validate the property in the setter method, and then assign to the field.
In the mean time I have found customizeContext method in ContextLoader which reads defined ApplicationContextInitializers. It is executed after the environment was created and before the context is reloaded, so decryption in an initializer should work (at least in the base case):
ConfigurableEnvironment env = wac.getEnvironment();
(...)
customizeContext(sc, wac);
wac.refresh();

Runtime loading of Controllers for Spring MVC and dynamically mapping requests/URLs

We are starting a new project using Spring MVC, and we would like to move away from annotation-driven request/url mapping. We wish to implement the following use case:
Use Case A
User enters a URL.
The request mapping handler retrieves a list of mappings (e.g. from the DB), and based on this dynamic list of mappings, it calls the relevant controller.
This is because we want to be able to do the following as well:
Use Case B
We want to load a new Controller (perhaps a new reports module) into the web app without having to redeploy or do a server restart.
We will map this new Controller to a URL and persist it somewhere (most likely the DB).
We would like the Controller to be registered in the Spring app context (managed by Spring).
We would then like to use this new Controller in the request mapping.
We've taken an initial look at the different ways we can implement this, but we are unsure of the best architecture/method to go about this route. A couple of questions:
For Use Case A, how do we implement this within the Spring MVC framework (or if it's possible)?
For Use Case B, is there a good framework or way to be able to do dynamically loading and registering of this for web applications? We've taken a cursory look at OSGI but it seems to be advisable for use in non-web applications.
For Use case A :
Instead of DB you can keep the url mappings in a property file and then use property place holder to initialize beans using xml configuration on context up. This way remaining inside the spring framework, you can avoid annotations.
For Use Case B :
Tomcat supports dynamic reloading of classes but that to of only non structural changes in class file. But this has memory leaks as well as it doesnt cleans up old instance of class loader rather it creates a new instance.
Its quite achievable using spring-mvc-router API.
Please check below link
url-action mapping & routing in Spring MVC 3.0
Here the URL can be configured to controller.method using .conf file, but this can be achievable using java configuration, and i haven't tried so far.
Also if xml configuration chosen, then check out the property 'autoReloadEnabled', but its not adviceable for production use.
Hope this helps!!!

How to load app-wide settings at startup (for Spring3 webapp)?

I am in the basic stages of writing a Spring3 MVC webapp with Hibernate. I want all of data model classes to be able to access basic configuration values for example, database table prefix name, etc. I want this option, so I (or other developers) can change things on the fly by modifying them in the .properties file.
Is my best bet to create a Config class in a util package with a static block that loads a bunch of properties from a .properties file? I suppose the class itself could be static with a variety of getters to access the values within.
If I choose the method above, how could I insure the application didn't load (Failed gently) if for some reason the .properties file I have specified was not able to be loaded? With exceptions?
If my way stinks, what might be a better scenario?
Thanks!
That's a fine approach IMHO. If you would explicitly declare a bean for this class, like
<bean id="myConfig" class="com.yourcompany.yourproject.Config"/>
spring will fail at startup if it cannot instantiate the bean. So if the properties file is unreadable/not available just throw an unchecked Exception from Configs constructor.
if -for some reason- you enabled lazy loading globally you have to explicitly disable it for this bean, otherwise you won't get a failfast solution
<bean id="myConfig" class="com.yourcompany.yourproject.Config" lazy-init="false"/>
EDIT:
another nice feature of this scenario is that you can tell maven to 'filter' the resource (the .properties file), and you can get all the maven variables. This is how my prop file looks (I use this info for the About dialog. Does anybody ever opens an about-dialog btw?)
project.version=${project.version}
project.name=${project.name}
project.organization.name=${project.organization.name}
project.url=${project.url}
project.description=${project.description}

Changing Spring PropertyPlaceholderConfigurer to read from another source

I'd like to extend/replace the Spring PropertyPlaceholderConfigurer to read from a web server as opposed to properties files.
A bit of background:
I work on a project, and we're finding the number of properties files located on the users systems is getting a little unwieldy. We'd like to replace these files with a 'config server' which will store basic key/value pairs and serve them when the user starts up the app.
To avoid making too many changes, I'd like to change the way the PropertyPlaceholderConfigurer finds properties - rather than implementing an entirely new way to manage properties. So on startup - Spring will read all properties from a url, and feed these into my spring config xml in the same way as it would have with actual files.
Bonus!
If anyone has any ideas how to do this where properties are reloaded from the server only when they change, will get bonus points (I have no idea if I have the ability to assign bonus points, but I'll try!). That would be a 'nice to have, if there's not too much effort involved' solution.
Spring's PropertyPlaceholderConfigurer (PPC) already uses the Resource interface to specfiy the location from where to read properties (via the setLocation(Resource) method inherited from PropertiesLoaderSupport.
There is an implementing class of this interface called URLResource which probably does what you want. You could simply create a PPC and set the location property with a bean of this type to load the properties from a URL instead of a file. This class also supports file:// type URLs, so you could switch between on- and offline properties loading depending on the URL you use.

Overwrite configuration for Spring project from outside

I'm developing a Spring application which shall be used by any kind of other application, no matter if that is a Spring project, a web application or even a simple single-class console application. The application who uses my project will just have to add the JAR file with my application.
So my project has a static factory class that gets and returns a bean from its Spring context which acts as an access object to access all public available functions of my project.
That part is already working.
But I need the developer of the application that uses my JAR to be able to overwrite certain configurations in my project without editing the config files in the JAR itself. At the moment those settings should be overwritable:
- the data source and hibernate bean configuration
- the jasypt (encryption) bean configuration
- the log4j settings
How do I make those settings overwriteable with configs from outside the jar?
Greetings
touchdown
Maybe a good solution would be a configuration that the user could override, for this take a look into:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java
Specially to #Configuration and #Bean
Maybe you could have a configuration class implemented and the user can override it. After extending the class and overwrite some methods that provides some beans the user shall inform it to your factory that will do nothing else than
new AnnotationConfigApplicationContext(userConfigurationClass);
If you want to replace the complete configuration, than the easyest way would be to have a parametrized factory that takes an alternative configuration file as its argument.
If you need it a bit more fine grain (lets say up to 10 parts), than you can split your application xml in several smaller once, and use again a configurable factory that allows to exchange the smaller xml files.
So I got a solution that is working for me.
I put an general import for override context-XMLs at the bottom of my main application context:
<import resource="classpath*:project/package/config/override/or-*.xml" />
So all the user has to do is to create the package "project/package/config/override" in his classpath (e.g. resource folder) and place matching XML files in it with new bean definitions.

Categories