jersey
  1. jersey
  2. JERSEY-517

Replace Jersey's dependency injection (DI) code with an @Inject-based framework

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.5
    • Fix Version/s: 2.0-m10, 2.0
    • Component/s: core
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      517

      Description

      As discussed on the mailing list thread "Appeal to jersey developers for
      better+reliable javax.inject/cdi/weld support", jersey's own legacy dependency
      manager is becomming a big problem. Jersey's own dependency injector was
      originally a good feature but now is highly problematic.

      What changed the situation? Well now we have javax.inject and CDI in the Java 6
      standard + many good implementations in spring, weld, guice etc. Developers
      using new Java 6 SE/EE technology is or will be using other dependency injection
      managers and it is a PAIN to get it to interoperate with jersey.

      The situation now is that we have a "feature" that is hard to maintain and a
      stone around the neck for java users that use JEE6 or guice/spring/weld/etc.
      Normally, I do not recommend removing features but for a feature that subtracts
      value for everybody and is costly to maintain I would say get rid of it as soon
      as possible.

      Hence, It would be much better if Jersey's own legacy dependency manager would
      be completely removed and for Jersey just to ride on top of any standard
      javax.inject and/or CDI implementation. This would give great benefits for both
      users of jersey and jersey developers.

      As for compatibility, the biggest problem with java is the unwillingness to
      cleanup things because of a 100% mindset on "backwards compatibility" that
      overcomplicates Java. If users want the old api then they should not upgrade
      their jersey libs. However, if you insist on some compatibility you could for
      example introduce a annotation processor that would convert existing source code
      at runtime to use standard annotations ? But maybe a clean cut would be much
      better for everybody ?

        Activity

        Hide
        sandoz added a comment -

        Jersey's DI code implements the JAX-RS 1.1 programming model.

        But still i would like to rip it out and replace it with an @Inject framework
        (and also use that framework internally within the Jersey implementation).

        However, it may still require some Jersey-specific support for the cases where
        the @Inject framework limits the JAX-RS 1.1 programming model.

        This is a big issue that if implemented will result in a major re-write of
        certain areas, introduce new dependencies, and potentially affect existing
        Jersey developers who use a chosen DI framework with Jersey.

        I would like see such work happen in conjunction with any JAX-RS 2.0 effort.

        Show
        sandoz added a comment - Jersey's DI code implements the JAX-RS 1.1 programming model. But still i would like to rip it out and replace it with an @Inject framework (and also use that framework internally within the Jersey implementation). However, it may still require some Jersey-specific support for the cases where the @Inject framework limits the JAX-RS 1.1 programming model. This is a big issue that if implemented will result in a major re-write of certain areas, introduce new dependencies, and potentially affect existing Jersey developers who use a chosen DI framework with Jersey. I would like see such work happen in conjunction with any JAX-RS 2.0 effort.
        Hide
        mmc41 added a comment -

        You write that this "will result in a major re-write of certain areas". That
        sounds costly?

        Is it not more accurate to say that the change "will result in a major code
        deletion/cleaning + small relatively small new additions to support pluggable
        dependency injection managers".

        I would guess that on the long run, that besides being of great benefit to
        users, this would save the jersey project man hours since you would not have to
        maintain a lot of legacy code.

        Show
        mmc41 added a comment - You write that this "will result in a major re-write of certain areas". That sounds costly? Is it not more accurate to say that the change "will result in a major code deletion/cleaning + small relatively small new additions to support pluggable dependency injection managers". I would guess that on the long run, that besides being of great benefit to users, this would save the jersey project man hours since you would not have to maintain a lot of legacy code.
        Hide
        sandoz added a comment -

        It is costly however you categorize it, which is why it might be best to
        associate this with any JAX-RS 2.0 development work. Not sure yet...

        It should result in a fair bit of deletion but then dependencies on deleted code
        need to change too. Jersey also uses it's DI mechanism internally in some cases.

        I agree on the good benefits you mention. This has been on my mind for a while

        Show
        sandoz added a comment - It is costly however you categorize it, which is why it might be best to associate this with any JAX-RS 2.0 development work. Not sure yet... It should result in a fair bit of deletion but then dependencies on deleted code need to change too. Jersey also uses it's DI mechanism internally in some cases. I agree on the good benefits you mention. This has been on my mind for a while
        Hide
        Jakub Podlesak added a comment -

        Changing priority. This new feature will be implemented in Jersey 2.

        Show
        Jakub Podlesak added a comment - Changing priority. This new feature will be implemented in Jersey 2.
        Hide
        Pavel Bucek added a comment -

        Jersey 2 uses hk2 for DI.

        Show
        Pavel Bucek added a comment - Jersey 2 uses hk2 for DI.

          People

          • Assignee:
            Unassigned
            Reporter:
            mmc41
          • Votes:
            6 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: