Re: Remove PartyContactMech.(months|years)WithContactMech?

[Adrian Crum]

From what I recall, the idea is for a customer service person to ask 
how long the customer has been at that address, and the customer would 
respond with a time duration of months or years. There are no exact 
dates in the scenario.


I would recommend using a TimeDuration to calculate a fromDate based on 
the current date. So, the CSR enters months or years at current address, 
and a service calculates PartyContactMech.fromDate based on that 
information.


-Adrian

On 5/30/2012 12:34 AM, Adam Heath wrote:

I noticed the 2 fields in the subject, but didn't actually recoginize
them(I've been using ofbiz for a *long* time).  I did a big of
digging, and noticed that those fields were added to the model in
2006-05-04(1), and were first utilized when anonymous checkout was
added 2006-11-28(2).  There has been no real use of the 2 fields since
then.

Why do they have to exist?  Why can't DATE_TRUNC or some other sql
function be used?  Or normal Timestamp manipulation on fromDate/thruDate?

1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513
2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adrian Crum]

On 5/29/2012 5:49 AM, Adam Heath wrote:

On 05/25/2012 01:22 AM, Adam Heath wrote:

On 05/25/2012 12:26 AM, Jacques Le Roux wrote:

From: Jacques Le Roux jacques.le.r...@les7arts.com

From: Adam Heath doo...@brainfood.com

On 05/24/2012 04:05 PM, Jacques Le Roux wrote:

From: Adam Heath doo...@brainfood.com

On 05/24/2012 10:18 AM, Adam Heath wrote:
The idea was that you would parse the sqlCondition once, in a 
static

{} block somewhere, then at runtime, just build that map. This
builds-upon the map/list idea inherent in ofbiz.

I also had plans that you could store sql strings into a properties
file somewhere, so that they could possibly be changed by the
end-user
without having to recompile.

I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId) FROM
Party a LEFT JOIN PartyContactMech b USING (partyId), now that 
ofbiz

better supports conditions on the join clauses, esp. when combining
views into other views.


Thanks for the explanation,

So should we not rather create a Jira with all the needed in a patch
until this is finished?
Or maybe a branch would be easier?

Still with the slim-down idea in mind and as objective.


I like the slimdown, but tbh, I would like to see the framework/sql
stuff used more than it is(0 right now). Andrew Zeneski was an
original requestor for something that parsed sql into
EntityCondition. I took his suggestion, but went further, to allow
CREATE VIEW AS SELECT to work.

I've noticed that there aren't that many view definitions in ofbiz.
As I've been deprecating all this code recently, I've noticed java
code doing nested loop kinda-stuff, instead of just doing a view. I'm
guessing because view-xml is verbose and not how people actually 
think.


However, with what I committed, you can define the view using a SQL
syntax, which is then backed by a DynamicViewEntity.

I've seen rather impressive speedups just rewriting code to a single
SQL query, instead of java loops; the database can be rather
efficient. So making view writing simpler is a laudable goal.


Great, but still, why not a branch as long as it's not finished?

Also something which I think is pretty neat in the principle (I still
did not review the code) and would speed up views:
https://issues.apache.org/jira/browse/OFBIZ-4041

Jacques


BTW another stuff that could be part of this branch
https://issues.apache.org/jira/browse/OFBIZ-3575


Ok, I suppose. This weekend I'll create such a branch to
fix/improve the view system. This will also attempt to fix the reverse
cache clearing issues.


branches/improved-entityengine-features-20120528

Also see 1343540, which adds a README that has some things that we 
might want to implement in the branch.


Adam,

I commented on the commit, but you didn't reply, so I will try again in 
this thread.


If you don't mind, I would like to clean up the EntityConditionVisitor 
interface so it looks more like a conventional visitor pattern.


Also, I was wondering if we could add some timing metrics to the entity 
engine. Maybe keep an average query time per entity, and throw an 
exception when the average exceeds a configurable threshold. This would 
facilitate server overload management.


-Adrian

Re: Proposal for a new best practice for logging

[Adrian Crum]

Not long ago, Jacques posted a link to logging best practices in the 
wiki - but I can't find it now.


The wiki page listed logging levels and how they should be used. From 
what I recall, the information was pretty basic and it could be built 
out more.


-Adrian

On 5/30/2012 10:14 AM, Jacopo Cappellato wrote:

Would you agree in adopting the following as a best practice for OFBiz logging: 
do not include full maps/lists in the output or if really necessary limit this 
to verbose output.

For example, avoid code like this:

 Debug.logInfo(Capture [ + serviceName + ] :  + captureContext, 
module);

that generates the following output:

  [java] 2012-05-30 11:07:42,676 (http-bio-0.0.0.0-8443-exec-4) 
[PaymentGatewayServices.java:1752:INFO ] Capture [testCCCapture] : 
{userLogin=[GenericEntity:UserLogin][createdStamp,2012-05-30 
11:03:31.383(java.sql.Timestamp)][createdTxStamp,2012-05-30 
11:03:31.275(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2012-05-30
 11:03:57.136(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
11:03:57.049(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
 
orderPaymentPreference=[GenericEntity:OrderPaymentPreference][billingPostalCode,null()][createdByUserLogin,admin(java.lang.String)][createdDate,2008-04-23
 16:49:27.966(java.sql.Timestamp)][createdStamp,2012-05-30 
11:04:26.446(java.sql.Timestamp)][createdTxStamp,2012-05-30 
11:04:25.488(java.sql.Timestamp)][finAccountId,null()][lastUpdatedStamp,2012-05-30
 11:07:42.63(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][manualAuthCode,null()][manualRefNum,null()][maxAmount,50.85(java.math.BigDecimal)][needsNsfRetry,N(java.lang.String)][orderId,DEMO10090(java.lang.String)][orderItemSeqId,null()][orderPaymentPreferenceId,9000(java.lang.String)][overflowFlag,N(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][presentFlag,N(java.lang.String)][processAttempt,1(java.lang.Long)][productPricePurposeId,null()][securityCode,null()][shipGroupSeqId,null()][statusId,PAYMENT_AUTHORIZED(java.lang.String)][swipedFlag,N(java.lang.String)][track2,null()],
 paymentConfig=payment.properties, paymentGatewayConfigId=null, currency=USD, 
captureAmount=50.85, 
authTrans=[GenericEntity:PaymentGatewayResponse][altReference,1338368862594(java.lang.String)][amount,50.85(java.math.BigDecimal)][createdStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][createdTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][currencyUomId,USD(java.lang.String)][gatewayAvsResult,null()][gatewayCode,100(java.lang.String)][gatewayCvResult,null()][gatewayFlag,A(java.lang.String)][gatewayMessage,This
 is a test processor; no payments were captured or 
authorized.(java.lang.String)][gatewayScoreResult,null()][lastUpdatedStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][orderPaymentPreferenceId,9000(java.lang.String)][paymentGatewayResponseId,1(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][paymentServiceTypeEnumId,PRDS_PAY_REAUTH(java.lang.String)][referenceNum,1338368862594(java.lang.String)][resultBadCardNumber,null()][resultBadExpire,null()][resultDeclined,null()][resultNsf,null()][subReference,null()][transCodeEnumId,PGT_AUTHORIZE(java.lang.String)][transactionDate,2012-05-30
 11:07:42.619(java.sql.Timestamp)]}

If you will agree we could proceed at fixing existing code or at least make 
sure that new code is clean.

Kind regards,

Jacopo

ImageManagment in Ofbiz

[Rasool]

Hi,

Can you anyone tell about new image management in the ofbiz than
previous one.

--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/ImageManagment-in-Ofbiz-tp4632766.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Discussion: Using Javolution (was: jdk7 feature that might be good for ofbiz)

[Adrian Crum]

I am reposting this thread with a different subject to make sure 
everyone interested has a chance to comment.


To summarize (and to make sure we are all on the same page):

1. Javolution was added to the project in the JDK 1.4 days. David Jones 
ran some performance tests that demonstrated a performance boost when 
using Javolution Fast* classes instead of java.util.* classes.
2. Javolution acheived this performance boost by eliminating some 
garbage collection. The Fast* classes use object pools - where objects 
are returned to the pool when they are unused instead of being garbage 
collected.
3. JDK 1.5 introduced an improved garbage collector that eliminated the 
long pauses caused by previous garbage collectors. Also, it introduced 
the java.util.concurrent package - which is functionally similar to 
Javolution's concurrency. When OFBiz switched to the JDK 1.5 
requirement, the need for Javolution was eliminated - but it was kept in 
the project anyway.
4. No performance tests have been executed recently to see what kind of 
impact removing Javolution will have.
5. In the attached thread I recommend removing Javolution from object 
fields that are effectively static (either declared static or a field of 
an object that is cached indefinitely), because the pooled object is 
never returned to the pool - defeating the purpose of the library.

6. In the attached thread Adam suggests removing Javolution entirely.

-Adrian


On 5/27/2012 9:56 PM, Adrian Crum wrote:

On 5/27/2012 5:56 PM, Adam Heath wrote:

On 05/27/2012 07:09 AM, Jacques Le Roux wrote:

From: Adrian Crum adrian.c...@sandglass-software.com

FYI, in the Mini-language overhaul I interned the Element tag name
Strings.


Yes, that's really a good improvment! Things are much more clear now.
It's only in minilang though (I mean not in widgets actions yet), 
right?



Another thing to discuss is the proper use of Javolution and/or
whether we still need it.


Yes, I also wondered about that last week when willing to cast to a
TreeMap.
The fact that it's a one man project and will maybe less and less
supported http://javolution.org/#HISTORY is not yet an issue but 
could be


I personally see no need for javolution.  It's non-standard 
concurrency(java.util.concurrent).  It does it's own memory 
allocation, which prevents escape-analysis from working(allocating 
memory on the stack instead of the heap).




In the Mini-language overhaul I removed Javolution classes from model 
fields - since the models could be kept in memory (cached) 
indefinitely (resulting in borrowed objects that are never returned to 
the pool). I kept Javolution in the script execution path - which is 
the proper use from my perspective. I know you ran into issues with 
FastMap previously, but I don't remember the details.


If there are no objections, I can remove Javolution from Mini-language 
entirely.


-Adrian

[jira] [Created] (OFBIZ-4908) Update Forum Group not working, missing update request in form action.

[Harsha Chadhar (JIRA)]

Harsha Chadhar created OFBIZ-4908:
-

 Summary: Update Forum Group not working, missing update request in 
form action.
 Key: OFBIZ-4908
 URL: https://issues.apache.org/jira/browse/OFBIZ-4908
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release 10.04, Release 09.04, Release Branch 11.04, SVN 
trunk
Reporter: Harsha Chadhar
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
Release 09.04


URL : https://demo-trunk.ofbiz.apache.org:8443/content/control/findForumGroups
https://demo-stable.ofbiz.apache.org:8443/content/control/findForumGroups

Missing target request : updateForumGroup in the form ListForumGroups.

--
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-4908) Update Forum Group not working, missing update request in form action.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4908:
--

Attachment: OFBIZ-4908.patch

 Update Forum Group not working, missing update request in form action.
 --

 Key: OFBIZ-4908
 URL: https://issues.apache.org/jira/browse/OFBIZ-4908
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
 trunk
Reporter: Harsha Chadhar
 Fix For: Release 09.04, Release Branch 10.04, Release Branch 
 11.04, SVN trunk

 Attachments: OFBIZ-4908.patch


 URL : https://demo-trunk.ofbiz.apache.org:8443/content/control/findForumGroups
 https://demo-stable.ofbiz.apache.org:8443/content/control/findForumGroups
 Missing target request : updateForumGroup in the form ListForumGroups.

--
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-4908) Update Forum Group not working, missing update request in form action.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4908:
--

Attachment: (was: OFBIZ-4908.patch)

 Update Forum Group not working, missing update request in form action.
 --

 Key: OFBIZ-4908
 URL: https://issues.apache.org/jira/browse/OFBIZ-4908
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
 trunk
Reporter: Harsha Chadhar
 Fix For: Release 09.04, Release Branch 10.04, Release Branch 
 11.04, SVN trunk

 Attachments: OFBIZ-4908.patch


 URL : https://demo-trunk.ofbiz.apache.org:8443/content/control/findForumGroups
 https://demo-stable.ofbiz.apache.org:8443/content/control/findForumGroups
 Missing target request : updateForumGroup in the form ListForumGroups.

--
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-4908) Update Forum Group not working, missing update request in form action.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4908:
--

Attachment: OFBIZ-4908.patch

 Update Forum Group not working, missing update request in form action.
 --

 Key: OFBIZ-4908
 URL: https://issues.apache.org/jira/browse/OFBIZ-4908
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
 trunk
Reporter: Harsha Chadhar
 Fix For: Release 09.04, Release Branch 10.04, Release Branch 
 11.04, SVN trunk

 Attachments: OFBIZ-4908.patch


 URL : https://demo-trunk.ofbiz.apache.org:8443/content/control/findForumGroups
 https://demo-stable.ofbiz.apache.org:8443/content/control/findForumGroups
 Missing target request : updateForumGroup in the form ListForumGroups.

--
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: using subquery in drop down list for two entities..

[Himanil Gupta]

Hello pravin,

you can fetch data from 'Forms' in your dropdown list by using 'action' tag 
when two entities are used (namely 'helloPersonHobby' and 'hello_hobby'),
see example below:-

*_ From Widget:_*
-- ExampleFroms .xml

form name=ExampleForm type=single target=..
   action
entity-one value-field=helloPersonHobby 
entity-name=hello_person_hobby
   field-map field-name=hello_person_id value=1/
/entity-one
   /action
   field name=examplelist title=ExampleList
drop-down allow-empty=true
entity-options entity-name=hello_hobby key-field-name=hello_hobby_Id 
description=${hello_hobby_Id}
entity-constraint name=hello_hobby_Id operator=not-equals 
env-name=helloPersonHobby.hello_hobby_Id/
/entity-options
   /drop-down
/field
/form


Thanks  regards
--
Himanil Gupta
Enterprise Software Developer
HotWax Media Indore
http://www.hotwaxmedia.com/


On 05/24/2012 12:25 PM, pravin wrote:

this is my sql query.. this answer i need to show in a drop down list..
select * from hello_hobby where hello_hobby_id NOT IN
(select hello_hobby_id from hello_person_hobby where
hello_person_id='1')

Am using the following code to display the query select hello_hobby_id from
hello_person_hobby where hello_person_id='1'

entity-options entity-name=HelloPersonHobby
description=${helloHobbyId}
  entity-constraint name=helloPersonId operator=equals
value=${helloPersonId}/

I dono how to use for two queries

--
View this message in 
context:http://ofbiz.135035.n4.nabble.com/using-subquery-in-drop-down-list-for-two-entities-tp4632377.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] [Created] (OFBIZ-4909) OFBiz contains Sun extensions and it will not run on Linux or on the IBM Z servers

[Kirk Ritchey (JIRA)]

Kirk Ritchey created OFBIZ-4909:
---

 Summary: OFBiz  contains Sun extensions and it will not run on 
Linux or on the IBM Z servers  
 Key: OFBIZ-4909
 URL: https://issues.apache.org/jira/browse/OFBIZ-4909
 Project: OFBiz
  Issue Type: Wish
  Components: ALL APPLICATIONS
Affects Versions: Release 10.04
 Environment: IBM Z servers  Linux OS
Reporter: Kirk Ritchey
 Fix For: Release Branch 10.04


OFBiz contains Sun extensions and will not run on Linux or on the IBM Z 
servers. 1) Confirm this 2) advise how to overcome this show-stopper

--
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-4909) OFBiz contains Sun extensions and it will not run on Linux or on the IBM Z servers

[Adrian Crum (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285689#comment-13285689
 ] 

Adrian Crum commented on OFBIZ-4909:


Could you be more specific? What extensions are you referring to?

 OFBiz  contains Sun extensions and it will not run on Linux or on the IBM Z 
 servers  
 -

 Key: OFBIZ-4909
 URL: https://issues.apache.org/jira/browse/OFBIZ-4909
 Project: OFBiz
  Issue Type: Wish
  Components: ALL APPLICATIONS
Affects Versions: Release 10.04
 Environment: IBM Z servers  Linux OS
Reporter: Kirk Ritchey
 Fix For: Release Branch 10.04


 OFBiz contains Sun extensions and will not run on Linux or on the IBM Z 
 servers. 1) Confirm this 2) advise how to overcome this show-stopper

