But the problem is that the behavior of the configuration admin depends on which bundles calls the createFactoryConfiguration(...) method and this makes debugging hard.
The problem was that when I create the first time a factory configuration via my remote bundle (which is running on the same system local in other OSGi framework), I become a exception. The remote bundle invokes the method "createWall(…)" see the code sample:
When the first caller of this method was the remote bundle I become the following exception (when the second caller of the configuration admin is a local bundle got the same exception, e.g. when a configuration is created via the apache webconsole):
When the same logic is called first time from a local bundle everything works fine. After some time of debugging, I found the issue. The point is not that the bundle is local or remote.
In the implementation of the method "createWall(...)" the Configuration Admin method "createFactoryConfiguration(...)" with location null is used. The JavaDoc of this method says, when this method is called the first time, with location null, then the location of the first bundle is used which register a service.
OSGi Compendium Specification JavaDoc for the createFactoryConfiguration says:
"The Configuration is bound to the location specified. If this location is null it will be bound to the location of the first bundle that registers a Managed Service Factory with a corresponding PID."
In my case the first bundle was sometimes indirect the remote bundle. So I have the problem and become the exception. My fix was to set the location to the bundle location of the bundle which creates the wall configuration, see the code sample:
In end I found out, that the two OSGi frameworks has the same configuration area, the same local directory. Provider an host are running on the same system. It was a coincidence that the fix work. If the PID for the configuration folder was not locked by the other OSGi instance everything works. So in the end I must say it is my mistake because the OSGi instances had the same directory configured as configuration area. But the design that the location depends on the first caller makes debugging crazy. Does anybody know if this is the expected behavior? This is really hard to debug, that the directory where the configuration is stored could depend on the first caller. What is the best practice set the location parameter always?
