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.
- Sijie On Wed, Oct 19, 2016 at 9:40 AM, Sijie Guo <[email protected]> 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 <[email protected]> > 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.ExtensionRegistry 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.GenericCallback<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. >> } >> >> } >> > >
