On Mon, Jul 24, 2017 at 1:29 PM, Enrico Olivelli <[email protected]> wrote:
> Il lun 24 lug 2017, 19:39 Sijie Guo <[email protected]> ha scritto: > > > On Mon, Jul 24, 2017 at 5:22 AM, Enrico Olivelli <[email protected]> > > wrote: > > > > > Hi, > > > we are going to release 4.5 soon, in this release we changed > > > EnsemblePlacementPolicy interface. > > > > > > It you are using a "custom" EnsemblePlacementPolicy in 4.4 and you just > > > switch the bookeeeper-server JAR on the classpath your application > won't > > > run. > > > > > > I already got that problem and I needed to implement some "support 4.5" > > > option in my projects which essentially tells "do not use a custom > > policy", > > > this is very bad because there is no way to apply the custom rules > > required > > > by the project. > > > > > > > Do you mean the new methods introduced in placement policy? Or methods > that > > whose signatures are changed? > > > > The new signatures > > > > > I believe the new methods 'reorderSequence' is disabled by default unless > > you enable it explicitly. > > > > For methods that whose signatures were changed, we can add the old > methods > > back and create overrides to keep the binary backward compatible. > > > > I don't know if this cam work. I have already tried. I will double check. > Anyway it will be a bit messy > > > > > However I am not sure if this works because the placement policy is > > instantiated and loaded by reflection. Typically when you upgrade a > > version, you have to compile it first, no? > > > > I have several libraries which use bk and they are built on 4.4 and they > are working together in the same classpath. > For instance now I am going to change one of them in order to leverage a > new 4.5 feature, like readUnconfirmedEntries just as an example, so I need > to switch to 4.5 on the classpath but the other projects won't run. > Are you talking about mixing 4.4 and 4.5 together? > For the server side this is not a problem but on the client it is a real > production problem. > Can you clarify more specifically on this? Not very sure I understand your problem and what are you going to achieve. > I am ok with changing the API, I was the first to ask to change it in 4.5 > in order to access custom metadata, but when we do such things I would like > to design a future proof API. > > I know it needs some time to design and I really to not want to block 4.5 > release. > I will send a BP and maybe we can discuss on a concrete proposal. > Can we first make things clear here before any proposals? > I think this change will break DL too. > When we upgraded the BK in DL, we will make some code changes to make sure binary compatible. > Does this sound good to you? > > Enrico > > > > > > > > > > As we are going to break the API now, would it be good to create a more > > > future-proof API ? > > > > We can just post-pone the problem to 4.6 > > > > > > Thoughts ? > > > > > > Enrico > > > > > > -- > > > -- Enrico Olivelli >
