Spring Framework
  1. Spring Framework
  2. SPR-8799

@Qualifier to support expressions like @Value

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as Designed
    • Affects Version/s: 3.0.5
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      It may be useful to support expressions in the @Qualifier annotation as they are in the @Value annotation.

        Activity

        Hide
        Sandro Ruch added a comment -

        Chris,
        I understand your point... but see, check the situation where you have multiple versions of an service endoint (say xml over http what we have) and you have to work with those versions in parallel... in that case it would be nice you can configure per teneant the version you work with in each environment. As I understand the spring profiles the main use case is the support of different environment (DEV, QUAL, TEST, PROD, etc.). Thats fine as long there is no other differentiation. But there will be tenants, versions of classes / endpoints, etc... and thats where I see the use cases for @Qualifier and the support of expressions... I think one should not mix the context (the intension) of the profiles per application... say one is the environment the other is tenants or version...

        I am not looking for hypothetical use case but in reality there are quite a plenty for...

        Cheers,
        Sandro

        Show
        Sandro Ruch added a comment - Chris, I understand your point... but see, check the situation where you have multiple versions of an service endoint (say xml over http what we have) and you have to work with those versions in parallel... in that case it would be nice you can configure per teneant the version you work with in each environment. As I understand the spring profiles the main use case is the support of different environment (DEV, QUAL, TEST, PROD, etc.). Thats fine as long there is no other differentiation. But there will be tenants, versions of classes / endpoints, etc... and thats where I see the use cases for @Qualifier and the support of expressions... I think one should not mix the context (the intension) of the profiles per application... say one is the environment the other is tenants or version... I am not looking for hypothetical use case but in reality there are quite a plenty for... Cheers, Sandro
        Hide
        Chris Beams added a comment - - edited

        Hi Sandro,

        When you say 'multi-tenant' in this context, I hear "multiple logical customer applications running within the same Spring ApplicationContext". We can hold aside different deployment environments, as it sounds like this is an orthogonal concern for you.

        Given that there is only one ApplicationContext, there will only be one opportunity to replace $

        {...} tokens in @Value annotations, or in @Qualifier annotations. Therefore, you're not going to achieve any kind of magical per-tenant wiring. ${...}

        replacement happens once and once only for all components within a given application context.

        If you like, feel free to provide a detailed use case here, use the

        { code }

        macro to propose a set of classes / interfaces / injection points and @Qualifier annotation with $

        {...}

        tokens that get replaced from properties files using PropertyPlaceholderConfigurer.

        I have a feeling that we'll find that the use case is simply outside the design of @Qualifier, but I'll happily stand corrected if you can prove otherwise. At this point, however, we need something concrete to discuss.

        Show
        Chris Beams added a comment - - edited Hi Sandro, When you say 'multi-tenant' in this context, I hear "multiple logical customer applications running within the same Spring ApplicationContext". We can hold aside different deployment environments, as it sounds like this is an orthogonal concern for you. Given that there is only one ApplicationContext, there will only be one opportunity to replace $ {...} tokens in @Value annotations, or in @Qualifier annotations. Therefore, you're not going to achieve any kind of magical per-tenant wiring. ${...} replacement happens once and once only for all components within a given application context. If you like, feel free to provide a detailed use case here, use the { code } macro to propose a set of classes / interfaces / injection points and @Qualifier annotation with $ {...} tokens that get replaced from properties files using PropertyPlaceholderConfigurer. I have a feeling that we'll find that the use case is simply outside the design of @Qualifier, but I'll happily stand corrected if you can prove otherwise. At this point, however, we need something concrete to discuss.
        Hide
        Sandro Ruch added a comment -

        Chris,
        Not exactly... The same application (version) runs in different environments for different tenants. So the @Value and the @Qualifier can be evaluated for each tenant independently. So the question remains whether to use multiple profile type for multiple purposes... In my opinion the profiles should be used for semantically one purpose (eg. different environment)... that is of course discussible...

        Sandro

        Show
        Sandro Ruch added a comment - Chris, Not exactly... The same application (version) runs in different environments for different tenants. So the @Value and the @Qualifier can be evaluated for each tenant independently. So the question remains whether to use multiple profile type for multiple purposes... In my opinion the profiles should be used for semantically one purpose (eg. different environment)... that is of course discussible... Sandro
        Hide
        Chris Beams added a comment -

        The profile mechanism is expressly designed to be general-purpose. We often discuss it in terms of aiding teams in distinguishing between dev/test/prod environments simply because this is a universally understood use case. You should be able to combine orthogonal sets of profiles (e.g. a set of profiles for deployment environments and a set of profiles for different customers) without too much trouble. Let us know how it goes if you go that route, thanks.

        Show
        Chris Beams added a comment - The profile mechanism is expressly designed to be general-purpose. We often discuss it in terms of aiding teams in distinguishing between dev/test/prod environments simply because this is a universally understood use case. You should be able to combine orthogonal sets of profiles (e.g. a set of profiles for deployment environments and a set of profiles for different customers) without too much trouble. Let us know how it goes if you go that route, thanks.
        Hide
        Eugen Paraschiv added a comment -

        This would be another usecase that may support the introduction of this kind of support:
        http://forum.springsource.org/showthread.php?131617-Support-for-expressions-in-ActiveProfiles-annotation&p=429322#post429322
        Thanks.
        Eugen.

        Show
        Eugen Paraschiv added a comment - This would be another usecase that may support the introduction of this kind of support: http://forum.springsource.org/showthread.php?131617-Support-for-expressions-in-ActiveProfiles-annotation&p=429322#post429322 Thanks. Eugen.

          People

          • Assignee:
            Chris Beams
            Reporter:
            Sandro Ruch
            Last updater:
            Eugen Paraschiv
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 18 weeks, 4 days ago