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.
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 :)
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!
Thank you Josh! Explanation is precise and to the point 😀
Just two days ago we tried to use this pattern, but due to not having the idea we did it manually. Thanks.
Nice one! I practically enjoyed this.
Very useful. Thank you Josh!
Thank you very much, can I package these plugins in separate jars?
Thank you very usefull!
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.
A great video 👌👏
Very nice, now time to refactoring 😂
good tips
Good Stuff
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 :)
Good Day
nice one!
What Is differece between plugin and make manually? Wha is extra or advantage? It's become probably a complex code using a dependency.
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?