Hi Taher,
It's certainly interesting, too bad Raj and Adrian are not there to help, they
would have loved it.
Also having Java 9 modularity in the picture will help, I guess.
Jacques
Le 29/05/2016 à 14:19, Taher Alkhateeb a écrit :
Hi Jacques,
Thank you very much for the research, excellent resources indeed.
I doubt the classloader is used for something similar to tomcat. Tomcat
uses the classloader to dynamically load the webapps. In OFBiz, everything
kickstarts from the beginning and you cannot enable a component at runtime.
I actually think I get it now. It has nothing to do with dynamic loading of
the components, it's just a dynamic loading of the classpath for the
libraries that are chugging along with every component. It is this specific
code in StartupControlPanel.createClassLoader(...)
NativeLibClassLoader classloader = new
NativeLibClassLoader(classPath.getUrls(), parent);
classloader.addNativeClassPath(System.getProperty("java.library.path"));
for (File folder : classPath.getNativeFolders()) {
classloader.addNativeClassPath(folder);
}
I see a word screaming in my face right now! OSGi. Implementing something
like that means we can be 100% dynamic in loading our components, and their
dependencies can also be dynamic, and we offset all the classloading
headache.
What this means is that many of the problems we currently face in ofbiz
will go away (e.g. disabling specialpurpose components stops testing them).
This also means we put real boundaries on components and disable all
unintentional entanglements, AND it also means we can have a real "plugin"
system for the components (a user can install a new component with his
mouse!)
I don't know if I'm going crazy with this, but it seems like a fundamental
solution to the current set of dependency problems we have, and it can be
done slowly and gradually while refactoring, and most of the work is in the
Start and Base components.
I know there were attempts in the past like:
http://ofbiz.135035.n4.nabble.com/OSGi-based-OFBiz-framework-td1929599.html
and
https://sourceforge.net/projects/ofbiz-osgi/
But the implementation I'm thinking of is different in that each component
is a bundle, not the whole framework.
What do you think?
Taher Alkhateeb
On Sun, May 29, 2016 at 2:25 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 28/05/2016 à 11:57, Taher Alkhateeb a écrit :
Hi Everyone,
This is a question for advanced developers. I notice that OFBiz uses a
custom class loader called NativeLibClassLoader which extends
URLClassLoader from the JDK
There is a comment in the class which mentions that the "class is
necessary
because the bootstrap ClassLoader caches the native library path - so any
changes to the library path are ignored (changes that might have been made
by loading OFBiz components)"
I don't quite understand what is meant by that even after digging into the
related classes. It seems like the design is saying that hey, we might
load
components dynamically and therefore, we will keep their effects in this
field -> "CopyOnWriteArrayList<String> libPaths"
However, as far as I understand, ofbiz does not load libraries or
components dynamically, they either load or not on start, and you cannot
call start twice as that would shoot an exception.
I guess my question is: Why does ofbiz have a custom ClassLoader? Why
bypassing the bootstrapping loader and even then, why not use one of the
standard JDK implementations in the ClassLoader hierarchy.
I really appreciate your insights on this.
Taher Alkhateeb
Hi Taher,
As you may know this was introduced by Adrian
at http://svn.apache.org/viewvc?view=revision&revision=1676746
for https://issues.apache.org/jira/browse/OFBIZ-6268
after an effort by Jacopo at
https://issues.apache.org/jira/browse/OFBIZ-5768
Maybe this was done for something like
https://stackoverflow.com/questions/15635039/how-to-handle-shared-native-library-in-multiple-web-applications-on-tomcat
where another way of doing it in the Tomcat context is suggested
I did not dig further today, but I note this link here for myself
http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
Adrian also introduced InstrumentingClassLoader class then. It's related
with Cobertura. But as Adrian said he was unable to have it working.
HTH
Jacques
