I don't think any implementation enforces this. I don't even think it is possible because in many cases classes will already be loaded and running. The running code is out of the frameworks hands. The only thing that could be done is to force class loading exceptions or security exceptions when a bundle is stopped. But that would violate the specification because classes are allowed to be loaded and executed from a bundle in the RESOLVED state.
I think the statement is meant bundle developers to make them aware that
using such a pattern will leave them in a strange state because they will
have a thread that is still running code but will not have access to a
valid BundleContext.
Tom
From: Alan Cabrera <[EMAIL PROTECTED]>
To: OSGi Developer Mail List <[email protected]>
Date: 08/21/2008 11:20 AM
Subject: Re: [osgi-dev] Question on Bundle#update()
On Aug 20, 2008, at 5:46 PM, BJ Hargrave wrote:
[EMAIL PROTECTED] wrote on 2008/08/17 08:29:15 PM:
> Re: [osgi-dev] Question on Bundle#update()
>
> Ikuo Yamasaki
>
> to:
>
> OSGi Developer Mail List
>
> 2008/08/17 08:38 PM
>
> Sent by:
>
> [EMAIL PROTECTED]
>
> Please respond to OSGi Developer Mail List <[email protected]>
>
> Thank you for answering my question, BJ.
>
> I got it.
>
> But, what does "this bundle tries to change its own state" mean in
the
> statement of the spec ?
It means a bundle calling, for example, stop on its own Bundle
object. Since the stop contract says the Bundle has to stop doing
things, then when Bundle.stop returns, the bundle is still executing.
This is an awkward state :-)
Do implementations really test for this? The implementation to catch this
seems straightforward using class loading/CGLIB mumbo jumbo but still adds
overhead in terms of both space, execution, and the code to implement it in
the framework. I can imagine some kind of chain of calls where a bundle
does not directly stop itself.
Seems like an odd rule to put into the spec.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
