glassfish
  1. glassfish
  2. GLASSFISH-19079

Decouple admin ReST resources from underlying protocol layer

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b53
    • Fix Version/s: 4.0_b55
    • Component/s: rest-interface
    • Labels:
      None

      Description

      Currently there are some references to underlying protocol layer from ReST resources such as: CommandResource, CompositeResource and SessionResource. e.g., CommandResource.java is making deep assumptions about Grizzly being the network manager:

      + @Inject
      + protected Ref<Request> requestRef;

      This is done to retrieve the current Subject which is a standard interface. So, if we bind the Subject as a request scoped object into Grizzly resource configuration, we could achieve desired decoupling.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        This issue has been fixed in following two svn commits:

        Revisions: #55983
        -----------------
        This involves abstracting out the Jersey container aspect by introducing an object called JerseyContainer.

        We also allow subclass to provide SubjectFactoryBinder which can retrieve the subject from appropriate
        protocol specific object.

        Ran QuickLook as well as some closed source admin tests as per recommendation of Martin Mares.

        Code reviewed by Martin Mares.

        Thanks to Jakub for providing the patch to inject Subject in CommandResource.

        Revisions: #55987
        -----------------

        This changeset involves abstracting out the ReST resource provider aspect by
        introducing an object called RestResourceProvider. Code out of RestCommandAdapter,
        RestManagementAdapter and RestMonitoringAdapter have been moved to implementations of
        RestResourceProviders called RestCommandResourceProvider, RestManagementResourceProvider
        and RestMonitoringResourceProvider respectively.

        RestAdapter uses a bridge pattern where RestResourceProvider is the delegate.

        This allows us to evolve RestAdapter independently from RestResourceProvider.

        Tests run: QuickLook and closed source tests that exercise ReST interfaces.

        Because of a bug in git/svn bridge, my comment didn't appear properly in svn.

        Show
        Sanjeeb Sahoo added a comment - This issue has been fixed in following two svn commits: Revisions: #55983 ----------------- This involves abstracting out the Jersey container aspect by introducing an object called JerseyContainer. We also allow subclass to provide SubjectFactoryBinder which can retrieve the subject from appropriate protocol specific object. Ran QuickLook as well as some closed source admin tests as per recommendation of Martin Mares. Code reviewed by Martin Mares. Thanks to Jakub for providing the patch to inject Subject in CommandResource. Revisions: #55987 ----------------- This changeset involves abstracting out the ReST resource provider aspect by introducing an object called RestResourceProvider. Code out of RestCommandAdapter, RestManagementAdapter and RestMonitoringAdapter have been moved to implementations of RestResourceProviders called RestCommandResourceProvider, RestManagementResourceProvider and RestMonitoringResourceProvider respectively. RestAdapter uses a bridge pattern where RestResourceProvider is the delegate. This allows us to evolve RestAdapter independently from RestResourceProvider. Tests run: QuickLook and closed source tests that exercise ReST interfaces. Because of a bug in git/svn bridge, my comment didn't appear properly in svn.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: