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 <
[email protected]> 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
>
>
