The most likely issue is that spring-dm provides a threadcontextclassloader
as well as monitoring of all activated bundles, combine that with classpath
scanning
and you have one of the reasons why Apache Aries Blueprint is popular :)
On Jun 2, 2011, at 10:27 PM, ext2 wrote:
> Thanks Johan Edstrom
>
> I think it should be a timing issume, not a visibility issue. I have
> traced the source code of DocumentBuilderFactoy where the exception occurs;
> it not try use a un-exists class or resource, but just try to find a
> resource in bundle's delegate class loader , then a exception raised;
>
> Now I still feel puzzled that which thing caused such a timing issue?
>
> To find the answer I tracking the source code of spring-dm and the hot
> deploy application(felix.fileinstall bundle); (the summarized logic will
> list at following.) It seems nothing is wrong.
>
> Hot deploy logic: org.apache.felix.fileinstall.internal.DirectoryWatcher
> Bundle = Context.getBundle(id);//find the old bundle
> Bundle.stop(transient); //stop the bundle
> Bundle.update(inputstream);//update the bundle;
> PackageAdmin.refreshPackages(null);//force updated bundle to be
> refreshed; until now the updated bundle should be resolved and ready for the
> updated content;
> Bundle.start();//restart the bundle; then spring dm will receive
> start event synchronized; and start a new thread to build
> spring-application-context;
>
> Spring DM:
> a summarized logic as( only asynchronized-start logical):
> 1)get bundle from event using synchronized event listener;
> 2)create OsgiBundleXmlapplicationContext();
> 3)if asynchronized, allocate a idle thread to refresh the
> application context;
> 3.1) in the thread: create a BundleDelegateClassLoader for the
> bundle
> 3.2)in the new thread: switch thread context class loader to
> BundleDelegateClassLoader
> 3.3) in the new thread: do spring's context building
> (
> while building spring context, the bean is created; in my problem:
> DocumentBuilderFactory will using the thread context class loader(here is
> Bundle Delegate Class Loader) to locate a DocumentBuilderFactory
> implementation; but the bundle is not valide; so a exception throwed;
> )
>
> 3.4)switch thread context class loader back to original, the ;
>
> Now it seems everything is ok, but which is the exactly reason caused such a
> timing issue?
>
>
> Maybe I should write a simplified program to simulate such a usage to see if
> this problem still exists; But because it's a timing issue, I am not sure
> if such a problem will reappear in the simplified program;
>
>
> Following is some fragments of code of spring dm:
>
> org....extender.internal.activator.ContextLoaderListener
> ContextBundleListener{ //this is synchronized listener;
> on BundleEvent.started:
> mayBeCreateApplicationContext for bundle
> (event.getBundle());
> }
>
> maybeCreateApplicationContext()
> {
> //now create a application context using the bundle's context
> (received from start event)
>
> OsgiApplicationContextCreator.createApplicationContext(bundleContext);
>
> If(asynchroniz)
> start a new thread to run: applicationContex.refresh()
> }
>
> AbstractDelegatedExecutionApplicationContext.startRefresh(){
> Do switch thread context;
> invoke building spring
> do switch back
> }
>
>
>> ----Original -----
>> Sender: Johan Edstrom [mailto:[email protected]]
>> Time: 2011/6/3 0:52
>> Receiver: [email protected]
>> Subject: Re: IllegalStateException of ServiceMix4.3
>>
>> Where you really have a problem is here :
>>
>> org.springframework.osgi.util.BundleDelegatingClassLoader
>>
>> It looks like you have a timing/visibility issue in spring-dm.
>>
>> On Jun 1, 2011, at 11:17 PM, ext2 wrote:
>>
>>> org.springframework.osgi.util.BundleDelegatingClassLoader.getResource(
>
>
>
