Uploaded image for project: 'JBoss Web Services'
  1. JBoss Web Services
  2. JBWS-4003

[API] Add ClientConfigFeature(String configName) constructor

    • Icon: Feature Request Feature Request
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • None
    • None
    • None

      For predefined client-config settings in standalone.xml, it would be more elegant to add a new constructor in org.jboss.ws.api.configuration.ClientConfigFeature that only takes a configName and forces configureProperties=true.

         public ClientConfigFeature(String configName) {
            this(null, configName, true);
         }
      

            [JBWS-4003] [API] Add ClientConfigFeature(String configName) constructor

            r searls added a comment -

            This exists in current master version 5.3.1-SNAPSHOT

            r searls added a comment - This exists in current master version 5.3.1-SNAPSHOT

            r searls added a comment -

            This exists in current master version 5.3.1-SNAPSHOT

            r searls added a comment - This exists in current master version 5.3.1-SNAPSHOT

            AFAIR, the reason why default configureProperties = false is that in the past not all implementations of ClientConfigurer supported properties setup.
            As for adding the additional constructor in ClientConfigFeature, I'd be fine with it but doing this(null, configName, false), that is with configureProperties = false, otherwise we'd have 2 different default behaviors (and at the same time I don't want to change the constructror with 2 parameters).
            A change in default behaviour would likely need a major API release, which is not really on the radar now...

            Alessio Soldano added a comment - AFAIR, the reason why default configureProperties = false is that in the past not all implementations of ClientConfigurer supported properties setup. As for adding the additional constructor in ClientConfigFeature, I'd be fine with it but doing this(null, configName, false), that is with configureProperties = false, otherwise we'd have 2 different default behaviors (and at the same time I don't want to change the constructror with 2 parameters). A change in default behaviour would likely need a major API release, which is not really on the radar now...

            Any reason why the default configureProperties==false was chosen? The opposite seems to be the most used scenario.

            Willem Salembier (Inactive) added a comment - Any reason why the default configureProperties==false was chosen? The opposite seems to be the most used scenario.

              Unassigned Unassigned
              willem.salembier@gmail.com Willem Salembier (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: