date:20151014

Re: Sharing ApacheCon Europe Slide Links

2015-10-14 Thread gil.portensei...@nereide.fr


I Gavin, 

Everything is already uploaded in the wiki, in the event section :). Dont know 
why mine is not appearing, i did upload it...

Cheers 

Gil



 Message original 
De : Gavin Mabie 
Envoyé : Wednesday, October 14, 2015 03:39 PM
À : dev@ofbiz.apache.org
Sujet : Sharing ApacheCon Europe Slide Links

>Hi All
>
>Here are a few links to slides presented  by OFBiz community members at the
>recent ApacheCon.
>
>State of Apache OFBiz
>
>(Jacopo Cappellato)
>GrowERP as a service
>
>(Hans Baker)
>UX Design in OFBiz: How tro make it a reality!
>
>(Julien Nicolas)
>OFBiz CRM &  Asterisk Call Center Integration
>
>(Youssef Khaye)
>DevOps Environment for an OFBiz Agile project
>
>(Nathan Boudou)
>It‘s OK – Consensus Reached. We‘ve Agreed to Disagree
>!(Sharan
>Foga)
>
>These are the links to all the presentations:
>Big Data
>
>Core 
>
>Maybe we could post them on the wiki (The OFBiz ones). I could not locate
>Gill's presentation amongst those listed.
>
>Regards
>Gavin

Re: Sharing ApacheCon Europe Slide Links

2015-10-14 Thread Gavin Mabie

Apologies for the redundancy!

On Wed, Oct 14, 2015 at 5:59 PM, gil.portensei...@nereide.fr <
gil.portensei...@nereide.fr> wrote:

>
> I Gavin,
>
> Everything is already uploaded in the wiki, in the event section :). Dont
> know why mine is not appearing, i did upload it...
>
> Cheers
>
> Gil
>
>
>
>  Message original 
> De : Gavin Mabie 
> Envoyé : Wednesday, October 14, 2015 03:39 PM
> À : dev@ofbiz.apache.org
> Sujet : Sharing ApacheCon Europe Slide Links
>
> >Hi All
> >
> >Here are a few links to slides presented  by OFBiz community members at
> the
> >recent ApacheCon.
> >
> >State of Apache OFBiz
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/ApacheconEU2015_0.pdf
> >
> >(Jacopo Cappellato)
> >GrowERP as a service
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/apachecon_0.pdf
> >
> >(Hans Baker)
> >UX Design in OFBiz: How tro make it a reality!
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/UXDesignInOFBiz-JulienNICOLAS.pdf
> >
> >(Julien Nicolas)
> >OFBiz CRM &  Asterisk Call Center Integration
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/ApacheCon-Core-EU_2015_Ofbiz-CRM-asterisk-.pdf
> >
> >(Youssef Khaye)
> >DevOps Environment for an OFBiz Agile project
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/apachecon_devops.pdf
> >
> >(Nathan Boudou)
> >It‘s OK – Consensus Reached. We‘ve Agreed to Disagree
> ><
> http://events.linuxfoundation.org/sites/events/files/slides/Its%20OK%20Consensus%20Reached_0.pd
> >!(Sharan
> >Foga)
> >
> >These are the links to all the presentations:
> >Big Data
> ><
> http://events.linuxfoundation.org/events/apache-big-data-europe/program/slides
> >
> >Core 
> >
> >Maybe we could post them on the wiki (The OFBiz ones). I could not locate
> >Gill's presentation amongst those listed.
> >
> >Regards
> >Gavin
>

[jira] [Commented] (OFBIZ-6236) Integration of OFBiz and Magento ecommerce for providing Order Management support

2015-10-14 Thread Pierre Smits (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956392#comment-14956392
 ] 

Pierre Smits commented on OFBIZ-6236:
-

Why is it better to have it in the OFBiz code base?

> Integration of OFBiz and Magento ecommerce for providing Order Management 
> support
> -
>
> Key: OFBIZ-6236
> URL: https://issues.apache.org/jira/browse/OFBIZ-6236
> Project: OFBiz
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Arun Patidar
>Priority: Trivial
> Attachments: Magento-Setup-Guide.pdf, OFBIZ-6236.patch, 
> OFBiz_Connect-1.0.0.tgz
>
>
> Integration of OFBiz and Magento Ecommerce for providing Order Management 
> support.
> We can use OFBiz ERP system for handling Magento orders work-flow till 
> fulfilment.
> Featrures:
> This integration can be use to provide Order and Warehouse Management to the 
> orders placed via Magento E-commerce store.
> -- Imports store data and configuartion settings from Magento store
> -- Imports Shipping configuration
> -- Imports Categories
> -- Imports Products along with images path
> -- One time import inventory count of products
> -- Import pending orders from Magento
> -- Sync Cancel and Held orders between Magento and OFBiz
> -- Push shipment details and tracking code to Magento
> -- Refund amoung using CreditMemo feature of Magento
> Once the setup would be done, there are scheduled services that checks orders 
> in Magento every hour.



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

