(It will rather be in the state stopping but, it is resolved nontheless.)
On Tue, Aug 16, 2011 at 3:01 PM, Per-Erik Svensson <
pererik.svens...@gmail.com> wrote:
> 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 <jim.tal...@groupgti.com>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<http://0.0.0.0:8016/mystuffUserdataLoad/TaskSchedulerClient%0A13: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 SelectChannelConnector@0.0.0.0: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: niiba...@gmail.com [mailto:niiba...@gmail.com]
>> Sent: 16 August 2011 12:04
>> To: users@felix.apache.org
>> 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:pererik.svens...@gmail.com]
>> > Sent: 16 August 2011 10:47
>> > To: users@felix.apache.org
>> > 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<jim.tal...@groupgti.com>
>> 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:jim.tal...@groupgti.com]
>> >> Sent: 12 August 2011 17:32
>> >> To: users@felix.apache.org
>> >> 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:he...@ungoverned.org]
>> >> Sent: 12 August 2011 14:44
>> >> To: users@felix.apache.org
>> >> 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: users-unsubscr...@felix.apache.org
>> >> For additional commands, e-mail: users-h...@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> >> For additional commands, e-mail: users-h...@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> >> For additional commands, e-mail: users-h...@felix.apache.org
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> > For additional commands, e-mail: users-h...@felix.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
