The current contents of the 'integration' folder are based on the service validator mechanism in Savara1. The service validator mechanism will change in Savara2, but the overall structure may still be relevant - i.e. jboss relevant modules, then modules for the specific technologies in jboss (esb, jbossws, etc).
However not sure whether things like database configuration could be more independent of the particular target platform?
In terms of the properties themselves, the idea behind the Configuration interface passed to the session store is that, although all of the main components are OSGi bundles, I didn't want them to be dependent upon OSGi. So didn't want properties to be retrieved from the OSGi configuration service.
However using a specific interface enables an appropriate implementation to be used, even in an OSGi container, where possibly the implementation will wrap usage of the OSGi configuration service.
Within JBoss we need to consider the way in which the components are going to be instantiated - and this may be dependent upon which version of AS we are targetting, as AS7 is effectively an OSGi container, but AS6 also supports some OSGi capabilities.
So for testing purposes, I think we just need a Configuration implementation that loads properties from a predefined properties file.
Not there yet, but just to provide an update.
There is now a org.savara.common.config.file bundle with a FileConfiguration implementation. This obtains the properties from a 'savara.properties' file.
I tried installing this bundle in JBoss AS7 (with its dependencies), but was unable to get the bundle to locate the properties file from anywhere in the container - so currently only loads from the property file contained within the bundle itself. One approach (if this remains the case) would be to provide a way to reconstruct the bundle with any changed properties.
One of the issues with integration in AS6 or 7 will be how non OSGi components will integrate with OSGi bundles - need further investigation into this.
May be better to package all of the bundles into a single 'jboss as' component and provide the configuration, data sources etc in a JEE deployment unit, rather than relying on OSGi in the app server.