Home » Eclipse Projects » Equinox » OSGi and application creating classloaders
| OSGi and application creating classloaders [message #10440] |
Sat, 08 March 2003 15:04  |
Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
Questions to the specialist of classloading in OSGi:
Recently, we discovered a nasty bug caused by some application
creating classloaders. Here is the scenario:
The antRunner (an eclipse cpt) requires Xerces (from eclipse).
For short, the antRunner is the context in which all the build scripts
are running, and so every script that uses xml stuffs see the same
version of xerces.
However we came up with a case where a build script was using
a task that was creating its own classloader (not bound to the eclipse
classloaders - it's one of the optional task that ant provides), and
was also loading some xml classes.
Then guess what....: ClassCastException...
So my question now:
How does OSGi handle those problems?
A related question:
Does OSGi provide hooks to application writer to provide their
own classloaders?
PaScaL
|
|
|
| Re: OSGi and application creating classloaders [message #10474 is a reply to message #10440] |
Sat, 08 March 2003 17:19  |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
> Then guess what....: ClassCastException...
That is not a guess ... :-) Preventing that case is the core of the OSGi
Framework specification. Each bundle (JAR file) has an import/export
specification for classes it is willing share with other bundles. An
OSGi framework has a map of all packages and picks one classloader for
each exported package. In OSGi, only one bundle can export a designated
package which is shared by all. This prevents the ClassCastException
problem.
Applications (bundles) can use their own classloaders if they want to
(and have permission in a secure system). There are no hooks to extend
the bundle's classloader. So you can use your own classloader in Jini
like scenarios. Of course you have to be careful not to mess up your own
package namespace, classloaders in a component like environment are
tricky for exactly the reason you mention.
What scenario are you thinking of that needs a class loader, because
except for Jini, I have not seen it necessary so far (except for Jini).
Just curious.
Kind regards,
Peter Kriens
Pascal Rapicault wrote:
> Questions to the specialist of classloading in OSGi:
>
> Recently, we discovered a nasty bug caused by some application
> creating classloaders. Here is the scenario:
>
> The antRunner (an eclipse cpt) requires Xerces (from eclipse).
> For short, the antRunner is the context in which all the build scripts
> are running, and so every script that uses xml stuffs see the same
> version of xerces.
> However we came up with a case where a build script was using
> a task that was creating its own classloader (not bound to the eclipse
> classloaders - it's one of the optional task that ant provides), and
> was also loading some xml classes.
>
> Then guess what....: ClassCastException...
>
> So my question now:
> How does OSGi handle those problems?
>
>
> A related question:
> Does OSGi provide hooks to application writer to provide their
> own classloaders?
>
>
> PaScaL
>
>
>
|
|
|
| Re: OSGi and application creating classloaders [message #10675 is a reply to message #10474] |
Sun, 09 March 2003 02:43 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Ant uses its own classloaders to manages the definition and use of user
defined "tasks". Basically users can register Java classes and give them a
name. The ant scripts run and reference the tasks by name thus requiring the
related classes to be loaded. The Ant framework itself has no prior
knowledge of the user-defined tasks so it creates a classloader and allows
tasks definers to add their code to the classpath. When the Ant script is
finished running, the classloader is thrown away and hopefully GC'd along
with all the loaded classes.
What actually happens in Eclipse is we create a special Ant classloader
which does the normal classloading and then consults the classloaders of all
the plugins which provided Ant task definitions.
Under OSGi,
- if the task classes/packages were exported, could the Ant bundle
dynamically add an import for a discovered task so the class could be
loaded? If it could, could the import be later removed when the script is
no longer running? would removal even be needed?
- often times the classes registered as tasks are not API and so should not
be exported (depending on your view of "export" semantics). Is there some
way we could still discover where the class is and ask its bundle's loader
to load it?
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E6A2612.7050507@aQute.se...
> > Then guess what....: ClassCastException...
> That is not a guess ... :-) Preventing that case is the core of the OSGi
> Framework specification. Each bundle (JAR file) has an import/export
> specification for classes it is willing share with other bundles. An
> OSGi framework has a map of all packages and picks one classloader for
> each exported package. In OSGi, only one bundle can export a designated
> package which is shared by all. This prevents the ClassCastException
> problem.
>
> Applications (bundles) can use their own classloaders if they want to
> (and have permission in a secure system). There are no hooks to extend
> the bundle's classloader. So you can use your own classloader in Jini
> like scenarios. Of course you have to be careful not to mess up your own
> package namespace, classloaders in a component like environment are
> tricky for exactly the reason you mention.
>
> What scenario are you thinking of that needs a class loader, because
> except for Jini, I have not seen it necessary so far (except for Jini).
> Just curious.
>
> Kind regards,
>
> Peter Kriens
>
>
> Pascal Rapicault wrote:
>
> > Questions to the specialist of classloading in OSGi:
> >
> > Recently, we discovered a nasty bug caused by some application
> > creating classloaders. Here is the scenario:
> >
> > The antRunner (an eclipse cpt) requires Xerces (from eclipse).
> > For short, the antRunner is the context in which all the build scripts
> > are running, and so every script that uses xml stuffs see the same
> > version of xerces.
> > However we came up with a case where a build script was using
> > a task that was creating its own classloader (not bound to the eclipse
> > classloaders - it's one of the optional task that ant provides), and
> > was also loading some xml classes.
> >
> > Then guess what....: ClassCastException...
> >
> > So my question now:
> > How does OSGi handle those problems?
> >
> >
> > A related question:
> > Does OSGi provide hooks to application writer to provide their
> > own classloaders?
> >
> >
> > PaScaL
> >
> >
> >
>
|
|
|
| Re: OSGi and application creating classloaders AND service registry [message #10772 is a reply to message #10675] |
Sun, 09 March 2003 10:45 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Jeff McAffer wrote:
> - if the task classes/packages were exported, could the Ant bundle
> dynamically add an import for a discovered task so the class could be
> loaded? If it could, could the import be later removed when the script is
> no longer running? would removal even be needed?
Dynamic import is supported in the upcoming release 3. Package
administration is exposed in OSGi with a special service called
PackageAdmin. This allows you to refresh the shared package map and
resolve again. We might need some special tricks in the implementation
to make this really efficient but I think the spec allows it. However,
maybe we do not need to have Ant handle this tricky stuff if we could
leverage the OSGi service registry, see next point.
> - often times the classes registered as tasks are not API and so should not
> be exported (depending on your view of "export" semantics). Is there some
> way we could still discover where the class is and ask its bundle's loader
> to load it?
In OSGi this problem is solved with the service registry. A task would
register an object in the service registry implementing a shared
interface, e.g. an AntTask interface. This interface is exported by the
Ant dynammic plugin and the task's plugin does therefore not have to
export any private packages at all.
However, this would require the dynamic plugin always to be started and
thus the 5000+ requirement comes into play ... So how do we optimize this?
If I had to do this optimization completely within the current R2 spec I
would do the following:
1. When a dynamic plugin is -installed- (i.e. NOT at boot time) Eclipse
would read the plugin.xml (or whatever other info there is to read from
META-INF) and find out the name of the Ant Tasks in there.
2. The bundle would normally not be started. Eclipse would then cache
this info and and register proxies for the Ant Task in the OSGi service
registry at boot time (or after an install).
3. These proxies implement the ServiceFactory interface. This means that
Eclipse is called back when somebody gets that service.
4. Eclipse starts the dynamic plugin that has the designated Ant Task.
5. This dynamic plugin registers an Ant Task. This service is gotten by
Eclipse. Eclipse returns this object to Ant.
6. If Ant is finished, it would "unget" the object. Eclipse is called
back and stops the Ant Task's dynamic plugin (if no other services are
in use from this plugin).
So I think the optimization could be done with the current spec if we
adopt the OSGi service registry. However, the idea of "lazy services"
could be done even more efficient by the Framework, as a general
feature. We could probably get this standardized in the OSGi if it
really works as I envision here. It seems an attractive optimization in
embedded systems.
Notice that in this model, Ant never has to import any special package
(It would not require dynamic import package). The AntTask interface
would be exported by Ant. The actual instance would automaticlly load
from its plugin's class loader. => coupling is minimal.
Anyway, the concept of a dynamic service registry is kind of crucial to
allow these kind of optimizations (Even for me, this example is kind of
enlightening why the OSGi service registry works so well in practice).
Kind regards,
Peter Kriens
>
> Jeff
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E6A2612.7050507@aQute.se...
>
>>>Then guess what....: ClassCastException...
>>>
>>That is not a guess ... :-) Preventing that case is the core of the OSGi
>>Framework specification. Each bundle (JAR file) has an import/export
>>specification for classes it is willing share with other bundles. An
>>OSGi framework has a map of all packages and picks one classloader for
>>each exported package. In OSGi, only one bundle can export a designated
>>package which is shared by all. This prevents the ClassCastException
>>problem.
>>
>>Applications (bundles) can use their own classloaders if they want to
>>(and have permission in a secure system). There are no hooks to extend
>>the bundle's classloader. So you can use your own classloader in Jini
>>like scenarios. Of course you have to be careful not to mess up your own
>>package namespace, classloaders in a component like environment are
>>tricky for exactly the reason you mention.
>>
>>What scenario are you thinking of that needs a class loader, because
>>except for Jini, I have not seen it necessary so far (except for Jini).
>>Just curious.
>>
>>Kind regards,
>>
>>Peter Kriens
>>
>>
>>Pascal Rapicault wrote:
>>
>>
>>>Questions to the specialist of classloading in OSGi:
>>>
>>>Recently, we discovered a nasty bug caused by some application
>>>creating classloaders. Here is the scenario:
>>>
>>>The antRunner (an eclipse cpt) requires Xerces (from eclipse).
>>>For short, the antRunner is the context in which all the build scripts
>>>are running, and so every script that uses xml stuffs see the same
>>>version of xerces.
>>>However we came up with a case where a build script was using
>>>a task that was creating its own classloader (not bound to the eclipse
>>>classloaders - it's one of the optional task that ant provides), and
>>>was also loading some xml classes.
>>>
>>>Then guess what....: ClassCastException...
>>>
>>>So my question now:
>>> How does OSGi handle those problems?
>>>
>>>
>>>A related question:
>>> Does OSGi provide hooks to application writer to provide their
>>> own classloaders?
>>>
>>>
>>> PaScaL
>>>
>>>
>>>
>>>
>
>
|
|
|
| Re: OSGi and application creating classloaders [message #11987 is a reply to message #10675] |
Mon, 10 March 2003 03:16 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Along the lines of my other recent post, when unloading or reloading a
plugin, you ideally want the "old one" to get GC'd. If any other class,
whether in a dependency or its own set of classes, has a ref to the plugin
lifecycle class, how do you "null out" all the refs to the plugin class, for
that matter ALL classes in the plugin, so that they can be GC'd and their
bytecode unloaded from memory (if their plugin classloader loaded their
bytecode). Is there some simple way in which you can just have the
classloader null out all of its refs to classes it loads? How do you null
the classloader for that matter so that the whole darn thing can get tossed
out and GC'd. I realize that a newly loaded plugin of the same name and
classes gets its own "space" and does load without problems, and future
calls to use that plugin all use the newly loaded one (assuming they both
are stored via the same key in the registry of loaded plugins). Having built
a MVC framework, I added reload abilities with classloaders, but I can't
even guess how I know if an "old" class and its loader get thrown out. In
the MVC framework there are no refs to anything but the HttpSession and
sometimes context, which of course its up to any class(es) to null out those
refs. But I am mystified as to how you can actually monitor a given class
and its classloader and know when it is GC'd. Does the finalize() method
work to inform us that the garbage collector is about to null out a class
and remove it from the jvm?
Thanks.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b4e9uq$lns$1@rogue.oti.com...
> Ant uses its own classloaders to manages the definition and use of user
> defined "tasks". Basically users can register Java classes and give them
a
> name. The ant scripts run and reference the tasks by name thus requiring
the
> related classes to be loaded. The Ant framework itself has no prior
> knowledge of the user-defined tasks so it creates a classloader and allows
> tasks definers to add their code to the classpath. When the Ant script is
> finished running, the classloader is thrown away and hopefully GC'd along
> with all the loaded classes.
>
> What actually happens in Eclipse is we create a special Ant classloader
> which does the normal classloading and then consults the classloaders of
all
> the plugins which provided Ant task definitions.
>
> Under OSGi,
>
> - if the task classes/packages were exported, could the Ant bundle
> dynamically add an import for a discovered task so the class could be
> loaded? If it could, could the import be later removed when the script is
> no longer running? would removal even be needed?
>
> - often times the classes registered as tasks are not API and so should
not
> be exported (depending on your view of "export" semantics). Is there some
> way we could still discover where the class is and ask its bundle's loader
> to load it?
>
> Jeff
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E6A2612.7050507@aQute.se...
> > > Then guess what....: ClassCastException...
> > That is not a guess ... :-) Preventing that case is the core of the OSGi
> > Framework specification. Each bundle (JAR file) has an import/export
> > specification for classes it is willing share with other bundles. An
> > OSGi framework has a map of all packages and picks one classloader for
> > each exported package. In OSGi, only one bundle can export a designated
> > package which is shared by all. This prevents the ClassCastException
> > problem.
> >
> > Applications (bundles) can use their own classloaders if they want to
> > (and have permission in a secure system). There are no hooks to extend
> > the bundle's classloader. So you can use your own classloader in Jini
> > like scenarios. Of course you have to be careful not to mess up your own
> > package namespace, classloaders in a component like environment are
> > tricky for exactly the reason you mention.
> >
> > What scenario are you thinking of that needs a class loader, because
> > except for Jini, I have not seen it necessary so far (except for Jini).
> > Just curious.
> >
> > Kind regards,
> >
> > Peter Kriens
> >
> >
> > Pascal Rapicault wrote:
> >
> > > Questions to the specialist of classloading in OSGi:
> > >
> > > Recently, we discovered a nasty bug caused by some application
> > > creating classloaders. Here is the scenario:
> > >
> > > The antRunner (an eclipse cpt) requires Xerces (from eclipse).
> > > For short, the antRunner is the context in which all the build scripts
> > > are running, and so every script that uses xml stuffs see the same
> > > version of xerces.
> > > However we came up with a case where a build script was using
> > > a task that was creating its own classloader (not bound to the eclipse
> > > classloaders - it's one of the optional task that ant provides), and
> > > was also loading some xml classes.
> > >
> > > Then guess what....: ClassCastException...
> > >
> > > So my question now:
> > > How does OSGi handle those problems?
> > >
> > >
> > > A related question:
> > > Does OSGi provide hooks to application writer to provide their
> > > own classloaders?
> > >
> > >
> > > PaScaL
> > >
> > >
> > >
> >
>
>
|
|
|
| Re: OSGi and application creating classloaders [message #12012 is a reply to message #11987] |
Mon, 10 March 2003 07:20 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
There is no magic here ... If a bundle/dynamic does not play by the
rules, there is not much you can do except toss out that bundle ...
and/or restart. (Starting stoppoing, the offending bundle usually helps).
A bundle's class loader get unreferenced at uninstall or during a
package refresh (which usually follows an install). The VM must then
garbage collect the classes and classloader when there are no longer
references to any of its instances.
Again, the service registry concentrates the depenencies significanly
and makes the problem much easier to handle, but it doesnt go away. We
have a ServiceTracker class that does all the hard work in this area for
a bundle that wants to play by the rules.
The only alternative is to put each bundle in its own VM (see isolation
API). However that means that bundles can no longer communicate with
Java Objects, they will need copy semantics for all their parameters.
This has a serious impact in performance. Maybe the isolation API in JCP
will make this feasible?
Kind regards,
Peter Kriens
Kevin wrote:
> Along the lines of my other recent post, when unloading or reloading a
> plugin, you ideally want the "old one" to get GC'd. If any other class,
> whether in a dependency or its own set of classes, has a ref to the plugin
> lifecycle class, how do you "null out" all the refs to the plugin class, for
> that matter ALL classes in the plugin, so that they can be GC'd and their
> bytecode unloaded from memory (if their plugin classloader loaded their
> bytecode). Is there some simple way in which you can just have the
> classloader null out all of its refs to classes it loads? How do you null
> the classloader for that matter so that the whole darn thing can get tossed
> out and GC'd. I realize that a newly loaded plugin of the same name and
> classes gets its own "space" and does load without problems, and future
> calls to use that plugin all use the newly loaded one (assuming they both
> are stored via the same key in the registry of loaded plugins). Having built
> a MVC framework, I added reload abilities with classloaders, but I can't
> even guess how I know if an "old" class and its loader get thrown out. In
> the MVC framework there are no refs to anything but the HttpSession and
> sometimes context, which of course its up to any class(es) to null out those
> refs. But I am mystified as to how you can actually monitor a given class
> and its classloader and know when it is GC'd. Does the finalize() method
> work to inform us that the garbage collector is about to null out a class
> and remove it from the jvm?
>
> Thanks.
>
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b4e9uq$lns$1@rogue.oti.com...
>
>>Ant uses its own classloaders to manages the definition and use of user
>>defined "tasks". Basically users can register Java classes and give them
>>
> a
>
>>name. The ant scripts run and reference the tasks by name thus requiring
>>
> the
>
>>related classes to be loaded. The Ant framework itself has no prior
>>knowledge of the user-defined tasks so it creates a classloader and allows
>>tasks definers to add their code to the classpath. When the Ant script is
>>finished running, the classloader is thrown away and hopefully GC'd along
>>with all the loaded classes.
>>
>>What actually happens in Eclipse is we create a special Ant classloader
>>which does the normal classloading and then consults the classloaders of
>>
> all
>
>>the plugins which provided Ant task definitions.
>>
>>Under OSGi,
>>
>>- if the task classes/packages were exported, could the Ant bundle
>>dynamically add an import for a discovered task so the class could be
>>loaded? If it could, could the import be later removed when the script is
>>no longer running? would removal even be needed?
>>
>>- often times the classes registered as tasks are not API and so should
>>
> not
>
>>be exported (depending on your view of "export" semantics). Is there some
>>way we could still discover where the class is and ask its bundle's loader
>>to load it?
>>
>>Jeff
>>
>>"pkriens" <Peter.Kriens@aQute.se> wrote in message
>>news:3E6A2612.7050507@aQute.se...
>>
>>>>Then guess what....: ClassCastException...
>>>>
>>>That is not a guess ... :-) Preventing that case is the core of the OSGi
>>>Framework specification. Each bundle (JAR file) has an import/export
>>>specification for classes it is willing share with other bundles. An
>>>OSGi framework has a map of all packages and picks one classloader for
>>>each exported package. In OSGi, only one bundle can export a designated
>>>package which is shared by all. This prevents the ClassCastException
>>>problem.
>>>
>>>Applications (bundles) can use their own classloaders if they want to
>>>(and have permission in a secure system). There are no hooks to extend
>>>the bundle's classloader. So you can use your own classloader in Jini
>>>like scenarios. Of course you have to be careful not to mess up your own
>>>package namespace, classloaders in a component like environment are
>>>tricky for exactly the reason you mention.
>>>
>>>What scenario are you thinking of that needs a class loader, because
>>>except for Jini, I have not seen it necessary so far (except for Jini).
>>>Just curious.
>>>
>>>Kind regards,
>>>
>>>Peter Kriens
>>>
>>>
>>>Pascal Rapicault wrote:
>>>
>>>
>>>>Questions to the specialist of classloading in OSGi:
>>>>
>>>>Recently, we discovered a nasty bug caused by some application
>>>>creating classloaders. Here is the scenario:
>>>>
>>>>The antRunner (an eclipse cpt) requires Xerces (from eclipse).
>>>>For short, the antRunner is the context in which all the build scripts
>>>>are running, and so every script that uses xml stuffs see the same
>>>>version of xerces.
>>>>However we came up with a case where a build script was using
>>>>a task that was creating its own classloader (not bound to the eclipse
>>>>classloaders - it's one of the optional task that ant provides), and
>>>>was also loading some xml classes.
>>>>
>>>>Then guess what....: ClassCastException...
>>>>
>>>>So my question now:
>>>> How does OSGi handle those problems?
>>>>
>>>>
>>>>A related question:
>>>> Does OSGi provide hooks to application writer to provide their
>>>> own classloaders?
>>>>
>>>>
>>>> PaScaL
>>>>
>>>>
>>>>
>>>>
>>
>
>
|
|
|
| Re: OSGi and application creating classloaders [message #12038 is a reply to message #12012] |
Mon, 10 March 2003 14:26 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Peter,
You are right, OSGi helps but the problem does not go away.
There is no way in current JVM to actually null-out reference
to classes or objects within a class loader space. This is it.
Some of the other systems that got mentioned here in the
newsgroup have proxied references... this is the only way
to achieve a cut... but with the usual overhead to method
invocation and the quite thorny management of those
proxy object, avoiding leaks of raw references.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E6C3CC3.8050605@aQute.se...
> There is no magic here ... If a bundle/dynamic does not play by the
> rules, there is not much you can do except toss out that bundle ...
> and/or restart. (Starting stoppoing, the offending bundle usually helps).
>
> A bundle's class loader get unreferenced at uninstall or during a
> package refresh (which usually follows an install). The VM must then
> garbage collect the classes and classloader when there are no longer
> references to any of its instances.
>
> Again, the service registry concentrates the depenencies significanly
> and makes the problem much easier to handle, but it doesnt go away. We
> have a ServiceTracker class that does all the hard work in this area for
> a bundle that wants to play by the rules.
>
> The only alternative is to put each bundle in its own VM (see isolation
> API). However that means that bundles can no longer communicate with
> Java Objects, they will need copy semantics for all their parameters.
> This has a serious impact in performance. Maybe the isolation API in JCP
> will make this feasible?
>
> Kind regards,
>
> Peter Kriens
>
>
> Kevin wrote:
>
> > Along the lines of my other recent post, when unloading or reloading a
> > plugin, you ideally want the "old one" to get GC'd. If any other class,
> > whether in a dependency or its own set of classes, has a ref to the
plugin
> > lifecycle class, how do you "null out" all the refs to the plugin class,
for
> > that matter ALL classes in the plugin, so that they can be GC'd and
their
> > bytecode unloaded from memory (if their plugin classloader loaded their
> > bytecode). Is there some simple way in which you can just have the
> > classloader null out all of its refs to classes it loads? How do you
null
> > the classloader for that matter so that the whole darn thing can get
tossed
> > out and GC'd. I realize that a newly loaded plugin of the same name and
> > classes gets its own "space" and does load without problems, and future
> > calls to use that plugin all use the newly loaded one (assuming they
both
> > are stored via the same key in the registry of loaded plugins). Having
built
> > a MVC framework, I added reload abilities with classloaders, but I can't
> > even guess how I know if an "old" class and its loader get thrown out.
In
> > the MVC framework there are no refs to anything but the HttpSession and
> > sometimes context, which of course its up to any class(es) to null out
those
> > refs. But I am mystified as to how you can actually monitor a given
class
> > and its classloader and know when it is GC'd. Does the finalize() method
> > work to inform us that the garbage collector is about to null out a
class
> > and remove it from the jvm?
> >
> > Thanks.
> >
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:b4e9uq$lns$1@rogue.oti.com...
> >
> >>Ant uses its own classloaders to manages the definition and use of user
> >>defined "tasks". Basically users can register Java classes and give
them
> >>
> > a
> >
> >>name. The ant scripts run and reference the tasks by name thus requiring
> >>
> > the
> >
> >>related classes to be loaded. The Ant framework itself has no prior
> >>knowledge of the user-defined tasks so it creates a classloader and
allows
> >>tasks definers to add their code to the classpath. When the Ant script
is
> >>finished running, the classloader is thrown away and hopefully GC'd
along
> >>with all the loaded classes.
> >>
> >>What actually happens in Eclipse is we create a special Ant classloader
> >>which does the normal classloading and then consults the classloaders of
> >>
> > all
> >
> >>the plugins which provided Ant task definitions.
> >>
> >>Under OSGi,
> >>
> >>- if the task classes/packages were exported, could the Ant bundle
> >>dynamically add an import for a discovered task so the class could be
> >>loaded? If it could, could the import be later removed when the script
is
> >>no longer running? would removal even be needed?
> >>
> >>- often times the classes registered as tasks are not API and so should
> >>
> > not
> >
> >>be exported (depending on your view of "export" semantics). Is there
some
> >>way we could still discover where the class is and ask its bundle's
loader
> >>to load it?
> >>
> >>Jeff
> >>
> >>"pkriens" <Peter.Kriens@aQute.se> wrote in message
> >>news:3E6A2612.7050507@aQute.se...
> >>
> >>>>Then guess what....: ClassCastException...
> >>>>
> >>>That is not a guess ... :-) Preventing that case is the core of the
OSGi
> >>>Framework specification. Each bundle (JAR file) has an import/export
> >>>specification for classes it is willing share with other bundles. An
> >>>OSGi framework has a map of all packages and picks one classloader for
> >>>each exported package. In OSGi, only one bundle can export a designated
> >>>package which is shared by all. This prevents the ClassCastException
> >>>problem.
> >>>
> >>>Applications (bundles) can use their own classloaders if they want to
> >>>(and have permission in a secure system). There are no hooks to extend
> >>>the bundle's classloader. So you can use your own classloader in Jini
> >>>like scenarios. Of course you have to be careful not to mess up your
own
> >>>package namespace, classloaders in a component like environment are
> >>>tricky for exactly the reason you mention.
> >>>
> >>>What scenario are you thinking of that needs a class loader, because
> >>>except for Jini, I have not seen it necessary so far (except for Jini).
> >>>Just curious.
> >>>
> >>>Kind regards,
> >>>
> >>>Peter Kriens
> >>>
> >>>
> >>>Pascal Rapicault wrote:
> >>>
> >>>
> >>>>Questions to the specialist of classloading in OSGi:
> >>>>
> >>>>Recently, we discovered a nasty bug caused by some application
> >>>>creating classloaders. Here is the scenario:
> >>>>
> >>>>The antRunner (an eclipse cpt) requires Xerces (from eclipse).
> >>>>For short, the antRunner is the context in which all the build scripts
> >>>>are running, and so every script that uses xml stuffs see the same
> >>>>version of xerces.
> >>>>However we came up with a case where a build script was using
> >>>>a task that was creating its own classloader (not bound to the eclipse
> >>>>classloaders - it's one of the optional task that ant provides), and
> >>>>was also loading some xml classes.
> >>>>
> >>>>Then guess what....: ClassCastException...
> >>>>
> >>>>So my question now:
> >>>> How does OSGi handle those problems?
> >>>>
> >>>>
> >>>>A related question:
> >>>> Does OSGi provide hooks to application writer to provide their
> >>>> own classloaders?
> >>>>
> >>>>
> >>>> PaScaL
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
> >
>
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 07:00:47 GMT 2024
Powered by FUDForum. Page generated in 0.04169 seconds |
] 
Search
Help
Register
Login
Home
