13 Replies Latest reply on Feb 4, 2013 8:27 PM by Tomohisa igarashi

    Review of properties support for 0.8

    Keith Babo Master

      Here's a summary of our discussion of properties support in 0.8:

      https://community.jboss.org/wiki/SwitchYardPropertiesSupport

       

      Tomo - can you review that and let me know if more detail is required?  As part of the follow-up work, you would need to:

      • Implement a property resolver for composite properties
      • Implement a property resolver for unit test properties and define a mechanism for how these are specified
      • Add implementation property support in config layer
      • Handle the plumbing for all implementations to map properties to service logic
      • Follow up with Rob and Brian on tooling support

       

      BPEL, BPMN 2, Camel, and Drools peeps : please check out the implementation properties mapping section and holler if it's wrong/incomplete.

        • 1. Re: Review of properties support for 0.8
          David Ward Master

          The current interface for org.switchyard.common.property.PropertyResolver looks like this:

           

           

          public interface PropertyResolver {

              public String resolveProperty(String key);

          }

           

           

          However, we might want it to look like this:

           

           

          public interface PropertyResolver {

              public Object resolveProperty(String key);

          }

           

           

          Or like this:

           

           

          public interface PropertyResolver<T> {

              public T resolveProperty(String key);

          }

           

           

          Just to future-proof ourselves before we get too far.  Thoughts?

          • 2. Re: Review of properties support for 0.8
            Keith Babo Master


            That's a good point.  I think this might be good for now:

             

            public interface PropertyResolver {
                public Object resolveProperty(String key);
            }
            

             

            In our code, we can just toString() all non-strings for now if we are just expecting strings.

            • 3. Re: Review of properties support for 0.8
              David Ward Master

              Or overload it...

               

              public interface PropertyResolver {     public Object resolveProperty(String key);

                  public <T> T resolveProperty(String key, Class<T> type);

              }

               

              ...althought that's not any easier than a cast. :/

              • 4. Re: Review of properties support for 0.8
                Tomohisa igarashi Master

                Thank you for those info, Keith, David!

                 

                One question - Do we expect the Composite/Component properties would be used as Environment Properties, or just to be used as Implementation Properties?

                 

                doc is already suggesting system property would be used as implementation property, so priority order is

                1. System Property
                2. Component Property
                3. Composite Property
                4. Domain Property

                ... assuming composite property overrides domain property, component property overrides composite property(SCA says explicitly), and system property overrides all these.

                 

                Then how about environment property? do we accept like this?

                 

                <composite>
                    <service name="OrderService">
                        <interface.wsdl interface="wsdl/OrderService.wsdl#wsdl.porttype(OrderService)"/>
                        <soap:binding.soap>
                            <wsdl>wsdl/OrderService.wsdl</wsdl>
                            <socketAddr>$socketAddr</socketAddr>
                        </soap:binding.soap>
                    </service>
                    <property name="socketAddr">:18001</property>
                </composite>
                

                 

                Thanks,

                Tomo

                • 5. Re: Review of properties support for 0.8
                  David Ward Master

                  I would assume this order instead, unless Keith wants otherwise:

                  1. System Property
                  2. Domain Property
                  3. Component Property
                  4. Composite Property

                  , but I might just be misunderstanding what Component and Composite Properties are.

                   

                  Specifically with regards to priority, just so you know, priority is defined by the order in which the PropertyResolvers are evaluated inside CompoundPropertyResolver (the order of which is specified in the constructor, called on line 185 inside V1SwitchYardModel.java).

                   

                  Also, FYI, Tomo, check out SWITCHYARD-1288, which I just issued a pull request for.

                  • 6. Re: Review of properties support for 0.8
                    Keith Babo Master

                    I'm assuming that we will implement a property resolver for every place where properties can be resolved, so this would include component and composite properties.  These resolvers need to bet set on the configuration in the order of precedence.  The same precedence order is in place for environment and implementation properties.

                     

                    Going with the precedence list in the spec is probably best, but I would amend it slightly to include test properties:

                     

                    1. System Property
                    2. Test Property
                    3. Component Property
                    4. Composite Property
                    5. Domain Property

                     

                    The test property resolver is inserted by the test kit and only applies to unit tests.

                     

                    The example in your config excerpt is ok, but it should be ${socketAddr}.

                    • 7. Re: Review of properties support for 0.8
                      David Ward Master

                      Regarding test properties.. I have an idea that would be easy.  Notice the static methods.

                       

                      public class TestPropertyResolver implements PropertyResolver {

                          public static void setProperty(String name, value) {...}

                          public static void clearProperties() {...}

                          public Object resolveProperty(String key) {...}

                          public static TestPropertyResolver instance() {return singleton;}

                      }

                       

                      public class V1SwitchYardModel ... {

                         // inside here, we use SystemPropertiesResolver.instance(), TestPropertyResolver.instance() and domain properties...

                      }

                       

                      public class MyTests {

                          @Before

                          public void before() {

                              TestPropertyResolver.setProperty("foo", "bar");

                              TestPropertyResolver.setProperty("baz", "whiz");

                          }

                          @After

                          public void after() {

                              TestPropertyResolver.clearProperties();

                          }

                          @Test

                          public void test() {

                              // any work done with configs in here will respect test properties

                          }

                      }

                      • 8. Re: Review of properties support for 0.8
                        Keith Babo Master

                        OK, I actually screwed up the order of precedence.  I've revised it below.  The main reason behind these rules is that:

                         

                        a) dynamic properties take precedence over static properties

                        b) encapsulating (i.e. higher level) properties take precedence over encapsulated properties

                         

                        This leaves us with:

                         

                        1. System Property
                        2. Test Property
                        3. Domain Property
                        4. Composite Property
                        5. Component Property

                         

                        As the order of precedence.  Keep in mind that the config layer automatically registers the system property and domain property resolvers, so you are going to have to re-order these based on the precdence above when adding other resolvers.

                        • 9. Re: Review of properties support for 0.8
                          Keith Babo Master

                          For the test support, I was thinking that the test kit could support injecting an instance variable which could be used to add properties.  The test kit already does this for things like ServiceDomain, Deployment, and a few other things.  So maybe inject a Map which is wrapped behind the scenes with a property resolver.  A related option would be to use a setter or getter for this purpose with a specific signature (e.g. getTestProperties).  One thing to consider in the approach is cleaning the map or resetting the reference between test runs.

                          • 10. Re: Review of properties support for 0.8
                            David Ward Master

                            Sounds good, Keith.

                             

                            So, just so we're on the same page:

                            1. System Property: Done
                            2. Test Property: I will do this as part of SWITCHYARD-705
                            3. Domain Property: Done
                            4. Composite Property: Tomo will do this as part of SWITCHYARD-520?
                            5. Copmonent Property: Tomo will do this as part of SWITCHYARD-520?

                             

                            Thanks.

                            • 11. Re: Review of properties support for 0.8
                              Tomohisa igarashi Master

                              OK, implemented composite/component property support in config layer and implementation property injection into Bean component.

                               

                               

                              Any comments would be appreciated!

                               

                              I'll take a look at another service component for next.

                               

                              Thanks,

                              Tomo

                              • 12. Re: Review of properties support for 0.8
                                David Ward Master
                                1. It's unfortunate that <sca:property> elements (inside <sca:composite>) aren't enclosed in an <sca:properties> element, as that would be more a uniform and "normal" grouping. Oh well.
                                2. Inside bean/src/main/java/org/switchyard/component/bean/ServiceProxyHandler.java, you do a lot of reflection code.  We have common reflection utilities to do that sort of thing.  See our org.switchyard.common.type.reflect.FieldAccess class.  You could change your code to something like line 169 here: http://goo.gl/DXXce
                                3. Looks good otherwise.
                                • 13. Re: Review of properties support for 0.8
                                  Tomohisa igarashi Master

                                  Thanks for the comment, David!

                                   

                                  1. Indeed, next version of SCA should have sca:properties wrapping IMHO if it would happen. I don't like properties are placed right under the composite/component directly.
                                  2. OK, fixed.
                                  3. getting +1 from you as a author of configuration API is important for this task  I think it succeeded to put together.