|
Re: Running OSGi-DS as an "Eclipse Application" [message #134481 is a reply to message #134219] |
Mon, 06 July 2009 17:14 |
|
Oliver Wong schrieb:
> After some debugging, we realized one of the big difference between an
> OSGi launch config and an Eclipse launch config is that OSGi has "Default
> autostart" set to true, and Eclipse has it set to false. When I change my
> plugins so that their autostart is "true" instead of default, the example
> finally works in the Eclipse launch config.
That's the intended behavior. The "Eclipse Application" launch config
launches the Eclipse way which prefers lazy vs. eager. However, the DS
bundle need to be started eager in order make DS work. Thus, you can put
it into the config.ini and it will work as an "Eclipse Application" too.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
|
Re: Running OSGi-DS as an "Eclipse Application" [message #134670 is a reply to message #134505] |
Tue, 07 July 2009 14:37 |
Oliver Wong Messages: 47 Registered: July 2009 |
Member |
|
|
Thanks for the replies everyone (including Mike Evans). I've got a few
more questions:
Chris Aniszczyk wrote:
> Gunnar Wagenknecht wrote:
>> Oliver Wong schrieb:
>>> After some debugging, we realized one of the big difference between an
>>> OSGi launch config and an Eclipse launch config is that OSGi has "Default
>>> autostart" set to true, and Eclipse has it set to false. When I change my
>>> plugins so that their autostart is "true" instead of default, the example
>>> finally works in the Eclipse launch config.
>>
>> That's the intended behavior. The "Eclipse Application" launch config
>> launches the Eclipse way which prefers lazy vs. eager. However, the DS
>> bundle need to be started eager in order make DS work. Thus, you can put
>> it into the config.ini and it will work as an "Eclipse Application" too.
I'm not sure what you mean by config.ini, but I guess perhaps you're
talking about making an Eclipse product? I.e. shipping your own branded
exe file? By "Eclipse Application" I meant one of the possible type of
run configurations in your "Run" or "Debug" menu.
> On top of what Gunnar mentioned, PDE goes out of its way to ensure that
> the DS bundle is started in launch configurations. If you're building a
> product definition, make sure you include DS in the list of bundles to
> be auto-started. The DS bundle is the rare case where it actually needs
> to be started before it's really useful.
Back when I first posted this, I'm pretty sure my org.eclipse.equinox.ds
bundle *was* autostarted. However, I could not get the example working
unless I also set my own plugins (org.equinoxosgi.toast.client.emergency)
to start, even though I've specified the "immediate='true'" attribute in
that plugin's component.xml file.
Just to confirm: What I initially experienced was abnormal, and in theory,
you only need the org.eclipse.equinox.ds to be autostarted, and all the
others can be set to lazily started in the launch config; and the
org.eclipse.equinox.ds plugin may start up my bundles eagerly despite what
I've specified in the launch configuration if the component.xml file
states that they should be eagerly started?
|
|
|
|
|
Re: Running OSGi-DS as an "Eclipse Application" [message #502828 is a reply to message #502714] |
Wed, 09 December 2009 20:38 |
Bruce Kelly Messages: 63 Registered: July 2009 |
Member |
|
|
My understanding is that DS needs the bundle started event from the OSGi
framework in order to look for the service component definition files.
So if your bundles are not started by "something", then DS will not know
your bundles exist and so will not attempt to create any service components.
Namaste, Bruce
"Niels Bech Nielsen" <niels.b.nielsen@jpmorgan.com> wrote in message
news:hfobt1$kml$1@build.eclipse.org...
>A follow up question on this one.
>
> I use eclipse RCP 3.4.2 with the ds1.0.0, having interface and
> implementation split into two bundles, and of course a client bundle.
>
> My component specification is immediate and enabled (not sure whether
> 1.0.0 honour these?).
>
> When I specify default_auto_start to true, as suggested first, it works.
> All bundles are activated, and the scr has found my declarative service.
>
> Specifying default_auto_start as false, leaves the service and
> implementation bundle as resolved and hence the component is never loaded
> by scr.
>
> So basically, is this because 1.0.0 does not recognize immediate/enabled
> or if that is the case. How would I specify the default_auto_start in a
> config.ini (without having to list all bundles explicitly).
|
|
|
Powered by
FUDForum. Page generated in 0.02758 seconds