buildbot success in ASF Buildbot on ofbiz-trunk
The Buildbot has detected a restored build on builder ofbiz-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/3732 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch ofbiz/trunk] 1482132 Blamelist: doogie Build succeeded! sincerely, -The Buildbot
Re: buildbot exception in ASF Buildbot on ofbiz-trunk
Could it be an older ant? Maybe 1.7 doesn't auto-create folders. On 05/13/2013 03:16 PM, Adam Heath wrote: > I am very confused. This is the rmi/jar change I introduced in > 1482060. I just re-verified that both the internal ant(1.9.0) and the > system level ant(1.8.2) do the correct thing. A clean/build cycle > thru the framework/service component auto-creates the build/rmi > folder, without explicity doing so. > > I have done a build with both ants, after doing a clean, and verifying > that the framework/service/build directory does not exist inbetween. > > On 05/13/2013 03:09 PM, build...@apache.org wrote: >> The Buildbot has detected a new failure on builder ofbiz-trunk while >> building ASF Buildbot. >> Full details are available at: >> http://ci.apache.org/builders/ofbiz-trunk/builds/3731 >> >> Buildbot URL: http://ci.apache.org/ >> >> Buildslave for this Build: portunus_ubuntu >> >> Build Reason: scheduler >> Build Source Stamp: [branch ofbiz/trunk] 1482069 >> Blamelist: doogie >> >> BUILD FAILED: exception compile upload_3 >> >> sincerely, >> -The Buildbot >> >> >> >
Re: buildbot exception in ASF Buildbot on ofbiz-trunk
I am very confused. This is the rmi/jar change I introduced in 1482060. I just re-verified that both the internal ant(1.9.0) and the system level ant(1.8.2) do the correct thing. A clean/build cycle thru the framework/service component auto-creates the build/rmi folder, without explicity doing so. I have done a build with both ants, after doing a clean, and verifying that the framework/service/build directory does not exist inbetween. On 05/13/2013 03:09 PM, build...@apache.org wrote: > The Buildbot has detected a new failure on builder ofbiz-trunk while building > ASF Buildbot. > Full details are available at: > http://ci.apache.org/builders/ofbiz-trunk/builds/3731 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: portunus_ubuntu > > Build Reason: scheduler > Build Source Stamp: [branch ofbiz/trunk] 1482069 > Blamelist: doogie > > BUILD FAILED: exception compile upload_3 > > sincerely, > -The Buildbot > > >
buildbot exception in ASF Buildbot on ofbiz-trunk
The Buildbot has detected a new failure on builder ofbiz-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/3731 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch ofbiz/trunk] 1482069 Blamelist: doogie BUILD FAILED: exception compile upload_3 sincerely, -The Buildbot
Re: Are tests failing in the 12.04 release branch?
Thank you Jacques but I have tried again and this time it worked just fine... it was probably something wrong in my environment. Jacopo On May 13, 2013, at 11:54 AM, Jacques Le Roux wrote: > Buildbot is ok at least http://ci.apache.org/projects/ofbiz/logs/12.04/html/ > I will run them here too > > Jacques > > > From: "Jacopo Cappellato" >> Hi all, >> >> I see 3 tests failure in the latest 12.04 release branch that shouldn't be >> related to local changes? >> Is any of you experiencing the same? >> >> Thanks, >> >> Jacopo >> >>
[jira] [Commented] (OFBIZ-5188) failed to deploy ofbiz12.04 to jboss5.1.0.GA
[ https://issues.apache.org/jira/browse/OFBIZ-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655894#comment-13655894 ] Moustafa Mahmoud commented on OFBIZ-5188: - when deploying to tomcat 6, server is started without errors , but when invoking party manager application at https://localhost:8443/partymgr/control/main , and other OFBiz applications i got an error page containing "org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://common/widget/CommonScreens.xml#GlobalDecorator]: java.lang.IllegalArgumentException: Template location is empty (Template location is empty)" and in console i got the following exception org.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.jav a:321) org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:268) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:880) org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:149) org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:131) org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:7 6) org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:51) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:390) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:219) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:159) org.ofbiz.widget.screen.ModelScreenAction$Service.runAction(ModelScreenAction.ja va:481) org.ofbiz.widget.screen.ModelScreenAction.runSubActions(ModelScreenAction.java:1 18) org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreen Widget.java:220) org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393) org.ofbiz.widget.screen.ModelScreenWidget$IncludeScreen.renderWidgetString(Model ScreenWidget.java:552) org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidg et.java:138) org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreen Widget.java:227) org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393) org.ofbiz.widget.screen.ModelScreenWidget$IncludeScreen.renderWidgetString(Model ScreenWidget.java:552) org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidg et.java:138) org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreen Widget.java:227) org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393) org.ofbiz.widget.screen.ModelScreenWidget$DecoratorScreen.renderWidgetString(Mod elScreenWidget.java:646) org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidg et.java:138) org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreen Widget.java:227) org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393) org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:132) org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92) org.ofbiz.widget.screen.ScreenWidgetViewHandler.render(ScreenWidgetViewHandler.j ava:98) org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:795) org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:539) org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:202) javax.servlet.http.HttpServlet.service(HttpServlet.java:690) javax.servlet.http.HttpServlet.service(HttpServlet.java:803) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt erChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain. java:206) org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt erChain.java:235) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain. java:206) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2 33) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1 75) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109 ) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Pr otocol.java:583) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) java.lang.Thread.run(Thread.java:662) 2013-05-13 12:30:22,667 (http-8443-1) [ ServiceDispatcher.java:528:ERROR] Error in Service [getVisualThe
Re: svn commit: r1481276 - in /ofbiz/branches/release12.04: ./ applications/party/widget/partymgr/PartyForms.xml
Jacques Le Roux wrote: > From: "Adrian Crum" >> I don't understand what you mean when you say >> "entitycache.entity-list.default.PartyNameView nor >> entitycache.object-list.default.PartyNameView are not parts of >> utilCacheTable." Both of those caches extend >> AbstractEntityConditionCache, and that cache checks for view entities >> that the GenericValue is a member of. There is a chance there is a flaw >> in the view entity checking logic. > > Yes that's what I think also. I will have a deeper look when I will get a > chance > > Jacques OK, my answer was not clear. What I meant is we try to clear the caches of entitycache.entity-list.default.PartyNameView and entitycache.object-list.default.PartyNameView using the content of utilCacheTable which contains only entitycache.entity.default.PartyNameView. So we don't find them and don't clear what we should (I guess entitycache.entity.default.PartyNameView) That's why I agree it's a flaw in the view entity checking cache logic regarding cache clearing. I'm looking at it... Jacques >> -Adrian >> >> On 5/12/2013 10:30 PM, Jacques Le Roux wrote: >>> I had a quick look. As reported in the Jira this is an old neglected or >>> unknown issue (reproductible in R11.04 and R12.04) >>> >>> In this peculiar case, when storing we clear the cache for 2 entities: >>> Person and Party. >>> We use an EntityView in the display-entity (PartyNameView) and clearing >>> the entity cache does not refresh the EntityView >>> cache. In other words, the cache clearing done by >>> this.clearCacheLine(value) in GenericDelegator.store() does not propagated >>> to >>> the EntityView cache. This is simply because >>> entitycache.entity-list.default.PartyNameView nor >>> entitycache.object-list.default.PartyNameView are not parts of >>> utilCacheTable. I noticed tough that >>> entitycache.entity.default.PartyNameView is. I stopped there... >>> >>> Note that the the >>> this.distributedCacheClear.distributedClearCacheLine(value) is >>> automatically done in >>> GenericDelegator.clearCacheLine(). >>> >>> HTH >>> >>> Jacques >>> >>> From: "Adrian Crum" I fixed the entity condition cache. The cache being used in OFBIZ-5192 is the primary key cache. So that is the one to look at. Most likely, the code that saves the changes to Person is not clearing the pk cache - so that's why you see the stale data after an update. The entity model overhaul has nothing to do with this problem. -Adrian On 5/11/2013 11:32 AM, Jacques Le Roux wrote: > Ha, I thought you had already fixed the underneath issue. Now I remember > you also warned us at > https://issues.apache.org/jira/browse/OFBIZ-5146 and DCC will still to be > done > > OK, though it's not a biggie (not caching here does not hurt), I will > revert > > Note that I don't agree with Anyway, this should not be a problem on the trunk. > As I said it's easy to reproduce on trunk demo > > To be sure to understand. When your entity model overhaul WIP will be > committed this will fix this (kinda?) issue(s?) ? > > Thanks > > Jacques > > From: "Adrian Crum" >> You believe wrong. >> >> Please revert the OFBIZ-5192 related commits, then spend some time >> reviewing the discussion with the subject: "Important: Entity list cache >> and GenericValue discussion". >> >> Understand the problem before you try to fix it. >> >> -Adrian >> >> On 5/11/2013 11:02 AM, Jacques Le Roux wrote: >>> I intially reproduced with trunk demo, so I fixed it there and >>> backported. >>> I believe it's unrelated to the issues you fixed >>> >>> Jacques >>> >>> From: "Adrian Crum" Oops, I didn't notice this was on a release branch. Anyway, this should not be a problem on the trunk. -Adrian On 5/11/2013 10:14 AM, Adrian Crum wrote: > Are you sure this change is necessary? I fixed the caching problem a > few days ago. > > -Adrian > > > On 5/11/2013 10:09 AM, jler...@apache.org wrote: >> Author: jleroux >> Date: Sat May 11 09:09:26 2013 >> New Revision: 1481276 >> >> URL: http://svn.apache.org/r1481276 >> Log: >> "Applied fix from trunk for revision: 1481274" >> >> r1481274 | jleroux | 2013-05-11 10:52:25 +0200 (sam., 11 mai 2013) | >> 14 lines >> >> Fix "Name in List Related Contacts form doesn't get updated" reported >> by Karl Beecher at https://issues.apache.org/jira/browse/OFBIZ-5192 >> >> If a person is set as a related contact for a party, updates to their >> name are not immediately displayed
Re: Are tests failing in the 12.04 release branch?
Buildbot is ok at least http://ci.apache.org/projects/ofbiz/logs/12.04/html/ I will run them here too Jacques From: "Jacopo Cappellato" > Hi all, > > I see 3 tests failure in the latest 12.04 release branch that shouldn't be > related to local changes? > Is any of you experiencing the same? > > Thanks, > > Jacopo > >
Re: svn commit: r1481276 - in /ofbiz/branches/release12.04: ./ applications/party/widget/partymgr/PartyForms.xml
From: "Adrian Crum" >I don't understand what you mean when you say > "entitycache.entity-list.default.PartyNameView nor > entitycache.object-list.default.PartyNameView are not parts of > utilCacheTable." Both of those caches extend > AbstractEntityConditionCache, and that cache checks for view entities > that the GenericValue is a member of. There is a chance there is a flaw > in the view entity checking logic. Yes that's what I think also. I will have a deeper look when I will get a chance Jacques > -Adrian > > On 5/12/2013 10:30 PM, Jacques Le Roux wrote: >> I had a quick look. As reported in the Jira this is an old neglected or >> unknown issue (reproductible in R11.04 and R12.04) >> >> In this peculiar case, when storing we clear the cache for 2 entities: >> Person and Party. >> We use an EntityView in the display-entity (PartyNameView) and clearing the >> entity cache does not refresh the EntityView cache. In other words, the >> cache clearing done by this.clearCacheLine(value) in >> GenericDelegator.store() does not propagated to the EntityView cache. This >> is simply because entitycache.entity-list.default.PartyNameView nor >> entitycache.object-list.default.PartyNameView are not parts of >> utilCacheTable. I noticed tough that >> entitycache.entity.default.PartyNameView is. I stopped there... >> >> Note that the the >> this.distributedCacheClear.distributedClearCacheLine(value) is automatically >> done in GenericDelegator.clearCacheLine(). >> >> HTH >> >> Jacques >> >> From: "Adrian Crum" >>> I fixed the entity condition cache. The cache being used in OFBIZ-5192 >>> is the primary key cache. So that is the one to look at. >>> >>> Most likely, the code that saves the changes to Person is not clearing >>> the pk cache - so that's why you see the stale data after an update. >>> >>> The entity model overhaul has nothing to do with this problem. >>> >>> -Adrian >>> >>> On 5/11/2013 11:32 AM, Jacques Le Roux wrote: Ha, I thought you had already fixed the underneath issue. Now I remember you also warned us at https://issues.apache.org/jira/browse/OFBIZ-5146 and DCC will still to be done OK, though it's not a biggie (not caching here does not hurt), I will revert Note that I don't agree with >>> Anyway, this should >>> not be a problem on the trunk. As I said it's easy to reproduce on trunk demo To be sure to understand. When your entity model overhaul WIP will be committed this will fix this (kinda?) issue(s?) ? Thanks Jacques From: "Adrian Crum" > You believe wrong. > > Please revert the OFBIZ-5192 related commits, then spend some time > reviewing the discussion with the subject: "Important: Entity list cache > and GenericValue discussion". > > Understand the problem before you try to fix it. > > -Adrian > > On 5/11/2013 11:02 AM, Jacques Le Roux wrote: >> I intially reproduced with trunk demo, so I fixed it there and >> backported. >> I believe it's unrelated to the issues you fixed >> >> Jacques >> >> From: "Adrian Crum" >>> Oops, I didn't notice this was on a release branch. Anyway, this should >>> not be a problem on the trunk. >>> >>> -Adrian >>> >>> On 5/11/2013 10:14 AM, Adrian Crum wrote: Are you sure this change is necessary? I fixed the caching problem a few days ago. -Adrian On 5/11/2013 10:09 AM, jler...@apache.org wrote: > Author: jleroux > Date: Sat May 11 09:09:26 2013 > New Revision: 1481276 > > URL: http://svn.apache.org/r1481276 > Log: > "Applied fix from trunk for revision: 1481274" > > r1481274 | jleroux | 2013-05-11 10:52:25 +0200 (sam., 11 mai 2013) | > 14 lines > > Fix "Name in List Related Contacts form doesn't get updated" reported > by Karl Beecher at https://issues.apache.org/jira/browse/OFBIZ-5192 > > If a person is set as a related contact for a party, updates to their > name are not immediately displayed by the ListRelatedContacts form. > > To reproduce (with OFBiz demo data): > * In the Party Manager, go to the profile page of DemoSupplier (they > have a related contact called 'Peter Manager' > * Follow the link to Peter Manager's profile page. > * Click Update and change the name (e.g. to 'Peter Manageress') > * Save > * Return to DemoSupplier's profile page. Observe that the name of the > related contact is still 'Peter Manager'. Refreshing doesn't change > that. > * Restart OFBiz > * Refreshing the profile page now displays the updated name. > > jleroux: to test in trunk I used c
Are tests failing in the 12.04 release branch?
Hi all, I see 3 tests failure in the latest 12.04 release branch that shouldn't be related to local changes? Is any of you experiencing the same? Thanks, Jacopo
Re: svn commit: r1481276 - in /ofbiz/branches/release12.04: ./ applications/party/widget/partymgr/PartyForms.xml
I don't understand what you mean when you say "entitycache.entity-list.default.PartyNameView nor entitycache.object-list.default.PartyNameView are not parts of utilCacheTable." Both of those caches extend AbstractEntityConditionCache, and that cache checks for view entities that the GenericValue is a member of. There is a chance there is a flaw in the view entity checking logic. -Adrian On 5/12/2013 10:30 PM, Jacques Le Roux wrote: I had a quick look. As reported in the Jira this is an old neglected or unknown issue (reproductible in R11.04 and R12.04) In this peculiar case, when storing we clear the cache for 2 entities: Person and Party. We use an EntityView in the display-entity (PartyNameView) and clearing the entity cache does not refresh the EntityView cache. In other words, the cache clearing done by this.clearCacheLine(value) in GenericDelegator.store() does not propagated to the EntityView cache. This is simply because entitycache.entity-list.default.PartyNameView nor entitycache.object-list.default.PartyNameView are not parts of utilCacheTable. I noticed tough that entitycache.entity.default.PartyNameView is. I stopped there... Note that the the this.distributedCacheClear.distributedClearCacheLine(value) is automatically done in GenericDelegator.clearCacheLine(). HTH Jacques From: "Adrian Crum" I fixed the entity condition cache. The cache being used in OFBIZ-5192 is the primary key cache. So that is the one to look at. Most likely, the code that saves the changes to Person is not clearing the pk cache - so that's why you see the stale data after an update. The entity model overhaul has nothing to do with this problem. -Adrian On 5/11/2013 11:32 AM, Jacques Le Roux wrote: Ha, I thought you had already fixed the underneath issue. Now I remember you also warned us at https://issues.apache.org/jira/browse/OFBIZ-5146 and DCC will still to be done OK, though it's not a biggie (not caching here does not hurt), I will revert Note that I don't agree with Anyway, this should not be a problem on the trunk. As I said it's easy to reproduce on trunk demo To be sure to understand. When your entity model overhaul WIP will be committed this will fix this (kinda?) issue(s?) ? Thanks Jacques From: "Adrian Crum" You believe wrong. Please revert the OFBIZ-5192 related commits, then spend some time reviewing the discussion with the subject: "Important: Entity list cache and GenericValue discussion". Understand the problem before you try to fix it. -Adrian On 5/11/2013 11:02 AM, Jacques Le Roux wrote: I intially reproduced with trunk demo, so I fixed it there and backported. I believe it's unrelated to the issues you fixed Jacques From: "Adrian Crum" Oops, I didn't notice this was on a release branch. Anyway, this should not be a problem on the trunk. -Adrian On 5/11/2013 10:14 AM, Adrian Crum wrote: Are you sure this change is necessary? I fixed the caching problem a few days ago. -Adrian On 5/11/2013 10:09 AM, jler...@apache.org wrote: Author: jleroux Date: Sat May 11 09:09:26 2013 New Revision: 1481276 URL: http://svn.apache.org/r1481276 Log: "Applied fix from trunk for revision: 1481274" r1481274 | jleroux | 2013-05-11 10:52:25 +0200 (sam., 11 mai 2013) | 14 lines Fix "Name in List Related Contacts form doesn't get updated" reported by Karl Beecher at https://issues.apache.org/jira/browse/OFBIZ-5192 If a person is set as a related contact for a party, updates to their name are not immediately displayed by the ListRelatedContacts form. To reproduce (with OFBiz demo data): * In the Party Manager, go to the profile page of DemoSupplier (they have a related contact called 'Peter Manager' * Follow the link to Peter Manager's profile page. * Click Update and change the name (e.g. to 'Peter Manageress') * Save * Return to DemoSupplier's profile page. Observe that the name of the related contact is still 'Peter Manager'. Refreshing doesn't change that. * Restart OFBiz * Refreshing the profile page now displays the updated name. jleroux: to test in trunk I used company and scrum employee Modified: ofbiz/branches/release12.04/ (props changed) ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml Propchange: ofbiz/branches/release12.04/ -- Merged /ofbiz/trunk:r1470176,1481274 Modified: ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml URL: http://svn.apache.org/viewvc/ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml?rev=1481276&r1=1481275&r2=1481276&view=diff == --- ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml (original) +++ ofbiz/br
Re: Order cancellation exception
That looks good too and more cleaner. Thanks Scott.
I will try it and provide a new patch asap containing that approach.
On Mon, May 13, 2013 at 5:44 AM, Scott Gray wrote:
> FYI, you can also use some of groovy's other collection methods:
> // Retrieve all non-promo items that aren't cancelled
> context.orderItemListFiltered = orderReadHelper.getOrderItems().findAll {
> item ->
> (item.isPromo == null || item.isPromo == 'N') &&
> !(item.statusId.equals('ITEM_CANCELLED'))
> }
>
> Regards
> Scott
>
> On 12/05/2013, at 12:39 AM, Jacques Le Roux wrote:
>
> > I did not look into details, but yes seems the way
> >
> > Thanks
> >
> > Jacques
> >
> > Jonatan Soto wrote:
> >> There isn't afaik. Do you want me to create one if that's finally the
> case?
> >>
> >>
> >> On Sat, May 11, 2013 at 1:39 PM, Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Is there a Jira for that, should we not commit and backport?
> >>>
> >>> Jacques
> >>>
> >>> From: "Adrian Crum"
> That is correct.
>
> -Adrian
>
> On 5/11/2013 11:41 AM, Jonatan Soto wrote:
> > Ok, I think I got it. My solution only covered first problem, but the
> > second problem implies that the first problem is no longer a problem
> > because the original order item list has to remain unmodified for
> further
> > usage. So this might fix problem 2:
> >
> > orderItemListFiltered = new LinkedList();
> > orderItemList = orderReadHelper.getOrderItems();
> > orderItemList.each { orderItem ->
> > if (UtilValidate.isEmpty(orderItem.get("isPromo")) ||
> > "N".equals(orderItem.get("isPromo"))) {
> > orderItemListFiltered.add(orderItem);
> > } else {
> > if (!"ITEM_CANCELLED".equals(orderItem.get("statusId")))
> > orderItemListFiltered.add(orderItem);
> > }
> > }
> > context.orderItemList = orderItemListFiltered;
> >
> > HTH
> >
> >
> > On Sat, May 11, 2013 at 11:47 AM, Adrian Crum <
> > adrian.c...@sandglass-software.com> wrote:
> >
> >> There are two problems with that part of the script:
> >>
> >> 1. It modifies a List while iterating over it.
> >> 2. It modifies a List that is contained by OrderReadHelper - so any
> >> further use of OrderReadHelper will produce incorrect data.
> >>
> >> The solution is to iterate over the List contained on
> OrderReadHelper and
> >> build a new List based on the selection criteria. In other words,
> create a
> >> new List that excludes canceled promo items instead of modifying the
> >> existing List.
> >>
> >> -Adrian
> >>
> >>
> >> On 5/11/2013 10:41 AM, Jonatan Soto wrote:
> >>
> >>> I could fix the issue by doing the following at line 122 of that
> groovy
> >>> file:
> >>>
> >>> //canceledPromoOrderItem = [:];
> >>> orderItemList = orderReadHelper.getOrderItems(**);
> >>> for (Iterator iter = orderItemList.iterator(); iter.hasNext();) {
> >>> //orderItemList.each { orderItem ->
> >>> orderItem = iter.next();
> >>> if("Y".equals(orderItem.get("**isPromo")) &&
> >>> "ITEM_CANCELLED".equals(**orderItem.get("statusId"))) {
> >>> //canceledPromoOrderItem = orderItem;
> >>> iter.remove();
> >>> }
> >>> Debug.log("orderItem ==> " + orderItem);
> >>> }
> >>>
> >>>
> >>> I've proceed in that way according to what I read from the
> LinkedList java
> >>> doc http://docs.oracle.com/javase/**6/docs/api/java/util/**
> >>> LinkedList.html<
> >>> http://docs.oracle.com/javase/6/docs/api/java/util/LinkedList.html>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, May 10, 2013 at 2:38 PM, Adrian Crum <
> >>> adrian.crum@sandglass-**software.com <
> >>> adrian.c...@sandglass-software.com>>
> >>> wrote:
> >>>
> >>> Actually, OrderView.groovy line 122 doesn't make any sense. That
> is
> >>> a
> flaw
> in the groovy code, not a problem with the List implementation.
>
> -Adrian
>
>
> On 5/10/2013 1:09 PM, Adrian Crum wrote:
>
> It appears LinkedList was not a good replacement for FastList. I
> >>> will
> > take care of it this weekend.
> >
> > -Adrian
> >
> > On 5/10/2013 12:32 PM, Jonatan Soto wrote:
> >
> > This is a more detailed stack trace btw. Note that once this
> >>> happens is
> >> not
> >> possible to edit the order anymore.
> >>
> >> 2013-05-10 12:23:43,348 (ajp-bio-0.0.0.0-8009-exec-511) [
> >>
> >> ScreenFactory.java:130:INFO ] Got 29 screens in 0.0080s from:
> >> file:/home/ofbiz/trunk/applications/order/widget/
> >> ordermgr/OrderViewScreens.xml
> >>
> >>
> >> 2013-05-10 12:23:43,522 (ajp-bio-0.0.0.0-80
