I have just opened a PR with my proposal on https://issues.apache.org/jira/browse/BOOKKEEPER-959
-- Enrico 2016-10-20 14:20 GMT+02:00 Enrico Olivelli <eolive...@gmail.com>: > Here it it the issue > https://issues.apache.org/jira/browse/BOOKKEEPER-959 > > I will share some code soon > > I'm working on a SASL implementation similar to ZooKeeper SASL > implementation, in order to support oth MD5 and GSSAPI/Kerberos > authentication > > > 2016-10-20 0:37 GMT+02:00 Matteo Merli <mme...@yahoo-inc.com>: >> Hi Enrico, >> >> yes the shading of protobuf is a bit of a problem. A possible solution would >> be to include the implementation in BookKeeper itself, if it's of general >> interest. >> >> Another approach, could be to release both shaded and unshaded jars for >> bookkeeper-server artifact. > > I think we'd better to continue to shade protobuf, as it is a common > library and introduces compatibility problems. (we have just upgraded > to 2.6 which was compatibile only on the wire with previuos version) > >> >> >> Matteo >> >> >> On Wednesday, October 19, 2016 9:41 AM, Sijie Guo <si...@apache.org> wrote: >> >> >> I think we also need to think a solution on how to prevent this kind of >> shade behavior. It is not good to expose shade classes to any public >> interface. > > We should mark classes which are really part of the "Public API" (for > instance with annotations) and then we can develop/use some tool to > check the byte code > > >> >> - Sijie >> >> On Wed, Oct 19, 2016 at 9:40 AM, Sijie Guo <si...@apache.org> wrote: >> >> Ah, good catch, Enrico. >> >> It is really bad for this behavior. I think it should be fine to break the >> code backward compatibility for this interface. >> >> - Sijie >> >> On Wed, Oct 19, 2016 at 8:02 AM, Enrico Olivelli <eolive...@gmail.com> >> wrote: >> >> Hi, >> I'm going to implement a custom AuthProvider for BookKeeper, I have >> come to a showstopper: >> ClientAuthProvider.Factory depends on Protobuf ExtensionRegistry, >> which is shaded inside the BooKeeper JAR >> >> A custom provider will look like the code below, this is not good, >> because my code needs to depend on an "hidden" dependency of BK. >> >> I can file a JIRA and propose a fix, but any fix need to break >> compatibilty with existing custom Providers (But I assume that no >> implemention can actually exist, outside a fork of BookKeeper) >> >> What do you think ? >> >> This is an example >> >> public class CustomProvider implements ClientAuthProvider.Factory { >> >> @Override >> public void init(ClientConfiguration cc, >> bk-shade.com.google.protobuf.E xtensionRegistry er) throws IOException >> { >> throw new UnsupportedOperationException( "Not supported yet."); >> //To change body of generated methods, choose Tools | Templates. >> } >> >> @Override >> public ClientAuthProvider newProvider(InetSocketAddress isa, >> BookkeeperInternalCallbacks.Ge nericCallback<Void> gc) { >> throw new UnsupportedOperationException( "Not supported yet."); >> //To change body of generated methods, choose Tools | Templates. >> } >> >> @Override >> public String getPluginName() { >> throw new UnsupportedOperationException( "Not supported yet."); >> //To change body of generated methods, choose Tools | Templates. >> } >> >> } >> >> >> >> >>
