Home » Eclipse Projects » Equinox » howto launch osgi to use org.eclipse.core.runtime
| howto launch osgi to use org.eclipse.core.runtime [message #53707] |
Tue, 29 November 2005 06:00  |
Eclipse User |
|
|
|
Originally posted by: kai.klesatschke.netallied.de
Hello everybody,
this morning I read a lot of messages about "standalone", "pure" usage
of the OSGi impl equinox. Now I'm playing around with launching the OSGi
framework in a custom main method. Launching the framework with the
DefaultAdaptor works fine and I can install bundles/plugins. My custom
plugins make use of the ExtensionRegistry in the
org.eclipse.core.runtime plugin but if I try to start it I get some
nullpointers. First error was the configurationLocation. After
initializing the LocationManager I got a null pointer while retreiving
the config file.
I guess the problem is that some configuration is missing and maybe I
use the wrong adaptor. What have to be done to get the plugin
org.eclipse.core.runtime started? What is the best way to use the
facilities of org.eclipse.osgi and org.eclipse.core.runtime?
Regards, Kai
|
|
| | |
| Re: howto launch osgi to use org.eclipse.core.runtime [message #53839 is a reply to message #53812] |
Thu, 01 December 2005 06:13  |
| Eclipse User |
|
|
|
System.setProperty("osgi.adaptor",
"org.eclipse.core.runtime.adaptor.EclipseAdaptor");
-> EclipseAdaptor is the default setting. you might not set this property, but you can.
System.setProperty("osgi.framework", "..\\org.eclipse.osgi");
System.setProperty("osgi.install.area", "..\\org.eclipse.core.runtime");
-> I think the syntax is not right. try to place the org.eclipse.core.runtime_3.1.0.jar and the org.eclipse.osgi_3.2.0.jar in your project-subdirectory like 'lib'. For this case you ONLY set ONE sys-property:
System.setProperty("osgi.install.area", "file:lib");
this is for the org.eclipse.core.runtime. The org.eclipse.osgi_3.2.0.jar is found in the same directory. You only have to set the osgi.framework-property, if you have these jars in different locations.
To autostart the org.eclipse.core.runtime as osgi-bundle to run your own plugins you have two possibilities to do this:
1. an entry in the config.ini, which lies within the configuration-dir. This entry looks like:
osgi.bundles=org.eclipse.core.runtime@2:start
the "@2" is for the order of starting the osgi-bundles given in the list of the osgi.bundles-property. ":start" means, that the osgi.framework will automatically start this bundle after installing it.
2. set a sys-property:
System.setProperty("osgi.bundles", "org.eclipse.core.runtime@2:start")
I hope this time you will succeed in running your bundles. Otherwise let me know, what problem you have.
-martin
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #53865 is a reply to message #53839] |
Thu, 01 December 2005 07:48 |
| Eclipse User |
|
|
|
Originally posted by: kai.klesatschke.netallied.de
Martin, thanks for your help. I played around with the properties and
the URLs. After setting the properties for the framework and the install
with absolute paths it worked.
I wondered how to get a reference of the bundle context or the OSGi
instance to install and uninstall bundles. The EclipseStarter has no
function to retreive one of them.
I did another test with the startup.jar and I think I will use this
implementation to start my system because all plugins in the plugins dir
are installed automatically if the update.configurator is specified in
the osgi.bundles property.
I have another question: What about this platform protocol? I know the
org.eclipse.core.runtime registers a service to handle this protocol,
but where can I find the specification how the paths for this protocol
work? E.g. platform:/base references to ...? How to configurate it?
Martin Schikowski wrote:
> System.setProperty("osgi.adaptor",
> "org.eclipse.core.runtime.adaptor.EclipseAdaptor");
> -> EclipseAdaptor is the default setting. you might not set this property, but you can.
>
> System.setProperty("osgi.framework", "..\\org.eclipse.osgi");
> System.setProperty("osgi.install.area", "..\\org.eclipse.core.runtime");
> -> I think the syntax is not right. try to place the org.eclipse.core.runtime_3.1.0.jar and the org.eclipse.osgi_3.2.0.jar in your project-subdirectory like 'lib'. For this case you ONLY set ONE sys-property:
> System.setProperty("osgi.install.area", "file:lib");
> this is for the org.eclipse.core.runtime. The org.eclipse.osgi_3.2.0.jar is found in the same directory. You only have to set the osgi.framework-property, if you have these jars in different locations.
>
> To autostart the org.eclipse.core.runtime as osgi-bundle to run your own plugins you have two possibilities to do this:
> 1. an entry in the config.ini, which lies within the configuration-dir. This entry looks like:
> osgi.bundles=org.eclipse.core.runtime@2:start
> the "@2" is for the order of starting the osgi-bundles given in the list of the osgi.bundles-property. ":start" means, that the osgi.framework will automatically start this bundle after installing it.
> 2. set a sys-property:
> System.setProperty("osgi.bundles", "org.eclipse.core.runtime@2:start")
>
> I hope this time you will succeed in running your bundles. Otherwise let me know, what problem you have.
>
> -martin
|
|
| | | |
| Re: howto launch osgi to use org.eclipse.core.runtime [message #54082 is a reply to message #54054] |
Fri, 02 December 2005 10:33 |
| Eclipse User |
|
|
|
> If the start of the eclipse runtime had been
> successful I could go on and install and start all bundles I specified
> in some sort of extra "runtime" config. Maybe this config will be change
> during runtime and I have to stop/uninstall a bundle. Or, I have an user
> interface which lists all available bundles, their states and gives the
> user the chance to change their states.
I have almost the same problem. I want to install a bundle after the framework has already been initialized.
The OSCAR webpage, as another osgi-implementation (now Apache Felix), lists bundles to administrate a framework installation with all the bundles in it,
like the "HTTP Admin" or some JMX approaches (see http://oscar-osgi.sourceforge.net).
But for me, I would like to have a possibility to manage already installed Bundles
from the application, in which I started equinox, e.g. with Main.main(...). These bundles I have to
address with the bundle symbolic name and bundle version to find the right one. This makes it possible for me
to load and unload bundles, e.g. after parsing a xml file, which contains
all bundle information to install/reload/deinstall.
-martin
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #54687 is a reply to message #54054] |
Mon, 12 December 2005 18:04 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
Kai,
Thanks for the additional detail. I am still a little curious why you are
diving so deep. You should consider running
org.eclipse.core.launcher.Main.main() (in the startup.jar) or EclipseStarter
(in the OSGi bundle). These take care of alot of stuff for you.
As for the extension registry, check out the new refactored runtime. We
factored out the registry into its own bundle
(org.eclipse.equinox.registry).
Jeff
"Kai Klesatschke" <kai.klesatschke@netallied.de> wrote in message
news:dmp2h1$ki7$1@news.eclipse.org...
> > This is a good point. Most of the time people want to start the
framework
> > with a number of bundles and the bundles just do their thing. I'm a
little
> > curious about your usecase. Can you post some sample code illustrating
what
> > you would do if you had a BundleContext?
> >
> > In any event, the only BundleContext we could find and make available
would
> > be that of the system bundle and that would only be accessible via
> > reflection etc (if you were using startup.jar). When we see the usecase
it
> > will be easier to answer the question I think.
>
> Okay an usecase where I need a BundleContext... As I wrote in my first
> mail, this thread is about how to start the OSGi framework that it is
> possible to start/use the facilities of the org.eclipse.core.runtime.
>
> E.g. I tried the following:
>
> <code>
> String workspace = "somedir";
> System.setProperty("osgi.adaptor",
> "org.eclipse.core.runtime.adaptor.EclipseAdaptor");
> System.setProperty("osgi.configuration.area", "file:configuration");
> System.setProperty("osgi.framework", "file:" + workspace +
> "\\org.eclipse.osgi");
> System.setProperty("osgi.install.area", "file:" + workspace);
>
> EclipseAdaptor adaptor = new EclipseAdaptor(args);
> LocationManager.initializeLocations();
> OSGi osgi = new OSGi(adaptor);
> osgi.launch();
> BundleContext context = osgi.getBundleContext();
> Bundle runtime = context.installBundle("file:" + workspace +
> "\\org.eclipse.core.runtime");
> runtime.start();
> </code>
>
> The call of start ends with this exception:
> org.osgi.framework.BundleException: Exception in
> org.eclipse.core.internal.runtime.PlatformActivator.start() of bundle
> org.eclipse.core.runtime.
>
> Okay back to the usecase. If the start of the eclipse runtime had been
> successful I could go on and install and start all bundles I specified
> in some sort of extra "runtime" config. Maybe this config will be change
> during runtime and I have to stop/uninstall a bundle. Or, I have an user
> interface which lists all available bundles, their states and gives the
> user the chance to change their states.
> Why do I want to use the eclipse runtime? It registers extensions upon
> bundle installation and I want to make use of the extension registry to
> make some dependencies checks if the activeted bundles supports the
> extension points my "core" plugin provides and needs at runtime.
>
> I hope this description of a sample usecase helps. Thanks for your reply.
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #56513 is a reply to message #54000] |
Wed, 11 January 2006 18:34 |
| Eclipse User |
|
|
|
Jeff McAffer wrote:
> Update.configurator is useful because it means you don't have to list all
> the bundles you want installed in the config.ini osgi.bundles list. You can
> simply put them all in the plugins dir and update.configurator discovers and
> installs them for you.
As I understand it, you have some choices:
- Provide the list of bundles (with optional start levels) to the
runtime when you launch it.
- Use the update.configurator to discover and install *all* bundles in
the bundle store.
- Some more custom approach.
I have some questions related to this. [Note, I've been using the 3.1.1
release exclusively and have not been using any of the newer refactoring
available through the 3.2 milestones.]
1) What is the overhead of using the configurator? For example, what
kind of per-bundle metadata is created and cached in the configuration
directory of the running instance when a bundle is installed?
2) I am interested in launching multiple applications, each in its own
OSGI JVM, all using the same bundle store. I am concerned that the
different instances, though each is given a separate configuration
directory, might step on the common bundle store (e.g. jar file locking,
or one application updating from version 1.2.3.4 to 1.2.3.5, where the
bundle_1.2.3.jar is overwritten).
3) One use case that I'm considering is to start with a (small) number
of top-level bundles and dynamically form the closure of bundles upon
which they depend, and installing only those bundles. Good idea? Bad idea?
4) What about using the bundle store as a pool of jars for legacy
applications that are OSGi unaware? In other words, using the Eclipse
update mechanisms to keep a bundle store "up-to-date", and using the
jars in the bundle store in a "traditional" URLClassLoader instance by
"flattening" the bundle dependency tree? I know that there may be
version dependency issues and that bundle-private packages would be
exposed, but I'm again worried about possible file locking and
concurrency issues.
How's that for some interesting use cases?
As always, thanks for any answers or guidance.
/djk
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #56596 is a reply to message #56513] |
Thu, 12 January 2006 05:56 |
| Eclipse User |
|
|
|
hello,
> As I understand it, you have some choices:
>
> - Provide the list of bundles (with optional start
> levels) to the
> runtime when you launch it.
>
> - Use the update.configurator to discover and install
> *all* bundles in
> the bundle store.
yes.
>
> - Some more custom approach.
>
> I have some questions related to this. [Note, I've
> been using the 3.1.1
> release exclusively and have not been using any of
> the newer refactoring
> available through the 3.2 milestones.]
>
> 1) What is the overhead of using the configurator?
> For example, what
> kind of per-bundle metadata is created and cached in
> the configuration
> directory of the running instance when a bundle is
> installed?
the overhead is, that for every bundle located in the plugin-directory a bundle classloader will be created.
The configuration directory contains a subdirectory called org.eclipse.osgi. This contains information about the state of each installed bundle.
> 2) I am interested in launching multiple
> applications, each in its own
> OSGI JVM, all using the same bundle store.
why not using ONE JVM?
> I am
> concerned that the
> different instances, though each is given a separate
> configuration
> directory, might step on the common bundle store
> (e.g. jar file locking,
> or one application updating from version 1.2.3.4 to
> 1.2.3.5, where the
> bundle_1.2.3.jar is overwritten).
the behaviour I cannot predict, but I wonder why you want to do it this way.
>
> 3) One use case that I'm considering is to start with
> a (small) number
> of top-level bundles and dynamically form the closure
> of bundles upon
> which they depend, and installing only those bundles.
> Good idea? Bad idea?
hmm, this directs to interesting questions of best practices. Up to now I haven't enough experiences in serviceoriented programming. maybe someone else could answer.
I just think, that I would't think in a tree hierarchy. But maybe this is problem domain specific. I see bundles in a flat order.
>
> 4) What about using the bundle store as a pool of
> jars for legacy
> applications that are OSGi unaware? In other words,
> using the Eclipse
> update mechanisms to keep a bundle store
> "up-to-date", and using the
> jars in the bundle store in a "traditional"
> URLClassLoader instance by
> "flattening" the bundle dependency tree? I know that
> there may be
> version dependency issues and that bundle-private
> packages would be
> exposed, but I'm again worried about possible file
> locking and
> concurrency issues.
>
if you try to update a directory with jars used by a osgi unaware application, then this app must have some functionality to recognize new arrived jars and refresh them... a classloader problem.
You also want to load all Jars into ONE URLClassloader? Or didn't I understand your question right?
martin
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #56917 is a reply to message #56596] |
Mon, 16 January 2006 19:21 |
| Eclipse User |
|
|
|
Responses in line.
Martin Schikowski wrote:
> hello,
>
>
>>As I understand it, you have some choices:
>>
>>- Provide the list of bundles (with optional start
>>levels) to the
>>runtime when you launch it.
>>
>>- Use the update.configurator to discover and install
>>*all* bundles in
>>the bundle store.
>
>
> yes.
>
>
>>- Some more custom approach.
>>
>>I have some questions related to this. [Note, I've
>>been using the 3.1.1
>>release exclusively and have not been using any of
>>the newer refactoring
>>available through the 3.2 milestones.]
>>
>>1) What is the overhead of using the configurator?
>>For example, what
>>kind of per-bundle metadata is created and cached in
>>the configuration
>>directory of the running instance when a bundle is
>>installed?
>
>
> the overhead is, that for every bundle located in the plugin-directory a bundle classloader will be created.
> The configuration directory contains a subdirectory called org.eclipse.osgi. This contains information about the state of each installed bundle.
I am interested in the disk file overhead. For example, if the framework
cached a copy of the bundle JAR in the config area. It does not appear to.
>>2) I am interested in launching multiple
>>applications, each in its own
>>OSGI JVM, all using the same bundle store.
>
>
> why not using ONE JVM?
Imagine a number of independent runtime engines deployed on a machine.
It makes sense to want to share the actual code between them, but
combining all logic into a single JVM is too dangerous. If one engine
crashes the JVM, all engines come down.
I know that the goal of Equinox/OSGi is to create a "rock-solid"
component environment, but there will always be bugs.
In addition, I am trying to make this work with a mix of applications,
some of which are OSGi-aware, others of which are not. They simply will
not be compatible in the same JVM.
Essentially I want to use the plugin/feature logic of Eclipse to keep a
central component store up-to-date (and under the control of a single
OSGi-aware process), but be able to run multiple independent
applications using that store of components.
>>I am
>>concerned that the
>>different instances, though each is given a separate
>>configuration
>>directory, might step on the common bundle store
>>(e.g. jar file locking,
>>or one application updating from version 1.2.3.4 to
>>1.2.3.5, where the
>>bundle_1.2.3.jar is overwritten).
>
>
> the behaviour I cannot predict, but I wonder why you want to do it this way.
See above. I hope that explains the use case.
>>3) One use case that I'm considering is to start with
>>a (small) number
>>of top-level bundles and dynamically form the closure
>>of bundles upon
>>which they depend, and installing only those bundles.
>>Good idea? Bad idea?
>
>
> hmm, this directs to interesting questions of best practices. Up to now I haven't enough experiences in serviceoriented programming. maybe someone else could answer.
>
> I just think, that I would't think in a tree hierarchy. But maybe this is problem domain specific. I see bundles in a flat order.
I'm thinking a tree hierarchy with multiple roots (i.e. the closure of
one or more "main bundles" and their dependencies).
>>4) What about using the bundle store as a pool of
>>jars for legacy
>>applications that are OSGi unaware? In other words,
>>using the Eclipse
>>update mechanisms to keep a bundle store
>>"up-to-date", and using the
>>jars in the bundle store in a "traditional"
>>URLClassLoader instance by
>>"flattening" the bundle dependency tree? I know that
>>there may be
>>version dependency issues and that bundle-private
>>packages would be
>>exposed, but I'm again worried about possible file
>>locking and
>>concurrency issues.
>>
>
>
> if you try to update a directory with jars used by a osgi unaware application, then this app must have some functionality to recognize new arrived jars and refresh them... a classloader problem.
>
> You also want to load all Jars into ONE URLClassloader? Or didn't I understand your question right?
Yes, the OSGi-unaware application would not magically be aware of any
"live" code updates. It would need to be restarted through some external
mechanism.
Yes, the legacy code would need to use its existing "normal" (e.g.
class-path as a collection of jars and/or directories) class loader
hierarchy.
> martin
Thanks for the response.
/djk
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #57563 is a reply to message #56513] |
Mon, 23 January 2006 22:55 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
"David Kemper" <djk@tibco.com> wrote in message
news:43C5960F.8090301@tibco.com...
> Jeff McAffer wrote:
> > Update.configurator is useful because it means you don't have to list
all
> > the bundles you want installed in the config.ini osgi.bundles list. You
can
> > simply put them all in the plugins dir and update.configurator discovers
and
> > installs them for you.
>
> As I understand it, you have some choices:
>
> - Provide the list of bundles (with optional start levels) to the
> runtime when you launch it.
>
> - Use the update.configurator to discover and install *all* bundles in
> the bundle store.
>
> - Some more custom approach.
>
> I have some questions related to this. [Note, I've been using the 3.1.1
> release exclusively and have not been using any of the newer refactoring
> available through the 3.2 milestones.]
>
> 1) What is the overhead of using the configurator? For example, what
> kind of per-bundle metadata is created and cached in the configuration
> directory of the running instance when a bundle is installed?
There isn't much. Some of the information from the bundle manifest is
cached in the state and bundle data files but other than that, typically
there is none. Note that this is true if you use the reference: URL form
when installing the bundles (Update configurator does this automatically).
I fyou use a plain URL then the framework is forced to copy the contents of
the bundle into the configuration area.
> 2) I am interested in launching multiple applications, each in its own
> OSGI JVM, all using the same bundle store. I am concerned that the
> different instances, though each is given a separate configuration
> directory, might step on the common bundle store (e.g. jar file locking,
> or one application updating from version 1.2.3.4 to 1.2.3.5, where the
> bundle_1.2.3.jar is overwritten).
Sure. the bundles are treated as read-only so having multiple instances and
configurations sharing one pool of plugins is no problem. Personally I do
this frequently. It is actually a little known/exploited design feature.
> 3) One use case that I'm considering is to start with a (small) number
> of top-level bundles and dynamically form the closure of bundles upon
> which they depend, and installing only those bundles. Good idea? Bad idea?
You can do this but the problem is actually quite complicated. For example,
dependencies can be expressed using Require-Bundle and/or Import-Package.
It is hard to go from this to then pick the appropriate bundles to use.
Further, there are some bundle dependency structures that are not explicit.
For example, the Help system needs Tomcat (actually any suitable app server)
to run but that dependency is not expressed anywhere in the manifests etc.
The Tomcat plugin simply supplies an extension offering to serve webapps.
> 4) What about using the bundle store as a pool of jars for legacy
> applications that are OSGi unaware? In other words, using the Eclipse
> update mechanisms to keep a bundle store "up-to-date", and using the
> jars in the bundle store in a "traditional" URLClassLoader instance by
> "flattening" the bundle dependency tree? I know that there may be
> version dependency issues and that bundle-private packages would be
> exposed, but I'm again worried about possible file locking and
> concurrency issues.
Sure. As long as you cover all the class overlaps etc. File locking might
be an issue depending on how URL classloaders open files. It would likely
also depend on the OS and filesystem etc.
> How's that for some interesting use cases?
Cool. Its great to see people exploring the options. Please let us know
how it goes and press on any issues.
Jeff
|
|
|
Goto Forum:
Current Time: Mon May 12 07:36:50 EDT 2025
Powered by FUDForum. Page generated in 0.06947 seconds |
Home