| Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89369] |
Fri, 01 June 2007 14:42  |
Eclipse User |
|
|
|
Originally posted by: sjohnson.mediaspansoftware.com
Hello,
I'm new to Equinox (and OSGi for that matter). I have an application
(J2SE) that I'd like to write that starts up an embedded OSGi framework.
I found some posts online that refer to using either EclipseStarter or
the org.eclipse.core.launcher.Main classes to programmatically launch
the OSGi framework from my app's main() method.
I have been able to get the app and framework started via the
EclipseStarter route, but it fails to load any bundles in the plugins
directory automatically (as I expected it would based on the Equinox
Quick Start documentation). My app's folder layout was thus:
/root
/configuration
config.ini
/plugins
org.eclipse.equinox.common_3.2.0.v20060603.jar
org.eclipse.update.configurator_3.2.2.R32x_v20070111.jar
my.app.bundle.jar
equinox.jar
myapp.jar
I have been unable to startup using the
org.eclipse.core.launcher.Main.main() method because it claims it cannot
find the framework:
java.lang.RuntimeException: Could not find framework
at org.eclipse.core.launcher.Main.getBootPath(Main.java:639)
at org.eclipse.core.launcher.Main.basicRun(Main.java:274)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)
...
In that case I used the following layout (again based on some comments
online I came across):
/root
myapp.jar
/configuration
config.ini
/plugins
equinox.jar
startup.jar
org.eclipse.equinox.common_3.2.0.v20060603.jar
org.eclipse.update.configurator_3.2.2.R32x_v20070111.jar
my.app.bundle.jar
I changed my app's classpath to reflect the new location of the equinox
and startup jars within the plugins folder.
I guess my question is twofold:
1. Which method of starting the framework embedded in a plain J2SE app
is preferred?
2. Should I expect my bundles to be automatically loaded (if not
started) or do I resign myself to writing my own discovery and loading code?
Thanks for your time!
Scott A. Johnson
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89460 is a reply to message #89369] |
Fri, 01 June 2007 16:14  |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
I'm surprised that you don't have org.eclipse.core.runtime in there. Things may not work without it.
The update configurator will scan for plugins in the plugins/ folder when it starts. It's not that customisable IIRC. You need to have in the config.ini an osgi.bundles property that includes the update configurator, because if you don't, then it doesn't find it.
If you have a known set of bundles, you can put them in osgi.bundles yourself and have the framework start them 'manually'. The update configurator merely goes through and installs any plugins that it can find. NB bundles aren't start()ed by default; they are started on class access or on specific request.
Alex.
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89475 is a reply to message #89460] |
Fri, 01 June 2007 16:46 |
| Eclipse User |
|
|
|
Originally posted by: sjohnson.mediaspansoftware.com
Alex Blewitt wrote:
> I'm surprised that you don't have org.eclipse.core.runtime in there. Things may not work without it.
>
> The update configurator will scan for plugins in the plugins/ folder when it starts. It's not that customisable IIRC. You need to have in the config.ini an osgi.bundles property that includes the update configurator, because if you don't, then it doesn't find it.
>
> If you have a known set of bundles, you can put them in osgi.bundles yourself and have the framework start them 'manually'. The update configurator merely goes through and installs any plugins that it can find. NB bundles aren't start()ed by default; they are started on class access or on specific request.
>
> Alex.
Sorry I left that bit of information out...my config.ini file looks like
this:
osgi.bundles=plugins/org.eclipse.equinox.common@2:start,plugins/org.eclipse.update.configurator@3:start
eclipse.ignoreApp=true
Also, org.eclipse.core.runtime is in fact in my equinox.jar (which is
just org.eclipse.osgi_3.2.0.jar renamed).
Under the EclipseStarter method the framework is launched and the 2
bundles specified in the config.ini file *are* loaded. It's just my
custom bundles (which I can successfully load and start manually) are
seemingly ignored.
Ultimately I suppose it doesn't matter *too* much if I have to use my
own code to iterate and load my plugins (I don't want to specify them
manually in a config file), as long as I can load and start new plugins
that may be copied to that folder while the application is still running.
Thanks,
Scott
|
|
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89613 is a reply to message #89592] |
Tue, 05 June 2007 12:16 |
| Eclipse User |
|
|
|
Originally posted by: sjohnson.mediaspansoftware.com
Scott Johnson wrote:
> Alex Blewitt wrote:
>> org.eclipse.core.runtime and org.eclipse.osgi are two different bundles.
>
> What specifically should I be looking for. There are several
> org.eclipse.core.runtime packages in the .jar?
Sorry I did find a separate org.eclipse.core.runtime jar which I placed
next to the equinox jar. Unfortunately it has no effect on the dynamic
discovery of my bundles. I still have to load them manually.
Thanks,
Scott
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89622 is a reply to message #89613] |
Tue, 05 June 2007 12:27 |
| Eclipse User |
|
|
|
Originally posted by: sjohnson.mediaspansoftware.com
Scott Johnson wrote:
> Scott Johnson wrote:
>> Alex Blewitt wrote:
>>> org.eclipse.core.runtime and org.eclipse.osgi are two different bundles.
>>
>> What specifically should I be looking for. There are several
>> org.eclipse.core.runtime packages in the .jar?
>
> Sorry I did find a separate org.eclipse.core.runtime jar which I placed
> next to the equinox jar. Unfortunately it has no effect on the dynamic
> discovery of my bundles. I still have to load them manually.
>
> Thanks,
> Scott
Then I thought to myself, "well idiot, maybe it's a bundle that needs to
be started via config.ini"...so I tried that. In fact the runtime shows
up as installed when I look at the osgi framework via the console after
starting my app, but it won't start that bundle because now it's looking
for org.eclipse.core.jobs. Before I go down that path, it seems to me
that I'm bringing in a lot of "extraneous" stuff for what I want, which
is just core OSGi as provided by Equinox.
Is it not possible to do the dynamic loading of bundles with just the
core OSGi framework?
Thanks again,
Scott
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89635 is a reply to message #89592] |
Tue, 05 June 2007 12:58 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
Bundles and packages are different concepts. A bundle has one or more packages, and a package is provided by one or more bundles.
Generally a bundle com.example.foo (as identified by the MANIEFST.MF's Bundle-SymbolicName field) is stored in a jar com.example.foo_1.2.3.jar and contains packages com.example.foo.*, but that's not necessarily the case.
In this case, there are two bundles; the org.eclipse.osgi bundle stored in org.eclipse.osgi_1.2.3.jar, and org.eclipse.core.runtime stored in org.eclipse.core.runtime_1.2.3.jar. The fact that both bundles export a package called org.eclipse.core.runtime is somewhat irrelivant. You'll also notice that org.eclipse.equinox.common provides org.eclipse.core.runtime packages as well.
So, one bundle = one jar; the bundle has a single name which you can infer from the jar name, but more correctly comes from the manifest.mf. What packages it exports are somewhat unrelated to the bundle's name, although conventionally they share the same prefix.
The important thing to note is that a package may be exported by two or more bundles, and thus when others depend on that package, you need to provide the two or more bundles for it to work.
In this case, org.eclipse.core.runtime is a well-known package that is split in this way, and generally isn't common; however, it got that way after refactoring. But it's incorrect to refer to org.eclipse.equinox.common as 'the o.e.core.runtime bundle'; it's 'the o.e.equinox.common which happens to export o.e.core.runtime'
Anyway, back to the original point; you'll need org.eclipse.equinox.common and org.eclipse.core.runtime in most equinox apps, and you probably didn't have those.
Alex.
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89684 is a reply to message #89635] |
Tue, 05 June 2007 13:47 |
| Eclipse User |
|
|
|
Originally posted by: sjohnson.mediaspansoftware.com
Alex Blewitt wrote:
> Bundles and packages are different concepts. A bundle has one or more packages, and a package is provided by one or more bundles.
>
> Generally a bundle com.example.foo (as identified by the MANIEFST.MF's Bundle-SymbolicName field) is stored in a jar com.example.foo_1.2.3.jar and contains packages com.example.foo.*, but that's not necessarily the case.
>
> In this case, there are two bundles; the org.eclipse.osgi bundle stored in org.eclipse.osgi_1.2.3.jar, and org.eclipse.core.runtime stored in org.eclipse.core.runtime_1.2.3.jar. The fact that both bundles export a package called org.eclipse.core.runtime is somewhat irrelivant. You'll also notice that org.eclipse.equinox.common provides org.eclipse.core.runtime packages as well.
>
> So, one bundle = one jar; the bundle has a single name which you can infer from the jar name, but more correctly comes from the manifest.mf. What packages it exports are somewhat unrelated to the bundle's name, although conventionally they share the same prefix.
>
> The important thing to note is that a package may be exported by two or more bundles, and thus when others depend on that package, you need to provide the two or more bundles for it to work.
>
> In this case, org.eclipse.core.runtime is a well-known package that is split in this way, and generally isn't common; however, it got that way after refactoring. But it's incorrect to refer to org.eclipse.equinox.common as 'the o.e.core.runtime bundle'; it's 'the o.e.equinox.common which happens to export o.e.core.runtime'
>
> Anyway, back to the original point; you'll need org.eclipse.equinox.common and org.eclipse.core.runtime in most equinox apps, and you probably didn't have those.
>
> Alex.
So if I need all these jars just to get the core OSGi framework, why
does the "quick start" page state this:
"If you don't have Eclipse and just want OSGi, click here to get the JAR
from the Equinox download site." [The link downloads just the osgi jar.]
Then furthermore, to move to the next step of automatically discovering
and installing bundles, it states this:
"Now, if you want to make things even easier, you can add in a few
Eclipse bundles (i.e., org.eclipse.equinox.common and
org.eclipse.update.configurator). This gives you automatic bundle
discovery/install. Add these bundles on the osgi.bundles list in your
config.ini as follows:
osgi.bundles=org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start"
Is this page then imcomplete/incorrect? It mentions nothing about
requiring org.eclipse.core.runtime (and it seems org.eclipse.core.jobs
since the runtime bundle won't start without it).
Note also that I *can* get the OSGi framework running with only the OSGi
jar and load/install my bundles programmatically...I was just hoping to
get to the step of automatically installing any bundles present in the
plugins folder.
Thanks,
Scott
|
|
|
| Re: Dynamic Bundle Discovery from Equinox Embedded in a J2SE Application [message #89757 is a reply to message #89684] |
Tue, 05 June 2007 18:33 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
Just to be clear ... the o.e.c.runtime isn't needed by the o.e.u.configurator or the OSGi bundle in general. (In fact, that's why some classes were refactored out into the o.e.e.common bundle, to minimise the dependency on that).
However, other bundles (like o.e.c.jobs) *do* need the o.e.c.runtime bundle.
Either way, the osgi.bundles using the o.e.u.configurator should start the other bundles in the plugins/ folder, assuming that the plugins/ folder is also where the OSGi Jar is.
Alex.
|
|
|
Powered by
FUDForum. Page generated in 0.03563 seconds
] 
Search
Help
Register
Login
Home
