Re: OFBiz shell
Hello Taher, Taher Alkhateeb writes: > On a quick review of the code, and given that we're populating the > class loader of current thread, can we ensure clean termination of > shells? This work is experimental, so be prepared to ruff edges. :-) I didn't thought about the implications of using the current thread class loader. What kind of scenario of non-clean termination of shells have you in mind? Thanks for your comment. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: OFBiz shell
+1, very cool idea. A proper review of the code might be in order. On a quick review of the code, and given that we're populating the class loader of current thread, can we ensure clean termination of shells? On Sat, Jan 12, 2019 at 9:14 PM Mathieu Lirzin wrote: > > Hello, > > One issue with the current way of writing Groovy tests is that the > feedback between writing an instruction and checking its result is slow > because one has to rerun the corresponding test case. > > Providing a Groovy shell access with a delegator and dispatcher allows > developers to interactively execute commands and check their results > instantly. > > I have implemented such feature in OFBIZ-10805 [1] which might be > interested to follow/review for those who care about interactive > development. > > Thanks. > > [1] https://issues.apache.org/jira/browse/OFBIZ-10805 > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: git commit workflow for ofbiz
It's awesome to revive this discussion Michael. +1 of course. We need to think practically of our workflows though and whether we want a linear vs non-linear history model. I prefer the latter to allow proper decentralized workflows but it's up to everyone here to decide. I think the overall process is described thoroughly and we can adhere to it for the most part. On Sat, Jan 12, 2019 at 9:35 PM Deepak Dixit wrote: > > We are using git since long and it's a great tool for collaboration. > It has distributed version control system so you don't need an internet > connection to view history and branch switching. > > Thanks Taher for nicly describing it. > > +1 for Git. > > Thanks & Regards > -- > Deepak Dixit > > > > On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma < > aditya.sha...@hotwaxsystems.com> wrote: > > > +1 for Git > > > > Thanks and Regards, > > Aditya Sharma > > > > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana > wrote: > > > > > +1 to move from SVN to Git. > > > > > > -- > > > Best Regards, > > > Suraj Khurana > > > Technical Consultant > > > > > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin < > > mathieu.lir...@nereide.fr> > > > wrote: > > > > > > > Hello Michael, > > > > > > > > Michael Brohl writes: > > > > > > > > > I'd like to revive this discussion again. > > > > > > > > Do we still need to discuss it? If the response is not obviously “yes > > > > we should move to Git” now that Git has become ubiquitous and that SVN > > > > is a moribund tool, then this community has a serious problem. :-) > > > > > > > > Joke aside I think the question should rather be: > > > > > > > >Is there anyone here opposing to the move from SVN to Git? > > > > > > > > Thanks for reviving this topic! > > > > > > > > -- > > > > Mathieu Lirzin > > > > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > > > > > > > > >
Re: git commit workflow for ofbiz
We are using git since long and it's a great tool for collaboration. It has distributed version control system so you don't need an internet connection to view history and branch switching. Thanks Taher for nicly describing it. +1 for Git. Thanks & Regards -- Deepak Dixit On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma < aditya.sha...@hotwaxsystems.com> wrote: > +1 for Git > > Thanks and Regards, > Aditya Sharma > > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana wrote: > > > +1 to move from SVN to Git. > > > > -- > > Best Regards, > > Suraj Khurana > > Technical Consultant > > > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin < > mathieu.lir...@nereide.fr> > > wrote: > > > > > Hello Michael, > > > > > > Michael Brohl writes: > > > > > > > I'd like to revive this discussion again. > > > > > > Do we still need to discuss it? If the response is not obviously “yes > > > we should move to Git” now that Git has become ubiquitous and that SVN > > > is a moribund tool, then this community has a serious problem. :-) > > > > > > Joke aside I think the question should rather be: > > > > > >Is there anyone here opposing to the move from SVN to Git? > > > > > > Thanks for reviving this topic! > > > > > > -- > > > Mathieu Lirzin > > > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > > > > > >
Re: git commit workflow for ofbiz
+1 for Git Thanks and Regards, Aditya Sharma On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana +1 to move from SVN to Git. > > -- > Best Regards, > Suraj Khurana > Technical Consultant > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin > wrote: > > > Hello Michael, > > > > Michael Brohl writes: > > > > > I'd like to revive this discussion again. > > > > Do we still need to discuss it? If the response is not obviously “yes > > we should move to Git” now that Git has become ubiquitous and that SVN > > is a moribund tool, then this community has a serious problem. :-) > > > > Joke aside I think the question should rather be: > > > >Is there anyone here opposing to the move from SVN to Git? > > > > Thanks for reviving this topic! > > > > -- > > Mathieu Lirzin > > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > > >
OFBiz shell
Hello, One issue with the current way of writing Groovy tests is that the feedback between writing an instruction and checking its result is slow because one has to rerun the corresponding test case. Providing a Groovy shell access with a delegator and dispatcher allows developers to interactively execute commands and check their results instantly. I have implemented such feature in OFBIZ-10805 [1] which might be interested to follow/review for those who care about interactive development. Thanks. [1] https://issues.apache.org/jira/browse/OFBIZ-10805 -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: git commit workflow for ofbiz
+1 to move from SVN to Git. -- Best Regards, Suraj Khurana Technical Consultant On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin wrote: > Hello Michael, > > Michael Brohl writes: > > > I'd like to revive this discussion again. > > Do we still need to discuss it? If the response is not obviously “yes > we should move to Git” now that Git has become ubiquitous and that SVN > is a moribund tool, then this community has a serious problem. :-) > > Joke aside I think the question should rather be: > >Is there anyone here opposing to the move from SVN to Git? > > Thanks for reviving this topic! > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 >
Re: git commit workflow for ofbiz
Hello Michael, Michael Brohl writes: > I'd like to revive this discussion again. Do we still need to discuss it? If the response is not obviously “yes we should move to Git” now that Git has become ubiquitous and that SVN is a moribund tool, then this community has a serious problem. :-) Joke aside I think the question should rather be: Is there anyone here opposing to the move from SVN to Git? Thanks for reviving this topic! -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: svn propchange: r1850648 - svn:log
Not sure why the automatic backport script derailed (I guess I was too demanding to Windows). I checked there are no other cases Le 12/01/2019 à 14:11, jler...@apache.org a écrit : Author: jleroux Revision: 1850648 Modified property: svn:log Modified: svn:log at Sat Jan 12 13:11:04 2019 -- --- svn:log (original) +++ svn:log Sat Jan 12 13:11:04 2019 @@ -1 +1,16 @@ -"Applied fix from trunk for revision: " +"Applied fix from trunk for revision: 1850647" + +r1850647 | jleroux | 2019-01-07 15:46:50 +0100 (lun. 07 janv. 2019) | 11 lignes + +Improved: Update Apache commons-fileupload to last version +(OFBIZ-10770) + +This is an easy doing, we just need to add + +compile 'commons-fileupload:commons-fileupload:1.3-3' + +to the build.gradle file. + +So far the dependency was not given directly but by other dependencies + +
Re: git commit workflow for ofbiz
Use Git !!! 😃😃😃 On Sat, 12 Jan 2019 at 11:01 pm, Michael Brohl wrote: > Hi all, > > I'd like to revive this discussion again. > > Personally, I am now working with git for a few years and almost all > customer and company related projects have moved to git over time. In > the beginning, I found git complicated and less straight forward, a bit > like Adrian mentioned in [1]. But once I have understood the main > principles and get used to it, I won't like to switch back to svn ever > since. > > In my opinion, using git would make things much easier for > collaboration. Taher thoroughly described them in the inital thread > message. > > An important point for me would be that we could prevent premature > commits just to get things to be tested. Features which take some time > to be worked on or tested can be in separate branches which can be > updated with the main branch constantly. > > So, from my point of view, we should again have a disussion and/or vote > to see if the overall opinions have changed and if we could move to git. > > Thanks, > > Michael > > > [1] http://markmail.org/message/m4z5b5qevqx7n6u7 > > Am 24.10.15 um 10:23 schrieb Taher Alkhateeb: > > Hello Everyone, > > > > I refer to the discussion about moving to git initiated by Hans Bakker > back in April. After a long, long discussion followed by a vote the > community agreed that we should develop a more elaborate and formal > workflow to vote on, as the initial vote was not detailed enough. Based on > that, I have proposed a workflow to see if people are interested in it. But > the topic just slowly died out. > > > > The links to both threads are listed below. I understand that there was > a lot of interest in the community as the thread was really long. I would > like to revive the discussion and see if people are still interested in > implementing / amending the proposed workflow if they find it appealing. > > > > discussion and vote thread : > http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev&page=1 > > > > workflow proposition thread : > http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow > > > > Taher Alkhateeb > > - Original Message - > > > > From: "Taher Alkhateeb" > > To: dev@ofbiz.apache.org > > Sent: Wednesday, 24 June, 2015 5:25:31 PM > > Subject: Re: git commit workflow for ofbiz > > > > > > Hi Jacques, > > > > Very good read, thank you for sharing. > > > > The person who wrote complaining about gitflow (I think Adam Ruka) makes > a good point. He prefers linear to branched history. I do not mind branched > history myself as I know how to navigate it but to each his own. Either > way, The workflow can be accomplished the way he suggested by rebasing > rather than merging the history and making a few other changes like > dropping "develop". It is up to community to decide, and git is flexible > enough to accommodate any model. > > > > Taher Alkhateeb > > > > - Original Message - > > > > From: "Jacques Le Roux" > > To: dev@ofbiz.apache.org > > Sent: Wednesday, 24 June, 2015 4:19:42 PM > > Subject: Re: git commit workflow for ofbiz > > > > Le 24/06/2015 14:06, Jacques Le Roux a écrit : > >> If you get a chance to read these articles I highly recommend them > >> > >> > http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/ > > Of course don't miss > http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/ > > > > Jacques > > > >> http://endoflineblog.com/gitflow-considered-harmful > >> http://endoflineblog.com/follow-up-to-gitflow-considered-harmful > >> > >> Jacques > >> > >> > >> Le 12/05/2015 19:28, Adam Heath a écrit : > >>> Nice. This is quite thorough. There is an option missing. SVN > committers who use git offline. In this case, their changes can be > published as > >>> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and > as an SVN branch, for an example. > >>> > >>> I've read through most of what follows, and am in agreement, but I'm > dealing with hardware problems, so I need to let it sink in first. > >>> > >>> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: > Hi everyone, > > This email refers to the thread for voting to move to git (link at > bottom) in which the vote decision was to delay and elaborate on the > workflow > first. I am not well versed in ASF guidelines and appreciate any help > and feedback and also please note some of the below is my opinion and not > necessarily 100% factual. > > ## First, identified problems > > 1. patches can quickly be outdated if not applied quickly > 2. big patches are hard to audit and not desired nor preferred and It > is hard to break big patches to smaller ones because if any of those patches > is outdated or modified then everything needs to be re-patched > 3. to collaborate with other people (non-committers) freely on big > features
Re: git commit workflow for ofbiz
Hi all, I'd like to revive this discussion again. Personally, I am now working with git for a few years and almost all customer and company related projects have moved to git over time. In the beginning, I found git complicated and less straight forward, a bit like Adrian mentioned in [1]. But once I have understood the main principles and get used to it, I won't like to switch back to svn ever since. In my opinion, using git would make things much easier for collaboration. Taher thoroughly described them in the inital thread message. An important point for me would be that we could prevent premature commits just to get things to be tested. Features which take some time to be worked on or tested can be in separate branches which can be updated with the main branch constantly. So, from my point of view, we should again have a disussion and/or vote to see if the overall opinions have changed and if we could move to git. Thanks, Michael [1] http://markmail.org/message/m4z5b5qevqx7n6u7 Am 24.10.15 um 10:23 schrieb Taher Alkhateeb: Hello Everyone, I refer to the discussion about moving to git initiated by Hans Bakker back in April. After a long, long discussion followed by a vote the community agreed that we should develop a more elaborate and formal workflow to vote on, as the initial vote was not detailed enough. Based on that, I have proposed a workflow to see if people are interested in it. But the topic just slowly died out. The links to both threads are listed below. I understand that there was a lot of interest in the community as the thread was really long. I would like to revive the discussion and see if people are still interested in implementing / amending the proposed workflow if they find it appealing. discussion and vote thread : http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev&page=1 workflow proposition thread : http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow Taher Alkhateeb - Original Message - From: "Taher Alkhateeb" To: dev@ofbiz.apache.org Sent: Wednesday, 24 June, 2015 5:25:31 PM Subject: Re: git commit workflow for ofbiz Hi Jacques, Very good read, thank you for sharing. The person who wrote complaining about gitflow (I think Adam Ruka) makes a good point. He prefers linear to branched history. I do not mind branched history myself as I know how to navigate it but to each his own. Either way, The workflow can be accomplished the way he suggested by rebasing rather than merging the history and making a few other changes like dropping "develop". It is up to community to decide, and git is flexible enough to accommodate any model. Taher Alkhateeb - Original Message - From: "Jacques Le Roux" To: dev@ofbiz.apache.org Sent: Wednesday, 24 June, 2015 4:19:42 PM Subject: Re: git commit workflow for ofbiz Le 24/06/2015 14:06, Jacques Le Roux a écrit : If you get a chance to read these articles I highly recommend them http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/ Of course don't miss http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/ Jacques http://endoflineblog.com/gitflow-considered-harmful http://endoflineblog.com/follow-up-to-gitflow-considered-harmful Jacques Le 12/05/2015 19:28, Adam Heath a écrit : Nice. This is quite thorough. There is an option missing. SVN committers who use git offline. In this case, their changes can be published as primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and as an SVN branch, for an example. I've read through most of what follows, and am in agreement, but I'm dealing with hardware problems, so I need to let it sink in first. On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: Hi everyone, This email refers to the thread for voting to move to git (link at bottom) in which the vote decision was to delay and elaborate on the workflow first. I am not well versed in ASF guidelines and appreciate any help and feedback and also please note some of the below is my opinion and not necessarily 100% factual. ## First, identified problems 1. patches can quickly be outdated if not applied quickly 2. big patches are hard to audit and not desired nor preferred and It is hard to break big patches to smaller ones because if any of those patches is outdated or modified then everything needs to be re-patched 3. to collaborate with other people (non-committers) freely on big features, we need a separate branch. On svn this is lengthy and heavily controlled. If we create a git repository then we need to constantly update from svn and merge . Another solution is to clone the ofbiz read-only git repository but then there are some patch issues to convert them to clean svn patches (I faced a few including things like white space) 4. a lot of _local_ offline freedom to branch, merge, commit, share and experiment cann
Re: Session timeout for webapps
Done, thanks Deepak Jacques Le 12/01/2019 à 07:24, Deepak Nigam a écrit : Hi Jacques, On double checking, I found that /applications/marketing/webapp/marketing/WEB-INF/web.xml and /applications/party/webapp/partymgr/WEB-INF/web.xml files have been missed. Apart from that, I think we need to work for web.xml of various plugins also. Thanks & Regards -- Deepak Nigam HotWax Systems Pvt. Ltd On Fri, Jan 11, 2019 at 9:58 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi Guys, Done, please double-check that I have not missed a web.xml files Thanks Jacques Le 11/01/2019 à 11:34, Jacques Le Roux a écrit : Thanks Guys, I'll do this afternoon using OFBIZ-6655 Jacques Le 11/01/2019 à 07:03, Deepak Nigam a écrit : Thanks, Jacques and Girish. Yes, it makes sense to get back to web.xml for the session timeout value. On Fri, Jan 11, 2019 at 11:13 AM Girish Vasmatkar < girish.vasmat...@hotwaxsystems.com> wrote: Hi Jacques Yes, we should put back the session timeout declaration in web.xml. Given the fact that we can always mix web.xml and Annotation based configuration, it only makes sense to let web.xml decide the session timeout and even if we have the session listener (via web.xml declaration or Annotation), we should not programatically try to override the setting. Thanks and Regards, Girish On Thu, Jan 10, 2019 at 7:14 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi Deepak, Girish, I had a look at the issue. The specifications of Java Servlet Specification 3.0 don't include an annotation to change the session time out. https://www.baeldung.com/servlet-session-timeout https://stackoverflow.com/questions/20389833/session-timeout-config-with-no-web-xml-file I think the best solution is to put back what we had before, ie set it to a value (it was 1 hour before) in all web.xml file and remove the session.setMaxInactiveInterval(60*60); //in seconds line in ControlEventListener::sessionCreated I thought about keeping this line if a check to null for the session timeout value (from web.xml) was positive. But by default Tomcat sets it to 30 min (so it's never null) and it's possible but hard to change in OFBiz (eg to a known specific extraordinary value that could be checked instead of null as above) So it could be confusing and anyway best practice is to prefer convention over configuration, even if in this case it's much redundant. I think we can reopen OFBIZ-6655 and handle it there, with an explanation. Other ideas? Jacques Le 09/01/2019 à 10:11, Girish Vasmatkar a écrit : Hi Deepak By the time sessionCreated is called in an HttpSessionListener, the session has already been created. I am sure if you try to get the HttpSession from the HttpSessionEvent object, it will have what you defined in tag. But the code is overriding the timeout using setMaxInactiveInterval to 1 hour that is why it is looking like web.xml is not being given precedence over programmatic session configuration. Whether web.xml takes precedence over annotation does not apply in this case because anyway the session timeout value is being overridden by the code. The tomcat container definitely reads session-timeout from web.xml and assigns timeout for the session accordingly. But since a listener is configured for session lifecycle management, it invokes the method and there the session value is being overridden. Try to set 2 minutes session timeout in web.xml and remove session.setMaxInactiveInterval(60*60). I would say you will be logged out after 2 minutes. If that is not the case, pl let me know. I hope I understood your question and problem correctly. Best, Girish On Wed, Jan 9, 2019 at 1:53 PM Deepak Nigam < deepak.nigam1...@gmail.com> wrote: Thanks, Jacques. Apart from the hardcoded thing, I am not able to override the session timeout value using tag in web.xml. On Tue, Jan 8, 2019 at 1:55 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi Deepak, You are right, it's hardcoded and should not. I have no time to go further at the moment, but I'll ASAP Thanks Jacques Le 08/01/2019 à 06:10, Deepak Nigam a écrit : Hello all, I tried to set the session timeout for the 'ecommerce' and the 'webtools' components using of web.xml, but unable to do so. Session for the logged-in user remains active even after the set time. On further research, I found that we did some changes in this area in the ticket OFBIZ-6655 < https://issues.apache.org/jira/browse/OFBIZ-6655 . We have hard coded the session timeout (1 hr) in the sessionCreated() method of ControlEventListner class. As per the comments in the Jira ticket, session timeout declarations in web.xml have been removed by the use of @WebListner annotation. This is to avoid duplicates things everywhere in web.xml files. Since the web.xml files have precedence on annotations, the setting can be easily overridden when necessary. But the
