Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.4.0
    • Component/s: None
    • Labels:
      None

      Description

      org.jvnet.hk2.guice.bridge.test.bidirectional.BiDirectionalBridgeTest tests basic Guice injection but it fails to take Guice-Servlet into consideration.

      Please add a unit test for a bi-directional HK2 <--> Guice Servlet bridge.

        Issue Links

          Activity

          Hide
          cowwoc added a comment -

          Guys, the problem is no longer when/how to initialize the GuiceBridge. The problem is that it is technically impossible for GuiceBridge to work unless Guice adds new functionality (more on this below).

          There are only two possible solutions I am aware of:

          1. Guice needs to add functionality to make GuiceBridge work: https://code.google.com/p/google-guice/issues/detail?id=778 (or...)
          2. Jersey needs to become DI agnostic (allowing us to replace HK2 with Guice): JERSEY-1950

          If you want this issue resolved, please voice your support on the Guice and Jersey mailing list and star the relevant issues.

          Show
          cowwoc added a comment - Guys, the problem is no longer when/how to initialize the GuiceBridge. The problem is that it is technically impossible for GuiceBridge to work unless Guice adds new functionality (more on this below). There are only two possible solutions I am aware of: Guice needs to add functionality to make GuiceBridge work: https://code.google.com/p/google-guice/issues/detail?id=778 (or...) Jersey needs to become DI agnostic (allowing us to replace HK2 with Guice): JERSEY-1950 If you want this issue resolved, please voice your support on the Guice and Jersey mailing list and star the relevant issues.
          Hide
          Dreamershl added a comment -

          to Jwells, it is my pleasure. Please go ahead.

          Show
          Dreamershl added a comment - to Jwells, it is my pleasure. Please go ahead.
          Hide
          jontro added a comment -

          Cowwoc, agreed.
          Im running into new issues all the time.
          Binding issues should be fail fast, not runtime aware.
          Custom type listeners do not seem to work etc.

          Show
          jontro added a comment - Cowwoc, agreed. Im running into new issues all the time. Binding issues should be fail fast, not runtime aware. Custom type listeners do not seem to work etc.
          Hide
          cowwoc added a comment -

          (I'm posting this discussion on the HK2 issue tracker first. If it makes sense, we'll move discussion to the Jersey issue tracker)

          I've recently moved away from Dependency Injection towards https://bitbucket.org/cowwoc/servicelocator/wiki/Home

          I'm not necessarily advocating you do the same (although...) but this change of perspective gave me some ideas:

          Guice cannot delegate to another framework for failed bindings, and the Jersey team refuses to provide the building blocks for creating such bindings. But... what about implementing a Guice Provider on top of HK2's ServiceLocator for each Jersey type (e.g. UriInfo) and bind it like Guice expects?

          Meaning:

          1. Configure HK2 to inject Jersey types. Don't try making it inject Guice types.
          2. Create one Provider per Jersey-type, built on top of a HK2 ServiceLocator which is passed into the Module.
          3. At runtime, get your hands on an HK2 ServiceLocator, use it to create a Guice Injector then add a binding to HK2 which delegates to this injector for unknown types.

          The beauty of this approach is that it would work for any DI framework, including https://bitbucket.org/cowwoc/servicelocator/wiki/Home

          This story isn't complete for two reasons:

          1. Can we add an HK2 binding for unknown types after the HK2 ServiceLocator is already instantiated? I think so, but we'd need to double check.
          2. We need to figure out whether GuiceFilter is still needed injecting resources (I suspect it is), or whether we can find a replacement. If we need GuiceFilter then the Jersey team needs to let us pass in a ServiceLocator into the ResourceConfig constructor instead of having ResourceConfig construct its own instance.
          Show
          cowwoc added a comment - (I'm posting this discussion on the HK2 issue tracker first. If it makes sense, we'll move discussion to the Jersey issue tracker) I've recently moved away from Dependency Injection towards https://bitbucket.org/cowwoc/servicelocator/wiki/Home I'm not necessarily advocating you do the same (although...) but this change of perspective gave me some ideas: Guice cannot delegate to another framework for failed bindings, and the Jersey team refuses to provide the building blocks for creating such bindings. But... what about implementing a Guice Provider on top of HK2's ServiceLocator for each Jersey type (e.g. UriInfo ) and bind it like Guice expects? Meaning: Configure HK2 to inject Jersey types. Don't try making it inject Guice types. Create one Provider per Jersey-type, built on top of a HK2 ServiceLocator which is passed into the Module . At runtime, get your hands on an HK2 ServiceLocator , use it to create a Guice Injector then add a binding to HK2 which delegates to this injector for unknown types. The beauty of this approach is that it would work for any DI framework, including https://bitbucket.org/cowwoc/servicelocator/wiki/Home This story isn't complete for two reasons: Can we add an HK2 binding for unknown types after the HK2 ServiceLocator is already instantiated? I think so, but we'd need to double check. We need to figure out whether GuiceFilter is still needed injecting resources (I suspect it is), or whether we can find a replacement. If we need GuiceFilter then the Jersey team needs to let us pass in a ServiceLocator into the ResourceConfig constructor instead of having ResourceConfig construct its own instance.
          Hide
          cowwoc added a comment -

          It took me a while, but I can finally provide you with some answers.

          1. Yes, you can add bindings to ServiceLocator after its already instantiated.
          2. I haven't tried implementing this with GuiceFilter but I don't think you need it. If you use ServletContainer, injection will pass from Jersey to HK2 to Guice, which is just fine.

          Here is how I got this to work for my own IoC framework: https://bitbucket.org/cowwoc/pouch-jersey2/wiki/Home

          I believe the following steps will work for Guice:

          1. Inject ServiceLocator into the Jersey application. Notice that HK2's ServiceLocator must be instantiated before Guice's Injector.
          2. Create a new Guice injector, passing in a Module that takes the ServiceLocator as argument.
          3. The Module should bind each Jersey type to a Provider that delegates to ServiceLocator for injection. So for example, when you invoke Injector.getInstance(UriInfo.class) this should bind to a Provider that invokes serviceLocator.getService(UriInfo.class).
          4. GuiceBridge.getGuiceBridge().initializeGuiceBridge(serviceLocator) will take care of the opposite direction, instructing HK2 to delegate to Guice on unknown types.

          The main reason I haven't translated these instructions into code is that I have moved from from Guice to Pouch: https://bitbucket.org/cowwoc/pouch/

          Please let me know if anyone picks this up and converts it into a library.

          Show
          cowwoc added a comment - It took me a while, but I can finally provide you with some answers. Yes, you can add bindings to ServiceLocator after its already instantiated. I haven't tried implementing this with GuiceFilter but I don't think you need it. If you use ServletContainer , injection will pass from Jersey to HK2 to Guice, which is just fine. Here is how I got this to work for my own IoC framework: https://bitbucket.org/cowwoc/pouch-jersey2/wiki/Home I believe the following steps will work for Guice: Inject ServiceLocator into the Jersey application. Notice that HK2's ServiceLocator must be instantiated before Guice's Injector . Create a new Guice injector, passing in a Module that takes the ServiceLocator as argument. The Module should bind each Jersey type to a Provider that delegates to ServiceLocator for injection. So for example, when you invoke Injector.getInstance(UriInfo.class) this should bind to a Provider that invokes serviceLocator.getService(UriInfo.class) . GuiceBridge.getGuiceBridge().initializeGuiceBridge(serviceLocator) will take care of the opposite direction, instructing HK2 to delegate to Guice on unknown types. The main reason I haven't translated these instructions into code is that I have moved from from Guice to Pouch: https://bitbucket.org/cowwoc/pouch/ Please let me know if anyone picks this up and converts it into a library.

            People

            • Assignee:
              jwells
              Reporter:
              cowwoc
            • Votes:
              23 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated: