Repository bundle loading not working when using BundleContext.installBundle

[gekkothelizard]

I have a problem using my custom bundle loading bundle. I have been developing my bundles by copying them into the pickup folder, where their dependencies were satisfied by the dm-server by installing needed bundles from repositories/ext. Now that I'm using my own bundle loader only those dependencies work that have been already loaded for some reason. Dependencies that aren't started but are in the repository are reported as unresolved.

Is this the defined behaviour, or is it just something waiting to be implemented? Also is there some workaround? Starting the dependency bundles by hand somehow wouldn't be a nice sollution...

[Andy Wilkinson]

The BundleContext.installBundle call only allows a single bundle to be installed at a time, unfortunately there's no hook point that dm Server can use to also install all of the bundle's dependencies.

If you'd like to continue installing your bundle(s) programatically and have the missing dependencies installed from the repository as well you can use dm Server's deployer instead of BundleContext.install(). The deployer's available to you as an MBean or as an OSGi service published under the com.springsource.kernel.deployer.core.ApplicationD eployer interface.

One word of caution: it isn't guaranteed that the MBean or the ApplicationDeployer interface will be unchanged in the run-up to the release of 2.0. It's unlikely that they will change but it is still a possibility.

[gekkothelizard]

I'm pretty heavily depending on dm-server now, so using your API wont be a problem. Thanks for the help!

[gekkothelizard]

We have started using com.springsource.kernel.deployer.core.ApplicationD eployer to deploy bundles, and it works fine, except that after a few (3-10) deployments the service proxy gets destroyed, and we get the following exception:

 org.springframework.osgi.service.importer.ServiceProxyDestroyedException: service proxy has been destroyed
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor$ServiceLookUpCallback.doWithRetry(ServiceDynamicInterceptor.java:105)
    at org.springframework.osgi.service.importer.support.internal.support.RetryTemplate.execute(RetryTemplate.java:83)
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.lookupService(ServiceDynamicInterceptor.java:430)
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:415)
    at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
    at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
    at $Proxy152.isDeployed(Unknown Source)

As this is a system service, I would think that it doesn't get unregistered, but I may be wrong. Is it a bug or some excepected behaviour?

ps: we are injecting the service in context.xml