Github user eolivelli commented on the issue:
https://github.com/apache/bookkeeper/pull/210
Some comments:
1) is it possible NOT to bundle all the implementations in
bookkeeper-server project ?
Or at least mark the dependencies as "provided" o "runtime" so that we do
not make clients import transitively all that new jars. Maybe we can do as for
stats-providers
2) we are giving access to Bookie configuration, what about security ?
Maybe an user can provide a custom implementation of the HttpServer which
requires auth ?
3) @reddycharan I think that this could be the base for implementing the
dropped JMX-based features, we could (in another issue)
4) I think that this proposal does not 'force' a clear HTTP API to
implementations, that is that from the various implementations it seems that we
want to provide a REST-like API but it is really up to the implementations.
This actually means that no one can write other tools to integrate with the
Bookie, as the API will depend on the actual provider .
It would be better to decide a standard API and document it.
I am really in favor to make the low level implementation "pluggable": for
instance I run my Bookies in the same process of a Tomcat and/or with Jetty.
I think that a better approach would be to provide a standard HttpServlet
which could be deployed to any standard Web Container. This way we (BookKeeper
community) will be driving the API and the security aspects of the Bookie
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
