| About the ClassLoader in SharedObjectDescription [message #591845] |
Tue, 06 December 2005 09:57  |
 cloudor Mising name
Messages: 34
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  |
Scott Lewis
Messages: 1038
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 |
Scott Lewis
Messages: 1038
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
>
>
>
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03228 seconds
] 
Search
Help
Register
Login
Home
