Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » About the ClassLoader in SharedObjectDescription
About the ClassLoader in SharedObjectDescription [message #591845] Tue, 06 December 2005 09:57 Go to next message
cloudor is currently offline cloudor
Messages: 32
Registered: July 2009
Member
Hi,

When I called sharedObject.getContext().sendCreate(null, description) ,
I got exceptions in other containers. It seems that I have to declare
the shared object's class package in Export-Package section in
MENIFEST.MF because classLoader in SharedObjectDescription cannot be
serialized and passed to other containers, so I can only rely on the
container's classLoader to load a class in a global exported package.

Maybe it is better to store a String bundleId in SharedObjectDescription
rather than a ClassLoader classLoader.

String can be passed around so in SOManager#loadSharedObject we can do
like this:

protected ISharedObject loadSharedObject(
SharedObjectDescription sd) throws Exception
{
Class newClass = null;
ClassLoader cl = null;
// get bundle
Bundle bundle = Platform.getBundle("");
if (bundle != null)
{
try
{
newClass = bundle.loadClass(sd.getClassname());
cl = newClass.getClassLoader();
} catch (ClassNotFoundException e)
{
}
}
// if bundle failed
if (newClass == null)
{
// First get classloader
cl = container.getClassLoaderForSharedObject(sd);
newClass = Class
.forName(sd.getClassname(), true, cl);

}
// Then get args array from properties
Object[] args = container.getArgsFromProperties(sd);
// And arg types
String[] types = container.getArgTypesFromProperties(sd);
Class[] argTypes = getArgTypes(types, args, cl);

return makeSharedObjectInstance(newClass, argTypes, args);
}




--
Cloudor Pu
http://cloudor.blogthing.com/
Re: About the ClassLoader in SharedObjectDescription [message #591856 is a reply to message #591845] Tue, 06 December 2005 17:02 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Hi Cloudor,

Cloudor Pu wrote:
> Hi,
>
> When I called sharedObject.getContext().sendCreate(null, description) ,
> I got exceptions in other containers. It seems that I have to declare
> the shared object's class package in Export-Package section in
> MENIFEST.MF because classLoader in SharedObjectDescription cannot be
> serialized and passed to other containers, so I can only rely on the
> container's classLoader to load a class in a global exported package.
>
> Maybe it is better to store a String bundleId in SharedObjectDescription
> rather than a ClassLoader classLoader.
>
> String can be passed around so in SOManager#loadSharedObject we can do
> like this:
>
> protected ISharedObject loadSharedObject(
> SharedObjectDescription sd) throws Exception
> {
> Class newClass = null;
> ClassLoader cl = null;
> // get bundle
> Bundle bundle = Platform.getBundle("");
> if (bundle != null)
> {
> try
> {
> newClass = bundle.loadClass(sd.getClassname());
> cl = newClass.getClassLoader();
> } catch (ClassNotFoundException e)
> {
> }
> }
> // if bundle failed
> if (newClass == null)
> {
> // First get classloader
> cl = container.getClassLoaderForSharedObject(sd);
> newClass = Class
> .forName(sd.getClassname(), true, cl);
>
> }
> // Then get args array from properties
> Object[] args = container.getArgsFromProperties(sd);
> // And arg types
> String[] types = container.getArgTypesFromProperties(sd);
> Class[] argTypes = getArgTypes(types, args, cl);
>
> return makeSharedObjectInstance(newClass, argTypes, args);
> }
>
>
>
>

We have considered doing this for some time. It's a good suggestion.
The only thing that's prevented it is that we would like to be able to
run (shared object) servers that are *not* running inside Eclipse
runtimes...and therefore would be lacking any concept of a
Platform...plugin...or a plugin id for that matter.

And actually there is nothing in OSGI 3 with a String plugin id (OSGI 4
I'm not sure of but will look)...so even with an OSGI 3 compliant server
runtime there would not necessarily be what we need. Eclipse impl of
OSGI spec is ahead of the spec here (at least as of OSGI 3).

I'm following work by the fmr Equinox (now platform) team being done to
allow server impls of the Eclipse OSGI implementation (e.g. embedded in
servlet container) as I also would like to use the plugin id as a way to
lookup bundles/classloaders, etc.

Also...with the Eclipse 3.1 'buddy loader' structure (which we still
need to move to) many of the shared object creator difficulties go away
here, as plugins can then register themselves with a target plugin (e.g.
org.eclipse.ecf.provider) as the appropriate location for the loading of
certain classes. With 'buddy loading' this is done in the manifest.mf.
Once we begin using this on both client and servers then this will be
a *much* more effective way of dealing with classloading difficulties.
We may, however, want to do some tooling around modifying the
manifest.mf contents when creating a shared object, etc to make it
easier for people to manage this information.

Thanks again,

Scott
Re: About the ClassLoader in SharedObjectDescription [message #591861 is a reply to message #591856] Tue, 06 December 2005 20:05 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Hi Folks,

One correction to my post...it seems that
org.osgi.framework.Bundle.getSymbolicName() is there. I apparently
missed it (was looking for String getId()).

So it's quite possible that modulo that OSGI-on-server issue (which will
be eventually solved) that we would/will be able to use the bundle's
symbolic name to dynamically look up the bundle (and classloader for
that bundle) associated with a given SharedObjectDescription.

Not sure yet whether this is useful alongside the buddy loader approach
or not. Need to give it some thought. Any thoughts/comments appreciated.

Scott


Scott Lewis wrote:
> Hi Cloudor,
>
> Cloudor Pu wrote:
>
>> Hi,
>>
>> When I called sharedObject.getContext().sendCreate(null, description)
>> , I got exceptions in other containers. It seems that I have to
>> declare the shared object's class package in Export-Package section in
>> MENIFEST.MF because classLoader in SharedObjectDescription cannot be
>> serialized and passed to other containers, so I can only rely on the
>> container's classLoader to load a class in a global exported package.
>>
>> Maybe it is better to store a String bundleId in
>> SharedObjectDescription rather than a ClassLoader classLoader.
>
> >
> > String can be passed around so in SOManager#loadSharedObject we can do
> > like this:
> >
> > protected ISharedObject loadSharedObject(
> > SharedObjectDescription sd) throws Exception
> > {
> > Class newClass = null;
> > ClassLoader cl = null;
> > // get bundle
> > Bundle bundle = Platform.getBundle("");
> > if (bundle != null)
> > {
> > try
> > {
> > newClass = bundle.loadClass(sd.getClassname());
> > cl = newClass.getClassLoader();
> > } catch (ClassNotFoundException e)
> > {
> > }
> > }
> > // if bundle failed
> > if (newClass == null)
> > {
> > // First get classloader
> > cl = container.getClassLoaderForSharedObject(sd);
> > newClass = Class
> > .forName(sd.getClassname(), true, cl);
> >
> > }
> > // Then get args array from properties
> > Object[] args = container.getArgsFromProperties(sd);
> > // And arg types
> > String[] types = container.getArgTypesFromProperties(sd);
> > Class[] argTypes = getArgTypes(types, args, cl);
> >
> > return makeSharedObjectInstance(newClass, argTypes, args);
> > }
> >
> >
> >
> >
>
> We have considered doing this for some time. It's a good suggestion.
> The only thing that's prevented it is that we would like to be able to
> run (shared object) servers that are *not* running inside Eclipse
> runtimes...and therefore would be lacking any concept of a
> Platform...plugin...or a plugin id for that matter.
>
> And actually there is nothing in OSGI 3 with a String plugin id (OSGI 4
> I'm not sure of but will look)...so even with an OSGI 3 compliant server
> runtime there would not necessarily be what we need. Eclipse impl of
> OSGI spec is ahead of the spec here (at least as of OSGI 3).
>
> I'm following work by the fmr Equinox (now platform) team being done to
> allow server impls of the Eclipse OSGI implementation (e.g. embedded in
> servlet container) as I also would like to use the plugin id as a way to
> lookup bundles/classloaders, etc.
>
> Also...with the Eclipse 3.1 'buddy loader' structure (which we still
> need to move to) many of the shared object creator difficulties go away
> here, as plugins can then register themselves with a target plugin (e.g.
> org.eclipse.ecf.provider) as the appropriate location for the loading of
> certain classes. With 'buddy loading' this is done in the manifest.mf.
> Once we begin using this on both client and servers then this will be a
> *much* more effective way of dealing with classloading difficulties. We
> may, however, want to do some tooling around modifying the manifest.mf
> contents when creating a shared object, etc to make it easier for people
> to manage this information.
>
> Thanks again,
>
> Scott
>
>
>
>
>
Re: About the ClassLoader in SharedObjectDescription [message #591870 is a reply to message #591845] Wed, 07 December 2005 04:08 Go to previous messageGo to next message
cloudor is currently offline cloudor
Messages: 32
Registered: July 2009
Member
Cloudor Pu wrote:
> Hi,
>
> String can be passed around so in SOManager#loadSharedObject we can do
> like this:
>
> protected ISharedObject loadSharedObject(
> SharedObjectDescription sd) throws Exception
> {
> Class newClass = null;
> ClassLoader cl = null;
> // get bundle
> Bundle bundle = Platform.getBundle("");
My mistake. It should be: Platform.getBundle(sd.getBundleId());
> if (bundle != null)
> {


--
Cloudor Pu
http://cloudor.blogthing.com/
Re: About the ClassLoader in SharedObjectDescription [message #591892 is a reply to message #591870] Thu, 08 December 2005 04:42 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 970
Registered: July 2009
Senior Member
Hi Cloudor,

FYI, there is specifically an equinox incubator project looking at
running OSGI in server contexts:

http://eclipse.org/equinox/incubator/server/

The reason this is relevant to our discussion is that the buddy loading
mechanisms, along with ability to run on the server would go a long way
to solving many of these classloading problems (as ECF and all apps
based upon it would be able to use the buddy loading mechanisms to
explicitly setup inter-plugin classloading dependencies).

Scott


Cloudor Pu wrote:
>
> Cloudor Pu wrote:
>
>> Hi,
>>
>> String can be passed around so in SOManager#loadSharedObject we can do
>> like this:
>>
>> protected ISharedObject loadSharedObject(
>> SharedObjectDescription sd) throws Exception
>> {
>> Class newClass = null;
>> ClassLoader cl = null;
>> // get bundle
>> Bundle bundle = Platform.getBundle("");
>
> My mistake. It should be: Platform.getBundle(sd.getBundleId());
>
>> if (bundle != null)
>> {
>
>
>
Previous Topic:JMDNSDiscoveryContainer issue
Next Topic:JmDNS provider problem 0.5.3
Goto Forum:
  


Current Time: Thu Oct 02 14:38:19 GMT 2014

Powered by FUDForum. Page generated in 0.01703 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software