Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.14, 2.0-m08
    • Fix Version/s: 2.0-rc2, 2.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      Grizzly 2.2.18

      Description

      A slightly modified version of JERSEY-1411, but fails in a different way. Please, see attachment.

      Following resource, deployed to /hello1/hello2. Request to /hello1/hello2/anotherHello returns 404. If deployed to /hello, request to /hello/anotherHello works as expected.

      HTTP/1.1 404 Not Found
      Server: grizzly/2.2.18
      Date: Fri, 21 Sep 2012 12:45:05 GMT
      Content-Length: 0
      
      @Path("")
      @Singleton
      public class HelloWorldResource {
      
      	@GET
      	@Path("anotherHello")
      	@Produces(MediaType.TEXT_PLAIN)
      	public String anotherHello() {
      		return "anotherHello";
      	}
      }
      
      1. sample3.tar.gz
        2 kB
        Mikhail Mazursky

        Issue Links

          Activity

          Hide
          Martin Matula added a comment -

          I noticed a similar issue with Jersey 2.0 milestone builds in the past as well - seems when you use multiple path segments in the context path when deploying on grizzly it does not work for some reason. Pavel, please investigate.

          Show
          Martin Matula added a comment - I noticed a similar issue with Jersey 2.0 milestone builds in the past as well - seems when you use multiple path segments in the context path when deploying on grizzly it does not work for some reason. Pavel, please investigate.
          Hide
          Marek Potociar added a comment -

          Moving to 2.0 unplanned (issues that should be fixed in the current sprint but which were not planned for the sprint), but with a lower priority.

          Show
          Marek Potociar added a comment - Moving to 2.0 unplanned (issues that should be fixed in the current sprint but which were not planned for the sprint), but with a lower priority.
          Hide
          Pavel Bucek added a comment -

          looks like a issue in Grizzly container, filed http://java.net/jira/browse/GRIZZLY-1481

          Show
          Pavel Bucek added a comment - looks like a issue in Grizzly container, filed http://java.net/jira/browse/GRIZZLY-1481
          Hide
          Pavel Bucek added a comment -

          quick update.

          when you are deploying/starting Grizzly container, you can specify full URI, BUT only first path segment is considered to be context path (which is most likely correct, seems like this is aligned with servlet specification document).

          the other part of this issue is how is this state handled, I guess we need to at least describe what will happen when GrizzlyHttpServerFactory.createHttpServer(URI [,...]) is invoked.

          Show
          Pavel Bucek added a comment - quick update. when you are deploying/starting Grizzly container, you can specify full URI, BUT only first path segment is considered to be context path (which is most likely correct, seems like this is aligned with servlet specification document). the other part of this issue is how is this state handled, I guess we need to at least describe what will happen when GrizzlyHttpServerFactory.createHttpServer(URI [,...] ) is invoked.
          Hide
          Pavel Bucek added a comment -

          updated container factory javadoc.

          only first path segment is considered as context path, rest is ignored.

          Show
          Pavel Bucek added a comment - updated container factory javadoc. only first path segment is considered as context path, rest is ignored.
          Hide
          Mikhail Mazursky added a comment -

          Will a warning with descripion of the issue be logged in that case?

          Show
          Mikhail Mazursky added a comment - Will a warning with descripion of the issue be logged in that case?
          Hide
          Pavel Bucek added a comment -

          no.

          problem with this would be that we don't anyhow detect this case - this is just standard grizzly behavior, which may change in the future (see linked Grizzly issue) and then we should be able to remove this limitation. So, to produce this warning, we would need to parse path from given uri..

          Show
          Pavel Bucek added a comment - no. problem with this would be that we don't anyhow detect this case - this is just standard grizzly behavior, which may change in the future (see linked Grizzly issue) and then we should be able to remove this limitation. So, to produce this warning, we would need to parse path from given uri..

            People

            • Assignee:
              Pavel Bucek
              Reporter:
              Mikhail Mazursky
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 3 hours
                3h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours Time Not Required
                2h