[
https://issues.apache.org/jira/browse/KARAF-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Barthel updated KARAF-2420:
-------------------------------
Description:
*Preparation*
1) Start clean Karaf instance
2) Install Aries JNDI and HSQLDB via:
{code}
karaf@root> bundle:install -s mvn:org.hsqldb/hsqldb
karaf@root> feature:install jndi
{code}
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 and the KAR deployer don't redeploying it. The
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 but the JNDI lookup starts after deregistering
the service from JNDI.
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) ???
was:
*Preparation*
1) Start clean Karaf instance
2) Install Aries JNDI and HSQLDB via:
{code}
karaf@root> bundle:install -s mvn:org.hsqldb/hsqldb
karaf@root> feature:install jndi
{code}
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.sqlDatasource}} 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 and the KAR deployer don't redeploying it. The
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 but the JNDI lookup starts after deregistering
the service from JNDI.
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) ???
> blueprint deployer: redeploy untouched blueprint xml in deploy folder after
> restart
> -----------------------------------------------------------------------------------
>
> Key: KARAF-2420
> URL: https://issues.apache.org/jira/browse/KARAF-2420
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
> Affects Versions: 2.2.8, 2.2.11
> Environment: Karaf 2.2.11
> JNDI feature installed
> HSQLDB 2.3.0
> Reporter: Uwe Barthel
> Fix For: 2.2.12
>
> Attachments: datasource.xml
>
>
> *Preparation*
> 1) Start clean Karaf instance
> 2) Install Aries JNDI and HSQLDB via:
> {code}
> karaf@root> bundle:install -s mvn:org.hsqldb/hsqldb
> karaf@root> feature:install jndi
> {code}
> 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 and the KAR deployer don't redeploying
> it. The 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 but the JNDI lookup starts after
> deregistering the service from JNDI.
> 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) ???
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
