Re: jackrabbit test cases failing?
Thanks guys, is fixed. Lessen learned: never rely on the internal eclipse build when running unit tests within eclipse :-) 2012/4/19 Hans Bakker mailingl...@antwebsystems.com: Yes, I confirm, they do fail (Welcome back Adam!) On 04/19/2012 02:08 AM, Adam Heath wrote: See attached file. -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: svn commit: r1327835 - in /ofbiz/trunk/framework: jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java widget/src/org/ofbiz/widget/WidgetWorker.java
Hi Sascha,
is this the right way to fix the test?
Jacopo
On Apr 19, 2012, at 7:58 AM, sascharodek...@apache.org wrote:
Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
(original)
+++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java Thu
Apr 19 05:58:29 2012
@@ -379,10 +379,14 @@ public class WidgetWorker {
returnValue = df.format((java.util.Date) retVal);
} else {
try {
-returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(UTF-8).displayName());
+returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(ISO-8859-1).displayName());
} catch (UnsupportedEncodingException e) {
Debug.logError(e, module);
}
+
+//StringUtil.SimpleEncoder simpleEncoder =
(StringUtil.SimpleEncoder) context.get(simpleEncoder);
+//returnValue = simpleEncoder.encode(retVal.toString());
+
}
return returnValue;
} else {
Re: Mini-language Overhaul, Part 2
On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting patches. Jacopo On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote: Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk? This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go. Jacopo On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote: I am still working on the Mini-language Reference page: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes. Here is what I would like to do before creation of the next release branch (in sequence): 1. Reformat all Mini-language Java code. This would be a single, separate commit. 2. Get developer community approval of the Attribute Types reference section, the set element section, and the deprecated items marked in red. 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference. 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way. 5. Update the set element Java code and schema to match the reference. The changes to the set element are the most important and they will have the biggest impact on Mini-language code. The updated set element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code. I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done. So, please take a few minutes to review the Attribute Types reference section and the set element section and let me know if you see any problems with them. -Adrian
ant build if failing since 8.25 CET
Hi all, Running ./ant build after an ./ant clean-all on trunk at 8:25 CET failed with messages: [javac16] Compiling 35 source files to /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/build/classes [javac16] /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/api/jackrabbit/JackrabbitFileHelper.java:25: cannot find symbol [javac16] symbol : class JcrUtilJackrabbit [javac16] location: package org.ofbiz.jcr.util.jackrabbit [javac16] import org.ofbiz.jcr.util.jackrabbit.JcrUtilJackrabbit; [javac16] ^ [javac16] /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/api/jackrabbit/JackrabbitFileHelper.java:123: cannot find symbol [javac16] symbol : variable JcrUtilJackrabbit [javac16] location: class org.ofbiz.jcr.api.jackrabbit.JackrabbitFileHelper [javac16] folderPath = JcrUtilJackrabbit.createAbsoluteNodePath(folderPath); [javac16] ^ [javac16] Note: /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/loader/RepositoryFactory.java uses unchecked or unsafe operations. [javac16] Note: Recompile with -Xlint:unchecked for details. [javac16] 2 errors BUILD FAILED /Users/s0001/Documents/workspace/ofbiz-trunk-base/build.xml:214: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/build.xml:148: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/macros.xml:39: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/common.xml:91: Compile failed; see the compiler error output for details. I ran it after I got the latest revisions from trunk. Regards, Pierre
Re: svn commit: r1327835 - in /ofbiz/trunk/framework: jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java widget/src/org/ofbiz/widget/WidgetWorker.java
Hi Jacopo, year right, ups. The Widget Worker sneaked in the commit list ;-)
2012/4/19 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
Hi Sascha,
is this the right way to fix the test?
Jacopo
On Apr 19, 2012, at 7:58 AM, sascharodek...@apache.org wrote:
Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
(original)
+++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java Thu
Apr 19 05:58:29 2012
@@ -379,10 +379,14 @@ public class WidgetWorker {
returnValue = df.format((java.util.Date) retVal);
} else {
try {
- returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(UTF-8).displayName());
+ returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(ISO-8859-1).displayName());
} catch (UnsupportedEncodingException e) {
Debug.logError(e, module);
}
+
+ //StringUtil.SimpleEncoder simpleEncoder =
(StringUtil.SimpleEncoder) context.get(simpleEncoder);
+ //returnValue = simpleEncoder.encode(retVal.toString());
+
}
return returnValue;
} else {
--
Sascha Rodekamp
Visit the new german OFBiz Blog: http://www.ofbiz.biz
Lynx-Consulting GmbH
Johanniskirchplatz 6
D-33615 Bielefeld
http://www.lynx.de
Re: ant build if failing since 8.25 CET
After doing another update from trunk at 8:45 CET ./ant build resumed normal working (build successful) conditions. Op 19 april 2012 08:31 schreef Pierre Smits pierre.sm...@gmail.com het volgende: Hi all, Running ./ant build after an ./ant clean-all on trunk at 8:25 CET failed with messages: [javac16] Compiling 35 source files to /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/build/classes [javac16] /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/api/jackrabbit/JackrabbitFileHelper.java:25: cannot find symbol [javac16] symbol : class JcrUtilJackrabbit [javac16] location: package org.ofbiz.jcr.util.jackrabbit [javac16] import org.ofbiz.jcr.util.jackrabbit.JcrUtilJackrabbit; [javac16] ^ [javac16] /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/api/jackrabbit/JackrabbitFileHelper.java:123: cannot find symbol [javac16] symbol : variable JcrUtilJackrabbit [javac16] location: class org.ofbiz.jcr.api.jackrabbit.JackrabbitFileHelper [javac16] folderPath = JcrUtilJackrabbit.createAbsoluteNodePath(folderPath); [javac16] ^ [javac16] Note: /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/jcr/src/org/ofbiz/jcr/loader/RepositoryFactory.java uses unchecked or unsafe operations. [javac16] Note: Recompile with -Xlint:unchecked for details. [javac16] 2 errors BUILD FAILED /Users/s0001/Documents/workspace/ofbiz-trunk-base/build.xml:214: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/framework/build.xml:148: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/macros.xml:39: The following error occurred while executing this line: /Users/s0001/Documents/workspace/ofbiz-trunk-base/common.xml:91: Compile failed; see the compiler error output for details. I ran it after I got the latest revisions from trunk. Regards, Pierre
Re: svn commit: r1327411 - in /ofbiz/trunk: bin/ tools/functions.sh tools/git-rebase-runner.sh
On Apr 18, 2012, at 6:55 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 6:43 PM, Adam Heath wrote: It currently takes my desktop 1 hour to run a full test suite. clean, load-demo(30m), run-tests(30m). It used to take 12-15m. wow, it takes me 2-3 minutes in my laptop. Jacopo To be more precise: (less than) 3 minutes for load-demo 4 minutes and 3 seconds for run-tests Jacopo
Upgrading Freemarker in our release branches
Hi all, there are a few interesting bug fixes and performance improvements between Freemarker 2.3.10, currently used in our release branches, and 2.3.19, currently used in trunk. Is it ok if I upgrade 10.04 and 11.04to use freemarker-2.3.19.jar? Kind regards, Jacopo
HashCrypt is deprecated: is this an issue?
When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
Re: Upgrading Freemarker in our release branches
Hi Jacopo, Does the upgrade fix any bugs currently in r10.04 or r11.04? If not, don't do, otherwise all kinds of improvements are wanted to get in. Regards, Pierre Op 19 april 2012 09:05 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi all, there are a few interesting bug fixes and performance improvements between Freemarker 2.3.10, currently used in our release branches, and 2.3.19, currently used in trunk. Is it ok if I upgrade 10.04 and 11.04to use freemarker-2.3.19.jar? Kind regards, Jacopo
Re: svn commit: r1327411 - in /ofbiz/trunk: bin/ tools/functions.sh tools/git-rebase-runner.sh
OK seems after all that I need a brand new CPU, hence a new box... I must say with the SSDs when running run-tests my CPU is always at 100% (I put the run-tests process priority level to idle to be able to continue other tasks) Do you have a SSD in your laptop Jacopo? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 18, 2012, at 6:55 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 6:43 PM, Adam Heath wrote: It currently takes my desktop 1 hour to run a full test suite. clean, load-demo(30m), run-tests(30m). It used to take 12-15m. wow, it takes me 2-3 minutes in my laptop. Jacopo To be more precise: (less than) 3 minutes for load-demo 4 minutes and 3 seconds for run-tests Jacopo
Re: Upgrading Freemarker in our release branches
+0 As long as it's has been sufficiently tested I see no pb Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi all, there are a few interesting bug fixes and performance improvements between Freemarker 2.3.10, currently used in our release branches, and 2.3.19, currently used in trunk. Is it ok if I upgrade 10.04 and 11.04to use freemarker-2.3.19.jar? Kind regards, Jacopo
Re: Upgrading Freemarker in our release branches
I checked at the FreeMarker release, the new version is able to handle concurrent access of templates in multithreading environment. Which in turn gives significant performance improvement. So from my side Big +1 for upgrading the jars on release. Thanks! -- Rishi Solanki Manager, Enterprise Software Development HotWax Media Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxmedia.com On Thu, Apr 19, 2012 at 1:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: +0 As long as it's has been sufficiently tested I see no pb Jacques From: Jacopo Cappellato jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com Hi all, there are a few interesting bug fixes and performance improvements between Freemarker 2.3.10, currently used in our release branches, and 2.3.19, currently used in trunk. Is it ok if I upgrade 10.04 and 11.04to use freemarker-2.3.19.jar? Kind regards, Jacopo
[jira] [Created] (OFBIZ-4823) DEMO users can'l login anymore
DEMO users can'l login anymore
--
Key: OFBIZ-4823
URL: https://issues.apache.org/jira/browse/OFBIZ-4823
Project: OFBiz
Issue Type: Bug
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Pierre Smits
Priority: Blocker
Fix For: SVN trunk
With r1327736 passwords for various demo userids have changed from:
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
to:
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709
Hence no demo user can login.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1327411 - in /ofbiz/trunk: bin/ tools/functions.sh tools/git-rebase-runner.sh
Jacques, here are some details: Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro8,2 Processor Name: Intel Core i7 Processor Speed: 2.2 GHz Number of Processors: 1 Total Number of Cores:4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 8 GB HD details are: Intel 6 Series Chipset: Vendor: Intel Product: 6 Series Chipset Link Speed: 6 Gigabit Negotiated Link Speed:3 Gigabit Description: AHCI Version 1.30 Supported Hitachi HTS725050A9A362: Capacity: 500.11 GB (500,107,862,016 bytes) Model:Hitachi HTS725050A9A362 Queue Depth: 32 Rotational Rate: 7200 Jacopo On Apr 19, 2012, at 9:58 AM, Jacques Le Roux wrote: OK seems after all that I need a brand new CPU, hence a new box... I must say with the SSDs when running run-tests my CPU is always at 100% (I put the run-tests process priority level to idle to be able to continue other tasks) Do you have a SSD in your laptop Jacopo? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 18, 2012, at 6:55 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 6:43 PM, Adam Heath wrote: It currently takes my desktop 1 hour to run a full test suite. clean, load-demo(30m), run-tests(30m). It used to take 12-15m. wow, it takes me 2-3 minutes in my laptop. Jacopo To be more precise: (less than) 3 minutes for load-demo 4 minutes and 3 seconds for run-tests Jacopo
[jira] [Updated] (OFBIZ-4823) DEMO users can'l login anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits updated OFBIZ-4823:
Attachment: OFBIZ -4823-DEMO-passwords.patch
This patch resets the passwords of various demo users to its original
DEMO users can'l login anymore
--
Key: OFBIZ-4823
URL: https://issues.apache.org/jira/browse/OFBIZ-4823
Project: OFBiz
Issue Type: Bug
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Pierre Smits
Priority: Blocker
Fix For: SVN trunk
Attachments: OFBIZ -4823-DEMO-passwords.patch
With r1327736 passwords for various demo userids have changed from:
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
to:
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709
Hence no demo user can login.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Upgrading Freemarker in our release branches
until we haven't any related issues which are caused by the update +1 from me. There are really a few helpful bugfixes in the release. 2012/4/19 Rishi Solanki rishisolan...@gmail.com: I checked at the FreeMarker release, the new version is able to handle concurrent access of templates in multithreading environment. Which in turn gives significant performance improvement. So from my side Big +1 for upgrading the jars on release. Thanks! -- Rishi Solanki Manager, Enterprise Software Development HotWax Media Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxmedia.com On Thu, Apr 19, 2012 at 1:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: +0 As long as it's has been sufficiently tested I see no pb Jacques From: Jacopo Cappellato jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com Hi all, there are a few interesting bug fixes and performance improvements between Freemarker 2.3.10, currently used in our release branches, and 2.3.19, currently used in trunk. Is it ok if I upgrade 10.04 and 11.04to use freemarker-2.3.19.jar? Kind regards, Jacopo -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
[jira] [Assigned] (OFBIZ-4823) DEMO users can'l login anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato reassigned OFBIZ-4823:
Assignee: Jacopo Cappellato
DEMO users can'l login anymore
--
Key: OFBIZ-4823
URL: https://issues.apache.org/jira/browse/OFBIZ-4823
Project: OFBiz
Issue Type: Bug
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Pierre Smits
Assignee: Jacopo Cappellato
Priority: Blocker
Fix For: SVN trunk
Attachments: OFBIZ -4823-DEMO-passwords.patch
With r1327736 passwords for various demo userids have changed from:
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
to:
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709
Hence no demo user can login.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4823) DEMO users can'l login anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato closed OFBIZ-4823.
DEMO users can'l login anymore
--
Key: OFBIZ-4823
URL: https://issues.apache.org/jira/browse/OFBIZ-4823
Project: OFBiz
Issue Type: Bug
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Pierre Smits
Assignee: Jacopo Cappellato
Priority: Blocker
Fix For: SVN trunk
Attachments: OFBIZ -4823-DEMO-passwords.patch
With r1327736 passwords for various demo userids have changed from:
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
to:
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709
Hence no demo user can login.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: HashCrypt is deprecated: is this an issue?
No, those are deprecations that were introduced in a recent commit. Most likely the warnings will be fixed in a future commit. -Adrian On 4/19/2012 8:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
Re: HashCrypt is deprecated: is this an issue?
So a JIRA would be in order? Op 19 april 2012 11:14 schreef Adrian Crum adrian.c...@sandglass-software.com het volgende: No, those are deprecations that were introduced in a recent commit. Most likely the warnings will be fixed in a future commit. -Adrian On 4/19/2012 8:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/**build/classes [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/** GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(** encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode**(java.lang.String,java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.**getDigestHashOldFunnyHexEncode**(originalKeyName, null) : HashCrypt.getDigestHash(**originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.**getDigestHashOldFunnyHexEncode**(originalKeyName, null) : HashCrypt.getDigestHash(**originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
Re: HashCrypt is deprecated: is this an issue?
Yes. Just a guess: Fixing the deprecations might fix the demo user login problem experienced recently. -Adrian On 4/19/2012 10:27 AM, Pierre Smits wrote: So a JIRA would be in order? Op 19 april 2012 11:14 schreef Adrian Crum adrian.c...@sandglass-software.com het volgende: No, those are deprecations that were introduced in a recent commit. Most likely the warnings will be fixed in a future commit. -Adrian On 4/19/2012 8:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/**build/classes [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/** GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(** encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode**(java.lang.String,java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.**getDigestHashOldFunnyHexEncode**(originalKeyName, null) : HashCrypt.getDigestHash(**originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/**src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.**String) in org.ofbiz.base.crypto.**HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.**getDigestHashOldFunnyHexEncode**(originalKeyName, null) : HashCrypt.getDigestHash(**originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
Re: HashCrypt is deprecated: is this an issue?
Ok. Will do. Op 19 april 2012 11:30 schreef Adrian Crum adrian.c...@sandglass-software.com het volgende: Yes. Just a guess: Fixing the deprecations might fix the demo user login problem experienced recently. -Adrian On 4/19/2012 10:27 AM, Pierre Smits wrote: So a JIRA would be in order? Op 19 april 2012 11:14 schreef Adrian Crum adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com het volgende: No, those are deprecations that were introduced in a recent commit. Most likely the warnings will be fixed in a future commit. -Adrian On 4/19/2012 8:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/** GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(** encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
[jira] [Created] (OFBIZ-4824) Deprecated use of org.ofbiz.base.crypto.HashCrypt
Deprecated use of org.ofbiz.base.crypto.HashCrypt - Key: OFBIZ-4824 URL: https://issues.apache.org/jira/browse/OFBIZ-4824 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Fix For: SVN trunk Hash classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Mini-language Overhaul, Part 2
Yes trunk is the bleeding edge anyway... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting patches. Jacopo On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote: Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk? This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go. Jacopo On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote: I am still working on the Mini-language Reference page: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes. Here is what I would like to do before creation of the next release branch (in sequence): 1. Reformat all Mini-language Java code. This would be a single, separate commit. 2. Get developer community approval of the Attribute Types reference section, the set element section, and the deprecated items marked in red. 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference. 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way. 5. Update the set element Java code and schema to match the reference. The changes to the set element are the most important and they will have the biggest impact on Mini-language code. The updated set element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code. I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done. So, please take a few minutes to review the Attribute Types reference section and the set element section and let me know if you see any problems with them. -Adrian
[jira] [Created] (OFBIZ-4826) Release branch doesn't test in Jenkins
Release branch doesn't test in Jenkins -- Key: OFBIZ-4826 URL: https://issues.apache.org/jira/browse/OFBIZ-4826 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4825) Release branch doesn't test in Jenkins
Release branch doesn't test in Jenkins -- Key: OFBIZ-4825 URL: https://issues.apache.org/jira/browse/OFBIZ-4825 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4827) Release branch doesn't test in Jenkins
Release branch doesn't test in Jenkins -- Key: OFBIZ-4827 URL: https://issues.apache.org/jira/browse/OFBIZ-4827 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4827) Release branch doesn't test in Jenkins
[ https://issues.apache.org/jira/browse/OFBIZ-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-4827: Attachment: OFBIZ-4827-r1104-testport.patch This patch fixes the issue Release branch doesn't test in Jenkins -- Key: OFBIZ-4827 URL: https://issues.apache.org/jira/browse/OFBIZ-4827 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 Attachments: OFBIZ-4827-r1104-testport.patch Original Estimate: 0.5h Remaining Estimate: 0.5h As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: HashCrypt is deprecated: is this an issue?
I wanted to review the related commits, but did not get enough time. I 'm interested because of https://issues.apache.org/jira/browse/OFBIZ-1151 https://issues.apache.org/jira/browse/OFBIZ-2729 https://issues.apache.org/jira/browse/OFBIZ-3006 Jacques From: Pierre Smits pierre.sm...@gmail.com Ok. Will do. Op 19 april 2012 11:30 schreef Adrian Crum adrian.c...@sandglass-software.com het volgende: Yes. Just a guess: Fixing the deprecations might fix the demo user login problem experienced recently. -Adrian On 4/19/2012 10:27 AM, Pierre Smits wrote: So a JIRA would be in order? Op 19 april 2012 11:14 schreef Adrian Crum adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com het volgende: No, those are deprecations that were introduced in a recent commit. Most likely the warnings will be fixed in a future commit. -Adrian On 4/19/2012 8:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/** GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(** encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/** EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Regards, Pierre
[jira] [Closed] (OFBIZ-4825) Release branch doesn't test in Jenkins
[ https://issues.apache.org/jira/browse/OFBIZ-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed OFBIZ-4825. --- Resolution: Fixed My apologies. Something went wrong when creating the issue Release branch doesn't test in Jenkins -- Key: OFBIZ-4825 URL: https://issues.apache.org/jira/browse/OFBIZ-4825 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 Original Estimate: 0.5h Remaining Estimate: 0.5h As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4826) Release branch doesn't test in Jenkins
[ https://issues.apache.org/jira/browse/OFBIZ-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed OFBIZ-4826. --- Resolution: Fixed My apologies. Something went wrong when creating the issue Release branch doesn't test in Jenkins -- Key: OFBIZ-4826 URL: https://issues.apache.org/jira/browse/OFBIZ-4826 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, Release 11.04.01 Reporter: Pierre Smits Priority: Critical Fix For: Release 11.04.01 Original Estimate: 0.5h Remaining Estimate: 0.5h As with trunk was, R11.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4828) R10.04 testports in use when testing in CI (Jenkins)
R10.04 testports in use when testing in CI (Jenkins) Key: OFBIZ-4828 URL: https://issues.apache.org/jira/browse/OFBIZ-4828 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release 10.04, Release Branch 10.04 Reporter: Pierre Smits Fix For: Release Branch 10.04, Release 10.04 As with trunk was, R10.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4828) R10.04 testports in use when testing in CI (Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-4828: Attachment: OFBIZ-4828-r10.04-testports.patch This patch fixes the issue R10.04 testports in use when testing in CI (Jenkins) Key: OFBIZ-4828 URL: https://issues.apache.org/jira/browse/OFBIZ-4828 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 10.04, Release 10.04 Reporter: Pierre Smits Fix For: Release Branch 10.04, Release 10.04 Attachments: OFBIZ-4828-r10.04-testports.patch Original Estimate: 0.5h Remaining Estimate: 0.5h As with trunk was, R10.04 doesn't test in CI (Jenkins) as ports are already in use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4829) Missing decorator location in ExampleExt component:
Missing decorator location in ExampleExt component: --- Key: OFBIZ-4829 URL: https://issues.apache.org/jira/browse/OFBIZ-4829 Project: OFBiz Issue Type: Bug Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk Reporter: yashwant dhakad Priority: Trivial Missing following decorator location in ExampleExt component: 1. CommonExampleGeoLocationDecorator. 2. CommonExampleOsmGeoLocationDecorator. 3. CommonBirtDecorator. 4. CommonExampleChartsDecorator. 5. CommonExampleJackrabbitDecorator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4829) Missing decorator location in ExampleExt component:
[ https://issues.apache.org/jira/browse/OFBIZ-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yashwant dhakad updated OFBIZ-4829: --- Fix Version/s: Release 10.04 SVN trunk Release Branch 11.04 Missing decorator location in ExampleExt component: --- Key: OFBIZ-4829 URL: https://issues.apache.org/jira/browse/OFBIZ-4829 Project: OFBiz Issue Type: Bug Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk Reporter: yashwant dhakad Priority: Trivial Fix For: Release 10.04, Release Branch 11.04, SVN trunk Missing following decorator location in ExampleExt component: 1. CommonExampleGeoLocationDecorator. 2. CommonExampleOsmGeoLocationDecorator. 3. CommonBirtDecorator. 4. CommonExampleChartsDecorator. 5. CommonExampleJackrabbitDecorator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4829) Missing decorator location in ExampleExt component:
[ https://issues.apache.org/jira/browse/OFBIZ-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yashwant dhakad updated OFBIZ-4829: --- Attachment: OFBIZ-4829-10.04.patch OFBIZ-4829-11.04.patch OFBIZ-4829-Trunk.patch Missing decorator location in ExampleExt component: --- Key: OFBIZ-4829 URL: https://issues.apache.org/jira/browse/OFBIZ-4829 Project: OFBiz Issue Type: Bug Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk Reporter: yashwant dhakad Priority: Trivial Fix For: Release 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-4829-10.04.patch, OFBIZ-4829-11.04.patch, OFBIZ-4829-Trunk.patch Missing following decorator location in ExampleExt component: 1. CommonExampleGeoLocationDecorator. 2. CommonExampleOsmGeoLocationDecorator. 3. CommonBirtDecorator. 4. CommonExampleChartsDecorator. 5. CommonExampleJackrabbitDecorator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4829) Missing decorator location in ExampleExt component:
[ https://issues.apache.org/jira/browse/OFBIZ-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257425#comment-13257425 ] yashwant dhakad commented on OFBIZ-4829: Here is the patch for the issue. Missing decorator location in ExampleExt component: --- Key: OFBIZ-4829 URL: https://issues.apache.org/jira/browse/OFBIZ-4829 Project: OFBiz Issue Type: Bug Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk Reporter: yashwant dhakad Priority: Trivial Fix For: Release 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-4829-10.04.patch, OFBIZ-4829-11.04.patch, OFBIZ-4829-Trunk.patch Missing following decorator location in ExampleExt component: 1. CommonExampleGeoLocationDecorator. 2. CommonExampleOsmGeoLocationDecorator. 3. CommonBirtDecorator. 4. CommonExampleChartsDecorator. 5. CommonExampleJackrabbitDecorator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Mini-language Overhaul, Part 2
That is correct - if I make the non-functional changes before the release branch is created, then future trunk fixes will be easier to backport to the release branch. A separate fix will be needed for versions prior to 12.x. -Adrian On 4/19/2012 7:29 AM, Jacopo Cappellato wrote: On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting patches. Jacopo On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote: Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk? This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go. Jacopo On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote: I am still working on the Mini-language Reference page: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes. Here is what I would like to do before creation of the next release branch (in sequence): 1. Reformat all Mini-language Java code. This would be a single, separate commit. 2. Get developer community approval of the Attribute Types reference section, theset element section, and the deprecated items marked in red. 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference. 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way. 5. Update theset element Java code and schema to match the reference. The changes to theset element are the most important and they will have the biggest impact on Mini-language code. The updatedset element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code. I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done. So, please take a few minutes to review the Attribute Types reference section and theset element section and let me know if you see any problems with them. -Adrian
Re: svn commit: r1327735 - in /ofbiz/trunk/framework/entity/src/org/ofbiz/entity: jdbc/SqlJdbcUtil.java model/ModelViewEntity.java
On 04/18/2012 09:14 PM, Scott Gray wrote:
Nice, I ran into a problem related to this very recently. Thanks for taking
care of it.
view-entity
member-entity entity-name=Foo
view-entity
view-entity entity-name=Foo
member-entity alias=A entity-name=Bar
member-entity alias=B entity-name=Baz
view-link entity-alias=A rel-entity-alias=B
view-condition/
/view-link
/view-entity
entity entity-name=Bar/
view-entity entity-name=Baz
view-condition/
/view-entity
This now works.
Regards
Scott
On 19/04/2012, at 11:48 AM, doo...@apache.org wrote:
Author: doogie
Date: Wed Apr 18 23:48:40 2012
New Revision: 1327735
URL: http://svn.apache.org/viewvc?rev=1327735view=rev
Log:
FEATURE/FIX: entity-condition on views are now done correctly. When a
view was previously joined to another view, the conditions on the inner
view were added to the outer-most WHERE clause. This caused multiple
problems. One, if the join was optional, the generated sql actually made
it required(because it was in the WHERE, and not in the ON clause).
Second, the outer WHERE may reference a field that was not available *at
all* in the generated nested select(view table).
The fix is to *not* recurse thru all view member entities when finding
conditions, and instead attach them to a new WHERE clause on the
generated inner SELECT(view table).
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelViewEntity.java
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java?rev=1327735r1=1327734r2=1327735view=diff
==
--- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java
(original)
+++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java
Wed Apr 18 23:48:40 2012
@@ -40,6 +40,7 @@ import java.util.TreeSet;
import javax.sql.rowset.serial.SerialBlob;
import javax.sql.rowset.serial.SerialClob;
+import javolution.util.FastList;
import javolution.util.FastMap;
import org.ofbiz.base.util.Debug;
@@ -54,6 +55,7 @@ import org.ofbiz.entity.GenericNotImplem
import org.ofbiz.entity.GenericValue;
import org.ofbiz.entity.condition.EntityCondition;
import org.ofbiz.entity.condition.EntityConditionParam;
+import org.ofbiz.entity.condition.EntityOperator;
import org.ofbiz.entity.condition.OrderByList;
import org.ofbiz.entity.config.DatasourceInfo;
import org.ofbiz.entity.jdbc.JdbcValueHandler;
@@ -420,11 +422,31 @@ public class SqlJdbcUtil {
}
sql.append(makeFromClause(modelEntity, modelFieldTypeReader,
datasourceInfo));
String viewWhereClause = makeViewWhereClause(modelEntity,
datasourceInfo.joinStyle);
-if (UtilValidate.isNotEmpty(viewWhereClause)) {
+ModelViewEntity modelViewEntity = (ModelViewEntity)modelEntity;
+ListEntityCondition whereConditions = FastList.newInstance();
+ListEntityCondition havingConditions = FastList.newInstance();
+ListString orderByList = FastList.newInstance();
+
+
modelViewEntity.populateViewEntityConditionInformation(modelFieldTypeReader,
whereConditions, havingConditions, orderByList, null);
+String viewConditionClause;
+if (!whereConditions.isEmpty()) {
+viewConditionClause =
EntityCondition.makeCondition(whereConditions,
EntityOperator.AND).makeWhereString(modelViewEntity, null, datasourceInfo);
+} else {
+viewConditionClause = null;
+}
+if (UtilValidate.isNotEmpty(viewWhereClause) ||
UtilValidate.isNotEmpty(viewConditionClause)) {
sql.append( WHERE );
-sql.append(viewWhereClause);
+if (UtilValidate.isNotEmpty(viewWhereClause)) {
+sql.append(().append(viewWhereClause).append());
+if (UtilValidate.isNotEmpty(viewConditionClause)) {
+sql.append( AND );
+}
+}
+if (UtilValidate.isNotEmpty(viewConditionClause)) {
+sql.append(().append(viewConditionClause).append());
+}
}
-ModelViewEntity modelViewEntity = (ModelViewEntity)modelEntity;
+// FIXME: handling HAVING, don't need ORDER BY for nested views
modelViewEntity.colNameString(modelViewEntity.getGroupBysCopy(),
sql, GROUP BY , , , , false);
sql.append());
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelViewEntity.java
URL:
[jira] [Assigned] (OFBIZ-4622) Avoiding confusion of 'Vendor' and 'Supplier' in the German locale translations
[ https://issues.apache.org/jira/browse/OFBIZ-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Geisert reassigned OFBIZ-4622: Assignee: Christian Geisert Avoiding confusion of 'Vendor' and 'Supplier' in the German locale translations --- Key: OFBIZ-4622 URL: https://issues.apache.org/jira/browse/OFBIZ-4622 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Release 09.04, Release 10.04 Environment: irrelevant, this is about XML label files Reporter: Carsten Schinzer Assignee: Christian Geisert Labels: i18n, label, locale:de, locale:de_DE Fix For: Release Branch 10.04, SVN trunk Attachments: 0001-Replace-Lieferant-with-more-commonly-used-Verkaeufer.patch Original Estimate: 2h Remaining Estimate: 2h On the user mailing list, the concepts of 'vendor' vs. 'supplier' were discussed and as a matter of fact, many labels in the German translation files of OFBiz are pointing to the term 'Lieferant' for both, especially the role select-boxes in the Party Manager application. As this is confusing and sharper terms can be found and defined in German for these two roles as well, this Issue will track the implementation of such 'sharpened' working in the translation files of all applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1327411 - in /ofbiz/trunk: bin/ tools/functions.sh tools/git-rebase-runner.sh
On 04/18/2012 11:33 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 7:37 PM, Adam Heath wrote: On 04/18/2012 12:28 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 7:20 PM, Adam Heath wrote: ps: I am going to switch if in ant *back* to javascript, *away* from ant-contrib. The latter is significantly slower when using a system installed ant. No please, don't do that. I've pointed out a problem, and I have a solution. Don't just respond saying don't do that, without a reason. That isn't enough to stop me. I thought that all the recent threads about code refactoring, moving out custom code etc... were enough to motivate my response; but it seems that you ignored all of them and now pretend a response from me, for such a trivial and small topic. The reason is that we want to keep code as clean as possible, as slim as possible (ok, I know it looks silly if you look at the code now... but we are determined to work on this): using an external tool for this instead of custom code is a step in this direction. The stats below show that the problem is trivial: it is only relevant when you use your own ant that is not what we recommend; and it is something that should be fixed with the ant community: in fact we want to increase the cooperation with other communities (especially if they are in the ASF world) rather than blobbing everything into OFBiz. I didn't ignore them all, I've been away and haven't had time to keep uptodate. I haven't committed anything for this yet, once you said you had issues with the switch. I have 130 commits in my local ofbiz tree, keeping some out is *not* a problem (for instance, that salted-based password change I've kept around for about 2 years). This explanation is a *good* one. And yes, I do realize that the problem is with ant, even system level shouldn't be running as slow as it is.
Re: svn commit: r1327835 - in /ofbiz/trunk/framework: jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java widget/src/org/ofbiz/widget/WidgetWorker.java
On 04/19/2012 12:58 AM, sascharodek...@apache.org wrote:
Author: sascharodekamp
Date: Thu Apr 19 05:58:29 2012
New Revision: 1327835
URL: http://svn.apache.org/viewvc?rev=1327835view=rev
Log:
Fix jackrabbit unit testing.
Modified:
ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
Modified:
ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
(original)
+++ ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java Thu
Apr 19 05:58:29 2012
@@ -18,18 +18,13 @@ under the License.
*/
package org.ofbiz.jcr.test;
-import java.io.File;
-import java.io.FileInputStream;
-import java.io.InputStream;
import java.util.GregorianCalendar;
-import java.util.List;
import java.util.Map;
import javax.jcr.ItemExistsException;
import javax.jcr.PathNotFoundException;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
-import javax.jcr.query.QueryResult;
import javolution.util.FastMap;
import net.sf.json.JSONArray;
@@ -46,9 +41,7 @@ import org.ofbiz.jcr.access.JcrRepositor
import org.ofbiz.jcr.access.jackrabbit.ContentWriterJackrabbit;
import org.ofbiz.jcr.access.jackrabbit.JackrabbitRepositoryAccessor;
import org.ofbiz.jcr.api.JcrDataHelper;
-import org.ofbiz.jcr.api.JcrFileHelper;
import org.ofbiz.jcr.api.jackrabbit.JackrabbitArticleHelper;
-import org.ofbiz.jcr.api.jackrabbit.JackrabbitFileHelper;
import org.ofbiz.jcr.loader.JCRFactory;
import org.ofbiz.jcr.loader.JCRFactoryUtil;
import org.ofbiz.jcr.loader.jackrabbit.JCRFactoryImpl;
This change doesn't fix the unit testing. It should be a separate commit.
Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
(original)
+++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java Thu
Apr 19 05:58:29 2012
@@ -379,10 +379,14 @@ public class WidgetWorker {
returnValue = df.format((java.util.Date) retVal);
} else {
try {
-returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(UTF-8).displayName());
+returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(ISO-8859-1).displayName());
Er, that can't be right.
} catch (UnsupportedEncodingException e) {
Debug.logError(e, module);
}
+
+//StringUtil.SimpleEncoder simpleEncoder =
(StringUtil.SimpleEncoder) context.get(simpleEncoder);
+//returnValue = simpleEncoder.encode(retVal.toString());
+
Why did you check this in?
}
return returnValue;
} else {
[jira] [Closed] (OFBIZ-4768) Improvement for flatgrey theme
[ https://issues.apache.org/jira/browse/OFBIZ-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wai closed OFBIZ-4768. -- Resolution: Won't Fix Improvement for flatgrey theme -- Key: OFBIZ-4768 URL: https://issues.apache.org/jira/browse/OFBIZ-4768 Project: OFBiz Issue Type: Improvement Components: themes Reporter: Wai Priority: Trivial Attachments: after-sample-catalogmgr1.png, after-sample-catalogmgr1.png, after-sample-catalogmgr2.png, after-sample-catalogmgr2.png, after-sample-partymgr.png, after-sample-partymgr.png, after-sample-webtools.png, after-sample-webtools.png, before-sample-catalogmgr1.png, before-sample-catalogmgr2.png, before-sample-partymgr.png, before-sample-webtools.png, flatgray-images.tar.gz, ofbiz-4768.patch, ofbiz-4768.patch, ofbiz-style1.patch, ofbiz-style1.patch, ofbiz-style2.patch, ofbiz-style2.patch Improvement to flatgrey theme. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: HashCrypt is deprecated: is this an issue?
On 04/19/2012 02:06 AM, Pierre Smits wrote: When building the trunk I get (amonst others) following notifications: classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings Do we have an issue here? Working on it.
Re: svn commit: r1327411 - in /ofbiz/trunk: bin/ tools/functions.sh tools/git-rebase-runner.sh
On 04/19/2012 03:15 AM, Jacopo Cappellato wrote: Jacques, here are some details: Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro8,2 Processor Name: Intel Core i7 Processor Speed:2.2 GHz Number of Processors: 1 Total Number of Cores: 4 So 4 threads. That doesn't help that much, unless the test suite is multithreaded now. L2 Cache (per Core):256 KB L3 Cache: 6 MB Memory: 8 GB HD details are: Intel 6 Series Chipset: Vendor: Intel Product:6 Series Chipset Link Speed: 6 Gigabit Negotiated Link Speed: 3 Gigabit Description:AHCI Version 1.30 Supported Hitachi HTS725050A9A362: Capacity: 500.11 GB (500,107,862,016 bytes) Model: Hitachi HTS725050A9A362 Queue Depth:32 Rotational Rate:7200 Jacopo On Apr 19, 2012, at 9:58 AM, Jacques Le Roux wrote: OK seems after all that I need a brand new CPU, hence a new box... I must say with the SSDs when running run-tests my CPU is always at 100% (I put the run-tests process priority level to idle to be able to continue other tasks) Do you have a SSD in your laptop Jacopo? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 18, 2012, at 6:55 PM, Jacopo Cappellato wrote: On Apr 18, 2012, at 6:43 PM, Adam Heath wrote: It currently takes my desktop 1 hour to run a full test suite. clean, load-demo(30m), run-tests(30m). It used to take 12-15m. wow, it takes me 2-3 minutes in my laptop. Jacopo To be more precise: (less than) 3 minutes for load-demo 4 minutes and 3 seconds for run-tests Jacopo
recent HashCrypt changes, and using salt-based password hashing
As some may have noticed, I recently changed the way ofbiz creates password hashes when it stores them in the database. Each time a new password is created, a bit of randomness is used, to create a random-length, random-content salt. This is placed at the beginning of the hashed password, stored along with it in the database. Then, when it comes time to compare passwords, the salt is extracted, and used to re-hash. If someone continously changes their password to the same value, you'll end up getting different raw hashed values in the database. It also increases the workload for crackers, and makes rainbow tables much less fruitful. I wrote this change over 2 years ago, in direct response to the jira intrusion that happened.
upcoming Delegator deprecations
commit 6493e4845f2acab9ce3e1f92cdc7f5b62bb79a2f Author: Adam Heath doo...@brainfood.com Date: Sun Dec 5 18:32:01 2010 -0600 Deprecate GenericValue.getRelatedDummyPK(String). Still more api simplification. Fortunately, this is a very small change. It seems that this method is hardly used by anything. GenericValue.getRelatedDummyPK(String) is replaced by GenericValue.getRelatedDummyPK(String, Map). commit 3e91daff87f5a35c9910f6a19698b755a05e1c80 Author: Adam Heath doo...@brainfood.com Date: Sun Dec 5 16:30:03 2010 -0600 Deprecate all Delegator.getRelatedOne and Delegator.getRelatedOneCache, and GenericValue.getRelatedOne/GenericValue.getRelatedOneCache, and add a version that takes a cache parameter. Yet again, another simplication of the delegator api. This replaces all simple getRelatedOne type methods with a single version that takes all possible arguments. Delegator.getRelatedOne(String, GenericValue) is replaced by Delegator.getRelatedOne(String, boolean, GenericValue). Delegator.getRelatedOneCache(String, GenericValue) is replaced by Delegator.getRelatedOne(String, boolean, GenericValue). GenericValue.getRelatedOne(String) is replaced by GenericValue.getRelatedOne(String, boolean). GenericValue.getRelatedOneCache(String) is replaced by GenericValue.getRelatedOne(String, boolean). commit f841a522ead6a8cb9787e7ce3f26ec0979c278cc Author: Adam Heath doo...@brainfood.com Date: Sun Jun 26 17:14:07 2011 -0500 Deprecate all Delegator.findByAnd and Delegator.findByAndCache; introduce a new Delegator.findByAnd variant that takes a boolean cache parameter. This change continues the simplication of the delegator api. There is no longer a version of a method with a 'Cache' suffix; instead, a single version now exists that takes a boolean cache parameter. Also, there has been a trend to remove several method variants that take different numbers and types of parameters, instead preferring to fully specify all parameters; this also continues that trend. Delegator.findByAnd(String, Map) is replaced with findByAnd(String, Map, List, boolean). Delegator.findByAnd(String, Map, List) is replaced with findByAnd(String, Map, List, boolean). Delegator.findByAnd(String, Object...) is replaced with findByAnd(String, Map, List, boolean). The object array is converted to a map by using UtilMisc.toMap(Object...). Delegator.findByAndCache(String, Map) is replaced with findByAnd(String, Map, List, boolean). Delegator.findByAndCache(String, Map, List) is replaced with findByAnd(String, Map, List, boolean). commit e5fd12b37f07dbee109e30a0d528ba1ca7e226e6 Author: Adam Heath doo...@brainfood.com Date: Sun Dec 5 21:51:51 2010 -0600 Deprecate Delegator.findByPrimaryKey and Delegator.findByPrimaryKeyCache. Ofbiz is moving towards simpler delegator apis; this means all 'fooCache' variants are removed(and their matching 'foo' method), and a new version of 'foo' added that takes a boolean cache parameter. Delegator.findByPrimaryKey(String, Map) is replaced with findOne(String, Map, false). Delegator.findByPrimaryKeyCache(String, Map) is replaced with findOne(String, Map, true). Delegator.findByPrimaryKey(String, Object...) is replaced with findOne(String, false, Object...).
Re: svn commit: r1327835 - in /ofbiz/trunk/framework: jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java widget/src/org/ofbiz/widget/WidgetWorker.java
Hi Adam, yea the Worker class sneaked accidentally in the commit list. It has
been removed already.
Am 19.04.2012 um 17:11 schrieb Adam Heath doo...@brainfood.com:
On 04/19/2012 12:58 AM, sascharodek...@apache.org wrote:
Author: sascharodekamp
Date: Thu Apr 19 05:58:29 2012
New Revision: 1327835
URL: http://svn.apache.org/viewvc?rev=1327835view=rev
Log:
Fix jackrabbit unit testing.
Modified:
ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
Modified:
ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
(original)
+++ ofbiz/trunk/framework/jcr/src/org/ofbiz/jcr/test/JackrabbitTests.java
Thu Apr 19 05:58:29 2012
@@ -18,18 +18,13 @@ under the License.
*/
package org.ofbiz.jcr.test;
-import java.io.File;
-import java.io.FileInputStream;
-import java.io.InputStream;
import java.util.GregorianCalendar;
-import java.util.List;
import java.util.Map;
import javax.jcr.ItemExistsException;
import javax.jcr.PathNotFoundException;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
-import javax.jcr.query.QueryResult;
import javolution.util.FastMap;
import net.sf.json.JSONArray;
@@ -46,9 +41,7 @@ import org.ofbiz.jcr.access.JcrRepositor
import org.ofbiz.jcr.access.jackrabbit.ContentWriterJackrabbit;
import org.ofbiz.jcr.access.jackrabbit.JackrabbitRepositoryAccessor;
import org.ofbiz.jcr.api.JcrDataHelper;
-import org.ofbiz.jcr.api.JcrFileHelper;
import org.ofbiz.jcr.api.jackrabbit.JackrabbitArticleHelper;
-import org.ofbiz.jcr.api.jackrabbit.JackrabbitFileHelper;
import org.ofbiz.jcr.loader.JCRFactory;
import org.ofbiz.jcr.loader.JCRFactoryUtil;
import org.ofbiz.jcr.loader.jackrabbit.JCRFactoryImpl;
This change doesn't fix the unit testing. It should be a separate commit.
Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java?rev=1327835r1=1327834r2=1327835view=diff
==
--- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
(original)
+++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java Thu
Apr 19 05:58:29 2012
@@ -379,10 +379,14 @@ public class WidgetWorker {
returnValue = df.format((java.util.Date) retVal);
} else {
try {
-returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(UTF-8).displayName());
+returnValue = URLEncoder.encode(retVal.toString(),
Charset.forName(ISO-8859-1).displayName());
Er, that can't be right.
} catch (UnsupportedEncodingException e) {
Debug.logError(e, module);
}
+
+//StringUtil.SimpleEncoder simpleEncoder =
(StringUtil.SimpleEncoder) context.get(simpleEncoder);
+//returnValue = simpleEncoder.encode(retVal.toString());
+
Why did you check this in?
}
return returnValue;
} else {
openid support
I have a series of patches that enable ofbiz to be used as an openid *provider*. I used this to allow a wordpress site to delegate authentication to ofbiz(the company in question already had an ofbiz deployment hooked into their internal ldap, with phone/name synching; didn't want to duplicate all that). I do *not* yet have working openid client support. Should I wait until I do(there is no client that has payed for that), or should I commit what I already have? I need to verify it again first, but that shouldn't take overly long.
Re: svn commit: r1327866 - in /ofbiz/trunk: applications/accounting/data/ applications/content/data/ applications/humanres/data/ applications/marketing/data/ applications/order/data/ framework/example
On 04/19/2012 03:43 AM, jaco...@apache.org wrote:
Author: jacopoc
Date: Thu Apr 19 08:43:54 2012
New Revision: 1327866
URL: http://svn.apache.org/viewvc?rev=1327866view=rev
Log:
Reverted rev. 1327736: with it it was impossible to log in with demo accounts.
Ok, then the test cases suck. I'll look into the real reason.
Modified:
ofbiz/trunk/applications/accounting/data/DemoAccountingUserData.xml
ofbiz/trunk/applications/content/data/DemoBlogUsersData.xml
ofbiz/trunk/applications/humanres/data/HumanResDemoData.xml
ofbiz/trunk/applications/marketing/data/sfaDemoData.xml
ofbiz/trunk/applications/order/data/OrderDemoUser.xml
ofbiz/trunk/framework/example/testdef/assertdata/TestUserLoginData.xml
ofbiz/trunk/framework/security/data/PasswordSecurityData.xml
ofbiz/trunk/specialpurpose/ecommerce/data/DemoPurchasing.xml
ofbiz/trunk/specialpurpose/projectmgr/data/ProjectMgrDemoPasswordData.xml
Modified: ofbiz/trunk/applications/accounting/data/DemoAccountingUserData.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/data/DemoAccountingUserData.xml?rev=1327866r1=1327865r2=1327866view=diff
==
--- ofbiz/trunk/applications/accounting/data/DemoAccountingUserData.xml
(original)
+++ ofbiz/trunk/applications/accounting/data/DemoAccountingUserData.xml Thu
Apr 19 08:43:54 2012
@@ -30,7 +30,7 @@ under the License.
PartyRole partyId=accountingadmin roleTypeId=ACCOUNTANT/
PartyRole partyId=accountingadmin roleTypeId=EMPLOYEE/
PartyRole partyId=accountingadmin roleTypeId=_NA_/
-UserLogin userLoginId=accountingadmin
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709
partyId=accountingadmin passwordHint=/
+UserLogin userLoginId=accountingadmin
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
partyId=accountingadmin passwordHint=/
UserLoginSecurityGroup groupId=ACCTG_FUNCTNL_ADMIN
userLoginId=accountingadmin fromDate=2001-01-01 12:00:00.0/
PartyRelationship partyIdFrom=Company partyIdTo=accountingadmin
partyRelationshipTypeId=EMPLOYMENT roleTypeIdFrom=INTERNAL_ORGANIZATIO
roleTypeIdTo=EMPLOYEE fromDate=2001-01-01 12:00:00.0/
Modified: ofbiz/trunk/applications/content/data/DemoBlogUsersData.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/content/data/DemoBlogUsersData.xml?rev=1327866r1=1327865r2=1327866view=diff
==
--- ofbiz/trunk/applications/content/data/DemoBlogUsersData.xml (original)
+++ ofbiz/trunk/applications/content/data/DemoBlogUsersData.xml Thu Apr 19
08:43:54 2012
@@ -21,31 +21,31 @@ under the License.
entity-engine-xml
Party partyId=BLOGUSER_ADMIN partyTypeId=PERSON
createdDate=2004-03-27 09:37:40.989 createdByUserLogin=admin
lastModifiedDate=2004-03-27 09:37:40.989 lastModifiedByUserLogin=admin/
Person partyId=BLOGUSER_ADMIN lastName=Blog firstName=Admin/
-UserLogin userLoginId=blog_admin partyId=BLOGUSER_ADMIN
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709/
+UserLogin userLoginId=blog_admin partyId=BLOGUSER_ADMIN
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a/
PartyRole partyId=BLOGUSER_ADMIN roleTypeId=CONTENT_ADMIN/
ContentRole partyId=BLOGUSER_ADMIN roleTypeId=CONTENT_ADMIN
contentId=BLOGROOT fromDate=2004-03-27 09:37:40.989/
UserLoginSecurityGroup userLoginId=blog_admin groupId=FULLADMIN
fromDate=2004-09-15 00:00:00.000/
Party partyId=BLOGUSER_EDITOR partyTypeId=PERSON
createdDate=2004-03-27 09:37:40.989 createdByUserLogin=admin
lastModifiedDate=2004-03-27 09:37:40.989 lastModifiedByUserLogin=admin/
Person partyId=BLOGUSER_EDITOR lastName=Blog firstName=Editor/
-UserLogin userLoginId=blog_editor partyId=BLOGUSER_EDITOR
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709/
+UserLogin userLoginId=blog_editor partyId=BLOGUSER_EDITOR
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a/
PartyRole partyId=BLOGUSER_EDITOR roleTypeId=CONTENT_ADMIN/
ContentRole partyId=BLOGUSER_EDITOR roleTypeId=CONTENT_ADMIN
contentId=BLOGROOT fromDate=2004-03-27 09:37:40.989/
UserLoginSecurityGroup userLoginId=blog_editor groupId=FULLADMIN
fromDate=2004-09-15 00:00:00.000/
Party partyId=BLOGUSER_USER partyTypeId=PERSON
createdDate=2004-03-27 09:37:40.989 createdByUserLogin=admin
lastModifiedDate=2004-03-27 09:37:40.989 lastModifiedByUserLogin=admin/
Person partyId=BLOGUSER_USER lastName=Blog firstName=User/
-UserLogin userLoginId=blog_user partyId=BLOGUSER_USER
currentPassword={SHA}da39a3ee5e6b4b0d3255bfef95601890afd80709/
+UserLogin userLoginId=blog_user partyId=BLOGUSER_USER
currentPassword={SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a/
PartyRole partyId=BLOGUSER_USER
[jira] [Assigned] (OFBIZ-4824) Deprecated use of org.ofbiz.base.crypto.HashCrypt
[ https://issues.apache.org/jira/browse/OFBIZ-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-4824: - Assignee: Adam Heath Deprecated use of org.ofbiz.base.crypto.HashCrypt - Key: OFBIZ-4824 URL: https://issues.apache.org/jira/browse/OFBIZ-4824 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Adam Heath Fix For: SVN trunk Hash classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4824) Deprecated use of org.ofbiz.base.crypto.HashCrypt
[ https://issues.apache.org/jira/browse/OFBIZ-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257602#comment-13257602 ] Adam Heath commented on OFBIZ-4824: --- I have fixed GenericEntity locally. However, it means that every time GenericEntity.toString() is called, you will get a *different* string, as a random salt is prepended to encrypted fields. But really, no one should be comparing the exact string output anyways. And, actually, that call in toString is really truly broken. It should do the same thing as EntityCrypto; to do anything less, would mean that PCI compliance is not being met. Fixing EntityCrypto is a bit more difficult. I don't want to just @SuppressWarnings(deprecation) on these methods; they really need to use the new and improved methods. However, I can't just switch completely, 'cuz then all existing crypted fields will no longer load. Stay tuned. Deprecated use of org.ofbiz.base.crypto.HashCrypt - Key: OFBIZ-4824 URL: https://issues.apache.org/jira/browse/OFBIZ-4824 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Adam Heath Fix For: SVN trunk Hash classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4830) eCommerce Customer Code Cleanup
eCommerce Customer Code Cleanup
---
Key: OFBIZ-4830
URL: https://issues.apache.org/jira/browse/OFBIZ-4830
Project: OFBiz
Issue Type: Improvement
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Environment: demo-trunk
Reporter: Tom Burns
Priority: Minor
Fix For: SVN trunk
Attachments: OFBIZ-4830 eCommerce Customer Code Cleanup.patch
1. In OFBIZ-4822 it was decided that request to authview would be removed from
the eCommerce customer ftl files because their only purpose was to set URL to
https. The set field donePage in CustomerScreens.xml editperson effects the
same result.
2. There are brackets in the password.ftl display for the href:
a href=@ofbizUrlauthview/${donePage}/@ofbizUrl
class=button[${uiLabelMap.CommonGoBack}]/a
The brackets are inconsistent with the display for similar elements in the
applications
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4830) eCommerce Customer Code Cleanup
[
https://issues.apache.org/jira/browse/OFBIZ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Burns updated OFBIZ-4830:
-
Attachment: OFBIZ-4830 eCommerce Customer Code Cleanup.patch
eCommerce Customer Code Cleanup
---
Key: OFBIZ-4830
URL: https://issues.apache.org/jira/browse/OFBIZ-4830
Project: OFBiz
Issue Type: Improvement
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Environment: demo-trunk
Reporter: Tom Burns
Priority: Minor
Fix For: SVN trunk
Attachments: OFBIZ-4830 eCommerce Customer Code Cleanup.patch
1. In OFBIZ-4822 it was decided that request to authview would be removed
from the eCommerce customer ftl files because their only purpose was to set
URL to https. The set field donePage in CustomerScreens.xml editperson
effects the same result.
2. There are brackets in the password.ftl display for the href:
a href=@ofbizUrlauthview/${donePage}/@ofbizUrl
class=button[${uiLabelMap.CommonGoBack}]/a
The brackets are inconsistent with the display for similar elements in the
applications
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4824) Deprecated use of org.ofbiz.base.crypto.HashCrypt
[ https://issues.apache.org/jira/browse/OFBIZ-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257723#comment-13257723 ] Adam Heath commented on OFBIZ-4824: --- Wow, EntityCrypt is full of all sorts of fun stuff. First, the constructor creates 20 random keys if none are found in the database. Those 20 keys could never possibly be used. That loop should just be removed. Second, getKey(String, boolean) has broken synchronization on the keyMap.get/put pair. We've been lucky that is hasn't entered into a loop inside HashMap. This is problably due to the first item above. 20 keys get stored in the map, which is enough to cause the map to *not* resize it's internal buckets, when later keys get requested. Next, getRandomString() is not secure. That's the point of the SecureRandom class. This is a simple fix, however. Also, the transaction suspending that it doesn't doesn't do the right thing if there is an OutOfMemory thrown, or other Error or RuntimeException. It really needs to do that cleanup inside a finally. Fortunately, that's what TransactionUtil.doNewTransaction is for. Ideally, decrypt(), when it calls getKey(), shouldn't be creating *new* keys in the database, nor storing into the keyMap. Deprecated use of org.ofbiz.base.crypto.HashCrypt - Key: OFBIZ-4824 URL: https://issues.apache.org/jira/browse/OFBIZ-4824 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Adam Heath Fix For: SVN trunk Hash classes: [javac16] Compiling 140 source files to /ci/ofbiz/framework/entity/build/classes [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/GenericEntity.java:1299: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] curValue = HashCrypt.getDigestHash(encryptField); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHashOldFunnyHexEncode(java.lang.String,java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] /ci/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java:122: warning: [deprecation] getDigestHash(java.lang.String) in org.ofbiz.base.crypto.HashCrypt has been deprecated [javac16] String hashedKeyName = useOldFunnyKeyHash? HashCrypt.getDigestHashOldFunnyHexEncode(originalKeyName, null) : HashCrypt.getDigestHash(originalKeyName); [javac16] ^ [javac16] 3 warnings -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4830) eCommerce Customer Code Cleanup
[
https://issues.apache.org/jira/browse/OFBIZ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Burns updated OFBIZ-4830:
-
Attachment: OFBIZ-4830 eCommerce Customer Code Cleanup.html
The attached file may be used for testing the changes in OFBIZ-4830 eCommerce
Customer Code Cleanup.patch in the Selenium IDE.
To test :
Load the file into the Selenium IDE.
Login to eCommerce as DemoCustomer (using Firefox)
Invoke the script.
The script walks through each of the impacted screens and clicks their back
buttons.
As the script runs watch the URL. It should always display https.
eCommerce Customer Code Cleanup
---
Key: OFBIZ-4830
URL: https://issues.apache.org/jira/browse/OFBIZ-4830
Project: OFBiz
Issue Type: Improvement
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Environment: demo-trunk
Reporter: Tom Burns
Priority: Minor
Fix For: SVN trunk
Attachments: OFBIZ-4830 eCommerce Customer Code Cleanup.html,
OFBIZ-4830 eCommerce Customer Code Cleanup.patch
1. In OFBIZ-4822 it was decided that request to authview would be removed
from the eCommerce customer ftl files because their only purpose was to set
URL to https. The set field donePage in CustomerScreens.xml editperson
effects the same result.
2. There are brackets in the password.ftl display for the href:
a href=@ofbizUrlauthview/${donePage}/@ofbizUrl
class=button[${uiLabelMap.CommonGoBack}]/a
The brackets are inconsistent with the display for similar elements in the
applications
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openid support
Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà Jacques From: Adam Heath doo...@brainfood.com I have a series of patches that enable ofbiz to be used as an openid *provider*. I used this to allow a wordpress site to delegate authentication to ofbiz(the company in question already had an ofbiz deployment hooked into their internal ldap, with phone/name synching; didn't want to duplicate all that). I do *not* yet have working openid client support. Should I wait until I do(there is no client that has payed for that), or should I commit what I already have? I need to verify it again first, but that shouldn't take overly long.
Re: recent HashCrypt changes, and using salt-based password hashing
Looking forward for https://issues.apache.org/jira/browse/OFBIZ-1151 https://issues.apache.org/jira/browse/OFBIZ-2729 https://issues.apache.org/jira/browse/OFBIZ-3006 Jacques From: Adam Heath doo...@brainfood.com As some may have noticed, I recently changed the way ofbiz creates password hashes when it stores them in the database. Each time a new password is created, a bit of randomness is used, to create a random-length, random-content salt. This is placed at the beginning of the hashed password, stored along with it in the database. Then, when it comes time to compare passwords, the salt is extracted, and used to re-hash. If someone continously changes their password to the same value, you'll end up getting different raw hashed values in the database. It also increases the workload for crackers, and makes rainbow tables much less fruitful. I wrote this change over 2 years ago, in direct response to the jira intrusion that happened.
Re: openid support
On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà There are multiple layers. framework/openid, which has the basic logic, but not any of the AX extensions. applications/openidext, which then can pull in Person firstName/lastName, ContactMech(ICQ, website, phone, etc). I'd really prefer to have the former in framework. But I guess I need to wait until I can verify it actually works before sending it(it does internally, but I need to check it again).
Re: Opinions wanted on r1307895
Committed at revision: 1328122 Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Nope, I'd not have raised a warning else ;o) The user must read it at the end, it's the body part of the email in the service result Jacques From: Adrian Crum adrian.c...@sandglass-software.com Is the logged password encrypted? If yes, then I don't see a problem with it. -Adrian On 4/7/2012 10:39 AM, Jacques Le Roux wrote: Hi, I followed Scott's suggestion and added a generic EMAIL_PASSWORD EmailTemplateSetting (used to send a new password at user request). I finally kept also the previous way (in r1307895) because it allows an easier 18n of the email subject. Something is worrying me a bit. Since the service takes more than 50/200 ms, ServiceDispatcher.java (just above line 600) shows the password in console and logs. To prevent this by and large, I'd like to add a hideResult attribute to service defintion. It would be false by default and used in ServiceDispatcher.runAsync() An alternative would be to use runSyncIgnore to call sendMailFromScreen service in LoginEvents.java. But I think it's a more general issue... What do you think? Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Thanks Scott, This sounds like a plan. I will try to apply it... Jacques From: Scott Gray scott.g...@hotwaxmedia.com Hi Jacques, I think the better approach would have been to fall back to the EmailTemplateSetting (after adding a demo record for it) and failing if it isn't present (along with removing that default screen reference altogether). The reason for this is simplicity, we give the user one path through the system: - Define a forgot password template for the entire system in EmailTemplateSetting - If you want ones for specific product stores then define them in ProductStoreEmailSetting Regards Scott On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: Do you agree with r1307895 and to backport it to releases? http://svn.apache.org/viewvc?rev=1307895view=rev Jacques
[jira] [Commented] (OFBIZ-4813) ajax autocomplete and dialog during session timeout
[ https://issues.apache.org/jira/browse/OFBIZ-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257840#comment-13257840 ] Jacques Le Roux commented on OFBIZ-4813: Wai, Are you sure that removing the spinner in Tomahawk works? Here it does not it seems... Also I did not see any spinner repeated before. Is there a specific use case to reproduce? ajax autocomplete and dialog during session timeout --- Key: OFBIZ-4813 URL: https://issues.apache.org/jira/browse/OFBIZ-4813 Project: OFBiz Issue Type: Bug Components: framework Reporter: Wai Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: ofbiz-4813-additional.patch, ofbiz-4813.patch, ofbiz-4813.patch, ofbiz-4813.patch, spinner.gif 1. autocomplete feature shows the message no records found during a session timeout. This could be misleading for the user. 2. During a session timeout, clicking on ajax dialog button shows a large frame containing a message indicating session has timeout. Should show a more detailed message. 3. All ajax dialogs are on the left of browser window. A number of fixes have been implemented for this issue. 1. At session timeout, user enters a character into autocomplete input box results in a alert window popup. 2. At session timeout, clicking on ajax dialog button will cause alert window to popup. 3. A large round spinner is shown when the ajax dialog is loading. This spinner image comes from http://mentalized.net/activity-indicators/ and is royalty free. Note the round spinner does not show in Tomahawk theme as it uses its own spinner. 4. Now all ajax dialogs are centered. 5. Change session timeout message to something more detailed. 6. Server response to ajax request now contain html tags. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: recent HashCrypt changes, and using salt-based password hashing
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
Jacques
From: Adam Heath doo...@brainfood.com
As some may have noticed, I recently changed the way ofbiz creates
password hashes when it stores them in the database. Each time a new
password is created, a bit of randomness is used, to create a
random-length, random-content salt. This is placed at the beginning
of the hashed password, stored along with it in the database.
Then, when it comes time to compare passwords, the salt is extracted,
and used to re-hash.
If someone continously changes their password to the same value,
you'll end up getting different raw hashed values in the database. It
also increases the workload for crackers, and makes rainbow tables
much less fruitful.
I wrote this change over 2 years ago, in direct response to the jira
intrusion that happened.
Re: Opinions wanted on r1307895
On 04/19/2012 04:41 PM, Jacques Le Roux wrote: Committed at revision: 1328122 Jacques This change would be needed for anything dealing with PAN(credit-card number for those not into the lingo). From: Jacques Le Roux jacques.le.r...@les7arts.com Nope, I'd not have raised a warning else ;o) The user must read it at the end, it's the body part of the email in the service result Jacques From: Adrian Crum adrian.c...@sandglass-software.com Is the logged password encrypted? If yes, then I don't see a problem with it. -Adrian On 4/7/2012 10:39 AM, Jacques Le Roux wrote: Hi, I followed Scott's suggestion and added a generic EMAIL_PASSWORD EmailTemplateSetting (used to send a new password at user request). I finally kept also the previous way (in r1307895) because it allows an easier 18n of the email subject. Something is worrying me a bit. Since the service takes more than 50/200 ms, ServiceDispatcher.java (just above line 600) shows the password in console and logs. To prevent this by and large, I'd like to add a hideResult attribute to service defintion. It would be false by default and used in ServiceDispatcher.runAsync() An alternative would be to use runSyncIgnore to call sendMailFromScreen service in LoginEvents.java. But I think it's a more general issue... What do you think? Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Thanks Scott, This sounds like a plan. I will try to apply it... Jacques From: Scott Gray scott.g...@hotwaxmedia.com Hi Jacques, I think the better approach would have been to fall back to the EmailTemplateSetting (after adding a demo record for it) and failing if it isn't present (along with removing that default screen reference altogether). The reason for this is simplicity, we give the user one path through the system: - Define a forgot password template for the entire system in EmailTemplateSetting - If you want ones for specific product stores then define them in ProductStoreEmailSetting Regards Scott On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: Do you agree with r1307895 and to backport it to releases? http://svn.apache.org/viewvc?rev=1307895view=rev Jacques
Re: recent HashCrypt changes, and using salt-based password hashing
On 04/19/2012 04:49 PM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
Also, no longer using hex-encoding for the values, but base64, as it
produces a smaller encoded value. The new salt-based password stuff
I've committed already does that.
Re: openid support
From: Adam Heath doo...@brainfood.com On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà There are multiple layers. framework/openid, which has the basic logic, but not any of the AX extensions. applications/openidext, which then can pull in Person firstName/lastName, ContactMech(ICQ, website, phone, etc). I'd really prefer to have the former in framework. But I guess I need to wait until I can verify it actually works before sending it(it does internally, but I need to check it again). I'm personaly not against it. I guess it's not a large piece of software? Jacques
Re: openid support
Adam, There was a previous thread on the subject of implementing other authentication and security models to support OpenId, LDAP, and other custom authentication needs. The subject of the thread was Alternatives to using UserLoginId as a primary key. Here is a snippet of that thread from Jacopo. Does your implementation follow a similar approach to what Jacopo suggested? I'm asking because we need a custom authentication model to support unique user IDs across groups where the individual IDs may conflict. On Mon, Feb 20, 2012 at 5:59 AM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I like Adrian's proposal to make the UserLogin entity more flexible. Brett, as regards your proposal about the extension mechanism (i.e. the UserCredentials), I think it would be better an approach where each specific security implementation defines its own *Credentials (or *UserLogin or *Authentication or some other name) entity as an extension to the UserLogin for that authenticationTypeId (instead of attempting to define a general purpose UserCredentials entity). For example, for a UserLogin record for LDAP (i.e. authenticationTypeId=LDAP) we could have a corresponding record in the LdapUserLogin record; for a UserLogin record for OpenId we could have a corresponding record in the OpenIdUserLogin record etc... you could define your own for the specific security you are working on. Kind regards, Jacopo On Thu, Apr 19, 2012 at 9:26 AM, Adam Heath doo...@brainfood.com wrote: I have a series of patches that enable ofbiz to be used as an openid *provider*. I used this to allow a wordpress site to delegate authentication to ofbiz(the company in question already had an ofbiz deployment hooked into their internal ldap, with phone/name synching; didn't want to duplicate all that). I do *not* yet have working openid client support. Should I wait until I do(there is no client that has payed for that), or should I commit what I already have? I need to verify it again first, but that shouldn't take overly long. Thanks, Brett
Re: openid support
On 04/19/2012 04:55 PM, Brett Palmer wrote: Adam, There was a previous thread on the subject of implementing other authentication and security models to support OpenId, LDAP, and other custom authentication needs. The subject of the thread was Alternatives to using UserLoginId as a primary key. Here is a snippet of that thread from Jacopo. Does your implementation follow a similar approach to what Jacopo suggested? I'm asking because we need a custom authentication model to support unique user IDs across groups where the individual IDs may conflict. The openid stuff I currently have allow for ofbiz to *answer* openid requests from other systems. There is nothing in ofbiz that does anything like that. It's as if ofbiz *was* the ldap server. I plan on letting openid be used on login pages, but none of our clients have requested such a feature.
Re: recent HashCrypt changes, and using salt-based password hashing
From: Adam Heath doo...@brainfood.com On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Looking forward for https://issues.apache.org/jira/browse/OFBIZ-1151 https://issues.apache.org/jira/browse/OFBIZ-2729 https://issues.apache.org/jira/browse/OFBIZ-3006 2729 doesn't apply for what I am doing. Here's the list of things that this solves: Oops indeed sorry, I too hastily picked them up from https://issues.apache.org/jira/browse/OFBIZ-1525 2729 is only about permission. For that we want to introduce Shiro but that's not for a near future: we agreed on slim down 1st... Jacques
Re: recent HashCrypt changes, and using salt-based password hashing
From: Adam Heath doo...@brainfood.com
On 04/19/2012 04:49 PM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
Also, no longer using hex-encoding for the values, but base64, as it
produces a smaller encoded value. The new salt-based password stuff
I've committed already does that.
Sounds good, long awaited feature...
Jacques
[jira] [Assigned] (OFBIZ-3006) entity encrypt columns not using encryption salt value?
[
https://issues.apache.org/jira/browse/OFBIZ-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath reassigned OFBIZ-3006:
-
Assignee: Adam Heath
entity encrypt columns not using encryption salt value?
---
Key: OFBIZ-3006
URL: https://issues.apache.org/jira/browse/OFBIZ-3006
Project: OFBiz
Issue Type: Sub-task
Affects Versions: SVN trunk
Reporter: chris snow
Assignee: Adam Heath
It looks as though no salt data is used when saving encrypted entity data
making the stored data susceptible to dictionary attacks.
If you look through the stored demo data, you can see all the demo accounts
passwords are the same:
{code}
UserLogin:
admin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
flexadmin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
...
{code}
As a comparison, if you create a two unix accounts, ofbiz1 and ofbiz2 and
set both passwords to ofbiz
{code}
ofbiz1:$6$3.mYZg9u$0E...:14524:0:9:7:::
ofbiz2:$6$MJhYeMqO$Jf...:14524:0:9:7:::
{code}
You can see that on unix, even though the passwords are the same, the
encrypted values are completely different.
For more information see:
[http://en.wikipedia.org/wiki/Salt_(cryptography)]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-1151) Passwords are not salted
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-1151: -- Summary: Passwords are not salted (was: Passwords are not seeded) Passwords are not salted Key: OFBIZ-1151 URL: https://issues.apache.org/jira/browse/OFBIZ-1151 Project: OFBiz Issue Type: Sub-task Components: party Affects Versions: Release Branch 4.0, SVN trunk Reporter: Wickersheimer Jeremy Assignee: Adam Heath Priority: Minor Password are currently hashed but not seeded which may be a security issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-1151) Passwords are not seeded
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-1151: - Assignee: Adam Heath (was: Jacques Le Roux) Passwords are not seeded Key: OFBIZ-1151 URL: https://issues.apache.org/jira/browse/OFBIZ-1151 Project: OFBiz Issue Type: Sub-task Components: party Affects Versions: Release Branch 4.0, SVN trunk Reporter: Wickersheimer Jeremy Assignee: Adam Heath Priority: Minor Password are currently hashed but not seeded which may be a security issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-1151) Passwords are not salted
[ https://issues.apache.org/jira/browse/OFBIZ-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257861#comment-13257861 ] Adam Heath commented on OFBIZ-1151: --- I've just committed a change that finally implements this(svn 1327741). There are a few remaining buglets, however, in the existing seed/demo data that I'm working thru. Passwords are not salted Key: OFBIZ-1151 URL: https://issues.apache.org/jira/browse/OFBIZ-1151 Project: OFBiz Issue Type: Sub-task Components: party Affects Versions: Release Branch 4.0, SVN trunk Reporter: Wickersheimer Jeremy Assignee: Adam Heath Priority: Minor Password are currently hashed but not seeded which may be a security issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3006) entity encrypt columns not using encryption salt value?
[
https://issues.apache.org/jira/browse/OFBIZ-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257868#comment-13257868
]
Adam Heath commented on OFBIZ-3006:
---
I'm working on this today. Should have it implemented by this evening. Won't
be able to commit it right away, as I need to split the commit up into smaller
chunks. The changes are in EntityCrypto.
entity encrypt columns not using encryption salt value?
---
Key: OFBIZ-3006
URL: https://issues.apache.org/jira/browse/OFBIZ-3006
Project: OFBiz
Issue Type: Sub-task
Affects Versions: SVN trunk
Reporter: chris snow
Assignee: Adam Heath
It looks as though no salt data is used when saving encrypted entity data
making the stored data susceptible to dictionary attacks.
If you look through the stored demo data, you can see all the demo accounts
passwords are the same:
{code}
UserLogin:
admin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
flexadmin {SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a
...
{code}
As a comparison, if you create a two unix accounts, ofbiz1 and ofbiz2 and
set both passwords to ofbiz
{code}
ofbiz1:$6$3.mYZg9u$0E...:14524:0:9:7:::
ofbiz2:$6$MJhYeMqO$Jf...:14524:0:9:7:::
{code}
You can see that on unix, even though the passwords are the same, the
encrypted values are completely different.
For more information see:
[http://en.wikipedia.org/wiki/Salt_(cryptography)]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4831) eCommerce Create New Customer Improvement
eCommerce Create New Customer Improvement - Key: OFBIZ-4831 URL: https://issues.apache.org/jira/browse/OFBIZ-4831 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: demo-trunk Reporter: Tom Burns Priority: Minor 1. Add support for dependent Country / State drop down to newcustomer.ftl This change makes the behavior of the Country / State drop downs in newcustomer.ftl consistent with the Profile Contact Information Postal Address Create New and Update behavior. 2. When an eCommerce user, who is not Logged In, clicks Register the newcustomer.ftl from opens with a Go Back button. This button navigates to a Login form that prompts the user for a user name and password. This makes no sense in the context. A better design is to have a Cancel button. When the user clicks Cancel the application returns to the Main display for the current session. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4831) eCommerce Create New Customer Improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Burns updated OFBIZ-4831: - Attachment: OFBIZ-4831 eCommerce Create New Customer Improvement.patch eCommerce Create New Customer Improvement - Key: OFBIZ-4831 URL: https://issues.apache.org/jira/browse/OFBIZ-4831 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: demo-trunk Reporter: Tom Burns Priority: Minor Attachments: OFBIZ-4831 eCommerce Create New Customer Improvement.patch 1. Add support for dependent Country / State drop down to newcustomer.ftl This change makes the behavior of the Country / State drop downs in newcustomer.ftl consistent with the Profile Contact Information Postal Address Create New and Update behavior. 2. When an eCommerce user, who is not Logged In, clicks Register the newcustomer.ftl from opens with a Go Back button. This button navigates to a Login form that prompts the user for a user name and password. This makes no sense in the context. A better design is to have a Cancel button. When the user clicks Cancel the application returns to the Main display for the current session. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openid support
On 20/04/2012, at 9:40 AM, Adam Heath wrote: On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà There are multiple layers. framework/openid, which has the basic logic, but not any of the AX extensions. applications/openidext, which then can pull in Person firstName/lastName, ContactMech(ICQ, website, phone, etc). I'd really prefer to have the former in framework. But I guess I need to wait until I can verify it actually works before sending it(it does internally, but I need to check it again). Perhaps consider putting a patch in jira for review? A new folder under both applications and framework seems pretty heavy handed for something that sounds so simple. If they're both just components then there's also no reason why they need to be in OFBiz rather than distributed separately unless we know they're going to see a reasonable amount of use from the community. I think this is going to become a recurring problem though, people will always want their components in OFBiz proper for fear of them being ignored/invisible if distributed by any other means. What this project really needs is an extensions website that acts as an aggregator for 3rd party components in a similar manner to firefox/chrome/jQuery/Magento/Eclipse and so manner other extensible applications. If it had a rating/review system then that could help us evaluate potential components for inclusion in the core distribution (assuming an appropriate license).
Re: recent HashCrypt changes, and using salt-based password hashing
On 20/04/2012, at 9:49 AM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
Please just do your best to ensure backwards compatibility is maintained. I
can't imagine anything worse than doing an upgrade and discovering that all my
user passwords are no longer valid.
Jacques
From: Adam Heath doo...@brainfood.com
As some may have noticed, I recently changed the way ofbiz creates
password hashes when it stores them in the database. Each time a new
password is created, a bit of randomness is used, to create a
random-length, random-content salt. This is placed at the beginning
of the hashed password, stored along with it in the database.
Then, when it comes time to compare passwords, the salt is extracted,
and used to re-hash.
If someone continously changes their password to the same value,
you'll end up getting different raw hashed values in the database. It
also increases the workload for crackers, and makes rainbow tables
much less fruitful.
I wrote this change over 2 years ago, in direct response to the jira
intrusion that happened.
Re: recent HashCrypt changes, and using salt-based password hashing
On 04/19/2012 06:13 PM, Scott Gray wrote:
On 20/04/2012, at 9:49 AM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
Please just do your best to ensure backwards compatibility is maintained. I
can't imagine anything worse than doing an upgrade and discovering that all
my user passwords are no longer valid.
Sure, I've got things done as an array of handlers now(2 current, plus
1 new).
How do we feel about moving EntityKeyStore into a separate database?
It'd improve the security a little bit, and is rather simple to do
with ofbiz.
Re: openid support
Hey Guys, We are soon going to need OAuth support to allow external users to log into OFBiz Ecommerce site, which I believe is similar in design to openid. Just wondering if you considered using Apache Shiro http://shiro.apache.org/ to help manage the different authentication systems as plugins? If you are having to touch all those parts of the framework is it worth thinking about changing the system to something that already does this stuff out the box? Thanks Sam On 20 Apr 2012, at 07:10, Scott Gray wrote: On 20/04/2012, at 9:40 AM, Adam Heath wrote: On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà There are multiple layers. framework/openid, which has the basic logic, but not any of the AX extensions. applications/openidext, which then can pull in Person firstName/lastName, ContactMech(ICQ, website, phone, etc). I'd really prefer to have the former in framework. But I guess I need to wait until I can verify it actually works before sending it(it does internally, but I need to check it again). Perhaps consider putting a patch in jira for review? A new folder under both applications and framework seems pretty heavy handed for something that sounds so simple. If they're both just components then there's also no reason why they need to be in OFBiz rather than distributed separately unless we know they're going to see a reasonable amount of use from the community. I think this is going to become a recurring problem though, people will always want their components in OFBiz proper for fear of them being ignored/invisible if distributed by any other means. What this project really needs is an extensions website that acts as an aggregator for 3rd party components in a similar manner to firefox/chrome/jQuery/Magento/Eclipse and so manner other extensible applications. If it had a rating/review system then that could help us evaluate potential components for inclusion in the core distribution (assuming an appropriate license). smime.p7s Description: S/MIME cryptographic signature
test failing because sending email is broken
currently 18 tests are failing, an example: org.ofbiz.testtools.SimpleMethodTest.shipment-tests.testShipmentServices (from facilitytests) Failing for the past 2 builds (Since #109 ) Took 12 sec. add description Error Message Problem sending email Stacktrace junit.framework.AssertionFailedError: Problem sending email at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:362) at org.ofbiz.base.start.Start.start(Start.java:337) at org.ofbiz.base.start.Start.main(Start.java:139)
Re: openid support
On 04/19/2012 10:39 PM, Sam Hamilton wrote: Hey Guys, We are soon going to need OAuth support to allow external users to log into OFBiz Ecommerce site, which I believe is similar in design to openid. Just wondering if you considered using Apache Shiro http://shiro.apache.org/ to help manage the different authentication systems as plugins? If you are having to touch all those parts of the framework is it worth thinking about changing the system to something that already does this stuff out the box? OAuth is not the same as OpenID. The former let's Application A access the resources owned by User U. The latter allows Application A to verify the identity of User U. They don't really align. I've looked at OAuth, it has a *much* worse example api. So much worse, that the 'library', if you could call it that, is barely more than a series of abstract interfaces. Client/server code ends up implementing *way* to much of the protocol itself. Additionally, both OAuth and OpenID are suffering from *massive* bit-rot. The specs are all several years old, software doesn't implement the latest versions, etc. I had to patch the openid plugin for wordpress to get it to actually work with OpenID 2.0, a spec released over 4 years ago. But I'm jaded.
Re: openid support
There is a SocialAuth project (http://code.google.com/p/socialauth/) which provides oAuth and OpenId based authentication using oAuth providers such as Google, Facebook, Twitter, LinkedIn, Yahoo etc. We used it for one of our client project. Thanks, Raj On Friday 20 April 2012 09:09 AM, Sam Hamilton wrote: Hey Guys, We are soon going to need OAuth support to allow external users to log into OFBiz Ecommerce site, which I believe is similar in design to openid. Just wondering if you considered using Apache Shiro http://shiro.apache.org/ to help manage the different authentication systems as plugins? If you are having to touch all those parts of the framework is it worth thinking about changing the system to something that already does this stuff out the box? Thanks Sam On 20 Apr 2012, at 07:10, Scott Gray wrote: On 20/04/2012, at 9:40 AM, Adam Heath wrote: On 04/19/2012 04:28 PM, Jacques Le Roux wrote: Hi Adam, The recent trend is to slim down OFBiz. This could be one of the Apache OFBiz Extras If someone needs it it pick up from there, et voilà There are multiple layers. framework/openid, which has the basic logic, but not any of the AX extensions. applications/openidext, which then can pull in Person firstName/lastName, ContactMech(ICQ, website, phone, etc). I'd really prefer to have the former in framework. But I guess I need to wait until I can verify it actually works before sending it(it does internally, but I need to check it again). Perhaps consider putting a patch in jira for review? A new folder under both applications and framework seems pretty heavy handed for something that sounds so simple. If they're both just components then there's also no reason why they need to be in OFBiz rather than distributed separately unless we know they're going to see a reasonable amount of use from the community. I think this is going to become a recurring problem though, people will always want their components in OFBiz proper for fear of them being ignored/invisible if distributed by any other means. What this project really needs is an extensions website that acts as an aggregator for 3rd party components in a similar manner to firefox/chrome/jQuery/Magento/Eclipse and so manner other extensible applications. If it had a rating/review system then that could help us evaluate potential components for inclusion in the core distribution (assuming an appropriate license).
Re: openid support
Thanks for the explanation Adam - do you see worth in implementing one system which has plugins for OAuth, OpenID LDAP etc over implementing each one individually plus the benefit of a larger security community maintaining the core security system? Sam On 20 Apr 2012, at 12:08, Adam Heath wrote: On 04/19/2012 10:39 PM, Sam Hamilton wrote: Hey Guys, We are soon going to need OAuth support to allow external users to log into OFBiz Ecommerce site, which I believe is similar in design to openid. Just wondering if you considered using Apache Shiro http://shiro.apache.org/ to help manage the different authentication systems as plugins? If you are having to touch all those parts of the framework is it worth thinking about changing the system to something that already does this stuff out the box? OAuth is not the same as OpenID. The former let's Application A access the resources owned by User U. The latter allows Application A to verify the identity of User U. They don't really align. I've looked at OAuth, it has a *much* worse example api. So much worse, that the 'library', if you could call it that, is barely more than a series of abstract interfaces. Client/server code ends up implementing *way* to much of the protocol itself. Additionally, both OAuth and OpenID are suffering from *massive* bit-rot. The specs are all several years old, software doesn't implement the latest versions, etc. I had to patch the openid plugin for wordpress to get it to actually work with OpenID 2.0, a spec released over 4 years ago. But I'm jaded. smime.p7s Description: S/MIME cryptographic signature
Re: test failing because sending email is broken
looks like 1327866 is fine, i guess it is revision 1327981 from Adrian that is the problem. Regards. Hans On 04/20/2012 10:59 AM, Hans Bakker wrote: currently 18 tests are failing, an example: org.ofbiz.testtools.SimpleMethodTest.shipment-tests.testShipmentServices (from facilitytests) Failing for the past 2 builds (Since #109 ) Took 12 sec. add description Error Message Problem sending email Stacktrace junit.framework.AssertionFailedError: Problem sending email at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:362) at org.ofbiz.base.start.Start.start(Start.java:337) at org.ofbiz.base.start.Start.main(Start.java:139)
[jira] [Commented] (OFBIZ-2729) special security should be required for setting passwords
[ https://issues.apache.org/jira/browse/OFBIZ-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258034#comment-13258034 ] Jacques Le Roux commented on OFBIZ-2729: Ping special security should be required for setting passwords -- Key: OFBIZ-2729 URL: https://issues.apache.org/jira/browse/OFBIZ-2729 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: Release Branch 4.0, Release Branch 09.04, SVN trunk Reporter: Si Chen This issue was first brought up here: https://sourceforge.net/forum/message.php?msg_id=7496877 Basically, any user with PARTYMGR_CREATE/UPDATE permissions can set the password of another user. This creates opportunity for Malfeasance. For example, a customer service rep could set the password of the admin user. A simple solution would be to create a new security permission PARTYMGR_PASSWD and require that permission for setting or changing password of a different user, instead of using PARTYMGR_UPDATE. PARTYMGR_PASSWD could then be associated with the administrative user. An alternative is to use the SECURITY_UPDATE permission instead of PARTYMGR_UPDATE or a new PARTYMGR_PASSWD permission. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4832) Product images are getting removed when user uploads specific (small, medium, large or detail) image from product content screen in 11.04 release
Product images are getting removed when user uploads specific (small, medium, large or detail) image from product content screen in 11.04 release --- Key: OFBIZ-4832 URL: https://issues.apache.org/jira/browse/OFBIZ-4832 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release Branch 11.04 Reporter: Suprit Udawat Fix For: Release Branch 11.04 Attachments: OFBIZ-4832.patch In current system when user upload original image system will automatically create rest of images that is small, medium, large, detail and thumbnail but when user upload specific image like small, medium or other image of product, system will remove all the images from specific product folder and place only recently updated image. Also if there will be medium, large or detail images are exist in system and user upload small image to complete image set then system removed all three images and add small image instead system should add new small image without touching other images. So this is a bug in 11.04. Provided patch in the task to resolve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4832) Product images are getting removed when user uploads specific (small, medium, large or detail) image from product content screen in 11.04 release
[ https://issues.apache.org/jira/browse/OFBIZ-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suprit Udawat updated OFBIZ-4832: - Attachment: OFBIZ-4832.patch Product images are getting removed when user uploads specific (small, medium, large or detail) image from product content screen in 11.04 release --- Key: OFBIZ-4832 URL: https://issues.apache.org/jira/browse/OFBIZ-4832 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release Branch 11.04 Reporter: Suprit Udawat Fix For: Release Branch 11.04 Attachments: OFBIZ-4832.patch In current system when user upload original image system will automatically create rest of images that is small, medium, large, detail and thumbnail but when user upload specific image like small, medium or other image of product, system will remove all the images from specific product folder and place only recently updated image. Also if there will be medium, large or detail images are exist in system and user upload small image to complete image set then system removed all three images and add small image instead system should add new small image without touching other images. So this is a bug in 11.04. Provided patch in the task to resolve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: recent HashCrypt changes, and using salt-based password hashing
Hi Adam,
How would that be? That would be one per tenant in a multi-tenant setup? I
can imagine in a multi-tenant setup with the db backend not on derby (as we
all recommend) the upgrade/migration aspect can be enormous. Even more so
in a HAFO-setup.
Regards,
Pierre
Op 20 april 2012 01:23 schreef Adam Heath doo...@brainfood.com het
volgende:
On 04/19/2012 06:13 PM, Scott Gray wrote:
On 20/04/2012, at 9:49 AM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
Please just do your best to ensure backwards compatibility is
maintained. I can't imagine anything worse than doing an upgrade and
discovering that all my user passwords are no longer valid.
Sure, I've got things done as an array of handlers now(2 current, plus
1 new).
How do we feel about moving EntityKeyStore into a separate database?
It'd improve the security a little bit, and is rather simple to do
with ofbiz.