[jira] [Comment Edited] (OFBIZ-6669) Possible static XSS issue with Content

2015-10-14 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954165#comment-14954165
 ] 

Jacques Le Roux edited comment on OFBIZ-6669 at 10/14/15 8:52 AM:
--

The ContentWorker is fixed in
trunk r1708274  + r1708560  
R14.12 r1708275 + r1708471  




was (Author: jacques.le.roux):
The ContentWorker is fixed in
trunk r1708274  
R14.12 r1708275 + r1708471  



> Possible static XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page 1 
> - Hard Coded Link using the Sub-Content Pattern
> - href="/cmssite/cms/CMSS_DEMO_PAGE1;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page 1 - Dynamic Link
> - href="/cmssite/cms/CMSS_DEMO_SCREEN;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with screen widget and screen decorator
> -

Re: Java 8 and functional programming in trunk

2015-10-14 Thread Pierre Smits

So we need to plan for it, and tie it to a release branch?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Wed, Oct 14, 2015 at 11:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I tend to agree. Actually there are 2 points,
> 1) use Java 8 to compile
> 2) use new Java 8 features
>
> We can already do 1, but we should maybe wait the next freezed branch to
> do 2. That should be discussed but does not prevent 1. Of course any commit
> with 2 will be rejected as long as an agreement on 2 will not be reached
>
> Jacques
>
>
> Le 11/10/2015 19:09, Ron Wheeler a écrit :
>
>> I am not sure why backwards compatibility is an issue with moving to Java
>> 8.
>>
>> It works well,
>> it is the supported version of Java.
>> As far as I have heard, the Java 8 JVM runs code compiled with earlier
>> versions of Java. (My own experience is uniformly positive).
>>
>> I can see no reason to think that anyone who is developing or using OFBiz
>> would need to compile or run with an older version of Java.
>>
>> In this day of VM and Docker Containers, it is hard to imagine that
>> someone would be stuck on an older JVM in a production environment and
>> unable to come up with a configuration that would allow them to run JVM 8
>> to support OFBiz.
>>
>> IMHO, we should just move to requiring the supported version of Java as
>> soon as possible.
>>
>> Ron
>>
>>
>> On 11/10/2015 4:14 AM, Taher Alkhateeb wrote:
>>
>>> Hello Everyone,
>>>
>>> We created and provided the patches for this issue since June and OFBiz
>>> is pretty much ready to move to JDK 8. I'm not sure if lazy consensus is
>>> enough or whether a vote is warranted to move this issue forward?
>>>
>>> Cheers,
>>>
>>> Taher Alkhateeb
>>>
>>> - Original Message -
>>>
>>> From: "Pierre Smits" 
>>> To: dev@ofbiz.apache.org
>>> Sent: Thursday, 7 May, 2015 10:52:00 AM
>>> Subject: Re: Java 8 and functional programming in trunk
>>>
>>> I don't think that it is a question of using or not using J8. It is more
>>> about when to move it into trunk, as from that moment on there will be
>>> backward compatibility issues.
>>> A helpful solution in this respect could be to designate a specific
>>> release
>>> branch now (e.g. r15 or r16), create the version in JIRA and setup the
>>> dev
>>> branch in svn. Doing it that way J8 related issues can get registered,
>>> changes can get implemented and assessed (in the dev branch) without
>>> breaking current stuff in trunk.
>>>
>>> But it also ensures that we can create awareness prior to releasing
>>> stuff.
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin 
>>> wrote:
>>>
>>> Ok Thanks Scott and Jacques.

 So Who is against use java 8 and more on trunk ?

 :)

 Nicolas


 Le 07/05/2015 08:46, Jacques Le Roux a écrit :

 Yes (lazy) consensus over vote ;)
>
> Jacques
>
> Le 07/05/2015 05:02, Scott Gray a écrit :
>
> I'm not sure if a vote is necessary, particularly if no one has any
>> objections.
>>
>> Regards
>> Scott
>> On 7 May 2015 07:44, "Nicolas Malin" 
>> wrote:
>>
>> I'm favorable to use java 8.
>>
>>> I think it's will be pretty fin if you can support oracle jdk8 and
>>> openjdk8 also.
>>>
>>> I propose to organize a vote to validate or not this proposition
>>>
>>> Nicolas
>>>
>>> Le 03/05/2015 11:52, Jacques Le Roux a écrit :
>>>
>>> Hi Taher,
>>>
 Yes I think so. For now well known (I hope ;)) security reasons, if
 people want to use Oracle JDK they need to use Java 8.
 So implementing with new Java 8 features now in trunk sounds good to
 me.
 BTW this is only my opinion...

 Note that our demos are still using OpenJDK 1.7 I'm not quite sure
 of
 the
 policy


 http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html



 Jacques


 Le 03/05/2015 10:52, Taher Alkhateeb a écrit :

 Hi everyone,

