Hi Jacques, Jacopo and everyone, I have a big patch (about 1,500 lines) that among other things deletes CommonsDaemonStart and fully refactors the Start component.
I need help in checking this patch. The system seems to be running smoothly and all tests pass on my computer. A few more eyeballs on this would help though. Thank you for your help! Taher Alkhateeb -----Original Message----- From: Jacopo Cappellato [mailto:jacopo.cappell...@hotwaxsystems.com] Sent: 17 May 2016 10:54 To: dev@ofbiz.apache.org Subject: Re: Deleting CommonsDaemonStart.java I second this approach as a general rule, if applied carefully and wisely (as it is in this specific case). By removing incomplete code, the person working on the refactoring will have a simplified system to work with in the refactoring; the removed code will always be available in the history of the revision control system and the persons interested in completing the support of the removed feature will have a chance to check the code out and refactor/complete it. Jacopo On Tue, May 10, 2016 at 7:03 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Actually this is what I think too. Adam never completed the work and > it's useless as is. Maybe he has his own usage of it, but for a reason > did not contribute it. > > Anyway, I see no problem removing it, it seems Adam and others are > also not concerned. > > Jacques > > > Le 06/05/2016 à 12:11, Taher Alkhateeb a écrit : > >> Hi Jacque, >> >> I suspect that jsvc is half-cooked and is not really implemented. You >> can't find commons-daemon-*.jar anywhere in the code base. The only >> thing that exists is CommonsDaemonStart.java which is exposing >> Start.start(), >> Start.shutdownServer() and Start.init() and is not fully implemented >> (destroy() does nothing). >> >> My objective right now is not to implement jsvc (although a good >> idea) but to clean up the code. It is really nasty to expose >> Start.java by calling >> Start.getInstance().init(args) for example. So my suggestion is, if >> no one is actually using or depending on CommonsDaemonStart.java (I >> suspect no one is using it) then we are better off deleting it. This >> makes the refactoring of Start.java much better and actually allows >> for better implementation of jsvc in the future if needed. >> >> So my recommendation for better cleaner code is to simply delete >> CommonsDaemonStart.java due to poor code and my suspicion that it is >> not used. Otherwise, I'll have to try and refactor _around_ it. Not >> sure if we should vote on this, or wait for more feedback, or just drop it? >> Appreciate >> any feedback. >> >> Taher Alkhateeb >> >> >> >> On Fri, May 6, 2016 at 11:45 AM, Jacques Le Roux < >> jacques.le.r...@les7arts.com> wrote: >> >> Hi Taher, >>> >>> Jsvc sounds like a good thing to have. So if you envision a better >>> to way to have it in OFBiz, please share in a new Jira with a ref to >>> 5710 >>> >>> Thanks >>> >>> Jacques >>> >>> >>> Le 05/05/2016 à 17:59, Taher Alkhateeb a écrit : >>> >>> Hello Everyone, >>>> >>>> So while trying to refactor Start.java, I see uglier code as I dig >>>> deeper. >>>> One of the annoying things I've seen so far is the introduction of >>>> jsvc through the class org.ofbiz.base.start.CommonsDaemonStart. >>>> >>>> The dependency from CommonsDaemonStart.java to Start.java is making >>>> the code ugly and exposed not to mention some other technical >>>> problems as discussed in >>>> https://issues.apache.org/jira/browse/OFBIZ-5710 >>>> >>>> I want to know whether the community is using this class and there >>>> is valuable use for it, or whether we can just delete it. I believe >>>> we can reintroduce jsvc in a much cleaner way in the future. >>>> >>>> Thank you in advance for your feedback. >>>> >>>> Taher Alkhateeb >>>> >>>> >>>> >
