[jira] [Assigned] (OFBIZ-7021) Rename .ftl file as per best practises
[ https://issues.apache.org/jira/browse/OFBIZ-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Dixit reassigned OFBIZ-7021: --- Assignee: 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: Deepak Dixit > 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-5732) Error in sendMailHiddenInLog service
[
https://issues.apache.org/jira/browse/OFBIZ-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263488#comment-15263488
]
Wei Zhang commented on OFBIZ-5732:
--
Hi Jacques,
Yes, the OFBIZ-5732 and OFBIZ-6686 are the same one.
Re. OFBIZ-3379-2.patch. I don't think it is correct and the required prameter
bodyParts still missed.
Regards,
Wei
> 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
>
> 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)
Re: Solr libs duplication
OK, I'll try to upgrad the hadoop jars to 2.7.2. -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2016年4月28日 19:53 收件人: dev@ofbiz.apache.org 主题: Re: Solr libs duplication Thanks Shingai! And while at it, if it's possible, it would be good, for security reason, to upgrade (or remember to upgrade) Hadoop libs, used in Solr component, to the 2.7.2 version. This is due to https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1776 which is quite recent. I don't know (did not try) if it's possible to simply upgrade the libs or to wait for a new Solr version covering the issue. I checked the last available Solr version (6.0.0) does not. For details see https://svn.apache.org/viewvc/ofbiz/trunk/tools/security/dependency-check/dependency-check-report.html?view=co=HEAD Thanks Jacques Le 28/04/2016 à 06:06, Shi Jinghai a écrit : > Thanks Christian! > > I created an issue on the jars duplicated: > https://issues.apache.org/jira/browse/OFBIZ-7026 > > I'll remove the dupliations step by step. > > Kind Regards, > > Shi Jinghai > > -邮件原件- > 发件人: Christian Geisert [mailto:christian.geis...@isu-gmbh.de] > 发送时间: 2016年4月27日 18:02 > 收件人: dev@ofbiz.apache.org > 主题: Re: Solr libs duplication > > There are also duplicates with regards to framework (noticed that while > integrating Apache Camel, but didn't have time to work on it yet) > > ./specialpurpose/solr/webapp/solr/WEB-INF/lib/concurrentlinkedhashmap-lru-1.2.jar > ./framework/base/lib/clhm-release-1.0-lru.jar > > I think version 1.2 should be moved to framework. > > Christian > > Am 27.04.2016 11:34, schrieb Shi Jinghai: >> Hi Jacques, >> >> Obviously it's my fault :-( >> >> The duplicated jars under webapp /solr/WEB-INF/lib/ can be removed as they >> are already common jars at container level. I'll remove the duplicated jars >> ASAP. >> >> Kind Regards, >> >> Shi Jinghai >> >> -邮件原件- >> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >> 发送时间: 2016年4月26日 17:58 >> 收件人: dev@ofbiz.apache.org; shi.jinghai >> 主题: Solr libs duplication >> >> Hi Jinghai, >> >> Do you think it's possible to somehow avoid these duplications in Solr >> component? >> >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\joda-time-2.2.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\joda-time-2.2.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-codecs-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-codecs-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-highlighter-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-highlighter-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-join-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-join-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-queries-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-queries-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-spatial-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-spatial-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-suggest-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-suggest-5.3.1.jar >> >> >> I think it must be hard (if even possible) because it's runtime >> dependencies, right? >> >> Thanks >> >> Jacques >> >> >> > > >
Re: Solr libs duplication
Thanks Jacques! I'll check how to remove this duplication this weekend. Kind Regards, Shi Jinghai -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2016年4月28日 16:55 收件人: dev@ofbiz.apache.org 主题: Re: Solr libs duplication About concurrentlinkedhashmap the author himself recommends to use Guava or possibly his last version built for Java 8 https://stackoverflow.com/questions/15299554/what-does-it-mean-that-concurrentlinkedhashmap-has-been-integrated-into-guava Please check Thanks Jacques Le 28/04/2016 à 06:06, Shi Jinghai a écrit : > Thanks Christian! > > I created an issue on the jars duplicated: > https://issues.apache.org/jira/browse/OFBIZ-7026 > > I'll remove the dupliations step by step. > > Kind Regards, > > Shi Jinghai > > -邮件原件- > 发件人: Christian Geisert [mailto:christian.geis...@isu-gmbh.de] > 发送时间: 2016年4月27日 18:02 > 收件人: dev@ofbiz.apache.org > 主题: Re: Solr libs duplication > > There are also duplicates with regards to framework (noticed that while > integrating Apache Camel, but didn't have time to work on it yet) > > ./specialpurpose/solr/webapp/solr/WEB-INF/lib/concurrentlinkedhashmap-lru-1.2.jar > ./framework/base/lib/clhm-release-1.0-lru.jar > > I think version 1.2 should be moved to framework. > > Christian > > Am 27.04.2016 11:34, schrieb Shi Jinghai: >> Hi Jacques, >> >> Obviously it's my fault :-( >> >> The duplicated jars under webapp /solr/WEB-INF/lib/ can be removed as they >> are already common jars at container level. I'll remove the duplicated jars >> ASAP. >> >> Kind Regards, >> >> Shi Jinghai >> >> -邮件原件- >> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >> 发送时间: 2016年4月26日 17:58 >> 收件人: dev@ofbiz.apache.org; shi.jinghai >> 主题: Solr libs duplication >> >> Hi Jinghai, >> >> Do you think it's possible to somehow avoid these duplications in Solr >> component? >> >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\joda-time-2.2.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\joda-time-2.2.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-codecs-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-codecs-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-highlighter-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-highlighter-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-join-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-join-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-queries-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-queries-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-spatial-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-spatial-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-suggest-5.3.1.jar >> C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-suggest-5.3.1.jar >> >> >> I think it must be hard (if even possible) because it's runtime >> dependencies, right? >> >> Thanks >> >> Jacques >> >> >> > > >
[jira] [Comment Edited] (OFBIZ-6711) Have configuration options regarding widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262801#comment-15262801 ] Jacques Le Roux edited comment on OFBIZ-6711 at 4/28/16 7:32 PM: - I had a doubt about the number above, notably about lookups bq. it would be interesting to 1st remove the 156 useless occurences of Have configuration options regarding widgets > > > Key: OFBIZ-6711 > URL: https://issues.apache.org/jira/browse/OFBIZ-6711 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS, ALL COMPONENTS >Reporter: Pierre Smits >Assignee: Pierre Smits > Attachments: OFBIZ-6711-widget.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6711) Have configuration options regarding widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262801#comment-15262801 ] Jacques Le Roux commented on OFBIZ-6711: I had a doubt about the number above, notably about lookups .bq it would be interesting to 1st remove the 156 useless occurences of Have configuration options regarding widgets > > > Key: OFBIZ-6711 > URL: https://issues.apache.org/jira/browse/OFBIZ-6711 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS, ALL COMPONENTS >Reporter: Pierre Smits >Assignee: Pierre Smits > Attachments: OFBIZ-6711-widget.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6988) Estimated shipping cost resolution with breaks on price and quantity
[
https://issues.apache.org/jira/browse/OFBIZ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262695#comment-15262695
]
Jacques Le Roux commented on OFBIZ-6988:
I think we should also warn users when one of their breaks is not valid (to
avoid skipping a missing or an error). Maybe that's what you tried with the log
entries you added (in the code example, they are not present OOTB)?
> Estimated shipping cost resolution with breaks on price and quantity
>
>
> Key: OFBIZ-6988
> URL: https://issues.apache.org/jira/browse/OFBIZ-6988
> Project: OFBiz
> Issue Type: Improvement
> Components: product
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
> Labels: shipping
>
> On the service *calcShipmentCostEstimate*, each estimated shipment cost is
> analysed to resolve which ones should be applied on the order.
> During the breakQtys block analysis, OFBiz checks if the estimate match the
> quantity with their breaks and validates if one is good
> {code}
> if (qv != null) {
> useQty = true;
> BigDecimal min = BigDecimal.ONE.movePointLeft(4);
> BigDecimal max = BigDecimal.ONE.movePointLeft(4);
> try {
> min = qv.getBigDecimal("fromQuantity");
> max = qv.getBigDecimal("thruQuantity");
> } catch (Exception e) {
> }
> if (shippableQuantity.compareTo(min) >= 0 &&
> (max.compareTo(BigDecimal.ZERO) == 0 || shippableQuantity.compareTo(max) <=
> 0)) {
> qtyValid = true;
> }
> if (Debug.infoOn()) Debug.logInfo(" # QUANTITY SHIP
> min : " + min + ", max : " + max + ", value " + shippableQuantity + "
> qtyValid " + qtyValid, module);
> }
> if (pv != null) {
> usePrice = true;
> BigDecimal min = BigDecimal.ONE.movePointLeft(4);
> BigDecimal max = BigDecimal.ONE.movePointLeft(4);
> try {
> min = pv.getBigDecimal("fromQuantity");
> max = pv.getBigDecimal("thruQuantity");
> } catch (Exception e) {
> }
> if (shippableTotal.compareTo(min) >= 0 &&
> (max.compareTo(BigDecimal.ZERO) == 0 || shippableTotal.compareTo(max) <= 0)) {
> priceValid = true;
> }
> if (Debug.infoOn()) Debug.logInfo(" # PRICE TOT SHIP
> min : " + min + ", max : " + max + ", value " + shippableTotal+ " qtyValid "
> + priceValid, module);
> }
> // Now check the tests.
> if ((useWeight && weightValid) || (useQty && qtyValid)
> || (usePrice && priceValid)) {
> estimateList.add(thisEstimate);
> }
> {code}
> I didn't understand why an estimated shippping cost that contains a no valid
> break can be applied on the order.
> On a customer project I have these rules:
> ||||Quantity Break Id|| Price Break Id|| Flat Price || Order Price
> Percent ||
> |FR000| | 0 - 1000 [FRP4] | 25|0|
> |FR001| 0 - 500,000 [FRB01]|1000 - 0 [FRP3] | |15|
> |FR004| 2,000,000 - 0 [FRB04]| 1000 - 0 [FRP3] | |2|
> |FR003| 1,000,001 - 1,999,999 [FRB03]| 1000 - 0 [FRP3] |
> |5|
> |FR002| 500,001 - 1,000,000 [FRB02]|1000 - 0 [FRP3] |
> |8|
> The problem with the previous code is that for a total price more than 300€
> OFBiz gives me a random rule between FR00[1-4] and it's wrong because I have
> also a break on total quantity shipped
> I propose to change the check like this
> {code}
> @@ -406,7 +410,9 @@
> }
> }
> // Now check the tests.
> -if ((useWeight && weightValid) || (useQty && qtyValid)
> || (usePrice && priceValid)) {
> +if ((!useWeight || useWeight && weightValid)
> +&& (!useQty || useQty && qtyValid)
> +&& (!usePrice || usePrice && priceValid)) {
> estimateList.add(thisEstimate);
> }
> }
> {code}
> To ensure that if a break is defined on the estimated shipping cost, we
> enable it only if all defined breaks are valid.
> Any suggestion ?
--
This message was sent by
[jira] [Commented] (OFBIZ-6988) Estimated shipping cost resolution with breaks on price and quantity
[
https://issues.apache.org/jira/browse/OFBIZ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262689#comment-15262689
]
Jacques Le Roux commented on OFBIZ-6988:
I reviewed (and slightly amended the description ;)), I agree with you Nicolas.
If you refactor, please don't let unhandled exceptions.
> Estimated shipping cost resolution with breaks on price and quantity
>
>
> Key: OFBIZ-6988
> URL: https://issues.apache.org/jira/browse/OFBIZ-6988
> Project: OFBiz
> Issue Type: Improvement
> Components: product
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
> Labels: shipping
>
> On the service *calcShipmentCostEstimate*, each estimated shipment cost is
> analysed to resolve which ones should be applied on the order.
> During the breakQtys block analysis, OFBiz checks if the estimate match the
> quantity with their breaks and validates if one is good
> {code}
> if (qv != null) {
> useQty = true;
> BigDecimal min = BigDecimal.ONE.movePointLeft(4);
> BigDecimal max = BigDecimal.ONE.movePointLeft(4);
> try {
> min = qv.getBigDecimal("fromQuantity");
> max = qv.getBigDecimal("thruQuantity");
> } catch (Exception e) {
> }
> if (shippableQuantity.compareTo(min) >= 0 &&
> (max.compareTo(BigDecimal.ZERO) == 0 || shippableQuantity.compareTo(max) <=
> 0)) {
> qtyValid = true;
> }
> if (Debug.infoOn()) Debug.logInfo(" # QUANTITY SHIP
> min : " + min + ", max : " + max + ", value " + shippableQuantity + "
> qtyValid " + qtyValid, module);
> }
> if (pv != null) {
> usePrice = true;
> BigDecimal min = BigDecimal.ONE.movePointLeft(4);
> BigDecimal max = BigDecimal.ONE.movePointLeft(4);
> try {
> min = pv.getBigDecimal("fromQuantity");
> max = pv.getBigDecimal("thruQuantity");
> } catch (Exception e) {
> }
> if (shippableTotal.compareTo(min) >= 0 &&
> (max.compareTo(BigDecimal.ZERO) == 0 || shippableTotal.compareTo(max) <= 0)) {
> priceValid = true;
> }
> if (Debug.infoOn()) Debug.logInfo(" # PRICE TOT SHIP
> min : " + min + ", max : " + max + ", value " + shippableTotal+ " qtyValid "
> + priceValid, module);
> }
> // Now check the tests.
> if ((useWeight && weightValid) || (useQty && qtyValid)
> || (usePrice && priceValid)) {
> estimateList.add(thisEstimate);
> }
> {code}
> I didn't understand why an estimated shippping cost that contains a no valid
> break can be applied on the order.
> On a customer project I have these rules:
> ||||Quantity Break Id|| Price Break Id|| Flat Price || Order Price
> Percent ||
> |FR000| | 0 - 1000 [FRP4] | 25|0|
> |FR001| 0 - 500,000 [FRB01]|1000 - 0 [FRP3] | |15|
> |FR004| 2,000,000 - 0 [FRB04]| 1000 - 0 [FRP3] | |2|
> |FR003| 1,000,001 - 1,999,999 [FRB03]| 1000 - 0 [FRP3] |
> |5|
> |FR002| 500,001 - 1,000,000 [FRB02]|1000 - 0 [FRP3] |
> |8|
> The problem with the previous code is that for a total price more than 300€
> OFBiz gives me a random rule between FR00[1-4] and it's wrong because I have
> also a break on total quantity shipped
> I propose to change the check like this
> {code}
> @@ -406,7 +410,9 @@
> }
> }
> // Now check the tests.
> -if ((useWeight && weightValid) || (useQty && qtyValid)
> || (usePrice && priceValid)) {
> +if ((!useWeight || useWeight && weightValid)
> +&& (!useQty || useQty && qtyValid)
> +&& (!usePrice || usePrice && priceValid)) {
> estimateList.add(thisEstimate);
> }
> }
> {code}
> To ensure that if a break is defined on the estimated shipping cost, we
> enable it only if all defined breaks are valid.
> Any suggestion ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-6988) Estimated shipping cost resolution with breaks on price and quantity
[
https://issues.apache.org/jira/browse/OFBIZ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-6988:
---
Description:
On the service *calcShipmentCostEstimate*, each estimated shipment cost is
analysed to resolve which ones should be applied on the order.
During the breakQtys block analysis, OFBiz checks if the estimate match the
quantity with their breaks and validates if one is good
{code}
if (qv != null) {
useQty = true;
BigDecimal min = BigDecimal.ONE.movePointLeft(4);
BigDecimal max = BigDecimal.ONE.movePointLeft(4);
try {
min = qv.getBigDecimal("fromQuantity");
max = qv.getBigDecimal("thruQuantity");
} catch (Exception e) {
}
if (shippableQuantity.compareTo(min) >= 0 &&
(max.compareTo(BigDecimal.ZERO) == 0 || shippableQuantity.compareTo(max) <= 0))
{
qtyValid = true;
}
if (Debug.infoOn()) Debug.logInfo(" # QUANTITY SHIP min
: " + min + ", max : " + max + ", value " + shippableQuantity + " qtyValid " +
qtyValid, module);
}
if (pv != null) {
usePrice = true;
BigDecimal min = BigDecimal.ONE.movePointLeft(4);
BigDecimal max = BigDecimal.ONE.movePointLeft(4);
try {
min = pv.getBigDecimal("fromQuantity");
max = pv.getBigDecimal("thruQuantity");
} catch (Exception e) {
}
if (shippableTotal.compareTo(min) >= 0 &&
(max.compareTo(BigDecimal.ZERO) == 0 || shippableTotal.compareTo(max) <= 0)) {
priceValid = true;
}
if (Debug.infoOn()) Debug.logInfo(" # PRICE TOT SHIP
min : " + min + ", max : " + max + ", value " + shippableTotal+ " qtyValid " +
priceValid, module);
}
// Now check the tests.
if ((useWeight && weightValid) || (useQty && qtyValid) ||
(usePrice && priceValid)) {
estimateList.add(thisEstimate);
}
{code}
I didn't understand why an estimated shippping cost that contains a no valid
break can be applied on the order.
On a customer project I have these rules:
|| ||Quantity Break Id|| Price Break Id|| Flat Price || Order Price
Percent ||
|FR000| | 0 - 1000 [FRP4] | 25|0|
|FR001| 0 - 500,000 [FRB01]|1000 - 0 [FRP3] | |15|
|FR004| 2,000,000 - 0 [FRB04]| 1000 - 0 [FRP3] | |2|
|FR003| 1,000,001 - 1,999,999 [FRB03]| 1000 - 0 [FRP3] |
|5|
|FR002| 500,001 - 1,000,000 [FRB02]|1000 - 0 [FRP3] |
|8|
The problem with the previous code is that for a total price more than 300€
OFBiz gives me a random rule between FR00[1-4] and it's wrong because I have
also a break on total quantity shipped
I propose to change the check like this
{code}
@@ -406,7 +410,9 @@
}
}
// Now check the tests.
-if ((useWeight && weightValid) || (useQty && qtyValid) ||
(usePrice && priceValid)) {
+if ((!useWeight || useWeight && weightValid)
+&& (!useQty || useQty && qtyValid)
+&& (!usePrice || usePrice && priceValid)) {
estimateList.add(thisEstimate);
}
}
{code}
To ensure that if a break is defined on the estimated shipping cost, we enable
it only if all defined breaks are valid.
Any suggestion ?
was:
On the service *calcShipmentCostEstimate*, each estimated shipment cost are
analysed to resolve who is enable to apply on the order.
During the breakQtys block analyse, OFBiz check if the estimate match the
quantity with their breaks and valid it if one is good
{code}
if (qv != null) {
useQty = true;
BigDecimal min = BigDecimal.ONE.movePointLeft(4);
BigDecimal max = BigDecimal.ONE.movePointLeft(4);
try {
min = qv.getBigDecimal("fromQuantity");
max = qv.getBigDecimal("thruQuantity");
} catch (Exception e) {
}
if (shippableQuantity.compareTo(min) >= 0 &&
(max.compareTo(BigDecimal.ZERO) == 0 || shippableQuantity.compareTo(max) <= 0))
{
qtyValid
[jira] [Comment Edited] (OFBIZ-7003) Error when accessing project manager
[
https://issues.apache.org/jira/browse/OFBIZ-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262189#comment-15262189
]
Jacques Le Roux edited comment on OFBIZ-7003 at 4/28/16 2:33 PM:
-
Hi,
I looked into the problem and found where this error comes from.
When the project list is loaded, it uses the form "ListCurrentProjects" from
the file ProjectsForms.xml.
In this form, the diffrent informations about the projects are loaded.
The error indicates that the property "actualNonBilledTotalHours" does not
exist in the current context. And this value is used in this line :
{code}
{code}
The condition means : If the hours are billable And there is at least 1 hour
not billed Then display this number of hours Else diplay ""
I'm not sure about the "!=void" thing, I would use Util.isNotEmpty instead.
When the condition is checked, the property actualNonBilledTotalHours is
searched through the context but is not found.
I search something that was related to this property and found the
simple-method "getHours" from the file "WorkEffortSimpleServices.xml". Under
the right condition, it does evaluate and return the property. But the thing is
that this method is not called by the "ListCurrentProject". And one of the
reason is that this method is not available as a service.
So the problem behind this one is that there is nothing to put the
"actualNonBilledTotalHours" in the context of "ListCurrentProject" thus showing
the error about this property missing.
To solve this problem, either a service can be created to call the method
getHours and then updating the ListCurrentProject (this choice is to be made by
the community) or this feature about the "actualNonBilledTotalHours" can be
dropped (choice decided by the community too).
I hope I'm not mistaking about the root problem and hope that will help you.
Have a nice day,
Florian
was (Author: florian m):
Hi,
I looked into the problem and found where this error comes from.
When the project list is loaded, it uses the form "ListCurrentProjects" from
the file ProjectsForms.xml.
In this form, the diffrent informations about the projects are loaded.
The error indicates that the property "actualNonBilledTotalHours" does not
exist in the current context. And this value is used in this line :
The condition means : If the hours are billable And there is at least 1 hour
not billed Then display this number of hours Else diplay ""
I'm not sure about the "!=void" thing, I would use Util.isNotEmpty instead.
When the condition is checked, the property actualNonBilledTotalHours is
searched through the context but is not found.
I search something that was related to this property and found the
simple-method "getHours" from the file "WorkEffortSimpleServices.xml". Under
the right condition, it does evaluate and return the property. But the thing is
that this method is not called by the "ListCurrentProject". And one of the
reason is that this method is not available as a service.
So the problem behind this one is that there is nothing to put the
"actualNonBilledTotalHours" in the context of "ListCurrentProject" thus showing
the error about this property missing.
To solve this problem, either a service can be created to call the method
getHours and then updating the ListCurrentProject (this choice is to be made by
the community) or this feature about the "actualNonBilledTotalHours" can be
dropped (choice decided by the community too).
I hope I'm not mistaking about the root problem and hope that will help you.
Have a nice day,
Florian
> Error when accessing project manager
>
>
> Key: OFBIZ-7003
> URL: https://issues.apache.org/jira/browse/OFBIZ-7003
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: james yong
>Priority: Minor
>
> I am running SVN version 1738958.
> Problem
> ===
> I navigate to https://localhost:8443/projectmgr, and found the following
> error on the console:
> {code}
> 2016-04-14 22:31:56,648 |http-nio-8443-exec-3 |ServiceDispatcher
> |T| Sync service [projectmgr/getProject] finished in [24] milliseconds
> 2016-04-14 22:31:56,724 |http-nio-8443-exec-3 |FlexibleStringExpander
> |W| Error evaluating scriptlet
> [${groovy:isBillable&!=void?actualNonBilledTotalHours:""}];
> error was: groovy.lang.MissingPropertyException: No such property:
> actualNonBilledTotalHours for class: script14606441839311459442740
> groovy.lang.MissingPropertyException: No such property:
> actualNonBilledTotalHours for class: script14606441839311459442740
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
> ~[groovy-all-2.4.5.jar:2.4.5]
> at
>
[jira] [Commented] (OFBIZ-7020) Page navigation problem with grid and include-grid
[ https://issues.apache.org/jira/browse/OFBIZ-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262230#comment-15262230 ] Jacques Le Roux commented on OFBIZ-7020: I confirm the behaviour, no time to look at it yet > Page navigation problem with grid and include-grid > -- > > Key: OFBIZ-7020 > URL: https://issues.apache.org/jira/browse/OFBIZ-7020 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Montalbano Florian >Priority: Minor > Labels: grid, include-grid, pagination > > The bottom navigation buttons are not working correctly in pages with grid > and include-grid. > How to reproduce : > 1) Connect to OFBiz > 2) Go to the Party component > 3) Let all field blank and do a search > 4) Scroll down and try to use the next result page button > Result : The result page is still the same, the upper navigation bar shows > "Page 1" and the bottom one "Page 2". > Problem : With some help, I figured out where the problem is. > The result of the search is displayed in a grid. But inside this grid can > show up "include-grid" (the field User Login ID for example). Each time a > grid is created, it calls the function > "WidgetWorker.incrementPaginatorNumber(context);" which increments the > paginator number by one. > So when there are more than one grid (and include-grid) on a page, the > paginator number is modified. This means that the upper navigation bar > paginator number and the one from the bottom bar is not the same. > The bottom navigation bar is then set with wrong value and the URL put in > each navigation button is corrupted, thus not correctly redirecting to the > good page. > If you look at the URL after clicking on the bottom next button, you will see > the "bad" paginator number. > I hope this can lead someone to a solution, I lack experiences on OFBiz to > provide a patch on this issue. > Thanks, > Florian Montalbano -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7027) Added support to include party classification information in Promo description
[ https://issues.apache.org/jira/browse/OFBIZ-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mridul Pathak updated OFBIZ-7027: - Affects Version/s: (was: Upcoming Branch) > Added support to include party classification information in Promo description > -- > > Key: OFBIZ-7027 > URL: https://issues.apache.org/jira/browse/OFBIZ-7027 > Project: OFBiz > Issue Type: Improvement > Components: order, specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Swapnil M Mane >Assignee: Mridul Pathak >Priority: Minor > Attachments: OFBIZ-7027.patch > > > When the user navigates to promo description screen (if the promo is not > having any promoText), from makeAutoDescription method of ProductPromoWorker, > the description is prepared and shown on UI. > As per current code implementation, we are not having the support of which > party classification condition is included in the Promo description. > Steps to verify, > 1.) Create a Promo with condition on Party Classification (for this you need > to create the party classification group) > 2.) Assign any demo customer to this group > 3.) Create a sales order (from Order Entry or E-Commerce) and apply the promo > code. > 4.) Now as the Promo is applied, it showed on cart screen, select 'details' > option in front of the promo code. > 5.) The promo detail screen will be shown (now the description shown of Promo > in incorrect, since there is not support of party classification condition in > the auto-generated promo description) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-7027) Added support to include party classification information in Promo description
[ https://issues.apache.org/jira/browse/OFBIZ-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mridul Pathak reassigned OFBIZ-7027: Assignee: Mridul Pathak > Added support to include party classification information in Promo description > -- > > Key: OFBIZ-7027 > URL: https://issues.apache.org/jira/browse/OFBIZ-7027 > Project: OFBiz > Issue Type: Improvement > Components: order, specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Swapnil M Mane >Assignee: Mridul Pathak >Priority: Minor > Attachments: OFBIZ-7027.patch > > > When the user navigates to promo description screen (if the promo is not > having any promoText), from makeAutoDescription method of ProductPromoWorker, > the description is prepared and shown on UI. > As per current code implementation, we are not having the support of which > party classification condition is included in the Promo description. > Steps to verify, > 1.) Create a Promo with condition on Party Classification (for this you need > to create the party classification group) > 2.) Assign any demo customer to this group > 3.) Create a sales order (from Order Entry or E-Commerce) and apply the promo > code. > 4.) Now as the Promo is applied, it showed on cart screen, select 'details' > option in front of the promo code. > 5.) The promo detail screen will be shown (now the description shown of Promo > in incorrect, since there is not support of party classification condition in > the auto-generated promo description) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7027) Added support to include party classification information in Promo description
[ https://issues.apache.org/jira/browse/OFBIZ-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil M Mane updated OFBIZ-7027: -- Attachment: OFBIZ-7027.patch > Added support to include party classification information in Promo description > -- > > Key: OFBIZ-7027 > URL: https://issues.apache.org/jira/browse/OFBIZ-7027 > Project: OFBiz > Issue Type: Improvement > Components: order, specialpurpose/ecommerce >Affects Versions: Trunk, Upcoming Branch >Reporter: Swapnil M Mane >Priority: Minor > Attachments: OFBIZ-7027.patch > > > When the user navigates to promo description screen (if the promo is not > having any promoText), from makeAutoDescription method of ProductPromoWorker, > the description is prepared and shown on UI. > As per current code implementation, we are not having the support of which > party classification condition is included in the Promo description. > Steps to verify, > 1.) Create a Promo with condition on Party Classification (for this you need > to create the party classification group) > 2.) Assign any demo customer to this group > 3.) Create a sales order (from Order Entry or E-Commerce) and apply the promo > code. > 4.) Now as the Promo is applied, it showed on cart screen, select 'details' > option in front of the promo code. > 5.) The promo detail screen will be shown (now the description shown of Promo > in incorrect, since there is not support of party classification condition in > the auto-generated promo description) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7003) Error when accessing project manager
[
https://issues.apache.org/jira/browse/OFBIZ-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262189#comment-15262189
]
Montalbano Florian commented on OFBIZ-7003:
---
Hi,
I looked into the problem and found where this error comes from.
When the project list is loaded, it uses the form "ListCurrentProjects" from
the file ProjectsForms.xml.
In this form, the diffrent informations about the projects are loaded.
The error indicates that the property "actualNonBilledTotalHours" does not
exist in the current context. And this value is used in this line :
The condition means : If the hours are billable And there is at least 1 hour
not billed Then display this number of hours Else diplay ""
I'm not sure about the "!=void" thing, I would use Util.isNotEmpty instead.
When the condition is checked, the property actualNonBilledTotalHours is
searched through the context but is not found.
I search something that was related to this property and found the
simple-method "getHours" from the file "WorkEffortSimpleServices.xml". Under
the right condition, it does evaluate and return the property. But the thing is
that this method is not called by the "ListCurrentProject". And one of the
reason is that this method is not available as a service.
So the problem behind this one is that there is nothing to put the
"actualNonBilledTotalHours" in the context of "ListCurrentProject" thus showing
the error about this property missing.
To solve this problem, either a service can be created to call the method
getHours and then updating the ListCurrentProject (this choice is to be made by
the community) or this feature about the "actualNonBilledTotalHours" can be
dropped (choice decided by the community too).
I hope I'm not mistaking about the root problem and hope that will help you.
Have a nice day,
Florian
> Error when accessing project manager
>
>
> Key: OFBIZ-7003
> URL: https://issues.apache.org/jira/browse/OFBIZ-7003
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: james yong
>Priority: Minor
>
> I am running SVN version 1738958.
> Problem
> ===
> I navigate to https://localhost:8443/projectmgr, and found the following
> error on the console:
> {code}
> 2016-04-14 22:31:56,648 |http-nio-8443-exec-3 |ServiceDispatcher
> |T| Sync service [projectmgr/getProject] finished in [24] milliseconds
> 2016-04-14 22:31:56,724 |http-nio-8443-exec-3 |FlexibleStringExpander
> |W| Error evaluating scriptlet
> [${groovy:isBillable&!=void?actualNonBilledTotalHours:""}];
> error was: groovy.lang.MissingPropertyException: No such property:
> actualNonBilledTotalHours for class: script14606441839311459442740
> groovy.lang.MissingPropertyException: No such property:
> actualNonBilledTotalHours for class: script14606441839311459442740
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
> ~[groovy-all-2.4.5.jar:2.4.5]
> at
> org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:52)
> ~[groovy-all-2.4.5.jar:2.4.5]
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307)
> ~[groovy-all-2.4.5.jar:2.4.5]
> at
> script14606441839311459442740.run(script14606441839311459442740.groovy:1)
> ~[?:?]
> at org.ofbiz.base.util.ScriptUtil.evaluate(ScriptUtil.java:263)
> ~[ofbiz-base.jar:?]
> at
> org.ofbiz.base.util.string.FlexibleStringExpander$ScriptElem.get(FlexibleStringExpander.java:657)
> [ofbiz-base.jar:?]
> at
> org.ofbiz.base.util.string.FlexibleStringExpander.expandString(FlexibleStringExpander.java:437)
> [ofbiz-base.jar:?]
> at
> org.ofbiz.base.util.string.FlexibleStringExpander.expandString(FlexibleStringExpander.java:407)
> [ofbiz-base.jar:?]
> at
> org.ofbiz.widget.model.ModelFormField$DisplayField.getDescription(ModelFormField.java:1496)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDisplayField(MacroFormRenderer.java:194)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.model.ModelFormField$DisplayField.renderFieldString(ModelFormField.java:1615)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:724)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.renderer.FormRenderer.renderItemRow(FormRenderer.java:582)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.renderer.FormRenderer.renderItemRows(FormRenderer.java:899)
> [ofbiz-widget.jar:?]
> at
> org.ofbiz.widget.renderer.FormRenderer.renderListFormString(FormRenderer.java:941)
> [ofbiz-widget.jar:?]
> at
[jira] [Created] (OFBIZ-7027) Added support to include party classification information in Promo description
Swapnil M Mane created OFBIZ-7027: - Summary: Added support to include party classification information in Promo description Key: OFBIZ-7027 URL: https://issues.apache.org/jira/browse/OFBIZ-7027 Project: OFBiz Issue Type: Improvement Components: order, specialpurpose/ecommerce Affects Versions: Trunk, Upcoming Branch Reporter: Swapnil M Mane Priority: Minor When the user navigates to promo description screen (if the promo is not having any promoText), from makeAutoDescription method of ProductPromoWorker, the description is prepared and shown on UI. As per current code implementation, we are not having the support of which party classification condition is included in the Promo description. Steps to verify, 1.) Create a Promo with condition on Party Classification (for this you need to create the party classification group) 2.) Assign any demo customer to this group 3.) Create a sales order (from Order Entry or E-Commerce) and apply the promo code. 4.) Now as the Promo is applied, it showed on cart screen, select 'details' option in front of the promo code. 5.) The promo detail screen will be shown (now the description shown of Promo in incorrect, since there is not support of party classification condition in the auto-generated promo description) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Solr libs duplication
Thanks Shingai! And while at it, if it's possible, it would be good, for security reason, to upgrade (or remember to upgrade) Hadoop libs, used in Solr component, to the 2.7.2 version. This is due to https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1776 which is quite recent. I don't know (did not try) if it's possible to simply upgrade the libs or to wait for a new Solr version covering the issue. I checked the last available Solr version (6.0.0) does not. For details see https://svn.apache.org/viewvc/ofbiz/trunk/tools/security/dependency-check/dependency-check-report.html?view=co=HEAD Thanks Jacques Le 28/04/2016 à 06:06, Shi Jinghai a écrit : Thanks Christian! I created an issue on the jars duplicated: https://issues.apache.org/jira/browse/OFBIZ-7026 I'll remove the dupliations step by step. Kind Regards, Shi Jinghai -邮件原件- 发件人: Christian Geisert [mailto:christian.geis...@isu-gmbh.de] 发送时间: 2016年4月27日 18:02 收件人: dev@ofbiz.apache.org 主题: Re: Solr libs duplication There are also duplicates with regards to framework (noticed that while integrating Apache Camel, but didn't have time to work on it yet) ./specialpurpose/solr/webapp/solr/WEB-INF/lib/concurrentlinkedhashmap-lru-1.2.jar ./framework/base/lib/clhm-release-1.0-lru.jar I think version 1.2 should be moved to framework. Christian Am 27.04.2016 11:34, schrieb Shi Jinghai: Hi Jacques, Obviously it's my fault :-( The duplicated jars under webapp /solr/WEB-INF/lib/ can be removed as they are already common jars at container level. I'll remove the duplicated jars ASAP. Kind Regards, Shi Jinghai -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2016年4月26日 17:58 收件人: dev@ofbiz.apache.org; shi.jinghai 主题: Solr libs duplication Hi Jinghai, Do you think it's possible to somehow avoid these duplications in Solr component? C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\joda-time-2.2.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\joda-time-2.2.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-codecs-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-codecs-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-highlighter-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-highlighter-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-join-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-join-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-queries-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-queries-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-spatial-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-spatial-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-suggest-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-suggest-5.3.1.jar I think it must be hard (if even possible) because it's runtime dependencies, right? Thanks Jacques
Re: Solr libs duplication
About concurrentlinkedhashmap the author himself recommends to use Guava or possibly his last version built for Java 8 https://stackoverflow.com/questions/15299554/what-does-it-mean-that-concurrentlinkedhashmap-has-been-integrated-into-guava Please check Thanks Jacques Le 28/04/2016 à 06:06, Shi Jinghai a écrit : Thanks Christian! I created an issue on the jars duplicated: https://issues.apache.org/jira/browse/OFBIZ-7026 I'll remove the dupliations step by step. Kind Regards, Shi Jinghai -邮件原件- 发件人: Christian Geisert [mailto:christian.geis...@isu-gmbh.de] 发送时间: 2016年4月27日 18:02 收件人: dev@ofbiz.apache.org 主题: Re: Solr libs duplication There are also duplicates with regards to framework (noticed that while integrating Apache Camel, but didn't have time to work on it yet) ./specialpurpose/solr/webapp/solr/WEB-INF/lib/concurrentlinkedhashmap-lru-1.2.jar ./framework/base/lib/clhm-release-1.0-lru.jar I think version 1.2 should be moved to framework. Christian Am 27.04.2016 11:34, schrieb Shi Jinghai: Hi Jacques, Obviously it's my fault :-( The duplicated jars under webapp /solr/WEB-INF/lib/ can be removed as they are already common jars at container level. I'll remove the duplicated jars ASAP. Kind Regards, Shi Jinghai -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2016年4月26日 17:58 收件人: dev@ofbiz.apache.org; shi.jinghai 主题: Solr libs duplication Hi Jinghai, Do you think it's possible to somehow avoid these duplications in Solr component? C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\joda-time-2.2.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\joda-time-2.2.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-codecs-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-codecs-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-highlighter-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-highlighter-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-join-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-join-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-queries-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-queries-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-spatial-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-spatial-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\lib\runtime\lucene-suggest-5.3.1.jar C:\projectASF-Mars\ofbiz\specialpurpose\solr\webapp\solr\WEB-INF\lib\lucene-suggest-5.3.1.jar I think it must be hard (if even possible) because it's runtime dependencies, right? Thanks Jacques
[jira] [Closed] (OFBIZ-7025) Email-Notification send multiple times
[ https://issues.apache.org/jira/browse/OFBIZ-7025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-7025. -- Resolution: Fixed Fix Version/s: Upcoming Branch Thanks Ingo, Your patch is in trunk revision: 1741393 > Email-Notification send multiple times > -- > > Key: OFBIZ-7025 > URL: https://issues.apache.org/jira/browse/OFBIZ-7025 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > Attachments: services.xml.patch > > > Enable E-Mail Notifications > Create order (trigger sendOrderConfirmation) > --> createOrderNotificationLog fails due to missing PK in "entity-auto" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-7025) Email-Notification send multiple times
[ https://issues.apache.org/jira/browse/OFBIZ-7025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-7025: -- Assignee: Jacques Le Roux > Email-Notification send multiple times > -- > > Key: OFBIZ-7025 > URL: https://issues.apache.org/jira/browse/OFBIZ-7025 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux > Attachments: services.xml.patch > > > Enable E-Mail Notifications > Create order (trigger sendOrderConfirmation) > --> createOrderNotificationLog fails due to missing PK in "entity-auto" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5732) Error in sendMailHiddenInLog service
[
https://issues.apache.org/jira/browse/OFBIZ-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261770#comment-15261770
]
Jacques Le Roux commented on OFBIZ-5732:
Hi Wei,
If you do please check the related issues, to see if it fixes them also or help
at least, thanks!
Thanks Gareth for feedback
> 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
>
> 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-5732) Error in sendMailHiddenInLog service
[
https://issues.apache.org/jira/browse/OFBIZ-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261727#comment-15261727
]
Gareth Carter commented on OFBIZ-5732:
--
I would, we've applied this as a patch in our production systems now and works
fine.
> 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
>
> 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)
Refactoring Start.java
Hello Folks, Since I'm touching the bootstrapping code in ofbiz and doing open heart surgery, I would appreciate comments and feedback on the first patch to ensure that I'm on the right track. You can find the patch in https://issues.apache.org/jira/browse/OFBIZ-6783 All tests pass, the class is still ugly and messy, but this is a first step. Thank you in advance for your help! Taher Alkhateeb.
[jira] [Commented] (OFBIZ-6783) Refactor start.java
[ https://issues.apache.org/jira/browse/OFBIZ-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261621#comment-15261621 ] Taher Alkhateeb commented on OFBIZ-6783: I also forgot to mention that I deleted the list loaderArgs declared inside main, it is simply not used for any purpose > 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-6783) Refactor start.java
[ https://issues.apache.org/jira/browse/OFBIZ-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb updated OFBIZ-6783: --- Attachment: OFBIZ-6783.patch Hey everyone, please check this patch, I've done the following so far: - remove private comments relating to the class to the JavaDoc location at the top of the class - relocate class fields to the top of the class as per Java conventions - relocate the constructor with its singleton instance to the top of the class below the fields - sort all the methods starting with main, followed by public, default and private - add JavaDoc to main - remove System.exit(99) from main and replace it with throw new StartException(e); I did this because main declares that it throws a StartupException which it never does - breakup the logic part to evaluate ofbiz command to a new method called evaluateOfbizCommand(String[] args). I will replace this eventually with apache commons-cli - make startStartLoaders private, since it is not called outside Start.java > 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)
