Not being able to stop the bundle is likely to mess with the refreshing that PackageAdmin is doing. It can't stop the bundle and move it to the INSTALLED state, and thus, it will (i presume) remain RESOLVED meaning that anyone depending on it can still see it's classes.
Regards, Per-Erik Svensson On Tue, Aug 16, 2011 at 2:57 PM, Jim Talbut <[email protected]> wrote: > Refreshing again now produced these logs (but I can't say whether it would > have picked up new classes or not because I haven't made any changes there): > There is an error about taking too long to shutdown, but it still shuts > down before restarting - is this likely to be the problem? > > Thanks. > > 13:52:08,907 | INFO | Timer-1 | OsgiBundleXmlApplicationContext > | pport.AbstractApplicationContext 1002 | 89 - org.springframework.context > - 3.0.5.RELEASE | Closing > OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml): startup date [Mon Aug 15 15:56:18 > BST 2011]; root of context hierarchy > 13:52:08,907 | INFO | Timer-1 | log > | .eclipse.jetty.util.log.Slf4jLog 55 | 51 - org.eclipse.jetty.util - > 7.4.2.v20110526 | stopped > o.e.j.s.h.ContextHandler{/mystuffUserdataLoad,null} > 13:52:08,972 | WARN | Timer-1 | JettyHTTPServerEngine > | http_jetty.JettyHTTPServerEngine 215 | - - | Failed to shutdown Jetty > server on port 9000 because it is still in use > 13:52:08,972 | WARN | Timer-1 | JettyHTTPServerEngine > | http_jetty.JettyHTTPServerEngine 215 | - - | Failed to shutdown Jetty > server on port 9000 because it is still in use > 13:52:08,973 | INFO | Timer-1 | DefaultListableBeanFactory > | ort.DefaultSingletonBeanRegistry 422 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Destroying singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@132962af: > defining beans > [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor,traceHandler,soapFaultConverter,cxfInboundLoggingInterceptor,cxfOutboundLoggingInterceptor,tracer,cxf.config6,serviceSchedulerClient,sourceDataSource,targetDataSource,taskExecutor,processVocabularies,processTermData,processOrganisations,processUsers,processUserSectors,processUserRegions,processUserOrganisations,responseFactory,mystuffUserdataLoadCamelContext:beanPostProcessor,mystuffUserdataLoadCamelContext]; > root of factory hierarchy > 13:52:08,974 | INFO | Timer-1 | ThreadPoolTaskExecutor > | ent.ExecutorConfigurationSupport 150 | 89 - org.springframework.context - > 3.0.5.RELEASE | Shutting down ExecutorService 'taskExecutor' > 13:52:08,977 | INFO | Timer-1 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1463 | 104 - org.apache.camel.camel-core > - 2.8.0 | Apache Camel 2.8.0 (CamelContext:mystuffUserdataLoadCamelContext) > is shutting down > 13:52:18,909 | ERROR | elixPackageAdmin | RunnableTimedExecution > | oncurrent.RunnableTimedExecution 109 | 94 - > org.springframework.osgi.extender - 1.2.1 | Closing runnable for context > OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml) did not finish in 10000ms; > consider taking a snapshot and then shutdown the VM in case the thread still > hangs > 13:52:18,916 | INFO | elixPackageAdmin | ultOsgiApplicationContextCreator > | ultOsgiApplicationContextCreator 67 | 94 - > org.springframework.osgi.extender - 1.2.1 | Discovered configurations > {osgibundle:/META-INF/spring/*.xml} in bundle [null (mystuffUserdataLoad)] > 13:52:20,990 | INFO | xtenderThread-25 | OsgiBundleXmlApplicationContext > | pport.AbstractApplicationContext 456 | 89 - org.springframework.context > - 3.0.5.RELEASE | Refreshing > OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml): startup date [Tue Aug 16 13:52:20 > BST 2011]; root of context hierarchy > 13:52:20,993 | INFO | xtenderThread-25 | XmlBeanDefinitionReader > | tory.xml.XmlBeanDefinitionReader 315 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Loading XML bean definitions from URL > [bundle://210.0:0/META-INF/spring/mystuffUserdataLoad-1.0.0.xml] > 13:52:21,004 | INFO | Timer-1 | DefaultShutdownStrategy > | mel.impl.DefaultShutdownStrategy 120 | 104 - org.apache.camel.camel-core > - 2.8.0 | Starting to graceful shutdown 1 routes (timeout 300 seconds) > 13:52:21,008 | INFO | 6 - ShutdownTask | DefaultShutdownStrategy > | ultShutdownStrategy$ShutdownTask 393 | 104 - org.apache.camel.camel-core > - 2.8.0 | Route: RouteUserdataLoad shutdown complete, was consuming from: > Endpoint[cxf://bean:serviceSchedulerClient?dataFormat=POJO&synchronous=true] > 13:52:21,008 | INFO | Timer-1 | DefaultShutdownStrategy > | mel.impl.DefaultShutdownStrategy 158 | 104 - org.apache.camel.camel-core > - 2.8.0 | Graceful shutdown of 1 routes completed in 0 seconds > 13:52:21,009 | INFO | Timer-1 | DefaultInflightRepository > | l.impl.DefaultInflightRepository 89 | 104 - org.apache.camel.camel-core > - 2.8.0 | Shutting down with no inflight exchanges. > 13:52:21,010 | INFO | Timer-1 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1519 | 104 - org.apache.camel.camel-core > - 2.8.0 | Uptime: 21 hours 56 minutes > 13:52:21,010 | INFO | Timer-1 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1520 | 104 - org.apache.camel.camel-core > - 2.8.0 | Apache Camel 2.8.0 (CamelContext: mystuffUserdataLoadCamelContext) > is shutdown in 12.033 seconds > 13:52:21,013 | INFO | Timer-1 | ContextLoaderListener > | BundleApplicationContextListener 60 | 94 - > org.springframework.osgi.extender - 1.2.1 | Application context succesfully > closed (OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml)) > 13:52:21,056 | INFO | xtenderThread-25 | XmlBeanDefinitionReader > | tory.xml.XmlBeanDefinitionReader 315 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Loading XML bean definitions from OSGi > resource[classpath:META-INF/cxf/cxf.xml|bnd.id > =210|bnd.sym=mystuffUserdataLoad] > 13:52:21,065 | INFO | xtenderThread-25 | XmlBeanDefinitionReader > | tory.xml.XmlBeanDefinitionReader 315 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Loading XML bean definitions from OSGi > resource[classpath:META-INF/cxf/cxf-extension-soap.xml|bnd.id > =210|bnd.sym=mystuffUserdataLoad] > 13:52:21,097 | INFO | xtenderThread-25 | XmlBeanDefinitionReader > | tory.xml.XmlBeanDefinitionReader 315 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Loading XML bean definitions from OSGi > resource[classpath:META-INF/cxf/cxf-extension-http.xml|bnd.id > =210|bnd.sym=mystuffUserdataLoad] > 13:52:21,167 | INFO | xtenderThread-25 | XmlBeanDefinitionReader > | tory.xml.XmlBeanDefinitionReader 315 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Loading XML bean definitions from OSGi > resource[classpath:META-INF/cxf/cxf-extension-http-jetty.xml|bnd.id > =210|bnd.sym=mystuffUserdataLoad] > 13:52:21,211 | INFO | xtenderThread-25 | WaiterApplicationContextExecutor > | WaiterApplicationContextExecutor 243 | 94 - > org.springframework.osgi.extender - 1.2.1 | No outstanding OSGi service > dependencies, completing initialization for > OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml) > 13:52:21,287 | INFO | xtenderThread-26 | OsgiBundleXmlApplicationContext > | Context$BeanPostProcessorChecker 122 | 89 - org.springframework.context > - 3.0.5.RELEASE | Bean 'cxf' is not eligible for getting processed by all > BeanPostProcessors (for example: not eligible for auto-proxying) > 13:52:21,290 | INFO | xtenderThread-26 | DefaultListableBeanFactory > | pport.DefaultListableBeanFactory 555 | 87 - org.springframework.beans - > 3.0.5.RELEASE | Pre-instantiating singletons in > org.springframework.beans.factory.support.DefaultListableBeanFactory@7d53a03c: > defining beans > [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor,traceHandler,soapFaultConverter,cxfInboundLoggingInterceptor,cxfOutboundLoggingInterceptor,tracer,cxf.config7,serviceSchedulerClient,sourceDataSource,targetDataSource,taskExecutor,processVocabularies,processTermData,processOrganisations,processUsers,processUserSectors,processUserRegions,processUserOrganisations,responseFactory,mystuffUserdataLoadCamelContext:beanPostProcessor,mystuffUserdataLoadCamelContext]; > root of factory hierarchy > 13:52:21,298 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 470 | 93 - > org.springframework.osgi.core - 1.2.1 | Looking for mandatory OSGi service > dependency for bean [traceHandler] matching filter > (objectClass=org.apache.camel.processor.interceptor.TraceEventHandler) > 13:52:21,298 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 476 | 93 - > org.springframework.osgi.core - 1.2.1 | Found mandatory OSGi service for > bean [traceHandler] > 13:52:21,300 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 470 | 93 - > org.springframework.osgi.core - 1.2.1 | Looking for mandatory OSGi service > dependency for bean [soapFaultConverter] matching filter > (&(objectClass=org.apache.camel.Processor)(com.mycompany.routemaster.purpose=SoapFaultConverter)) > 13:52:21,300 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 476 | 93 - > org.springframework.osgi.core - 1.2.1 | Found mandatory OSGi service for > bean [soapFaultConverter] > 13:52:21,303 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 470 | 93 - > org.springframework.osgi.core - 1.2.1 | Looking for mandatory OSGi service > dependency for bean [cxfInboundLoggingInterceptor] matching filter > (objectClass=com.mycompany.routemaster.cxf.interceptors.InboundInterceptor) > 13:52:21,304 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 476 | 93 - > org.springframework.osgi.core - 1.2.1 | Found mandatory OSGi service for > bean [cxfInboundLoggingInterceptor] > 13:52:21,437 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 470 | 93 - > org.springframework.osgi.core - 1.2.1 | Looking for mandatory OSGi service > dependency for bean [cxfOutboundLoggingInterceptor] matching filter > (objectClass=com.mycompany.routemaster.cxf.interceptors.OutboundInterceptor) > 13:52:21,437 | INFO | xtenderThread-26 | OsgiServiceProxyFactoryBean > | al.aop.ServiceDynamicInterceptor 476 | 93 - > org.springframework.osgi.core - 1.2.1 | Found mandatory OSGi service for > bean [cxfOutboundLoggingInterceptor] > 13:52:21,456 | WARN | xtenderThread-26 | OldSpringSupport > | .cxf.bus.spring.OldSpringSupport 54 | - - | Import of > META-INF/cxf/cxf-extension-soap.xml has been deprecated and is unnecessary. > 13:52:21,457 | WARN | xtenderThread-26 | OldSpringSupport > | .cxf.bus.spring.OldSpringSupport 54 | - - | Import of > META-INF/cxf/cxf-extension-http.xml has been deprecated and is unnecessary. > 13:52:21,458 | WARN | xtenderThread-26 | OldSpringSupport > | .cxf.bus.spring.OldSpringSupport 54 | - - | Import of > META-INF/cxf/cxf-extension-http-jetty.xml has been deprecated and is > unnecessary. > 13:52:21,460 | INFO | xtenderThread-26 | AbstractCamelContextFactoryBean > | .AbstractCamelContextFactoryBean 197 | 107 - > org.apache.camel.camel-spring - 2.8.0 | Using custom Tracer: Tracer > 13:52:21,462 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 2301 | 104 - org.apache.camel.camel-core > - 2.8.0 | JMX enabled. Using ManagedManagementStrategy. > 13:52:21,465 | INFO | xtenderThread-26 | AnnotationTypeConverterLoader > | er.AnnotationTypeConverterLoader 118 | 104 - org.apache.camel.camel-core > - 2.8.0 | Found 3 packages with 14 @Converter classes to load > 13:52:21,471 | INFO | xtenderThread-26 | DefaultTypeConverter > | verter.BaseTypeConverterRegistry 394 | 104 - org.apache.camel.camel-core > - 2.8.0 | Loaded 153 core type converters (total 153 type converters) > 13:52:21,471 | INFO | xtenderThread-26 | Activator > | BundleTypeConverterLoader$Loader 353 | 104 - org.apache.camel.camel-core > - 2.8.0 | Found 2 @Converter classes to load > 13:52:21,472 | INFO | xtenderThread-26 | Activator > | BundleTypeConverterLoader$Loader 353 | 104 - org.apache.camel.camel-core > - 2.8.0 | Found 2 @Converter classes to load > 13:52:21,473 | INFO | xtenderThread-26 | Activator > | BundleTypeConverterLoader$Loader 353 | 104 - org.apache.camel.camel-core > - 2.8.0 | Found 2 @Converter classes to load > 13:52:21,477 | INFO | xtenderThread-26 | ThreadPoolTaskExecutor > | ent.ExecutorConfigurationSupport 115 | 89 - org.springframework.context - > 3.0.5.RELEASE | Initializing ExecutorService 'taskExecutor' > 13:52:21,533 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1318 | 104 - org.apache.camel.camel-core > - 2.8.0 | Apache Camel 2.8.0 (CamelContext: mystuffUserdataLoadCamelContext) > is starting > 13:52:21,533 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1366 | 104 - org.apache.camel.camel-core > - 2.8.0 | Tracing is enabled on CamelContext: > mystuffUserdataLoadCamelContext > 13:52:21,689 | INFO | xtenderThread-26 | ReflectionServiceFactoryBean > | ory.ReflectionServiceFactoryBean 366 | - - | Creating Service { > http://mycompany.com/esb/jobengines/client/service/mycompanySupportSystem/ClientSchedulerTarget}ClientSchedulerTargetServicefrom > WSDL: resources/mystuffUserdataLoad/1.0.0/TaskSchedulerClient.wsdl > 13:52:21,772 | INFO | xtenderThread-26 | ServerImpl > | g.apache.cxf.endpoint.ServerImpl 93 | - - | Setting the server's > publish address to be > http://0.0.0.0:8016/mystuffUserdataLoad/TaskSchedulerClient > 13:52:22,099 | INFO | xtenderThread-26 | log > | .eclipse.jetty.util.log.Slf4jLog 55 | 51 - org.eclipse.jetty.util - > 7.4.2.v20110526 | jetty-7.4.2.v20110526 > 13:52:22,111 | INFO | xtenderThread-26 | log > | .eclipse.jetty.util.log.Slf4jLog 55 | 51 - org.eclipse.jetty.util - > 7.4.2.v20110526 | Started [email protected]:8016 STARTING > 13:52:22,112 | INFO | xtenderThread-26 | log > | .eclipse.jetty.util.log.Slf4jLog 55 | 51 - org.eclipse.jetty.util - > 7.4.2.v20110526 | started > o.e.j.s.h.ContextHandler{/mystuffUserdataLoad,null} > 13:52:22,112 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1906 | 104 - org.apache.camel.camel-core > - 2.8.0 | Route: RouteUserdataLoad started and consuming from: > Endpoint[cxf://bean:serviceSchedulerClient?dataFormat=POJO&synchronous=true] > 13:52:22,115 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1335 | 104 - org.apache.camel.camel-core > - 2.8.0 | Total 1 routes, of which 1 is started. > 13:52:22,115 | INFO | xtenderThread-26 | OsgiSpringCamelContext > | e.camel.impl.DefaultCamelContext 1336 | 104 - org.apache.camel.camel-core > - 2.8.0 | Apache Camel 2.8.0 (CamelContext: mystuffUserdataLoadCamelContext) > started in 0.582 seconds > 13:52:22,116 | INFO | xtenderThread-26 | OsgiBundleXmlApplicationContext > | ractOsgiBundleApplicationContext 348 | 89 - org.springframework.context > - 3.0.5.RELEASE | Not publishing application context OSGi service for bundle > null (mystuffUserdataLoad) > 13:52:22,117 | INFO | xtenderThread-26 | ContextLoaderListener > | BundleApplicationContextListener 45 | 94 - > org.springframework.osgi.extender - 1.2.1 | Application context successfully > refreshed (OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, > config=osgibundle:/META-INF/spring/*.xml)) > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 16 August 2011 12:04 > To: [email protected] > Subject: Re: Help understanding OSGi class loading > > Was the application context refreshed when you refreshed the xml bundle? > Is there any logs after refresh? > > On 16.08.2011 14:56, Jim Talbut wrote: > > The xml-bundle does not contain code - but it does contain instructions > that tell Spring to instantiate objects (and thus to load classes). > > > > "it" is the xml-bundle. > > The xml-bundle instructs spring/camel/cxf to set up a web service, when I > call that web service I was getting the old implementation. > > > > I refreshed both the xml bundle and the bundle containing the > implementation and the web service was still getting the old implementation. > > When the xml-bundle was uninstalled (by deleting the file) and > reinstalled (by copying the same file back in place again) it picked up the > new implementation. > > > > Jim > > > > > > -----Original Message----- > > From: Per-Erik Svensson [mailto:[email protected]] > > Sent: 16 August 2011 10:47 > > To: [email protected] > > Subject: Re: Help understanding OSGi class loading > > > > So, if the only things in the system are > > > > osgi framework (felix) > > fileinstall > > some code bundle (spring bundle) > > a bundle with an xml file only > > > > And the xml-bundle imports packages that the spring-bundle exports, > > than updating and refreshing the spring-bundle should cause the > > xml-bundle to be "reloaded". However, if the xml-bundle does not > > contain code, why is it important that it gets it's package > > dependencies rewired? It will not load any classes anyway (and > > shouldn't have any package imports because it needs no packages)? I > > must be missing something of your problem. :) > > > > If the xml-bundle however does contain code (and needs to load classes), > are you sure that the only one exporting the packages of those classes is > the spring-bundle. One possiblity is that you have other bundles in the > system that export the same packages and that you're getting wired to those > packages instead. > > > > "It didn't pick up the new version of the classes until I deleted the > Spring file[...]" > > 1. What is "it"? Which bundle are you expecting to see the changes from? > If it's the xml-bundle, have you confirmed that it's manifest.mf-file states > that it needs at least one package that ONLY the spring-bundle can give. > > 2. There is no way to unload classes, so if "it" has already loaded the > classes it is using, it doesn't matter that you update the origin of those > classes. You also need a refresh which will rewire the package dependencies, > restart the dependent bundles, and reload the classes. > > 3. Have you made sure that the framework actually gets an update request > on the spring bundle? Fileinstall only has the info supplied by the OS > (file-size, file creation date and so on) to go on, and might determine that > spring-bundleA and spring-bundleB are the same thing (no change, no update). > > > > Finally, trying this in gogo shell might help you see what is wired to > what and when updates actually happen! > > > > Regards, > > Per-Erik Svensson > > > > > > On Tue, Aug 16, 2011 at 7:08 AM, Jim Talbut<[email protected]> > wrote: > > > >> I've tried using refresh now (sorry it takes so long to get things > >> done around here) and it made no difference. > >> It didn't pick up the new version of the classes until I deleted the > >> Spring file, waited for fileinstall to pick that up and remove the > >> bundle, copied the file over again and waited for fileinstall to pick > that up. > >> Note that this is using a 1.0-SNAPSHOT version of the classes so > >> there is no version number change, if that affects things. > >> > >> Jim > >> > >> -----Original Message----- > >> From: Jim Talbut [mailto:[email protected]] > >> Sent: 12 August 2011 17:32 > >> To: [email protected] > >> Subject: RE: Help understanding OSGi class loading > >> > >> No I didn't. > >> How does that work with existing instantiated objects? > >> > >> Thanks > >> > >> Jim > >> > >> -----Original Message----- > >> From: Richard S. Hall [mailto:[email protected]] > >> Sent: 12 August 2011 14:44 > >> To: [email protected] > >> Subject: Re: Help understanding OSGi class loading > >> > >> Did you refresh after doing the update? > >> > >> On 8/12/11 4:03 AM, Jim Talbut wrote: > >>> Hi, > >>> > >>> I've just been surprised by the behaviour of karaf/felix and I'd be > >> grateful for some help understanding how this works. > >>> My code is split into two chunks: > >>> > >>> 1. A compiled bundle. > >>> > >>> 2. A Spring XML file. > >>> My intention is that the Spring file contains all the configuration > >> relating to the piece of work, whilst the bundle contains the (more > >> static) compiled code - with the intention of being able to > >> update/replace the Spring file whenever I want. > >>> I just found an error in the bundle and uninstalled it, but the > >>> bundle > >> created for the Spring file is still running. > >>> Does this mean that only OSGi services are dynamically removed, and > >>> if > >> the Spring file directly references exported classes from a bundle > >> then the classes are only resolved via OSGi when they are loaded? > >>> In which case will restarting the Spring bundle clear it out > >>> adequately > >> to ensure that it picks up a new compiled bundle? > >>> Thanks > >>> > >>> Jim > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
