| extending eclipse class loaders [message #45653] |
Tue, 21 September 2004 08:52  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.com
hi,
there have been some older postings that might cover the same
topic, but those guys seemed to already have a better understanding
of eclipse class loading. my understanding is more basic...
does anybody know, if it is possible to change the class
that is used as plugin classloader, either for all plugins or
better for certain plugins?
i don't want to change the loader-hierarchy or the strategy.
it would be great, to substitute a classloader, that is, for
example, able to load encrypted jars to enforce a license...
cheers
/eike
|
|
|
| Re: extending eclipse class loaders [message #45684 is a reply to message #45653] |
Tue, 21 September 2004 20:57  |
 Martin Lippert
Messages: 124
Registered: July 2009 |
Senior Member |
|
|
Hi,
the new OSGi-based runtime and its adoption in Eclipse 3.0 indeed allows
you to do that. I did this to integrate load-time bytecode modification
into the runtime (for load-time aspect weaving).
What you need to do is:
- Implement your own framework adaptor for example as a subclass of
org.eclipse.core.runtime.adaptor.EclipseAdaptor. Using your subclass you
can override "getElementFactory" to return a specialized factory for
framework elements. This specialized element factory can, for example,
subclass org.eclipse.core.runtime.adaptor.EclipseElementFactory and
override the method "createClassLoader". This method is used by the
runtime to create class loaders for bundles (plugins). You can get
information about the bundle for which the class loader should be
created from the parameters of that method (if you would like to create
different kinds of class loaders for different bunldes/plugins).
- You can implement your specialized class loader as a subclass of
org.eclipse.core.runtime.adaptor.EclipseClassLoader (by overriding
"findClassImpl").
- Now you need tell your runtime to use your specialized adaptor instead
of the EclipseAdaptor and your plugin (that contains your specialized
class loader and your specialized framework adaptor) needs to provide a
spezialized ADAPTOR.MF file. You can find many interesting information
on this in the comments of this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=48695
Hope this helps to provide a first insight.
If you want to take a look at an example you can download the current
release candidate of AJEER (AspectJ-Enabled Eclipse Runtime) from my
website (http://www.martinlippert.com). Take a look at the
org.eclipse.transformer plugin. There you should find everything you
need to get a first impression. (The current version works well with M9
and with some modified startup options also with R3.0. Haven't put up
the newest version yet.)
Let me know if you need more help with this.
Best regards,
Martin
Eike Stepper wrote:
> hi,
>
> there have been some older postings that might cover the same
> topic, but those guys seemed to already have a better understanding
> of eclipse class loading. my understanding is more basic...
>
> does anybody know, if it is possible to change the class
> that is used as plugin classloader, either for all plugins or
> better for certain plugins?
>
> i don't want to change the loader-hierarchy or the strategy.
> it would be great, to substitute a classloader, that is, for
> example, able to load encrypted jars to enforce a license...
>
> cheers
> /eike
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.85058 seconds
] 
Search
Help
Register
Login
Home
