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