Re: In preparation for the 13.04 branch
It is OK, But Does this mean ecommerce application will be removed to another directory, or will be entirely suppressed from the new release and released separately? Does this mean we will have main release with core components, and any other components will be treated as plugins or something like that? Regards, Medhat On Sat, Mar 23, 2013 at 6:36 AM, Deepak Dixit wrote: > +1 > > One thing will need to move convertProductPriceCurrency property from > ecommerce.properies file, may be place it in catalog.properties or in some > other property file. > As this is used for automatic product price currency conversion (r1125215). > > Thanks & Regards > -- > Deepak Dixit > > On Mar 23, 2013, at 2:40 AM, Jacques Le Roux wrote: > > > Agreed > > > > Jacques > > > > From: "Adrian Crum" > >> That seems pretty harmless. Anyone wanting to use specialpurpose can > >> just add it to their local copy. > >> > >> -Adrian > >> > >> On 3/22/2013 4:19 PM, Jacopo Cappellato wrote: > >>> Hi all, > >>> > >>> the next month is the month of the creation of our annual branch > release: release13.04. > >>> In preparation for this, I would like to propose to exclude from the > upcoming new branch the specialpurpose folder and some of the themes > components: this is inline with what we have discussed recently for the > trunk (and there seemed to be a good consensus/interest about this), i.e. > separating the specialpurpose folders into an optional module that is not > built and deployed by default: for the trunk this requires some work to > make the build scripts more flexible, but for the branch it is much simpler > (we can simply remove the folders from the branch). > >>> This will help a lot to avoid the risk to receive vulnerability > reports for the future releases, that require a good amount of work for us; > in fact there are a lot of external jars in specialpurpose and if we > deliver them in our releases we should also take care of making sure that, > if the external projects issue new releases with fixes for vulnerabilities > then we should also issue a new release as well: maintaining this is time > consuming and also reviewing all the code to make sure it meets good > standard of quality and it is clear from license issues when a release is > issued is becoming an overwhelming effort. If we deliver in releases a > smaller codebase, everything will be easier and more manageable. > >>> Of course we can still decide to issue a release of "specialpurpose" > components separately. > >>> > >>> WDYT? > >>> > >>> Jacopo > >> > >
Re: In preparation for the 13.04 branch
+1 One thing will need to move convertProductPriceCurrency property from ecommerce.properies file, may be place it in catalog.properties or in some other property file. As this is used for automatic product price currency conversion (r1125215). Thanks & Regards -- Deepak Dixit On Mar 23, 2013, at 2:40 AM, Jacques Le Roux wrote: > Agreed > > Jacques > > From: "Adrian Crum" >> That seems pretty harmless. Anyone wanting to use specialpurpose can >> just add it to their local copy. >> >> -Adrian >> >> On 3/22/2013 4:19 PM, Jacopo Cappellato wrote: >>> Hi all, >>> >>> the next month is the month of the creation of our annual branch release: >>> release13.04. >>> In preparation for this, I would like to propose to exclude from the >>> upcoming new branch the specialpurpose folder and some of the themes >>> components: this is inline with what we have discussed recently for the >>> trunk (and there seemed to be a good consensus/interest about this), i.e. >>> separating the specialpurpose folders into an optional module that is not >>> built and deployed by default: for the trunk this requires some work to >>> make the build scripts more flexible, but for the branch it is much simpler >>> (we can simply remove the folders from the branch). >>> This will help a lot to avoid the risk to receive vulnerability reports for >>> the future releases, that require a good amount of work for us; in fact >>> there are a lot of external jars in specialpurpose and if we deliver them >>> in our releases we should also take care of making sure that, if the >>> external projects issue new releases with fixes for vulnerabilities then we >>> should also issue a new release as well: maintaining this is time consuming >>> and also reviewing all the code to make sure it meets good standard of >>> quality and it is clear from license issues when a release is issued is >>> becoming an overwhelming effort. If we deliver in releases a smaller >>> codebase, everything will be easier and more manageable. >>> Of course we can still decide to issue a release of "specialpurpose" >>> components separately. >>> >>> WDYT? >>> >>> Jacopo >>
Re: svn commit: r1458429 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
If it solves all related issues, notably the one with Entity Sync at the origin
of the Jira IIRW, then it should be applied to R11.04 and R10.04 as well.
Else, I believe we should revert all what was committed (and not reverted) in
OFBIZ-4602 and tackle the issues at the root again
Jacques
From: "David E. Jones"
>
> It could be. Wow. That issue is a mess. If it is related it looks like this
> bug was caused by the "fix" for that issue.
>
> -David
>
>
> On Mar 21, 2013, at 4:56 PM, Paul Foxworthy wrote:
>
>> Hi David and Jacopo,
>>
>> is this change related to Jira issue OFBIZ-4602?
>>
>> Thanks
>>
>> Paul Foxworthy
>>
>>
>> Jacopo Cappellato-4 wrote
>>> Hi David,
>>>
>>> is it ok if I backport this also to the 12.04 branch?
>>>
>>> Jacopo
>>>
>>> On Mar 19, 2013, at 6:48 PM,
>>
>>> jonesde@
>>
>>> wrote:
>>>
Author: jonesde
Date: Tue Mar 19 17:48:28 2013
New Revision: 1458429
URL: http://svn.apache.org/r1458429
Log:
Fixed issue with deserialization from XML of an entity value with null
fields
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java?rev=1458429&r1=1458428&r2=1458429&view=diff
==
---
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
(original)
+++
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
Tue Mar 19 17:48:28 2013
@@ -2377,7 +2377,13 @@ public class GenericDelegator implements
String attr = element.getAttribute(name);
if (UtilValidate.isNotEmpty(attr)) {
-value.setString(name, attr);
+// GenericEntity.makeXmlElement() sets null values to
GenericEntity.NULL_FIELD.toString(), so look for
+// that and treat it as null
+if (GenericEntity.NULL_FIELD.toString().equals(attr)) {
+value.set(name, null);
+} else {
+value.setString(name, attr);
+}
} else {
// if no attribute try a subelement
Element subElement = UtilXml.firstChildElement(element,
name);
>>
>>
>>
>>
>>
>> -
>> --
>> Coherent Software Australia Pty Ltd
>> http://www.coherentsoftware.com.au/
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1458429-ofbiz-trunk-framework-entity-src-org-ofbiz-entity-GenericDelegator-java-tp4639948p4639969.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
Re: In preparation for the 13.04 branch
Agreed Jacques From: "Adrian Crum" > That seems pretty harmless. Anyone wanting to use specialpurpose can > just add it to their local copy. > > -Adrian > > On 3/22/2013 4:19 PM, Jacopo Cappellato wrote: >> Hi all, >> >> the next month is the month of the creation of our annual branch release: >> release13.04. >> In preparation for this, I would like to propose to exclude from the >> upcoming new branch the specialpurpose folder and some of the themes >> components: this is inline with what we have discussed recently for the >> trunk (and there seemed to be a good consensus/interest about this), i.e. >> separating the specialpurpose folders into an optional module that is not >> built and deployed by default: for the trunk this requires some work to make >> the build scripts more flexible, but for the branch it is much simpler (we >> can simply remove the folders from the branch). >> This will help a lot to avoid the risk to receive vulnerability reports for >> the future releases, that require a good amount of work for us; in fact >> there are a lot of external jars in specialpurpose and if we deliver them in >> our releases we should also take care of making sure that, if the external >> projects issue new releases with fixes for vulnerabilities then we should >> also issue a new release as well: maintaining this is time consuming and >> also reviewing all the code to make sure it meets good standard of quality >> and it is clear from license issues when a release is issued is becoming an >> overwhelming effort. If we deliver in releases a smaller codebase, >> everything will be easier and more manageable. >> Of course we can still decide to issue a release of "specialpurpose" >> components separately. >> >> WDYT? >> >> Jacopo >
Re: svn commit: r1458429 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
It could be. Wow. That issue is a mess. If it is related it looks like this bug
was caused by the "fix" for that issue.
-David
On Mar 21, 2013, at 4:56 PM, Paul Foxworthy wrote:
> Hi David and Jacopo,
>
> is this change related to Jira issue OFBIZ-4602?
>
> Thanks
>
> Paul Foxworthy
>
>
> Jacopo Cappellato-4 wrote
>> Hi David,
>>
>> is it ok if I backport this also to the 12.04 branch?
>>
>> Jacopo
>>
>> On Mar 19, 2013, at 6:48 PM,
>
>> jonesde@
>
>> wrote:
>>
>>> Author: jonesde
>>> Date: Tue Mar 19 17:48:28 2013
>>> New Revision: 1458429
>>>
>>> URL: http://svn.apache.org/r1458429
>>> Log:
>>> Fixed issue with deserialization from XML of an entity value with null
>>> fields
>>>
>>> Modified:
>>>
>>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>>>
>>> Modified:
>>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java?rev=1458429&r1=1458428&r2=1458429&view=diff
>>> ==
>>> ---
>>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>>> (original)
>>> +++
>>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>>> Tue Mar 19 17:48:28 2013
>>> @@ -2377,7 +2377,13 @@ public class GenericDelegator implements
>>>String attr = element.getAttribute(name);
>>>
>>>if (UtilValidate.isNotEmpty(attr)) {
>>> -value.setString(name, attr);
>>> +// GenericEntity.makeXmlElement() sets null values to
>>> GenericEntity.NULL_FIELD.toString(), so look for
>>> +// that and treat it as null
>>> +if (GenericEntity.NULL_FIELD.toString().equals(attr)) {
>>> +value.set(name, null);
>>> +} else {
>>> +value.setString(name, attr);
>>> +}
>>>} else {
>>>// if no attribute try a subelement
>>>Element subElement = UtilXml.firstChildElement(element,
>>> name);
>>>
>>>
>
>
>
>
>
> -
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1458429-ofbiz-trunk-framework-entity-src-org-ofbiz-entity-GenericDelegator-java-tp4639948p4639969.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: svn commit: r1458429 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
Sorry, just noticed this. Yes, it probably applies to 12.04 as well.
-David
On Mar 20, 2013, at 2:57 AM, Jacopo Cappellato
wrote:
> Hi David,
>
> is it ok if I backport this also to the 12.04 branch?
>
> Jacopo
>
> On Mar 19, 2013, at 6:48 PM, jone...@apache.org wrote:
>
>> Author: jonesde
>> Date: Tue Mar 19 17:48:28 2013
>> New Revision: 1458429
>>
>> URL: http://svn.apache.org/r1458429
>> Log:
>> Fixed issue with deserialization from XML of an entity value with null fields
>>
>> Modified:
>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>>
>> Modified:
>> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java?rev=1458429&r1=1458428&r2=1458429&view=diff
>> ==
>> --- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>> (original)
>> +++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
>> Tue Mar 19 17:48:28 2013
>> @@ -2377,7 +2377,13 @@ public class GenericDelegator implements
>>String attr = element.getAttribute(name);
>>
>>if (UtilValidate.isNotEmpty(attr)) {
>> -value.setString(name, attr);
>> +// GenericEntity.makeXmlElement() sets null values to
>> GenericEntity.NULL_FIELD.toString(), so look for
>> +// that and treat it as null
>> +if (GenericEntity.NULL_FIELD.toString().equals(attr)) {
>> +value.set(name, null);
>> +} else {
>> +value.setString(name, attr);
>> +}
>>} else {
>>// if no attribute try a subelement
>>Element subElement = UtilXml.firstChildElement(element, name);
>>
>>
>
Re: In preparation for the 13.04 branch
That seems pretty harmless. Anyone wanting to use specialpurpose can just add it to their local copy. -Adrian On 3/22/2013 4:19 PM, Jacopo Cappellato wrote: Hi all, the next month is the month of the creation of our annual branch release: release13.04. In preparation for this, I would like to propose to exclude from the upcoming new branch the specialpurpose folder and some of the themes components: this is inline with what we have discussed recently for the trunk (and there seemed to be a good consensus/interest about this), i.e. separating the specialpurpose folders into an optional module that is not built and deployed by default: for the trunk this requires some work to make the build scripts more flexible, but for the branch it is much simpler (we can simply remove the folders from the branch). This will help a lot to avoid the risk to receive vulnerability reports for the future releases, that require a good amount of work for us; in fact there are a lot of external jars in specialpurpose and if we deliver them in our releases we should also take care of making sure that, if the external projects issue new releases with fixes for vulnerabilities then we should also issue a new release as well: maintaining this is time consuming and also reviewing all the code to make sure it meets good standard of quality and it is clear from license issues when a release is issued is becoming an overwhelming effort. If we deliver in releases a smaller codebase, everything will be easier and more manageable. Of course we can still decide to issue a release of "specialpurpose" components separately. WDYT? Jacopo
In preparation for the 13.04 branch
Hi all, the next month is the month of the creation of our annual branch release: release13.04. In preparation for this, I would like to propose to exclude from the upcoming new branch the specialpurpose folder and some of the themes components: this is inline with what we have discussed recently for the trunk (and there seemed to be a good consensus/interest about this), i.e. separating the specialpurpose folders into an optional module that is not built and deployed by default: for the trunk this requires some work to make the build scripts more flexible, but for the branch it is much simpler (we can simply remove the folders from the branch). This will help a lot to avoid the risk to receive vulnerability reports for the future releases, that require a good amount of work for us; in fact there are a lot of external jars in specialpurpose and if we deliver them in our releases we should also take care of making sure that, if the external projects issue new releases with fixes for vulnerabilities then we should also issue a new release as well: maintaining this is time consuming and also reviewing all the code to make sure it meets good standard of quality and it is clear from license issues when a release is issued is becoming an overwhelming effort. If we deliver in releases a smaller codebase, everything will be easier and more manageable. Of course we can still decide to issue a release of "specialpurpose" components separately. WDYT? Jacopo
[jira] [Updated] (OFBIZ-5160) Unable to search accounting aransaction entries by productId
[ https://issues.apache.org/jira/browse/OFBIZ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Olmstead updated OFBIZ-5160: --- Attachment: OFBIZ-5160.patch > Unable to search accounting aransaction entries by productId > > > Key: OFBIZ-5160 > URL: https://issues.apache.org/jira/browse/OFBIZ-5160 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release 09.04, Release 09.04.01, Release Branch 10.04, > Release 10.04, Release Branch 11.04, SVN trunk, Release 11.04.01, Release > Branch 12.04 > Environment: Windows 8 Pro >Reporter: Jeremy Olmstead >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-5160.patch > > > From the FindAcctgTransEntries screen, enter a part number to search > for...you will still get a complete list of all transactions because the form > field name is produtId instead of productId. After searching relevant > document types it turns out there are a few places where produtId is used > instead of productId, the patch is meant to fix them all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-5160) Unable to search accounting aransaction entries by productId
Jeremy Olmstead created OFBIZ-5160: -- Summary: Unable to search accounting aransaction entries by productId Key: OFBIZ-5160 URL: https://issues.apache.org/jira/browse/OFBIZ-5160 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: Release 10.04, Release 09.04.01, Release 09.04, Release Branch 10.04, Release Branch 11.04, SVN trunk, Release 11.04.01, Release Branch 12.04 Environment: Windows 8 Pro Reporter: Jeremy Olmstead Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-5160.patch >From the FindAcctgTransEntries screen, enter a part number to search for...you >will still get a complete list of all transactions because the form field name >is produtId instead of productId. After searching relevant document types it >turns out there are a few places where produtId is used instead of productId, >the patch is meant to fix them all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Some ideas for the future of the OFBiz
I would like to see a deep refactoring of the UI. Ideally, it should be separated into two distinct components, a view renderer and a series of authenticated services that support it. It is about time for us to step into the modern world where the UI is an application, written in Javascript, that communicates with the application using JSON or XML RPC calls. If rendering for javascriptless clients is really still a priority then we might want to look at using rhino or nashorn in the server to do the same rendering there but, fundamentally, move to a javascript based view rendering solution. The interactivity and fluidity of a properly AJAX based interface is part of what makes us look so dated compared to solutions like OpenERP. We also need to completely reconsider the UI experience. The interface is overwhelming to new users. If we could have a role based method for hiding controls then we could have a "beginner" user mode that greatly simplified core screens. A basic drop-ship ecommerce user doesn't need to see billing accounts, facilities and a lot of the other complexity on the product screens. Our order entry process is also rather clunky, even in comparison to older systems like SQL-Ledger. - "Jacopo Cappellato" wrote: > Hi all, > this is just intended to brainstorm some ideas for the future OFBiz (let's > say for the 14.04 branch) and to get the community feedback... I don't have > concrete plans at the moment for most of them > Some of the ideas below are intended to renew some core parts of the OFBiz > Framework, replacing custom code (some of getting old) with Open Source > alternatives; some of them are just cleanups. > * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo TX > and DBCP, well... they actually can stay as optional components) with: > http://www.atomikos.com/Main/TransactionsEssentials > (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) > * Refactor the OFBiz Security (authentication/authorization/cryptography) > with (a session I attended during ApacheCon@Portland inspired me for this): > http://shiro.apache.org > * Replace Javolution (this has been already discussed in the past) > * Replace the OFBiz cache system with: > http://ehcache.org > * Replace the OFBiz job scheduler with: > http://quartz-scheduler.org > * Reorganize the screen data preparation Groovy scripts into bigger files > with methods (they are now individual files); for example, instead of having: > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy > > ... > we could have one file: > applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy > with methods: > editProductAssoc, editProductContent, editProductContentContent, > editProductFeatures... > (note: this switch is possible since the enhancements we did one year ago); > this could make our code more readable and organized without loosing the > ability to override individual scripts from hot-deploy components; in the > process, we could also review the scripts and clean them or improve (some of > them are pretty old) > * (in the process) we could also refactor the code of the Groovy scripts to > use the (now experimental and to be tested/expanded) DSL methods we > implemented one year ago > Kind regards, > Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
Hi Jacopo, looks nice ! Cheers, 2013/3/21 Jacopo Cappellato > Hi all, > > this is just intended to brainstorm some ideas for the future OFBiz (let's > say for the 14.04 branch) and to get the community feedback... I don't have > concrete plans at the moment for most of them > > Some of the ideas below are intended to renew some core parts of the OFBiz > Framework, replacing custom code (some of getting old) with Open Source > alternatives; some of them are just cleanups. > > * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo > TX and DBCP, well... they actually can stay as optional components) with: > http://www.atomikos.com/Main/TransactionsEssentials > (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) > > * Refactor the OFBiz Security (authentication/authorization/cryptography) > with (a session I attended during ApacheCon@Portland inspired me for > this): > http://shiro.apache.org > > * Replace Javolution (this has been already discussed in the past) > > * Replace the OFBiz cache system with: > http://ehcache.org > > * Replace the OFBiz job scheduler with: > http://quartz-scheduler.org > > * Reorganize the screen data preparation Groovy scripts into bigger files > with methods (they are now individual files); for example, instead of > having: > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy > ... > we could have one file: > applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy > with methods: > editProductAssoc, editProductContent, editProductContentContent, > editProductFeatures... > > (note: this switch is possible since the enhancements we did one year > ago); this could make our code more readable and organized without loosing > the ability to override individual scripts from hot-deploy components; in > the process, we could also review the scripts and clean them or improve > (some of them are pretty old) > > * (in the process) we could also refactor the code of the Groovy scripts > to use the (now experimental and to be tested/expanded) DSL methods we > implemented one year ago > > Kind regards, > > Jacopo > > -- Erwan de FERRIERES
[jira] [Created] (OFBIZ-5159) Bug in properties management.
Jacques Le Roux created OFBIZ-5159:
--
Summary: Bug in properties management.
Key: OFBIZ-5159
URL: https://issues.apache.org/jira/browse/OFBIZ-5159
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04, Release Branch 11.04, SVN trunk,
Release Branch 12.04
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Trivial
Yesterday, I faced a weird bug in properties management.
For a reason, a copy of a project slipped in the project itself (like if you
had a copy of ofbiz root in ofbiz root).
And in this project a properties file (in a hotdeploy component) as the same
name than the project (like ofbiz.properties)
Then, as properties for this file, I got all the content of the sub-dir (here
would be the files in ofbiz/ofbiz) instead of the properties, something like
{code}
properties={LICENSE=, hot-deploy=, .hgignore=, themes=, rc.ofbiz.for.debian=,
ofbiz.jar=, NOTICE=, macros.xml=, .classpath=, sparta-maint4-to-trunk-qs.sh=,
common.xml=, rc.activemq.conf.for.sparta.rej=, rc.activemq.for.sparta.rej=,
sparta-stop.sh=, lib=, startofbizBoth.bat=, rc.activemq.conf.for.sparta=,
debian=, bin=, .xmlcatalog.xml=, stopofbiz.sh=, startofbiz.bat=,
rc.ofbiz.for.sparta.rej=, rc.ofbiz.for.sparta=, sparta-trunk-to-maint4-qs.sh=,
ivy.xml=, svnUpHotdeploy.bat=, applications=, runtime=, sparta.on.error.sh=,
README=, sparta-backup-prod-daily.sh=, sparta-restore-logs.sh=, startofbiz.sh=,
startofbiz.sh.rej=, sparta-restart.sh=, tools=, sparta-restart-qs.sh=,
rc.ofbiz=, stopofbiz.sh.rej=, startofbizPos.bat=, 1und1_key.pem=,
wsdspa_key.pem=, rc.activemq.for.sparta=, specialpurpose=,
sparta-backup-logs.sh=, .project=, ant=, sparta-load-data.bat=,
sparta-checkout-prod.sh=, sparta-trunk-to-maint4.sh=, clean-ofbiz-db.sh=,
ij.ofbiz=, build.xml.rej=, build.xml=, sparta-reload-data.bat=,
sparta-backup-prod.sh=, KEYS=, OPTIONAL_LIBRARIES=,
ofbiz.aptana.js.format.xml=, .svn=, framework=, ant.bat=, revert.bat=,
sparta-maint4-to-trunk.sh=, APACHE2_HEADER=, sparta-get-last-tag.sh=,
.gitignore=}
{code}
I will have a look when I will get a chance (it's a rare case), so this message
for if ever you cross the same
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Some ideas for the future of the OFBiz
OFBiz Job scheduler is performing very well on Release 11.04. Last year we have faced problem in two production system due to too much traffic and most of the scheduled service were running at MID_NIGHT. This was keeping server too much busy at that time and then we were seeing downtime once or twice in a week. To fix this problem we have rescheduled most of the service times so now all the services runs at the interval of 15 minutes. Today I did get a chance to read details available on Quartz and I think it can be better option then the existing Job Scheduler. Thanks! -- Kind Regards Ashish Vijaywargiya HotWax Media - est. 1997 ApacheCon US 2013 Gold Sponsor http://na.apachecon.com/sponsors/ On Friday 22 March 2013 12:02 PM, Jacopo Cappellato wrote: On the other hand, the OFBiz job scheduler is used a lot and so it is "tested" every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. smime.p7s Description: S/MIME Cryptographic Signature
buildbot success in ASF Buildbot on ofbiz-branch11
The Buildbot has detected a restored build on builder ofbiz-branch11 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-branch11/builds/63 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch ofbiz/branches/release11.04] 1459709 Blamelist: jleroux Build succeeded! sincerely, -The Buildbot
[jira] [Closed] (OFBIZ-5157) Error on createShoppingListItem when adding item to cart as anonymous
[ https://issues.apache.org/jira/browse/OFBIZ-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-5157. -- Resolution: Fixed > Error on createShoppingListItem when adding item to cart as anonymous > - > > Key: OFBIZ-5157 > URL: https://issues.apache.org/jira/browse/OFBIZ-5157 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 12.04 >Reporter: Mirko Vogelsmeier >Assignee: Jacques Le Roux > Fix For: Release Branch 12.04 > > Attachments: OFBIZ-5157-ShoppingListServices.patch > > > When we add items to cart as a non-logged in user (ProductStore setting > autoSaveCart on 'Y') ofbiz adds that item to ShoppingList as well. Following > security error occures: > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > UtilProperties.java:1063:INFO ] ResourceBundle MiniLangErrorUiLabels (en) > created in 0.031s with 4 properties > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > TransactionUtil.java:379:WARN ] > [java] exception report > -- > [java] [TransactionUtil.setRollbackOnly] Calling transaction > setRollbackOnly; this stack trace shows where this is happening: > [java] Exception: java.lang.Exception > [java] Message: Error in simple-method [Create a ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] stack trace > --- > [java] java.lang.Exception: Error in simple-method [Create a > ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] > org.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.java:379) > [java] > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:320) > [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:582) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:275) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:294) > [java] > org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:79) > [java] > org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:48) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:390) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:225) > [java] > org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:163) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.addBulkFromCart(ShoppingListEvents.java:167) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.fillAutoSaveList(ShoppingListEvents.java:425) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.setQuantity(ShoppingCartItem.java:1059) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:578) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:359) > [java] > org.ofbiz.order.shoppingcart.ShoppingCart.addOrIncreaseItem(ShoppingCart.java:583) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartHelper.addToCart(ShoppingCartHelper.java:246) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartEvents.addToCart(ShoppingCartEvents.java:586) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5157) Error on createShoppingListItem when adding item to cart as anonymous
[ https://issues.apache.org/jira/browse/OFBIZ-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610150#comment-13610150 ] Jacques Le Roux commented on OFBIZ-5157: Backported in R12.04 r1459698 R11.04 r1459709 R10.04 r1459715 > Error on createShoppingListItem when adding item to cart as anonymous > - > > Key: OFBIZ-5157 > URL: https://issues.apache.org/jira/browse/OFBIZ-5157 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 12.04 >Reporter: Mirko Vogelsmeier >Assignee: Jacques Le Roux > Fix For: Release Branch 12.04 > > Attachments: OFBIZ-5157-ShoppingListServices.patch > > > When we add items to cart as a non-logged in user (ProductStore setting > autoSaveCart on 'Y') ofbiz adds that item to ShoppingList as well. Following > security error occures: > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > UtilProperties.java:1063:INFO ] ResourceBundle MiniLangErrorUiLabels (en) > created in 0.031s with 4 properties > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > TransactionUtil.java:379:WARN ] > [java] exception report > -- > [java] [TransactionUtil.setRollbackOnly] Calling transaction > setRollbackOnly; this stack trace shows where this is happening: > [java] Exception: java.lang.Exception > [java] Message: Error in simple-method [Create a ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] stack trace > --- > [java] java.lang.Exception: Error in simple-method [Create a > ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] > org.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.java:379) > [java] > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:320) > [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:582) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:275) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:294) > [java] > org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:79) > [java] > org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:48) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:390) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:225) > [java] > org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:163) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.addBulkFromCart(ShoppingListEvents.java:167) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.fillAutoSaveList(ShoppingListEvents.java:425) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.setQuantity(ShoppingCartItem.java:1059) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:578) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:359) > [java] > org.ofbiz.order.shoppingcart.ShoppingCart.addOrIncreaseItem(ShoppingCart.java:583) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartHelper.addToCart(ShoppingCartHelper.java:246) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartEvents.addToCart(ShoppingCartEvents.java:586) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-5157) Error on createShoppingListItem when adding item to cart as anonymous
[ https://issues.apache.org/jira/browse/OFBIZ-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-5157: -- Assignee: Jacques Le Roux > Error on createShoppingListItem when adding item to cart as anonymous > - > > Key: OFBIZ-5157 > URL: https://issues.apache.org/jira/browse/OFBIZ-5157 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 12.04 >Reporter: Mirko Vogelsmeier >Assignee: Jacques Le Roux > Fix For: Release Branch 12.04 > > Attachments: OFBIZ-5157-ShoppingListServices.patch > > > When we add items to cart as a non-logged in user (ProductStore setting > autoSaveCart on 'Y') ofbiz adds that item to ShoppingList as well. Following > security error occures: > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > UtilProperties.java:1063:INFO ] ResourceBundle MiniLangErrorUiLabels (en) > created in 0.031s with 4 properties > [java] 2013-03-19 17:56:15,713 (http-bio-0.0.0.0-8080-exec-4) [ > TransactionUtil.java:379:WARN ] > [java] exception report > -- > [java] [TransactionUtil.setRollbackOnly] Calling transaction > setRollbackOnly; this stack trace shows where this is happening: > [java] Exception: java.lang.Exception > [java] Message: Error in simple-method [Create a ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] stack trace > --- > [java] java.lang.Exception: Error in simple-method [Create a > ShoppingList Item > [file:/D:/Workspace/ofbiz/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: > [java] > org.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.java:379) > [java] > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:320) > [java] org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:582) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:275) > [java] > org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:294) > [java] > org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:79) > [java] > org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:48) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:390) > [java] > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:225) > [java] > org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:163) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.addBulkFromCart(ShoppingListEvents.java:167) > [java] > org.ofbiz.order.shoppinglist.ShoppingListEvents.fillAutoSaveList(ShoppingListEvents.java:425) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.setQuantity(ShoppingCartItem.java:1059) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:578) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartItem.makeItem(ShoppingCartItem.java:359) > [java] > org.ofbiz.order.shoppingcart.ShoppingCart.addOrIncreaseItem(ShoppingCart.java:583) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartHelper.addToCart(ShoppingCartHelper.java:246) > [java] > org.ofbiz.order.shoppingcart.ShoppingCartEvents.addToCart(ShoppingCartEvents.java:586) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Some ideas for the future of the OFBiz
Hi Jacopo, I plenty agree on all, but the last point, where I have to review and check As you suggested for DBCP, having both for each point (ie DBCP or Atomikos, OFBiz Security or Shiro, etc.) at hand for a while would be a wise solution. I mean having both of them ready to use, not to have to get your hand dirty... Cheers Jacques From: "Jacopo Cappellato" > Hi all, > > this is just intended to brainstorm some ideas for the future OFBiz (let's > say for the 14.04 branch) and to get the community feedback... I don't have > concrete plans at the moment for most of them > > Some of the ideas below are intended to renew some core parts of the OFBiz > Framework, replacing custom code (some of getting old) with Open Source > alternatives; some of them are just cleanups. > > * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo TX > and DBCP, well... they actually can stay as optional components) with: > http://www.atomikos.com/Main/TransactionsEssentials > (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) > > * Refactor the OFBiz Security (authentication/authorization/cryptography) > with (a session I attended during ApacheCon@Portland inspired me for this): > http://shiro.apache.org > > * Replace Javolution (this has been already discussed in the past) > > * Replace the OFBiz cache system with: > http://ehcache.org > > * Replace the OFBiz job scheduler with: > http://quartz-scheduler.org > > * Reorganize the screen data preparation Groovy scripts into bigger files > with methods (they are now individual files); for example, instead of having: > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy > ... > we could have one file: > applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy > with methods: > editProductAssoc, editProductContent, editProductContentContent, > editProductFeatures... > > (note: this switch is possible since the enhancements we did one year ago); > this could make our code more readable and organized without loosing the > ability to override individual scripts from hot-deploy components; in the > process, we could also review the scripts and clean them or improve (some of > them are pretty old) > > * (in the process) we could also refactor the code of the Groovy scripts to > use the (now experimental and to be tested/expanded) DSL methods we > implemented one year ago > > Kind regards, > > Jacopo > >
Re: Some ideas for the future of the OFBiz
I also crossed issues but using something near R11.04. I believe it's better now, but did not use it in production Jacques From: "Adrian Crum" >I overhauled the Job Scheduler, so many of the problems you listed don't > exist anymore. > > -Adrian > > On 3/22/2013 6:32 AM, Jacopo Cappellato wrote: >> Hi Paul, >> >> and thank you for your feedback on Quartz. >> As regards the current job scheduler, there are a few issues that I often >> have to cope with in production, when the number of records in the >> JobSandbox grows over a certain limit (due to high load or to some failing >> job that is executed over and over); you can end up with db lock errors on >> the JobSandbox and the implementation of the service that cleans the old job >> (purgeOldJobs) is not ideal; that service also makes use of the >> ServiceSemaphore entity in order to guarantee that no more than one job at >> the time is run and I have some concerns about the reliability of this >> approach (race conditions, stale data); some interesting threads are: >> >> http://ofbiz.135035.n4.nabble.com/Replace-JobManager-with-Quartz-Scheduler-td2999416.html >> http://ofbiz.135035.n4.nabble.com/Job-Manager-td4635496.html >> http://permalink.gmane.org/gmane.comp.java.ofbiz.user/34131 >> >> On the other hand, the OFBiz job scheduler is used a lot and so it is >> "tested" every day in many production instances and, despite of some >> problems (some of them mentioned above), as you said, it just works. For >> this reason I agree that we should evaluate this (and similar other proposed >> in my first email) changes carefully before taking a decision. >> >> Kind regards, >> >> Jacopo >> >> On Mar 22, 2013, at 12:26 AM, Paul Piper wrote: >> >>> I have worked with Quartz before - it is a fantastic solution, so I'd also >>> second that opinion of implementing Quartz as a replacement for the job >>> scheduler. The only point that would speak against it, is that I haven't >>> really had any issues with the current scheduler, so a replacement may not >>> be necessary and should be discussed whether it is a worthwhile venture. >>> >>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >
Re: Some ideas for the future of the OFBiz
+1 Jacques From: "Jacopo Cappellato" > we could also add to the list: > > * Java 7 > > Jacopo > > > On Mar 22, 2013, at 3:43 AM, hongs bill wrote: > >> +1 >> >> add workflow engine,such as jBPM or Activiti . >> >> >> -- >> I am hongs >
Re: Some ideas for the future of the OFBiz
I overhauled the Job Scheduler, so many of the problems you listed don't exist anymore. -Adrian On 3/22/2013 6:32 AM, Jacopo Cappellato wrote: Hi Paul, and thank you for your feedback on Quartz. As regards the current job scheduler, there are a few issues that I often have to cope with in production, when the number of records in the JobSandbox grows over a certain limit (due to high load or to some failing job that is executed over and over); you can end up with db lock errors on the JobSandbox and the implementation of the service that cleans the old job (purgeOldJobs) is not ideal; that service also makes use of the ServiceSemaphore entity in order to guarantee that no more than one job at the time is run and I have some concerns about the reliability of this approach (race conditions, stale data); some interesting threads are: http://ofbiz.135035.n4.nabble.com/Replace-JobManager-with-Quartz-Scheduler-td2999416.html http://ofbiz.135035.n4.nabble.com/Job-Manager-td4635496.html http://permalink.gmane.org/gmane.comp.java.ofbiz.user/34131 On the other hand, the OFBiz job scheduler is used a lot and so it is "tested" every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. Kind regards, Jacopo On Mar 22, 2013, at 12:26 AM, Paul Piper wrote: I have worked with Quartz before - it is a fantastic solution, so I'd also second that opinion of implementing Quartz as a replacement for the job scheduler. The only point that would speak against it, is that I haven't really had any issues with the current scheduler, so a replacement may not be necessary and should be discussed whether it is a worthwhile venture. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
we could also add to the list: * Java 7 Jacopo On Mar 22, 2013, at 3:43 AM, hongs bill wrote: > +1 > > add workflow engine,such as jBPM or Activiti . > > > -- > I am hongs
