Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-7507

Let GuiceParameterResolver support generics so that they could be used at least with ComponentProvider#newInstance

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Done
    • Neutral
    • 6.1
    • None
    • None
    • None
    • Foundation 11

    Description

      Guice by design is pretty picky/complicated when it comes to generics. In order to let it inject generics, TypeLiteral workarounds have to be applied and we do not support that in our XML-based IoC configuration. Effectively, we only map the raw types regardless of the generic signature (whatever Class#forName produces while XML is read).

      However, we can use the latter fact to our own benefit: when we create an instance of a type with ComponentProvider#newInstance(args) and some args are to be handled with Guice param resolver (i.e. - injected), we can detect that some of them are generic and then "downgrade" the Guice key resolution to raw type only (will work cause that's how we map them).

      This allows e.g. UI framework to keep certain interfaces generic and yet injectable.

      The only valid question in this situation - how do we eventually get the correctly parameterised instances? There could several soultions that come to my mind and probably cover the most of the potential use cases. Most common one - we need to inject some generic singleton/instance/definition, which is already cached in some UI bean store and is already of a "good" type. The parameter resolver will just locate it and will implicitly make a cast. Another use case - datasource bound components (depending on the datasource definition in context - different impls are used). This case will delegate type-correctness maintenance responsibility to UI configuration.

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                apchelintcev Aleksandr Pchelintcev
                apchelintcev Aleksandr Pchelintcev
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Task DoD

                    Time Tracking

                      Estimated:
                      Original Estimate - Not Specified
                      Not Specified
                      Remaining:
                      Time Spent - 56m Remaining Estimate - 1h 34m
                      1h 34m
                      Logged:
                      Time Spent - 56m Remaining Estimate - 1h 34m
                      56m