[jira] Reopened: (ODE-295) Integration-Layer configuration

["Alexis Midon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ODE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexis Midon reopened ODE-295:
------------------------------


After discussion about this, we agreed on the following:

    * EPRs implementation knowledge belongs to the messaging part of the IL, the deployment part should only have to deal with the EndpointReference interface and its representation as a configuration key.

    * we should have a better abstraction than a String[] (that assumes ordering and such) as representation of the characteristics of an EPR for configuration lookup.

So in the code we would have to modify:

    * EndpointReferenceContext to add a getConfigLookup(EndpointReference) method that would return a Map (and in the case of the Axis2 IL it would return something like {'service'=>'foo', 'port'=>'bar', 'url'=>'baz'}).

    * Have the 2 methods named getProcessProperties() (instead of getDeploymentProperties) and getEndpointProperties(EndpointReference) (instead of getProperties(String...)).

    * Set a reference to EndpointReferenceContext in the process store so that it can pass it the ProcessConfImpl instances. ProcessConfImpl.getEndpointProperties would then call EndpointReferenceContext.getConfigLookup(epr) to get the names it should use for the configuration lookup. Once these names are obtained, the implementation is going to be roughly the same.

We discussed a bit about how to handle namespaces and urls and thought the prettiest would probably be aliasing them. So you would have a set of alias at the beginning of the property file, like:

alias.foo=http://foo.com

> Integration-Layer configuration
> -------------------------------
>
>                 Key: ODE-295
>                 URL: https://issues.apache.org/jira/browse/ODE-295
>             Project: ODE
>          Issue Type: New Feature
>          Components: BPEL Runtime
>            Reporter: Alexis Midon
>            Assignee: Matthieu Riou
>             Fix For: 1.2
>
>         Attachments: ODE-295_patch#1.txt, ODE-295_trunk_patch#1.txt
>
>
> *Abstract:*
> Add support for external services configuration at runtime.
> Some settings (like timeout, proxy, headers etc) may have to be defined dynamically and on a service-basis.
> This could be done with a property file (per deployment unit).
> *Details:*
> This issue adds a mechanism to pass properties from the ProcessConf to the Integration Layer, and leverages it to configure external services.
> The ProcessConf interface has a method Map<String, String> getProperties(String...).
> This method is meant to expose properties to the Integration Layer. These properties have to be specific to the process configuration. It's the implementor responsability to define what these properties are, what they are used for. The String array received as argument may be used to specify filters, criteria to get only a subset of the properties.
> Default Implementation
> The default implementation will use the first two parameters as service name and port name.
> This method is backed by a property file named integration-layer.properties. This file must be placed in the deployment unit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.