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 <
jacopo.cappell...@hotwaxsystems.com> 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 <
jacques.le.r...@les7arts.com> 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 <
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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
