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 scott.g...@hotwaxmedia.comwrote:
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 adrian.c...@sandglass-software.com
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-8009-exec-511) [
ScriptUtil.java:347:WARN ] runtime exception report
-- Error
running
script at
location
[component://order/webapp/ordermgr/WEB-INF/actions/
order/OrderView.groovy]:
java.util.ConcurrentModificationException Exception:
java.util.ConcurrentModificationException Message: null
stack
trace
--**
--**---
java.util.ConcurrentModificationException
java.util.LinkedList$ListItr.checkForComodification(**
LinkedList.java:761)
java.util.LinkedList$ListItr.next(LinkedList.java:696)
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(**
DefaultGroovyMethods.java:1375)
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(**
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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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=1481276r1=1481275r2=1481276view=diff == ---
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
From: Adrian Crum adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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:
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 jacopo.cappell...@hotwaxmedia.com 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
Jacques Le Roux wrote: From: Adrian Crum adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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 adrian.c...@sandglass-software.com 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
[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-tabpanelfocusedCommentId=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
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 jacques.le.r...@les7arts.com 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 jacopo.cappell...@hotwaxmedia.com 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
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: 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
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
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
