Home » Eclipse Projects » Equinox » How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed after resta
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79110 is a reply to message #79077] |
Thu, 14 December 2006 16:10   |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
This is part of the OSGi spec; see 4.3.5, for example. You've got two choices:
1) Call it with Bundle.stop() prior to shutdown. That way, it's no longer started.
2) Don't call Bundle.start()
Instead, if your bundle supports lazy activation (one of Eclipse-AutoStart: true/Eclipse-LazyStart: true/Bundle-ActivationPolicy: lazy, depending on Equinox version :-) then you can trigger a bundle to come up by asking for something from the bundle via its classloader. For example, if . is on your classpath, then you could trigger pretty much any bundle with:
Bundle.getResource("META-INF/MANIFEST.MF")
Given that this starts the classloader, and the classloader is used to resolve where it is, the bundle is brought into the STARTED state as long as it's automatic. However, you're better off trying to use
Bundle.loadClass("some.class.name")
where some.class.name is present, since some other OSGi frameworks might not treat a resource (instead of a class) bringing it up automatically.
Alex.
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79123 is a reply to message #79110] |
Fri, 15 December 2006 00:31 |
 John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
If Eclipse-LazyStart calls Bundle.start(), then won't the bundle start
automatically next time?
Is there a way in eclipse (or equinox) to insure that stop() is called
no matter what way eclipse ends?
Whatever the OSGi spec says isn't relevant since the issue for users of
the Eclipse framework is repeatable, predicable application behavior.
If we can't get that from Equinox then we'll have to start writing
our own activation code which pretty much defeats the purpose of
Equinox. It seems likely to me that the problem is that we don't
undertand OSGi well enough to control it, but the feed back here,
repeating that the current behavoir is dictated by some arbitrary
specification, leads me to wonder if there is no adequate control
mechanism. I suggest it would be helpful for the equinox experts to
consider the point of view of developers trying to use this tool.
John.
Alex Blewitt wrote:
> This is part of the OSGi spec; see 4.3.5, for example. You've got two choices:
>
> 1) Call it with Bundle.stop() prior to shutdown. That way, it's no longer started.
> 2) Don't call Bundle.start()
>
> Instead, if your bundle supports lazy activation (one of Eclipse-AutoStart: true/Eclipse-LazyStart: true/Bundle-ActivationPolicy: lazy, depending on Equinox version :-) then you can trigger a bundle to come up by asking for something from the bundle via its classloader. For example, if . is on your classpath, then you could trigger pretty much any bundle with:
>
> Bundle.getResource("META-INF/MANIFEST.MF")
>
> Given that this starts the classloader, and the classloader is used to resolve where it is, the bundle is brought into the STARTED state as long as it's automatic. However, you're better off trying to use
>
> Bundle.loadClass("some.class.name")
>
> where some.class.name is present, since some other OSGi frameworks might not treat a resource (instead of a class) bringing it up automatically.
>
> Alex.
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79139 is a reply to message #79110] |
Fri, 15 December 2006 07:54 |
Marcin Okraszewski
Messages: 32
Registered: July 2009 |
Member |
|
|
Thanks a lot for the answer. I'm running it on Eclipse 3.2.1 and I was
trying with Eclipse-LazyStart: true and it seems it didn't work.
I was thinking those solutions you suggested, but didn't get idea with
resource MANIFEST.MF. Thanks for that.
I think I'll use getting MANIFEST.MF and if it doesn't start the bundle,
then load it's activator class.
Thanks a lot.
Marcin Okraszewski
Alex Blewitt napisał(a):
> This is part of the OSGi spec; see 4.3.5, for example. You've got two choices:
>
> 1) Call it with Bundle.stop() prior to shutdown. That way, it's no longer started.
> 2) Don't call Bundle.start()
>
> Instead, if your bundle supports lazy activation (one of Eclipse-AutoStart: true/Eclipse-LazyStart: true/Bundle-ActivationPolicy: lazy, depending on Equinox version :-) then you can trigger a bundle to come up by asking for something from the bundle via its classloader. For example, if . is on your classpath, then you could trigger pretty much any bundle with:
>
> Bundle.getResource("META-INF/MANIFEST.MF")
>
> Given that this starts the classloader, and the classloader is used to resolve where it is, the bundle is brought into the STARTED state as long as it's automatic. However, you're better off trying to use
>
> Bundle.loadClass("some.class.name")
>
> where some.class.name is present, since some other OSGi frameworks might not treat a resource (instead of a class) bringing it up automatically.
>
> Alex.
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79153 is a reply to message #79123] |
Fri, 15 December 2006 09:25 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
> Whatever the OSGi spec says isn't relevant since the issue for users of
> the Eclipse framework is repeatable, predicable application behavior.
Yes, and this is the behaviour required by the OSGi spec. So it's completely relevant. Also, the Bundle is determined by the OSGi spec, and neither Eclipse (nor Equinox) can change it without feeding the changes back via OSGi, and that isn't the case for this specific issue.
Eclipse-Lazy/AutoStart does *not* call Bundle.start(). It causes the bundle to be started. Therefore, this behaviour does not occur for bundles that are started automatically.
> It seems likely to me that the problem is that we don't
> understand OSGi well enough to control it, but the feed back here,
> repeating that the current behavoir is dictated by some arbitrary
> specification.
It's worth making clear; Eclipse is built upon Equinox, which is an implementation of the OSGi specification. There are other tools, like Felix or Knopflerfish that are also implementations of the OSGi specification. They all behave in exactly the same way, and invoking Bundle.start() will cause the bundle to be brought up automatically on the next framework restart, because *it is part of the specification of OSGi*
So, you're right -- *you* don't understand the spec well enough, but that doesn't mean that Equinox is wrong. I gave you an example of how to bring a bundle into the started state without using Bundle.start(), which is how every other Equinox developer does it when they don't want to control the .start() and .stop() methods themselves.
I agree with you -- there *ought* to be an easier way to bring up a bundle such that it doesn't get started automatically next time. I personally have always thought that the whole remembering-state-thing of Bundle.start() is both unnecessary and an issue to be worked around. But you would be better addressing your thoughts and concerns to the OSGi spec (or the JSR 291 spec comments, since that's what OSGi 4.1 will be) and request that they add a new method .startTemporarily() or some such. Bashing Equinox will not get you any further towards your goal.
Alex.
|
|
| |
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79176 is a reply to message #79110] |
Fri, 15 December 2006 09:56 |
Marcin Okraszewski
Messages: 32
Registered: July 2009 |
Member |
|
|
Getting resource with Bundle.getResource() didn't start the bundle. But
thrick with loading Activator class worked :)
Marcin Okraszewski
Alex Blewitt napisał(a):
> This is part of the OSGi spec; see 4.3.5, for example. You've got two choices:
>
> 1) Call it with Bundle.stop() prior to shutdown. That way, it's no longer started.
> 2) Don't call Bundle.start()
>
> Instead, if your bundle supports lazy activation (one of Eclipse-AutoStart: true/Eclipse-LazyStart: true/Bundle-ActivationPolicy: lazy, depending on Equinox version :-) then you can trigger a bundle to come up by asking for something from the bundle via its classloader. For example, if . is on your classpath, then you could trigger pretty much any bundle with:
>
> Bundle.getResource("META-INF/MANIFEST.MF")
>
> Given that this starts the classloader, and the classloader is used to resolve where it is, the bundle is brought into the STARTED state as long as it's automatic. However, you're better off trying to use
>
> Bundle.loadClass("some.class.name")
>
> where some.class.name is present, since some other OSGi frameworks might not treat a resource (instead of a class) bringing it up automatically.
>
> Alex.
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bun [message #79190 is a reply to message #79153] |
Fri, 15 December 2006 11:41 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
By the way, there's currently a proposed item from the OSGi 4.1 spec that allows you to request it:
Bundle.start() -> Bundle.start(0) // starts persistently
Bundle.start(START_TRANSIENT) // starts non-persistently
Of course, it's still undergoing proposal/reivew so it might change before it's fully released. It's likely to make it into Equinox for the 3.3 release in some way.
In the meantime, causing the bundle to be started as a side-effect of loading something via the classloader is still possible now.
Alex.
|
|
| | | | |
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79273 is a reply to message #79153] |
Fri, 15 December 2006 21:45 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Sorry if I am sounding rude, but I still hope you will consider my point
of view.
This thread and others make the case that plugin activiation is not
behaving in a way that developers need or expect. OSGi was not designed
for plugins in Eclipse. OSGi has a lot of great features but I think
that the OSGi bundle activation model is not appropriate for Eclipse or
we need to have a better understanding of how to use it. Isn't just
possible that the design can be better?
For example, what are we supposed to make of:
> Eclipse-Lazy/AutoStart does *not* call Bundle.start(). It causes the
> bundle to be started.
I know that it may make sense to you, but I hope you can see that it
seems rather bizarre.
John.
Alex Blewitt wrote:
>>Whatever the OSGi spec says isn't relevant since the issue for users of
>>the Eclipse framework is repeatable, predicable application behavior.
>
>
> Yes, and this is the behaviour required by the OSGi spec. So it's completely relevant. Also, the Bundle is determined by the OSGi spec, and neither Eclipse (nor Equinox) can change it without feeding the changes back via OSGi, and that isn't the case for this specific issue.
>
> Eclipse-Lazy/AutoStart does *not* call Bundle.start(). It causes the bundle to be started. Therefore, this behaviour does not occur for bundles that are started automatically.
>
>
>>It seems likely to me that the problem is that we don't
>>understand OSGi well enough to control it, but the feed back here,
>>repeating that the current behavoir is dictated by some arbitrary
>>specification.
>
>
> It's worth making clear; Eclipse is built upon Equinox, which is an implementation of the OSGi specification. There are other tools, like Felix or Knopflerfish that are also implementations of the OSGi specification. They all behave in exactly the same way, and invoking Bundle.start() will cause the bundle to be brought up automatically on the next framework restart, because *it is part of the specification of OSGi*
>
> So, you're right -- *you* don't understand the spec well enough, but that doesn't mean that Equinox is wrong. I gave you an example of how to bring a bundle into the started state without using Bundle.start(), which is how every other Equinox developer does it when they don't want to control the .start() and .stop() methods themselves.
>
> I agree with you -- there *ought* to be an easier way to bring up a bundle such that it doesn't get started automatically next time. I personally have always thought that the whole remembering-state-thing of Bundle.start() is both unnecessary and an issue to be worked around. But you would be better addressing your thoughts and concerns to the OSGi spec (or the JSR 291 spec comments, since that's what OSGi 4.1 will be) and request that they add a new method .startTemporarily() or some such. Bashing Equinox will not get you any further towards your goal.
>
> Alex.
|
|
| | | |
| Re: How to remove "persistentlyStarted" flag?? I don't [message #79362 is a reply to message #79318] |
Mon, 18 December 2006 14:06 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
If you have Eclipse-LazyStart: true (or Eclipse-AutoStart: true for older versions of Eclipse), then accessing a class will cause the bundle to be started.
If your bundle is Eclipse-LazyStart: false, then it will not start your bundle on class access.
That's why it's not starting :-)
Alex.
|
|
| |
| Re: How to remove "persistentlyStarted" flag?? I don't [message #79538 is a reply to message #79203] |
Tue, 19 December 2006 16:39 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Getting resources does not cause activation. The only thing that
triggers lazy start is the loading of a class that actually comes from
the bundle.
As was noted elsewhere in this thread, the new 4.1 spec has
Bundle.start(int) and allows you to start a bundle without marking it
persistently started. While the spec may indeed change before going
final in Feb, Eclipse 3.3 already has this implemented and the final 3.3
will conform to the 4.1 spec.
Jeff
Alex Blewitt wrote:
> Yeah, I wasn't sure if the resource would work, but it's always worth a try. Glad that the activator class made it work.
>
> Alex.
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79553 is a reply to message #79273] |
Tue, 19 December 2006 16:45 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
JOHN J. BARTON wrote:
> Sorry if I am sounding rude, but I still hope you will consider my point
> of view.
>
> This thread and others make the case that plugin activiation is not
> behaving in a way that developers need or expect. OSGi was not designed
> for plugins in Eclipse. OSGi has a lot of great features but I think
> that the OSGi bundle activation model is not appropriate for Eclipse or
> we need to have a better understanding of how to use it. Isn't just
> possible that the design can be better?
I would like to know more about what you see in OSGi as inappropriate
for Eclipse.
> For example, what are we supposed to make of:
>
> > Eclipse-Lazy/AutoStart does *not* call Bundle.start(). It causes the
> > bundle to be started.
>
> I know that it may make sense to you, but I hope you can see that it
> seems rather bizarre.
As a point of reference, the Eclipse-LazyStart stuff is *Eclipse* not
OSGi. This is being added to the OSGi 4.1 spec but the
ideas/requirements originated with Eclipse. The confusion in this area
really comes from the fact that there are two start() methods. There is
Bundle.start() and BundleActivator.start(). The first is effective,
"make this bundle startable and start it when appropriate (i.e., when
the right start level is reached)". BundleActivator.start() is the
method you implement to capture the start lifecycle for bundles. The
former is NOT called by lazystart. The latter is.
Jeff
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79625 is a reply to message #79553] |
Tue, 19 December 2006 19:21 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Jeff McAffer wrote:
>
>
> JOHN J. BARTON wrote:
>
>> Sorry if I am sounding rude, but I still hope you will consider my
>> point of view.
>>
>> This thread and others make the case that plugin activiation is not
>> behaving in a way that developers need or expect. OSGi was not designed
>> for plugins in Eclipse. OSGi has a lot of great features but I think
>> that the OSGi bundle activation model is not appropriate for Eclipse or
>> we need to have a better understanding of how to use it. Isn't just
>> possible that the design can be better?
>
>
> I would like to know more about what you see in OSGi as inappropriate
> for Eclipse.
Restarting plugins unless the MANIFEST.MF says to do so explicitly.
Autorestart is a fine option for those who know what to expect. For the
rest of us it clouds an already opaque class-loading nightmare (see
numerous posts about class loading and the numerous quirky options in
MANIFEST.MF). Autorestart should not be the default, even if I did not
specify Eclipse-LazyStart the first time I ran my plugin.
>
>> For example, what are we supposed to make of:
>>
>> > Eclipse-Lazy/AutoStart does *not* call Bundle.start(). It causes the
>> > bundle to be started.
>>
>> I know that it may make sense to you, but I hope you can see that it
>> seems rather bizarre.
>
>
> As a point of reference, the Eclipse-LazyStart stuff is *Eclipse* not
> OSGi. This is being added to the OSGi 4.1 spec but the
Is Equinox "Eclipse" or "OSGi"?
> ideas/requirements originated with Eclipse. The confusion in this area
> really comes from the fact that there are two start() methods. There is
> Bundle.start() and BundleActivator.start(). The first is effective,
> "make this bundle startable and start it when appropriate (i.e., when
> the right start level is reached)". BundleActivator.start() is the
> method you implement to capture the start lifecycle for bundles. The
> former is NOT called by lazystart. The latter is.
Ok thanks, that seems very helpful. Now the remark "started but
Bundle.start() is not called" makes some sense.
The name BundleActivator.start() is very unfortunate on two counts.
First it leads us to confuse plugin start() with bundle.start(). (Lots
of other comments also lead to this confusion). Second, we actually have
no idea what "started" means for a plugin. There is no thread of control
here. As far as I can tell, "started" means the plugin class has been
class-loaded, all of the static initializers in the class have run in
order of declaration, and this additional pseudo-static initializer
BundleActivator.start() has been called. I don't know why we need this,
but we have it. Overall it would be much clearer if the method were
called BundleActivator.onClassLoad() or some such.
>
> Jeff
|
|
|
| Re: How to remove "persistentlyStarted" flag?? I don't want a bundle to be resumed [message #79730 is a reply to message #79625] |
Thu, 21 December 2006 04:27 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
JOHN J. BARTON wrote:
> Jeff McAffer wrote:
>> I would like to know more about what you see in OSGi as inappropriate
>> for Eclipse.
>
> Restarting plugins unless the MANIFEST.MF says to do so explicitly.
>
> Autorestart is a fine option for those who know what to expect. For the
> rest of us it clouds an already opaque class-loading nightmare (see
> numerous posts about class loading and the numerous quirky options in
> MANIFEST.MF). Autorestart should not be the default, even if I did not
> specify Eclipse-LazyStart the first time I ran my plugin.
Your point is understood and to a certain extent the upcoming 4.1 OSGi
spec addresses this by including Bundle.start(int) that allows you to
start a bundle but not persist that information. On restart of the
framework then, such "transient" bundles are not automatically restarted.
Note that some/most of the quirks are our fault as we worked through
various iterations of the function and the naming. The stuff around
lazy start is also being codified in the spec.
>> As a point of reference, the Eclipse-LazyStart stuff is *Eclipse* not
>> OSGi. This is being added to the OSGi 4.1 spec but the
>
> Is Equinox "Eclipse" or "OSGi"?
Equinox is the Eclipse implementation of the OSGi standard so I guess
you could say that it is both. We, as other framework implementers, are
free to add value/function as required by our usecases. The LazyStart
support is one such case. As mentioned earlier, others are seeing that
there is value in this behaviour and future versions of the spec will
include this capability.
> The name BundleActivator.start() is very unfortunate on two counts.
> First it leads us to confuse plugin start() with bundle.start(). (Lots
> of other comments also lead to this confusion). Second, we actually have
> no idea what "started" means for a plugin. There is no thread of control
> here. As far as I can tell, "started" means the plugin class has been
> class-loaded, all of the static initializers in the class have run in
> order of declaration, and this additional pseudo-static initializer
> BundleActivator.start() has been called. I don't know why we need this,
> but we have it. Overall it would be much clearer if the method were
> called BundleActivator.onClassLoad() or some such.
I agree that there is some unfortunate naming but there's not much that
can be done about this now. Those methods have been around since the
beginning of OSGi. As for the need for BundleActivators, I also agree
that *in general* they should not be needed. However there are real
usecases where a bundle (collection of function) needs to be
initialized. From a user/admin point of view they see Bundles and can
start/stop/install/uninstall them. The bundles have an opportunity to
hook into those lifecycle events by supplying a BundleActivator. So,
when say the HTTP Bundle is started, it can start the HTTP server
listening on port 80.
Just to be clear, the "plugin class" you refer to is for the most part
deprecated. It had many duties in the old Eclipse and those duties are
fulfilled individually by the Bundle, BundleContext and BundleActivator
classes in OSGi. Personally I like the OSGi way better as it more
clearly separates the concerns.
Jeff
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:22:23 GMT 2024
Powered by FUDForum. Page generated in 0.04593 seconds |
] 
Search
Help
Register
Login
Home
