Re: Taking a decision on remaining Jars in OFBiz

[Scott Gray]

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:

> 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 issue, but simpler users need to be warned...
>
> Jacques
>
> Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :
>
>> 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
>> - update the documentation so that users need not worry about calling any
>> secure tasks. So they only need to do custom work such as the whitelist,
>> etc ...
>>
>> I am not sure but I think there is no performance penalty right? That is
>> why I suggest lumping them together.
>>
>> Taher Alkhateeb
>>
>> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" 
>> wrote:
>>
>> 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 related wiki page
>>>
>>> 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 run, and
 also
 the rc scripts need to be modified to production and might be confusing
 (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be
 too
 many options to choose from in a production environment.

 No strong opinion, but I am suggesting to make it a little easier for
 people with a less-is-more kind of approach.

 What would you suggest? It seems to me that removing these options would
>>> degrade the information about rare but possible vulnerabilities
>>>
>>> Jacques
>>>
>>>
>>> Taher Alkhateeb

 On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 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
>
> Pattern: ofbizSecure : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : Execute OFBiz startup
> commands
> in background (secure mode) and output to console.log
>
> Jacques
>
>
>
> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>
> Why isn't whatever functionality 'ofbizSecure' provides, just included
> as
>
>> part of the regular 'ofbiz' task?
>>
>> On 5 August 2016 at 21:35, Jacques Le Roux <
>> jacques.le.r...@les7arts.com>
>> wrote:
>>
>> Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :
>>
>> +1 makes sense
>>>
>>> Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
 and
 replace them with some scripts in /tools if people are not using
 them?
 (I
 assume we only use them with demos?)

 On Aug 5, 2016 10:07 AM, "Jacques Le Roux">> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>

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

[devi sri prasad (JIRA)]

[ 
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 useful for all.It is 
informative blog.
powerplan is important for all.
http://www.happydiwalismsmessages.in/
http://www.happydiwalismsmessages.in/2016/07/deepavali-greetings-messages-diwali-greetings.html
http://www.happydiwalismsmessages.in/2015/10/happy-diwali-images-wallpaper-pictures-hd.html
http://www.happydiwalismsmessages.in/2015/10/happy-diwali-2016-messages-sms-quotes-status.html

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: buildbot success in on ofbiz-trunk

[Taher Alkhateeb]

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 complaining about UTF-8 encoding. Not sure exactly why but it
very much smells like a bug around encoding and string parsing. Still
investigating.

On Aug 6, 2016 4:43 PM, "Jacques Le Roux" 
wrote:

> 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
> https://ci.apache.org/builders/ofbiz-trunk?numbuilds=35 I don't see how
> it could be related, but this is weird indeed
>
> Unrelated, just FYI: we also no longer use the Gradle daemon with trunk
> demo as it seems it was sometimes an issue. Though actually the real issue
> (DB related) we got there was using "shutdown" instead of now
> "terminateOfbiz"which seems to have fixed the DB issue
>
> Jacques
>
>
> Le 06/08/2016 à 17:06, Taher Alkhateeb a écrit :
>
>> 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 <
>> slidingfilame...@gmail.com>
>> wrote:
>>
>> 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 org.apache.shiro:shiro-core:1.2.5.
>>>   Required by:
>>>   :ofbiz:unspecified
>>>
>>> There is no project called :ofbiz:unspecified. Something is not parsing
>>> the project tree correctly and I'm not sure of the reason yet. It could be
>>> that when we fixed the project name as "ofbiz" in settings.gradle something
>>> got affected in the cache.
>>>
>>> I don't think this is a transient bug, I suspect we introduced something
>>> that is causing this weird behavior.
>>>
>>>
>>> On Sat, Aug 6, 2016 at 5:23 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> 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" 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:
>>   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 scheduler named 'on-ofbiz-commit'
>> triggered this build
>> Build Source Stamp: [branch ofbiz/trunk] 1755393
>> Blamelist: arunpatidar
>>
>> Build succeeded!
>>
>> Sincerely,
>>-The Buildbot
>>
>>
>>
>>
>>
>>
>
>

Re: buildbot success in on ofbiz-trunk

[Jacques Le Roux]

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 https://ci.apache.org/builders/ofbiz-trunk?numbuilds=35 I don't see how it could be 
related, but this is weird indeed


Unrelated, just FYI: we also no longer use the Gradle daemon with trunk demo as it seems it was sometimes an issue. Though actually the real issue (DB 
related) we got there was using "shutdown" instead of now "terminateOfbiz"which seems to have fixed the DB issue


Jacques


Le 06/08/2016 à 17:06, Taher Alkhateeb a écrit :

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:


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 org.apache.shiro:shiro-core:1.2.5.
  Required by:
  :ofbiz:unspecified

There is no project called :ofbiz:unspecified. Something is not parsing the project tree 
correctly and I'm not sure of the reason yet. It could be that when we fixed the project 
name as "ofbiz" in settings.gradle something got affected in the cache.

I don't think this is a transient bug, I suspect we introduced something that 
is causing this weird behavior.


On Sat, Aug 6, 2016 at 5:23 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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" 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:
  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 scheduler named 'on-ofbiz-commit'
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1755393
Blamelist: arunpatidar

Build succeeded!

Sincerely,
   -The Buildbot

Re: buildbot success in on ofbiz-trunk

[Taher Alkhateeb]

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:

> 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 org.apache.shiro:shiro-core:1.2.5.
>  Required by:
>  :ofbiz:unspecified
>
> There is no project called :ofbiz:unspecified. Something is not parsing the 
> project tree correctly and I'm not sure of the reason yet. It could be that 
> when we fixed the project name as "ofbiz" in settings.gradle something got 
> affected in the cache.
>
> I don't think this is a transient bug, I suspect we introduced something that 
> is causing this weird behavior.
>
>
> On Sat, Aug 6, 2016 at 5:23 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> 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" 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:
  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 scheduler named 'on-ofbiz-commit'
 triggered this build
 Build Source Stamp: [branch ofbiz/trunk] 1755393
 Blamelist: arunpatidar

 Build succeeded!

 Sincerely,
   -The Buildbot





>>>
>>>
>>
>

Re: buildbot success in on ofbiz-trunk

[Taher Alkhateeb]

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 org.apache.shiro:shiro-core:1.2.5.
 Required by:
 :ofbiz:unspecified

There is no project called :ofbiz:unspecified. Something is not
parsing the project tree correctly and I'm not sure of the reason yet.
It could be that when we fixed the project name as "ofbiz" in
settings.gradle something got affected in the cache.

I don't think this is a transient bug, I suspect we introduced
something that is causing this weird behavior.


On Sat, Aug 6, 2016 at 5:23 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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" 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:
>>>  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 scheduler named 'on-ofbiz-commit'
>>> triggered this build
>>> Build Source Stamp: [branch ofbiz/trunk] 1755393
>>> Blamelist: arunpatidar
>>>
>>> Build succeeded!
>>>
>>> Sincerely,
>>>   -The Buildbot
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Re: buildbot success in on ofbiz-trunk

[Jacques Le Roux]

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" 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:
 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 scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1755393
Blamelist: arunpatidar

Build succeeded!

Sincerely,
  -The Buildbot

Re: buildbot success in on ofbiz-trunk

[Taher Alkhateeb]

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 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:
>>  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 scheduler named 'on-ofbiz-commit'
>> triggered this build
>> Build Source Stamp: [branch ofbiz/trunk] 1755393
>> Blamelist: arunpatidar
>>
>> Build succeeded!
>>
>> Sincerely,
>>   -The Buildbot
>>
>>
>>
>>
>>
>

buildbot exception in on ofbiz-trunk

[buildbot]

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 scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1755401
Blamelist: jleroux

BUILD FAILED: exception shell upload_2

Sincerely,
 -The Buildbot

Re: buildbot success in on ofbiz-trunk

[Jacques Le Roux]

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:
 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 scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1755393
Blamelist: arunpatidar

Build succeeded!

Sincerely,
  -The Buildbot

Re: Taking a decision on remaining Jars in OFBiz

[Jacopo Cappellato]

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 in ofbizSecure). This means
> ofbiz, ofbizBackground and ofbizDebug
> - update the documentation so that users need not worry about calling any
> secure tasks. So they only need to do custom work such as the whitelist,
> etc ...
>
>
+1

Jacopo

buildbot success in on ofbiz-trunk

[buildbot]

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 scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1755393
Blamelist: arunpatidar

Build succeeded!

Sincerely,
 -The Buildbot

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

[Arun Patidar (JIRA)]

 [ 
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 [~suraj.khurana] for your contribution.

> 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
>  Issue Type: Bug
>  Components: specialpurpose/webpos
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Arun Patidar
>Priority: Critical
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7946.patch
>
>
> ProductStoreId=9100 is not available due to removal of POS component from 
> specialPurpose



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Arun Patidar (JIRA)]

 [ 
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 removal of POS component
> 
>
> Key: OFBIZ-7946
> URL: https://issues.apache.org/jira/browse/OFBIZ-7946
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/webpos
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Arun Patidar
>Priority: Critical
> Attachments: OFBIZ-7946.patch
>
>
> ProductStoreId=9100 is not available due to removal of POS component from 
> specialPurpose



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Suraj Khurana (JIRA)]

 [ 
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 component due to removal of POS component
> 
>
> Key: OFBIZ-7946
> URL: https://issues.apache.org/jira/browse/OFBIZ-7946
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/webpos
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Critical
> Attachments: OFBIZ-7946.patch
>
>
> ProductStoreId=9100 is not available due to removal of POS component from 
> specialPurpose



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Suraj Khurana (JIRA)]

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
  Issue Type: Bug
  Components: specialpurpose/webpos
Affects Versions: Trunk
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Critical


ProductStoreId=9100 is not available due to removal of POS component from 
specialPurpose



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Taking a decision on remaining Jars in OFBiz

[Taher Alkhateeb]

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 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 issue, but simpler users need to be warned...
>
> Jacques
>
> Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :
>
>> 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
>> - update the documentation so that users need not worry about calling any
>> secure tasks. So they only need to do custom work such as the whitelist,
>> etc ...
>>
>> I am not sure but I think there is no performance penalty right? That is
>> why I suggest lumping them together.
>>
>> Taher Alkhateeb
>>
>> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" 
>> wrote:
>>
>> 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 related wiki page
>>>
>>> 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 run, and
 also
 the rc scripts need to be modified to production and might be confusing
 (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be
 too
 many options to choose from in a production environment.

 No strong opinion, but I am suggesting to make it a little easier for
 people with a less-is-more kind of approach.

 What would you suggest? It seems to me that removing these options would
>>> degrade the information about rare but possible vulnerabilities
>>>
>>> Jacques
>>>
>>>
>>> Taher Alkhateeb

 On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 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
>
> Pattern: ofbizSecure : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : Execute OFBiz startup
> commands
> in background (secure mode) and output to console.log
>
> Jacques
>
>
>
> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>
> Why isn't whatever functionality 'ofbizSecure' provides, just included
> as
>
>> part of the regular 'ofbiz' task?
>>
>> On 5 August 2016 at 21:35, Jacques Le Roux <
>> jacques.le.r...@les7arts.com>
>> wrote:
>>
>> Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :
>>
>> +1 makes sense
>>>
>>> Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
 and
 replace them with some scripts in /tools if people are not using
 them?
 (I
 assume we only use them with demos?)

 On Aug 5, 2016 10:07 AM, "Jacques Le Roux">> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>

Re: Taking a decision on remaining Jars in OFBiz

[Jacques Le Roux]

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 issue, but simpler users need to be warned...

Jacques

Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :

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
- update the documentation so that users need not worry about calling any
secure tasks. So they only need to do custom work such as the whitelist,
etc ...

I am not sure but I think there is no performance penalty right? That is
why I suggest lumping them together.

Taher Alkhateeb

On Aug 6, 2016 11:40 AM, "Jacques Le Roux" 
wrote:


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 related wiki page

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 run, and also
the rc scripts need to be modified to production and might be confusing
(ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
many options to choose from in a production environment.

No strong opinion, but I am suggesting to make it a little easier for
people with a less-is-more kind of approach.


What would you suggest? It seems to me that removing these options would
degrade the information about rare but possible vulnerabilities

Jacques



Taher Alkhateeb

On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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

Pattern: ofbizSecure : Execute OFBiz startup commands
pre-loading the notsoserial Java agent
Pattern: ofbizBackgroundSecure : Execute OFBiz startup commands
in background (secure mode) and output to console.log

Jacques



Le 06/08/2016 à 03:33, Scott Gray a écrit :

Why isn't whatever functionality 'ofbizSecure' provides, just included as

part of the regular 'ofbiz' task?

On 5 August 2016 at 21:35, Jacques Le Roux <
jacques.le.r...@les7arts.com>
wrote:

Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :


+1 makes sense


Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
and
replace them with some scripts in /tools if people are not using them?
(I
assume we only use them with demos?)

On Aug 5, 2016 10:07 AM, "Jacques Le Roux"

Re: Taking a decision on remaining Jars in OFBiz

[Taher Alkhateeb]

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
- update the documentation so that users need not worry about calling any
secure tasks. So they only need to do custom work such as the whitelist,
etc ...

I am not sure but I think there is no performance penalty right? That is
why I suggest lumping them together.

Taher Alkhateeb

On Aug 6, 2016 11:40 AM, "Jacques Le Roux" 
wrote:

> 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 related wiki page
>
> 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 run, and also
>> the rc scripts need to be modified to production and might be confusing
>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
>> many options to choose from in a production environment.
>>
>> No strong opinion, but I am suggesting to make it a little easier for
>> people with a less-is-more kind of approach.
>>
>
> What would you suggest? It seems to me that removing these options would
> degrade the information about rare but possible vulnerabilities
>
> Jacques
>
>
>> Taher Alkhateeb
>>
>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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
>>>
>>> Pattern: ofbizSecure : Execute OFBiz startup commands
>>> pre-loading the notsoserial Java agent
>>> Pattern: ofbizBackgroundSecure : Execute OFBiz startup commands
>>> in background (secure mode) and output to console.log
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>>
>>> Why isn't whatever functionality 'ofbizSecure' provides, just included as
 part of the regular 'ofbiz' task?

 On 5 August 2016 at 21:35, Jacques Le Roux <
 jacques.le.r...@les7arts.com>
 wrote:

 Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :

> +1 makes sense
>
>> Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
>> and
>> replace them with some scripts in /tools if people are not using them?
>> (I
>> assume we only use them with demos?)
>>
>> On Aug 5, 2016 10:07 AM, "Jacques Le Roux"> .com
>> wrote:
>>
>> Nope, those are intended to be used in production if ever you need it.
>>
> See the warning there https://cwiki.apache.org/confl
> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>
> Jacques
>
>
>
>
>

Re: Gradle loadDefault has some hiccup on BuildBot

[Jacques Le Roux]

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 (like locally) the cache is OK, so the copyLib task would be also. The problem here is more because 
with ASF Buildbot we start anew each time.

It's not bad that ASF Buildbot does that, it warns us about possible issues 
when using Gradle in such a situation.

Also, as Pierre outlined, there are situations were you can't use Gradle but on dev machines. I experienced that, no servers were allowed to connect 
to the Internet at all...



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. Right now, OFBiz is pulling wy to much! In
a sense OFBiz suffers from library bloat, and this is an area ripe for
improvement I think.


Yes I know, we have still work on the plate...

Jacques



Taher Alkhateeb

On Sat, Aug 6, 2016 at 12:41 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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, Taher Alkhateeb a écrit :


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, Aug 6, 2016 at 12:28 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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 build system as it has to do with the
remote
repository.

On Aug 6, 2016 10:11 AM, "Taher Alkhateeb" 
wrote:

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" 

Re: Taking a decision on remaining Jars in OFBiz

[Jacques Le Roux]

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 related wiki page


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 run, and also
the rc scripts need to be modified to production and might be confusing
(ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
many options to choose from in a production environment.

No strong opinion, but I am suggesting to make it a little easier for
people with a less-is-more kind of approach.


What would you suggest? It seems to me that removing these options would 
degrade the information about rare but possible vulnerabilities

Jacques



Taher Alkhateeb

On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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

Pattern: ofbizSecure : Execute OFBiz startup commands
pre-loading the notsoserial Java agent
Pattern: ofbizBackgroundSecure : Execute OFBiz startup commands
in background (secure mode) and output to console.log

Jacques



Le 06/08/2016 à 03:33, Scott Gray a écrit :


Why isn't whatever functionality 'ofbizSecure' provides, just included as
part of the regular 'ofbiz' task?

On 5 August 2016 at 21:35, Jacques Le Roux 
wrote:

Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :

+1 makes sense

Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
and
replace them with some scripts in /tools if people are not using them?
(I
assume we only use them with demos?)

On Aug 5, 2016 10:07 AM, "Jacques Le Roux"

Re: Gradle loadDefault has some hiccup on BuildBot

[Taher Alkhateeb]

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. Right now, OFBiz is pulling wy to much! In
a sense OFBiz suffers from library bloat, and this is an area ripe for
improvement I think.

Taher Alkhateeb

On Sat, Aug 6, 2016 at 12:41 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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, Taher Alkhateeb a écrit :
>
>> 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, Aug 6, 2016 at 12:28 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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 build system as it has to do with the
 remote
 repository.

 On Aug 6, 2016 10:11 AM, "Taher Alkhateeb" 
 wrote:

 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
>
>> 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" <
>> jacques.le.r...@les7arts.com
>> wrote:
>>
>> 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 swipe
>>> my
>>> Gradle cache to verify!
>>>
>>> This shows that you should not rely on Gradle in production. I more
>>> and
>>> more believe Pierre is right on this aspect!
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>

Re: Taking a decision on remaining Jars in OFBiz

[Taher Alkhateeb]

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 run, and also
the rc scripts need to be modified to production and might be confusing
(ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
many options to choose from in a production environment.

No strong opinion, but I am suggesting to make it a little easier for
people with a less-is-more kind of approach.

Taher Alkhateeb

On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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
>
> Pattern: ofbizSecure : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : Execute OFBiz startup commands
> in background (secure mode) and output to console.log
>
> Jacques
>
>
>
> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>
>> Why isn't whatever functionality 'ofbizSecure' provides, just included as
>> part of the regular 'ofbiz' task?
>>
>> On 5 August 2016 at 21:35, Jacques Le Roux 
>> wrote:
>>
>> Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :
>>>
>>> +1 makes sense

 Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
 and
 replace them with some scripts in /tools if people are not using them?
 (I
 assume we only use them with demos?)

 On Aug 5, 2016 10:07 AM, "Jacques Le Roux"
 wrote:

 Nope, those are intended to be used in production if ever you need it.
>>>
>>> See the warning there https://cwiki.apache.org/confl
>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>

Re: Gradle loadDefault has some hiccup on BuildBot

[Jacques Le Roux]

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, Taher Alkhateeb a écrit :

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, Aug 6, 2016 at 12:28 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 build system as it has to do with the remote
repository.

On Aug 6, 2016 10:11 AM, "Taher Alkhateeb" 
wrote:

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

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" 

Re: Gradle loadDefault has some hiccup on BuildBot

[Taher Alkhateeb]

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, Aug 6, 2016 at 12:28 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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 build system as it has to do with the remote
>> repository.
>>
>> On Aug 6, 2016 10:11 AM, "Taher Alkhateeb" 
>> wrote:
>>
>> 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
 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,
>
> 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 swipe my
> Gradle cache to verify!
>
> This shows that you should not rely on Gradle in production. I more and
> more believe Pierre is right on this aspect!
>
> Jacques
>
>
>
>

Re: Gradle loadDefault has some hiccup on BuildBot

[Jacques Le Roux]

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 build system as it has to do with the remote
repository.

On Aug 6, 2016 10:11 AM, "Taher Alkhateeb" 
wrote:


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
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,

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 swipe my
Gradle cache to verify!

This shows that you should not rely on Gradle in production. I more and
more believe Pierre is right on this aspect!

Jacques

Re: Gradle loadDefault has some hiccup on BuildBot

[Jacques Le Roux]

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 root project 'build'.

On Aug 6, 2016 9:49 AM, "Jacques Le Roux" 
wrote:


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 swipe my
Gradle cache to verify!

This shows that you should not rely on Gradle in production. I more and
more believe Pierre is right on this aspect!

Jacques

Re: Gradle loadDefault has some hiccup on BuildBot

[Taher Alkhateeb]

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" 
wrote:

> 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
>> 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,
>>>
>>> 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 swipe my
>>> Gradle cache to verify!
>>>
>>> This shows that you should not rely on Gradle in production. I more and
>>> more believe Pierre is right on this aspect!
>>>
>>> Jacques
>>>
>>>

Re: Gradle loadDefault has some hiccup on BuildBot

[Taher Alkhateeb]

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
> 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,
>>
>> 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 swipe my
>> Gradle cache to verify!
>>
>> This shows that you should not rely on Gradle in production. I more and
>> more believe Pierre is right on this aspect!
>>
>> Jacques
>>
>>

Re: Gradle loadDefault has some hiccup on BuildBot

[Taher Alkhateeb]

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,
>
> 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 swipe my
> Gradle cache to verify!
>
> This shows that you should not rely on Gradle in production. I more and
> more believe Pierre is right on this aspect!
>
> Jacques
>
>

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

[Jacques Le Roux (JIRA)]

[ 
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 function to trigger it
terminateOfbiz ?

> Running OFBiz as a service fails
> 
>
> Key: OFBIZ-7796
> URL: https://issues.apache.org/jira/browse/OFBIZ-7796
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Trunk
> Environment: Ubuntu 16.04, openjdk-8-jdk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-77796-rc.ofbiz.for.debian.patch, 
> OFBIZ-7796-rc.ofbiz.for.debian-v2.patch
>
>
> In a new ubuntu environment I performed a checkout  from trunk and ran the 
> loadDefault build script.
> After this had completed, I moved the ofbiz directory from my user folder to 
> the /opt folder, and configured the Ubuntu environment to be able to run 
> OFBiz as a service.
> This entails:
> * deploy a script in /etc/init.d
> * set the correct permissions of the service script
> * create the service user 
> * changed the owner and ownergroup of the files and folders in /opt/ofbiz
> and then fire the service:
> sudo /etc/init.d/ofbiz start
> This normally starts the proces java -jar ofbiz.jar
> But now nothing happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Jacques Le Roux (JIRA)]

[ 
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 also removes: the 'kill' reference as there is no function to trigger it
terminateOfbiz works on demo


was (Author: jacques.le.roux):
bq. It also removes: the 'kill' reference as there is no function to trigger it
terminateOfbiz ?

> Running OFBiz as a service fails
> 
>
> Key: OFBIZ-7796
> URL: https://issues.apache.org/jira/browse/OFBIZ-7796
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Trunk
> Environment: Ubuntu 16.04, openjdk-8-jdk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-77796-rc.ofbiz.for.debian.patch, 
> OFBIZ-7796-rc.ofbiz.for.debian-v2.patch
>
>
> In a new ubuntu environment I performed a checkout  from trunk and ran the 
> loadDefault build script.
> After this had completed, I moved the ofbiz directory from my user folder to 
> the /opt folder, and configured the Ubuntu environment to be able to run 
> OFBiz as a service.
> This entails:
> * deploy a script in /etc/init.d
> * set the correct permissions of the service script
> * create the service user 
> * changed the owner and ownergroup of the files and folders in /opt/ofbiz
> and then fire the service:
> sudo /etc/init.d/ofbiz start
> This normally starts the proces java -jar ofbiz.jar
> But now nothing happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Jacques Le Roux (JIRA)]

[ 
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 http://markmail.org/message/uirwfrdzg2lhyi6i I believe you are right, 
this would be a wrong advice to advocate Gradle in production!

> Running OFBiz as a service fails
> 
>
> Key: OFBIZ-7796
> URL: https://issues.apache.org/jira/browse/OFBIZ-7796
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Trunk
> Environment: Ubuntu 16.04, openjdk-8-jdk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-77796-rc.ofbiz.for.debian.patch, 
> OFBIZ-7796-rc.ofbiz.for.debian-v2.patch
>
>
> In a new ubuntu environment I performed a checkout  from trunk and ran the 
> loadDefault build script.
> After this had completed, I moved the ofbiz directory from my user folder to 
> the /opt folder, and configured the Ubuntu environment to be able to run 
> OFBiz as a service.
> This entails:
> * deploy a script in /etc/init.d
> * set the correct permissions of the service script
> * create the service user 
> * changed the owner and ownergroup of the files and folders in /opt/ofbiz
> and then fire the service:
> sudo /etc/init.d/ofbiz start
> This normally starts the proces java -jar ofbiz.jar
> But now nothing happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Gradle loadDefault has some hiccup on BuildBot

[Jacques Le Roux]

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 swipe my Gradle 
cache to verify!


This shows that you should not rely on Gradle in production. I more and more 
believe Pierre is right on this aspect!

Jacques

Re: Taking a decision on remaining Jars in OFBiz

[Jacques Le Roux]

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

Pattern: ofbizSecure : Execute OFBiz startup commands pre-loading the 
notsoserial Java agent
Pattern: ofbizBackgroundSecure : Execute OFBiz startup commands in 
background (secure mode) and output to console.log

Jacques


Le 06/08/2016 à 03:33, Scott Gray a écrit :

Why isn't whatever functionality 'ofbizSecure' provides, just included as
part of the regular 'ofbiz' task?

On 5 August 2016 at 21:35, Jacques Le Roux 
wrote:


Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :


+1 makes sense

Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure and
replace them with some scripts in /tools if people are not using them? (I
assume we only use them with demos?)

On Aug 5, 2016 10:07 AM, "Jacques Le Roux"
wrote:


Nope, those are intended to be used in production if ever you need it.

See the warning there https://cwiki.apache.org/confl
uence/display/OFBIZ/Keeping+OFBiz+secure for details

Jacques

Re: Security : seed-initial

[Jacques Le Roux]

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. e.g. shipping a demo order and then reloading the XML would leave the
shipment and issuances in place but revert the order to approved.

Perhaps it should be renamed to PasswordSecurityDemoData.xml

Regards
Scott

On 6 August 2016 at 02:04, Jacques Le Roux 
wrote:


Mmm, yes you are right, it can't be seed-initial. But also not ext-demo,
it's only for adopters. I finally think we should keep as is or introduce
another specialised reader, not a big deal and not for today...

Thanks

Jacques



Le 05/08/2016 à 15:54, Taher Alkhateeb a écrit :


I think by convention seed-initial does not setup users or passwords, that
should be either demo or ext-demo or something like that. Not entirely
sure
of this though.

On Aug 5, 2016 1:37 PM, "Jacques Le Roux" 
wrote:

Hi,

I stumbled upon this by chance

  
  
  
  

Should we not use seed-initial rather than demo here?

Jacques

Re: Taking a decision on remaining Jars in OFBiz

[Taher Alkhateeb]

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 by default (ofbiz, ofbizDebug, ofbizBackground).

Taher Alkhateeb

On Saturday, 6 August 2016, Scott Gray  wrote:

> Why isn't whatever functionality 'ofbizSecure' provides, just included as
> part of the regular 'ofbiz' task?
>
> On 5 August 2016 at 21:35, Jacques Le Roux  >
> wrote:
>
> > Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit :
> >
> >> +1 makes sense
> >>
> >> Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure
> and
> >> replace them with some scripts in /tools if people are not using them?
> (I
> >> assume we only use them with demos?)
> >>
> >> On Aug 5, 2016 10:07 AM, "Jacques Le Roux" >
> >> wrote:
> >>
> >
> > Nope, those are intended to be used in production if ever you need it.
> >
> > See the warning there https://cwiki.apache.org/confl
> > uence/display/OFBIZ/Keeping+OFBiz+secure for details
> >
> > Jacques
> >
> >
>