[jira] [Created] (OFBIZ-9578) Collection added to itself
JC created OFBIZ-9578:
-
Summary: Collection added to itself
Key: OFBIZ-9578
URL: https://issues.apache.org/jira/browse/OFBIZ-9578
Project: OFBiz
Issue Type: Bug
Components: framework
Reporter: JC
Priority: Trivial
Hi
In a recent github mirror, I've found suspicious code.
Branch: master
path:
framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/DatabaseUtil.java
{code:java}
...
1588 protected final List messages = new LinkedList();
...
1596 protected int updateData(Collection messages) {
1597 if (messages != null &&
UtilValidate.isNotEmpty(this.messages)) {
1598 messages.addAll(messages);
1599 }
1600 return count;
1601 }
1602 }
{code}
In Line 1598, `messages.addAll' should be `this.messages.addAll'? This might
not be an issue but I wanted to report this just in case.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OFBIZ-9306) Check there are no white spaces around the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9306: --- Attachment: OFBIZ-9306-ModelFormField.java.patch Michael, Oh right, a new pair of eyes was needed, I did not consider the code above. Here is a new patch. BTW I wonder what happens when we get null there. I did not check calling locations, I guess it's OK. > Check there are no white spaces around the name of a form field when updating > a form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch, > OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9306) Check there are no white spaces around the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126120#comment-16126120 ] Michael Brohl commented on OFBIZ-9306: -- Jacques, if returnValue is null, you'll get a NullPointerException... > Check there are no white spaces around the name of a form field when updating > a form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9571) [DEPRECATION] Replace BigDecimal.ROUND_* by RoundingMode.*
[ https://issues.apache.org/jira/browse/OFBIZ-9571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125368#comment-16125368 ] Jacques Le Roux commented on OFBIZ-9571: In a 1st step at revision: 1804953, I did an easy global replacement. But it also needs to import the RoundingMode class. It was 26 files so I decided to rather clean all the imports in all files with the help of Eclipse. In a 2nd step, I will need to closely look at 2 special class: UtilNumber and Calculate. > [DEPRECATION] Replace BigDecimal.ROUND_* by RoundingMode.* > -- > > Key: OFBIZ-9571 > URL: https://issues.apache.org/jira/browse/OFBIZ-9571 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Upcoming Release > > > 3 years ago I wrote about that in dev ML: https://s.apache.org/EVxA > bq. I just read at > http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html : < the integer fields in this class (such as > [ROUND_HALF_UP|http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#ROUND_HALF_UP]) > to represent rounding mode is largely obsolete; the enumeration values of > the RoundingMode enum, (such as > [RoundingMode.HALF_UP|http://docs.oracle.com/javase/7/docs/api/java/math/RoundingMode.html#HALF_UP]) > should be used instead. > It's time for action... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9400) GenericServiceJob.failed(Throwable) avoid logging stacktraces for non technical service semaphore exceptions
[ https://issues.apache.org/jira/browse/OFBIZ-9400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9400: -- Assignee: Jacques Le Roux > GenericServiceJob.failed(Throwable) avoid logging stacktraces for non > technical service semaphore exceptions > > > Key: OFBIZ-9400 > URL: https://issues.apache.org/jira/browse/OFBIZ-9400 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Martin Becker >Assignee: Jacques Le Roux >Priority: Trivial > Attachments: OFBIZ-9400_GenericServiceJobAvoidStacktraceLog.patch > > > GenericServicejob.failed(...) logs a stacktrace on every SemaphoreWait and > SemaphoreFail exception. The patch changes this for the non-technical service > semaphore exceptions to a one liner error logging to avoid polluting the > logfile with stacktraces e.g. in a scenario where a service is scheduled in > short intervals and fails expected while the former one is still running. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyra Pritzel-Hentley updated OFBIZ-9486: Attachment: OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch I have added the private modifier to the validIn and validOut variables in RitaApi and PcChargeApi > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch, > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyra Pritzel-Hentley updated OFBIZ-9486: Flags: Patch > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyra Pritzel-Hentley updated OFBIZ-9486: Attachment: OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch This patch resolves the bugs found in package org.apache.ofbiz.accounting.thirdparty.gosoftware. The Nullchecks in RitaServices at Lines 61, 164, 233, 301 are not redundant and were not fixed since the methods buildPccProperties(context, delegator) and getApi(props, "CREDIT") in lines 59 and 60 respectively may return null. > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125523#comment-16125523 ] Kyra Pritzel-Hentley commented on OFBIZ-9486: - Hello Jacques, I removed the modifier because FindBugs suggested to make the variables package protected. But it would make a lot of sense as well to go one step further, as you say, and make them private. Then nothing can have influence on these variables from the outside. > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125425#comment-16125425 ] Jacques Le Roux commented on OFBIZ-9486: Same for RitaApi. > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125423#comment-16125423 ] Jacques Le Roux commented on OFBIZ-9486: Hi Kyra, I did not review all, but why did you remove protected for validOut and validIn in PcChargeApi class? BTW they are only used in PcChargeApi class, so I'd rather make them private. > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9397) New UtilMisc method collectionToString(...) building safely a String with the given collection and delimiter
[ https://issues.apache.org/jira/browse/OFBIZ-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9397. -- Resolution: Implemented Fix Version/s: Upcoming Release Thanks Martin, Your patch is in trunk at revision: 1804970 > New UtilMisc method collectionToString(...) building safely a String with the > given collection and delimiter > > > Key: OFBIZ-9397 > URL: https://issues.apache.org/jira/browse/OFBIZ-9397 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Martin Becker >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Upcoming Release > > Attachments: OFBIZ-9397_UtilMiscCollectionToString.patch > > > The added method UtilMisc.collectionToString(Collection values, String > delimiter) creates a String from the values of a collection, separated with > the given delimiter. This is done in a safe way without a "null" literal. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
Jacques Le Roux created OFBIZ-9572: -- Summary: Replace all "BigDecimal ZERO" by BigDecimal.ZERO Key: OFBIZ-9572 URL: https://issues.apache.org/jira/browse/OFBIZ-9572 Project: OFBiz Issue Type: Improvement Reporter: Jacques Le Roux Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9572: --- Description: Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. This should not be done when setScale() is used on the ZERO constant was:Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-9571) [DEPRECATION] Replace BigDecimal.ROUND_* by RoundingMode.*
[ https://issues.apache.org/jira/browse/OFBIZ-9571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125368#comment-16125368 ] Jacques Le Roux edited comment on OFBIZ-9571 at 8/14/17 9:37 AM: - In a 1st step at revision: 1804953, I did an easy global replacement. But it also needs to import the RoundingMode class. It was 26 files so I decided to rather clean all the imports in all files with the help of Eclipse. In a 2nd step, I will need to closely look at 2 special classes: UtilNumber and Calculate. was (Author: jacques.le.roux): In a 1st step at revision: 1804953, I did an easy global replacement. But it also needs to import the RoundingMode class. It was 26 files so I decided to rather clean all the imports in all files with the help of Eclipse. In a 2nd step, I will need to closely look at 2 special class: UtilNumber and Calculate. > [DEPRECATION] Replace BigDecimal.ROUND_* by RoundingMode.* > -- > > Key: OFBIZ-9571 > URL: https://issues.apache.org/jira/browse/OFBIZ-9571 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Upcoming Release > > > 3 years ago I wrote about that in dev ML: https://s.apache.org/EVxA > bq. I just read at > http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html : < the integer fields in this class (such as > [ROUND_HALF_UP|http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#ROUND_HALF_UP]) > to represent rounding mode is largely obsolete; the enumeration values of > the RoundingMode enum, (such as > [RoundingMode.HALF_UP|http://docs.oracle.com/javase/7/docs/api/java/math/RoundingMode.html#HALF_UP]) > should be used instead. > It's time for action... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9400) GenericServiceJob.failed(Throwable) avoid logging stacktraces for non technical service semaphore exceptions
[ https://issues.apache.org/jira/browse/OFBIZ-9400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9400. -- Resolution: Implemented Fix Version/s: Upcoming Release Thanks Martin, Your patch is in trunk at revision: 1804962 > GenericServiceJob.failed(Throwable) avoid logging stacktraces for non > technical service semaphore exceptions > > > Key: OFBIZ-9400 > URL: https://issues.apache.org/jira/browse/OFBIZ-9400 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Martin Becker >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Upcoming Release > > Attachments: OFBIZ-9400_GenericServiceJobAvoidStacktraceLog.patch > > > GenericServicejob.failed(...) logs a stacktrace on every SemaphoreWait and > SemaphoreFail exception. The patch changes this for the non-technical service > semaphore exceptions to a one liner error logging to avoid polluting the > logfile with stacktraces e.g. in a scenario where a service is scheduled in > short intervals and fails expected while the former one is still running. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9397) New UtilMisc method collectionToString(...) building safely a String with the given collection and delimiter
[ https://issues.apache.org/jira/browse/OFBIZ-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9397: -- Assignee: Jacques Le Roux > New UtilMisc method collectionToString(...) building safely a String with the > given collection and delimiter > > > Key: OFBIZ-9397 > URL: https://issues.apache.org/jira/browse/OFBIZ-9397 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Martin Becker >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Upcoming Release > > Attachments: OFBIZ-9397_UtilMiscCollectionToString.patch > > > The added method UtilMisc.collectionToString(Collection values, String > delimiter) creates a String from the values of a collection, separated with > the given delimiter. This is done in a safe way without a "null" literal. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9394) FileUtil.java: New method to get absolute path from given relative path on base of ofbiz.home dir
[ https://issues.apache.org/jira/browse/OFBIZ-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125309#comment-16125309 ] Jacques Le Roux commented on OFBIZ-9394: That's right Deepak, but I find Martin's proposition logical because we somehow miss a such function in it's most logical place: FileUtil class. Now I don't have a strong opinion about that. Maybe we could discuss on dev ML... > FileUtil.java: New method to get absolute path from given relative path on > base of ofbiz.home dir > - > > Key: OFBIZ-9394 > URL: https://issues.apache.org/jira/browse/OFBIZ-9394 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Martin Becker >Priority: Trivial > Attachments: OFBIZ-9394_absolutePathOfbizHome.patch > > > This patch adds a method getAbsolutePathWithOfbizHome(String filename) to > FileUtil.java. It returns by the given filename the absolute path starting > with "ofbiz.home". Note that a quite similar method already exists in > UtilURL.fromOfbizHomePath(String filename). > While both methods share similar code, the idea of extracting the duplicated > code into another method or even class results in unnecessary imports (one or > the other has to hold such a method and the other has to import the holding > class) and thus has not been and shouldn't be done in the future. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9306) Check there are no white spaces in the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9306: -- Assignee: Jacques Le Roux > Check there are no white spaces in the name of a form field when updating a > form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9558) Manage deprecated service on the ModelService
[ https://issues.apache.org/jira/browse/OFBIZ-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125591#comment-16125591 ] Jacques Le Roux commented on OFBIZ-9558: I'm waiting a bit in this thread http://markmail.org/message/ofwvwe2tgsxckptr (Pony Mail does not have it all, yet?) before writing the rules in the wiki page > Manage deprecated service on the ModelService > - > > Key: OFBIZ-9558 > URL: https://issues.apache.org/jira/browse/OFBIZ-9558 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Attachments: OFBIZ-9558.patch, OFBIZ-9558.patch > > > Following the thread > https://lists.apache.org/thread.html/ce4f9899d811208b8ecbc0a6bdc99a47057dfcd354f932a879aa947b@%3Cdev.ofbiz.apache.org%3E > on how manage the deprecated service we started on the idea : > * create a new element deprecated on services.xsd with attribute > * * use-instead : what service replace the current > * * since > * * and content element as reason of the deprecation > * alert in log warning each call on this service > * set "@deprecated" on the service List in webtools and inform on detail > service page. > The patch contains this feature -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9558) Manage deprecated service on the ModelService
[ https://issues.apache.org/jira/browse/OFBIZ-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9558: --- Description: Following the thread https://s.apache.org/6PzU on how manage the deprecated service we started on the idea : * create a new element deprecated on services.xsd with attribute * * use-instead : what service replace the current * * since * * and content element as reason of the deprecation * alert in log warning each call on this service * set "@deprecated" on the service List in webtools and inform on detail service page. The patch contains this feature was: Following the thread https://lists.apache.org/thread.html/ce4f9899d811208b8ecbc0a6bdc99a47057dfcd354f932a879aa947b@%3Cdev.ofbiz.apache.org%3E on how manage the deprecated service we started on the idea : * create a new element deprecated on services.xsd with attribute * * use-instead : what service replace the current * * since * * and content element as reason of the deprecation * alert in log warning each call on this service * set "@deprecated" on the service List in webtools and inform on detail service page. The patch contains this feature > Manage deprecated service on the ModelService > - > > Key: OFBIZ-9558 > URL: https://issues.apache.org/jira/browse/OFBIZ-9558 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Attachments: OFBIZ-9558.patch, OFBIZ-9558.patch > > > Following the thread https://s.apache.org/6PzU on how manage the deprecated > service we started on the idea : > * create a new element deprecated on services.xsd with attribute > * * use-instead : what service replace the current > * * since > * * and content element as reason of the deprecation > * alert in log warning each call on this service > * set "@deprecated" on the service List in webtools and inform on detail > service page. > The patch contains this feature -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9574) [FB] Package org.apache.ofbiz.base.test
[ https://issues.apache.org/jira/browse/OFBIZ-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-9574: - Attachment: OFBIZ-9574_org.apache.ofbiz.base.test_bugfixes.patch - fixed Diamond Operators did nothing else, everything seems intended as it is, even though findbugs doesn't like it like that. there were no critical bugs and errors too > [FB] Package org.apache.ofbiz.base.test > --- > > Key: OFBIZ-9574 > URL: https://issues.apache.org/jira/browse/OFBIZ-9574 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-9574_org.apache.ofbiz.base.test_bugfixes.patch > > > - GenericTestCaseBase.java:47, UC_USELESS_OBJECT > Useless object created > Our analysis shows that this object is useless. It's created and modified, > but its value never go outside of the method or produce any side-effect. > Either there is a mistake and object was intended to be used or it can be > removed. > This analysis rarely produces false-positives. Common false-positive cases > include: > - This object used to implicitly throw some obscure exception. > - This object used as a stub to generalize the code. > - This object used to hold strong references to weak/soft-referenced objects. > - GenericTestCaseBase.java:99, NP_LOAD_OF_KNOWN_NULL_VALUE > NP: Load of known null value in > org.apache.ofbiz.base.test.GenericTestCaseBase.assertNotEquals(String, > Object, Object) > The variable referenced at this point is known to be null due to an earlier > check against null. Although this is valid, it might be a mistake (perhaps > you intended to refer to a different variable, or perhaps the earlier check > to see if the variable is null should have been a check to see if it was > non-null). > - GenericTestCaseBase.java:99, NP_LOAD_OF_KNOWN_NULL_VALUE > NP: Load of known null value in > org.apache.ofbiz.base.test.GenericTestCaseBase.assertNotEquals(String, > Object, Object) > The variable referenced at this point is known to be null due to an earlier > check against null. Although this is valid, it might be a mistake (perhaps > you intended to refer to a different variable, or perhaps the earlier check > to see if the variable is null should have been a check to see if it was > non-null). > - GenericTestCaseBase.java:327, NP_LOAD_OF_KNOWN_NULL_VALUE > NP: Load of known null value in > org.apache.ofbiz.base.test.GenericTestCaseBase.assertEquals(String, Object, > Object) > The variable referenced at this point is known to be null due to an earlier > check against null. Although this is valid, it might be a mistake (perhaps > you intended to refer to a different variable, or perhaps the earlier check > to see if the variable is null should have been a check to see if it was > non-null). > - GenericTestCaseBase.java:334, NP_LOAD_OF_KNOWN_NULL_VALUE > NP: Load of known null value in > org.apache.ofbiz.base.test.GenericTestCaseBase.assertEquals(String, Object, > Object) > The variable referenced at this point is known to be null due to an earlier > check against null. Although this is valid, it might be a mistake (perhaps > you intended to refer to a different variable, or perhaps the earlier check > to see if the variable is null should have been a check to see if it was > non-null). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9576) [FB] Package org.apache.ofbiz.base.util.cache.test
Dennis Balkir created OFBIZ-9576:
Summary: [FB] Package org.apache.ofbiz.base.util.cache.test
Key: OFBIZ-9576
URL: https://issues.apache.org/jira/browse/OFBIZ-9576
Project: OFBiz
Issue Type: Sub-task
Components: base
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor
- UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition is
final but declares protected field
org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition.newValue
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
- UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal is final
but declares protected field
org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal.oldValue
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
- UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is final
but declares protected field
org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.newValue
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
- UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is final
but declares protected field
org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.oldValue
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
- UtilCacheTests.java:39, SE_NO_SUITABLE_CONSTRUCTOR
Se: org.apache.ofbiz.base.util.cache.test.UtilCacheTests is Serializable but
its superclass doesn't define an accessible void constructor
This class implements the Serializable interface and its superclass does not.
When such an object is deserialized, the fields of the superclass need to be
initialized by invoking the void constructor of the superclass. Since the
superclass does not have one, serialization and deserialization will fail at
runtime.
- UtilCacheTests.java:39, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.base.util.cache.test.UtilCacheTests is Serializable;
consider declaring a serialVersionUID
This class implements the Serializable interface, but does not define a
serialVersionUID field. A change as simple as adding a reference to a .class
object will add synthetic fields to the class, which will unfortunately change
the implicit serialVersionUID (e.g., adding a reference to String.class will
generate a static field class$java$lang$String). Also, different source code to
bytecode compilers may use different naming conventions for synthetic variables
generated for references to class objects or inner classes. To ensure
interoperability of Serializable across versions, consider adding an explicit
serialVersionUID.
- UtilCacheTests.java:148, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Listener defines
equals and uses Object.hashCode()
This class overrides equals(Object), but does not override hashCode(), and
inherits the implementation of hashCode() from java.lang.Object (which returns
the identity hash code, an arbitrary value assigned to the object by the VM).
Therefore, the class is very likely to violate the invariant that equal objects
must have equal hashcodes.
If you don't think instances of this class will ever be inserted into a
HashMap/HashTable, the recommended hashCode implementation to use is:
public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}
- UtilCacheTests.java:148, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP:
org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Listener.equals(Object)
does not check for null argument
This implementation of equals(Object) violates the contract defined by
java.lang.Object.equals() because it does not check for null being passed as
the argument. All equals() methods should return false if passed a null value.
-
[jira] [Created] (OFBIZ-9574) [FB] Package org.apache.ofbiz.base.test
Dennis Balkir created OFBIZ-9574: Summary: [FB] Package org.apache.ofbiz.base.test Key: OFBIZ-9574 URL: https://issues.apache.org/jira/browse/OFBIZ-9574 Project: OFBiz Issue Type: Sub-task Components: base Affects Versions: Trunk Reporter: Dennis Balkir Priority: Minor - GenericTestCaseBase.java:47, UC_USELESS_OBJECT Useless object created Our analysis shows that this object is useless. It's created and modified, but its value never go outside of the method or produce any side-effect. Either there is a mistake and object was intended to be used or it can be removed. This analysis rarely produces false-positives. Common false-positive cases include: - This object used to implicitly throw some obscure exception. - This object used as a stub to generalize the code. - This object used to hold strong references to weak/soft-referenced objects. - GenericTestCaseBase.java:99, NP_LOAD_OF_KNOWN_NULL_VALUE NP: Load of known null value in org.apache.ofbiz.base.test.GenericTestCaseBase.assertNotEquals(String, Object, Object) The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null). - GenericTestCaseBase.java:99, NP_LOAD_OF_KNOWN_NULL_VALUE NP: Load of known null value in org.apache.ofbiz.base.test.GenericTestCaseBase.assertNotEquals(String, Object, Object) The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null). - GenericTestCaseBase.java:327, NP_LOAD_OF_KNOWN_NULL_VALUE NP: Load of known null value in org.apache.ofbiz.base.test.GenericTestCaseBase.assertEquals(String, Object, Object) The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null). - GenericTestCaseBase.java:334, NP_LOAD_OF_KNOWN_NULL_VALUE NP: Load of known null value in org.apache.ofbiz.base.test.GenericTestCaseBase.assertEquals(String, Object, Object) The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9575) [FB] Package org.apache.ofbiz.base.util.cache
Dennis Balkir created OFBIZ-9575: Summary: [FB] Package org.apache.ofbiz.base.util.cache Key: OFBIZ-9575 URL: https://issues.apache.org/jira/browse/OFBIZ-9575 Project: OFBiz Issue Type: Sub-task Components: base Affects Versions: Trunk Reporter: Dennis Balkir Priority: Minor - CacheSoftReference.java:29, SE_NO_SUITABLE_CONSTRUCTOR Se: org.apache.ofbiz.base.util.cache.CacheSoftReference is Serializable but its superclass doesn't define an accessible void constructor This class implements the Serializable interface and its superclass does not. When such an object is deserialized, the fields of the superclass need to be initialized by invoking the void constructor of the superclass. Since the superclass does not have one, serialization and deserialization will fail at runtime. - CacheSoftReference.java:45, FI_PUBLIC_SHOULD_BE_PROTECTED FI: org.apache.ofbiz.base.util.cache.CacheSoftReference.finalize() is public; should be protected A class's finalize() method should have protected access, not public. - UtilCache.java:-1, SE_BAD_FIELD Se: Class org.apache.ofbiz.base.util.cache.UtilCache defines non-transient non-serializable instance field memoryTable This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods. Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field. - UtilCache.java:-1, SE_BAD_FIELD Se: Class org.apache.ofbiz.base.util.cache.UtilCache defines non-transient non-serializable instance field listeners This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods. Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field. - UtilCache.java:63, SE_NO_SERIALVERSIONID SnVI: org.apache.ofbiz.base.util.cache.UtilCache is Serializable; consider declaring a serialVersionUID This class implements the Serializable interface, but does not define a serialVersionUID field. A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID. - UtilCache.java:160, DMI_INVOKING_TOSTRING_ON_ARRAY USELESS_STRING: Invocation of toString on propNames in org.apache.ofbiz.base.util.cache.UtilCache.getPropertyParam(ResourceBundle, String[], String) The code invokes toString on an array, which will generate a fairly useless result such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12. - UtilCache.java:387, NP_NULL_ON_SOME_PATH_EXCEPTION NP: Possible null pointer dereference of o in org.apache.ofbiz.base.util.cache.UtilCache.findSizeInBytes(Object) on exception path A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning. Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9333) Random failings of tests on Buildbot
[ https://issues.apache.org/jira/browse/OFBIZ-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9333. -- Resolution: Cannot Reproduce Assignee: Jacques Le Roux Seems that since INFRA-14463 I can't reproduce :D > Random failings of tests on Buildbot > > > Key: OFBIZ-9333 > URL: https://issues.apache.org/jira/browse/OFBIZ-9333 > Project: OFBiz > Issue Type: Bug > Components: BuildBot >Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > > For few months now the tests randomy fail on Buildbot. When it happens, it's > always and only the SOAP and XML-RPC which fail. Nothing alike happens > locally, even on Windows. > I thought it's could be somehow related with tests running in parallel but It > does not make sense since, on one VM, the builds (of any project) run one > after the other. And even if OFBiz builds can be run by 3 different VMs, then > they can't collide (not same VM) > Note: at the moment we have a pending issue with tests on trunk and R16 but > we are aware of it and Deepak said he will work on it: > https://s.apache.org/PhgM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9573) [FB] Package org.apache.ofbiz.base.start
Dennis Balkir created OFBIZ-9573: Summary: [FB] Package org.apache.ofbiz.base.start Key: OFBIZ-9573 URL: https://issues.apache.org/jira/browse/OFBIZ-9573 Project: OFBiz Issue Type: Sub-task Components: base Affects Versions: Trunk Reporter: Dennis Balkir Priority: Minor - AdminClient.java:77, DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in org.apache.ofbiz.base.start.AdminClient.sendSocketCommand(AdminServer$OfbizSocketCommand, Config): new java.io.PrintWriter(OutputStream, boolean) Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. - AdminClient.java:78, DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in org.apache.ofbiz.base.start.AdminClient.sendSocketCommand(AdminServer$OfbizSocketCommand, Config): new java.io.InputStreamReader(InputStream) Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. - AdminServer.java:84, DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in org.apache.ofbiz.base.start.AdminServer.processClientRequest(Socket, List, AtomicReference): new java.io.InputStreamReader(InputStream) Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. - AdminServer.java:85, DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in org.apache.ofbiz.base.start.AdminServer.processClientRequest(Socket, List, AtomicReference): new java.io.PrintWriter(OutputStream, boolean) Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. - AdminServer.java:109, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE RCN: Redundant nullcheck of String.substring(int), which is known to be non-null in org.apache.ofbiz.base.start.AdminServer.determineClientCommand(String) This method contains a redundant check of a known non-null value against the constant null. - Classpath.java:104, NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE NP: Possible null pointer dereference in org.apache.ofbiz.base.start.Classpath.addFilesFromPath(File) due to return value of called method The return value from a method is dereferenced without a null check, and the return value of that method is one that should generally be checked for null. This may lead to a NullPointerException when the code is executed. - Classpath.java:105, DM_CONVERT_CASE Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.start.Classpath.addFilesFromPath(File) A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the String.toUpperCase( Locale l ) String.toLowerCase( Locale l ) versions instead. - Config.java:154, SF_SWITCH_NO_DEFAULT SF: Switch statement found in org.apache.ofbiz.base.start.Config.getDefaultLocale(Properties, String) where default case is missing This method contains a switch statement where default case is missing. Usually you need to provide a default case. Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if the default case is at the end of the switch statement and the switch statement doesn't contain break statements for other cases. - Start.java:121, DM_CONVERT_CASE Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.start.Start$ServerState.toString() A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the String.toUpperCase( Locale l ) String.toLowerCase( Locale l ) versions instead. - StartupCommandUtil.java:156, DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in org.apache.ofbiz.base.start.StartupCommandUtil.printOfbizStartupHelp(PrintStream): new java.io.PrintWriter(OutputStream, boolean) Found a call to a method which will perform a byte to
[jira] [Updated] (OFBIZ-9573) [FB] Package org.apache.ofbiz.base.start
[
https://issues.apache.org/jira/browse/OFBIZ-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9573:
-
Attachment: OFBIZ-9573_org.apache.ofbiz.base.start_bugfixes.patch
- fixed Diamond Operators
class AdminClient:
- Line 79: added a {{StandardCharset}} to {{OutputStream}} to prevent
conversion problems
- Line 80: added a {{StandardCharset}} to {{InputStream}} to prevent conversion
problems
class AdminServer:
- Line 86: added a {{StandardCharset}} to {{InputStream}} to prevent conversion
problems
- Line 87: added a {{StandardCharset}} to {{OutputStream}} to prevent
conversion problems
- Line 106: method {{determineClientCommand()}}:
- put long if clause in extra method, easier to read
- returned directly to not have to declare more variables
- caught the "fail" with if, so the method ends naturally with the correct
return -> easier to read
- reversed the if-clause -> easier to read
class ClassPath:
- method {{addFilesFromPath}}:
- added nullcheck to check for potential empty lists
- added default Locale to {{toLowerCase}}
class Config:
- added default case with an {{IllegalArgumentException}} to prevent failures
because of empty or to long {{locales[]}}
class Start:
- added default Locale to {{toLowerCase}}
class StartUpCommandUtil:
- initialised new {{OutputStreamWriter}} with a {{StandardCharset}} to properly
read from {{printStream}}
class StartupControlPanel:
- Line 102: did nothing, the method was build to end all processes
- Line 122: did nothing, the method was build to end all processes
- last two bugs fixed as another try-catch was implemented to close streams
which maybe weren't closed before (just in case, as intended by findbugs)
> [FB] Package org.apache.ofbiz.base.start
>
>
> Key: OFBIZ-9573
> URL: https://issues.apache.org/jira/browse/OFBIZ-9573
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-9573_org.apache.ofbiz.base.start_bugfixes.patch
>
>
> - AdminClient.java:77, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.start.AdminClient.sendSocketCommand(AdminServer$OfbizSocketCommand,
> Config): new java.io.PrintWriter(OutputStream, boolean)
> Found a call to a method which will perform a byte to String (or String to
> byte) conversion, and will assume that the default platform encoding is
> suitable. This will cause the application behaviour to vary between
> platforms. Use an alternative API and specify a charset name or Charset
> object explicitly.
> - AdminClient.java:78, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.start.AdminClient.sendSocketCommand(AdminServer$OfbizSocketCommand,
> Config): new java.io.InputStreamReader(InputStream)
> Found a call to a method which will perform a byte to String (or String to
> byte) conversion, and will assume that the default platform encoding is
> suitable. This will cause the application behaviour to vary between
> platforms. Use an alternative API and specify a charset name or Charset
> object explicitly.
> - AdminServer.java:84, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.start.AdminServer.processClientRequest(Socket, List,
> AtomicReference): new java.io.InputStreamReader(InputStream)
> Found a call to a method which will perform a byte to String (or String to
> byte) conversion, and will assume that the default platform encoding is
> suitable. This will cause the application behaviour to vary between
> platforms. Use an alternative API and specify a charset name or Charset
> object explicitly.
> - AdminServer.java:85, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.start.AdminServer.processClientRequest(Socket, List,
> AtomicReference): new java.io.PrintWriter(OutputStream, boolean)
> Found a call to a method which will perform a byte to String (or String to
> byte) conversion, and will assume that the default platform encoding is
> suitable. This will cause the application behaviour to vary between
> platforms. Use an alternative API and specify a charset name or Charset
> object explicitly.
> - AdminServer.java:109, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of String.substring(int), which is known to be
> non-null in
> org.apache.ofbiz.base.start.AdminServer.determineClientCommand(String)
> This method contains a redundant check of a known non-null value against the
> constant null.
> - Classpath.java:104, NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE
> NP: Possible null pointer dereference in
> org.apache.ofbiz.base.start.Classpath.addFilesFromPath(File) due to return
>
[jira] [Updated] (OFBIZ-9575) [FB] Package org.apache.ofbiz.base.util.cache
[
https://issues.apache.org/jira/browse/OFBIZ-9575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9575:
-
Attachment: OFBIZ-9575_org.apache.ofbiz.base.util.cache_bugfixes.patch
- fixed Diamond Operators
class CacheSoftReference:
- didn't fix first bug: why is this class implementing Serializable at all? I
didn't get it :(
- set method {{finalize}} to {{protected}}
class UtilCache:
- deleted unnecessary else blocks
- added {{Arrays.toString()}} to prevent the reading of the Array {{propNames}}
from returning random text
- didn't fix Line 108 & 110, not really possible to fix there, hopefully
intended as it is
- circular dependency not found, maybe there is none..?
- moved nullcheck in {{findSizeInBytes}} in front of the try-block, therefore
no possible null inside of the try-block
> [FB] Package org.apache.ofbiz.base.util.cache
> -
>
> Key: OFBIZ-9575
> URL: https://issues.apache.org/jira/browse/OFBIZ-9575
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments:
> OFBIZ-9575_org.apache.ofbiz.base.util.cache_bugfixes.patch
>
>
> - CacheSoftReference.java:29, SE_NO_SUITABLE_CONSTRUCTOR
> Se: org.apache.ofbiz.base.util.cache.CacheSoftReference is Serializable but
> its superclass doesn't define an accessible void constructor
> This class implements the Serializable interface and its superclass does not.
> When such an object is deserialized, the fields of the superclass need to be
> initialized by invoking the void constructor of the superclass. Since the
> superclass does not have one, serialization and deserialization will fail at
> runtime.
> - CacheSoftReference.java:45, FI_PUBLIC_SHOULD_BE_PROTECTED
> FI: org.apache.ofbiz.base.util.cache.CacheSoftReference.finalize() is public;
> should be protected
> A class's finalize() method should have protected access, not public.
> - UtilCache.java:-1, SE_BAD_FIELD
> Se: Class org.apache.ofbiz.base.util.cache.UtilCache defines non-transient
> non-serializable instance field memoryTable
> This Serializable class defines a non-primitive instance field which is
> neither transient, Serializable, or java.lang.Object, and does not appear to
> implement the Externalizable interface or the readObject() and writeObject()
> methods. Objects of this class will not be deserialized correctly if a
> non-Serializable object is stored in this field.
> - UtilCache.java:-1, SE_BAD_FIELD
> Se: Class org.apache.ofbiz.base.util.cache.UtilCache defines non-transient
> non-serializable instance field listeners
> This Serializable class defines a non-primitive instance field which is
> neither transient, Serializable, or java.lang.Object, and does not appear to
> implement the Externalizable interface or the readObject() and writeObject()
> methods. Objects of this class will not be deserialized correctly if a
> non-Serializable object is stored in this field.
> - UtilCache.java:63, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.cache.UtilCache is Serializable; consider
> declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> - UtilCache.java:160, DMI_INVOKING_TOSTRING_ON_ARRAY
> USELESS_STRING: Invocation of toString on propNames in
> org.apache.ofbiz.base.util.cache.UtilCache.getPropertyParam(ResourceBundle,
> String[], String)
> The code invokes toString on an array, which will generate a fairly useless
> result such as [C@16f0472. Consider using Arrays.toString to convert the
> array into a readable String that gives the contents of the array. See
> Programming Puzzlers, chapter 3, puzzle 12.
> - UtilCache.java:387, NP_NULL_ON_SOME_PATH_EXCEPTION
> NP: Possible null pointer dereference of o in
> org.apache.ofbiz.base.util.cache.UtilCache.findSizeInBytes(Object) on
> exception path
> A reference value which is null on some exception control path is
> dereferenced here. This may lead to a NullPointerException when the code is
> executed. Note that because FindBugs currently does not prune infeasible
> exception paths, this may be a false warning.
> Also note that FindBugs considers the default case
[jira] [Commented] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125805#comment-16125805 ] Gil Portenseigne commented on OFBIZ-9572: - +1 on removing variable declaration and using BigDecimal.ZERO. On the setScale part, i find it awkward to define it on the class variable, or on the ZERO value... In any case, the setScale must be used when returning BigDecimal value from a method/service. > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125841#comment-16125841 ] Jacques Le Roux commented on OFBIZ-9572: Thanks Gil, Indeed I finally see no reasons to use setScale() on BigDecimal.ZERO. It's the _"deep"_ zero and nothing can change it (thanks to Indians who gave us zero long ago). For the rest we need to check if is correctly used everywhere... > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125805#comment-16125805 ] Gil Portenseigne edited comment on OFBIZ-9572 at 8/14/17 3:30 PM: -- +1 on removing variable declaration and using BigDecimal.ZERO. On the setScale part, i find it awkward to define it on the class variable (=> FinAccountHelper.java), or on the ZERO value... In any case, the setScale must be used when returning BigDecimal value from a method/service. was (Author: gil portenseigne): +1 on removing variable declaration and using BigDecimal.ZERO. On the setScale part, i find it awkward to define it on the class variable, or on the ZERO value... In any case, the setScale must be used when returning BigDecimal value from a method/service. > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125841#comment-16125841 ] Jacques Le Roux edited comment on OFBIZ-9572 at 8/14/17 3:32 PM: - Thanks Gil, Indeed I finally see no reasons to use setScale() on BigDecimal.ZERO. It's the _"deep"_ zero and nothing can change it (thanks to Indians who gave us zero long ago). For the rest we need to check if setScale() is correctly used everywhere... was (Author: jacques.le.roux): Thanks Gil, Indeed I finally see no reasons to use setScale() on BigDecimal.ZERO. It's the _"deep"_ zero and nothing can change it (thanks to Indians who gave us zero long ago). For the rest we need to check if is correctly used everywhere... > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9306) Check there are no white spaces in the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9306: --- Attachment: OFBIZ-9306-ModelFormField.java.patch It seems to me that a name should not be preceded by a white-space. So this uses a trim() to removes all preceding or trailing white-spaces. I wait a week to see if people agree with this notion before committing... > Check there are no white spaces in the name of a form field when updating a > form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9306) Check there are no white spaces in the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125775#comment-16125775 ] Michael Brohl commented on OFBIZ-9306: -- I agree with the trim, but you should check for null first. > Check there are no white spaces in the name of a form field when updating a > form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9486) [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware
[ https://issues.apache.org/jira/browse/OFBIZ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125747#comment-16125747 ] Jacques Le Roux commented on OFBIZ-9486: Hi Kyra, I guess it was a mistake, actually in your 1st patch you *removed* proctected ;) But anyway indeed private was the way to go, thanks! > [FB] Package org.apache.ofbiz.accounting.thirdparty.gosoftware > -- > > Key: OFBIZ-9486 > URL: https://issues.apache.org/jira/browse/OFBIZ-9486 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Kyra Pritzel-Hentley >Priority: Minor > Attachments: > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch, > OFBIZ-9486_org.apache.ofbiz.accounting.thirdparty.gosoftware_bugfixes.patch > > > PcChargeApi.java:81: 82, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > PcChargeApi.java:189, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > java.io.PrintStream(OutputStream) > Found a call to a method which will perform a byte to String (or String to > byte) conversion, and will assume that the default platform encoding is > suitable. This will cause the application behaviour to vary between > platforms. Use an alternative API and specify a charset name or Charset > object explicitly. > PcChargeApi.java:198, DM_DEFAULT_ENCODING > * Dm: Found reliance on default encoding in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeApi.send(): new > String(byte[], int, int) > PcChargeServices.java:94: 180: 246: 306, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of out, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.PcChargeServices > This method contains a redundant check of a known non-null value against the > constant null. > RitaApi.java:80, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validOut > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaApi.java:84, MS_PKGPROTECT > * MS: org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaApi.validIn > should be package protected > A mutable static field could be changed by malicious code or by accident. The > field could be made package protected to avoid this vulnerability. > RitaServices.java:61: 98: 164: 184: 233: 260: 301: 329, > RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > * RCN: Redundant nullcheck of api, which is known to be non-null in > org.apache.ofbiz.accounting.thirdparty.gosoftware.RitaServices > This method contains a redundant check of a known non-null value against the > constant null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9576) [FB] Package org.apache.ofbiz.base.util.cache.test
[
https://issues.apache.org/jira/browse/OFBIZ-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9576:
-
Attachment: OFBIZ-9576_org.apache.ofbiz.base.util.cache.test_bugfixes.patch
- fixed Diamond Operators
- Line 39: didn't fix error, {{serialVersionUID}} doesn't have to be
implemented for this test class
- class Removal: changed {{oldValue}} from {{protected}} to {{private}}
- class Addition: changed {{newValue}} from {{protected}} to {{private}}
- class Update: changed {{newValue}} and {{oldValue}} from {{protected}} to
{{private}}
- added type-check in {{equals}} to prevent casting errors
- implemented {{hashCode()}}, because {{equals}} was implemented (it still
throws a findbugs bug, because it just uses the {{super.hashCode()}}
- Line 353: didn't change anything, if the declaration is changed, it won't work
- Line 354: didn't change anything, if the declaration is changed, it won't work
- put code, which was used more often in an own method called
{{assertKeyLoop}}, because it is DRY, but didn't change the String declaration,
because it was used to clone the String
- Line 358: didn't fix anything, method was planned this way
> [FB] Package org.apache.ofbiz.base.util.cache.test
> --
>
> Key: OFBIZ-9576
> URL: https://issues.apache.org/jira/browse/OFBIZ-9576
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments:
> OFBIZ-9576_org.apache.ofbiz.base.util.cache.test_bugfixes.patch
>
>
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition is
> final but declares protected field
> org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition.newValue
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal is
> final but declares protected field
> org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal.oldValue
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is
> final but declares protected field
> org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.newValue
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is
> final but declares protected field
> org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.oldValue
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> - UtilCacheTests.java:39, SE_NO_SUITABLE_CONSTRUCTOR
> Se: org.apache.ofbiz.base.util.cache.test.UtilCacheTests is Serializable but
> its superclass doesn't define an accessible void constructor
> This class implements the Serializable interface and its superclass does not.
> When such an object is deserialized, the fields of the superclass need to be
> initialized by invoking the void constructor of the superclass. Since the
> superclass does not have one, serialization and deserialization will fail at
> runtime.
> - UtilCacheTests.java:39, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.cache.test.UtilCacheTests is Serializable;
> consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different
[jira] [Updated] (OFBIZ-9306) Check there are no white spaces around the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9306: --- Summary: Check there are no white spaces around the name of a form field when updating a form (was: Check there are no white spaces in the name of a form field when updating a form) > Check there are no white spaces around the name of a form field when updating > a form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125965#comment-16125965 ] Jacques Le Roux commented on OFBIZ-9572: To be completly clear: # BigDecimal.ZERO is the real zero constant and should not be changed. That makes no sense. # But, like in any BigDecimal comparison, values compared to BigDecimal.ZERO must be weighted by using setScale() # Like I did in OFBIZ-9571 we should not use the setScale() variant with integer but the one with RoundingMode. I'll now update the description > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > This should not be done when setScale() is used on the ZERO constant -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9572: --- Description: Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. was: Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. This should not be done when setScale() is used on the ZERO constant > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9572) Replace all "BigDecimal ZERO" by BigDecimal.ZERO
[ https://issues.apache.org/jira/browse/OFBIZ-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9572: --- Description: Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. # But, like in any BigDecimal comparison, values compared to BigDecimal.ZERO must be weighted by using setScale() # Like I did in OFBIZ-9571 we must always use the setScale() variant with integer but the one with RoundingMode. was: Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but more useless code. They are both constants and the compiler will made them so. > Replace all "BigDecimal ZERO" by BigDecimal.ZERO > > > Key: OFBIZ-9572 > URL: https://issues.apache.org/jira/browse/OFBIZ-9572 > Project: OFBiz > Issue Type: Improvement >Reporter: Jacques Le Roux > > Using "BigDecimal ZERO" instead of BigDecimal.ZERO does not add anything but > more useless code. They are both constants and the compiler will made them so. > # But, like in any BigDecimal comparison, values compared to BigDecimal.ZERO > must be weighted by using setScale() > # Like I did in OFBIZ-9571 we must always use the setScale() variant with > integer but the one with RoundingMode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9306) Check there are no white spaces around the name of a form field when updating a form
[ https://issues.apache.org/jira/browse/OFBIZ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125990#comment-16125990 ] Jacques Le Roux commented on OFBIZ-9306: Thanks Michael, Why do you think introducing a check for null should be done now? Is it related to this change or in general (as it's now in trunk)? I'm not sure it's needed because this change is only removing white-spaces around the name. If the name is already empty I guess it's already handled with current code. This said I'm not against checking for null first, I just want to understand why and maybe where in code (I guess you mean just before the return, right?) > Check there are no white spaces around the name of a form field when updating > a form > > > Key: OFBIZ-9306 > URL: https://issues.apache.org/jira/browse/OFBIZ-9306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9306-ModelFormField.java.patch > > > Sometimes ago, I lost an hour because of a space at the end of a field's name > in a form. In creation it does not pass (the field lacks) but when updating > the form it passes and it's hard to find from where comes the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-9577) Manage File upload with auto-fields-service
Nicolas Malin created OFBIZ-9577: Summary: Manage File upload with auto-fields-service Key: OFBIZ-9577 URL: https://issues.apache.org/jira/browse/OFBIZ-9577 Project: OFBiz Issue Type: Improvement Reporter: Nicolas Malin Assignee: Nicolas Malin When you use a auto-fields-service element on form, if the service wait a file, manage it directly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
