Review of properties support for 0.8

[kcbabo]

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.

[dward]

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?

[kcbabo]

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.

[dward]

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. :/

[igarashitm]

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

[dward]

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.

[kcbabo]

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}.

[dward]

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

    }

}

[kcbabo]

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.

[kcbabo]

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.

[dward]

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.

[igarashitm]

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

• [core] https://github.com/igarashitm/core/tree/SWITCHYARD-520
• [component] https://github.com/igarashitm/components/tree/SWITCHYARD-520

Any comments would be appreciated!

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

Thanks,

Tomo

[dward]

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.

[igarashitm]

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.