Just as a proof-of-concept I developed a simple SASL/Md%-DIGEST/Kerberos Auth provider https://github.com/eolivelli/bookkeeper/tree/BOOKKEEPER-391/bookkeeper-server/src/main/java/org/apache/bookkeeper/sasl
this is just a simple test, but it is very like to current ZooKeeper implementation and the implementation I have on Majordodo and BlazingCache projects Enrico 2016-10-20 16:24 GMT+02:00 Enrico Olivelli <eolive...@gmail.com>: > 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. >>> } >>> >>> } >>> >>> >>> >>> >>>
