RE: Re[2]: [platform-core-dev] Can I use EclipsePlatform Corefunctionali

[Glyn Normington <glyn_normington@xxxxxxxxxx>]

"Kai Shen" <kshen@xxxxxxxxxxx> wrote on 15/04/2005 02:36:37:

> Even though we can write our own code to load the class (basically
> by extending the URLClassLoader class), the functionality would be
> much limited compared with Eclipse's OSGi code. I'm not familiar
> with OSGi, I don't know whether it's enough if we only implement
> loadClass function (for ConfigurationElement). What other
> functionality we need to implement?

If you just need to load classes from the file system, then an extension of
URLClassLoader may be sufficient. I say "may" because I think Eclipse
depends upon quite a bit of the function provided by OSGi and, depending on
how much of Eclipse you use, you'll need to satisfy those dependencies too.

The OSGi framework gives you:

(a) controlled delegation between class loaders via the import/export
syntax in the bundle's manifest,
(b) careful management of the lifecycle of a bundle, including notification
of lifecycle events, and
(c) a service registry, service publish/bind capabilities, and notification
of service lifecycle events.

For an overview of OSGi R3, see
http://www.osgi.org/osgi_technology/index.asp?section=2 but note the
comments below about OSGi R4.

> If we can use Eclipse standalone OSGi framework as suggested by
> Glyn, this part will be much easier. But I'm not sure if the
> standalone OSGi requires a separate classloader. If the standalone
> OSGi and the main Java application can be in the same classloader,
> things will be easier and our solution would be:
>
> 1. Create the standalone OSGi framework in the main Java
> application. The OSGi framework and the main Java application will
> be in the same class loader. If so, the main application can access
> the OSGi framework directly.
> 2. Copy Eclipse's extension point related logic into the Java
> application. Notice that the extension related code will call the
> standalone OSGi framework if necessary. (In fact, since we have the
> OSGi, is it possible for us to use org.eclipse.core.runtime directly
> instead of copying the logic?)
>
> Can anyone make sure if the standalone OSGi and the main Java
> application can be in the SAME classloader?

My experiments created the OSGi framework from the application class
loader. Susequently, the OSGi framework creates a new class loader instance
per bundle which is resolved in the framework. You can provide your own
class loader to the framework if you want to or you can take the default
provided with the framework.

> By the way, do you guys have any internal design documents which
> talk about the architecture of org.eclipse.osgi and
org.eclipse.core.runtime?

The OSGi framework implements some of the draft specifications which are
expected to appear in OSGi R4 which is due out for public review later this
year. I don't think there's much in the way of design documentation for the
OSGi framework on eclipse.org other than commented code. Asking questions
here may unearth design information in people's heads. Also, please feel
free to write up design documentation as you discover it and contribute it
back as a documentation patch. :-)

Glyn