Details
Description
Preparation
1) Start clean Karaf instance
2) Install Aries JNDI and HSQLDB via:
karaf@root> bundle:install -s mvn:org.hsqldb/hsqldb karaf@root> feature:install jndi
3) Copy attached blueprint Datasource service description into deploy/ folder and check if the blueprint deployer creates a bundle (datasource.xml bundle).
4) Deploy a blueprint service bundle use Datasource internally via JNDI lookup via KAR file (consumer bundle)
5) Stop Karaf instance
6) Start Karaf
Problem
If a blueprint service bundle is installed depending on the Datasource service. This bundle may or may not start depending of the Datasource service state. It's a timing issue and difficult to reproduce with a simple test case.
The datasource.xml bundle will start up and Aries JNDI setup the InitialContext and exports the javax.sql.Datasource service.
FINE
The dependency for the Datasource service (incl. filter on the datasource name (osgi.jndi.service.name=jdbc/hsqlds)) is resolvable and the consumer bundle is starting up.
Within the #activate(...) method of the service implementation (created and exported via blueprint service on consumer bundle) the code is trying to get the Datasource reference via JNDI lookup.
BUT
At the same time the fileinstall get two file references from deploy/ folder. It is the KAR file (contains the blueprint consumer bundle) and the KAR deployer don't redeploying it if timestamp of the file was not changed. The other file is the datasource.xml file. The blueprint deployer redeploy this file.
It seems that the Datasource service reference for the consumer bundle was resolved before redeploying the datasource.xml but the JNDI lookup starts after deregistering the Datasource service from JNDI during the redeploy of the datasource.xml.
The start of the consumer bundle failed.
I tried the configuration org.apache.aries.blueprint.synchronous=true but it doesn't help either.
temp. Solution
1) Stop Karaf
2) Remove blueprint xml file from deploy/
3) Start Karaf
possible Solution
a) Create .timestamp file for blueprint service xml files and don't redeploy the xml if these files wasn't touch. Like the KAR deployer does.
b) Use bundle version with file specific content like the modification timestamp (0.0.0.20130731071830100) instead of the default bundle version (0.0.0) and check version number before reinstall the generated bundle.
c) ???
Attachments
Attachments
Issue Links
- is blocked by
-
KARAF-2906 Upgrade to fileinstall 3.4.0
-
- Resolved
-
- is related to
-
FELIX-4436 DirectoryWatcher should not refresh transformed bundles on every start-up
-
- Closed
-