[jira] [Comment Edited] (OFBIZ-6218) Unit tests throw exception in DBCP
[
https://issues.apache.org/jira/browse/OFBIZ-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385518#comment-14385518
]
Pierre Smits edited comment on OFBIZ-6218 at 3/28/15 8:49 PM:
--
This might be related to something I am experiencing with a piece of groovy
code:
{code}
rolesIter = partyRelationRoles.iterator()
while (rolesIter){
thisItem = rolesIter.next()
partyNameView = delegator.findOne(PartyNameView,[partyId :
thisItem.partyIdFrom], false)
}
{code}
Which results in following log messages:
{code}
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |
|I| in community,
getRoles:org.ofbiz.entity.util.EntityListIterator@12f4bdac
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |EntityListIterator
|W| For performance reasons do not use the
EntityListIterator.hasNext() method, just call next() until it returns null;
see JavaDoc comments in the EntityListIterator class for details and an example
[java] java.lang.Exception
[java] at
org.ofbiz.entity.util.EntityListIterator.hasNext(EntityListIterator.java:254)
[ofbiz-entity.jar:?]
[java] at
org.codehaus.groovy.runtime.DefaultGroovyMethods.asBoolean(DefaultGroovyMethods.java:7781)
[groovy-all-2.2.1.jar:2.2.1]
[java] at org.codehaus.groovy.runtime.dgm$28.doMethodInvoke(Unknown
Source) [groovy-all-2.2.1.jar:2.2.1]
[java] at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085)
[groovy-all-2.2.1.jar:2.2.1]
{code}
followed by:
{code}
[java] 2015-03-28 21:36:39,424 |Finalizer|EntityListIterator
|E|
[java]
[java] EntityListIterator Not Closed for Entity [PartyRelationship],
caught in Finalize
[java]
[java]
[java] 2015-03-28 21:36:39,425 |Finalizer|SQLProcessor
|E| Error closing the result, connection, etc in finalize SQLProcessor
[java] java.lang.NullPointerException
[java] at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
~[commons-dbcp2-2.1.jar:2.1]
[java] at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
~[commons-dbcp2-2.1.jar:2.1]
[java] at
org.apache.commons.dbcp2.managed.ManagedConnection.close(ManagedConnection.java:166)
~[commons-dbcp2-2.1.jar:2.1]
[java] at
org.ofbiz.entity.jdbc.SQLProcessor.close(SQLProcessor.java:235)
~[ofbiz-entity.jar:?]
[java] at
org.ofbiz.entity.jdbc.SQLProcessor.finalize(SQLProcessor.java:844)
[ofbiz-entity.jar:?]
[java] at java.lang.System$2.invokeFinalize(System.java:1213)
[?:1.7.0_71]
[java] at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:98)
[?:1.7.0_71]
[java] at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
[?:1.7.0_71]
[java] at
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:210) [?:1.7.0_71]
{code}
was (Author: pfm.smits):
This might be related to something I am experiencing with a piece of groovy
code:
{code}
rolesIter = partyRelationRoles.iterator()
while (rolesIter){
thisItem = rolesIter.next()
partyNameView = delegator.findOne(PartyNameView,[partyId :
thisItem.partyIdFrom], false)
}
{code}
Which results in following log messages:
{code}
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |
|I| in community,
getRoles:org.ofbiz.entity.util.EntityListIterator@12f4bdac
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |EntityListIterator
|W| For performance reasons do not use the
EntityListIterator.hasNext() method, just call next() until it returns null;
see JavaDoc comments in the EntityListIterator class for details and an example
[java] java.lang.Exception
[java] at
org.ofbiz.entity.util.EntityListIterator.hasNext(EntityListIterator.java:254)
[ofbiz-entity.jar:?]
[java] at
org.codehaus.groovy.runtime.DefaultGroovyMethods.asBoolean(DefaultGroovyMethods.java:7781)
[groovy-all-2.2.1.jar:2.2.1]
[java] at org.codehaus.groovy.runtime.dgm$28.doMethodInvoke(Unknown
Source) [groovy-all-2.2.1.jar:2.2.1]
[java] at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085)
[groovy-all-2.2.1.jar:2.2.1]
{code}
Unit tests throw exception in DBCP
--
Key: OFBIZ-6218
URL: https://issues.apache.org/jira/browse/OFBIZ-6218
Project: OFBiz
Issue Type: Bug
Reporter: Adrian Crum
Details in comments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385489#comment-14385489 ] Taher Alkhateeb commented on OFBIZ-6217: bump. Please apply the corrected patch fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6218) Unit tests throw exception in DBCP
[
https://issues.apache.org/jira/browse/OFBIZ-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385518#comment-14385518
]
Pierre Smits commented on OFBIZ-6218:
-
This might be related to something I am experiencing with a piece of groovy
code:
{code}
rolesIter = partyRelationRoles.iterator()
while (rolesIter){
thisItem = rolesIter.next()
partyNameView = delegator.findOne(PartyNameView,[partyId :
thisItem.partyIdFrom], false)
}
{code}
Which results in following log messages:
{code}
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |
|I| in community,
getRoles:org.ofbiz.entity.util.EntityListIterator@12f4bdac
[java] 2015-03-28 21:33:36,303 |http-bio-8443-exec-7 |EntityListIterator
|W| For performance reasons do not use the
EntityListIterator.hasNext() method, just call next() until it returns null;
see JavaDoc comments in the EntityListIterator class for details and an example
[java] java.lang.Exception
[java] at
org.ofbiz.entity.util.EntityListIterator.hasNext(EntityListIterator.java:254)
[ofbiz-entity.jar:?]
[java] at
org.codehaus.groovy.runtime.DefaultGroovyMethods.asBoolean(DefaultGroovyMethods.java:7781)
[groovy-all-2.2.1.jar:2.2.1]
[java] at org.codehaus.groovy.runtime.dgm$28.doMethodInvoke(Unknown
Source) [groovy-all-2.2.1.jar:2.2.1]
[java] at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085)
[groovy-all-2.2.1.jar:2.2.1]
{code}
Unit tests throw exception in DBCP
--
Key: OFBIZ-6218
URL: https://issues.apache.org/jira/browse/OFBIZ-6218
Project: OFBiz
Issue Type: Bug
Reporter: Adrian Crum
Details in comments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Proposal to introduce factory pattern to java collections
Hi Adrian, Would you not find it useful especially for those not experienced in data structures and algorithms not to worry about picking the right implementation for a list, map, set, tree or any other data structure by defaulting to what the factory would yield? Furthermore, let's say you dislike the HashMap that everyone is using and would prefer a different implementation. Would it not be a lot faster to change that in one place instead of the thousands upon thousands of sprinkled new instantiations? I am suggesting a factory just to have sanity and consistency. In fact, when looking at the source code I see people using different implementations of the interfaces in different places! Taher Alkhateeb - Original Message - From: Adrian Crum adrian.c...@sandglass-software.com To: dev@ofbiz.apache.org Sent: Saturday, 28 March, 2015 1:40:31 PM Subject: Re: Proposal to introduce factory pattern to java collections Personally, I am opposed to making simple things like this overly complicated. It is unlikely the Java collections API will change enough to warrant a factory for every collection type. Javolution was used in Java 1.4 to reduce the latency caused by garbage collection. That is not a problem with JREs = 1.5, so we don't need the library any more. Adrian Crum Sandglass Software www.sandglass-software.com On 3/28/2015 10:01 AM, Taher Alkhateeb wrote: Hi All, The move from javolution to the collections API built in to java proves to be painful. To avoid such things in the future and to reduce the new keyword clutter in the code I suggest we create factories for all collections. This way we we can also enhance the collections in the future with any ofbiz specific code. This is also a best practice in terms of design patterns. I would like to have opinions on whether this is a wanted / acceptable feature so I can create a JIRA accordingly. Your opinions are appreciated. Taher Alkhateeb.
Re: Are git patches acceptable?
Bump. Committers? On Fri, 2015-03-27 at 19:33 -0500, Christian Carlow wrote: Are git patches acceptable?
Re: Are git patches acceptable?
Hi Christian, If this kind of patch is easily applyable, it will be accepted. No problem if the patch is generated from git, svn or other system (addonmanager for example). Best Regards Gil On 28/03/2015 14:47, Deepak Dixit wrote: Hi Christian, You can create git patch using git diff —no-prefix, It will create patch similar to svn diff. I think it should be accepted. We can apply patch using patch -p0 file path Others opinion ? Thanks Regards — Deepak Dixit On Mar 28, 2015, at 7:07 PM, Christian Carlow christian.car...@gmail.com wrote: Bump. Committers? On Fri, 2015-03-27 at 19:33 -0500, Christian Carlow wrote: Are git patches acceptable?
Re: Are git patches acceptable?
The git patches are just as easily applied as svn and created similarly in eclipse. Git allows anyone to create local branches without needing committer privilege. I just wanted to make sure that the switch wouldn't prevent patches from being rejected. On Sat, 2015-03-28 at 15:03 +0100, gil portenseigne wrote: Hi Christian, If this kind of patch is easily applyable, it will be accepted. No problem if the patch is generated from git, svn or other system (addonmanager for example). Best Regards Gil On 28/03/2015 14:47, Deepak Dixit wrote: Hi Christian, You can create git patch using git diff —no-prefix, It will create patch similar to svn diff. I think it should be accepted. We can apply patch using patch -p0 file path Others opinion ? Thanks Regards — Deepak Dixit On Mar 28, 2015, at 7:07 PM, Christian Carlow christian.car...@gmail.com wrote: Bump. Committers? On Fri, 2015-03-27 at 19:33 -0500, Christian Carlow wrote: Are git patches acceptable?
[jira] [Updated] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb updated OFBIZ-6217: --- Attachment: warnings_patch_2.patch fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385241#comment-14385241 ] Taher Alkhateeb commented on OFBIZ-6217: Hi Adrian, Updated patch is available fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6175) Replace findInventoryEventPlan.ftl with form widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385305#comment-14385305 ] Christian Carlow commented on OFBIZ-6175: - All events are deleted once the MRP is run and recreated if identified as still not fulfilled. This patch only involves changes to the presentation layer. All business logic was left unchanged. I'm not aware of the Job Id relating to the event type in any way. Replace findInventoryEventPlan.ftl with form widgets Key: OFBIZ-6175 URL: https://issues.apache.org/jira/browse/OFBIZ-6175 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Priority: Trivial Labels: inventory, mrp, plan Attachments: OFBIZ-6175.patch While troubleshooting production run requirements created from the Mrp I evaluated findInventoryEventPlan.ftl for conversion to a form widget which I generally do for any FTL file I encounter since I find the widgets much easier to interpret. Other than the the ERROR mrpEventType record not being combined with the INITIAL_QOH line, I was able to reproduce the FTL with a form widget. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal to introduce factory pattern to java collections
The reason different implementations are used is because the requirements are different. A HashMap is not always the correct Map implementation to use. Adrian Crum Sandglass Software www.sandglass-software.com On 3/28/2015 11:28 AM, Taher Alkhateeb wrote: Hi Adrian, Would you not find it useful especially for those not experienced in data structures and algorithms not to worry about picking the right implementation for a list, map, set, tree or any other data structure by defaulting to what the factory would yield? Furthermore, let's say you dislike the HashMap that everyone is using and would prefer a different implementation. Would it not be a lot faster to change that in one place instead of the thousands upon thousands of sprinkled new instantiations? I am suggesting a factory just to have sanity and consistency. In fact, when looking at the source code I see people using different implementations of the interfaces in different places! Taher Alkhateeb - Original Message - From: Adrian Crum adrian.c...@sandglass-software.com To: dev@ofbiz.apache.org Sent: Saturday, 28 March, 2015 1:40:31 PM Subject: Re: Proposal to introduce factory pattern to java collections Personally, I am opposed to making simple things like this overly complicated. It is unlikely the Java collections API will change enough to warrant a factory for every collection type. Javolution was used in Java 1.4 to reduce the latency caused by garbage collection. That is not a problem with JREs = 1.5, so we don't need the library any more. Adrian Crum Sandglass Software www.sandglass-software.com On 3/28/2015 10:01 AM, Taher Alkhateeb wrote: Hi All, The move from javolution to the collections API built in to java proves to be painful. To avoid such things in the future and to reduce the new keyword clutter in the code I suggest we create factories for all collections. This way we we can also enhance the collections in the future with any ofbiz specific code. This is also a best practice in terms of design patterns. I would like to have opinions on whether this is a wanted / acceptable feature so I can create a JIRA accordingly. Your opinions are appreciated. Taher Alkhateeb.
Re: Are git patches acceptable?
Hi Christian, You can create git patch using git diff —no-prefix, It will create patch similar to svn diff. I think it should be accepted. We can apply patch using patch -p0 file path Others opinion ? Thanks Regards — Deepak Dixit On Mar 28, 2015, at 7:07 PM, Christian Carlow christian.car...@gmail.com wrote: Bump. Committers? On Fri, 2015-03-27 at 19:33 -0500, Christian Carlow wrote: Are git patches acceptable?
Re: Proposal to introduce factory pattern to java collections
On 28/03/2015 7:28 AM, Taher Alkhateeb wrote: Hi Adrian, Would you not find it useful especially for those not experienced in data structures and algorithms not to worry about picking the right implementation for a list, map, set, tree or any other data structure by defaulting to what the factory would yield? Furthermore, let's say you dislike the HashMap that everyone is using and would prefer a different implementation. Would it not be a lot faster to change that in one place instead of the thousands upon thousands of sprinkled new instantiations? This seems like a modern way to do things. I am suggesting a factory just to have sanity and consistency. In fact, when looking at the source code I see people using different implementations of the interfaces in different places! A factory will still allow different implementation (as Adrian feels is required) but at least the best practices will be documented and encapsulated in the factory. Ron Taher Alkhateeb - Original Message - From: Adrian Crum adrian.c...@sandglass-software.com To: dev@ofbiz.apache.org Sent: Saturday, 28 March, 2015 1:40:31 PM Subject: Re: Proposal to introduce factory pattern to java collections Personally, I am opposed to making simple things like this overly complicated. It is unlikely the Java collections API will change enough to warrant a factory for every collection type. Javolution was used in Java 1.4 to reduce the latency caused by garbage collection. That is not a problem with JREs = 1.5, so we don't need the library any more. Adrian Crum Sandglass Software www.sandglass-software.com On 3/28/2015 10:01 AM, Taher Alkhateeb wrote: Hi All, The move from javolution to the collections API built in to java proves to be painful. To avoid such things in the future and to reduce the new keyword clutter in the code I suggest we create factories for all collections. This way we we can also enhance the collections in the future with any ofbiz specific code. This is also a best practice in terms of design patterns. I would like to have opinions on whether this is a wanted / acceptable feature so I can create a JIRA accordingly. Your opinions are appreciated. Taher Alkhateeb. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Created] (OFBIZ-6222) Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter
Arun Patidar created OFBIZ-6222: --- Summary: Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter Key: OFBIZ-6222 URL: https://issues.apache.org/jira/browse/OFBIZ-6222 Project: OFBiz Issue Type: Bug Components: framework Reporter: Arun Patidar Priority: Critical Fix For: Trunk, Release Branch 14.12 Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter While using webtools for tenantGroup and searching with a tenantId then its interpreting it as tenantId in request and switching delegator for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6222) Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter
[ https://issues.apache.org/jira/browse/OFBIZ-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385174#comment-14385174 ] Adrian Crum commented on OFBIZ-6222: That is a good idea! We had a similar problem with the screens that set the user's locale and time zone. Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter Key: OFBIZ-6222 URL: https://issues.apache.org/jira/browse/OFBIZ-6222 Project: OFBiz Issue Type: Bug Components: framework Reporter: Arun Patidar Priority: Critical Fix For: Release Branch 14.12, Trunk Change the field name 'tenantId' to 'userTenantId' from login page and ContextFilter While using webtools for tenantGroup and searching with a tenantId then its interpreting it as tenantId in request and switching delegator for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb updated OFBIZ-6217: --- Attachment: (was: wrong_suppress_and_voids.patch) fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb updated OFBIZ-6217: --- Attachment: warnings_patch_2.patch fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6175) Replace findInventoryEventPlan.ftl with form widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385209#comment-14385209 ] Pierre Smits commented on OFBIZ-6175: - If the ftl can be replaced with a screen/form combo, then go for it. Replace findInventoryEventPlan.ftl with form widgets Key: OFBIZ-6175 URL: https://issues.apache.org/jira/browse/OFBIZ-6175 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Priority: Trivial Labels: inventory, mrp, plan Attachments: OFBIZ-6175.patch While troubleshooting production run requirements created from the Mrp I evaluated findInventoryEventPlan.ftl for conversion to a form widget which I generally do for any FTL file I encounter since I find the widgets much easier to interpret. Other than the the ERROR mrpEventType record not being combined with the INITIAL_QOH line, I was able to reproduce the FTL with a form widget. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal to introduce factory pattern to java collections
Personally, I am opposed to making simple things like this overly complicated. It is unlikely the Java collections API will change enough to warrant a factory for every collection type. Javolution was used in Java 1.4 to reduce the latency caused by garbage collection. That is not a problem with JREs = 1.5, so we don't need the library any more. Adrian Crum Sandglass Software www.sandglass-software.com On 3/28/2015 10:01 AM, Taher Alkhateeb wrote: Hi All, The move from javolution to the collections API built in to java proves to be painful. To avoid such things in the future and to reduce the new keyword clutter in the code I suggest we create factories for all collections. This way we we can also enhance the collections in the future with any ofbiz specific code. This is also a best practice in terms of design patterns. I would like to have opinions on whether this is a wanted / acceptable feature so I can create a JIRA accordingly. Your opinions are appreciated. Taher Alkhateeb.
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385231#comment-14385231 ] Taher Alkhateeb commented on OFBIZ-6217: Hi Adrian, Good catch. The reason I did not apply the generics is because I thought I would break the function signature of the callee object. Your solution looks good. However, if you look at OfbizBshBsfEngine.java for example, you will see that I will actually break the signature so I cannot do anything about it. Do you want me to repatch or can you correct it from your side? fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6217) fix warnings in trunk on java source code
[
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385222#comment-14385222
]
Adrian Crum edited comment on OFBIZ-6217 at 3/28/15 10:34 AM:
--
Taher,
Thank you for working on this! One thing has me confused: You make use of the
UtilGenerics methods in some places, but not in others - where you add a
@SuppressWarnings annotation instead. Why not always use UtilGenerics?
Example from your patch:
{code}
@SuppressWarnings(rawtypes)
public void testJSONToMap() throws Exception {
ConverterJSON, Map converter = Converters.getConverter(JSON.class,
Map.class);
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
The @SuppressWarnings annotation is not needed:
{code}
public void testJSONToMap() throws Exception {
ConverterJSON, MapString,String converter =
UtilGenerics.cast(Converters.getConverter(JSON.class, Map.class));
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
was (Author: adri...@hlmksw.com):
Taher,
Thank you for working on this! One thing has me confused: You make use of the
UtilGenerics methods in some places, but not in others - where you add a
@SuppressWarnings annotation instead. Why not always use UtilGenerics?
Example from your patch:
{code}
@SuppressWarnings(rawtypes)
public void testJSONToMap() throws Exception {
ConverterJSON, Map converter = Converters.getConverter(JSON.class,
Map.class);
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
The @Suppress annotation is not needed:
{code}
public void testJSONToMap() throws Exception {
ConverterJSON, MapString,String converter =
UtilGenerics.cast(Converters.getConverter(JSON.class, Map.class));
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
fix warnings in trunk on java source code
-
Key: OFBIZ-6217
URL: https://issues.apache.org/jira/browse/OFBIZ-6217
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Taher Alkhateeb
Assignee: Adrian Crum
Priority: Minor
Labels: java, warning
Fix For: Upcoming Branch
Attachments: remove_unused_imports.patch, warnings_patch_2.patch
Right now, we have 528 warnings on trunk out of which 238 are about raw types
and 118 never used imports. So we can already eliminate most of the warning
quite quickly.
I will issue multiple patches to resolve most of these warnings. It might be
a bit of a challenge to eliminate the raw types because the generics are not
always deducable from the code especially when relying on external APIs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385239#comment-14385239 ] Adrian Crum commented on OFBIZ-6217: Please provide an updated patch. fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385200#comment-14385200 ] Taher Alkhateeb commented on OFBIZ-6217: I have created a new attachment called warnings_patch_2.patch. This will bring down the number of warnings to 294. The patch includes the followings - removal of deprecated code causing some warnings - Introduction of generics to many collections - conversion of many maps and lists to java API instead of the old fastmap and fastlist from javolution - removal of redundant and unnecessary suppress tags - addition of suppress tags to places where the issue is not solvable - cleaning up iterator code to use generics - refactoring some code where the generics are incorrectly applied Please apply fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385200#comment-14385200 ] Taher Alkhateeb edited comment on OFBIZ-6217 at 3/28/15 9:01 AM: - I have created a new attachment called warnings_patch_2.patch and deleted the other patch to avoid confusion. This will bring down the number of warnings to 294. The patch includes the followings - removal of deprecated code causing some warnings - Introduction of generics to many collections - conversion of many maps and lists to java API instead of the old fastmap and fastlist from javolution - removal of redundant and unnecessary suppress tags - addition of suppress tags to places where the issue is not solvable - cleaning up iterator code to use generics - refactoring some code where the generics are incorrectly applied Please apply was (Author: taher): I have created a new attachment called warnings_patch_2.patch. This will bring down the number of warnings to 294. The patch includes the followings - removal of deprecated code causing some warnings - Introduction of generics to many collections - conversion of many maps and lists to java API instead of the old fastmap and fastlist from javolution - removal of redundant and unnecessary suppress tags - addition of suppress tags to places where the issue is not solvable - cleaning up iterator code to use generics - refactoring some code where the generics are incorrectly applied Please apply fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6175) Replace findInventoryEventPlan.ftl with form widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385210#comment-14385210 ] Pierre Smits edited comment on OFBIZ-6175 at 3/28/15 9:40 AM: -- Where do 'Inventory Planned Events' go when they are finished? Do they stay on the list? Does MRP Event Type Id in any way relate to the MRP Job Id? was (Author: pfm.smits): Where do 'Inventory Planned Events' go when they are finished? Do they stay on the list? Replace findInventoryEventPlan.ftl with form widgets Key: OFBIZ-6175 URL: https://issues.apache.org/jira/browse/OFBIZ-6175 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Priority: Trivial Labels: inventory, mrp, plan Attachments: OFBIZ-6175.patch While troubleshooting production run requirements created from the Mrp I evaluated findInventoryEventPlan.ftl for conversion to a form widget which I generally do for any FTL file I encounter since I find the widgets much easier to interpret. Other than the the ERROR mrpEventType record not being combined with the INITIAL_QOH line, I was able to reproduce the FTL with a form widget. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6175) Replace findInventoryEventPlan.ftl with form widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385210#comment-14385210 ] Pierre Smits commented on OFBIZ-6175: - Where do 'Inventory Planned Events' go when they are finished? Do they stay on the list? Replace findInventoryEventPlan.ftl with form widgets Key: OFBIZ-6175 URL: https://issues.apache.org/jira/browse/OFBIZ-6175 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Priority: Trivial Labels: inventory, mrp, plan Attachments: OFBIZ-6175.patch While troubleshooting production run requirements created from the Mrp I evaluated findInventoryEventPlan.ftl for conversion to a form widget which I generally do for any FTL file I encounter since I find the widgets much easier to interpret. Other than the the ERROR mrpEventType record not being combined with the INITIAL_QOH line, I was able to reproduce the FTL with a form widget. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum reassigned OFBIZ-6217: -- Assignee: Adrian Crum fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: remove_unused_imports.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Proposal to introduce factory pattern to java collections
Hi All, The move from javolution to the collections API built in to java proves to be painful. To avoid such things in the future and to reduce the new keyword clutter in the code I suggest we create factories for all collections. This way we we can also enhance the collections in the future with any ofbiz specific code. This is also a best practice in terms of design patterns. I would like to have opinions on whether this is a wanted / acceptable feature so I can create a JIRA accordingly. Your opinions are appreciated. Taher Alkhateeb.
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385222#comment-14385222
]
Adrian Crum commented on OFBIZ-6217:
Taher,
Thank you for working on this! One thing has me confused: You make use of the
UtilGenerics methods in some places, but not in others - where you add a
@SuppressWarnings annotation instead. Why not always use UtilGenerics?
Example from your patch:
{code}
@SuppressWarnings(rawtypes)
public void testJSONToMap() throws Exception {
ConverterJSON, Map converter = Converters.getConverter(JSON.class,
Map.class);
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
The @Suppress annotation is not needed:
{code}
public void testJSONToMap() throws Exception {
ConverterJSON, MapString,String converter =
UtilGenerics.cast(Converters.getConverter(JSON.class, Map.class));
MapString,String map, convertedMap;
map = new HashMapString,String();
map.put(field1, value1);
JSON json = JSON.from(map);
convertedMap = UtilGenerics.toMap(converter.convert(json));
assertEquals(JSON to Map, map, convertedMap);
}
{code}
fix warnings in trunk on java source code
-
Key: OFBIZ-6217
URL: https://issues.apache.org/jira/browse/OFBIZ-6217
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Taher Alkhateeb
Assignee: Adrian Crum
Priority: Minor
Labels: java, warning
Fix For: Upcoming Branch
Attachments: remove_unused_imports.patch, warnings_patch_2.patch
Right now, we have 528 warnings on trunk out of which 238 are about raw types
and 118 never used imports. So we can already eliminate most of the warning
quite quickly.
I will issue multiple patches to resolve most of these warnings. It might be
a bit of a challenge to eliminate the raw types because the generics are not
always deducable from the code especially when relying on external APIs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
