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 11: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 #53812 is a reply to message #53759] |
Thu, 01 December 2005 08:22  |
| Eclipse User |
|
|
|
Originally posted by: kai.klesatschke.googlemail.com
> How did you configured the DefaultAdaptor, using
> "osgi.adaptor"?
I didn't config any of the osgi or eclipse related system properties.
> For using the EclipseStarter-method you should specify
> the install area (System property "osgi.install.area")
> for the location of the Eclipse-Runtime. The OSGi-Framework
> is searched for in the path given by the sys-property
> "osgi.framework". But if not given it will be found
> in the same directory as the Eclipse-Runtime. Lastly
> you have to set the sys-property "osgi.configuration.area". This specifies the folder of
> the osgi configuration directory. In this folder a config.ini
> can be placed and the bundle-information is stored.
> For further runtime options see http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse. platform.doc.isv/reference/misc/runtime-options.html.
Okay few minutes ago I tested this:
System.setProperty("osgi.adaptor",
"org.eclipse.core.runtime.adaptor.EclipseAdaptor");
System.setProperty("osgi.configuration.area","configuration ");
System.setProperty("osgi.framework", "..\\org.eclipse.osgi");
System.setProperty("osgi.install.area", "..\\org.eclipse.core.runtime");
EclipseStarter.startup(args,null);
I started the main as a Java application from within eclipse ide. In my
workspace I've imported the plugins org.eclipse.osgi and
org.eclipse.core.runtime. In the call of the function
EclipseStarter.startup(args,null) I get the following null pointer
exception:
java.lang.NullPointerException
at
org.eclipse.osgi.framework.adaptor.core.AbstractBundleData.g etEntry(AbstractBundleData.java:163)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getE ntry(AbstractBundle.java:1284)
at
org.eclipse.osgi.framework.internal.core.Framework.findVMPro file(Framework.java:415)
at
org.eclipse.osgi.framework.internal.core.Framework.loadVMPro file(Framework.java:367)
at
org.eclipse.osgi.framework.internal.core.Framework.initializ e(Framework.java:181)
at
org.eclipse.osgi.framework.internal.core.Framework.<init>(Framework.java:106)
at
org.eclipse.osgi.framework.internal.core.OSGi.createFramewor k(OSGi.java:90)
at org.eclipse.osgi.framework.internal.core.OSGi.<init>(OSGi.java:31)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(Ecli pseStarter.java:272)
at Main.launch1(Main.java:58)
at Main.main(Main.java:43)
I think the problem here is that the bundle file of the osgi bundle
isn't found but what is wrong with the system property osgi.framework?
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #53839 is a reply to message #53812] |
Thu, 01 December 2005 11:13 |
 Martin Schikowski
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
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 12: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 #54000 is a reply to message #53886] |
Fri, 02 December 2005 02:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
First, Martin, thanks for all the great answers! Fantastic!
Second, Kai, thanks for your patience. The usecases you are trying now are
somewhat new. We are refactoring the runtime and OSGi layers and there are
many rough edges. By pushing on this you help us find and smooth them out.
Thanks.
See some embedded comments below.
Jeff
"Martin Schikowski" <schikowski@gmx.de> wrote in message
news:21146356.1133449735703.JavaMail.root@cp1.javalobby.org...
> > 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.
>
> hmm, this the same problem I'm confronting with. I think about some kind
of Management-layer. Do you have some idea?
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.
> > 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.
> Just to understand you:
> You start with the osgi-framework and eclipse-runtime with Main.main(...)
or main.run(). But why is the update.configurator needed in this case?
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.
> > 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?
>
> I already heard from the platform-protocol, but I don't know what it is
about. What's your intention on using the
> platform-protocol? can you please tell me?
There are several variations on the platform: URL.
platform:/base/ = the install location of eclipse
platform:/plugin/<bundle symbolic name> = install area of the given
bundle...
platform:/config/ = the configuration location
platform:/meta/ = the meta data area in the instance location
These are not well documented but you can check out the classes PlatformURL*
in the OSGi bundle.
|
|
|
| Re: howto launch osgi to use org.eclipse.core.runtime [message #54054 is a reply to message #54000] |
Fri, 02 December 2005 09:01 |
| Eclipse User |
|
|
|
Originally posted by: kai.klesatschke.netallied.de
> 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 #54082 is a reply to message #54054] |
Fri, 02 December 2005 15:33 |
Martin Schikowski
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
> 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 23: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 23:34 |
David Kemper
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
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 10:56 |
Martin Schikowski
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
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] |
Tue, 17 January 2006 00:21 |
David Kemper
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
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] |
Tue, 24 January 2006 03: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: Fri Apr 19 19:20:26 GMT 2024
Powered by FUDForum. Page generated in 0.04134 seconds |
] 
Search
Help
Register
Login
Home
