Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Review Request 23988: Use Dropwizard to create a proper REST monitor service

Copy link to this message
Re: Review Request 23988: Use Dropwizard to create a proper REST monitor service

Is it possible to spawn this as part of the monitor, rather than a separate service, then? I don't mind a separate lib, but it seems a bit weird to have a separate process.

The point isn't moot. Many distributions disallow bundled binaries (because by some definitions, such are not considered "open source" even if they were derived from open source). And, forcing this to be a dependency (using the shaded jar approach) is a non-starter for such requirements. The approach to deal with bundled binaries is to rebuild from source... but that can't be done if it depends on an old version which has been superceded.

That's one reason why one might care what version of Jetty is being used. Another (quite important reason) why one might care is because an older version might have security vulnerabilities or bugs that require a user to use a newer version. If they cannot use a newer version, because we depend on something that exists in an older version (which happens routinely anyway, but it's still good to avoid if possible), that makes it that much harder for a user to adopt the software.

For my packaging requirements in Fedora, it doesn't really matter, because I simply won't build the REST service if it requires a version not available. It's an optional component (as implemented), so it wouldn't affect me much to exclude it.

Shading comes with a whole host of problems, some of which I mentioned above, but also because anybody having a dependency on some POJO inside the jar is going to have a huge nightmare with additional bundled stuff.

If that's the only way to reasonable work with dropwizard, then I think we should look at alternative REST frameworks, for something that can be more easily baked in to the existing monitor packaging. Alternatively, we could do a full separation and provide that service as a separate project or contrib, which might actually help us focus on providing a standard API for metrics/stats that any monitoring tool might be able to use, rather than enriching the existing one.

On the other hand, that link you provide doesn't really explain that we need to build shaded jars... it just explains what shaded jars are and why you might want to create them. In our case, I think non-shaded is preferred. It fits better into our existing build and scripts, and doesn't come with all the problems that shaded jars have.
- Christopher
This is an automatically generated e-mail. To reply, visit:
On July 28, 2014, 12:55 p.m., Josh Elser wrote: