You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jim Talbut <Ji...@groupgti.com> on 2011/08/12 10:03:08 UTC
Help understanding OSGi class loading
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
Re: Help understanding OSGi class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/16/11 11:09, Per-Erik Svensson wrote:
> "If there are dependencies, then it should refresh."
>
> Does this hold true even if one of the bundles that is in the
> "refresh-graph" throws an exception when it is stopped?
Technically, yes, but I guess that would depend on how messed up things
really are...
>
> Or am I not reading the log correctly?
>
> "[...]
> 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
> [...]"
Yeah, that seems odd. Maybe there is some sort of deadlock situation.
-> richard
>
> Regards,
> Per-Erik Svensson
>
> On Tue, Aug 16, 2011 at 5:00 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 8/16/11 6: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.
>>>
>> If one bundle has a dependency on another, then it will be refreshed when
>> the providing bundle is refreshed (unless there is a bug). A simple test is
>> to get yourself to the point where you think the refresh is necessary, then
>> use the Gogo shell "inspect" command to see if there are any dependencies on
>> the bundle you want to refresh. You could check to see if any bundle is
>> importing from your bundle using "inspect p c<bundle-id>" or bundle
>> dependencies with "inspect b c<bundle-id>" or conversely from the dependent
>> bundle you can query its package requirements with "inspect p r<bundle-id>"
>> and its bundle requirements with "inspect b r<bundle-id>".
>>
>> If there are dependencies, then it should refresh.
>>
>> -> richard
>>
>>
>>
>>> Jim
>>>
>>>
>>> -----Original Message-----
>>> From: Per-Erik Svensson [mailto:pererik.svensson@**gmail.com<pe...@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.Talbut@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.Talbut@groupgti.**com<Ji...@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:heavy@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-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by Per-Erik Svensson <pe...@gmail.com>.
"If there are dependencies, then it should refresh."
Does this hold true even if one of the bundles that is in the
"refresh-graph" throws an exception when it is stopped?
Or am I not reading the log correctly?
"[...]
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
[...]"
Regards,
Per-Erik Svensson
On Tue, Aug 16, 2011 at 5:00 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 8/16/11 6: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.
>>
>
> If one bundle has a dependency on another, then it will be refreshed when
> the providing bundle is refreshed (unless there is a bug). A simple test is
> to get yourself to the point where you think the refresh is necessary, then
> use the Gogo shell "inspect" command to see if there are any dependencies on
> the bundle you want to refresh. You could check to see if any bundle is
> importing from your bundle using "inspect p c <bundle-id>" or bundle
> dependencies with "inspect b c <bundle-id>" or conversely from the dependent
> bundle you can query its package requirements with "inspect p r <bundle-id>"
> and its bundle requirements with "inspect b r <bundle-id>".
>
> If there are dependencies, then it should refresh.
>
> -> richard
>
>
>
>> Jim
>>
>>
>> -----Original Message-----
>> From: Per-Erik Svensson [mailto:pererik.svensson@**gmail.com<pe...@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.Talbut@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.Talbut@groupgti.**com<Ji...@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:heavy@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-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help understanding OSGi class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/16/11 6: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.
If one bundle has a dependency on another, then it will be refreshed
when the providing bundle is refreshed (unless there is a bug). A simple
test is to get yourself to the point where you think the refresh is
necessary, then use the Gogo shell "inspect" command to see if there are
any dependencies on the bundle you want to refresh. You could check to
see if any bundle is importing from your bundle using "inspect p c
<bundle-id>" or bundle dependencies with "inspect b c <bundle-id>" or
conversely from the dependent bundle you can query its package
requirements with "inspect p r <bundle-id>" and its bundle requirements
with "inspect b r <bundle-id>".
If there are dependencies, then it should refresh.
-> richard
>
> Jim
>
>
> -----Original Message-----
> From: Per-Erik Svensson [mailto:pererik.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "niibasta@gmail.com" <ni...@gmail.com>.
Try to change "Import-Package" to "DynamicImport-Package" in your xml
bundle.
DynamicImport-Package tries to refresh packages after every bundle
initialization.
Just for experiment :)
On 16.08.2011 17:19, Per-Erik Svensson wrote:
> (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.svensson@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<Ji...@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: niibasta@gmail.com [mailto:niibasta@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.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by Per-Erik Svensson <pe...@gmail.com>.
(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.svensson@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 <Ji...@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: niibasta@gmail.com [mailto:niibasta@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.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
Re: Help understanding OSGi class loading
Posted by Per-Erik Svensson <pe...@gmail.com>.
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 <Ji...@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 | 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: niibasta@gmail.com [mailto:niibasta@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.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Help understanding OSGi class loading
Posted by Jim Talbut <Ji...@groupgti.com>.
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}ClientSchedulerTargetService from 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 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: niibasta@gmail.com [mailto:niibasta@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.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by Per-Erik Svensson <pe...@gmail.com>.
"I refreshed both the xml bundle and the bundle containing the
implementation and the web service was still getting the old
implementation."
Could you please submit a list of all bundles that you have put in to the
system. I'm sadly still having trouble understanding your env (sry, I don't
work with Spring). :(
If I assume the following
osgi framework
fileinstall
xml-bundle
spring-bundle
I need to know where the "bundel containing the implementation" is and also
where the "web service bundle" is. Maybe if I knew more about spring I would
be able to figure it out but...
It is important to know to get a clear picture of what depends on what.
Generally though, if I assume that the web service is a bundle separate from
xml and spring and that the spring bundle is the bundle containing the
implementation, I get the following:
osgi framework bundle
fileinstall
xml-bundle
spring-bundle
web service-bundle
and then I also guess the dependencies (on package level but nevermind at
this point) look like
xml-bundle : no export, no import
spring-bundle: export org.spring, no import
web service: no export, import org.spring
Then updating the xml-bundle will be completely transparent to all other
bundles. Updating the spring-bundle and refreshing will affect the
web-service bundle (unless it was wired to some other bundle exporting
org.spring but that is unlikely). Updating the web service-bundle will not
affect any other bundle.
With this I'm just trying to say that it would be easier to explain things
if we knew your dependency graph, or at least the relevant parts of it. If
you know your dependency graph then maybe the following can be helpfull:
http://www.osgi.org/javadoc/r2/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[])
It explains what the framework does when a bundle is refreshed.
Maybe, depending on your dependency graph, the bundle you need to refresh is
the web service-bundle (if that is even a bundle, I'm really not sure about
your system).
Also note in the link that you can refresh all bundles by specifying null to
package admin. Also note that this migth restart the entire framework,
however I don't think any of the big dists of osgi does that (felix,
equinox, knopflerfish) so it should be a feasable way to test this.
Basically, what you want to do should be possible, unless you have some
strange class-loading that somehow circumvents the export-import or a
dependency graph that contain elements that we don't know of.
Finally, if you're having trouble with this, instead of updating, try and
uninstall and install the bundle that had a bug. This is semantically
different than an update (which is why Richard asked if you had done a
refresh). Currently, my guess is that you either have no dependencies on the
bundle that you updated (no one depends on it) or that you load classes from
that bundle while somehow circumventing the bundle classloaders. A third
less plausible explanation is that whatever package that you export from the
bundle you updated are imported by others from some other place (so in
effect no one depends on the bundle you updated). Forthly, and maybe most
likely, I'm misinterpreting your dependency graph.
Regards
Per-Erik Svensson
On Tue, Aug 16, 2011 at 1:04 PM, niibasta@gmail.com <ni...@gmail.com>wrote:
> 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.svensson@**gmail.com<pe...@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.Talbut@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.Talbut@groupgti.**com<Ji...@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:heavy@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-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help understanding OSGi class loading
Posted by "niibasta@gmail.com" <ni...@gmail.com>.
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.svensson@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<Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Help understanding OSGi class loading
Posted by Jim Talbut <Ji...@groupgti.com>.
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.svensson@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 <Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by Matt Stevenson <ma...@gmail.com>.
I've been writing an introduction to OSGi dependencies for my project.
It is aimed at people of all levels who have never worked with OSGi, but
parts of it may be helpful.
https://docs.google.com/document/d/1iTlrOjwU1lcY7jM6HjkfXP3dOhir5ep-nliMO9K75rw/edit?hl=en_US
On Tue, Aug 16, 2011 at 4:46 AM, Per-Erik Svensson <
pererik.svensson@gmail.com> wrote:
> 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 <Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
Matt Stevenson.
Re: Help understanding OSGi class loading
Posted by Per-Erik Svensson <pe...@gmail.com>.
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 <Ji...@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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Help understanding OSGi class loading
Posted by Jim Talbut <Ji...@groupgti.com>.
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.Talbut@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:heavy@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: GoGo scripting
Posted by jo...@exceter.com.
Thanks!
Quoting "Richard S. Hall" <he...@ungoverned.org>:
> Gogo supports scripting at least to some degree...not sure if it is
> properly documented, but I'd guess not...
>
> Type "gosh -?" at the Gogo prompt...
>
> You can look at the org.apache.felix.gogo.shell.Shell.gosh() method
> source to get more details on what is going on here.
>
> For an example of a script, just check out the gosh_profile resource in
> the Gogo shell bundle...this is the script that gets executed to start
> every gosh shell session.
>
> -> richard
>
> On 8/12/11 14:10, john.dunlap@exceter.com wrote:
>> Can GoGo be scripted and, if so, where can I find documentation for
>> how to do this?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: GoGo scripting
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Gogo supports scripting at least to some degree...not sure if it is
properly documented, but I'd guess not...
Type "gosh -?" at the Gogo prompt...
You can look at the org.apache.felix.gogo.shell.Shell.gosh() method
source to get more details on what is going on here.
For an example of a script, just check out the gosh_profile resource in
the Gogo shell bundle...this is the script that gets executed to start
every gosh shell session.
-> richard
On 8/12/11 14:10, john.dunlap@exceter.com wrote:
> Can GoGo be scripted and, if so, where can I find documentation for
> how to do this?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
GoGo scripting
Posted by jo...@exceter.com.
Can GoGo be scripted and, if so, where can I find documentation for
how to do this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/12/11 12:52, Donald Whytock wrote:
> That should mean refreshing bundle 0 refreshes everything, right?
Technically, yes, which is effectively the equivalent of just calling
Bundle.update() on the system bundle.
-> richard
>
> On Fri, Aug 12, 2011 at 12:36 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 8/12/11 12:32, Jim Talbut wrote:
>>> No I didn't.
>>> How does that work with existing instantiated objects?
>> When you refresh a bundle, any bundles that depend on it (e.g., import
>> packages from it) will also be refreshed. This is equivalent to starting
>> your bundle up from scratch. All old instances from any refreshed bundles
>> should be forgot about and will eventually be garbage collected.
>>
>> -> richard
>>
>>> Thanks
>>>
>>> Jim
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by Donald Whytock <dw...@gmail.com>.
That should mean refreshing bundle 0 refreshes everything, right?
On Fri, Aug 12, 2011 at 12:36 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 8/12/11 12:32, Jim Talbut wrote:
>>
>> No I didn't.
>> How does that work with existing instantiated objects?
>
> When you refresh a bundle, any bundles that depend on it (e.g., import
> packages from it) will also be refreshed. This is equivalent to starting
> your bundle up from scratch. All old instances from any refreshed bundles
> should be forgot about and will eventually be garbage collected.
>
> -> richard
>
>>
>> Thanks
>>
>> Jim
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/12/11 12:32, Jim Talbut wrote:
> No I didn't.
> How does that work with existing instantiated objects?
When you refresh a bundle, any bundles that depend on it (e.g., import
packages from it) will also be refreshed. This is equivalent to starting
your bundle up from scratch. All old instances from any refreshed
bundles should be forgot about and will eventually be garbage collected.
-> richard
>
> Thanks
>
> Jim
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Help understanding OSGi class loading
Posted by Jim Talbut <Ji...@groupgti.com>.
No I didn't.
How does that work with existing instantiated objects?
Thanks
Jim
-----Original Message-----
From: Richard S. Hall [mailto:heavy@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "niibasta@gmail.com" <ni...@gmail.com>.
Packages are resolved on "resolved" phase just after "install" phase.
Framework creates "wires" between bundles using "Import" and "Export"
packages directives.
When exporting bundle goes away, importing bundle still holds references
to loaded classes until "update" or "refresh" will be called.
If you want to get more deeper into this process, you need to check
"OSGi Core Specification" chapters
3.7 "Resolving process",
4.4.6.3 "Restoring State After Refresh or Update"
4.4.9 "Updating Bundles".
On 12.08.2011 14:11, Jim Talbut wrote:
> Yes, though the spring bundle is just the single XML file loaded via the fileinstaller.
>
> I think my question should be the same for any two bundles that relate purely by Import/Export packages:
> At what point are the packages resolved?
> What happens to that resolving when the Exporting bundle goes away?
>
> Thanks
>
> Jim
>
> -----Original Message-----
> From: niibasta@gmail.com [mailto:niibasta@gmail.com]
> Sent: 12 August 2011 10:14
> To: users@felix.apache.org
> Subject: Re: Help understanding OSGi class loading
>
> Hello!
>
> I didn't understand clearly your task. Do you have one bundle with classes and another bundle with spring xml file?
>
> On 12.08.2011 12:03, 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Help understanding OSGi class loading
Posted by Jim Talbut <Ji...@groupgti.com>.
Yes, though the spring bundle is just the single XML file loaded via the fileinstaller.
I think my question should be the same for any two bundles that relate purely by Import/Export packages:
At what point are the packages resolved?
What happens to that resolving when the Exporting bundle goes away?
Thanks
Jim
-----Original Message-----
From: niibasta@gmail.com [mailto:niibasta@gmail.com]
Sent: 12 August 2011 10:14
To: users@felix.apache.org
Subject: Re: Help understanding OSGi class loading
Hello!
I didn't understand clearly your task. Do you have one bundle with classes and another bundle with spring xml file?
On 12.08.2011 12:03, 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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help understanding OSGi class loading
Posted by "niibasta@gmail.com" <ni...@gmail.com>.
Hello!
I didn't understand clearly your task. Do you have one bundle with
classes and another bundle with spring xml file?
On 12.08.2011 12:03, 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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org