I have an OSGi
bundle with persistence service (using hibernate
) and a fragment, which contains configuration (xml file). In bundle's activator, I'm loading the configuration using:
@Override
public void start(BundleContext ctx) {
URL url = ctx.getBundle().getResource("hibernate.cfg.xml");
SessionFactory sessionFactory = new AnnotationConfiguration().configure(url).buildSessionFactory();
}
but sometimes, the URL
is null. When I've tried to list all available URL
s (using findEntries
method), it appeared that the bundle's own ones are available always, but the fragment ones only sometimes. I'm using Felix
4.0.2, the bundle and the fragment is started at the same Felix
. auto.start level.
Fragments attach to the host at the time that the host is resolved. Normally the fragment will be attached so long as it is installed before the host resolves.
However there is always the possibility for the host to resolve without the fragment, because hosts do not depend on their fragments. Therefore ordinarily you should write your host so that it can cope with the fragment not being present -- i.e. it should not throw NPEs etc.
Since OSGi R4.3 you can introduce a dependency from the host onto its fragment using the Require-Capability
and Provide-Capability
headers. By inventing your own namespace for the dependency you can make your fragment provide it with Provide-Capability
. Then your host can require it with Require-Capability
.... now the OSGi framework will ensure that the fragment must be available before it resolves the host.
The fragment is attached to the host during the resolving process of the fragment bundle.
The host is resolved and can start successfully even if the fragment is not there; but the fragment is dependent on the host - it can be resolved and afterwards started only after it is attached to the host.
By having both bundles with the same start level, it seems that you have created race conditions for these two bundles. The framework starts resolving and starting both bundles at the same time. Sometimes it manages to start the host bundle before the resolving process of the fragment has been finished -> then the start method of the host bundle behaves as if no fragment is available.
What you can do is e.g. to give the fragment an earlier start level than that of the host bundle. The fragment should resolve and start successfully even if the host bundle is not started yet. It only needs the host bundle to be resolved.
You can also test this behavior on other OSGi frameworks - e.g. on ProSyst's mBedded Server (mBS) - I know that it is fully compliant with OSGI spec 4.2 where the above fragment resolving is specified.