Denis, it's not about different users services implementations. A real use case is user's services API versioning which is being used widely t in SOAP/REST microservices infrastructure.
In my opinion, it is about services with the same name and the same full class name, but different classes versions for example in different classloaders. On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <dmekhani...@gmail.com> wrote: > > I don't think, that we really need this feature. > It seems to me, that if you want to use a different implementation of a > service, you can assign a different name to it. > > What do you think? > > Denis > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <daradu...@gmail.com> > > wrote: > > > > > Hi, Igniters! > > > > > > I found a ticket about a service’s versioning [1]. > > > > > > It’s out of scope IEP-17, but if we are going to implement this > > > feature we should build a base in the first iteration of IEP-17 > > > because of change messages formats. > > > > > > In case of the versioning which assumes that we are able to host > > > services with the same name, but with different class/version, we > > > should introduce *service’s id* to manage service’s lifecycle instead > > > of service’s name. > > > > > > Thoughts? > > > > > > > My only concern would be on the usability side. Is user going to have to > > deal with IDs now, or will it be handled internally? > > > > D. > > -- Best Regards, Vyacheslav D.
