| Custom priority ClassLoader extention ? [message #74151] |
Sat, 07 October 2006 11:50  |
Eclipse User |
|
|
|
What is involved in providing an Equinox extension to allow a plugin to
provide its own ClassLoader implementation has higher precedence than
the default class loader.
Obviously it would be necessary to provide two piece of data in the
MANIFEST.MF, the location of where the custom ClassLoader implementation
(and its supporting classes) can be found and the name of the class.
Bundle-ClassLoader: classloader.jar!com.enterprise.MyClassLoaderImpl;
priority="first"
The reason for this request is that the ATF project are already forcing
the issue to allow loading of the correct JAR file from the xulrunner
distribution location.
The xulrunner project already provides two compatible counterpart JAR
files as part of an xulrunner installation. It would be less
maintainence to have a single Eclipse plugin that was able to resolve
the location of the counterpart JAR files directly from within the
xulrunner installation.
At the moment it is necessary to re-release an updated version of the
Eclipse connecting plugin whenever any part of the interfaces change.
The users of extra new functionality are already doing Class.forName()
existance checking to confirm the interface class is present to make use
of for a certain feature.
Please feel free to point out any obvious holes I maybe digging for
myself with this approach.
RFC
Darryl
|
|
|
|
| Re: Custom priority ClassLoader extention ? [message #74205 is a reply to message #74187] |
Sun, 08 October 2006 07:44  |
| Eclipse User |
|
|
|
Alex Blewitt wrote:
> What are you trying to achieve by doing this? If the two Jars are compatible, what is the difference between them? How do you determine which of the two Jars to select? Could other approaches, such as having two fragments with one Jar each help solve the problem?
>
> Alex.
The Java interface JAR file for Mozilla are distributed with Xulrunner.
There is a one-to-one relationship between the JAR and xulrunner
because those JARs are built and distributed with Xulrunner so always
contain the correct feature set and interfaces that exact version of
Mozilla provides through Java.
mozilla$ find dist -name "Mozilla*.jar" -or -name "javaxpcom*jar"
../dist/sdk/lib/MozillaInterfaces.jar
../dist/sdk/lib/MozillaInterfaces-src.jar
../dist/bin/javaxpcom-src.jar
../dist/bin/javaxpcom.jar
> what is the difference between them?
Well for each successive version of Mozilla/Xulrunner the Xulrunner
developers may choose to add new interfaces that are available over Java.
The version lifecycles of the vendor provided Xulrunner package are
independant of Eclipse version lifecycles. A user may choose to upgrade
his Xulrunner from a vendor (RedHat, etc...) update.
> How do you determine which of the two Jars to select?
This is essentially the point of why a custom ClassLoader is necessary,
with Equinox as it stands it is not in a position to determine this but
a custom provided class would be.
The way the process currently works with Mozilla/Xulrunner is a mixture of:
* Utilizing $HOME/.gre.d/*.conf, /etc/gre.d/*.conf, /etc/gre*conf files
* Looking in the Windows registry for gre.conf information (on windows)
* Looking in specific configuration files (on Mac OS X)
* Utilizing environment variables MOZILLA_FIVE_HOME (in the case of
SWTs native Mozilla embeded widget)
* Automatic searching of the well known locations that popular
distributions use (/usr/lib/mozilla-*, /usr/lib64/mozilla-*, etc..)
This location process is _ALREADY_ being performed by the respective
Eclipse components.
This location process is necessary since Xulrunner is distributed
independently of Eclipse. As in Xulrunner itself is not an eclipse
plugin and a large free standing application. There are moves to
address this situation by some eclipse users (easyeclipse to name an
example). But some Linux users might object to installing two copies of
xulrunner on their system, one within eclipse and one provided by their
vendor. The easyeclipse solution makes most sense to me for users on
the windows getting functionality without installation headache.
Once the location process has completed and a valid libxpcom.{so,dll}
library has been found and loaded and native methods called upon it,
then the counterpart javaxpcom.jar and MozillaInterfaces.jar should be
picked up and used directly from the xulrunner distribution if available.
The purpose of the request/thread to get away from distributing
counterpart Java interface JAR separately from the Xulrunner
distribution as an eclipse plugin.
It would be possible to create an eclipse plugin that contributed the
JARs to the Eclipse platform by way of dynamic location resolution and
then optionally provide a fallback version from its own.
A custom class loader solution then leads into another scenario that
could be implemented as well as (I have not previously discussed in this
thread so as to not cloud the issue).
This feature request would also allow a single plugin version to
successively include fallback JAR files like:
myjavalib-1.7.12-release.jar
myjavalib-1.8.0.4-release.jar
myjavalib-1.8.1-devel.jar
In this scenario we could distribute a copy of the JAR which correctly
married up with the version of Mozilla it was working against at
runtime. So my custom ClassLoader when operating in a fallback scenario
would pick the correct JAR file to introduce to the ClassLoader.
This way version 1.8.1 of the plugin actually supports interfaces of
1.7.12 and 1.8.0.4 and 1.8.1 etc... so the user doesn't have to worry
exactly which version of Mozilla he has installed to get things working.
Any new functionality added in 1.8.1 would simply not be available
because the interface would not be available when trying to instate it
through XPCOM.
To not cloud the issue let me restate the main goal would be dynamic
resolution.
Darryl
|
|
|
|
|
|
|
|
| Re: Custom priority ClassLoader extention ? [message #74645 is a reply to message #74610] |
Tue, 10 October 2006 11:40 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
the $JDBC_HOME thing needs to be set as a system property. So you can
set it in config.ini or on the command line. I actually don't remember
when we look for the property but suspect it is when we go to actually
create the classloader. This will be, generally speaking, either when
you start the bundle or first try to load something from the bundle.
As for who is using the classloading hooks, there are several people we
have heard of but its hard to list them. Of course, we use them
ourselves to implement the Eclipse Adaptor. I believe the Aspect folks
(in the Equinox incubator) are using them as well. Various of the IBM
Eclipse based products use them to exploit classloading optimizations
available in the IBM VMs, ...
Jeff
Darryl L. Miles wrote:
> Jeff McAffer wrote:
>> I'm not sure I follow the whole issue but is section 20.4 of the
>> Eclipse RCP book (http://eclipsercp.org) of any use here? See
>> http://www.eclipse.org/orbit/documents/RCP_Chapter20.pdf
>
> Thanks for the pointer. The crux for those who have not read the PDF is
> the use of:
>
> Bundle-Classpath: external:$JDBC_HOME$/drivers/jdbc.jar
>
> This is approach is fine, but I would need to be able to set the value
> of JDBC_HOME via code, not from an inherited value since startup. I
> guess this wouldn't work as its a chicken and egg situation.
>
> This is why having my own ClassLoader attacks this problem nicely, I can
> have auto-configuration on first use, and still provide some classes to
> perform fault diagnostic on why my ClassLoader couldn't find the
> expected JAR to load.
>
>
>> Otherwise, there is a whole adaptor layer below the framework that
>> allows you to mess with classloader implementation etc. See
>> http://wiki.eclipse.org/index.php/Adaptor_Hooks
>
> Now this looks promising org.eclipse.osgi.baseadaptor.hooks for a
> Class Loading Hook, EclipseClassLoadingHook. I shall investigate some
> more this week.
>
> Any body know of an OSS project which is using it ?
>
> Darryl
|
|
|
Powered by
FUDForum. Page generated in 0.09811 seconds
Home