[rcernich]

In addition to dynamically setting the property values, they may also be configured through system properties, which override anything in the switchyard.xml.  Just another complication.

[jeff.yuchang]

Hi Tomo,

Yes, change it directly. As I said, you put the properties in the Context class, this class is accessable from the BpelEngine. Was thinking that you can do something like following:

BpelProcess.java

    public Node getProcessProperty(QName propertyName) {

        Node value = getEngine()._contexts.containerProperties.getProperty(propertyName);

        if (value != null) {

            return value;

        }

        Map<QName, Node> properties = _pconf.getProcessProperties();

        if (properties != null) {

            return properties.get(propertyName);

        }

        return null;

    }

Here I made the 'containerProperties' name up. So in the BPELActivator class, you inject the value into containerProperties.

Regards

Jeff

[objectiser]

Hi Tomo

Have just added the ability to supply the BPEL process name (QName) as the first parameter to the custom XPath function, to provide some context to the method.

Not sure if its possible, but if you can obtain a static reference to the switchyard runtime, then could you access the app containing the supplied process name, as a way to obtain the config?

Regards

Gary

[dward]

Just to re-iterate, we will not be providing a way to "get all properties" from various sources, and copy them someplace.  We only provide a way to resolve a property by name. So we can't "put the properties in the Context class", but maybe we can "put a PropertyResolver in the Context class", and use it from there?

[igarashitm]

@David, @Jeff,

Yep, so "containerProperties" should be able to invoke PropertyResolver.resolveProperty(). I think that means riftsaw-ode should depend on SwitchYard PropertyResolver *OR* have a generic pluggable point in the "Contexts". We can't choose former as we talked above. I don't have any good idea for latter right now by design of riftsaw-ode.

@Gary,

We're eventually going to bundle like this with BPEL component, and then BPELActivator.activateService() or BPELExchangeHandler would put each PropertyResolver via SwitchYardPropertyResolverXPathFunction.setPropertyResolver() . Is that reasonable for us?

https://gist.github.com/igarashitm/4945785

Thanks,

Tomo

[dward]

I think that means riftsaw-ode should depend on SwitchYard PropertyResolver *OR* have a generic pluggable point in the "Contexts". We can't choose former as we talked above. I don't have any good idea for latter right now by design of riftsaw-ode.

I don't believe riftsaw-ode should have a dependency on SwitchYard.  It would be better if they provided an interface we can implement, then plug in.

...or BPELExchangeHandler would put each PropertyResolver via SwitchYardPropertyResolverXPathFunction.setPropertyResolver() .

What do you mean "each PropertyResolver"? There only needs to be one, but that one can be a CompoundPropertyResolver (which can wrap multiple others).

[dward]

...or BPELExchangeHandler would put each PropertyResolver via SwitchYardPropertyResolverXPathFunction.setPropertyResolver() .

What do you mean "each PropertyResolver"? There only needs to be one, but that one can be a CompoundPropertyResolver (which can wrap multiple others).

Nevermind. I just saw your gist. You mean one PropertyResolver per process. Sorry!

[objectiser]

Hi Tomo

Yes I think this should work.

Regards

Gary

[igarashitm]

Hi Gary,

OK, that's working basically... confirmed the resolveProperty() has been invoked.

https://github.com/igarashitm/components/tree/SWITCHYARD-1306

just one trivial question - how can I pass a string literal to the custom function? single quote doesn't work expectedly as well.

Thanks,

Tomo

[igarashitm]

It works with following expression

            <bpel:copy>
                <bpel:from xmlns:fn="http://www.w3.org/2005/xpath-functions"
                           xmlns:property="java:org.switchyard.component.bpel.riftsaw.SwitchYardPropertyFunction"
                           expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0">
                    <![CDATA[concat(property:resolveProperty(fn:QName("", "Greeting")), $ReceiveSayHelloVar.parameters/tns:input)]]>
                </bpel:from>
                <bpel:to part="parameters" variable="ReplySayHelloVar">
                    <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[tns:result]]></bpel:query>
                </bpel:to>
            </bpel:copy>

hmm, verbose.

[objectiser]

Sorry Tomo - should be sorted now, to allow single quoted string literals. Riftsaw artifacts have been deployed to nexus, so should be available during next switchyard build.

Regards

Gary

[igarashitm]

Now it works with single quoted string literal! I didn't think it would be supported. Thanks a lot for your support, Gary.