> I would like to work on a few JIRAs and at the same refactor some
> existing
> code to utilize Lambdas and Streams utilizing Java 8 features.
>
>
> Is it acceptable to develop with JDK 8 features into trunk?
>
> Taher Alkhateeb
>
>
>
>
>>>
>>
>>

[jira] [Commented] (OFBIZ-6669) Possible static XSS issue with Content

2015-10-14 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956492#comment-14956492
 ] 

Jacques Le Roux commented on OFBIZ-6669:


Yes right Vyom, I thought just before getting to sleep yesterday night (I don't 
know you but for me it almost always happen at this moment or when I awake :D)

So I will simply move the guava lib from solr to base component. There is 
already a build dependency from solr to base so that's all what's needed. I 
feared it could be a problem because the sanitizer dependency on guava lib is 
at runtime, but it works perfectly well.

Thanks for the reminder :)

> Possible static XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page 1 
> - Hard Coded Link using the Sub-Content Pattern
> - href="/cmssite/cms/CMSS_DEMO_PAGE1;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page 1 - Dynamic Link
> -

[jira] [Commented] (OFBIZ-6669) Possible static XSS issue with Content

2015-10-14 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956497#comment-14956497
 ] 

Jacques Le Roux commented on OFBIZ-6669:


I'm not quite sure about that, at least the sanitizer needs 
com/google/common/collect/ImmutableSet, maybe that's all but you can't be sure 
since once installed no errors come again. More information at 
https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

> Possible static XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page 1 
> - Hard Coded Link using the Sub-Content Pattern
> - href="/cmssite/cms/CMSS_DEMO_PAGE1;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page 1 - Dynamic Link
> - href="/cmssite/cms/CMSS_DEMO_SCREEN;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with screen widget and screen decorator
> -

Re: Java 8 and functional programming in trunk

2015-10-14 Thread Jacques Le Roux


I tend to agree. Actually there are 2 points,
1) use Java 8 to compile
2) use new Java 8 features

We can already do 1, but we should maybe wait the next freezed branch to do 2. That should be discussed but does not prevent 1. Of course any commit 
with 2 will be rejected as long as an agreement on 2 will not be reached


Jacques

Le 11/10/2015 19:09, Ron Wheeler a écrit :

I am not sure why backwards compatibility is an issue with moving to Java 8.

It works well,
it is the supported version of Java.
As far as I have heard, the Java 8 JVM runs code compiled with earlier versions 
of Java. (My own experience is uniformly positive).

I can see no reason to think that anyone who is developing or using OFBiz would 
need to compile or run with an older version of Java.

In this day of VM and Docker Containers, it is hard to imagine that someone would be stuck on an older JVM in a production environment and unable to 
come up with a configuration that would allow them to run JVM 8 to support OFBiz.


IMHO, we should just move to requiring the supported version of Java as soon as 
possible.

Ron


On 11/10/2015 4:14 AM, Taher Alkhateeb wrote:

Hello Everyone,

We created and provided the patches for this issue since June and OFBiz is pretty much ready to move to JDK 8. I'm not sure if lazy consensus is 
enough or whether a vote is warranted to move this issue forward?


Cheers,

Taher Alkhateeb

- Original Message -

From: "Pierre Smits" 
To: dev@ofbiz.apache.org
Sent: Thursday, 7 May, 2015 10:52:00 AM
Subject: Re: Java 8 and functional programming in trunk

I don't think that it is a question of using or not using J8. It is more
about when to move it into trunk, as from that moment on there will be
backward compatibility issues.
A helpful solution in this respect could be to designate a specific release
branch now (e.g. r15 or r16), create the version in JIRA and setup the dev
branch in svn. Doing it that way J8 related issues can get registered,
changes can get implemented and assessed (in the dev branch) without
breaking current stuff in trunk.

But it also ensures that we can create awareness prior to releasing stuff.

Best regards,



Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin 
wrote:


Ok Thanks Scott and Jacques.

So Who is against use java 8 and more on trunk ?

:)

Nicolas


Le 07/05/2015 08:46, Jacques Le Roux a écrit :


Yes (lazy) consensus over vote ;)

Jacques

Le 07/05/2015 05:02, Scott Gray a écrit :


