On 1/11/12 12:54 , Neil Bartlett wrote:
It's not always about services. For example many Eclipse bundles assume that
the SWT Display has already been created, and furthermore they are being
activated on the UI thread. Again, that's a bunch of bad assumptions on behalf
of the bundle author, but they *do* work if the activation policy is used.
This will always only ever work if the SWT bundle is started before a
client bundle tries to use it. I think Eclipse always immediately lazily
starts lazy bundles, which makes it appear to "work"...
-> richard
I guess I agree with you that eager activation should always be possible, but
following the bundle's policy makes most sense to me as a default.
Neil
On Wednesday, 11 January 2012 at 17:45, Richard S. Hall wrote:
On 1/11/12 12:34 , Neil Bartlett wrote:
Unfortunately I have seen many errors with bundles that assume they are lazily
activated and actually fail if eagerly activated. While that is clearly an
error, I tend to regard the Bundle-ActivationPolicy header as an expression of
intended usage from the bundle author.
What kind of errors?
The only error I can think of is that the bundle wasn't actually
activated before client bundles, but that is a general problem with
these sorts of bundles because they always need to be started (lazily or
not) before client bundles otherwise they'll fail.
That's why they're not so good, because they create bundle activation
ordering requirements.
-> richard
I do agree with you that in general, lazy activation is a hack... it
complicates the bundle lifecycle and is too easily abused. I am much more a fan
of the style of laziness supported by DS and iPOJO.
Neil
On Wednesday, 11 January 2012 at 17:20, Richard S. Hall wrote:
On 1/11/12 12:04 , Neil Bartlett wrote:
Guillaume,
In this case the bundle will be fully started, i.e. "forced" to start without
regard for its policy. Because of this I recommend that you *always* start bundles with
the START_ACTIVATION_POLICY flag.
I believe that it was discussed that the default behaviour of the zero-arg
start() method should be changed to be equivalent to
start(START_ACTIVATION_POLICY). However the old behaviour was kept for
backwards compatibility reasons.
Not sure I agree with this. It is never wrong to start a bundle eagerly,
but it can lead to unexpected results if a bundle that provides a
service is started lazily...of course, you could argue that this bundle
shouldn't have a lazy policy, but that is a separate issue. My first
point remains, it is never incorrect to start a bundle eagerly.
In general, laziness is actually not that great since it hides
dependencies in class loads, rather than basing them on services.
-> richard
Regards,
Neil
On Wednesday, 11 January 2012 at 16:55, Guillaume Sauthier (OW2) wrote:
Another question related to the activation policy.
What happen if the Bundle's manifest has the Bundle-ActivationPolicy header but
the Bundle.start() methods is called without arguments (no options so no
START_TRANSIENT and no START_LAZY_ACTIVATION) ?
--G
2012/1/11 Guillaume Sauthier (OW2)<[email protected]
(mailto:[email protected])>
With Felix, we experienced that the Bundle triggering the class load can use
the class loaded from the lazy Bundle, but the lazy Bundle was not activated
after the class was loaded...
--G
2012/1/11 Guillaume Sauthier (OW2)<[email protected]
(mailto:[email protected])>
Hi all
What happen when a Bundle with Bundle-ActivationPolicy: lazy in its Manifest is
being used while in the RESOLVED state ?
In other words, the Bundle has not yet been started with
Bundle.start(START_LAZY_ACTIVATION), but another Bundle is being activated and
is using a class from the lazy Bundle.
The examples I found on the OSGi web site are only explaining behaviors when
the lazy bundle is activated because of a Bundle.loadClass() while in STARTING
state.
Thanks
--G
_______________________________________________
OSGi Developer Mail List
[email protected] (mailto:[email protected])
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] (mailto:[email protected])
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] (mailto:[email protected])
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] (mailto:[email protected])
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] (mailto:[email protected])
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
