accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ctubbsii <...@git.apache.org>
Subject [GitHub] accumulo pull request #194: ACCUMULO-3005 Added REST API calls
Date Fri, 23 Dec 2016 18:16:24 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message