[jira] [Created] (OFBIZ-7040) Redesign EntitySaxReader
Martin Becker created OFBIZ-7040: Summary: Redesign EntitySaxReader Key: OFBIZ-7040 URL: https://issues.apache.org/jira/browse/OFBIZ-7040 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor org.ofbiz.entity.util.EntitySaxReader requires refactoring to achieve the following goals Refactor EntitySaxReader to an interface Create an implementing class Remove all dependencies on Javolution Fix all dependencies in the framework to match the new signature of the interface Delete the javolution library from the framework Taken from the Refactor ToDo list at https://cwiki.apache.org/confluence/display/OFBIZ/Re-Factor+To-Do+List -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-7039) Parameterize everything in DebugManagedDataSource
Martin Becker created OFBIZ-7039: Summary: Parameterize everything in DebugManagedDataSource Key: OFBIZ-7039 URL: https://issues.apache.org/jira/browse/OFBIZ-7039 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor Generics need to be introduced to multiple places. Requires knowledge in commons-pool Taken from the Refactor ToDo list at https://cwiki.apache.org/confluence/display/OFBIZ/Re-Factor+To-Do+List -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6984) CommonWorkers.java needs simplifying and cleaning up
Martin Becker created OFBIZ-6984: Summary: CommonWorkers.java needs simplifying and cleaning up Key: OFBIZ-6984 URL: https://issues.apache.org/jira/browse/OFBIZ-6984 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Trivial Refactor CommonWorkers.java. Lots of code is repetitive and can be factored out into shared private methods. This includes things like: * Exception handling * Queries * Building the return data structures Taken from the Refactor ToDo list at https://cwiki.apache.org/confluence/display/OFBIZ/Re-Factor+To-Do+List -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6651) Remove deprecated methods from GenericValue and EntityUtil classes
[
https://issues.apache.org/jira/browse/OFBIZ-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14904295#comment-14904295
]
Martin Becker commented on OFBIZ-6651:
--
Oh yes, I see, sorry. Maybe I should have used the full text search by my own
when I build the fix for OFBIZ-6276 a few month ago...
> Remove deprecated methods from GenericValue and EntityUtil classes
> ---
>
> Key: OFBIZ-6651
> URL: https://issues.apache.org/jira/browse/OFBIZ-6651
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> Strategy:
> # Using an IDE replace the deprecated methods in Java code (but not in
> GenericValue class)
> # Before removing the deprecated methods from GenericValue class, place
> {code}
> Debug.logWarning("deprecated 'methodName', please replace them, see
> OFBIZ-6651", new Exception());
> {code}
> in them. On the long run, this will allow to spot where these methods are
> used in templates and scripts and replace them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6651) Remove deprecated methods from GenericValue class
[
https://issues.apache.org/jira/browse/OFBIZ-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14904119#comment-14904119
]
Martin Becker commented on OFBIZ-6651:
--
Why not just using the full text search for finding occurrences in templates,
screen-definitions and scripts?
> Remove deprecated methods from GenericValue class
> -
>
> Key: OFBIZ-6651
> URL: https://issues.apache.org/jira/browse/OFBIZ-6651
> Project: OFBiz
> Issue Type: Task
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> Strategy:
> # Using an IDE replace the deprecated methods in Java code (but not in
> GenericValue class)
> # Before removing the deprecated methods from GenericValue class, place
> {code}
> Debug.logWarning("deprecated 'methodName', please replace them, see
> OFBIZ-6651", new Exception());
> {code}
> in them. On the long run, this will allow to spot where these methods are
> used in templates and scripts and replace them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-293) data import - nulling fields impossible
[ https://issues.apache.org/jira/browse/OFBIZ-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14904278#comment-14904278 ] Martin Becker commented on OFBIZ-293: - The use of the xsi:nil attribute is basically correct but is no solution for the problem we have to represent NULL values in XML element attributes, used for entity attributes. As I see, the xsi:nil attribute is only for defining a XML element as NULL, in our use case the entity itself. My thought was to improve the current logic without compromising current legacy data and usage. For now, empty string attribute values are ignored when loading XML entity data, that is just not correct. If we treat them as empty string, what would be the most correct solution, we not really gain a functional benefit but need to fix existing entity data files with for example ...parentTypeId=""... in it. For a full update while syncing data over the entity xml mechanism, the current solution with an additional specified action like "REPLACE" meets the requirements and the "XML Standard" by interpreting missing entity field (xml attributes) as NULL values. The gap I want to fill is the default action for loading entity XML data, where only explicitly defined fields are part of an update and there should be the possibility to "clear" single field values. There should only be very rare cases where someone would want to define and insert empty strings instead of NULL. Not even the current logic support this. > data import - nulling fields impossible > --- > > Key: OFBIZ-293 > URL: https://issues.apache.org/jira/browse/OFBIZ-293 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Marco Risaliti >Priority: Minor > Attachments: OFBIZ-293_set-empty-strings-as-null.patch, > ofbiz-293-patch.txt, ofbiz-462-patch.txt > > > It's a copy of the old-jira issue > http://jira.undersunconsulting.com/browse/OFBIZ-462 Tarlika Elisabeth Schmitz > = > I am on rev 5274. > data import from .xml file: empty attributes (e.g. description="") are > ignored and the field retains its former value. > Comment by Chris Juettner [04/Oct/05 01:51 PM] > This patch comments out the check for null or empty values in the data XML > file found by the EntitySaxReader. I also added an additional warning message > in case you do not want to persist empty values to the database but still > would like to know what happened. > Comment by Si Chen [04/Oct/05 01:59 PM] > Chris- > Just a comment: it's very important that a field in the entity engine is set > to null ONLY when the XML file specifically has an empty attribute (ie, > description=""). Otherwise, there's a lot of seed data that is in separate > XML files, and they could overwrite each other. > Comment by Chris Juettner [10/Oct/05 11:56 AM] [ Permlink ] > Si, > I'm not sure I understand your comment about seed data in seperate XML files > overwriting each other. Shouldn't seed data XML files be entity specific? Why > would one seed data XML file overwrite another? > Do you have any comment on what a better solution is for seed data values > that could be empty? > Thanks > Chris -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6641) Missing CountryCodeData.xml values for countries of the former Yugoslavia
[ https://issues.apache.org/jira/browse/OFBIZ-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6641: - Attachment: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch > Missing CountryCodeData.xml values for countries of the former Yugoslavia > - > > Key: OFBIZ-6641 > URL: https://issues.apache.org/jira/browse/OFBIZ-6641 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > Attachments: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch > > > Instead of former YUGOSLAVIA there should be SERBIA. > Also CountryTeleCode and CountryCapital is missing for MONTENEGRO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6640) Eclipse .classpath contains internal Groovy Library classpath container
[
https://issues.apache.org/jira/browse/OFBIZ-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Becker updated OFBIZ-6640:
-
Attachment: OFBIZ-6640_Removed-Groovy-CP-CONs.patch
> Eclipse .classpath contains internal Groovy Library classpath container
> ---
>
> Key: OFBIZ-6640
> URL: https://issues.apache.org/jira/browse/OFBIZ-6640
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
>Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6640_Removed-Groovy-CP-CONs.patch
>
>
> There are unnecessarily eclipse internal Groovy Library classpath container
> referenced in the .classpath file. This may lead to conflicts with the OFBiz
> "original" groovy libs contained in the framework and produces errors while
> running OFBiz within eclipse.
> {{}}
> {{}}
> I'll provide a patch for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-1032) EntitySaxReader mostly-insert (store after create-error) Fix
[ https://issues.apache.org/jira/browse/OFBIZ-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-1032: - Attachment: OFBIZ-1032_Remove-fallback-store.patch I removed the unnecessary call to store after a failing create on "mostly-inserts" activated. This call to store can never be successful, because the running transaction is already marked rollback only because of the failed create attempt. Instead it pollutes the log with additional errors. The old patch in this issue uses a delegator API that does not exist, maybe there had to be additional patches for that. Conceptual I think, the data load with "mostly inserts" activated should fail on a create-failure (what it does indeed already), so I see no need for a working solution of a fallback store attempt. Consistently the Feature should be renamed in the frontend from "mostly inserts" to "only inserts". Additional trivial refactoring in the patch: I reduced the full qualified classname of org.xml.sax.SAXException in method signatures to the simple name. > EntitySaxReader mostly-insert (store after create-error) Fix > > > Key: OFBIZ-1032 > URL: https://issues.apache.org/jira/browse/OFBIZ-1032 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk > Environment: Win XP >Reporter: Karl Eilebrecht >Assignee: Adam Heath >Priority: Minor > Attachments: OFBIZ-1032_Remove-fallback-store.patch, patch9675.patch > > > This issue is part of Key-Work Ofbiz Contribution Proposal. > http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal > Based on Release: 540035 > Includes: - > Required: JIRA-1031, JIRA-1030, JIRA-1029, JIRA-1017, JIRA-1016 > Recommended: - > Classes: EntitySaxReader > Description: Avoids rollback on create error to be able to store the > entity instead (mostly-inserts feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6641) Missing CountryCodeData.xml values for countries of the former Yugoslavia
[ https://issues.apache.org/jira/browse/OFBIZ-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6641: - Sprint: Community Day 3 - 2015 > Missing CountryCodeData.xml values for countries of the former Yugoslavia > - > > Key: OFBIZ-6641 > URL: https://issues.apache.org/jira/browse/OFBIZ-6641 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > Attachments: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch > > > Instead of former YUGOSLAVIA there should be SERBIA. > Also CountryTeleCode and CountryCapital is missing for MONTENEGRO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-1032) EntitySaxReader mostly-insert (store after create-error) Fix
[ https://issues.apache.org/jira/browse/OFBIZ-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-1032: - Sprint: Bug Crush Event - 21/2/2015, Community Day 3 - 2015 (was: Bug Crush Event - 21/2/2015) > EntitySaxReader mostly-insert (store after create-error) Fix > > > Key: OFBIZ-1032 > URL: https://issues.apache.org/jira/browse/OFBIZ-1032 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk > Environment: Win XP >Reporter: Karl Eilebrecht >Assignee: Adam Heath >Priority: Minor > Attachments: patch9675.patch > > > This issue is part of Key-Work Ofbiz Contribution Proposal. > http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal > Based on Release: 540035 > Includes: - > Required: JIRA-1031, JIRA-1030, JIRA-1029, JIRA-1017, JIRA-1016 > Recommended: - > Classes: EntitySaxReader > Description: Avoids rollback on create error to be able to store the > entity instead (mostly-inserts feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-293) data import - nulling fields impossible
[ https://issues.apache.org/jira/browse/OFBIZ-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-293: Sprint: Bug Crush Event - 21/2/2015, Community Day 3 - 2015 (was: Bug Crush Event - 21/2/2015) > data import - nulling fields impossible > --- > > Key: OFBIZ-293 > URL: https://issues.apache.org/jira/browse/OFBIZ-293 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Marco Risaliti >Priority: Minor > Attachments: OFBIZ-293_set-empty-strings-as-null.patch, > ofbiz-293-patch.txt, ofbiz-462-patch.txt > > > It's a copy of the old-jira issue > http://jira.undersunconsulting.com/browse/OFBIZ-462 Tarlika Elisabeth Schmitz > = > I am on rev 5274. > data import from .xml file: empty attributes (e.g. description="") are > ignored and the field retains its former value. > > > AllCommentsWork LogChange History Sort Order: > Comment by Chris Juettner [04/Oct/05 01:51 PM] [ Permlink ] > This patch comments out the check for null or empty values in the data XML > file found by the EntitySaxReader. I also added an additional warning message > in case you do not want to persist empty values to the database but still > would like to know what happened. > Comment by Si Chen [04/Oct/05 01:59 PM] [ Permlink ] > Chris- > Just a comment: it's very important that a field in the entity engine is set > to null ONLY when the XML file specifically has an empty attribute (ie, > description=""). Otherwise, there's a lot of seed data that is in separate > XML files, and they could overwrite each other. > Si > Comment by Chris Juettner [10/Oct/05 11:56 AM] [ Permlink ] > Si, > I'm not sure I understand your comment about seed data in seperate XML files > overwriting each other. Shouldn't seed data XML files be entity specific? Why > would one seed data XML file overwrite another? > Do you have any comment on what a better solution is for seed data values > that could be empty? > Thanks > Chris -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-293) data import - nulling fields impossible
[ https://issues.apache.org/jira/browse/OFBIZ-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-293: Attachment: OFBIZ-293_set-empty-strings-as-null.patch I've attached an updated version of the patch from 2011. In my opinion it would be straight forward, if the entity import would treat fields that are mentioned in entity XML files as fields that should be updated always, as the GenericDAO does. The current logic ignores fields, if there is only an empty string as value. The enhancement brought by the solution of OFBIZ-4949 makes it possible to generally configure an entity-engine-xml file to be interpreted as replacement, so that all NOT mentioned fields are set to NULL instead of leaving the old value while updating the entity. Nevertheless I think, that the default (update) behavior, the one with fine grained control over which fields are touched, should also give the possibility to set field values to NULL by including them in the XML. The solution with the lowest impact on existing XML files and the most natural meaning should be to interpret empty string values in the XML as NULL, as it is today. The only difference would be, that they are not longer ignored but set as NULL values in the database. The only drawback I see is, that you're still not able to set "empty string" values as concrete values to the database (no loss of function, because you can't do it today, too). As far as I can see, there should be no conflict with current existing data files. There are some where for example a parentTypeId is contained with empty string as value. Interpreting it as NULL and setting in database is exactly what is meant by such a definition. > data import - nulling fields impossible > --- > > Key: OFBIZ-293 > URL: https://issues.apache.org/jira/browse/OFBIZ-293 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Marco Risaliti >Priority: Minor > Attachments: OFBIZ-293_set-empty-strings-as-null.patch, > ofbiz-293-patch.txt, ofbiz-462-patch.txt > > > It's a copy of the old-jira issue > http://jira.undersunconsulting.com/browse/OFBIZ-462 Tarlika Elisabeth Schmitz > = > I am on rev 5274. > data import from .xml file: empty attributes (e.g. description="") are > ignored and the field retains its former value. > > > AllCommentsWork LogChange History Sort Order: > Comment by Chris Juettner [04/Oct/05 01:51 PM] [ Permlink ] > This patch comments out the check for null or empty values in the data XML > file found by the EntitySaxReader. I also added an additional warning message > in case you do not want to persist empty values to the database but still > would like to know what happened. > Comment by Si Chen [04/Oct/05 01:59 PM] [ Permlink ] > Chris- > Just a comment: it's very important that a field in the entity engine is set > to null ONLY when the XML file specifically has an empty attribute (ie, > description=""). Otherwise, there's a lot of seed data that is in separate > XML files, and they could overwrite each other. > Si > Comment by Chris Juettner [10/Oct/05 11:56 AM] [ Permlink ] > Si, > I'm not sure I understand your comment about seed data in seperate XML files > overwriting each other. Shouldn't seed data XML files be entity specific? Why > would one seed data XML file overwrite another? > Do you have any comment on what a better solution is for seed data values > that could be empty? > Thanks > Chris -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6640) Eclipse .classpath contains internal Groovy Library classpath container
Martin Becker created OFBIZ-6640:
Summary: Eclipse .classpath contains internal Groovy Library
classpath container
Key: OFBIZ-6640
URL: https://issues.apache.org/jira/browse/OFBIZ-6640
Project: OFBiz
Issue Type: Bug
Components: ALL COMPONENTS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor
There are unnecessarily eclipse internal Groovy Library classpath container
referenced in the .classpath file. This may lead to conflicts with the OFBiz
"original" groovy libs contained in the framework and produces errors while
running OFBiz within eclipse.
{{}}
{{}}
I'll provide a patch for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6641) Missing CountryCodeData.xml values for countries of the former Yugoslavia
Martin Becker created OFBIZ-6641: Summary: Missing CountryCodeData.xml values for countries of the former Yugoslavia Key: OFBIZ-6641 URL: https://issues.apache.org/jira/browse/OFBIZ-6641 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor Instead of former YUGOSLAVIA there should be SERBIA. Also CountryTeleCode and CountryCapital is missing for MONTENEGRO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14876955#comment-14876955 ] Martin Becker commented on OFBIZ-6276: -- Hi Jacques, now there have been two more month passed ;-) > Fix deprecation issues in framework/entity > -- > > Key: OFBIZ-6276 > URL: https://issues.apache.org/jira/browse/OFBIZ-6276 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Reporter: Adam Heath >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-6276-EntityStoreOptions.patch, > OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch > > > It appears that the storeAll() variants are being refactor; basically, the > useCache parameter is being removed. However, this has caused the > entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed
Martin Becker created OFBIZ-6630: Summary: Update ShoppingCartItem locale if ShoppingCart locale is changed Key: OFBIZ-6630 URL: https://issues.apache.org/jira/browse/OFBIZ-6630 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor If the locale of the cart is changed, for example by choosing the language in frontend and setting the locale by CommonEvents.setSessionLocale, the locale stored in each cart item isn't updated. A call to item.getName() for example uses the wrong locale afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed
[ https://issues.apache.org/jira/browse/OFBIZ-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6630: - Attachment: OFBIZ-6630-KeepCartItemLocalInSync.patch > Update ShoppingCartItem locale if ShoppingCart locale is changed > > > Key: OFBIZ-6630 > URL: https://issues.apache.org/jira/browse/OFBIZ-6630 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > Attachments: OFBIZ-6630-KeepCartItemLocalInSync.patch > > > If the locale of the cart is changed, for example by choosing the language in > frontend and setting the locale by CommonEvents.setSessionLocale and updating > the cart locale by keepCartUpdated event, the locale stored in each cart item > isn't updated. A call to item.getName() for example uses the wrong locale > afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6631) Optimize ShoppingCart.removeCartItem (skip price calc and inventory check)
Martin Becker created OFBIZ-6631: Summary: Optimize ShoppingCart.removeCartItem (skip price calc and inventory check) Key: OFBIZ-6631 URL: https://issues.apache.org/jira/browse/OFBIZ-6631 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor Based on the standard parameter completion from the overloaded API of ShoppingCartItem.setQuantity, the use of the ShoppingCart.removeCartItem method leads to an unnecessary price calculation and inventory check for the item being removed. By using the setQuantity method with full parameter list in this case, this can be avoided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6631) Optimize ShoppingCart.removeCartItem (skip price calc and inventory check)
[ https://issues.apache.org/jira/browse/OFBIZ-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6631: - Attachment: OFBIZ-6631-Optimized-RemoveCartItem.patch > Optimize ShoppingCart.removeCartItem (skip price calc and inventory check) > -- > > Key: OFBIZ-6631 > URL: https://issues.apache.org/jira/browse/OFBIZ-6631 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > Attachments: OFBIZ-6631-Optimized-RemoveCartItem.patch > > > Based on the standard parameter completion from the overloaded API of > ShoppingCartItem.setQuantity, the use of the ShoppingCart.removeCartItem > method leads to an unnecessary price calculation and inventory check for the > item being removed. > By using the setQuantity method with full parameter list in this case, this > can be avoided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877013#comment-14877013 ] Martin Becker commented on OFBIZ-6276: -- Hi Jacques, did you have a problem to apply the OFBIZ-6276-EntityStoreOptions.patch? It is in universal diff format and I just tried to apply it within my eclipse and it worked fine. > Fix deprecation issues in framework/entity > -- > > Key: OFBIZ-6276 > URL: https://issues.apache.org/jira/browse/OFBIZ-6276 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Reporter: Adam Heath >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-6276-EntityStoreOptions.patch, > OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch > > > It appears that the storeAll() variants are being refactor; basically, the > useCache parameter is being removed. However, this has caused the > entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6629) Duplicate calculation and typo in ShoppingCart.getGrandTotal()
[ https://issues.apache.org/jira/browse/OFBIZ-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6629: - Attachment: OFBIZ-6629.patch I added a type parameter to an Iterator in renamed method getOrderGlobalAdjustments(), too > Duplicate calculation and typo in ShoppingCart.getGrandTotal() > -- > > Key: OFBIZ-6629 > URL: https://issues.apache.org/jira/browse/OFBIZ-6629 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > Attachments: OFBIZ-6629.patch > > > The shopping cart grand total ist calculated twice in getGrandTotal(). > In addition, the Method getOrderGlobalAdjusments() is misspelled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled
Martin Becker created OFBIZ-6635: Summary: Old UserLogin from userLoginId-change is not correctly disabled Key: OFBIZ-6635 URL: https://issues.apache.org/jira/browse/OFBIZ-6635 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Critical If a userLoginId of an existing user is updated by LoginServices.updateUserLoginId, a new UserLogin value is created with the data of the old one and the old one is disabled afterwards. In addition to switch the enabled flag to "N" the disabledDateTime is set to current date. This is wrong because this makes it possible to reenable the old UserLogin by just do a login with the old userLoginId (standard mechanism to lock the login for a while after subsequent failed login requests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled
[ https://issues.apache.org/jira/browse/OFBIZ-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6635: - Attachment: OFBIZ-6635-FixedDisablingOldUserLogin.patch > Old UserLogin from userLoginId-change is not correctly disabled > --- > > Key: OFBIZ-6635 > URL: https://issues.apache.org/jira/browse/OFBIZ-6635 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Critical > Attachments: OFBIZ-6635-FixedDisablingOldUserLogin.patch > > > If a userLoginId of an existing user is updated by > LoginServices.updateUserLoginId, a new UserLogin value is created with the > data of the old one and the old one is disabled afterwards. In addition to > switch the enabled flag to "N" the disabledDateTime is set to current date. > This is wrong because this makes it possible to reenable the old UserLogin by > just do a login with the old userLoginId (standard mechanism to lock the > login for a while after subsequent failed login requests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6632) Incorrect comparison in TemporalExpressionWorker.java
[
https://issues.apache.org/jira/browse/OFBIZ-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Becker updated OFBIZ-6632:
-
Attachment: OFBIZ-6632-Fixed-exprAssocType-values.patch
Fixed the entitymodel.xml comment and the comparison in
TemporalExpressionWorker and added constants for the three mentioned values.
Maybe a Java Enum or the use of the OFBiz Enumeration for referential integrity
in database may be a more complete solution.
> Incorrect comparison in TemporalExpressionWorker.java
> -
>
> Key: OFBIZ-6632
> URL: https://issues.apache.org/jira/browse/OFBIZ-6632
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Vyom Jain
> Attachments: OFBIZ-6632-Fixed-exprAssocType-values.patch
>
>
> Line 128 in TemporalExpressionWorker.java does incorrect comparison
> {code}
> if ("SUBSTITUTION".equals(childExpression.get("exprAssocType"))) {
> {code} should be
> {code}
> if ("SUBSTITUTE".equals(childExpression.get("exprAssocType"))) {
> {code}
> Also documentation of field exprAssocType in entity definition of
> TemporalExpressionAssoc needs to be fixed. INCLUDED & EXCLUDED should be
> INCLUDE & EXCLUDE respectively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6629) Duplicate calculation and typo in ShoppingCart.getGrandTotal()
Martin Becker created OFBIZ-6629: Summary: Duplicate calculation and typo in ShoppingCart.getGrandTotal() Key: OFBIZ-6629 URL: https://issues.apache.org/jira/browse/OFBIZ-6629 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor The shopping cart grand total ist calculated twice in getGrandTotal(). In addition, the Method getOrderGlobalAdjusments() is misspelled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed
[ https://issues.apache.org/jira/browse/OFBIZ-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6630: - Description: If the locale of the cart is changed, for example by choosing the language in frontend and setting the locale by CommonEvents.setSessionLocale and updating the cart locale by keepCartUpdated event, the locale stored in each cart item isn't updated. A call to item.getName() for example uses the wrong locale afterwards. (was: If the locale of the cart is changed, for example by choosing the language in frontend and setting the locale by CommonEvents.setSessionLocale, the locale stored in each cart item isn't updated. A call to item.getName() for example uses the wrong locale afterwards.) > Update ShoppingCartItem locale if ShoppingCart locale is changed > > > Key: OFBIZ-6630 > URL: https://issues.apache.org/jira/browse/OFBIZ-6630 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Minor > > If the locale of the cart is changed, for example by choosing the language in > frontend and setting the locale by CommonEvents.setSessionLocale and updating > the cart locale by keepCartUpdated event, the locale stored in each cart item > isn't updated. A call to item.getName() for example uses the wrong locale > afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877021#comment-14877021 ] Martin Becker commented on OFBIZ-6276: -- Thanks a lot! > Fix deprecation issues in framework/entity > -- > > Key: OFBIZ-6276 > URL: https://issues.apache.org/jira/browse/OFBIZ-6276 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Reporter: Adam Heath >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-6276-EntityStoreOptions-SVN.patch, > OFBIZ-6276-EntityStoreOptions.patch, OFBIZ-6276-variant-1.patch, > OFBIZ-6276-variant-2.patch > > > It appears that the storeAll() variants are being refactor; basically, the > useCache parameter is being removed. However, this has caused the > entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled
[ https://issues.apache.org/jira/browse/OFBIZ-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6635: - Sprint: Community Day 3 - 2015 > Old UserLogin from userLoginId-change is not correctly disabled > --- > > Key: OFBIZ-6635 > URL: https://issues.apache.org/jira/browse/OFBIZ-6635 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Martin Becker >Priority: Critical > > If a userLoginId of an existing user is updated by > LoginServices.updateUserLoginId, a new UserLogin value is created with the > data of the old one and the old one is disabled afterwards. In addition to > switch the enabled flag to "N" the disabledDateTime is set to current date. > This is wrong because this makes it possible to reenable the old UserLogin by > just do a login with the old userLoginId (standard mechanism to lock the > login for a while after subsequent failed login requests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6632) Incorrect comparison in TemporalExpressionWorker.java
[
https://issues.apache.org/jira/browse/OFBIZ-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Becker updated OFBIZ-6632:
-
Sprint: Community Day 3 - 2015
> Incorrect comparison in TemporalExpressionWorker.java
> -
>
> Key: OFBIZ-6632
> URL: https://issues.apache.org/jira/browse/OFBIZ-6632
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Vyom Jain
> Attachments: OFBIZ-6632-Fixed-exprAssocType-values.patch
>
>
> Line 128 in TemporalExpressionWorker.java does incorrect comparison
> {code}
> if ("SUBSTITUTION".equals(childExpression.get("exprAssocType"))) {
> {code} should be
> {code}
> if ("SUBSTITUTE".equals(childExpression.get("exprAssocType"))) {
> {code}
> Also documentation of field exprAssocType in entity definition of
> TemporalExpressionAssoc needs to be fixed. INCLUDED & EXCLUDED should be
> INCLUDE & EXCLUDE respectively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595084#comment-14595084 ] Martin Becker commented on OFBIZ-6276: -- I forgot to mention: The standard tests were all green... Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Jacques Le Roux Priority: Minor Attachments: OFBIZ-6276-EntityStoreOptions.patch, OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6522) Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers
[ https://issues.apache.org/jira/browse/OFBIZ-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6522: - Attachment: OFBIZ-6522.patch Added patch with fixed potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers. BTW also ensured that the EntityListIterator gets closed if an error occurs and corrected some minor code laxness. Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers --- Key: OFBIZ-6522 URL: https://issues.apache.org/jira/browse/OFBIZ-6522 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor Attachments: OFBIZ-6522.patch If view indexes as input parameters of service getProductCategoryAndLimitedMembers get manipulated (e.g. by manipulating URL params or bookmarking an URL with those params an come back later), it can lead to an IndexOutOfBoundsException because of a lowIndex greater list size. The highIndex is checked for that, the lowIndex is not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6458) Upgrade OFBiz to Java JDK 8
[ https://issues.apache.org/jira/browse/OFBIZ-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595018#comment-14595018 ] Martin Becker commented on OFBIZ-6458: -- Hi Taher, what i meant was, I provided a fix for that with title Compiler-Error with JDK 1.8 and source compatibility 1.8 already 8 weeks ago, when the Java 8 compatibility was a headline once before, but it wasn't recognized or forgotten... Upgrade OFBiz to Java JDK 8 --- Key: OFBIZ-6458 URL: https://issues.apache.org/jira/browse/OFBIZ-6458 Project: OFBiz Issue Type: Improvement Affects Versions: Upcoming Branch Reporter: Taher Alkhateeb Assignee: Jacques Le Roux Priority: Critical Labels: java, jdk, jdk8, upgrade Fix For: Upcoming Branch Attachments: OFBIZ-6458-01-fix-test-errors.patch, OFBIZ-6458-02-fix-eclipse-compiler.patch, OFBIZ-6458-03-update-to-jdk8.patch, OFBIZ-6458-04-update-README.patch The following will be tracked through this JIRA: - upgrade the framework to JDK 8 and fix any errors - make sure that ./ant clean-all load-demo run-tests will run after the upgrade - upgrade the infrastructure and demo server to accommodate the new change -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6317: - Attachment: OFBIZ-6317_14-12.patch Added patch for Branch 14.12 which fixes the current missing/obsolete .classpath entries including birt libs and framework/base/config as stated above and removes in addition the following obsolete entries: * framework/webapp/lib/json-lib-2.2.3-jdk15.jar * framework/bi/src * framework/sql/src So that a fresh checkout is runnable within eclipse without changing the classpath within the run-/debug-configuration. Missing BIRT libs in eclipse .classpath file Key: OFBIZ-6317 URL: https://issues.apache.org/jira/browse/OFBIZ-6317 Project: OFBiz Issue Type: Bug Components: framework, specialpurpose/birt Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacques Le Roux Priority: Minor Fix For: Upcoming Branch Attachments: OFBIZ-6317.patch, OFBIZ-6317_14-12.patch, OFBIZ-6317_trunk_framework-base-config.patch Because of missing JARs from the specialpurpose component birt in the eclipse .classpath file OFBiz could not be startet within eclipse without errors (NoClassDefFoundError while starting birt component). With starting within eclipse I mean the configuration with hot code replacement like this: https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses I will provide a patch for the .classpath file with 4 added libs from the specialpurpose/birt/lib folder. It would be beneficial, at least for simple contribution of jira issue fixes, if the default configuration of OFBiz from trunk is runnable as is (in a common development scenario like the above), without the need to modify config files which are under version control (.classpath for example). The alternative could be to not put files under version control, that are related to individual development environments. By the way, it would also be nice to have the framework/base/config folder as src in the .classpath file as described in the wiki article above, so that the configuration of an eclipse debug/run target for starting OFBiz in eclipse is done by only selecting the project + start-class and giving some JVM args. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker reopened OFBIZ-6317: -- Reopened to provide patch for 14.12 Missing BIRT libs in eclipse .classpath file Key: OFBIZ-6317 URL: https://issues.apache.org/jira/browse/OFBIZ-6317 Project: OFBiz Issue Type: Bug Components: framework, specialpurpose/birt Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacques Le Roux Priority: Minor Fix For: Upcoming Branch Attachments: OFBIZ-6317.patch Because of missing JARs from the specialpurpose component birt in the eclipse .classpath file OFBiz could not be startet within eclipse without errors (NoClassDefFoundError while starting birt component). With starting within eclipse I mean the configuration with hot code replacement like this: https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses I will provide a patch for the .classpath file with 4 added libs from the specialpurpose/birt/lib folder. It would be beneficial, at least for simple contribution of jira issue fixes, if the default configuration of OFBiz from trunk is runnable as is (in a common development scenario like the above), without the need to modify config files which are under version control (.classpath for example). The alternative could be to not put files under version control, that are related to individual development environments. By the way, it would also be nice to have the framework/base/config folder as src in the .classpath file as described in the wiki article above, so that the configuration of an eclipse debug/run target for starting OFBiz in eclipse is done by only selecting the project + start-class and giving some JVM args. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6458) Upgrade OFBiz to Java JDK 8
[ https://issues.apache.org/jira/browse/OFBIZ-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14594519#comment-14594519 ] Martin Becker commented on OFBIZ-6458: -- The second patch (OFBIZ-6458-02-fix-eclipse-compiler.patch related to EntityFieldMap) compromises type security. I provided a patch for that within OFBIZ-6300 already in April. Upgrade OFBiz to Java JDK 8 --- Key: OFBIZ-6458 URL: https://issues.apache.org/jira/browse/OFBIZ-6458 Project: OFBiz Issue Type: Improvement Affects Versions: Upcoming Branch Reporter: Taher Alkhateeb Assignee: Jacques Le Roux Priority: Critical Labels: java, jdk, jdk8, upgrade Fix For: Upcoming Branch Attachments: OFBIZ-6458-01-fix-test-errors.patch, OFBIZ-6458-02-fix-eclipse-compiler.patch, OFBIZ-6458-03-update-to-jdk8.patch, OFBIZ-6458-04-update-README.patch The following will be tracked through this JIRA: - upgrade the framework to JDK 8 and fix any errors - make sure that ./ant clean-all load-demo run-tests will run after the upgrade - upgrade the infrastructure and demo server to accommodate the new change -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6317: - Attachment: OFBIZ-6317_trunk_framework-base-config.patch Added patch for adding framework/base/config dir as described above to the .classpath file in trunk Missing BIRT libs in eclipse .classpath file Key: OFBIZ-6317 URL: https://issues.apache.org/jira/browse/OFBIZ-6317 Project: OFBiz Issue Type: Bug Components: framework, specialpurpose/birt Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacques Le Roux Priority: Minor Fix For: Upcoming Branch Attachments: OFBIZ-6317.patch, OFBIZ-6317_trunk_framework-base-config.patch Because of missing JARs from the specialpurpose component birt in the eclipse .classpath file OFBiz could not be startet within eclipse without errors (NoClassDefFoundError while starting birt component). With starting within eclipse I mean the configuration with hot code replacement like this: https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses I will provide a patch for the .classpath file with 4 added libs from the specialpurpose/birt/lib folder. It would be beneficial, at least for simple contribution of jira issue fixes, if the default configuration of OFBiz from trunk is runnable as is (in a common development scenario like the above), without the need to modify config files which are under version control (.classpath for example). The alternative could be to not put files under version control, that are related to individual development environments. By the way, it would also be nice to have the framework/base/config folder as src in the .classpath file as described in the wiki article above, so that the configuration of an eclipse debug/run target for starting OFBiz in eclipse is done by only selecting the project + start-class and giving some JVM args. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6317: - Affects Version/s: Release Branch 14.12 Missing BIRT libs in eclipse .classpath file Key: OFBIZ-6317 URL: https://issues.apache.org/jira/browse/OFBIZ-6317 Project: OFBiz Issue Type: Bug Components: framework, specialpurpose/birt Affects Versions: Release Branch 14.12, Trunk Reporter: Martin Becker Assignee: Jacques Le Roux Priority: Minor Fix For: Upcoming Branch Attachments: OFBIZ-6317.patch, OFBIZ-6317_14-12.patch, OFBIZ-6317_trunk_framework-base-config.patch Because of missing JARs from the specialpurpose component birt in the eclipse .classpath file OFBiz could not be startet within eclipse without errors (NoClassDefFoundError while starting birt component). With starting within eclipse I mean the configuration with hot code replacement like this: https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses I will provide a patch for the .classpath file with 4 added libs from the specialpurpose/birt/lib folder. It would be beneficial, at least for simple contribution of jira issue fixes, if the default configuration of OFBiz from trunk is runnable as is (in a common development scenario like the above), without the need to modify config files which are under version control (.classpath for example). The alternative could be to not put files under version control, that are related to individual development environments. By the way, it would also be nice to have the framework/base/config folder as src in the .classpath file as described in the wiki article above, so that the configuration of an eclipse debug/run target for starting OFBiz in eclipse is done by only selecting the project + start-class and giving some JVM args. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6276: - Attachment: OFBIZ-6276-EntityStoreOptions.patch Added new patch which removes the use of deprecated API and the deprecated API itself from Delegator and GenericDelegator. Introduced the EntityStoreOptions class as mentioned in a comment before to substitute the createDummyFks parameter of storeAll method to avoid ambiguous API after removing the deprecated doCacheClear parameter. The decryptFieldValue method, just defined deprecated by Jacopo is left there as deprecated. Only the old deprecated methods where removed. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Jacques Le Roux Priority: Minor Attachments: OFBIZ-6276-EntityStoreOptions.patch, OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6522) Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers
Martin Becker created OFBIZ-6522: Summary: Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers Key: OFBIZ-6522 URL: https://issues.apache.org/jira/browse/OFBIZ-6522 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Upcoming Branch Reporter: Martin Becker Priority: Minor If view indexes as input parameters of service getProductCategoryAndLimitedMembers get manipulated (e.g. by manipulating URL params or bookmarking an URL with those params an come back later), it can lead to an IndexOutOfBoundsException because of a lowIndex greater list size. The highIndex is checked for that, the lowIndex is not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-PartyComponent.patch Sorry, I selected the wrong file for upload, now a correct patch for PartyComponent is availiable German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-PartyComponent.patch, OFBIZ-6305-PartyComponent.patch.html, OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: (was: OFBIZ-6305-PartyComponent.patch.html) German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-PartyComponent.patch, OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14552078#comment-14552078 ] Martin Becker commented on OFBIZ-6276: -- Good point, I would call it EntityStoreOptions according to the existing EntityFindOptions. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Jacques Le Roux Priority: Minor Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550171#comment-14550171 ] Martin Becker commented on OFBIZ-6276: -- Hi Jacques, what do you mean with we already used the same? This issue is open and unassigned and I wanted to take a step forward to be able to work on OFBIZ-6273. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550445#comment-14550445 ] Martin Becker commented on OFBIZ-6276: -- Mmmh, 1st way was my 1st idea, but I was not happy with introducing a new method name like storeAllWithDummyFks while the strategy is more like adding boolean parameters for such features (e.g. useCache parameter instead of methods like findByAnd and findByAndCache). This combined with the small relevance of the createDummyFks Feature (my opinion) led me to the simpler API without a different method name but switched parameter order for a method that may not be used very often. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Jacques Le Roux Priority: Minor Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550341#comment-14550341 ] Martin Becker commented on OFBIZ-6276: -- Aaah, check! Not really nice but effective ;-) Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Jacques Le Roux Priority: Minor Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-PartyComponent.patch.html Next translations, now for Party component... German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-PartyComponent.patch.html, OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6276) Fix deprecation issues in framework/entity
[
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Becker updated OFBIZ-6276:
-
Attachment: OFBIZ-6276-variant-2.patch
OFBIZ-6276-variant-1.patch
It has to be ensured, that with the future removal of the doCacheClear
parameter from the method signature:
from
{{storeAll(ListGenericValue values, boolean doCacheClear, boolean
createDummyFks)}}
to
{{storeAll(ListGenericValue values, boolean createDummyFks)}}
the signature afterwards does not match the old signature with different
meaning:
{{storeAll(ListGenericValue values, boolean doCacheClear)}}
where legacy code would get no compiler error and may miss the changed meaning.
I implemented two variants of a solution for this:
With the first I renamed the method with the concrete implementation from
storeAll to storeAllInternal and changed the visibility to private, so there is
no collision with the other signature with {{ListGenericValue, boolean}}
params. The createDummyFks function is made public available with a new method
{{storeAllWithDummyFks}}.
The second variant is simpler and without the need of changed method names, it
just switches the order of the parameters in the signature, which is not so
nice in reading the signature but avoids special method name for the
createDummyFks feature.
The next step for me would be to remove the deprecated code from the Delegator
implementation in the context of OFBIZ-6273.
Fix deprecation issues in framework/entity
--
Key: OFBIZ-6276
URL: https://issues.apache.org/jira/browse/OFBIZ-6276
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch
It appears that the storeAll() variants are being refactor; basically, the
useCache parameter is being removed. However, this has caused the
entity engine to have deprecation with itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6329: - Attachment: OFBIZ-6329_Non-Template-Caching-DiffOnly.patch OFBIZ-6329_FTL-Caching-DiffOnly.patch Patches *-DiffOnly.patch with simple diff format attached Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching-DiffOnly.patch, OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching-DiffOnly.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-ProductEntityLabels.patch Patch for ProductEntityLabels... German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528284#comment-14528284 ] Martin Becker commented on OFBIZ-6329: -- Sorry for that, Adrian. I'm using git locally and created the patch files with git format-patch as Michael stated. Therefore there are some header informations additional to the standard diff in the patch file. There should be no need for a committer to modify a patch file to get it working, so we will create the patch files with git diff, that should be fine. I will provide corrected patch files here soon and Adrian may check if they are usable for him (and thus for all others). Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-ProductErrorUiLabels.patch Next patch for the ProductErrorUiLabels... German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
Martin Becker created OFBIZ-6329: Summary: Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6329: - Attachment: OFBIZ-6329_Non-Template-Caching.patch OFBIZ-6329_FTL-Caching.patch Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6317: - Attachment: OFBIZ-6317.patch Missing BIRT libs in eclipse .classpath file Key: OFBIZ-6317 URL: https://issues.apache.org/jira/browse/OFBIZ-6317 Project: OFBiz Issue Type: Bug Components: framework, specialpurpose/birt Affects Versions: Trunk Reporter: Martin Becker Priority: Minor Attachments: OFBIZ-6317.patch Because of missing JARs from the specialpurpose component birt in the eclipse .classpath file OFBiz could not be startet within eclipse without errors (NoClassDefFoundError while starting birt component). With starting within eclipse I mean the configuration with hot code replacement like this: https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses I will provide a patch for the .classpath file with 4 added libs from the specialpurpose/birt/lib folder. It would be beneficial, at least for simple contribution of jira issue fixes, if the default configuration of OFBiz from trunk is runnable as is (in a common development scenario like the above), without the need to modify config files which are under version control (.classpath for example). The alternative could be to not put files under version control, that are related to individual development environments. By the way, it would also be nice to have the framework/base/config folder as src in the .classpath file as described in the wiki article above, so that the configuration of an eclipse debug/run target for starting OFBiz in eclipse is done by only selecting the project + start-class and giving some JVM args. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-ProductUiLabels.patch German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Attachments: OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521698#comment-14521698 ] Martin Becker commented on OFBIZ-6305: -- OFBIZ-6305-ProductUiLabels.patch is the first patch for this issue, it contains about 900 changes in ProductUILabels.xml. Mainly missing german translations added but also some corrections in other entries. German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Attachments: OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6319) Add missing entries to .gitignore to ignore typical Idea/eclipse folders/files
Martin Becker created OFBIZ-6319: Summary: Add missing entries to .gitignore to ignore typical Idea/eclipse folders/files Key: OFBIZ-6319 URL: https://issues.apache.org/jira/browse/OFBIZ-6319 Project: OFBiz Issue Type: Improvement Affects Versions: Trunk Reporter: Martin Becker Priority: Trivial Some folder/filenames that are configured for SVN to be ignored are missing in the current .gitignore file. Especially the internal config folders created by eclipse in the project root (.settings and .groovy) are missing for me, so that they get displayed as modification while using git. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6305) German translations for various applications
Martin Becker created OFBIZ-6305: Summary: German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5169) Removing Javolution from framework components
[ https://issues.apache.org/jira/browse/OFBIZ-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511170#comment-14511170 ] Martin Becker commented on OFBIZ-5169: -- Well, my intention is to overall switch the now used LinkedList to ArrayList, as it is the more proper default with a light performance drawback in rare cases, if at all, and to be in line with the types used in groovy scripts. No functional drawback compared to FastList is to be expected (in contrast to HashMap/HashSet, if preserving the insert-order for iteration is a requirement). That would be a good starting point for detailed analysis and changes in the scope of [OFBIZ-6298], to optimize the use of collection types, also this will be a very exhausting activity over thousands of code places with very small expectable benefits in real world performance. Removing Javolution from framework components - Key: OFBIZ-5169 URL: https://issues.apache.org/jira/browse/OFBIZ-5169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Varun Bhansaly Priority: Minor Attachments: framework-FastList-removed.patch a. Remove static instances of Javolution objects. b. Remove other uses of Javolution objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8
[ https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511232#comment-14511232 ] Martin Becker commented on OFBIZ-6300: -- 1.8 compile target top-level issue sounds good, currently (after applying my patch) there should only be warnings. The patched issue in EntityFieldMap was the only error I got. Compiler-Error with JDK 1.8 and source compatibility 1.8 Key: OFBIZ-6300 URL: https://issues.apache.org/jira/browse/OFBIZ-6300 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Martin Becker Assignee: Adam Heath Attachments: OFBIZ-6300-EntityFieldMap.patch I just found another error compiling the code with JDK 1.8 with source code compatibility switched to 1.8 in my eclipse workspace. The external ant build is working because there is java version 1.7 defined as target in the macros.xml. The error is an issue regarding generics in EntityFieldMap.java. I will provide a patch her soon. The code is the same in the release branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8
[ https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6300: - Attachment: OFBIZ-6300-EntityFieldMap.patch Compiler-Error with JDK 1.8 and source compatibility 1.8 Key: OFBIZ-6300 URL: https://issues.apache.org/jira/browse/OFBIZ-6300 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Martin Becker Assignee: Adam Heath Attachments: OFBIZ-6300-EntityFieldMap.patch I just found another error compiling the code with JDK 1.8 with source code compatibility switched to 1.8 in my eclipse workspace. The external ant build is working because there is java version 1.7 defined as target in the macros.xml. The error is an issue regarding generics in EntityFieldMap.java. I will provide a patch her soon. The code is the same in the release branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8
Martin Becker created OFBIZ-6300: Summary: Compiler-Error with JDK 1.8 and source compatibility 1.8 Key: OFBIZ-6300 URL: https://issues.apache.org/jira/browse/OFBIZ-6300 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Martin Becker I just found another error compiling the code with JDK 1.8 with source code compatibility switched to 1.8 in my eclipse workspace. The external ant build is working because there is java version 1.7 defined as target in the macros.xml. The error is an issue regarding generics in EntityFieldMap.java. I will provide a patch her soon. The code is the same in the release branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507275#comment-14507275 ] Martin Becker commented on OFBIZ-6238: -- What (F)partyId do you mean for your setting, from the order point of view, respectively which orderRole to get a party from the current oder? As there a different roles for sales and purchase orders, this has to be differentiated at least. My thought was a simple and robust way to give the attachment a unique name, which the orderId itself does, or isn't it? Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacopo Cappellato Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507425#comment-14507425 ] Martin Becker commented on OFBIZ-6273: -- There are about 375 findings of Deprecated keyword in java code in the trunk, some are duplicated, because of the deprecated keyword in javaDoc and as annotation for the same method. What about to link this issue with [OFBIZ-6275] OFBiz code seems make use of other deprecated OFBiz features from Adam for which a branch already exists, since the use of some deprecated API by OFBiz has to be changed first before we can get rid of the deprecated API itself? I would vote for first fixing the findings from Adam and then removing the deprecated API, either in the branch Adam just created or in another branch in sequence. Another question is: What about deprecated fields/entities and corresponding upgrade services? Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507496#comment-14507496 ] Martin Becker commented on OFBIZ-6273: -- Thats my opinion, too (entities/fields). I will monitor [OFBIZ-6275] and perhaps deliver some patches for the issues there and come back to this task if afterwards. Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506749#comment-14506749 ] Martin Becker commented on OFBIZ-6273: -- I would like to do this for the community. Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506749#comment-14506749 ] Martin Becker edited comment on OFBIZ-6273 at 4/22/15 10:04 AM: I would like to do this for the community. First I would have a look at the quantity of deprecated code to then discuss the reasonable way to spit it in patches, or should it be done in a separate branch? was (Author: mbecker): I would like to do this for the community. Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6258) Trivial perfomance improvement for creating OrderItemAttributes during store/update Order
Martin Becker created OFBIZ-6258:
Summary: Trivial perfomance improvement for creating
OrderItemAttributes during store/update Order
Key: OFBIZ-6258
URL: https://issues.apache.org/jira/browse/OFBIZ-6258
Project: OFBiz
Issue Type: Improvement
Components: order
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Trivial
Attachments: ShoppingCart-makeAllOrderItemAttributes.patch
Improved use of given mode parameter in {{makeAllOrderItemAttributes(String
orderId, int mode)}} to avoid creating new OrderItemAttribute GenericValues
that have not to be created according to the value for mode (FILLED_ONLY,
EMPTY_ONLY).
Change was made for a project with massive use of OrderItemAttributes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-6258) Trivial perfomance improvement for creating OrderItemAttributes during store/update Order
[
https://issues.apache.org/jira/browse/OFBIZ-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Becker updated OFBIZ-6258:
-
Attachment: ShoppingCart-makeAllOrderItemAttributes.patch
Trivial perfomance improvement for creating OrderItemAttributes during
store/update Order
-
Key: OFBIZ-6258
URL: https://issues.apache.org/jira/browse/OFBIZ-6258
Project: OFBiz
Issue Type: Improvement
Components: order
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Trivial
Attachments: ShoppingCart-makeAllOrderItemAttributes.patch
Improved use of given mode parameter in {{makeAllOrderItemAttributes(String
orderId, int mode)}} to avoid creating new OrderItemAttribute GenericValues
that have not to be created according to the value for mode (FILLED_ONLY,
EMPTY_ONLY).
Change was made for a project with massive use of OrderItemAttributes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6252) Release branches fail to compile with JDK 1.8
Martin Becker created OFBIZ-6252: Summary: Release branches fail to compile with JDK 1.8 Key: OFBIZ-6252 URL: https://issues.apache.org/jira/browse/OFBIZ-6252 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 14.12, Release Branch 13.07, Release Branch 12.04 Reporter: Martin Becker Due to a bug that was already fixed in trunk by Adrian C. (Jan 2015) but not in the current release branches (I checked 12.04, 13.07 and 14.12), the branches could not be compiled using JDK 1.8 because it discovers an variable operator might not have been initialized error in ModelViewController.java. Furthermore this is also a logical bug that leads to an incomplete error message. So the trivial fix should be applied to the release branches, I will attach one for 14.12. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6252) Release branches fail to compile with JDK 1.8
[ https://issues.apache.org/jira/browse/OFBIZ-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6252: - Attachment: ModelViewController_14-12.patch Release branches fail to compile with JDK 1.8 - Key: OFBIZ-6252 URL: https://issues.apache.org/jira/browse/OFBIZ-6252 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04, Release Branch 13.07, Release Branch 14.12 Reporter: Martin Becker Attachments: ModelViewController_14-12.patch Due to a bug that was already fixed in trunk by Adrian C. (Jan 2015) but not in the current release branches (I checked 12.04, 13.07 and 14.12), the branches could not be compiled using JDK 1.8 because it discovers an variable operator might not have been initialized error in ModelViewController.java. Furthermore this is also a logical bug that leads to an incomplete error message. So the trivial fix should be applied to the release branches, I will attach one for 14.12. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5169) Removing Javolution from framework components
[ https://issues.apache.org/jira/browse/OFBIZ-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494135#comment-14494135 ] Martin Becker commented on OFBIZ-5169: -- I wonder why the LinkedList was chosen as the default replacement of FastList in Java code instead if an ArrayList (see comment from Jacopo Cappellato above). Although it could be a very complex question which implementation to choose respecting the concrete logic and the underlying environment, I would prefer to use ArrayList as default on the basis of the memory consumption and general performance impacts of LinkedList alone. The cases at OFBiz where the main benefit of faster insert/remove in the middle/beginning of a large LinkedList is relevant should be very rare, especially with moderate list sizes. The disadvantage of ArrayList in growing over the initial capacity should always be encountered by specifying an appropriate initial capacity where possible. See short description from oracle: https://docs.oracle.com/javase/tutorial/collections/implementations/list.html Another conspicuity: The migrated groovy scripts instead often using the default list implementation which is ArrayList by only using „[]“ without specifying LinkedList as concrete type. Removing Javolution from framework components - Key: OFBIZ-5169 URL: https://issues.apache.org/jira/browse/OFBIZ-5169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Varun Bhansaly Priority: Minor Attachments: framework-FastList-removed.patch a. Remove static instances of Javolution objects. b. Remove other uses of Javolution objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
Martin Becker created OFBIZ-6238: Summary: Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Priority: Trivial According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6238: - Attachment: OrderServices.patch Patch for OrderServices.java Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
