Suppose this is a configuration data object that I read from DB/XML:
class ConfigurationClass{
//some configurations
public String getString(){
}
}
Now this is the class that uses this configuration object
class ConfigurationUser implements Reloadable{
private ConfigurationClass configuration;
//some extra logic required for making object ready to use
public void init(){
// some new object is created based on configuration
SomeObject obj = new SomeObject(configuration.getString());
//register to configuration manager
}
#Override
public void reload(){
//does whole reloading stuff
//creates a new instance of configuration class and reads new configuration which is not appropriate
}
}
Now when I have to reload the configuration then suppose I create a new instance of ConfigurationClass and inject it in ConfigurationUser class.
But I will also have to re-initialize the object, so that it can create new configuration dependent objects.
Is this a proper design to do it or there is a better approach? I thought of using Spring or Google Juice for DI, but again I will have to provide the callback to the configuration user class, that configuration has been reloaded.
I am new to using IoC containers so dont know if it is possible. Need to use this in real time server application so have to be strict about garbage production and performance.
Current solution:
public interface Reloadable{
public void reload();
}
I have a configuration manager to which I register all the configuration user instances, and when reload is to be done, manager just calls reload and it reads new configuration and re initializes all dependent objects.
Any help would be appreciated.
I think you're looking for an Observer/Listener design pattern. Your configuration user should be an "observer" and a configuration itself will be a "subject". First, the observer registers itself in a subject. Next, every time a subject is changed it notifies all observers, and they reload (or do anything they wish).
Related
I have an application with some externalized configuration in the form of properties. I would like the application to react to a change of such properties without a restart or full context refresh.
I am not clear what my options are.
Artificial example: the application implements a service that receives requests and decides whether to queue or reject them. The maximum size of the queue is a property.
final int queueMaxSize = queueProperties.getMaxSize();
if (queue.size() >= queueMaxSize) { //reject }
Where QueueProperties is a class annotated with #ConfigurationProperties.
#ConfigurationProperties(prefix = "myapp.limits.queue")
#Getter
#Setter
public class QueueProperties {
public int maxSize = 10;
}
This works as far as allowing me to control behavior via system properties, profiles, etc.
However, I would like to be able to change this value without releasing/deploying/restarting/refreshing the application.
My application already uses Archaius.
If I push a new value for this property using our internal infrastructure, i can see the application Spring Environment does receive the new value.
(e.g., /admin/env reflects the value and changes dynamically).
The part I'm not clear on is: how to make my service react to the change of value in the environment?
I found two ways, but they seem hairy, I wonder if there are better options. I expected this to be a common problem with a first class solution in the Spring ecosystem.
Hacky solution #1:
#Bean
#Scope("prototype")
#ConfigurationProperties(prefix = "myapp.limits.queue")
QueueProperties queueProperties() {
return new QueueProperties();
}
And inject this into the service using the properties as Provider<QueueProperties> and use it as queuePropertiesProvider.get().getMaxSize().
This works but has a few side-effects I'm not a fan of:
ConfigurationProperties annotation moved from the class to the bean definition
A new QueueProperties object is created and bound to values for every request coming in
Provider might throw on get()
Invalid values are not detected until the first request comes in
Hacky solution #2:
Don't annotate my properties class with ConfigurationProperties, inject the Spring environment at construction time. Implement the getters as such:
int getMaxSize() {
return environment.getProperty("myapp.limits.queue", 10);
}
This also works ok in terms of behavior. However
- This is not annotated as property (unlike the rest of the properties classes in this large project, makes it harder to find)
- This class does not show up in /admin/configprops
Hacky solution #3:
Schedule a recurring task that uses Environment to update my singleton QueueProperties bean.
Any further ideas/suggestions/pointers?
Is there a canonical/recommended way to do this that does not have the shortcoming of my solutions above?
I am writing a library which will be used by spring-boot projects. I'd like to inject into the boot projects' SpringEnvironment a property source that I take from the Internet.
I tried the following
#Configuration
public class MyCustomConfiguration {
#Bean
BeanDefinedAbove above() { /* do some work */ }
#Bean
#ConditionalOnBean(BeanDefinedAbove.class)
SmartInitializingSingleton propertySourceSetting(ConfigurableEnvironment env, BeanDefinedAbove bean) {
return () -> {
PropertySource source = bean.getPropertySourceDownloadedFromTheInternet();
env.getPropertySources().addFirst(source);
}
}
}
In my clients' projects when I debug this code what happens is either one of the two:
above() is called
user's #Service or #Controller are called
propertySourceSetting(...) is called
OR
user's #Service or #Controller are called
above() is called
propertySourceSetting(...) is called
Depending whether or not my client's depend on my BeanDefinedAbove bean, which is normal as the #Service is depdent on the bean created in above().
I have also added the FQDN of my class to the EnableAutoConfiguration in the META-INF/spring.factories.
So how to ensure that the logic in propertySourceSetting(..) is called before users' #Service and #Controller
I'll provide you with three options.
Option 1: (THIS IS A BAD APPROACH, BUT A QUICK WORKAROUND)
Add #Lazy(false) annotation to both Beans. Spring will eagerly create those two beans, which they will probably be created before the other ones.
Why this is bad?
This does not ensure order. Spring decides the creation order based on dependencies and some other conditions. This is why it will "probably" work :)
Option 2: Create a main class to bootstrap Spring Boot Initialization (the old way of starting spring boot).
public static void main(String[] args) throws Exception {
SpringApplication application = new SpringApplication(MyApplication.class);
// ... add property source here before start
application.run(args)
}
You also need to specify main class in the manifest for Spring Boot like this: https://www.baeldung.com/spring-boot-main-class
In that main-class you would add your propertysource, kinda like this:
SomeClassThatRetrievesProperties propRetriever = new SomeClassThatRetrievesProperties ();
Map<String,String> properties = propRetriever.getAllPropertiesAsMap();
application.setDefaultProperties(properties);
Option 3: Create a CustomApplicationContext by extending WebApplicationContext and overriding getSpecificConfigurations() method.
This way you will have full control but we aware that you could break some important stuff.
I am working on a OSGi application(with felix scr annotations) which exposes a service. The Service registers with external api's by passing String values.
listener.addSchemaChangeListener(new ChangeListener()
{
#Override
public void schemaChange(ChangeEvent changeEvent)
{
String schemaName = changeEvent.getSchemaName();
if (null != myBuilder && schemaList.contains(schemaName))
{
initVariables();
}
}
}, "SCHEMA1");
Service uses the above piece of code to register the listeners for mulitple values "SCHEMA1", "SCHEMA1", "SCHEMA3" ...
I am planning to reuse this service in various bundles. But i want to listen only for SCHEMA1 changes instead of all.
#Reference (name = "ServiceListener"", policy =
ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.MANDATORY_UNARY, bind = "bind", unbind =
"unbind", referenceInterface = ServiceListener.class)
private AtomicReference myServiceListener = new AtomicReference<>();
If i try to use it in another service with #Reference then there is no provision to pass values to service to listen only for particular schema changes so that
the service can be resued across my bundle by only passing the list of schema to listen instead of all. Because activate method will be called once the service is binded properly in the usage class(component).
Is there any provision in OSGi to acheive this functionality ?
You have included very little description of how your application is actually working, which makes this question challenging to answer.
From the code that you have shared it looks as though you are following quite a bad pattern. The Listener pattern is a source of many synchronisation problems and memory leaks, and the whiteboard pattern should be preferred when you are in OSGi.
The whiteboard pattern is pretty simple. Rather than having each listener look up a service and register with it, you invert the model. The source of events (in this case schema changes) looks for listener services that are registered in the OSGi service registry. That way the listeners are simple to write and filter, and there is no messy and error-prone add/remove listener logic to code.
A better model would use service properties to select particular schemas and look something like this (using the standard OSGi annotations).
Listener 1 (listens to changes for SCHEMA1)
#Component(
property="schemaName=SCHEMA1")
public class MyListener implements ChangeListener {
// Your implementation in here
}
Listener 2 (listens to changes for SCHEMA1, SCHEMA2, and SCHEMA3)
#Component(
property={"schemaName=SCHEMA1",
"schemaName=SCHEMA2",
"schemaName=SCHEMA3"})
public class MyListener implements ChangeListener {
// Your implementation in here
}
Example Source of events for Schema1:
#Component
public class MyListener implements ChangeListener {
#Reference(policy=DYNAMIC, target="(schemaName=SCHEMA1)")
private final List<ChangeListener> listeners = new CopyOnWriteArrayList<>();
private void onSchemaChange(ChangeEvent event) {
listeners.forEach(l -> l.schemaChange(event);
}
// Rest of your implementation in here
}
One way is to create one service for each schema. You can do this by supplying the schema name as a config value and using several configs. Each such service will then also hav this config parameter as a service property. So the clients then can filter for the schema property.
If you do not want to use these configs then you could create one service that offers a factory. Each client then would bind the factory and create an instance by supplying the schema name in the create method of the factory.
I have a spring service that provides configuration data. When the service is invoked by the GUI, it loads the configuration data from the database. It turns out that this happens quite often during the rendering of a single request. I want to optimize this by caching the configuration data. However, I am not sure if this is a good programming style or if it is "allowed" to have an instance variable in a service.
Here is some example code of what I am thinking of doing:
#Serivce("MyConfigService")
public class MyConfigServiceImpl implements MyConfigService {
private Config cachedConfig;
#Override
public Config loadConfig() {
if (cachedConfig != null) {
// load config
cachedConfig = loadedConfig;
}
return cachedConfig;
}
#Override
public saveConfig(Config config) {
cachedConfig = null;
// save the configuration
}
}
Having a instance variable (not managed by spring) introduces the possibility of the service becoming thread unsafe. So I try to avoid them, or make sure they are thread safe.
You may want to look at #configurable and #postconstuct annotations to achieve your goals.
Are instance variables allowed in Spring service layer classes? Sure.
Is it a good idea to use one to save a reference to the Config object here?
Maybe, maybe not.
You're not showing how Config normally gets loaded... Does the same Config instance get returned to all users? i.e. - When User1 calls saveConfig then User2 calls loadConfig User2 gets the Config object User1 saved.
If so, you should be able to cache the value with no problems.
Also, instead of implementing it yourself, you could use Spring's annotation-based caching.
Instance variables is what Spring IoC container is all about; what is dubious in your design is that you have your own lazy-loading logic in loadConfig—that's the concern you must leave to Spring via lazy-init=true (or similar, I don't remember exactly). The design will also probably involve lookup methods and posibly request-scoped beans.
I'm trying to change some legacy code to use DI with Spring framework. I have a concrete case for which I'm wondering which is the most proper way to implement it.
It is a java desktop application. There is a DataManager interface used to query / change data from the data store. Currently there is only one implementation using a XML file for store, but in the future it is possible to add SQL implementation. Also for unit testing I may need to mock it.
Currently every peace of code that needs the data manager retrieves it by using a factory. Here is the source code of the factory:
public class DataManagerFactory
{
private static DataManagerIfc dataManager;
public static DataManagerIfc getInstance()
{
// Let assume synchronization is not needed
if(dataManager == null)
dataManager = new XMLFileDataManager();
return dataManager;
}
}
Now I see 3 ways to change the application to use DI and Spring.
I. Inject the dependency only in the factory and do not change any other code.
Here is the new code:
public class DataManagerFactory
{
private DataManagerIfc dataManager;
public DataManagerFactory(DataManagerIfc dataManager)
{
this.dataManager = dataManager;
}
public DataManagerIfc getDataManager()
{
return dataManager;
}
public static DataManagerIfc getInstance()
{
return getFactoryInstance().getDataManager();
}
public static DataManagerFactory getFactoryInstance()
{
ApplicationContext context =
new ClassPathXmlApplicationContext(new String[] {"com/mypackage/SpringConfig.xml"});
return context.getBean(DataManagerFactory.class);
}
}
And the XML with the bean description:
<bean id="dataManagerFactory"
class="com.mypackage.DataManagerFactory">
<constructor-arg ref="xmlFileDataManager"/>
</bean>
<bean id="xmlFileDataManager"
class="com.mypackage.datamanagers.xmlfiledatamanager.XMLFileDataManager">
</bean>
II. Change every class that is using the data manager so it takes it through the constructor and store it as a class variable. Make Spring bean definitions only for the "root" classes from where the chain of creation starts.
III. Same as II. but for every class that is using the data manager create a Spring bean definition and instantiate every such class by using the Spring Ioc container.
As I'm new to the DI concept, I will appreciate every advice what will be the correct and "best practice" solution.
Many thanks in advance.
Use option 3.
The first option keeps your code untestable. You won't be able to easily mock the static factory method so that it returns a mock DataManager.
The second option will force you to have the root classes know all the dependencies of all the non-root classes in order to make the code testable.
The third option really uses dependency injection, where each bean only know about its direct dependencies, and is injected by the DI container.
Well... why did you write the factory in the first place? Spring is not intended to make you change how you write code (not just to suit Spring that is), so keeping the factory is correct as it uses well-known pattern. Injecting the dependency into the factory will retain that behaviour.
Option 3 is the correct route to take. By using such a configuration you can usefully take components of your configuration and use them in new configurations, and everything will work as expected.
As a rule of thumb, I would expect one call to Spring to instantiate the application context and get the top-level bean. I wouldn't expect to make repeated calls to the Spring framework to get multiple beans. Everything should be injected at the correct level to reflect responsibilities etc.
Beware (since you're new to this) that you don't plumb in your data manager into every class available! This is quite a common mistake to make, and if you've not abstracted out and centralised responsibilities sufficiently, you'll find you're configuring classes with lots of managers. When you see you're doing this it's a good time to step back and look at your abstractions and componentisation.