--
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: Proposal for a new best practice for logging

[Ashish Vijaywargiya]

+1.

--
Ashish

On Wed, May 30, 2012 at 2:44 PM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 Would you agree in adopting the following as a best practice for OFBiz
 logging: do not include full maps/lists in the output or if really
 necessary limit this to verbose output.

 For example, avoid code like this:

Debug.logInfo(Capture [ + serviceName + ] :  + captureContext,
 module);

 that generates the following output:

 [java] 2012-05-30 11:07:42,676 (http-bio-0.0.0.0-8443-exec-4)
 [PaymentGatewayServices.java:1752:INFO ] Capture [testCCCapture] :
 {userLogin=[GenericEntity:UserLogin][createdStamp,2012-05-30
 11:03:31.383(java.sql.Timestamp)][createdTxStamp,2012-05-30
 11:03:31.275(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2012-05-30
 11:03:57.136(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30
 11:03:57.049(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
 orderPaymentPreference=[GenericEntity:OrderPaymentPreference][billingPostalCode,null()][createdByUserLogin,admin(java.lang.String)][createdDate,2008-04-23
 16:49:27.966(java.sql.Timestamp)][createdStamp,2012-05-30
 11:04:26.446(java.sql.Timestamp)][createdTxStamp,2012-05-30
 11:04:25.488(java.sql.Timestamp)][finAccountId,null()][lastUpdatedStamp,2012-05-30
 11:07:42.63(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30
 11:07:38.495(java.sql.Timestamp)][manualAuthCode,null()][manualRefNum,null()][maxAmount,50.85(java.math.BigDecimal)][needsNsfRetry,N(java.lang.String)][orderId,DEMO10090(java.lang.String)][orderItemSeqId,null()][orderPaymentPreferenceId,9000(java.lang.String)][overflowFlag,N(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][presentFlag,N(java.lang.String)][processAttempt,1(java.lang.Long)][productPricePurposeId,null()][securityCode,null()][shipGroupSeqId,null()][statusId,PAYMENT_AUTHORIZED(java.lang.String)][swipedFlag,N(java.lang.String)][track2,null()],
 paymentConfig=payment.properties, paymentGatewayConfigId=null,
 currency=USD, captureAmount=50.85,
 authTrans=[GenericEntity:PaymentGatewayResponse][altReference,1338368862594(java.lang.String)][amount,50.85(java.math.BigDecimal)][createdStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][createdTxStamp,2012-05-30
 11:07:38.495(java.sql.Timestamp)][currencyUomId,USD(java.lang.String)][gatewayAvsResult,null()][gatewayCode,100(java.lang.String)][gatewayCvResult,null()][gatewayFlag,A(java.lang.String)][gatewayMessage,This
 is a test processor; no payments were captured or
 authorized.(java.lang.String)][gatewayScoreResult,null()][lastUpdatedStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30
 11:07:38.495(java.sql.Timestamp)][orderPaymentPreferenceId,9000(java.lang.String)][paymentGatewayResponseId,1(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][paymentServiceTypeEnumId,PRDS_PAY_REAUTH(java.lang.String)][referenceNum,1338368862594(java.lang.String)][resultBadCardNumber,null()][resultBadExpire,null()][resultDeclined,null()][resultNsf,null()][subReference,null()][transCodeEnumId,PGT_AUTHORIZE(java.lang.String)][transactionDate,2012-05-30
 11:07:42.619(java.sql.Timestamp)]}

 If you will agree we could proceed at fixing existing code or at least
 make sure that new code is clean.

 Kind regards,

 Jacopo

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adam Heath]

On 05/30/2012 02:46 AM, Adrian Crum wrote:
 On 5/29/2012 5:49 AM, Adam Heath wrote:
 On 05/25/2012 01:22 AM, Adam Heath wrote:
 On 05/25/2012 12:26 AM, Jacques Le Roux wrote:
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 From: Adam Heath doo...@brainfood.com
 On 05/24/2012 04:05 PM, Jacques Le Roux wrote:
 From: Adam Heath doo...@brainfood.com
 On 05/24/2012 10:18 AM, Adam Heath wrote:
 The idea was that you would parse the sqlCondition once, in a
 static
 {} block somewhere, then at runtime, just build that map. This
 builds-upon the map/list idea inherent in ofbiz.

 I also had plans that you could store sql strings into a
 properties
 file somewhere, so that they could possibly be changed by the
 end-user
 without having to recompile.

 I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId)
 FROM
 Party a LEFT JOIN PartyContactMech b USING (partyId), now
 that ofbiz
 better supports conditions on the join clauses, esp. when
 combining
 views into other views.

 Thanks for the explanation,

 So should we not rather create a Jira with all the needed in a
 patch
 until this is finished?
 Or maybe a branch would be easier?

 Still with the slim-down idea in mind and as objective.

 I like the slimdown, but tbh, I would like to see the framework/sql
 stuff used more than it is(0 right now). Andrew Zeneski was an
 original requestor for something that parsed sql into
 EntityCondition. I took his suggestion, but went further, to allow
 CREATE VIEW AS SELECT to work.

 I've noticed that there aren't that many view definitions in ofbiz.
 As I've been deprecating all this code recently, I've noticed java
 code doing nested loop kinda-stuff, instead of just doing a
 view. I'm
 guessing because view-xml is verbose and not how people actually
 think.

 However, with what I committed, you can define the view using a SQL
 syntax, which is then backed by a DynamicViewEntity.

 I've seen rather impressive speedups just rewriting code to a
 single
 SQL query, instead of java loops; the database can be rather
 efficient. So making view writing simpler is a laudable goal.

 Great, but still, why not a branch as long as it's not finished?

 Also something which I think is pretty neat in the principle (I
 still
 did not review the code) and would speed up views:
 https://issues.apache.org/jira/browse/OFBIZ-4041

 Jacques

 BTW another stuff that could be part of this branch
 https://issues.apache.org/jira/browse/OFBIZ-3575

 Ok, I suppose. This weekend I'll create such a branch to
 fix/improve the view system. This will also attempt to fix the reverse
 cache clearing issues.

 branches/improved-entityengine-features-20120528

 Also see 1343540, which adds a README that has some things that we
 might want to implement in the branch.
 
 Adam,
 
 I commented on the commit, but you didn't reply, so I will try again
 in this thread.

I saw, but didn't really think it needed a comment.  I guess I should
have given an affirmative response, instead of no response.  I assumed
that no response is not negative(yeah, that's a double negative).

 
 If you don't mind, I would like to clean up the EntityConditionVisitor
 interface so it looks more like a conventional visitor pattern.

I'm down to whatever other people for, within reason.  Tbh, I'm
currently tweaking EntityFieldValue, which is used by
ModelViewEntity.ViewEntityCondition, in a hackish way; it means I'm
having to tweak the visitor pattern, which sucks.

I'm the one who added the visitor pattern all those ages ago(goes back
to svn.ofbiz.org timeframe); I'd be fine with ripping it completely
out, as we(brainfood) don't use it anywhere.

 Also, I was wondering if we could add some timing metrics to the
 entity engine. Maybe keep an average query time per entity, and throw
 an exception when the average exceeds a configurable threshold. This
 would facilitate server overload management.

There is already code that does that, when a query takes a long time.
 If you do some stats(make it per-entity), make certain to use
AtomicInteger(or other AtomicFoo class).  You don't need to use
ConcurrentMap, as the list of entities to gather stats against is
static.  Just created the map at startup, or even store the stats in
ModelEntity.

Maybe the following will do what you want.  It's non-blocking
concurrent, makes use of work-borrowing type stuff(the double loop
update of 2 variables).

class Statistics {
 class Stat {
  AtomicReferenceLong[] countDurationAvgRef;
  QueueLong window;

  void add(long nanos) {
   window.add(nanos);
   while (true) {
Long[] oldValues = countDurationAvgRef.get();
long newCount = oldValues[0] + 1;
Long[] newValues = new Long[] {
 newCount,
 oldValues[1] + nanos,
 oldValues[2] + (nanos / newCount)
};
if (countDurationAvgRef.compareAndSet(oldValues, newValues)) {
 break;
}
   }
   while (true) {
Long[] oldValues = countDurationAvgRef.get();
long oldCount = oldValues[0];
if (oldCount = maxSize) {
  

Re: Proposal for a new best practice for logging

[Adam Heath]

On 05/30/2012 04:14 AM, Jacopo Cappellato wrote:
 Would you agree in adopting the following as a best practice for OFBiz 
 logging: do not include full maps/lists in the output or if really necessary 
 limit this to verbose output.
 
 For example, avoid code like this:
 
 Debug.logInfo(Capture [ + serviceName + ] :  + captureContext, 
 module);

Debug.logInfo(Capture [%s] : %s, module, serviceName, captureContext);

ps: this has been supported for a while now.

Re: Discussion: Using Javolution

[Adam Heath]

On 05/30/2012 06:24 AM, Adrian Crum wrote:
 I am reposting this thread with a different subject to make sure
 everyone interested has a chance to comment.
 
 To summarize (and to make sure we are all on the same page):
 
 1. Javolution was added to the project in the JDK 1.4 days. David
 Jones ran some performance tests that demonstrated a performance boost
 when using Javolution Fast* classes instead of java.util.* classes.
 2. Javolution acheived this performance boost by eliminating some
 garbage collection. The Fast* classes use object pools - where objects
 are returned to the pool when they are unused instead of being garbage
 collected.
 3. JDK 1.5 introduced an improved garbage collector that eliminated
 the long pauses caused by previous garbage collectors. Also, it
 introduced the java.util.concurrent package - which is functionally
 similar to Javolution's concurrency. When OFBiz switched to the JDK
 1.5 requirement, the need for Javolution was eliminated - but it was
 kept in the project anyway.
 4. No performance tests have been executed recently to see what kind
 of impact removing Javolution will have.
 5. In the attached thread I recommend removing Javolution from object
 fields that are effectively static (either declared static or a field
 of an object that is cached indefinitely), because the pooled object
 is never returned to the pool - defeating the purpose of the library.
 6. In the attached thread Adam suggests removing Javolution entirely.

7: In JDK 1.6, escape analysis is used to figure out that some objects
can be directly allocated on the stack, instead of the heap.  Using
pooled objects precludes this.

When using EntityCondition pooled objects, where the condition will
eventually be frozen and used as a key in a cache, it makes no sense
really to pool it at all.

When doing the actual query, escape analysis *might* detect that the
condition could be allocated on the stack(it'd have to look at several
deep method calls).

Re: Proposal for a new best practice for logging

[Adam Heath]

On 05/30/2012 04:14 AM, Jacopo Cappellato wrote:
 Would you agree in adopting the following as a best practice for OFBiz 
 logging: do not include full maps/lists in the output or if really necessary 
 limit this to verbose output.
 
 For example, avoid code like this:
 
 Debug.logInfo(Capture [ + serviceName + ] :  + captureContext, 
 module);

Additionally, this is *SUPER BAD NONO DEATH* for PCI compliance.  In
the following example, it is printing out a CreditCard entity, which
is mightly frowned upon.  Even if in this case it's an entity that
encrypts it's fields during toString(), there may be a parameters in
the context that contains an incoming credit card number that is
unencrypted.

 
 that generates the following output:
 
  [java] 2012-05-30 11:07:42,676 (http-bio-0.0.0.0-8443-exec-4) 
 [PaymentGatewayServices.java:1752:INFO ] Capture [testCCCapture] : 
 {userLogin=[GenericEntity:UserLogin][createdStamp,2012-05-30 
 11:03:31.383(java.sql.Timestamp)][createdTxStamp,2012-05-30 
 11:03:31.275(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2012-05-30
  11:03:57.136(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
 11:03:57.049(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
  
 orderPaymentPreference=[GenericEntity:OrderPaymentPreference][billingPostalCode,null()][createdByUserLogin,admin(java.lang.String)][createdDate,2008-04-23
  16:49:27.966(java.sql.Timest
amp)][createdStamp,2012-05-30 
11:04:26.446(java.sql.Timestamp)][createdTxStamp,2012-05-30 
11:04:25.488(java.sql.Timestamp)][finAccountId,null()][lastUpdatedStamp,2012-05-30
 11:07:42.63(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][manualAuthCode,null()][manualRefNum,null()][maxAmount,50.85(java.math.BigDecimal)][needsNsfRetry,N(java.lang.String)][orderId,DEMO10090(java.lang.String)][orderItemSeqId,null()][orderPaymentPreferenceId,9000(java.lang.String)][overflowFlag,N(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][presentFlag,N(java.lang.String)][processAttempt,1(java.lang.Long)][productPricePurposeId,null()][securityCode,null()][shipGroupSeqId,null()][statusId,PAYMENT_AUTHORIZED(java.lang.String)][swipedFlag,N(java.lang.String)][track2,null()],
 paymentConfig=payment.properties, paymentGatewayConfigId=null, currency=USD, 
captureAmount=50.85, authTrans=[GenericEntity:PaymentGa
tewayResponse][altReference,1338368862594(java.lang.String)][amount,50.85(java.math.BigDecimal)][createdStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][createdTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][currencyUomId,USD(java.lang.String)][gatewayAvsResult,null()][gatewayCode,100(java.lang.String)][gatewayCvResult,null()][gatewayFlag,A(java.lang.String)][gatewayMessage,This
 is a test processor; no payments were captured or 
authorized.(java.lang.String)][gatewayScoreResult,null()][lastUpdatedStamp,2012-05-30
 11:07:42.619(java.sql.Timestamp)][lastUpdatedTxStamp,2012-05-30 
11:07:38.495(java.sql.Timestamp)][orderPaymentPreferenceId,9000(java.lang.String)][paymentGatewayResponseId,1(java.lang.String)][paymentMethodId,9015(java.lang.String)][paymentMethodTypeId,CREDIT_CARD(java.lang.String)][paymentServiceTypeEnumId,PRDS_PAY_REAUTH(java.lang.String)][referenceNum,1338368862594(java.lang.String)][resultBadCardNumber,null()][resultBadExpire,null()][resultDeclined,null
()][resultNsf,null()][subReference,null()][transCodeEnumId,PGT_AUTHORIZE(java.lang.String)][transactionDate,2012-05-30
 11:07:42.619(java.sql.Timestamp)]}
 
 If you will agree we could proceed at fixing existing code or at least make 
 sure that new code is clean.
 
 Kind regards,
 
 Jacopo
 

Re: Proposal for a new best practice for logging

[Jacopo Cappellato]

On May 30, 2012, at 5:36 PM, Adam Heath wrote:

 Additionally, this is *SUPER BAD NONO DEATH* for PCI compliance.

Right!... and I actually didn't pick this example randomly ;-)

Jacopo

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adrian Crum]

On 5/30/2012 4:30 PM, Adam Heath wrote:

On 05/30/2012 02:46 AM, Adrian Crum wrote:

On 5/29/2012 5:49 AM, Adam Heath wrote:

On 05/25/2012 01:22 AM, Adam Heath wrote:

On 05/25/2012 12:26 AM, Jacques Le Roux wrote:

From: Jacques Le Rouxjacques.le.r...@les7arts.com

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 04:05 PM, Jacques Le Roux wrote:

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 10:18 AM, Adam Heath wrote:
The idea was that you would parse the sqlCondition once, in a
static
{} block somewhere, then at runtime, just build that map. This
builds-upon the map/list idea inherent in ofbiz.

I also had plans that you could store sql strings into a
properties
file somewhere, so that they could possibly be changed by the
end-user
without having to recompile.

I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId)
FROM
Party a LEFT JOIN PartyContactMech b USING (partyId), now
that ofbiz
better supports conditions on the join clauses, esp. when
combining
views into other views.

Thanks for the explanation,

So should we not rather create a Jira with all the needed in a
patch
until this is finished?
Or maybe a branch would be easier?

Still with the slim-down idea in mind and as objective.

I like the slimdown, but tbh, I would like to see the framework/sql
stuff used more than it is(0 right now). Andrew Zeneski was an
original requestor for something that parsed sql into
EntityCondition. I took his suggestion, but went further, to allow
CREATE VIEW AS SELECT to work.

I've noticed that there aren't that many view definitions in ofbiz.
As I've been deprecating all this code recently, I've noticed java
code doing nested loop kinda-stuff, instead of just doing a
view. I'm
guessing because view-xml is verbose and not how people actually
think.

However, with what I committed, you can define the view using a SQL
syntax, which is then backed by a DynamicViewEntity.

I've seen rather impressive speedups just rewriting code to a
single
SQL query, instead of java loops; the database can be rather
efficient. So making view writing simpler is a laudable goal.

Great, but still, why not a branch as long as it's not finished?

Also something which I think is pretty neat in the principle (I
still
did not review the code) and would speed up views:
https://issues.apache.org/jira/browse/OFBIZ-4041

Jacques

BTW another stuff that could be part of this branch
https://issues.apache.org/jira/browse/OFBIZ-3575

Ok, I suppose. This weekend I'll create such a branch to
fix/improve the view system. This will also attempt to fix the reverse
cache clearing issues.

branches/improved-entityengine-features-20120528

Also see 1343540, which adds a README that has some things that we
might want to implement in the branch.

Adam,

I commented on the commit, but you didn't reply, so I will try again
in this thread.

I saw, but didn't really think it needed a comment.  I guess I should
have given an affirmative response, instead of no response.  I assumed
that no response is not negative(yeah, that's a double negative).


If you don't mind, I would like to clean up the EntityConditionVisitor
interface so it looks more like a conventional visitor pattern.

I'm down to whatever other people for, within reason.  Tbh, I'm
currently tweaking EntityFieldValue, which is used by
ModelViewEntity.ViewEntityCondition, in a hackish way; it means I'm
having to tweak the visitor pattern, which sucks.

I'm the one who added the visitor pattern all those ages ago(goes back
to svn.ofbiz.org timeframe); I'd be fine with ripping it completely
out, as we(brainfood) don't use it anywhere.


I need to reacquaint myself with the entity engine code. I was thinking 
the visitor pattern could be used to construct the SQL string instead of 
the complicated if-then-else code spread across a number of classes. We 
could use different visitors for different databases.


From my perspective, the entity engine implementation seems a bit 
tangled, and I was trying to come up with a strategy to simplify things.




Also, I was wondering if we could add some timing metrics to the
entity engine. Maybe keep an average query time per entity, and throw
an exception when the average exceeds a configurable threshold. This
would facilitate server overload management.

There is already code that does that, when a query takes a long time.


I don't see any code that does that.


  If you do some stats(make it per-entity), make certain to use
AtomicInteger(or other AtomicFoo class).  You don't need to use
ConcurrentMap, as the list of entities to gather stats against is
static.  Just created the map at startup, or even store the stats in
ModelEntity.

Maybe the following will do what you want.  It's non-blocking
concurrent, makes use of work-borrowing type stuff(the double loop
update of 2 variables).

class Statistics {
  class Stat {
   AtomicReferenceLong[]  countDurationAvgRef;
   QueueLong  window;

   void add(long nanos) {
window.add(nanos);

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adam Heath]

On 05/30/2012 11:47 AM, Adrian Crum wrote:
 
 On 5/30/2012 4:30 PM, Adam Heath wrote:
 On 05/30/2012 02:46 AM, Adrian Crum wrote:
 On 5/29/2012 5:49 AM, Adam Heath wrote:
 On 05/25/2012 01:22 AM, Adam Heath wrote:
 On 05/25/2012 12:26 AM, Jacques Le Roux wrote:
 From: Jacques Le Rouxjacques.le.r...@les7arts.com
 From: Adam Heathdoo...@brainfood.com
 On 05/24/2012 04:05 PM, Jacques Le Roux wrote:
 From: Adam Heathdoo...@brainfood.com
 On 05/24/2012 10:18 AM, Adam Heath wrote:
 The idea was that you would parse the sqlCondition once, in a
 static
 {} block somewhere, then at runtime, just build that map. This
 builds-upon the map/list idea inherent in ofbiz.

 I also had plans that you could store sql strings into a
 properties
 file somewhere, so that they could possibly be changed by the
 end-user
 without having to recompile.

 I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId)
 FROM
 Party a LEFT JOIN PartyContactMech b USING (partyId), now
 that ofbiz
 better supports conditions on the join clauses, esp. when
 combining
 views into other views.
 Thanks for the explanation,

 So should we not rather create a Jira with all the needed in a
 patch
 until this is finished?
 Or maybe a branch would be easier?

 Still with the slim-down idea in mind and as objective.
 I like the slimdown, but tbh, I would like to see the
 framework/sql
 stuff used more than it is(0 right now). Andrew Zeneski was an
 original requestor for something that parsed sql into
 EntityCondition. I took his suggestion, but went further, to
 allow
 CREATE VIEW AS SELECT to work.

 I've noticed that there aren't that many view definitions in
 ofbiz.
 As I've been deprecating all this code recently, I've noticed
 java
 code doing nested loop kinda-stuff, instead of just doing a
 view. I'm
 guessing because view-xml is verbose and not how people actually
 think.

 However, with what I committed, you can define the view using
 a SQL
 syntax, which is then backed by a DynamicViewEntity.

 I've seen rather impressive speedups just rewriting code to a
 single
 SQL query, instead of java loops; the database can be rather
 efficient. So making view writing simpler is a laudable goal.
 Great, but still, why not a branch as long as it's not finished?

 Also something which I think is pretty neat in the principle (I
 still
 did not review the code) and would speed up views:
 https://issues.apache.org/jira/browse/OFBIZ-4041

 Jacques
 BTW another stuff that could be part of this branch
 https://issues.apache.org/jira/browse/OFBIZ-3575
 Ok, I suppose. This weekend I'll create such a branch to
 fix/improve the view system. This will also attempt to fix the
 reverse
 cache clearing issues.
 branches/improved-entityengine-features-20120528

 Also see 1343540, which adds a README that has some things that we
 might want to implement in the branch.
 Adam,

 I commented on the commit, but you didn't reply, so I will try again
 in this thread.
 I saw, but didn't really think it needed a comment.  I guess I should
 have given an affirmative response, instead of no response.  I assumed
 that no response is not negative(yeah, that's a double negative).

 If you don't mind, I would like to clean up the EntityConditionVisitor
 interface so it looks more like a conventional visitor pattern.
 I'm down to whatever other people for, within reason.  Tbh, I'm
 currently tweaking EntityFieldValue, which is used by
 ModelViewEntity.ViewEntityCondition, in a hackish way; it means I'm
 having to tweak the visitor pattern, which sucks.

 I'm the one who added the visitor pattern all those ages ago(goes back
 to svn.ofbiz.org timeframe); I'd be fine with ripping it completely
 out, as we(brainfood) don't use it anywhere.
 
 I need to reacquaint myself with the entity engine code. I was
 thinking the visitor pattern could be used to construct the SQL string
 instead of the complicated if-then-else code spread across a number of
 classes. We could use different visitors for different databases.

Yes, that was my original thought.  However, I don't think it's that
simple anymore.  I've got a much better understanding of the entity
system since I wrote the visitor stuff.

I'd actually like to see my generic sql code be used to represent
entitymodel, then add sql-sql conversion code.  I have an xslt that
can read *all* entitymodel.xml and convert it to entitymodel.sql, or
entitymodel.java.  I used the former to verify that my sql parsing was
featureful enough.

 From my perspective, the entity engine implementation seems a bit
 tangled, and I was trying to come up with a strategy to simplify things.

It's not too bad, imho; just has some issues with view abstraction
that can't be currently represented.  It's getting much closer to not
having to do raw sql anymore thru jdbc.

 Also, I was wondering if we could add some timing metrics to the
 entity engine. Maybe keep an average query time per entity, and throw
 an exception when the average exceeds a configurable 

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adrian Crum]

On 5/30/2012 6:06 PM, Adam Heath wrote:

On 05/30/2012 11:47 AM, Adrian Crum wrote:

On 5/30/2012 4:30 PM, Adam Heath wrote:

On 05/30/2012 02:46 AM, Adrian Crum wrote:

On 5/29/2012 5:49 AM, Adam Heath wrote:

On 05/25/2012 01:22 AM, Adam Heath wrote:

On 05/25/2012 12:26 AM, Jacques Le Roux wrote:

From: Jacques Le Rouxjacques.le.r...@les7arts.com

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 04:05 PM, Jacques Le Roux wrote:

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 10:18 AM, Adam Heath wrote:
The idea was that you would parse the sqlCondition once, in a
static
{} block somewhere, then at runtime, just build that map. This
builds-upon the map/list idea inherent in ofbiz.

I also had plans that you could store sql strings into a
properties
file somewhere, so that they could possibly be changed by the
end-user
without having to recompile.

I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId)
FROM
Party a LEFT JOIN PartyContactMech b USING (partyId), now
that ofbiz
better supports conditions on the join clauses, esp. when
combining
views into other views.

Thanks for the explanation,

So should we not rather create a Jira with all the needed in a
patch
until this is finished?
Or maybe a branch would be easier?

Still with the slim-down idea in mind and as objective.

I like the slimdown, but tbh, I would like to see the
framework/sql
stuff used more than it is(0 right now). Andrew Zeneski was an
original requestor for something that parsed sql into
EntityCondition. I took his suggestion, but went further, to
allow
CREATE VIEW AS SELECT to work.

I've noticed that there aren't that many view definitions in
ofbiz.
As I've been deprecating all this code recently, I've noticed
java
code doing nested loop kinda-stuff, instead of just doing a
view. I'm
guessing because view-xml is verbose and not how people actually
think.

However, with what I committed, you can define the view using
a SQL
syntax, which is then backed by a DynamicViewEntity.

I've seen rather impressive speedups just rewriting code to a
single
SQL query, instead of java loops; the database can be rather
efficient. So making view writing simpler is a laudable goal.

Great, but still, why not a branch as long as it's not finished?

Also something which I think is pretty neat in the principle (I
still
did not review the code) and would speed up views:
https://issues.apache.org/jira/browse/OFBIZ-4041

Jacques

BTW another stuff that could be part of this branch
https://issues.apache.org/jira/browse/OFBIZ-3575

Ok, I suppose. This weekend I'll create such a branch to
fix/improve the view system. This will also attempt to fix the
reverse
cache clearing issues.

branches/improved-entityengine-features-20120528

Also see 1343540, which adds a README that has some things that we
might want to implement in the branch.

Adam,

I commented on the commit, but you didn't reply, so I will try again
in this thread.

I saw, but didn't really think it needed a comment.  I guess I should
have given an affirmative response, instead of no response.  I assumed
that no response is not negative(yeah, that's a double negative).



Non-communication is not communication. ;)





If you don't mind, I would like to clean up the EntityConditionVisitor
interface so it looks more like a conventional visitor pattern.

I'm down to whatever other people for, within reason.  Tbh, I'm
currently tweaking EntityFieldValue, which is used by
ModelViewEntity.ViewEntityCondition, in a hackish way; it means I'm
having to tweak the visitor pattern, which sucks.

I'm the one who added the visitor pattern all those ages ago(goes back
to svn.ofbiz.org timeframe); I'd be fine with ripping it completely
out, as we(brainfood) don't use it anywhere.

I need to reacquaint myself with the entity engine code. I was
thinking the visitor pattern could be used to construct the SQL string
instead of the complicated if-then-else code spread across a number of
classes. We could use different visitors for different databases.

Yes, that was my original thought.  However, I don't think it's that
simple anymore.  I've got a much better understanding of the entity
system since I wrote the visitor stuff.

I'd actually like to see my generic sql code be used to represent
entitymodel, then add sql-sql conversion code.  I have an xslt that
can read *all* entitymodel.xml and convert it to entitymodel.sql, or
entitymodel.java.  I used the former to verify that my sql parsing was
featureful enough.



You lost me. How will this look when it is finished? Will the entity 
model XML files be replaced with SQL files?






 From my perspective, the entity engine implementation seems a bit
tangled, and I was trying to come up with a strategy to simplify things.

It's not too bad, imho; just has some issues with view abstraction
that can't be currently represented.  It's getting much closer to not
having to do raw sql anymore thru jdbc.


Also, I was wondering if we could add some timing 

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adam Heath]

On 05/30/2012 12:22 PM, Adrian Crum wrote:
 
 I need to reacquaint myself with the entity engine code. I was
 thinking the visitor pattern could be used to construct the SQL string
 instead of the complicated if-then-else code spread across a number of
 classes. We could use different visitors for different databases.
 Yes, that was my original thought.  However, I don't think it's that
 simple anymore.  I've got a much better understanding of the entity
 system since I wrote the visitor stuff.

 I'd actually like to see my generic sql code be used to represent
 entitymodel, then add sql-sql conversion code.  I have an xslt that
 can read *all* entitymodel.xml and convert it to entitymodel.sql, or
 entitymodel.java.  I used the former to verify that my sql parsing was
 featureful enough.
 
 
 You lost me. How will this look when it is finished? Will the entity
 model XML files be replaced with SQL files?

No.  I just used the xslt to verify that the actual sql parsing code,
and the built-up object graph, were capable of representing everything
mentioned in entitymodel.xml.

 Also, I was wondering if we could add some timing metrics to the
 entity engine. Maybe keep an average query time per entity, and
 throw
 an exception when the average exceeds a configurable threshold. This
 would facilitate server overload management.
 There is already code that does that, when a query takes a long time.
 I don't see any code that does that.
 I've seen lines in the log file where queries take too long.
 GenericDAO.selectListIteratorByCondition() has an example for that,
 but it's not done in select().
 
 
 Thanks. That code simply logs the time it took to execute a query. I'm
 proposing code that will monitor queries and provide feedback to a
 server management process.

Sure.  The quickly typed example class I gave would help in that.

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Adrian Crum]

On 5/30/2012 6:29 PM, Adam Heath wrote:

On 05/30/2012 12:22 PM, Adrian Crum wrote:

I need to reacquaint myself with the entity engine code. I was
thinking the visitor pattern could be used to construct the SQL string
instead of the complicated if-then-else code spread across a number of
classes. We could use different visitors for different databases.

Yes, that was my original thought.  However, I don't think it's that
simple anymore.  I've got a much better understanding of the entity
system since I wrote the visitor stuff.

I'd actually like to see my generic sql code be used to represent
entitymodel, then add sql-sql conversion code.  I have an xslt that
can read *all* entitymodel.xml and convert it to entitymodel.sql, or
entitymodel.java.  I used the former to verify that my sql parsing was
featureful enough.


You lost me. How will this look when it is finished? Will the entity
model XML files be replaced with SQL files?

No.  I just used the xslt to verify that the actual sql parsing code,
and the built-up object graph, were capable of representing everything
mentioned in entitymodel.xml.


Also, I was wondering if we could add some timing metrics to the
entity engine. Maybe keep an average query time per entity, and
throw
an exception when the average exceeds a configurable threshold. This
would facilitate server overload management.

There is already code that does that, when a query takes a long time.

I don't see any code that does that.

I've seen lines in the log file where queries take too long.
GenericDAO.selectListIteratorByCondition() has an example for that,
but it's not done in select().


Thanks. That code simply logs the time it took to execute a query. I'm
proposing code that will monitor queries and provide feedback to a
server management process.

Sure.  The quickly typed example class I gave would help in that.


Yes, that will help. I'm also looking at the Sandstorm (SEDA) 
implementation for ideas.

Re: ImageManagment in Ofbiz

[Jacques Le Roux]

Try rather user ML for such questions, larger audience, more chances to get a 
feedback

And also read
http://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists#MailingLists-DesignanddevelopmentList:dev@ofbiz.apache.org

Thanks

Jacques
From: Rasool skrasool...@gmail.com

Hi,
   
   Can you anyone tell about new image management in the ofbiz than

previous one.

--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/ImageManagment-in-Ofbiz-tp4632766.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: xui in pos

[Jacques Le Roux]

From: Amine Azzi bakht...@gmail.com

hi all,

I was trying to see how to make an Arabic version of the POS
application, and I found nowhere if it is possible to change the style
from 'left to right' to 'right to left'? I went to the xui project
mailing list but it seems that the last one was in 2008 and there was
nothing related to that subject. Then I decided to ask experts of the
POS project in Ofbiz. Maybe Jaques knows the answer :)


Unfortunately no, I never tried that. And I don't think there is anything 
available.
I could have a look but not before this weekend I guess...

Jacques


Actually I want only to change the direction of the table
journal_panel implemented in the Journal.java class  and it will be
much easier to do that throug hte style if possible otherwise I will
be obliged to change the order of these two arrays according the
language and all code related to them

private static String[] field = { sku, desc, qty, price };
private static String[] name = { PosSku, PosItem, PosQty, PosAmt };

Regards.
Amine Azzi

Re: Slim-down continue [was Re: svn commit: r1340414 - ...]

[Jacques Le Roux]

Adrian Crum wrote:

On 5/30/2012 6:06 PM, Adam Heath wrote:

On 05/30/2012 11:47 AM, Adrian Crum wrote:

On 5/30/2012 4:30 PM, Adam Heath wrote:

On 05/30/2012 02:46 AM, Adrian Crum wrote:

On 5/29/2012 5:49 AM, Adam Heath wrote:

On 05/25/2012 01:22 AM, Adam Heath wrote:

On 05/25/2012 12:26 AM, Jacques Le Roux wrote:

From: Jacques Le Rouxjacques.le.r...@les7arts.com

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 04:05 PM, Jacques Le Roux wrote:

From: Adam Heathdoo...@brainfood.com

On 05/24/2012 10:18 AM, Adam Heath wrote:
The idea was that you would parse the sqlCondition once, in a
static
{} block somewhere, then at runtime, just build that map. This
builds-upon the map/list idea inherent in ofbiz.

I also had plans that you could store sql strings into a
properties
file somewhere, so that they could possibly be changed by the
end-user
without having to recompile.

I need to revisit the SELECT a.partyId, b.* EXCLUDE(partyId)
FROM
Party a LEFT JOIN PartyContactMech b USING (partyId), now
that ofbiz
better supports conditions on the join clauses, esp. when
combining
views into other views.

Thanks for the explanation,

So should we not rather create a Jira with all the needed in a
patch
until this is finished?
Or maybe a branch would be easier?

Still with the slim-down idea in mind and as objective.

I like the slimdown, but tbh, I would like to see the
framework/sql
stuff used more than it is(0 right now). Andrew Zeneski was an
original requestor for something that parsed sql into
EntityCondition. I took his suggestion, but went further, to
allow
CREATE VIEW AS SELECT to work.

I've noticed that there aren't that many view definitions in
ofbiz.
As I've been deprecating all this code recently, I've noticed
java
code doing nested loop kinda-stuff, instead of just doing a
view. I'm
guessing because view-xml is verbose and not how people actually
think.

However, with what I committed, you can define the view using
a SQL
syntax, which is then backed by a DynamicViewEntity.

I've seen rather impressive speedups just rewriting code to a
single
SQL query, instead of java loops; the database can be rather
efficient. So making view writing simpler is a laudable goal.

Great, but still, why not a branch as long as it's not finished?

Also something which I think is pretty neat in the principle (I
still
did not review the code) and would speed up views:
https://issues.apache.org/jira/browse/OFBIZ-4041

Jacques

BTW another stuff that could be part of this branch
https://issues.apache.org/jira/browse/OFBIZ-3575

Ok, I suppose. This weekend I'll create such a branch to
fix/improve the view system. This will also attempt to fix the
reverse
cache clearing issues.

branches/improved-entityengine-features-20120528

Also see 1343540, which adds a README that has some things that we
might want to implement in the branch.

Adam,

I commented on the commit, but you didn't reply, so I will try again
in this thread.

I saw, but didn't really think it needed a comment.  I guess I should
have given an affirmative response, instead of no response.  I assumed
that no response is not negative(yeah, that's a double negative).



Non-communication is not communication. ;)


Especially when you ask

Jacques






If you don't mind, I would like to clean up the EntityConditionVisitor
interface so it looks more like a conventional visitor pattern.

I'm down to whatever other people for, within reason.  Tbh, I'm
currently tweaking EntityFieldValue, which is used by
ModelViewEntity.ViewEntityCondition, in a hackish way; it means I'm
having to tweak the visitor pattern, which sucks.

I'm the one who added the visitor pattern all those ages ago(goes back
to svn.ofbiz.org timeframe); I'd be fine with ripping it completely
out, as we(brainfood) don't use it anywhere.

I need to reacquaint myself with the entity engine code. I was
thinking the visitor pattern could be used to construct the SQL string
instead of the complicated if-then-else code spread across a number of
classes. We could use different visitors for different databases.

Yes, that was my original thought.  However, I don't think it's that
simple anymore.  I've got a much better understanding of the entity
system since I wrote the visitor stuff.

I'd actually like to see my generic sql code be used to represent
entitymodel, then add sql-sql conversion code.  I have an xslt that
can read *all* entitymodel.xml and convert it to entitymodel.sql, or
entitymodel.java.  I used the former to verify that my sql parsing was
featureful enough.



You lost me. How will this look when it is finished? Will the entity
model XML files be replaced with SQL files?





 From my perspective, the entity engine implementation seems a bit
tangled, and I was trying to come up with a strategy to simplify things.

It's not too bad, imho; just has some issues with view abstraction
that can't be currently represented.  It's getting much closer to not
having to do raw sql anymore thru jdbc.

Re: Discussion: Using Javolution (was: jdk7 feature that might be good for ofbiz)

[Scott Gray]

Perhaps my memory is failing but haven't you raised this topic before?  What 
was the outcome back then?

I think if you're planning to rehash old topics then it's good to call out the 
previous discussions that have been had to give a full context.  While I'm not 
at all suggesting you are doing this, it is entirely possible for someone with 
an agenda to keep raising old topics as new ones until the desired response is 
received from the community, later on when someone complains you can just say 
but I discussed it first! even if the idea had been rejected in several 
previous discussions.  Again, I'm not suggesting you're doing this, just using 
it as an example of why it's important to disclose previous discussions when 
raising them anew.

Regards
Scott

On 30/05/2012, at 11:24 PM, Adrian Crum wrote:

 I am reposting this thread with a different subject to make sure everyone 
 interested has a chance to comment.
 
 To summarize (and to make sure we are all on the same page):
 
 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran 
 some performance tests that demonstrated a performance boost when using 
 Javolution Fast* classes instead of java.util.* classes.
 2. Javolution acheived this performance boost by eliminating some garbage 
 collection. The Fast* classes use object pools - where objects are returned 
 to the pool when they are unused instead of being garbage collected.
 3. JDK 1.5 introduced an improved garbage collector that eliminated the long 
 pauses caused by previous garbage collectors. Also, it introduced the 
 java.util.concurrent package - which is functionally similar to Javolution's 
 concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for 
 Javolution was eliminated - but it was kept in the project anyway.
 4. No performance tests have been executed recently to see what kind of 
 impact removing Javolution will have.
 5. In the attached thread I recommend removing Javolution from object fields 
 that are effectively static (either declared static or a field of an object 
 that is cached indefinitely), because the pooled object is never returned to 
 the pool - defeating the purpose of the library.
 6. In the attached thread Adam suggests removing Javolution entirely.
 
 -Adrian
 
 
 On 5/27/2012 9:56 PM, Adrian Crum wrote:
 On 5/27/2012 5:56 PM, Adam Heath wrote:
 On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
 From: Adrian Crum adrian.c...@sandglass-software.com
 FYI, in the Mini-language overhaul I interned the Element tag name
 Strings.
 
 Yes, that's really a good improvment! Things are much more clear now.
 It's only in minilang though (I mean not in widgets actions yet), right?
 
 Another thing to discuss is the proper use of Javolution and/or
 whether we still need it.
 
 Yes, I also wondered about that last week when willing to cast to a
 TreeMap.
 The fact that it's a one man project and will maybe less and less
 supported http://javolution.org/#HISTORY is not yet an issue but could be
 
 I personally see no need for javolution.  It's non-standard 
 concurrency(java.util.concurrent).  It does it's own memory allocation, 
 which prevents escape-analysis from working(allocating memory on the stack 
 instead of the heap).
 
 
 In the Mini-language overhaul I removed Javolution classes from model fields 
 - since the models could be kept in memory (cached) indefinitely (resulting 
 in borrowed objects that are never returned to the pool). I kept Javolution 
 in the script execution path - which is the proper use from my perspective. 
 I know you ran into issues with FastMap previously, but I don't remember the 
 details.
 
 If there are no objections, I can remove Javolution from Mini-language 
 entirely.
 
 -Adrian
 

[jira] [Created] (OFBIZ-4910) clicking on an existing Calendar event displays the current time in the start and end time fields

[Ivan Cauchi (JIRA)]

Ivan Cauchi created OFBIZ-4910:
--

 Summary: clicking on an existing Calendar event displays the 
current time in the start and end time fields
 Key: OFBIZ-4910
 URL: https://issues.apache.org/jira/browse/OFBIZ-4910
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/myportal
Affects Versions: Release 10.04
 Environment: Ubuntu 10.04, OpenJDK 1.6.0_20
Reporter: Ivan Cauchi
 Fix For: Release Branch 12.04


when opening an existing Calendar event for display or further editing, the 
time fields display the current time (but the correct date).  This can be 
confusing for a user who for example simply intends to update the subject or 
description and does not notice the changed time.  On clicking on update, the 
current time displayed updates the calendar event.

This behaviour is evident in v10.04 r1344510, but not in v12.04 r1336603.

--
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

Proposal: separate loading of security files.

[Hans Bakker]

Problem:

Currently security files are loaded as part of seed. Therefore it is 
difficult to allow access to components differently per tenant.


Proposal:
1. create a new data-reader name 'security'.
2. Be able to load specific security files in a custom component and use 
in ofbiz-component.xml the component:// notation
3. now in the custom component can be defined which components should be 
active.


Any opinions or suggestions?

Regards,
Hans

Re: HR Interview Data Model Discussion

[Hans Bakker]

I would like to suggest to replace the jobinterview , jobinterviewtype 
with communicationEvent and communicationEventType and add the 
relationship entity  CommunicationEventJobReq.


in this case the relation to workeffort, content and attribute are 
already there


Regards,
Hans


On 05/25/2012 05:04 PM, Chatree Srichart wrote:

Hi Community

I see there is only one entity about an interview which specific for job
interview named JobInterview.
In an organization might have more than one types of interview, for
example, complain interview or interview to get more information from an
employee.
I am thinking about creating new entities:

Interview
- interviewId
- interviewTypeId

InterviewType
- interviewTypeId
- description

InterviewParty
- interviewId
- partyId
- roleTypeId
- fromDate
- thruDate

InterviewWorkEffort
- interviewId
- workEffortId

InterviewContent
- interviewId
- contentId

InterviewAttribute
- interviewId
- attrName
- attrValue

some thing like these.

Any suggestion?

Regards,
Chatree Srichart

[jira] [Created] (OFBIZ-4911) very trivial update to fieldlookup.js in case of null object failure for wierd unknonw reason

[Leon (JIRA)]

Leon created OFBIZ-4911:
---

 Summary: very trivial update to fieldlookup.js in case of null 
object failure for wierd unknonw reason
 Key: OFBIZ-4911
 URL: https://issues.apache.org/jira/browse/OFBIZ-4911
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Leon
Priority: Trivial
 Fix For: SVN trunk


I cannot find the root cause and it's hard to reproduce, but it does happen 
sometimes. The web browser reports null object exception when it tries to 
evaluate following codes in fieldlookup.js: 
{quote}
var obj_caller = (window.opener? window.opener.lookups[num_id]: null);
{quote}

window.opener is there but window.opener.lookups is null.

--
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-4911) very trivial update to fieldlookup.js in case of null object failure for wierd unknonw reason

[Leon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leon updated OFBIZ-4911:


Attachment: OFBIZ-4911.patch

 very trivial update to fieldlookup.js in case of null object failure for 
 wierd unknonw reason
 ---

 Key: OFBIZ-4911
 URL: https://issues.apache.org/jira/browse/OFBIZ-4911
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Leon
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-4911.patch


 I cannot find the root cause and it's hard to reproduce, but it does happen 
 sometimes. The web browser reports null object exception when it tries to 
 evaluate following codes in fieldlookup.js: 
 {quote}
 var obj_caller = (window.opener? window.opener.lookups[num_id]: null);
 {quote}
 window.opener is there but window.opener.lookups is null.

--
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: Discussion: Using Javolution

[Adrian Crum]

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3c2640abb5-65b1-4cb0-b360-2a97eac2e...@me.com%3E

-Adrian

On 5/31/2012 2:08 AM, Scott Gray wrote:

Perhaps my memory is failing but haven't you raised this topic before?  What 
was the outcome back then?

I think if you're planning to rehash old topics then it's good to call out the previous 
discussions that have been had to give a full context.  While I'm not at all suggesting 
you are doing this, it is entirely possible for someone with an agenda to keep raising 
old topics as new ones until the desired response is received from the community, later 
on when someone complains you can just say but I discussed it first! even if 
the idea had been rejected in several previous discussions.  Again, I'm not suggesting 
you're doing this, just using it as an example of why it's important to disclose previous 
discussions when raising them anew.

Regards
Scott

On 30/05/2012, at 11:24 PM, Adrian Crum wrote:


I am reposting this thread with a different subject to make sure everyone 
interested has a chance to comment.

To summarize (and to make sure we are all on the same page):

1. Javolution was added to the project in the JDK 1.4 days. David Jones ran 
some performance tests that demonstrated a performance boost when using 
Javolution Fast* classes instead of java.util.* classes.
2. Javolution acheived this performance boost by eliminating some garbage 
collection. The Fast* classes use object pools - where objects are returned to 
the pool when they are unused instead of being garbage collected.
3. JDK 1.5 introduced an improved garbage collector that eliminated the long 
pauses caused by previous garbage collectors. Also, it introduced the 
java.util.concurrent package - which is functionally similar to Javolution's 
concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for 
Javolution was eliminated - but it was kept in the project anyway.
4. No performance tests have been executed recently to see what kind of impact 
removing Javolution will have.
5. In the attached thread I recommend removing Javolution from object fields 
that are effectively static (either declared static or a field of an object 
that is cached indefinitely), because the pooled object is never returned to 
the pool - defeating the purpose of the library.
6. In the attached thread Adam suggests removing Javolution entirely.

-Adrian


On 5/27/2012 9:56 PM, Adrian Crum wrote:

On 5/27/2012 5:56 PM, Adam Heath wrote:

On 05/27/2012 07:09 AM, Jacques Le Roux wrote:

From: Adrian Crumadrian.c...@sandglass-software.com

FYI, in the Mini-language overhaul I interned the Element tag name
Strings.

Yes, that's really a good improvment! Things are much more clear now.
It's only in minilang though (I mean not in widgets actions yet), right?


Another thing to discuss is the proper use of Javolution and/or
whether we still need it.

Yes, I also wondered about that last week when willing to cast to a
TreeMap.
The fact that it's a one man project and will maybe less and less
supported http://javolution.org/#HISTORY is not yet an issue but could be

I personally see no need for javolution.  It's non-standard 
concurrency(java.util.concurrent).  It does it's own memory allocation, which 
prevents escape-analysis from working(allocating memory on the stack instead of 
the heap).


In the Mini-language overhaul I removed Javolution classes from model fields - 
since the models could be kept in memory (cached) indefinitely (resulting in 
borrowed objects that are never returned to the pool). I kept Javolution in the 
script execution path - which is the proper use from my perspective. I know you 
ran into issues with FastMap previously, but I don't remember the details.

If there are no objections, I can remove Javolution from Mini-language entirely.

-Adrian