Thrift
  1. Thrift
  2. THRIFT-814

Include a TServlet in the standard Thrift distribution

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.1, 0.2, 0.3
    • Fix Version/s: 0.4
    • Component/s: Java - Library
    • Labels:
      None
    • Environment:

      Any

      Description

      Thrift comes with a THttpClient used to consume Thrift services over an HTTP transport.

      Thrift however does not come with a Thrift specific servlet to serve those services.

      Tom White's servlet (http://www.lexemetech.com/2007/09/java-servlet-for-thrift.html, http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#vusEaWnOsAk/thrift/TServlet.java&q=TServlet) is probably in wide use but it would be great to have a standard Thrift servlet everyone can build upon.

      I've adapted Tom's Servlet to allow for Processor/Protocol parameterization.

      I've not cleared the licensing issues though, as Tom's original work has no license associated with it.

      1. TServlet.java
        4 kB
        Mathias Herberts
      2. TServlet.java-v2
        3 kB
        Mathias Herberts

        Activity

        Hide
        Mathias Herberts added a comment -

        Licensing has yet to be cleared out as my version of TServlet.java builds upon Tom White's version.

        Show
        Mathias Herberts added a comment - Licensing has yet to be cleared out as my version of TServlet.java builds upon Tom White's version.
        Hide
        Tom White added a comment -

        I grant a license to the ASF for the original work for inclusion in ASF works.

        Show
        Tom White added a comment - I grant a license to the ASF for the original work for inclusion in ASF works.
        Hide
        Bryan Duxbury added a comment -

        Some thoughts:

        • Why have the input and output transport factories at all if they're going to be private final default factories? You know that all it does is return the same transport you passed in, so it's basically a no-op.
        • Do you actually want to close the input and output transports? Won't the webserver do that for you on its own terms?
        • Why use a Collection of Map.Entry objects? Isn't that what we call a Map?
        Show
        Bryan Duxbury added a comment - Some thoughts: Why have the input and output transport factories at all if they're going to be private final default factories? You know that all it does is return the same transport you passed in, so it's basically a no-op. Do you actually want to close the input and output transports? Won't the webserver do that for you on its own terms? Why use a Collection of Map.Entry objects? Isn't that what we call a Map?
        Hide
        Mathias Herberts added a comment -

        I removed the input/output transport factories, they were leftovers of the initial code I based this one on.

        I also removed the finally clause which closed the transports, you are right the servlet container will take care of this (or not if keepalive was requested).

        For your last point, I'm using a Collection of Map.Entry objects so I can have several times the same header. This would not be possible using a Map.

        I'm attaching an updated version.

        Show
        Mathias Herberts added a comment - I removed the input/output transport factories, they were leftovers of the initial code I based this one on. I also removed the finally clause which closed the transports, you are right the servlet container will take care of this (or not if keepalive was requested). For your last point, I'm using a Collection of Map.Entry objects so I can have several times the same header. This would not be possible using a Map. I'm attaching an updated version.
        Hide
        Bryan Duxbury added a comment -

        For your last point, I'm using a Collection of Map.Entry objects so I can have several times the same header. This would not be possible using a Map.

        Typically I'd use a Map<X, List<Y>> for that purpose.

        Show
        Bryan Duxbury added a comment - For your last point, I'm using a Collection of Map.Entry objects so I can have several times the same header. This would not be possible using a Map. Typically I'd use a Map<X, List<Y>> for that purpose.
        Hide
        Mathias Herberts added a comment -

        Using Map<X, List<Y>> implies you need code to convert from a Map<X,Y> (in case you don't need several header values for a given name), whereas generating a Collection<Map.Entry<X,Y>> is straightforward using entrySet from java.util.Map.

        Show
        Mathias Herberts added a comment - Using Map<X, List<Y>> implies you need code to convert from a Map<X,Y> (in case you don't need several header values for a given name), whereas generating a Collection<Map.Entry<X,Y>> is straightforward using entrySet from java.util.Map.
        Hide
        Bryan Duxbury added a comment -

        OK, I committed this.

        Show
        Bryan Duxbury added a comment - OK, I committed this.

          People

          • Assignee:
            Mathias Herberts
            Reporter:
            Mathias Herberts
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development