You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently start() and stop() methods comes from the Plugin interface. It can be a good idea to move then to a new Lifecycle interface. The AbstractPlugin should extends this new interface for compatibility.
It will allow application developers to easily start/stop resources without creating a Plugin. Lifecycle implementations can be scanned during the init phase so there will be no need for ServiceLoader here.
The text was updated successfully, but these errors were encountered:
I think it is a good idea !
Let us think what can be the downside of this.
Why do not create a plugin that will do this exact thing ?
Will the Resource be injected ? or Injectable ? both ?
I imagine having this can be great.
Does plugin and resource really need to share this interface ?
Yes they should be injectable. Exactly like plugins currently.
And Yes, I think it should be the same interface. It's frequent that plugins don't implement lifecycle methods. So I think these methods could be extracted as a separate concern.
The kernel will start/stop all the Lifecycle implementations whether they are plugins or not. And not all the plugins have to implements Lifecycle.
I think the JSR 250 is also a must have but in another issue.
Adding jsr250 annotations on injected pojo might also be a good addition to the kernel.
I create the issue.
Currently
start()
andstop()
methods comes from thePlugin
interface. It can be a good idea to move then to a newLifecycle
interface. TheAbstractPlugin
should extends this new interface for compatibility.It will allow application developers to easily start/stop resources without creating a
Plugin
.Lifecycle
implementations can be scanned during the init phase so there will be no need forServiceLoader
here.The text was updated successfully, but these errors were encountered: