Hi, Spring fans! In this installment Josh Long (@starbuxman) looks at the little-known, often-used Spring Plugin project, which supports the strategy pattern
Hi @joshLong Is there a way of deploying the plugins while the application is already running without restarting? I can't find proper documentation, I really need to use this
I don’t get the different to having multiple components that implement the same interface and then just autowireing the interface type as a map with the bean name as key or using qualifier annotation ?
@Julian Ruppel one of the main points of this library is that it comes with an interface that allows to model if a bean supports the operation. How would you choose the supporting beans in the map in your example? By storing a set of classes? The library also works when the support overlaps for different plugin, example with a registry of 3 plugins, it can be that the 1 plugin supports working and handling modes A,B,C,D. the 2nd plugin supports modes B,C,D and a third plugin supports only E. The library comes handy and helps in complex scenarios should it be your case :)
I was wrong the entire time. I saw this in one of the spring source and have been doing this pattern in my codes for a long time, but I name it with "Factory" prefix instead of "Strategy", as I thought this is a Factory Pattern. Man, I have no idea what I'm doing lol.
Hey Josh, I'm trying to get an idea on this use case. How is this different from @ConditionalOnProperty on a @Configuration class that defines a bunch of beans?
ConditionalOnProperties applies to beans before they get registered. Here, objects are dynamically invoked. Add a Database/REST call (for example) and the logic is resolved at runtime.
@@jimmyl9658 Hi Jimmy, I have a question with "dynamically invoked". Does it means with Spring Plugins, objects are been lazily registered just like you put @Lazy on a normal bean?
Nice, I have tons of places where I used my own impl of this pattern. This will help refactoring. Thanks!
Nice one! Gave me idea where I can use it in my project. Some refactoring on the way. Thanks Josh!
Very useful. Thank you Josh!
Nice one! I practically enjoyed this.
Just two days ago we tried to use this pattern, but due to not having the idea we did it manually. Thanks.
good tips
Good Stuff
Thank you very usefull!
Very nice, now time to refactoring 😂
Good Day
nice one!
Thank you very much, can I package these plugins in separate jars?
Hi @joshLong Is there a way of deploying the plugins while the application is already running without restarting? I can't find proper documentation, I really need to use this
I don’t get the different to having multiple components that implement the same interface and then just autowireing the interface type as a map with the bean name as key or using qualifier annotation ?
@Julian Ruppel one of the main points of this library is that it comes with an interface that allows to model if a bean supports the operation. How would you choose the supporting beans in the map in your example? By storing a set of classes? The library also works when the support overlaps for different plugin, example with a registry of 3 plugins, it can be that the 1 plugin supports working and handling modes A,B,C,D. the 2nd plugin supports modes B,C,D and a third plugin supports only E. The library comes handy and helps in complex scenarios should it be your case :)
I was wrong the entire time.
I saw this in one of the spring source and have been doing this pattern in my codes for a long time, but I name it with "Factory" prefix instead of "Strategy", as I thought this is a Factory Pattern.
Man, I have no idea what I'm doing lol.
Could be that you are using a factory to create the concrete strategies. It is common to have a factory method pattern and strategy pattern together.
What Is differece between plugin and make manually? Wha is extra or advantage? It's become probably a complex code using a dependency.
Thank you Josh! Explanation is precise and to the point 😀
Hey Josh, I'm trying to get an idea on this use case. How is this different from @ConditionalOnProperty on a @Configuration class that defines a bunch of beans?
ConditionalOnProperties applies to beans before they get registered.
Here, objects are dynamically invoked. Add a Database/REST call (for example) and the logic is resolved at runtime.
@@jimmyl9658 Hi Jimmy, I have a question with "dynamically invoked". Does it means with Spring Plugins, objects are been lazily registered just like you put @Lazy on a normal bean?
A great video 👌👏