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<[email protected]>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<[email protected]>
]
Sent: 16 August 2011 10:47
To: [email protected]
Subject: Re: Help understanding OSGi class loading
So, if the only things in the system are
osgi framework (felix)
fileinstall
some code bundle (spring bundle)
a bundle with an xml file only
And the xml-bundle imports packages that the spring-bundle exports, than
updating and refreshing the spring-bundle should cause the xml-bundle to be
"reloaded". However, if the xml-bundle does not contain code, why is it
important that it gets it's package dependencies rewired? It will not load
any classes anyway (and shouldn't have any package imports because it needs
no packages)? I must be missing something of your problem. :)
If the xml-bundle however does contain code (and needs to load classes),
are you sure that the only one exporting the packages of those classes is
the spring-bundle. One possiblity is that you have other bundles in the
system that export the same packages and that you're getting wired to those
packages instead.
"It didn't pick up the new version of the classes until I deleted the
Spring file[...]"
1. What is "it"? Which bundle are you expecting to see the changes from?
If it's the xml-bundle, have you confirmed that it's manifest.mf-file states
that it needs at least one package that ONLY the spring-bundle can give.
2. There is no way to unload classes, so if "it" has already loaded the
classes it is using, it doesn't matter that you update the origin of those
classes. You also need a refresh which will rewire the package dependencies,
restart the dependent bundles, and reload the classes.
3. Have you made sure that the framework actually gets an update request
on the spring bundle? Fileinstall only has the info supplied by the OS
(file-size, file creation date and so on) to go on, and might determine that
spring-bundleA and spring-bundleB are the same thing (no change, no update).
Finally, trying this in gogo shell might help you see what is wired to
what and when updates actually happen!
Regards,
Per-Erik Svensson
On Tue, Aug 16, 2011 at 7:08 AM, Jim Talbut<[email protected]**>
wrote:
I've tried using refresh now (sorry it takes so long to get things
done around here) and it made no difference.
It didn't pick up the new version of the classes until I deleted the
Spring file, waited for fileinstall to pick that up and remove the
bundle, copied the file over again and waited for fileinstall to pick
that up.
Note that this is using a 1.0-SNAPSHOT version of the classes so there
is no version number change, if that affects things.
Jim
-----Original Message-----
From: Jim Talbut [mailto:Jim.Talbut@groupgti.**com<[email protected]>
]
Sent: 12 August 2011 17:32
To: [email protected]
Subject: RE: Help understanding OSGi class loading
No I didn't.
How does that work with existing instantiated objects?
Thanks
Jim
-----Original Message-----
From: Richard S. Hall [mailto:[email protected]]
Sent: 12 August 2011 14:44
To: [email protected]
Subject: Re: Help understanding OSGi class loading
Did you refresh after doing the update?
On 8/12/11 4:03 AM, Jim Talbut wrote:
Hi,
I've just been surprised by the behaviour of karaf/felix and I'd be
grateful for some help understanding how this works.
My code is split into two chunks:
1. A compiled bundle.
2. A Spring XML file.
My intention is that the Spring file contains all the configuration
relating to the piece of work, whilst the bundle contains the (more
static) compiled code - with the intention of being able to
update/replace the Spring file whenever I want.
I just found an error in the bundle and uninstalled it, but the
bundle
created for the Spring file is still running.
Does this mean that only OSGi services are dynamically removed, and
if
the Spring file directly references exported classes from a bundle
then the classes are only resolved via OSGi when they are loaded?
In which case will restarting the Spring bundle clear it out
adequately
to ensure that it picks up a new compiled bundle?
Thanks
Jim
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
