Custom ClassLoader in OFBiz

[taher]

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

[Jacques Le Roux]

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

[taher]

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

[Sharan-F]

Hi Taher

The main thing that jumped out at me  is that if OSGi is something that can fix “many” of our existing problems and can make a real difference  to simplify how we can deploy things – then I think it would be good to to at least look at how it could fit.

It sounds like we have a potential opportunity here so let's have the technical discussion about whether it makes sense and if so, how it could possibly work.

Thanks
Sharan

[Jacques Le Roux]

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

[Jacopo Cappellato-5]

Hi Taher,

as mentioned in previous posts by Jacques and you, yes the custom
classloader was introduced to provide the ability to load jar files added
to the Java class path after OFBiz starts.
This feature is actually one that we could drop to simplify our codebase:
no out of the box code is using it or has ever used it and I have never
heard of any users actually using it or asking about it.
In fact, as you mentioned, if in the future this requirement will be
needed, there are more elegant ways to implement it.

I hope it helps,

Jacopo

On Mon, May 30, 2016 at 10:14 AM, Jacques Le Roux <
[hidden email]> wrote:

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

[taher]

Hi Jacopo,

Great thank you! Two of the best inventions in the world are "delete" and
"backspace". I'll put them to good use.

Even adding something like OSGi is a lot easier "after" removing all the
dead bits. So I’ll pull out my axe and start hacking away. As usual, I'll
put the attachments in JIRA before committing to make sure everyone is
aligned on this.

Regards,

Taher Alkhateeb

On Mon, May 30, 2016 at 1:00 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Hi Taher,
>
> as mentioned in previous posts by Jacques and you, yes the custom
> classloader was introduced to provide the ability to load jar files added
> to the Java class path after OFBiz starts.
> This feature is actually one that we could drop to simplify our codebase:
> no out of the box code is using it or has ever used it and I have never
> heard of any users actually using it or asking about it.
> In fact, as you mentioned, if in the future this requirement will be
> needed, there are more elegant ways to implement it.
>
> I hope it helps,
>
> Jacopo
>
> On Mon, May 30, 2016 at 10:14 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > 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 <
> >> [hidden email]> 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
> >>>
> >>>
> >>>
> >
>

[Ron Wheeler]

Good work.
Everything should be made as simple as possible, but not simpler.

http://quoteinvestigator.com/2011/05/13/einstein-simple/

Ron
On 30/05/2016 10:49 AM, Taher Alkhateeb wrote:

> Hi Jacopo,
>
> Great thank you! Two of the best inventions in the world are "delete" and
> "backspace". I'll put them to good use.
>
> Even adding something like OSGi is a lot easier "after" removing all the
> dead bits. So I’ll pull out my axe and start hacking away. As usual, I'll
> put the attachments in JIRA before committing to make sure everyone is
> aligned on this.
>
> Regards,
>
> Taher Alkhateeb
>
> On Mon, May 30, 2016 at 1:00 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Hi Taher,
>>
>> as mentioned in previous posts by Jacques and you, yes the custom
>> classloader was introduced to provide the ability to load jar files added
>> to the Java class path after OFBiz starts.
>> This feature is actually one that we could drop to simplify our codebase:
>> no out of the box code is using it or has ever used it and I have never
>> heard of any users actually using it or asking about it.
>> In fact, as you mentioned, if in the future this requirement will be
>> needed, there are more elegant ways to implement it.
>>
>> I hope it helps,
>>
>> Jacopo
>>
>> On Mon, May 30, 2016 at 10:14 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> 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 <
>>>> [hidden email]> 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
>>>>>
>>>>>
>>>>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102