Pax ConfMan

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.

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 0.2.2
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Gentoo linux, java 1.5

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.

Activity

Hide
Permalink
Niclas Hedhman added a comment -

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

Show
Niclas Hedhman added a comment - 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...

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: