Val, Sounds reasonable. I just think, that user should have some way to know, that new version of a service class was deployed. One way to do it is to listen to *EVT_CLASS_DEPLOYED. *I'm not sure, whether it is triggered on class redeployment, though. If not, then another event type should be added.
I don't think, that a lot of people will implement their own *DeploymentSpi*-s, so we should make work with *UriDeploymentSpi* as comfortable as possible. Denis пт, 6 апр. 2018 г. в 23:40, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Yes, the class deployment itself has to be explicit. I.e., there has to be > a manual step where user updates the class, and the exact step required > would depend on DeploymentSpi implementation. But then Ignite takes care of > everything else - service redeployment and restart is automatic. > > Dmitriy Pavlov, all this is going to be disabled if DeploymentSpi is not > configured. In this case service class definitions have to be deployed on > local classpath and can't be updated in runtime. Just like it works right > now. > > -Val > > On Fri, Apr 6, 2018 at 10:20 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov <dpavlov....@gmail.com> > > wrote: > > > > > Hi Igniters, > > > > > > I like automatic redeploy which can be disabled by config if user wants > > to > > > control this process. What do you think? > > > > > > > I do not think we should have anything automatic when it comes to > > deployment, everything should be explicit. However, if we use the > > deployment SPI, then a user should be able to do "hot" redeploy, where a > > new service will be deployed if the user drops an updated jar. > > > > We should not create anything new here. Ignite already has a deployment > SPI > > and it already works in a certain way. Let's not change it. > > > > D. > > >