I'm not sure if a vote is necessary, particularly if no one has any
objections.

Regards
Scott
On 7 May 2015 07:44, "Nicolas Malin"  wrote:

I'm favorable to use java 8.

I think it's will be pretty fin if you can support oracle jdk8 and
openjdk8 also.

I propose to organize a vote to validate or not this proposition

Nicolas

Le 03/05/2015 11:52, Jacques Le Roux a écrit :

Hi Taher,

Yes I think so. For now well known (I hope ;)) security reasons, if
people want to use Oracle JDK they need to use Java 8.
So implementing with new Java 8 features now in trunk sounds good to
me.
BTW this is only my opinion...

Note that our demos are still using OpenJDK 1.7 I'm not quite sure of
the
policy

http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html



Jacques


Le 03/05/2015 10:52, Taher Alkhateeb a écrit :

Hi everyone,

I would like to work on a few JIRAs and at the same refactor some
existing
code to utilize Lambdas and Streams utilizing Java 8 features.


Is it acceptable to develop with JDK 8 features into trunk?

Taher Alkhateeb

[jira] [Commented] (OFBIZ-6669) Possible static XSS issue with Content

2015-10-14 Thread Vyom Jain (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956463#comment-14956463
 ] 

Vyom Jain commented on OFBIZ-6669:
--

If I understand r1708471 commit message, it seems trunk's applications/content 
has a runtime dependency on specialpurpose/solr because of 
specialpurpose/solr/lib/runtime/guava-14.0.1.jar. Is this dependency desired, 
what if someone has disabled the solr component?

> Possible static XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page 1 
> - Hard Coded Link using the Sub-Content Pattern
> - href="/cmssite/cms/CMSS_DEMO_PAGE1;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page 1 - Dynamic Link
> - href="/cmssite/cms/CMSS_DEMO_SCREEN;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with screen widget and screen decorator
> -

[jira] [Commented] (OFBIZ-6669) Possible static XSS issue with Content

2015-10-14 Thread Pierre Smits (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956476#comment-14956476
 ] 

Pierre Smits commented on OFBIZ-6669:
-

What does the guava lib deliver?


> Possible static XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page 1 
> - Hard Coded Link using the Sub-Content Pattern
> - href="/cmssite/cms/CMSS_DEMO_PAGE1;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page 1 - Dynamic Link
> - href="/cmssite/cms/CMSS_DEMO_SCREEN;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with screen widget and screen decorator
> - href="/cmssite/cms/CMSS_DEMO_BLOG;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with blog using screen decorator
> - href="/cmssite/cms/CMSS_DEMO_TPL_DATA;jsessionid=014BD837D7FFB6E0F8CB31AAF35092A0.jvm1">Demo
>  Page with an xml resource formatted with a template ftl

[jira] [Commented] (OFBIZ-6236) Integration of OFBiz and Magento ecommerce for providing Order Management support

2015-10-14 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956498#comment-14956498
 ] 

Jacques Le Roux commented on OFBIZ-6236:


Marketing :)

> Integration of OFBiz and Magento ecommerce for providing Order Management 
> support
> -
>
> Key: OFBIZ-6236
> URL: https://issues.apache.org/jira/browse/OFBIZ-6236
> Project: OFBiz
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Arun Patidar
>Priority: Trivial
> Attachments: Magento-Setup-Guide.pdf, OFBIZ-6236.patch, 
> OFBiz_Connect-1.0.0.tgz
>
>
> Integration of OFBiz and Magento Ecommerce for providing Order Management 
> support.
> We can use OFBiz ERP system for handling Magento orders work-flow till 
> fulfilment.
> Featrures:
> This integration can be use to provide Order and Warehouse Management to the 
> orders placed via Magento E-commerce store.
> -- Imports store data and configuartion settings from Magento store
> -- Imports Shipping configuration
> -- Imports Categories
> -- Imports Products along with images path
> -- One time import inventory count of products
> -- Import pending orders from Magento
> -- Sync Cancel and Held orders between Magento and OFBiz
> -- Push shipment details and tracking code to Magento
> -- Refund amoung using CreditMemo feature of Magento
> Once the setup would be done, there are scheduled services that checks orders 
> in Magento every hour.



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

Re: svn commit: r1708560 - in /ofbiz/trunk: framework/base/lib/guava-14.0.1.jar specialpurpose/solr/lib/runtime/guava-14.0.1.jar

2015-10-14 Thread Jacques Le Roux

BTW it's good to have guava lib in base/lib as explained recently by the (still?) only paid member of the Groovy project (Jochen Theodorou) because of 
its persistent collections


>


Also maybe time to move to Java 8 as Taher reminded us recently. I think I'll 
have a look at that again soon...

Jacques


Le 14/10/2015 10:51, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Oct 14 08:51:36 2015
New Revision: 1708560

URL: http://svn.apache.org/viewvc?rev=1708560=rev
Log:
Move guava lib from solr/lib/runtime to base/lib to avoid dependency on solr 
component, thanks to Vyom for the reminder

Added:
 ofbiz/trunk/framework/base/lib/guava-14.0.1.jar
   - copied unchanged from r1708559, 
ofbiz/trunk/specialpurpose/solr/lib/runtime/guava-14.0.1.jar
Removed:
 ofbiz/trunk/specialpurpose/solr/lib/runtime/guava-14.0.1.jar

Why A Framework Rewrite Is Necessary

2015-10-14 Thread Adrian Crum

I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further action
on this subject, because I've brought it up before without success, and
I'm tired of discussing it. It is my hope that the light bulb will click
on in someone's head and they will take action.

My Background
-

I became a member of the OFBiz community in 2004. I immediately started
making contributions to the project by supplying patches to the issue
tracker. In 2007, I became a committer. Most of my initial work was on
the UI and some work in the applications (mainly Asset Maintenance and
Work Effort). I stayed away from touching the framework code because it
was deep, dark, and scary.

Eventually, I started to understand how the framework code works and I
made some minor modifications. As my understanding grew, I progressed to
rewriting large swaths of framework code - making it thread-safe, fault
tolerant, efficient, and easier to use.

I will list some of my contributions here, so everyone can have a clear
understanding of my experience with the framework code:

New Features

User Preferences

Visual Themes

Custom UI Label XML File Format

Temporal Expressions

Data Type Conversion Framework

Screen Widget Boundary Comments

Metrics

Integrations

UEL

iCalendar

JSR 223

WebDAV

LDAP

Refactorings/Improvements

FlexibleStringExpander

FlexibleMapExpander

FOP Integration

FreeMarkerWorker

Date-Time Handling

Mini-language

Job Scheduler

In addition, I have performed innumerable framework bug fixes.

So, the contents of this message come from years of experience mucking
about in the framework code.

Okay, let's get started...

Initial Problem Statement
-

In 2009, David Jones started a framework rewrite in a branch:

https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716

At the time, there was some agreement that a rewrite was necessary, but
there was disagreement as to how the rewrite should be incorporated into
the project:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3c455601.62605...@web63102.mail.re1.yahoo.com%3E

There were concerns that a rewrite would break backward compatibility.
Work on the rewrite branch stopped. Eventually, Jacopo suggested the
community be more accepting of backward-incompatible changes:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cd24f129d-4f9f-444e-84af-aca46f499...@hotwaxmedia.com%3e

Despite an effort to convince David to proceed with the framework
rewrite, he ended up doing it in a separate project:

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3c07565c88-4023-4d24-93a3-a4906e86f...@me.com%3E

This page describes differences between OFBiz and Moqui, and within it
you can extract information on the problems David was trying to solve:

http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/

There was an email he sent out on the OFBiz dev list where he listed the
problems he saw in the framework, but I can't find it. The rest of this
message will include the issues he mentioned (the ones I remember). I
was in agreement with him at the time, and I still agree that a
framework rewrite is necessary.

The Problems

Code is scattered everywhere - due to an initial effort to make the
framework modular. This causes serious problems. The mere fact that
components like entityext and securityext EXIST makes it clear that
there are problems - those components should not be there. Also, we run
into the recurring problem of circular dependencies (component A will
not build unless component B is built, and component B will not build
unless component A is built).

Bad separation of concerns. There are far too many examples of classes
that try to be everything to everyone. This makes debugging difficult,
and it makes maintenance/improvements a nightmare. [Using an analogy,
consider an automobile design where a spark plug is not separate from a
transmission. Instead, the automobile uses a spark-plug-transmission. So
when the engine is running rough because the spark plug is bad, you have
to replace the spark plug AND the transmission.] A good framework
example can be found in my rewrite of the mini-language code.
Originally, the models AND the script execution context both contained
script behaviors - making debugging/improvements difficult. I changed it
so only the models contain script behavior and the script execution
context contains only the script execution state.

Lack of good OO design. There are many places where a bit

Re: Why A Framework Rewrite Is Necessary

2015-10-14 Thread Sharan-F

 Hi Adrian

Thanks for bringing the framework topic up again as I've seen quite a few
disucussions about it but nothing has gained enough momentum to do anything
about it.

At Apachecon it was one of the main subjects that I wanted to raise because
it sounded like an " elephant in the room " topic (i;e ; something so big
and obvious that no one wants to look at). In the end we concluded to do
something on it even something small just to get some work started on it; 

I'm not a technical person so a lot of what you describe is a bit over my
head but thanks for including some good examples that at least give me a
feel for what the problem is ;

I think that some of the previous discussions have got caught up in defining
the solution before we'd agreed to fix the problem ; First we need to
acknowledge that we have a problem and second we need find out how many
people are willing to help fix it ;

I know that we have people in the community that are really motivated to do
work to help work on the framework ; and I think all that's missing (if we
decide to go ahead) will be planning and organisation ; (we plan what we
want to do and then break it down into tasks that people can pick up and
do) :

Personally I think you have made a really compelling and important  case and
I think we do have a really important problem that needs work and community
support. I would be happy to support it in whatever capacity I can;

Adrian - if the community does come out in support of a framework rewrite
;would you would be willing to help oversee it ? (as I think your input and
experience would be invaluable)

Thanks
Sharan





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673386.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Why A Framework Rewrite Is Necessary

2015-10-14 Thread Taher Alkhateeb

Hi Adrian, Sharan and everyone, 

Thank you so much for this great input. I wholeheartedly agree with a rewrite 
(that is so badly needed) and we had a few other threads trying to push that. 
Adrian if the ball gets rolling on the vision you put forward then count me in. 
I would absolutely love to be a part of this. 

Taher Alkhateeb. 

- Original Message -

From: "Sharan-F"  
To: dev@ofbiz.apache.org 
Sent: Wednesday, 14 October, 2015 11:27:19 PM 
Subject: Re: Why A Framework Rewrite Is Necessary 

Hi Adrian 

Thanks for bringing the framework topic up again as I've seen quite a few 
disucussions about it but nothing has gained enough momentum to do anything 
about it. 

At Apachecon it was one of the main subjects that I wanted to raise because 
it sounded like an " elephant in the room " topic (i;e ; something so big 
and obvious that no one wants to look at). In the end we concluded to do 
something on it even something small just to get some work started on it; 

I'm not a technical person so a lot of what you describe is a bit over my 
head but thanks for including some good examples that at least give me a 
feel for what the problem is ; 

I think that some of the previous discussions have got caught up in defining 
the solution before we'd agreed to fix the problem ; First we need to 
acknowledge that we have a problem and second we need find out how many 
people are willing to help fix it ; 

I know that we have people in the community that are really motivated to do 
work to help work on the framework ; and I think all that's missing (if we 
decide to go ahead) will be planning and organisation ; (we plan what we 
want to do and then break it down into tasks that people can pick up and 
do) : 

Personally I think you have made a really compelling and important case and 
I think we do have a really important problem that needs work and community 
support. I would be happy to support it in whatever capacity I can; 

Adrian - if the community does come out in support of a framework rewrite 
;would you would be willing to help oversee it ? (as I think your input and 
experience would be invaluable) 

Thanks 
Sharan 





-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673386.html
 
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Why A Framework Rewrite Is Necessary

2015-10-14 Thread Ron Wheeler

How much of the Foundation core either overlaps with Spring or could be
implemented using Spring?

How much of the design for an API has been thought out?
Are there other documents that give use cases and general instructions
for writing an application using the framework?
Is there any hypothetical code demonstrating how a developer could write
a trivial application with security, persistence, logging, etc. or is
the assumption that the current OFBiz framework API be preserved?

A sub-project under Apache OFBiz would be an alternative if the
community wanted to get behind a rewite.
This would allow people interested in framework concerns as opposed to
business applications to work together.

Ron

On 14/10/2015 3:21 PM, Adrian Crum wrote:
I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further
action on this subject, because I've brought it up before without
success, and I'm tired of discussing it. It is my hope that the light
bulb will click on in someone's head and they will take action.

My Background
-

I became a member of the OFBiz community in 2004. I immediately
started making contributions to the project by supplying patches to
the issue tracker. In 2007, I became a committer. Most of my initial
work was on the UI and some work in the applications (mainly Asset
Maintenance and Work Effort). I stayed away from touching the
framework code because it was deep, dark, and scary.

Eventually, I started to understand how the framework code works and I
made some minor modifications. As my understanding grew, I progressed
to rewriting large swaths of framework code - making it thread-safe,
fault tolerant, efficient, and easier to use.

I will list some of my contributions here, so everyone can have a
clear understanding of my experience with the framework code:

New Features

User Preferences

Visual Themes

Custom UI Label XML File Format

Temporal Expressions

Data Type Conversion Framework

Screen Widget Boundary Comments

Metrics

Integrations

UEL

iCalendar

JSR 223

WebDAV

LDAP

Refactorings/Improvements

FlexibleStringExpander

FlexibleMapExpander

FOP Integration

FreeMarkerWorker

Date-Time Handling

Mini-language

Job Scheduler

In addition, I have performed innumerable framework bug fixes.

So, the contents of this message come from years of experience mucking
about in the framework code.

Okay, let's get started...

Initial Problem Statement
-

In 2009, David Jones started a framework rewrite in a branch:

https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716

At the time, there was some agreement that a rewrite was necessary,
but there was disagreement as to how the rewrite should be
incorporated into the project:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3c455601.62605...@web63102.mail.re1.yahoo.com%3E

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cd24f129d-4f9f-444e-84af-aca46f499...@hotwaxmedia.com%3e

Despite an effort to convince David to proceed with the framework
rewrite, he ended up doing it in a separate project:

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3c07565c88-4023-4d24-93a3-a4906e86f...@me.com%3E

This page describes differences between OFBiz and Moqui, and within it
you can extract information on the problems David was trying to solve:

http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/

There was an email he sent out on the OFBiz dev list where he listed
the problems he saw in the framework, but I can't find it. The rest of
this message will include the issues he mentioned (the ones I
remember). I was in agreement with him at the time, and I still agree
that a framework rewrite is necessary.

The Problems

Code is scattered everywhere - due to an initial effort to make the
framework modular. This causes serious problems. The mere fact that
components like entityext and securityext EXIST makes it clear that
there are problems - those components should not be there. Also, we
run into the recurring problem of circular dependencies (component A
will not build unless component B is built, and component B will not
build unless component A is built).

Bad separation of concerns. There are far too many examples of classes
that try to be everything to everyone. This makes

Re: Java 8 and functional programming in trunk

2015-10-14 Thread Taher Alkhateeb

Hi Jacques, 

I am a bit confused? Why wait for a frozen branch for anything? I thought trunk 
is your development/unstable bleeding-edge part of the code. This is where you 
introduce changes without worrying about people's stable systems because they 
base their systems on release branches. In fact, branches exist only to 
stabilize trunk at certain points of time. 

Furthermore, if we introduce Java 8 into trunk, what possible logical reason 
exists for _voting_ to use the new features of the language? Why did you 
upgrade in the first place if you do not intend to use the newer features? 

Taher Alkhateeb 

- Original Message -

From: "Jacques Le Roux"  
To: dev@ofbiz.apache.org 
Sent: Wednesday, 14 October, 2015 12:23:31 PM 
Subject: Re: Java 8 and functional programming in trunk 

I tend to agree. Actually there are 2 points, 
1) use Java 8 to compile 
2) use new Java 8 features 

We can already do 1, but we should maybe wait the next freezed branch to do 2. 
That should be discussed but does not prevent 1. Of course any commit 
with 2 will be rejected as long as an agreement on 2 will not be reached 

Jacques 

Le 11/10/2015 19:09, Ron Wheeler a écrit : 
> I am not sure why backwards compatibility is an issue with moving to Java 8. 
> 
> It works well, 
> it is the supported version of Java. 
> As far as I have heard, the Java 8 JVM runs code compiled with earlier 
> versions of Java. (My own experience is uniformly positive). 
> 
> I can see no reason to think that anyone who is developing or using OFBiz 
> would need to compile or run with an older version of Java. 
> 
> In this day of VM and Docker Containers, it is hard to imagine that someone 
> would be stuck on an older JVM in a production environment and unable to 
> come up with a configuration that would allow them to run JVM 8 to support 
> OFBiz. 
> 
> IMHO, we should just move to requiring the supported version of Java as soon 
> as possible. 
> 
> Ron 
> 
> 
> On 11/10/2015 4:14 AM, Taher Alkhateeb wrote: 
>> Hello Everyone, 
>> 
>> We created and provided the patches for this issue since June and OFBiz is 
>> pretty much ready to move to JDK 8. I'm not sure if lazy consensus is 
>> enough or whether a vote is warranted to move this issue forward? 
>> 
>> Cheers, 
>> 
>> Taher Alkhateeb 
>> 
>> - Original Message - 
>> 
>> From: "Pierre Smits"  
>> To: dev@ofbiz.apache.org 
>> Sent: Thursday, 7 May, 2015 10:52:00 AM 
>> Subject: Re: Java 8 and functional programming in trunk 
>> 
>> I don't think that it is a question of using or not using J8. It is more 
>> about when to move it into trunk, as from that moment on there will be 
>> backward compatibility issues. 
>> A helpful solution in this respect could be to designate a specific release 
>> branch now (e.g. r15 or r16), create the version in JIRA and setup the dev 
>> branch in svn. Doing it that way J8 related issues can get registered, 
>> changes can get implemented and assessed (in the dev branch) without 
>> breaking current stuff in trunk. 
>> 
>> But it also ensures that we can create awareness prior to releasing stuff. 
>> 
>> Best regards, 
>> 
>> 
>> 
>> Pierre Smits 
>> 
>> *ORRTIZ.COM * 
>> Services & Solutions for Cloud- 
>> Based Manufacturing, Professional 
>> Services and Retail & Trade 
>> http://www.orrtiz.com 
>> 
>> On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin  
>> wrote: 
>> 
>>> Ok Thanks Scott and Jacques. 
>>> 
>>> So Who is against use java 8 and more on trunk ? 
>>> 
>>> :) 
>>> 
>>> Nicolas 
>>> 
>>> 
>>> Le 07/05/2015 08:46, Jacques Le Roux a écrit : 
>>> 
 Yes (lazy) consensus over vote ;) 
 
 Jacques 
 
 Le 07/05/2015 05:02, Scott Gray a écrit : 
 
> I'm not sure if a vote is necessary, particularly if no one has any 
> objections. 
> 
> Regards 
> Scott 
> On 7 May 2015 07:44, "Nicolas Malin"  wrote: 
> 
> I'm favorable to use java 8. 
>> I think it's will be pretty fin if you can support oracle jdk8 and 
>> openjdk8 also. 
>> 
>> I propose to organize a vote to validate or not this proposition 
>> 
>> Nicolas 
>> 
>> Le 03/05/2015 11:52, Jacques Le Roux a écrit : 
>> 
>> Hi Taher, 
>>> Yes I think so. For now well known (I hope ;)) security reasons, if 
>>> people want to use Oracle JDK they need to use Java 8. 
>>> So implementing with new Java 8 features now in trunk sounds good to 
>>> me. 
>>> BTW this is only my opinion... 
>>> 
>>> Note that our demos are still using OpenJDK 1.7 I'm not quite sure of 
>>> the 
>>> policy 
>>> 
>>> http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html
>>>  
>>> 
>>> 
>>> 
>>> Jacques 
>>> 
>>> 
>>> Le 03/05/2015 10:52, Taher Alkhateeb

Re: Moving groovy script files

2015-10-14 Thread Jacques Le Roux


Thanks Pierre,

I re-read it all, I think we are ready to begin, aren't we?

Jacques

Le 11/10/2015 10:02, Pierre Smits a écrit :

I think this is the tread:
http://ofbiz.markmail.org/message/25dse4jke2fp64mx

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Sun, Oct 11, 2015 at 6:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Pierre,

I can't clearly remember the arguments behind this.
Could you recall them, or better give us a link to this thread?

Thanks

Jacques

Le 09/10/2015 07:53, Pierre Smits a écrit :


Hi all,

A while ago we discussed moving groovy code from
//webapp//WEB-INF/actions/* to a location under
//src/*.

Did we get to a resolution on that, or are there still issues regarding
that?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

Re: Moving groovy script files

2015-10-14 Thread Pierre Smits

It is a code change, so there must be consensus (albeit lazy is applicable).

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Wed, Oct 14, 2015 at 12:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Pierre,
>
> I re-read it all, I think we are ready to begin, aren't we?
>
> Jacques
>
> Le 11/10/2015 10:02, Pierre Smits a écrit :
>
>> I think this is the tread:
>> http://ofbiz.markmail.org/message/25dse4jke2fp64mx
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *OFBiz Extensions Marketplace*
>> http://oem.ofbizci.net/oci-2/
>>
>> On Sun, Oct 11, 2015 at 6:45 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Hi Pierre,
>>>
>>> I can't clearly remember the arguments behind this.
>>> Could you recall them, or better give us a link to this thread?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> Le 09/10/2015 07:53, Pierre Smits a écrit :
>>>
>>> Hi all,

 A while ago we discussed moving groovy code from
 //webapp//WEB-INF/actions/* to a location under
 //src/*.

 Did we get to a resolution on that, or are there still issues regarding
 that?

 Best regards,

 Pierre Smits

 *OFBiz Extensions Marketplace*
 http://oem.ofbizci.net/oci-2/

Re: Why A Framework Rewrite Is Necessary

2015-10-14 Thread Adrian Crum

On 10/14/2015 2:09 PM, Ron Wheeler wrote:

How much of the Foundation core either overlaps with Spring or could be
implemented using Spring?

How much of the design for an API has been thought out?

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

Please take some time to follow the links I provided in my original message.

Are there other documents that give use cases and general instructions
for writing an application using the framework?
Is there any hypothetical code demonstrating how a developer could write
a trivial application with security, persistence, logging, etc. or is
the assumption that the current OFBiz framework API be preserved?

Ron

On 14/10/2015 3:21 PM, Adrian Crum wrote: