The bundles.configuration.location path is relative to the execution dir, or absolute. No support for it being in relation to one of the osgi locations.

Description

The bundles.configuration.location path is interpreted as relative to the execution dir:

ConfigurationAdminFacade.java:

File dir = new File(configArea);
if( !dir.exists() )
{
String absolutePath = dir.getAbsolutePath();
LOGGER.error( "Configuration area [" + absolutePath + "] does not exist. Unable to load properties." );
return null;
}

This means it is taken in relation to the folder from which the current vm was started (user.dir) - or taken as an absolute path.

This makes it unsuitable for environments where the execution path is not under the control of the osgi system. For example - osgi running through a servlet bridge - where the user.dir will be for the servlet container. It also makes it impossible to write osgi config files that set this property unless you can modify them when they are deployed to include the full path to the the configuration location.

A better strategy would be to allow this path to be relative to one of the locations found in the osgi properties. For example the following properties are set when running equinox (I'm not sure about other osgi platforms):

osgi.configuration.area
osgi.install.area
osgi.instance.area
osgi.user.area

The first two seem like good candidates, the second two less so.

I'll be modifying the propsman to use the path relative to the configuration area so that it is suitable for my deployment.

Environment

Gentoo linux, java 1.5

Activity

Show:
NiclasH
August 26, 2010, 3:16 PM

Since this will impact compatibility a bit, I would advice that the implementation instead supports "properties"-expansion, so that ${system.java.home} ${system.java.user}, ${osgi.bin} and so on are supported instead...

Assignee

Alin Dreghiciu

Reporter

Lindsay Smith

Labels

None

Affects versions

Priority

Major
Configure