Re: Taking a decision on remaining Jars in OFBiz

I would suggest enabling the whitelist by default, adding whatever classes OFBiz needs OOTB and then having a clear failure message in the logs when a custom class fails serialization. Would that work? Regards Scott On 6/08/2016 23:13, "Jacques Le Roux" wrote: >

[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410660#comment-15410660 ] devi sri prasad commented on OFBIZ-5522: We are all in dust world, so the clean power plan is

Re: buildbot success in on ofbiz-trunk

Okay cool. I am trying to eliminate all causes. The crash is happening exactly when trying to construct the classpath for the constructed jar. This line of code in build.gradle is what's causing the crash: osClassPath = configurations.runtime.files.collect { "$it" }.join(' ') And it is

Re: buildbot success in on ofbiz-trunk

We never used the Gradle daemon on BuildBot as it's not recommended on CI servers. There is no cache on BuildBot, it always starts anew. We always use Gradle and not the wrapper there. Also the project name was fixed at r1754623 so 35 commits before

Re: buildbot success in on ofbiz-trunk

Hi Jacques, Can you try to disable the gradle Daemon? I suspect this might be a cause as per this discussion -> http://stackoverflow.com/questions/21267234/show-utf-8-text-properly-in-gradle Taher Alkhateeb On Sat, Aug 6, 2016 at 5:50 PM, Taher Alkhateeb wrote: >

Re: buildbot success in on ofbiz-trunk

Haa, I just noticed something interesting in https://ci.apache.org/builders/ofbiz-trunk/builds/1204/steps/shell/logs/stdio If you look at the logs, ignore shiro for a second, ant note the following: > Could not resolve all dependencies for configuration ':runtime'. > Could not resolve

Re: buildbot success in on ofbiz-trunk

OK, here we go again https://ci.apache.org/builders/ofbiz-trunk/builds/1204/steps/shell/logs/stdio Anyway "wait and see" will come to an end Jacques Le 06/08/2016 à 16:08, Jacques Le Roux a écrit : OK the dependency on Shiro is fixed in jcenter :) There is no issues that "wait and see"

Re: buildbot success in on ofbiz-trunk

As you can see it crashed again. Something is probably wrong perhaps from one of the recent commits that is causing this instability as we face the same shiro issue. I'll try to investigate a bit. On Aug 6, 2016 3:08 PM, "Jacques Le Roux" wrote: > OK the dependency

buildbot exception in on ofbiz-trunk

The Buildbot has detected a build exception on builder ofbiz-trunk while building . Full details are available at: https://ci.apache.org/builders/ofbiz-trunk/builds/1204 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: lares_ubuntu Build Reason: The AnyBranchScheduler

Re: buildbot success in on ofbiz-trunk

OK the dependency on Shiro is fixed in jcenter :) There is no issues that "wait and see" can't solve :D Jacques Le 06/08/2016 à 14:19, build...@apache.org a écrit : The Buildbot has detected a restored build on builder ofbiz-trunk while building . Full details are available at:

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 6, 2016 at 12:49 PM, Taher Alkhateeb wrote: > > [...} I suggest the following: > > - remove ofbizSecure and ofbizBackgroundSecure > - make all other server tasks secure by default (i.e. loading notsoserial > and all other jvm args which are currently used

buildbot success in on ofbiz-trunk

The Buildbot has detected a restored build on builder ofbiz-trunk while building . Full details are available at: https://ci.apache.org/builders/ofbiz-trunk/builds/1203 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler

[jira] [Closed] (OFBIZ-7946) Data load error on Web Pos component due to removal of POS component

[ https://issues.apache.org/jira/browse/OFBIZ-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar closed OFBIZ-7946. --- Resolution: Fixed Fix Version/s: Upcoming Branch Committed patch at rev: 1755393 Thanks

[jira] [Assigned] (OFBIZ-7946) Data load error on Web Pos component due to removal of POS component

[ https://issues.apache.org/jira/browse/OFBIZ-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar reassigned OFBIZ-7946: --- Assignee: Arun Patidar (was: Suraj Khurana) > Data load error on Web Pos component due to

[jira] [Updated] (OFBIZ-7946) Data load error on Web Pos component due to removal of POS component

[ https://issues.apache.org/jira/browse/OFBIZ-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suraj Khurana updated OFBIZ-7946: - Attachment: OFBIZ-7946.patch Attached patch with proper fix. > Data load error on Web Pos

[jira] [Created] (OFBIZ-7946) Data load error on Web Pos component due to removal of POS component

Suraj Khurana created OFBIZ-7946: Summary: Data load error on Web Pos component due to removal of POS component Key: OFBIZ-7946 URL: https://issues.apache.org/jira/browse/OFBIZ-7946 Project: OFBiz

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, Yeah agreed. I guess I'll wait for a few days before starting a JIRA to see if people have an opinion on this. I'll also make sure to coordinate with you on buildbot Taher Alkhateeb On Aug 6, 2016 12:13 PM, "Jacques Le Roux" wrote: > I'd not be

Re: Taking a decision on remaining Jars in OFBiz

I'd not be against but we need to be clear while documenting that it's not enough for security (when needed, users need to refer to the wiki page), a white list is necessary (again only when needed, not OOTB) I guess (at least I hope for them) most sysadmin, devops are aware of the possible

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, As I referred to earlier I suggest the following: - remove ofbizSecure and ofbizBackgroundSecure - make all other server tasks secure by default (i.e. loading notsoserial and all other jvm args which are currently used in ofbizSecure). This means ofbiz, ofbizBackground and ofbizDebug

Re: Gradle loadDefault has some hiccup on BuildBot

Le 06/08/2016 à 11:47, Taher Alkhateeb a écrit : Oh, sorry if I wasn't clear, I meant java -jar does not improve the situation because your issue is remote repository. Our issue :), I agree we need to download the Internet anyway (kidding ;)) . Note though that if nothing need to be updated

Re: Taking a decision on remaining Jars in OFBiz

Le 06/08/2016 à 11:43, Taher Alkhateeb a écrit : Hi Jacques, I think that filling the white list ,etc ... might be something to keep in the page on securing OFBiz (documentation). I prefer to have a direct link to notsoserial documentation to be sure it's up to date. That's what I did on the

Re: Gradle loadDefault has some hiccup on BuildBot

Oh, sorry if I wasn't clear, I meant java -jar does not improve the situation because your issue is remote repository. So my suggestion instead of copying jars locally (I don't see a lot of difference because you have to fetch either way) is to keep them remote but fine-tune the requirements.

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, I think that filling the white list ,etc ... might be something to keep in the page on securing OFBiz (documentation). I understand your point about making it more "explicit" which makes sense, it has, however, the downside of making the users aware that there are different tasks to

Re: Gradle loadDefault has some hiccup on BuildBot

Yes that's a better to way to say it, thanks. Indeed having collected and checked (I think at OWASP dependency checker) the libs and then stored them in a specific place seems a good way to go. I don't see much differences with java -jar. Where is it easier? Jacques Le 06/08/2016 à 11:30,

Re: Gradle loadDefault has some hiccup on BuildBot

Hi Jacques, I guess then you mean you never rely on a remote repository for production, Gradle is responsible for fetching, it is the repository that matters. This is an area where fine-tuning of the selected libraries is important rather than dropping down to java -jar. Taher Alkhateeb On Sat,

Re: Gradle loadDefault has some hiccup on BuildBot

I totally agree, that's why I'll never rely on Gradle in production Jacques Le 06/08/2016 à 11:15, Taher Alkhateeb a écrit : I also checked the second log, we have an issue with one of the dependencies on Shiro. Needs a little digging through but this is an issue you'd face regardless of the

Re: Gradle loadDefault has some hiccup on BuildBot

Seems that you were too fast, see the second link please Jacques Le 06/08/2016 à 11:10, Taher Alkhateeb a écrit : Jacques, this has nothing to do with stability. Something is wrong in the configuration. The error message shows it clearly: * What went wrong: Task 'loadDefault' not found in

Re: Gradle loadDefault has some hiccup on BuildBot

I also checked the second log, we have an issue with one of the dependencies on Shiro. Needs a little digging through but this is an issue you'd face regardless of the build system as it has to do with the remote repository. On Aug 6, 2016 10:11 AM, "Taher Alkhateeb"

Re: Gradle loadDefault has some hiccup on BuildBot

I would also like to add that massive production systems are deployed on Gradle already. Our issues are familiarity, not stability. On Aug 6, 2016 10:10 AM, "Taher Alkhateeb" wrote: > Jacques, this has nothing to do with stability. Something is wrong in the >

Re: Gradle loadDefault has some hiccup on BuildBot

Jacques, this has nothing to do with stability. Something is wrong in the configuration. The error message shows it clearly: * What went wrong: Task 'loadDefault' not found in root project 'build'. On Aug 6, 2016 9:49 AM, "Jacques Le Roux" wrote: > HI, > >

[jira] [Commented] (OFBIZ-7796) Running OFBiz as a service fails

[ https://issues.apache.org/jira/browse/OFBIZ-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410557#comment-15410557 ] Jacques Le Roux commented on OFBIZ-7796: bq. It also removes: the 'kill' reference as there is no

[jira] [Comment Edited] (OFBIZ-7796) Running OFBiz as a service fails

[ https://issues.apache.org/jira/browse/OFBIZ-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410557#comment-15410557 ] Jacques Le Roux edited comment on OFBIZ-7796 at 8/6/16 9:05 AM: bq. It

[jira] [Commented] (OFBIZ-7796) Running OFBiz as a service fails

[ https://issues.apache.org/jira/browse/OFBIZ-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410556#comment-15410556 ] Jacques Le Roux commented on OFBIZ-7796: Hi Pierre, After

Gradle loadDefault has some hiccup on BuildBot

HI, https://ci.apache.org/builders/ofbiz-trunk/builds/1199/steps/shell/logs/stdio https://ci.apache.org/builders/ofbiz-trunk/builds/1201/steps/shell/logs/stdio All is OK locally (here at least), so I guess better to wait and see. Could though be that the error is everywhere, I don't want to

Re: Taking a decision on remaining Jars in OFBiz

The idea is that by default the task does not do much. You have to follow the advices they give to make it really effective (filling a white list is the better way) That's why I separated it from the rest to make it more obvious for users. Currently "gradlew tasks" gives you this information

Re: Security : seed-initial

Thanks for the suggestion Scott, I think it's enough indeed, done at revision: 1755390 Jacques Le 06/08/2016 à 00:56, Scott Gray a écrit : It's demo data, what's wrong with it using the demo reader? Any number of issues can arise when you modify demo data in the database and then reload it.

Re: Taking a decision on remaining Jars in OFBiz

Hi Scott, Great idea! We would reduce the number of tasks for one thing (less is more). I doubt the notsoserial lib has any effect on performance, It just makes a few core classes in Java not serializable. I suggest we delete ofbizSecure and ofbizBackgroundSecure and make all the others secure