Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-2437

Improve isolation of ResteasyProviderFactory instances belonging to different applications

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Unresolved
    • Major
    • None
    • None
    • None
    • None

    Description

      ResteasyProviderFactory uses a singleton for storing its default instance, likely as a consequence of JAX-RS RuntimeDelegate relying on a similar approach.
      On server side, when the "deployment sensitive factory" option is enabled, the ThreadLocalResteasyProviderFactory implementation is used to differenciate the instance serving each deployment, but still, that can lead to a clash when a thread pool is in place.
      ResteasyProviderFactory.getInstance() is invoked in multiple places in the code, on client side that's used as a trick for getting the instance for the server in which the client is running (in case of in-container clients).
      I believe we should bind the application ResteasyProviderFactory instance to the application classloader, by assuming that's normally set as thread context classloader. The singleton should only be treated as fallback.

      Attachments

        Issue Links

          Activity

            People

              jperkins-rhn James Perkins
              rhn-support-asoldano Alessio Soldano
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: