[jira] [Commented] (OFBIZ-7021) Rename .ftl file as per best practises

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-7021:


Actually I only renamed files, I'll need also to rename where they are called...

> Rename .ftl file as per best practises
> --
>
> Key: OFBIZ-7021
> URL: https://issues.apache.org/jira/browse/OFBIZ-7021
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Assignee: Jacques Le Roux
> Attachments: LowecaseFtlFileNames.txt
>
>
> Rename all the ftl file name into upper camel case pattern.



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

[jira] [Commented] (OFBIZ-7021) Rename .ftl file as per best practises

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-7021:


I have this done on Windows, but hè on Windows files have no case :/ So I need 
to do it on Linux... Soon...

> Rename .ftl file as per best practises
> --
>
> Key: OFBIZ-7021
> URL: https://issues.apache.org/jira/browse/OFBIZ-7021
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Assignee: Jacques Le Roux
> Attachments: LowecaseFtlFileNames.txt
>
>
> Rename all the ftl file name into upper camel case pattern.



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

[jira] [Assigned] (OFBIZ-7021) Rename .ftl file as per best practises

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux reassigned OFBIZ-7021:
--

Assignee: Jacques Le Roux  (was: Deepak Dixit)

> Rename .ftl file as per best practises
> --
>
> Key: OFBIZ-7021
> URL: https://issues.apache.org/jira/browse/OFBIZ-7021
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Assignee: Jacques Le Roux
> Attachments: LowecaseFtlFileNames.txt
>
>
> Rename all the ftl file name into upper camel case pattern.



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

[jira] [Assigned] (OFBIZ-6810) Refactor components regarding groovy and freemarker file locations

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux reassigned OFBIZ-6810:
--

Assignee: Jacques Le Roux  (was: Nicolas Malin)

> Refactor components regarding groovy and freemarker file locations
> --
>
> Key: OFBIZ-6810
> URL: https://issues.apache.org/jira/browse/OFBIZ-6810
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>
> This is a placeholder issue to capture all tasks and related issues regarding 
> the refactoring of the directory structure with respect to the location of 
> .groovy and .ftl (freemarker templates) files.
> See related discussion: http://ofbiz.markmail.org/message/25dse4jke2fp64mx



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

Wrong Completed Sprint

[Jacques Le Roux]

Hi,

I noticed that the new OFBIZ-7028 subtask of OFBIZ-1525 that I just created and 
closed was automatically included in

Completed Sprint:Bug Crush Event - 21/2/2015 
 ended 
26/Feb/15

This does not make sense, how to prevent this?

Thanks

Jacques

[jira] [Closed] (OFBIZ-7028) Use SecureRandom instead of Random where appropriate, and randomUUID for externalKey

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-7028.
--
   Resolution: Fixed
Fix Version/s: 13.07.04
   15.12.01
   14.12.01

Committed in
trunk r1741684  
R15.12 r1741687
R14.12 r1741688
R13.07 r1741689 (incomplete missing EntityCrypto, conflicts)




> Use SecureRandom instead of Random where appropriate, and randomUUID for 
> externalKey
> 
>
> Key: OFBIZ-7028
> URL: https://issues.apache.org/jira/browse/OFBIZ-7028
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> After a discussion we had privately with [~gdraperi]  (on PMC private ML) 
> some time ago, I decided to apply his recommended changes in appropriate 
> places.
> Quoting Grégory:
> {quote}
> I had a look to the source code and I would like to speak about how we use 
> Random and Math.Random() java classes.
> To give a little bit of context, these two functions are marked as unsecured 
> because if you are able to know one output you are able to predict the future 
> outputs.
> As a short overview random java function relies on a linear congruential 
> generator (a complex word for a simple thing). Reference 
> http://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/
> LCG works like this: (a * x + c) mod m where a,c and m are static values and 
> x is the previous output (except for the first output where we determine x 
> and it is called the seed)
> So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0,
> then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7,
> 6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (3 * 2 + 5) mod 7
> It means that if I know the last output (4) I can predict what will be the
> next output:
> (3 * 4 +5) mod 7 -> 3.
> We use a lot of Math.Random which relies on Random() class and also Random() 
> class itself especially in the LoginWorker class where it is used to generate 
> the external link id. At that time I have no real proven vulnerability but 
> that worries me for two things .
> # If it is possible to retrieve the state of Math.Random() from another place 
> in the code it will be possible to predict future links
> # Even if the link is complex and almost impossible to guess by brute force 
> we downgrade the security as the space of possible values for the link id is 
> really lower than the space for session id. Example: 
> 3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372
> The topic is not urgent but I would recommend in the future using 
> SecureRandom class and maybe UUID.randomUUID to generate the external link id
> --
> Grégory Draperi
> {quote}
> Because using SecureRandom comes with a cost, I have identified the places 
> where it's reasonable to keep the non secured Random (like tests, internal 
> sequences, etc.).
> Using UUID.randomUUID to generate the external link id seems also the best 
> possible solution.
> Also, though there are no real proven vulnerabilities, I decided to backport 
> as much as possible since it's now public.



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

[jira] [Updated] (OFBIZ-7028) Use SecureRandom instead of Random where appropriate, and randomUUID for externalKey

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-7028:
---
Description: 
After a discussion we had privately with [~gdraperi]  (on PMC private ML) some 
time ago, I decided to apply his recommended changes in appropriate places.

Quoting Grégory:
{quote}
I had a look to the source code and I would like to speak about how we use 
Random and Math.Random() java classes.

To give a little bit of context, these two functions are marked as unsecured 
because if you are able to know one output you are able to predict the future 
outputs.

As a short overview random java function relies on a linear congruential 
generator (a complex word for a simple thing). Reference 
http://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/

LCG works like this: (a * x + c) mod m where a,c and m are static values and x 
is the previous output (except for the first output where we determine x and it 
is called the seed)

So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0,
then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7,
6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (3 * 2 + 5) mod 7

It means that if I know the last output (4) I can predict what will be the
next output:
(3 * 4 +5) mod 7 -> 3.

We use a lot of Math.Random which relies on Random() class and also Random() 
class itself especially in the LoginWorker class where it is used to generate 
the external link id. At that time I have no real proven vulnerability but that 
worries me for two things .

# If it is possible to retrieve the state of Math.Random() from another place 
in the code it will be possible to predict future links
# Even if the link is complex and almost impossible to guess by brute force we 
downgrade the security as the space of possible values for the link id is 
really lower than the space for session id. Example: 
3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372

The topic is not urgent but I would recommend in the future using SecureRandom 
class and maybe UUID.randomUUID to generate the external link id

--
Grégory Draperi
{quote}

Because using SecureRandom comes with a cost, I have identified the places 
where it's reasonable to keep the non secured Random (like tests, internal 
sequences, etc.).
Using UUID.randomUUID to generate the external link id seems also the best 
possible solution.

Also, though there are no real proven vulnerabilities, I decided to backport as 
much as possible since it's now public.

  was:
After a discussion we had privately with [~gdraperi]  (on PMC private ML) some 
time ago, I decided to apply his recommended changes in appropriate places.

Quoting Grégory:
{quote}
I had a look to the source code and I would like to speak about how we use 
Random and Math.Random() java classes.

To give a little bit of context, these two functions are marked as unsecured 
because if you are able to know one output you are able to predict the future 
outputs.

As a short overview random java function relies on a linear congruential 
generator (a complex word for a simple thing). Reference 
http://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/

LCG works like this: (a * x + c) mod m where a,c and m are static values and x 
is the previous output (except for the first output where we determine x and it 
is called the seed)

So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0,
then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7,
6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (3 * 2 + 5) mod 7

It means that if I know the last output (4) I can predict what will be the
next output:
(3 * 4 +5) mod 7 -> 3.

We use a lot of Math.Random which relies on Random() class and also Random() 
class itself especially in the LoginWorker class where it is used to generate 
the external link id. At that time I have no real proven vulnerability but that 
worries me for two things .

# If it is possible to retrieve the state of Math.Random() from another place 
in the code it will be possible to predict future links
# Even if the link is complex and almost impossible to guess by brute force we 
downgrade the security as the space of possible values for the link id is 
really lower than the space for session id. Example: 
3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372

The topic is not urgent but I would recommend in the future using SecureRandom 
class and maybe UUID.randomUUID to generate the external link id

--
Grégory Draperi
{quote}

Because using SecureRandom comes with a cost, I have identified the places 
where it's reasonnable to keep the non secured Random (like tests, internal 
sequences, etc.).
Using UUID.randomUUID to generate the external link id seems also the best 
possible solution.

Also, though there are no real proven vulnerabilities, I decided to backport as

[jira] [Created] (OFBIZ-7028) Use SecureRandom instead of Random where appropriate, and

[Jacques Le Roux (JIRA)]

Jacques Le Roux created OFBIZ-7028:
--

 Summary: Use SecureRandom instead of Random where appropriate, and 
 Key: OFBIZ-7028
 URL: https://issues.apache.org/jira/browse/OFBIZ-7028
 Project: OFBiz
  Issue Type: Sub-task
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Minor


After a discussion we had privately with [~gdraperi]  (on PMC private ML) some 
time ago, I decided to apply his recommended changes in appropriate places.

Quoting Grégory:
{quote}
I had a look to the source code and I would like to speak about how we use 
Random and Math.Random() java classes.

To give a little bit of context, these two functions are marked as unsecured 
because if you are able to know one output you are able to predict the future 
outputs.

As a short overview random java function relies on a linear congruential 
generator (a complex word for a simple thing). Reference 
http://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/

LCG works like this: (a * x + c) mod m where a,c and m are static values and x 
is the previous output (except for the first output where we determine x and it 
is called the seed)

So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0,
then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7,
6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (3 * 2 + 5) mod 7

It means that if I know the last output (4) I can predict what will be the
next output:
(3 * 4 +5) mod 7 -> 3.

We use a lot of Math.Random which relies on Random() class and also Random() 
class itself especially in the LoginWorker class where it is used to generate 
the external link id. At that time I have no real proven vulnerability but that 
worries me for two things .

# If it is possible to retrieve the state of Math.Random() from another place 
in the code it will be possible to predict future links
# Even if the link is complex and almost impossible to guess by brute force we 
downgrade the security as the space of possible values for the link id is 
really lower than the space for session id. Example: 
3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372

The topic is not urgent but I would recommend in the future using SecureRandom 
class and maybe UUID.randomUUID to generate the external link id

--
Grégory Draperi
{quote}

Because using SecureRandom comes with a cost, I have identified the places 
where it's reasonnable to keep the non secured Random (like tests, internal 
sequences, etc.).
Using UUID.randomUUID to generate the external link id seems also the best 
possible solution.

Also, though there are no real proven vulnerabilities, I decided to backport as 
much as possible since it's now public.



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

[jira] [Updated] (OFBIZ-7028) Use SecureRandom instead of Random where appropriate, and randomUUID for externalKey

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-7028:
---
Summary: Use SecureRandom instead of Random where appropriate, and 
randomUUID for externalKey  (was: Use SecureRandom instead of Random where 
appropriate, and )

> Use SecureRandom instead of Random where appropriate, and randomUUID for 
> externalKey
> 
>
> Key: OFBIZ-7028
> URL: https://issues.apache.org/jira/browse/OFBIZ-7028
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion we had privately with [~gdraperi]  (on PMC private ML) 
> some time ago, I decided to apply his recommended changes in appropriate 
> places.
> Quoting Grégory:
> {quote}
> I had a look to the source code and I would like to speak about how we use 
> Random and Math.Random() java classes.
> To give a little bit of context, these two functions are marked as unsecured 
> because if you are able to know one output you are able to predict the future 
> outputs.
> As a short overview random java function relies on a linear congruential 
> generator (a complex word for a simple thing). Reference 
> http://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/
> LCG works like this: (a * x + c) mod m where a,c and m are static values and 
> x is the previous output (except for the first output where we determine x 
> and it is called the seed)
> So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0,
> then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7,
> 6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (3 * 2 + 5) mod 7
> It means that if I know the last output (4) I can predict what will be the
> next output:
> (3 * 4 +5) mod 7 -> 3.
> We use a lot of Math.Random which relies on Random() class and also Random() 
> class itself especially in the LoginWorker class where it is used to generate 
> the external link id. At that time I have no real proven vulnerability but 
> that worries me for two things .
> # If it is possible to retrieve the state of Math.Random() from another place 
> in the code it will be possible to predict future links
> # Even if the link is complex and almost impossible to guess by brute force 
> we downgrade the security as the space of possible values for the link id is 
> really lower than the space for session id. Example: 
> 3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372
> The topic is not urgent but I would recommend in the future using 
> SecureRandom class and maybe UUID.randomUUID to generate the external link id
> --
> Grégory Draperi
> {quote}
> Because using SecureRandom comes with a cost, I have identified the places 
> where it's reasonnable to keep the non secured Random (like tests, internal 
> sequences, etc.).
> Using UUID.randomUUID to generate the external link id seems also the best 
> possible solution.
> Also, though there are no real proven vulnerabilities, I decided to backport 
> as much as possible since it's now public.



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

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

Taher Alkhateeb commented on OFBIZ-6783:


Hi Jacopo,

I was thinking that something else might need the commons-cli in the framework 
and so preferred keeping it in base. But anyway, no problem I can keep it in 
start. Either way, I need to modify start's build.xml to include the class-path 
in the jar construction otherwise it will not work (because ofbiz.jar is 
_copied_ to root)

Since you opened this subject up anyway, the radical idea I have in mind is to 
actually (more or less) eliminate the idea of components entirely in 
/framework. I think the framework should be one independent thing that loads 
other components. Anyway, I will compile my thoughts on this and discuss it at 
a later stage on the mailing list in the future.

> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacopo Cappellato (JIRA)]

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

Jacopo Cappellato commented on OFBIZ-6783:
--

Hi Taher,

I am not sure about the first point since the start component has been built to 
be independent (or sort of) from the base component... we may want to maintain 
this and have commons-cli in the start component.

> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



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

[jira] [Commented] (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-3379:


Could someone please check that OFBIZ-5732 did not fix this? Thanks!

> Email sending process using one connection for To/CC/BCC causing issues
> ---
>
> Key: OFBIZ-3379
> URL: https://issues.apache.org/jira/browse/OFBIZ-3379
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 09.04, Trunk
>Reporter: Pranay Pandey
>Assignee: Scott Gray
> Attachments: OFBIZ-3379-2.patch, OFBIZ-3379.patch, OFBIZ-3379.patch, 
> OFBIZ-3379.patch
>
>
> Typically BCCs are handled via the sending mail client. That is, when the 
> client sees a BCC in an email, it will open up two connections to the mail 
> server, the first for the To/CC fields, the second for BCC fields, this way 
> the addresses are masked from the headers and there is that layer of 
> anonymity that BCC is used for.
> What appears to be happening is that OFBiz is sending all of the information 
> in one connection to the mail server and having the mail server sort out the 
> details. So when sendTo encountering an invalid email, and then terminating 
> the remaining execution of the outgoing process and no email sent to BCC 
> address which is usually going to be a valid address from email settings for 
> the company.
> To fix the issue, we need to send this via two connection to mail client.



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

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

Taher Alkhateeb commented on OFBIZ-6783:


Thank you gentlemen. Patch is committed in r1741624.

The next items I have in mind for this JIRA is the following:
- To introduce commons-cli. I will keep it in the base component but refer to 
it from start
- To remove dependencies from other classes into Start.java. NOTHING should 
point to Start.java
- I am thinking of creating an OfbizCommand interface for executing the 
commands. Start.java should be a very small high level execution of the 
framework with all details hidden away.
- some code need to be simplified

> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacopo Cappellato (JIRA)]

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

Jacopo Cappellato commented on OFBIZ-6783:
--

Looks good.

> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


Hi Taher,

Thanks for the detailled explanations. After review and few tests, all your 
changes are OK with me. I agree about using commons-cli

> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



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

[jira] [Updated] (OFBIZ-6775) Duplicated to display jGrowl error message when open a popup dialog.

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-6775:
---
Fix Version/s: Upcoming Branch

Fixed by Zhang at r1720728

> Duplicated to display jGrowl error message when open a popup dialog.
> 
>
> Key: OFBIZ-6775
> URL: https://issues.apache.org/jira/browse/OFBIZ-6775
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: Duplicated jGrowl Error.png
>
>
> See the screen below.
> !Duplicated jGrowl Error.png!



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

[jira] [Commented] (OFBIZ-6761) The action of EditExampleBackgroundSubmit form is not correct when creating a example

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6761:


Fixed by Zhang at r1719024

> The action of EditExampleBackgroundSubmit form is not correct when creating a 
> example
> -
>
> Key: OFBIZ-6761
> URL: https://issues.apache.org/jira/browse/OFBIZ-6761
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/example
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: actionOfCreatingExample.png
>
>
> See the wrong action in the attached screen
> !actionOfCreatingExample.png!
> The expected action is createExampleAjax



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

[jira] [Updated] (OFBIZ-6762) Show JGrowl alert when using ajax submit form

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-6762:
---
Fix Version/s: (was: Trunk)
   Upcoming Branch

Fixed in trunk by Zhang at r1719250

> Show JGrowl alert when using ajax submit form
> -
>
> Key: OFBIZ-6762
> URL: https://issues.apache.org/jira/browse/OFBIZ-6762
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: ajaxSubmitFormAlert.png, ajaxSubmitFormJGrowlAlert.png
>
>
> The current alert for ajax submit form is like below
> !ajaxSubmitFormAlert.png!
> and the improved  alert should be 
> !ajaxSubmitFormJGrowlAlert.png!



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

[jira] [Updated] (OFBIZ-6761) The action of EditExampleBackgroundSubmit form is not correct when creating a example

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-6761:
---
Fix Version/s: (was: Trunk)
   Upcoming Branch

> The action of EditExampleBackgroundSubmit form is not correct when creating a 
> example
> -
>
> Key: OFBIZ-6761
> URL: https://issues.apache.org/jira/browse/OFBIZ-6761
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/example
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: actionOfCreatingExample.png
>
>
> See the wrong action in the attached screen
> !actionOfCreatingExample.png!
> The expected action is createExampleAjax



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

[jira] [Updated] (OFBIZ-6736) The attribute paginate-style of form widget does not work

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-6736:
---
Summary: The attribute paginate-style of form widget does not work  (was: 
The attribute paginate-style of form widget dose not work)

> The attribute paginate-style of form widget does not work
> -
>
> Key: OFBIZ-6736
> URL: https://issues.apache.org/jira/browse/OFBIZ-6736
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
> Fix For: 14.12.01
>
>
> If I set my paginate-style with following code 
> {code:xml}
>  paginate-target="FindExample" default-entity-name="Example" 
> separate-columns="true"
> odd-row-style="alternate-row" header-row-style="header-row-2" 
> default-table-style="basic-table hover-bar" paginate-style="my-style">
> {code}
> The output html code in browser is :
> {code:xml}
> 
> {code}  
> But the expected output should be:
> 



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

[jira] [Updated] (OFBIZ-6736) The attribute paginate-style of form widget dose not work

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-6736:
---
Fix Version/s: (was: Trunk)
   14.12.01

> The attribute paginate-style of form widget dose not work
> -
>
> Key: OFBIZ-6736
> URL: https://issues.apache.org/jira/browse/OFBIZ-6736
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
> Fix For: 14.12.01
>
>
> If I set my paginate-style with following code 
> {code:xml}
>  paginate-target="FindExample" default-entity-name="Example" 
> separate-columns="true"
> odd-row-style="alternate-row" header-row-style="header-row-2" 
> default-table-style="basic-table hover-bar" paginate-style="my-style">
> {code}
> The output html code in browser is :
> {code:xml}
> 
> {code}  
> But the expected output should be:
> 



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

[jira] [Updated] (OFBIZ-5732) Error in sendMailHiddenInLog service

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-5732:
---
Fix Version/s: (was: Trunk)
   13.07.04
   15.12.01
   14.12.01

Fixed in trunk by Wei at r1741563

Backported by [~jacques.le.roux] in
R15.12 r1741593
R14.12 r1741594
R13.07 r1741595



> Error in sendMailHiddenInLog service
> 
>
> Key: OFBIZ-5732
> URL: https://issues.apache.org/jira/browse/OFBIZ-5732
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> I got the following error when calling sendMailHiddenInLog, see the errors 
> below.
> {code}
> 2014-08-27 02:18:41,395 (OFBiz-JobQueue-0) [  
> ServiceDispatcher.java:550:ERROR]
>  exception report 
> --
> Could not commit transaction for service [sendMailHiddenInLog] call
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled back 
> instead because of: Service [sendMailMultiPart] threw an unexpected 
> exception/errororg.ofbiz.service.ServiceValidationException: The following 
> required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The 
> following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])
>  cause 
> -
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts]
>  stack trace 
> ---
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> org.ofbiz.service.ModelService.validate(ModelService.java:630)
> org.ofbiz.service.ModelService.validate(ModelService.java:572)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:667)
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:349)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69)
> org.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> 
> {code}
> I think we should miss the code below before line 667 in EmailServices.java
> {code}
> newContext.put("bodyParts", bodyParts);
> {code}



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

[jira] [Commented] (OFBIZ-7024) Attribute 'placeholder' is not allowed to appear in element 'text'

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-7024:


Hi Wei,

Some tips when you fix:
* An improvement, you don't need to backport but remember to put a comment in 
the Jira issuer with the commit number. Also just put "Upcoming Branch" in the 
fix version
* A bug, you should try to backport as much as possible (not an obligation, 
please be sure to read 
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities).
 If you only commit in trunk, just put "Upcoming Branch" in the fix version. If 
you backport don't put "Upcoming Branch" in the fix version but the next 
release version/s which will be impacted (you find them in the "Unreleased 
List")

Thanks!

> Attribute 'placeholder' is not allowed to appear in element 'text'
> --
>
> Key: OFBIZ-7024
> URL: https://issues.apache.org/jira/browse/OFBIZ-7024
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> The placeholder attribute is not defined in widget-form.xsd



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

[jira] [Commented] (OFBIZ-7024) Attribute 'placeholder' is not allowed to appear in element 'text'

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-7024:


Committed by Wei (should I say Zhang rather?) in trunk at r1741146

Backported by myself in 
R15.12 r1741591
R14.12 r1741589
R13.07 r1741590



> Attribute 'placeholder' is not allowed to appear in element 'text'
> --
>
> Key: OFBIZ-7024
> URL: https://issues.apache.org/jira/browse/OFBIZ-7024
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> The placeholder attribute is not defined in widget-form.xsd



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

[jira] [Updated] (OFBIZ-7024) Attribute 'placeholder' is not allowed to appear in element 'text'

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-7024:
---
Fix Version/s: (was: Upcoming Branch)

> Attribute 'placeholder' is not allowed to appear in element 'text'
> --
>
> Key: OFBIZ-7024
> URL: https://issues.apache.org/jira/browse/OFBIZ-7024
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> The placeholder attribute is not defined in widget-form.xsd



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

[jira] [Updated] (OFBIZ-7024) Attribute 'placeholder' is not allowed to appear in element 'text'

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-7024:
---
Fix Version/s: (was: Trunk)
   13.07.04
   15.12.01
   Upcoming Branch
   14.12.01

> Attribute 'placeholder' is not allowed to appear in element 'text'
> --
>
> Key: OFBIZ-7024
> URL: https://issues.apache.org/jira/browse/OFBIZ-7024
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
>Priority: Minor
> Fix For: 14.12.01, Upcoming Branch, 15.12.01, 13.07.04
>
>
> The placeholder attribute is not defined in widget-form.xsd



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

[jira] [Closed] (OFBIZ-5732) Error in sendMailHiddenInLog service

[Wei Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Zhang closed OFBIZ-5732.

   Resolution: Fixed
 Assignee: Wei Zhang
Fix Version/s: Trunk

done

> Error in sendMailHiddenInLog service
> 
>
> Key: OFBIZ-5732
> URL: https://issues.apache.org/jira/browse/OFBIZ-5732
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Wei Zhang
> Fix For: Trunk
>
>
> I got the following error when calling sendMailHiddenInLog, see the errors 
> below.
> {code}
> 2014-08-27 02:18:41,395 (OFBiz-JobQueue-0) [  
> ServiceDispatcher.java:550:ERROR]
>  exception report 
> --
> Could not commit transaction for service [sendMailHiddenInLog] call
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled back 
> instead because of: Service [sendMailMultiPart] threw an unexpected 
> exception/errororg.ofbiz.service.ServiceValidationException: The following 
> required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The 
> following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])
>  cause 
> -
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts]
>  stack trace 
> ---
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> org.ofbiz.service.ModelService.validate(ModelService.java:630)
> org.ofbiz.service.ModelService.validate(ModelService.java:572)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:667)
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:349)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69)
> org.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> 
> {code}
> I think we should miss the code below before line 667 in EmailServices.java
> {code}
> newContext.put("bodyParts", bodyParts);
> {code}



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