| using ecore in an equinox runtime [message #70219] |
Tue, 18 July 2006 13:07  |
 Thomas Watson
Messages: 503
Registered: July 2009 |
Senior Member |
|
|
Moving a question posted on osgi-dev@bundles.osgi.org mailing list at
http://www.mail-archive.com/osgi-dev@bundles.osgi.org/msg001 29.html
Posted from David Kemper:
I'm trying to use ecore in an Equinox OSGi environment. I'll try
first to state the problem and the symptoms without going deep into
details, and provide any additional info in any follow-ups.
I am installing a fairly large set of required bundles...about a
hundred. This is the result of analyzing all the bundle dependencies
of my client bundle. My client bundle has a dependency on the
org.eclipse.emf.ecore, and all of the hundred bundles that I install
get resolved, including my client bundle.
I explicitly start my client bundle. When I try to use ecore as a
result of my client bundle activator, I get a class not found error
on org.eclipse.em.ecore.EObject, which is in the ecore bundle.
Now here's the rub: If I explicitly start the
org.eclipse.equinox.common bundle before I start my client bundle, my
code works.
My underlying question is: How do I know what bundles need to be
explicitly started in any given configuration? In other words, what
makes org.eclipse.equinox.common special in that I need to explicitly
start it? In my mental OSGi model, a bundle that has an activator
will be started by the framework when its code gets referenced for
the first time (barring explicit calls using the bundle context). Is
this in error? Are there other bundles that I need to start
explicitly, even though their code gets referenced? If so, how do I
know? I'm wondering if there is a set of equinox bundles that I
really should start in my runtime to get a properly functional OSGi
runtime (Current the only such bundle is the org.eclipse.osgi
framework bundle, which gets started implicitly, as it is the
framework bundle).
As always, thanks for any pointers, or for sending me to a more
appropriate list...
/djk
|
|
|
|
| Re: using ecore in an equinox runtime [message #71391 is a reply to message #70240] |
Thu, 03 August 2006 17:34  |
David Kemper
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Tom,
Thanks for the response; it took me a while to get back to this issue,
and I want to be sure I understand its implications.
For various reasons the project that I'm working on launches an Equinox
OSGi runtime with our own bundle that performs functions similar to the
Eclipse Update Configurator. That bundle is explicitly started, and its
bundle activator determines what other bundles need to be installed and
optionally started.
Would you explain why it was necessary to create Eclipse-LazyStart? Its
requirement doesn't mesh with my mental model of OSGi. I thought that
if a bundle has an activator, its start method is called the first time
that code is loaded from that bundle.
If that is *not* the case, then in "pure" OSGi is it up to the operator
(a person or some controller code) to ensure that a given bundle is
explicitly started before its code is used? That would mean that when
starting some bundle X, the operator needs to know which of bundle X's
dependencies need to be explicitly started first, which seems *really*
onerous. It implies an intimate knowledge of the internals of a bundle
and all its dependencies.
If this is why Eclipse-LazyStart was created, I'm surprised it was
missing from OSGi to begin with.
Any insights into this issue, when to start bundles, bundle activators,
and related topics would be much appreciated.
/djk
Tom Watson wrote:
> In equinox we have a concept of lazy activation. This is not an OSGi
> spec'ed feature. When bundles are marked for lazy activation (using the
> Eclipse-LazyStart header) they will be activated upon the first class
> load. In Eclipse 3.2 we have a bug in org.eclipse.equinox.common, this
> bundle was not marked for lazy start. See
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=143038 this bug is fixed
> for 3.3.
>
> Eclipse is normally launched with a config.ini file that contains an
> osgi.bundles property to list the initial bundles that should be
> installed into the framework. This list also specifies whether the
> bundle should be started and at what start-level this bundle should be
> started. The reason the we do not see this problem in a "normal"
> eclipse launch is because this property is set to the following in a
> default eclipse installation ...
>
>
> osgi.bundles=
> org.eclipse.equinox.common@2:start,
> org.eclipse.update.configurator@3:start,
> org.eclipse.core.runtime@start
>
> This specifies that the common bundle should be install and started at
> start-level 2. So we explicitly start this bundle in a typical eclipse
> configuration.
>
> HTH
>
> Tom
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03110 seconds
] 
Search
Help
Register
Login
Home
