On 5/14/13 09:43 , Neil Bartlett wrote:
I think that as an alternative approach to using start levels, you
could use transient starting.
If (a) the management agent is the only bundle that ever starts
bundles besides itself, and (b) it always starts them transiently,
i.e. with Bundle.START_TRANSIENT, then you can be sure the management
agent will be the only bundle running after a framework restart.
Yes, that is a similar approach. The main thing you want to achieve is
to have the management bundle do its work before any other bundle gets
started.
-> richard
Neil
On Tue, May 14, 2013 at 2:39 PM, Dan Gravell <[email protected]> wrote:
Gotcha, thanks.
On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <[email protected]>wrote:
On 5/14/13 09:35 , Richard S. Hall wrote:
On 5/14/13 09:24 , Dan Gravell wrote:
Thanks Richard.
Are start levels not... "bad"... from a conceptual point of view? Or, in
this case, where start levels are used to separate "layers" (the
management
layer from the application layer) are they deemed ok?
This is pretty much why start levels exist, but regardless, we are
talking about restarting the JVM because you have bundles that won't
behave, so I think adding start levels doesn't really further soil the
situation. :-)
To further clarify, start levels are not intended as a poor man's approach
to ordering bundle start up, since you shouldn't care about the order in
which bundles start. Using start levels for coarse grained "mode"
management is not unreasonable, but you shouldn't do much more than that.
-> richard
-> richard
Dan
On Tue, May 14, 2013 at 2:07 PM, Richard S. Hall <[email protected]
wrote:
The simplest approach is once you decide some sort of restart is needed,
just stop the framework JVM and have your launcher relaunch it in
"update
mode" which would be a low start level in which no bundles but your
"management" bundle can execute.
In this mode, you know no other bundles have started, so your management
bundle can do whatever updates it wants, call refresh, then change the
start level to enter normal operating mode when it is done.
-> richard
On 5/14/13 07:17 , Dan Gravell wrote:
Hi all. After giving it about a year of tweaks, I'm finally going to
give
up trying to update my OSGi app in process. The killer is the
requirement
to stop all threads... for my particular requirements this just isn't
feasible. I have to maintain my own forks of projects, some complex
(the
Lift web framework) and some less so (JNotify) and this just takes too
long.
So I'm putting thought to how I can structure a solution that restarts
the
JVM *at some point*. I am using Felix 'bundlerepository' bundle to
perform
the deployments of bundles.
So first, the requirement to stop threads: is this a requirement
*before*
start(), stop() or update(URL) is called?
If it's only something that has to be done before stop() then I
_could_ do
everything I do now, up to when start() is called on each bundle. At
that
point, I could exit with an exit code and my launcher script checks
that
and, if it's a known value, restarts the same process. In this case, I
would have to re-start the bundles on restart.
If threads have to be stopped before the update itself, then I suppose
I
can download the bundles to a holding area, and have a bootstrap JVM
that
picks them up and somehow performs the update, and then starts.
If anyone has any wisdom or experience of this I would be grateful to
hear
it...
Dan
------------------------------****----------------------------**--**---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apac**he.org<http://apache.org>
<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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
