Issue with RecursiveBundleTracker and JPA

[Alasdair Nottingham <no...@apache.org>]

Hi,

I'm hitting a problem with the RecursiveBundleTracker, the equinox
composite bundle support and JPA. The problem is a little complex, but it
involves the way a composite bundle is resolved. To resolve a composite the
framework does the following:

1. creates the child framework.
2. attempt to resolve the child framework.
3. resolves the composite bundle.

In this case the composite bundle sits in the parent framework. The problem
is that until the composite bundle is resolved any attempt made to load a
class or resource that depends on the composite bundle being resolved is
failing. It fails with an NPE when getting the class loader for the
composite. The composite bundle is resolved quite late.

The RecursiveBundleTracker currently works by navigating into the child
framework and setting up a BundleTracker quite early on (before INSTALL
events are emitted for bundles in the child framework). This means that the
BundleTrackerCustomizer will be told about bundles from the start (which is
good) but if a customiser attempts to call getResource or loadClass on a
Bundle that could fail with an NPE. Not only can this happen, but it does
happen in some scenarios when using JPA.

I would like to propose updating the RecursiveBundleTracker to collect
events relating to the child framework and firing them inline to the event
that notifies us when a composite bundle has reached the RESOLVED state.

Thoughts?
Alasdair

-- 
Alasdair Nottingham
not@apache.org