Github user ctubbsii commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/194#discussion_r93790652
--- Diff: assemble/src/main/assemblies/component.xml ---
@@ -40,15 +40,48 @@
<include>org.apache.commons:commons-math3</include>
<include>org.apache.commons:commons-vfs2</include>
<include>org.apache.thrift:libthrift</include>
+ <include>org.eclipse.jetty:jetty-continuation</include>
<include>org.eclipse.jetty:jetty-http</include>
<include>org.eclipse.jetty:jetty-io</include>
<include>org.eclipse.jetty:jetty-security</include>
<include>org.eclipse.jetty:jetty-server</include>
+ <!-- jetty-servlet only needed by old monitor -->
<include>org.eclipse.jetty:jetty-servlet</include>
<include>org.eclipse.jetty:jetty-util</include>
<include>org.apache.htrace:htrace-core</include>
<include>org.slf4j:slf4j-api</include>
<include>org.slf4j:slf4j-log4j12</include>
+ <!-- Jersey/Jackson-based webservice -->
--- End diff --
Unfortunately, I disagree with @mikewalch on this point.
I'd prefer jersey. As the JAX-RS (JSR 311 & JSR 339) reference
implementation, it's the standard for webapps, widely available in many Linux
distributions, community-established APIs, and easily ported to various
containers. While we don't absolutely *have* to stick with Jersey, using the
JAX-RS standards as closely as possible ensures we have the ability to switch
out implementations with minimal code changes, as needed. I think that there's
a compelling case to be made for sticking with standards.
Jackson is useful with Jersey for automatic generation of JSON and XML, and
provides a lot of standard providers for serialization in Java webapps. I
wouldn't want us to switch to using Gson, as that would probably require
writing a custom provider.
While I find sparkjava compelling for quickly built applications, I'm not
convinced it's the best choice for us. Keep in mind, we will probably still
have to support some of the custom servlet stuff regardless (the shell servlet
cannot be converted to a REST interface, and we're using the base servlet to
load classpath resources). I'd rather stick to the standards to start, so we
can get the work done, and then consider switching frameworks later, after
we've stripped out all the servlet clutter.
If your concern is about bundling, we could stop bundling in the tarball.
But, a few extra jars, especially ones that are relatively small and standard,
isn't really a big deal, in my opinion.
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
