Re: [jira] Commented: (OFBIZ-3867) JobManager.poll() enters an endless loop when it can't get a connection

[Robert Morley]

On Jul 20, 2010, at 1:17 PM, Adam Heath wrote:


Robert Morley wrote:

We have made a number of changes to the JobScheduler to properly work
with multi-tenancy.  In this spot we created a list of the databases
that were down and when polling for jobs we would exclude these jobs.
We then had a separate polling period (default 5 minutes) that would
check the offline databases to see if they have gone back online.

This might not match what you are trying to do exactly because we  
have a
technique of storing all persisted jobs in our "main" database  
which has
a "delegatorName" column (which represents the tenant).  Jobs that  
are

destined to run for all tenants would be "exploded" into a job per
tenant (targeted for it).  This allows a "sendEmail" job (for  
example)

to execute on all tenant databases that are online, and safely skip
non-online tenants until they go back online.  This also creates a
singleton jobManager so you do not have one running for each  
tenant ...


Please comment on the issue.  I'll then add my own comments there.


Sorry Adam I do that all the time (just reply to the thread from my  
email) -- I will get better.  :p  My comments have been added to the  
JIRA as a comment.

Re: [jira] Commented: (OFBIZ-3867) JobManager.poll() enters an endless loop when it can't get a connection

[Robert Morley]

We have made a number of changes to the JobScheduler to properly work  
with multi-tenancy.  In this spot we created a list of the databases  
that were down and when polling for jobs we would exclude these jobs.   
We then had a separate polling period (default 5 minutes) that would  
check the offline databases to see if they have gone back online.


This might not match what you are trying to do exactly because we have  
a technique of storing all persisted jobs in our "main" database which  
has a "delegatorName" column (which represents the tenant).  Jobs that  
are destined to run for all tenants would be "exploded" into a job per  
tenant (targeted for it).  This allows a "sendEmail" job (for example)  
to execute on all tenant databases that are online, and safely skip  
non-online tenants until they go back online.  This also creates a  
singleton jobManager so you do not have one running for each tenant ...


Anyway those are my thoughts on it :)

On Jul 20, 2010, at 1:06 PM, Adrian Crum (JIRA) wrote:



   [ https://issues.apache.org/jira/browse/OFBIZ-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890329 
#action_12890329 ]


Adrian Crum commented on OFBIZ-3867:


One idea off the top of my head and without looking at the code  
would be to give the JobManager a state. It could enter a suspended  
state and then try switching to an active state from time to time.  
State change log entries would be informational, not warnings.


Having a hook where outside events could monitor/trigger state  
changes could be useful. A process monitoring the request load could  
suspend the JobManager during peak traffic times.



JobManager.poll() enters an endless loop when it can't get a  
connection

---

   Key: OFBIZ-3867
   URL: https://issues.apache.org/jira/browse/OFBIZ-3867
   Project: OFBiz
Issue Type: Bug
  Reporter: Adam Heath
  Assignee: Adam Heath

JobManager.poll(), line 157, where it calls storeByCondition, can  
fail when there is no connection available from the database(due to  
a connection leak, or just load, or whatever).  An exception then  
gets thrown by storeByCondition(deep inside ofbiz/commons-dbcp/ 
postgres).  The catch(Throwable) then logs the error, and the loop  
tries again.  Since pollDone never gets set to true, this loop is  
*very* tight, and the log file starts to fill up *very* fast, each  
each thread of JobPoller tries the same thing over and over.
I'm filing this bug mainly to see if anyone else works on it, but  
if not, it's a reminder for me.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Storing supplier provided account number

[Robert Morley]

On May 4, 2010, at 12:59 AM, Scott Gray wrote:



Personally I like using natural PKs whenever possible and the number  
of them doesn't really bother me with all the tools we have for auto- 
setting fields.


It would be interesting to see if there is some way to smarten up  
the entity engine so that these sub-types could be more deeply  
integrated.  I have no idea at the moment what form that might take  
though.




FYI -- Patch created as part of JIRA OFBIZ-3764.

Re: Survey Response Validation

[Robert Morley]

On May 3, 2010, at 6:17 PM, Scott Gray wrote:

I haven't had a good look in a while but I thought FreeMarker  
templates were used to render surveys?




This is from memory for me too; but I believe what happens is  
FreeMarker templates are used to create xml that represents a  
ModelForm.  The survey logic than instantiates an instance of  
ModelForm from this dynamically generated xml and (I think) stores  
it in the context.  When the survey is rendered the survey screen  
includes this dynamic form instance using the context:// notation  
and standard html rendering takes over.  I may have that context  
usage a bit wrong ... but I remember creating some ftl to handle  
additional field-types that I wanted to render as part of my survey.


I remember thinking it might have been better to instantiate a  
ModelForm and then set the appropriate attributes / fields / etc on  
it, rather than the FreeMarker usage and generate xml, and then  
suck that in to result to the same place ... an instantiated form  
instance ... but I never acted on that thought.  :)


All very interesting :-) but if I look at genericsurvey.ftl for  
example, it's just generating straight up html


Regardless, what you're suggesting is an order of magnitude more  
work than what I've proposed so whether it's a nice feature or not,  
I won't be implementing it :-)


Regards
Scott



Bah Mr. Gray!  I think what I was referring to was  
genericsurveyform.ftl.  Oh dammit!  I think this is something I must  
have implemented a year ago and only exists in our project LOL ...  Oh  
now it is coming back; we wanted to make use of party lookups (with  
ajax) and such in the forms, so it made sense to change the ftl to  
render a form and then leverage the standard form renderer.  I am so  
sorry; this was custom work I had done that I thought was OOB Ofbiz.


Any interest in it?  ;)

Re: Survey Response Validation

[Robert Morley]

On May 3, 2010, at 5:53 PM, Scott Gray wrote:

What I am getting at here is an ability to model a "validation  
service" as part of the ModalForm.  How it is implemented (sever- 
side vs. ajax callback) would really be secondary.  I like the ajax  
approach for the validation that you have suggested in the  
implementation ... I was just thinking if you were going to add  
validation logic to your survey you could expose that through an  
extension to the ModelForm

(since that is what survey is creating dynamically)


I haven't had a good look in a while but I thought FreeMarker  
templates were used to render surveys?




This is from memory for me too; but I believe what happens is  
FreeMarker templates are used to create xml that represents a  
ModelForm.  The survey logic than instantiates an instance of  
ModelForm from this dynamically generated xml and (I think) stores it  
in the context.  When the survey is rendered the survey screen  
includes this dynamic form instance using the context:// notation and  
standard html rendering takes over.  I may have that context usage a  
bit wrong ... but I remember creating some ftl to handle additional  
field-types that I wanted to render as part of my survey.


I remember thinking it might have been better to instantiate a  
ModelForm and then set the appropriate attributes / fields / etc on  
it, rather than the FreeMarker usage and generate xml, and then suck  
that in to result to the same place ... an instantiated form  
instance ... but I never acted on that thought.  :)

Re: Storing supplier provided account number

[Robert Morley]

On May 3, 2010, at 3:09 PM, Robert Morley wrote:



That wasn't what I was suggesting, I was describing  
SupplierRelationship as being an extension to PartyRelationship in  
the same way that Person or PartyGroup extends Party.





Yes I think this is the solution that Adrian has original suggested  
a couple of years back and is the same solution I had thought about  
implementing when I started this thread.  I think the difficulty  
here comes in the fact that the data model book has sub-classes for  
both PartyRelationship and Agreement for this purpose (Supplier  
Relationship and Purchase Agreement respectively from page 43 and  
149 of The Data Model Resource Book volume 1).  There are also sub- 
classes for both for "Employeement" named "Employment" and  
"Employment Agreement".


The book suggests that Agreement is involved in a single  
PartyRelationship (but the relationship may be associated with a  
collection of Agreements).  Ofbiz does not model this association,  
but I think it probably should.  A scan of the forum for anything on  
this topic did not produce any results.  Again the book suggests the  
PartyRelationship is an informal relationship where the agreement is  
created "when a formal agreement is established between these  
parties and a contract is drawn stipulating certain terms of this  
agreement ...".


For a supplier I think it is desirable to have an informal  
PartyRelationship between the Internal Organization and the Party  
that will be supplying products.  We may also (optionally) have a  
formal agreement that dictates pricing and other terms (like net 30,  
etc).  However, the life of this section agreement may be much  
shorter than the life of the relationship to the supplier.  And it  
is very likely that the supplier supplied "customerNumber" or  
"accountNumber" would live across many agreements.


As a result, I would like to get started on this new entity  
"SupplierRel" and will provide a patch soon.


Argh!  Ok now I understand why "Employment" which is a logic sub-class  
of PartyRelationship was not coded as such.  The issue is that there  
is not a specific single primary key for PartyRelationship -- its  
primary keys are partyto, partyfrom, roleto, roleform, and fromDate.   
As a result, without duplicating all of those keys you can not recall  
create the Employment entity like we do with other "inherited"  
entities like Party / Person & PartyGroup.


So the options are to add  "partyRelationshipId" to the entity and the  
changes that would involve (including about a 100 seeded  
PartyRelations), duplicate the fields in SupplierRel (like Employment  
does now), or fall back to putting the field directly on  
PartyRelationship itself.


Community direction requested ... :)

Re: Storing supplier provided account number

[Robert Morley]

On Apr 30, 2010, at 6:06 PM, Scott Gray wrote:


On 1/05/2010, at 3:52 AM, Adam Heath wrote:


Scott Gray wrote:
I think Agreements are more like the terms of a relationship and  
can change over the course of that relationship.


I would tend to think of an account number as being more like  
relationship meta data that exists so long as the relationship  
exists and for that reason I would either add a generic field to  
PartyRelationship or otherwise add a new entity  
SupplierRelationship and one-to-one it with PartyRelationship.


I like the latter, SupplierRelationship, as there could be an
unbounded set of SupplierIdentificationType and
SupplierIdentificationPurpose fields.


That wasn't what I was suggesting, I was describing  
SupplierRelationship as being an extension to PartyRelationship in  
the same way that Person or PartyGroup extends Party.





Yes I think this is the solution that Adrian has original suggested a  
couple of years back and is the same solution I had thought about  
implementing when I started this thread.  I think the difficulty here  
comes in the fact that the data model book has sub-classes for both  
PartyRelationship and Agreement for this purpose (Supplier  
Relationship and Purchase Agreement respectively from page 43 and 149  
of The Data Model Resource Book volume 1).  There are also sub-classes  
for both for "Employeement" named "Employment" and "Employment  
Agreement".


The book suggests that Agreement is involved in a single  
PartyRelationship (but the relationship may be associated with a  
collection of Agreements).  Ofbiz does not model this association, but  
I think it probably should.  A scan of the forum for anything on this  
topic did not produce any results.  Again the book suggests the  
PartyRelationship is an informal relationship where the agreement is  
created "when a formal agreement is established between these parties  
and a contract is drawn stipulating certain terms of this  
agreement ...".


For a supplier I think it is desirable to have an informal  
PartyRelationship between the Internal Organization and the Party that  
will be supplying products.  We may also (optionally) have a formal  
agreement that dictates pricing and other terms (like net 30, etc).   
However, the life of this section agreement may be much shorter than  
the life of the relationship to the supplier.  And it is very likely  
that the supplier supplied "customerNumber" or "accountNumber" would  
live across many agreements.


As a result, I would like to get started on this new entity  
"SupplierRel" and will provide a patch soon.

Re: Survey Response Validation

[Robert Morley]

On Apr 30, 2010, at 6:41 AM, Scott Gray wrote:

Is there an opportunity to plug-in a server-side validation service  
on any
ModalForm?  Has this been discussed before from you knowledge  
(excuse my

lack of search).  The theory would be that your dynamically generated
ModelForm instance could apply this validation service to the  
model.  The
RequestHandler on post-back could determine the ModelForm and  
execute any

defined validation service (if technically feasible).


What you could perhaps do is make sure you use services as your  
request map events and then create a special request/event that you  
can call via ajax that will valid the parameters against the service  
definition by serializing the form and telling it what your target  
request is.  There is a seldom used child element to service ->  
attribute called type-validate which can allow you to do custom  
field level validation on incoming parameters.
You just need to call modelService.validate(parameters, "IN",  
locale) in your special validation request/event and you're done.


Regards
Scott


What I am getting at here is an ability to model a "validation  
service" as part of the ModalForm.  How it is implemented (sever-side  
vs. ajax callback) would really be secondary.  I like the ajax  
approach for the validation that you have suggested in the  
implementation ... I was just thinking if you were going to add  
validation logic to your survey you could expose that through an  
extension to the ModelForm (since that is what survey is creating  
dynamically) and then we would have an ability that could be leveraged  
in a number of spots.  This would be versus having a survey validation  
service that your survey handler happens to call first before the  
async execution service.

Re: Code Coverage

[Robert Morley]

I seem to recall that the issue may be that EMMA is not being actively  
developed (that isn't to say people don't use it).  As you probably  
know I did some extensions to Adam's work with Cobertura so we could  
be generating code coverage as part of the build and ultimately  
publishing those metrics.  Adam took the initiative to make this  
pluggable and I provided targets that would allow users of Ofbiz to  
download the library if they saw fit.  In doing this, I did notice  
that some of the other Apache products use Clover for these type of  
metrics (assumption is this is just as prt of their build and not  
distributed with their product) ...



On Apr 30, 2010, at 10:28 AM, Scott Gray wrote:

I don't suppose anyone has looked at EMMA (http://emma.sourceforge.net/ 
) as an alternative to Cobertura?  It has a CPL license which means  
we could include the jar.


Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

Re: Promo items

[Robert Morley]

On Apr 29, 2010, at 5:54 PM, Adam Heath wrote:


Well, I don't know about your question, it really should be a separate
thread(or change the subject).

What we are seeing, is that getSurvey is being called on the product,
2000+ times.  It's also hitting the database quite a bit, because of
one missing findByAndCache call on ProductCategoryMember(I'll send a
patch for this one eventually).

There's no reason to call getSurvey over and over with the same
parameters.  However, there's also no way for it to cache that call.
The real fix here is to allow each promo action to 'swallow' as much
quantity as is allowed, instead of the higher code looping once for
each whole number of quantity.



Yes, I think it should do exactly what you are saying -- all I was  
saying was that you are in the code right now and it would be  
interesting (on a related matter) to know how it would handle quantity  
fractions.  If you are going to rework it one of the requirements  
should be that it handles these properly.  Being un-familiar with  
promotions I can only speculate that I should be able to create a  
promotion where if I buy a 1/2 oz of a product I should be able to get  
a 1/4 oz free.  And based on the original post I don't think that  
would work either.

Re: Storing supplier provided account number

[Robert Morley]

Ya ... the one thing I wondered about was the Employment entity.  I  
believe PartyRelationshipType has it set as hasTable = "Y" but then it  
redundantly stores the role, party to/from as well as the from/thru  
dates.  I would think if Employment is a sub-class of  
PartyRelationship, it should only have its unique fields (I think two  
termination related fields).


I would think a "fundamental" type like supplier may have its own  
SupplierRel table, but things that can be very vertical specific  
(dealers / houseowners) might be something better stored in an  
Agreement.  Would seem to me to jive with other "supplier" entities  
that already exist in the system.


Another thought that occurred to me is that we could have a  
PartyRelationshipIdent entity (like Good & Party) where we could store  
all sorts of identification numbers on the relationship.  This would  
give a nice place for the employee's number, and the other  
identification numbers we are talking about.  Waddya think about that?



On Apr 29, 2010, at 5:28 PM, Adrian Crum wrote:

My thoughts have changed a bit since that previous thread on the  
subject.


We have similar needs here with parties in other relationships. Our  
dealers have dealer numbers and license numbers, our suppliers give  
us numbers (the same as the previous thread), and the homeowners  
have a customer number and other bits of information we have to  
maintain for them.


The solution I came up with here was to create a properties entity  
for each party type. Each properties entity contains fields for the  
various bits of information we need to track for each party type.


The reason I mentioned that is to point out that there can be more  
than one piece of information you need to attach to a party. If  
those things are added to the party relationship, then that entity  
might start to look like a kludge. The same thing could happen if  
those fields are added to the agreement entity.


So now I'm undecided. If I had to choose between Party Relationship  
or Agreement, I would lean toward Agreement.


-Adrian


On 4/29/2010 1:42 PM, Bob Morley wrote:


My use case here is very similar to this thread --

http://ofbiz.135035.n4.nabble.com/Customer-number-from-suppliers-td142646.html#a142646

I think this thread would suggest the choices are ...

1) New field on PartyRelationship; something like "accountNumber"  
which
would be similar to "positionTitle" in that it really is only  
applicable to

some of the PartyRelationshipType sub-classes.

2) Formalize the sub-class by setting hasTable = "Y" on the type and
creating a new "SupplierRel" entity that contains this  
"accountNumber".


3) Leverage the agreement model for this relationship.

What I was personally going to do was #2 from this list (before  
reading the
thread) but after seeing positionTitle I am kind of leaning towards  
doing

#1.  Since I have to do this for our solution I want to do it in an
acceptable manner for inclusion into Ofbiz (providing we at least  
agree that

this would be a good thing).

Re: Storing supplier provided account number

[Robert Morley]

Is this the ContactMechType of "INTERNAL_PARTYID" ?

On Apr 29, 2010, at 5:22 PM, BJ Freeman wrote:


I added more to the contact mech
it is robust enough you just add types and reasons.

Re: Promo items

[Robert Morley]

On Apr 29, 2010, at 2:31 PM, Adam Heath wrote:


Robert Morley wrote:
We have not implemented promos to date, but can you comment on how  
the
promo adjustments would be created for a quantity like 1.542?  I  
would

agree rhat having a single adjustment for the order item line (per
promo) would make the most sense.


You misunderstand.  Add stock for 5000 items for a PROMO_GWP.  Add
enough stock for the parent item too.  Then add a quantity of 'two
thousand' on the original product.  Watch ofbiz fall over.

I think you are interpetting the ',' as a '.'.



I got the impression when Ean said "then the result is both a large  
quantity of promo adjustments" that Ofbiz was creating an adjustment  
for each of the product quantities.  That is to say if you had an item  
with a quantity of 10 with promo it would add 10 individual  
adjustments ... and when you went up really high it caused issues.  Is  
that not the case?  My question was actually, if that is the case what  
would ofbiz due with quantities that were not evenly divisible by 1  
(i.e. 1.542).

Re: Promo items

[Robert Morley]

We have not implemented promos to date, but can you comment on how the  
promo adjustments would be created for a quantity like 1.542?  I would  
agree rhat having a single adjustment for the order item line (per  
promo) would make the most sense.


Bob

On 2010-04-28, at 1:16 PM, Ean Schuessler  wrote:


The OFBiz promo code processes product quantities as singletons. If a
large quantity of an item is added to the cart (ie. 2,000) and there  
is

a promo for that product then the result is both a large quantity of
promo adjustments as well as a long processing time for the cart. For
some industries large order quantities are perfectly reasonable but  
the

current OFBiz design will fail.

Does anyone have any perspective on this issue? One possible solution
would be to remove the part of the promo design that reduces promo  
items
to singletons. I realize that introduces other challenges but they  
seem

to be deterministic. The singleton processing approach seems like an
effort to keep the implementation simple.

--
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: [VOTE] [BRANCH] Creation of the Release Branch "release10.04"

[Robert Morley]

+1

Bob

On 2010-04-28, at 4:10 AM, Jacopo Cappellato > wrote:


This is the vote thread to create a new release branch (not a  
release yet) named "release10.04".
This branch will represent a feature freeze and releases will be  
created over time out of it: all the commits in this  branch will be  
for bug fixes only, no new features.


Vote:

[ +1] create the branch "release10.04"
[ -1] do not create the branch

We will use the same rules for votes on releases (vote passes if  
there are more binding +1 than -1 and if there are at least 3  
binding +1)

For more details about this process please read this 
http://www.apache.org/foundation/voting.html

Kind Regards,

Jacopo

Re: Proper modeling of parameters and impact to page refresh ... (SVN 13393)

[Robert Morley]

On Apr 27, 2010, at 8:29 AM, Scott Gray wrote:



If the hidden form links are being generated by OFBiz's widget code  
then you can usually specify the type of link that is generated  
instead of using the default auto type which exhibits this  
behaviour.  POSTed parameters are only an enforced requirement of  
service events so as long as you're using a different type of event  
then GET requests should be fine.




Yep that was the original solution but we did not want to go through  
the entire application and find all "navigation" links to mark them  
with link-type="anchor" (or whatever the grammar is).  I think your  
original point is what I am going to look into further; perhaps having  
something that is really a navigation link having a controller request  
that includes an "event" is wrong in the first place.  That logic  
could be moved into the screen which would also avoid this whole  
problem, make our links bookmark-able again, etc etc.  Thanks for your  
input!

Proper modeling of parameters and impact to page refresh ... (SVN 13393)

[Robert Morley]

We ran into a problem where we have now properly modeled all  
parameters to controller requests with the "parameter" element; for  
example here is a properly modeled link ...




	field="parameters.orderId"/>




What ofbiz does when it attempts to render this link, is determine if  
it should render it as an anchor or with a hidden form.  The  
determining factor here is if the controller request "ViewSalesOrder"  
has an event defined.  If it has an event, it must render as a hidden  
form for security reasons.  In this case, ViewSalesOrder will call an  
event to properly create and save the ShoppingCart object into the  
session.  As a result, we now render this as a POST instead of a GET  
(when the parameters were defined as query string arguments).


After this happens, there may be a number of things that happen to the  
page that require us to do a page refresh.  This is typically done as  
part of a modal box operation.  What we had done in the past was use  
the document.location.href to refresh the page.  Now that these  
navigation links are rendered as POSTs this no longer works, and a  
number of bugs had been created around "missing orderId" and similar  
problems as part of that refresh.


Our solution right now was to fix how we do a refresh page.  I have  
created a "reloadPage" javascript snippet that gets rendered on all  
Emforium themed pages in the footer.  This uses the request to build a  
proper request to reload the page with the url, parameters, and  
request method.  The modal box inclusion now uses this function  
instead of its own location.href refreshing mechanism.  A number of  
parameters that were setting this success function directly have been  
removed in favor of this new method.


This was checked in as part of revision 13393 and has resolved a few  
tickets such as EMF-3403.


There should be no direct developer impact.  After an svn refresh you  
may be assigned tickets that were related to this problem and have now  
been fixed.  Please let me know if you have any questions or concerns.



Robert Morley
Senior Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
rmor...@emforium.com

Re: Bug: Not-Null Values are at top when fetching list from database, in Release 9.04

[Robert Morley]

No problemo; I will try to get that patch up in the next 48 hours.

It is very odd that you are seeing different results with the same database / 
drivers.  My understanding is that the sql standard does not dictate how nulls 
are sorted and it seemed a split as to having them first or last based on the 
DBMS in question.

At any rate, I will post the JIRA ticket back into this thread when a patch is 
available.

- Bob

- Original Message -
From: "Divesh Dutta" 
To: dev@ofbiz.apache.org
Sent: Saturday, April 24, 2010 1:18:44 AM
Subject: Re: Bug: Not-Null Values are at top when fetching list from database, 
in Release 9.04

Hello Robert,

To be more clear, I am using same database and database drivers on both 
the instances. By the way I think  "New element in the entityengine.xml 
that indicates if a particular data source supports the nulls-first 
grammar" will be good idea to add on.

Can you please create a jira issue and load your patch, so that 
Committers can have a look and give their views on this.

Re: Consistent required field indicators

[Robert Morley]

On Apr 23, 2010, at 5:53 PM, Adam Heath wrote:


Robert Morley wrote:


One could certainly harness the power of the model to walk and  
transform

based on all sorts of associations.  Internally we have added the
visitor pattern to the presentment, service, and controller models  
with

the intent of doing these sort of things.  To date we have applied
(traditional ofbiz) security -- think service definition defines a
permission check for PARTYMGR_VIEW and because a controller request
"ViewParty" uses that as a service event, it gets transformed to have
the same security check.  Naturally, the modeled MenuItem has a  
link to
this controller request, so it gets transformed to be wrapped with  
the

security check.  Net result is that the application no longer renders
the menu link because the logged in user does not have that  
permission.
But alas, I suspect that is a discussion for another day  or is  
it?

;)  (Please don't tell me I have to look at the security re-design, i
know know!)


Such a walker can not make any assumptions.  Events called from
widgets are difficult to walk down into, as are services themselves.
services can be written in just about any language.

What should be done, is that for each defined service, add a security
check service(which can then cascade), and a validation service(which
could do the same thing).



I do not believe the walker is making any assumptions.  It cascades  
security artifacts from wherever they are defined.  In just so happens  
that a controller request (which in our world can have security  
artifacts) may define an event of type service.  We do not attempt to  
walk any deeper than the service definition; and it can harvest  
security artifacts from there regardless if they are primitive  
security checks or invocations to a security method (as long as it is  
modeled).


If one was to do what you are saying, I believe it would boil down to  
the same thing -- service definition defines behaviour and modeled  
objects that have a hard reference to that service definition could  
obtain that behaviour and transform themselves as a result.


Is it complete?  Of course not -- if a widget has a soft reference  
(say a target is determined dynamically) then we can not do anything  
(remember this is loaded at cache time).  Moreover, there is (in this  
case) permission join considerations.  Say I have a form that has two  
links; does the parent widget OR those permissions or AND them?  We  
have expected the presentment model to account for this; so on a  
screenlet (for example) you can indicate if all permissions are  
required to show that widget (AND) or if you can partially show it (OR).


Having said all this; it is one of the reasons why we like minilang.   
Being heavily modeled it provides an opportunity to get right in there  
and walk and transform it.  That is something that has come up quite a  
bit as well as additional uses for walking the entity model.  In my  
mind the form can be shaped quite a bit if you have a deterministic  
way to link it to the entity it operates on and the service that does  
that work.

Re: Consistent required field indicators

[Robert Morley]

On Apr 23, 2010, at 5:33 PM, Adam Heath wrote:


I like the idea of service definitions driving the required fields.


Sure, that would be nice.  However, what happens when service A  
calls
service B, and service C sometimes dependening on the situation.   
How
would you chain the validations, so that no processing code was  
run in

A until both B and C were satisified that the data was correct?



I think you would be using the required fields defined by the service
definition of service A which is what the form would be bound to.  If
there are optional parameters to service A that are required by  
service

B (and service B is always called) then service A should have them
marked as required as well.  However, if service B is optionally  
called
itself (based on logic) then without the client duplicating that  
logic

client-side, the page has no choice but to make those parameters
optional as well.


Validation is more than just a required check.  Various fields may be
restricted to a certain list of allowed values.  This list could
change based on other incoming parameters.  And copying such
validation all over the place would lead to more madness(I have enough
of my own).



No argument about validation; but I thought the original point was  
adjusting the model form field's required attribute based on the  
service that is it bound to.  In that case, my expectation would be  
that it would honour what is marked as non-optional from the service  
definition.


One could certainly harness the power of the model to walk and  
transform based on all sorts of associations.  Internally we have  
added the visitor pattern to the presentment, service, and controller  
models with the intent of doing these sort of things.  To date we have  
applied (traditional ofbiz) security -- think service definition  
defines a permission check for PARTYMGR_VIEW and because a controller  
request "ViewParty" uses that as a service event, it gets transformed  
to have the same security check.  Naturally, the modeled MenuItem has  
a link to this controller request, so it gets transformed to be  
wrapped with the security check.  Net result is that the application  
no longer renders the menu link because the logged in user does not  
have that permission.  But alas, I suspect that is a discussion for  
another day  or is it?  ;)  (Please don't tell me I have to look  
at the security re-design, i know know!)

Re: Consistent required field indicators

[Robert Morley]

On Apr 23, 2010, at 5:18 PM, Adam Heath wrote:


Adrian Crum wrote:

--- On Fri, 4/23/10, Robert Morley  wrote:

+1 - I think properly modeling the
field using the required-field attribute makes perfect
sense.  I would think our html form renderer
implementation should probably just apply a class "required"
at render time and the visual should be handled by css.


I believe I was the one who introduced the required CSS class and  
that was my reasoning - have the style sheet determine what a  
required field looks like.


At the time, the asterisk was being used to indicate a required  
field. The problem was, most forms didn't have an explanation as to  
what the asterisk meant. So the result looked odd.


No "best practice" was discussed or decided upon. I just put the  
new CSS class in the style sheet and I left it to the community to  
decide by using it or not.


I like the idea of service definitions driving the required fields.


Sure, that would be nice.  However, what happens when service A calls
service B, and service C sometimes dependening on the situation.  How
would you chain the validations, so that no processing code was run in
A until both B and C were satisified that the data was correct?



I think you would be using the required fields defined by the service  
definition of service A which is what the form would be bound to.  If  
there are optional parameters to service A that are required by  
service B (and service B is always called) then service A should have  
them marked as required as well.  However, if service B is optionally  
called itself (based on logic) then without the client duplicating  
that logic client-side, the page has no choice but to make those  
parameters optional as well.

Re: Consistent required field indicators

[Robert Morley]

+1 - I think properly modeling the field using the required-field  
attribute makes perfect sense.  I would think our html form renderer  
implementation should probably just apply a class "required" at render  
time and the visual should be handled by css.


On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:


Here is what I propose:
Remove all the ${uiLabelMap.CommonRequired} tooltips from form  
definitions. The tooltip should be used to provide other information  
as it is for not required fields (the purpose of the field, the  
format)

Remove all the widget-style="required" from form definitions.
If a field is required, (on form widget) set only its attribute  
required-field="true". In cases when the form is based on service  
definition (auto-fields-service) it is not neccessary to set this  
attribute. Then  no need to add tooltip="$ 
{uiLabelMap.CommonRequired} or widget-style="required" attibutes on  
the form definition. The renderer should decide how to indicate the  
required field.


Change form renderer, so if a field is required it is indicated by  
asterix plus required style ( same as widget-style="required")

Re: Bug: Not-Null Values are at top when fetching list from database, in Release 9.04

[Robert Morley]

There are differences in how the various databases elect to sort nulls  
using a standard order by clause.  Some databases (Postgres and Oracle  
I believe) support a "NULLS FIRST" or "NULLS LAST" grammar on the  
order by clause to dictate this.


I meant to package this up as a patch, but in our solution we provided  
consistent ordering regardless of database as well as the ability on  
an order-by element to indicate if you want the nulls ordered first or  
last for that particular field.  There is also a new element in the  
entityengine.xml that indicates if a particular data source supports  
the "nulls-first" grammar.


If there is interest and a committer that would be willing to reivew,  
I can package this up ASAP and you can consider for back porting.


On Apr 23, 2010, at 11:18 AM, David E Jones wrote:



For that call the sorting is done in the database (not cached), so  
there's probably a difference in databases or database configs.


-David


On Apr 23, 2010, at 8:49 AM, Divesh Dutta wrote:


Hello Developers,

I see an strange issue on Release 9.04. But that issue does not  
exists on latest OFBiz trunk. Below is brief description  of  issue:


1) When I use  any of the method (like findList or findByAnd) of  
DelegatorImpl.java class , and sort it by "sequenceNum", For eg in  
EditProductFeatures.groovy: (Release 9.04)


 context.productFeatureAndAppls =  
delegator.findList('ProductFeatureAndAppl',

 EntityCondition.makeCondition([productId : productId]), null,
 ['sequenceNum', 'productFeatureApplTypeId',  
'productFeatureTypeId', 'description'], null, false);


It returns me the list of values, with *Not-Null values at the  
top* , and then it sort in Ascending order by "sequenceNum", ..


2) But When I use Latest trunk in OFBiz: Using same example, It  
returns me the list sorted by "sequenceNum",  in ascending  
order and then *Not-null values at the bottom


*3) I think this is the major bug in Release 9.04, because if we  
think at application level, if a catagory has over 800 products,  
Catalog Manager will have to go to the last page, to sequence every  
single product for it to show properly on the front end.


4) Instead if Catalog Manager want to sequence the products,  he  
will  arrange them at very first page.


5) I tried to found the reason of this major difference, but could  
not locate the exact fix in any of the commit. So I request all the  
developers, if any one have any idea regarding this please share  
your views here. Also I think this should be fixed in Release 9.04  
as well.


Thanks
--
Divesh Dutta.





Robert Morley
Senior Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
rmor...@emforium.com

Re: Regarding SVN commit r892904

[Robert Morley]

Lol of course not, I was just suggesting that strictly speaking that  
constructor misuses the makeNegative.  With classes like this it is  
probably better to have a single instance variable store the ms for  
the duration.  Just impressions when previewing; if there us no value  
let's ignore.


I may reply quarter to ten (10,-15).

I will take a look at the lookup screen as per your direction.  But I  
can't imagine it makes use of TimeDuration directly, it would have to  
convert 4.5 to long or to (4,30).


Bob

On 2010-04-21, at 1:26 AM, Adrian Crum  wrote:

If you spend a little time with Work Effort's Estimated Milliseconds  
field, you will find that there is a lookup screen that will allow  
you to enter 4.5 hours.


TimeDuration will encode/decode long values. You don't need to use  
the int constructors.


If you were entering 10 months into a field, I'm sure you would  
enter it as 10 months, not one year plus negative 2 months. When  
someone asks me for the time, I usually don't reply "11:00 PM minus  
35 minutes."


-Adrian


--- On Tue, 4/20/10, Bob Morley  wrote:


From: Bob Morley 
Subject: Re: Regarding SVN commit r892904
To: dev@ofbiz.apache.org
Date: Tuesday, April 20, 2010, 9:49 PM


Adrian Crum wrote:


We have the TimeDuration data type for the

estimated/actual time.




Are you referring to
org.ofbiz.base.util.TimeDuration?  The intent would
seem to be that we would define fields in the entity model
as (what results
to a Long) and use this class for simple (manual)
serialization /
deserialization.  That would work well for WorkEffort
fields as you have
indicated.

However, in taking a quick glance at TimeDuration a couple
of things struck
me ...

1) I am forced to use a constructor that requires int for
the components of
the duration.  If I was to build a screen that allowed
the user to indicate
4.5 hours (for example) I could not use this class to
easily convert to my
long value for persistence (if that is part of its
intent).

2) The makeNegative usage looks incorrect in the
"component" constructor --
say I am going to new TimeDuration(1,-2,0,0,0,0,0) I think
my expectation is
my duration would be 10 months (1 year - 2 months); but
what would happen is
since one of the components is negative it would negate all
components and I
believe I would have a duration of -14 months.  (In
fairness, the only
existing use case that would appear to use negative
duration is in
WorkEffortServices and it is using the constructor that
takes a long).

Bottom-line; I agree I think we should leave these on
WorkEffort as stored
in milliseconds and leverage TimeDuration.  If either
of these two points
make sense; perhaps we should cut a minor JIRA to resolve
them if you feel
they warrant potential repair.
--
View this message in context: 
http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2018379.html
Sent from the OFBiz - Dev mailing list archive at
Nabble.com.

Re: Excluding test classes from deployed Jars

[Robert Morley]

On Apr 17, 2010, at 6:18 PM, Adam Heath wrote:


I've got it working locally, for base.  Will be applying it to the
other components that have test classes.  Currently, it'll only save
about 145k of compressed bytecode data(based on the size of the jars).
But that will probably increase as more source-level tests are added.

We might always want to consider splitting ofbiz-component.xml,
splitting screen/form/script resources, basically move out everything
that is only used when tests are being run, and don't make it
available at all during normal runs.



Did we get closure on separating out the test and product artifacts in  
the src folder?  It seems to me that separation would be a good thing  
as you have alluded to in your last paragraph.  As for concerns with  
build dependencies, I would have thought that it would be standard  
practice for any (reasonable sized) change to go through a series of  
"clean-all", "run-install", "run-tests" before doing the commit.   
Certainly as the bulk of unit tests increase, it will have to be  
become standard practice to avoid failing builds.

Re: Excluding test classes from deployed Jars

[Robert Morley]

As per that thread, I was planning on doing this in conjunction with  
renaming some of the tests. Shall I proceed?


Bob

On 2010-04-17, at 12:48 PM, Adrian Crum  wrote:


Thanks for the link. I missed that thread.

-Adrian

--- On Sat, 4/17/10, Erwan de FERRIERES ferrie...@nereide.fr> wrote:



From: Erwan de FERRIERES 
Subject: Re: Excluding test classes from deployed Jars
To: dev@ofbiz.apache.org
Date: Saturday, April 17, 2010, 9:30 AM

Yes, this vould be great ! we've already been speaking on
doing this in this
thread.
But I don't think it's needed to create a main dir, just
adding a test dir
under src is enough.

http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188
--
View this message in context: 
http://n4.nabble.com/Excluding-test-classes-from-deployed-Jars-tp2014236p2014256.html
Sent from the OFBiz - Dev mailing list archive at
Nabble.com.

Re: [jira] Commented: (OFBIZ-3700) Convert WorkEffort (and related entities) quantities from Double -> BigDecimal

[Robert Morley]

(Replying outside of JIRA)

Adrian,

Sounds good -- we are really just getting started with the  
manufacturing component / work effort component.  The trouble I am  
running into (and this is pretty typical of working in any new ofbiz  
area) is understanding the data model coupled with the standard  
workflow.  The UI tends to be CRUD based so it is difficult to figure  
out what things I should be providing with each step of a standard  
production run.  The second problem is that we have last merged ofbiz  
about six months ago, and it appears a number of enhancements have  
gone into ProductionRunServices, so the behaviour I see in our  
solution is different from what I see on ofbiz-trunk demo.


The things that are troubling my little brain now are ...

- why is there no option to assign a party to a routing task in a PRun
- it appears the changeProductionRunStatus and  
changeProductionRunTaskStatus do not enforce the StatusValidChange  
entity
- we not only have "assembly" of products but also "disassembly"; not  
sure how I am going to do that ... logically it is just the inverse of  
an assembly, so I may consider "producing" multiple products of type  
RAW_MATERIAL from one or more FINISHED_GOODS
- from data modeling v2 it appears that a services business may work  
with an "engagement" entity and/or a sub-class of order for "service  
order" ... ofbiz has neither of these, so I am unclear on how I am  
going to support straight service requests that have work effort  
involved



On Apr 14, 2010, at 12:21 PM, Adrian Crum (JIRA) wrote:



   [ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856948 
#action_12856948 ]


Adrian Crum commented on OFBIZ-3700:


Bob,

Thank you for the information. I will work on this issue this  
weekend if no one beats me to it.


I am about to deploy Manufacturing where I work, so I'm learning it  
as well. Maybe between the two of us we can get some documentation  
on the Wiki and work out any kinks we encounter.

Re: [jira] Commented: (OFBIZ-3633) Minimum order quantity

[Robert Morley]

To be honest, we did not have volume 3 in house so we ordered a few of  
them and I have only browsed through it.  I will read through that  
chapter as soon as I can, but on first glance it did look promising.


On Apr 14, 2010, at 10:52 AM, Jeroen van der Wal wrote:


Robert, did you manage to read Chapter 8 of Volume 3 of the DMRB? I am
curious if that pattern could solve your problem.
-Jeroen

Re: [jira] Commented: (OFBIZ-3633) Minimum order quantity

[Robert Morley]

BJ - we will have to disagree on the interpretation of those pages.

In principle,  am ok with Jacopo's suggestion.  However, the  
relationship is between two parties, and in this case we are talking  
about a seller and a product.  If there was a unique set of conditions  
between a seller and a buyer then it makes perfect sense to model this  
as an agreement.  Without any changes, I would guess this would end up  
being an agreement between either the "_NA" party or a party group  
that contains all customers in the system.  Neither of these would  
feel like the right thing to do ...



On Apr 13, 2010, at 7:03 PM, BJ Freeman (JIRA) wrote:



   [ https://issues.apache.org/jira/browse/OFBIZ-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856675 
#action_12856675 ]


BJ Freeman commented on OFBIZ-3633:
---

Bob
the pages you refer to are for company to Manufacture a product then  
have supplier (distributors) sell that product.
this is different than order from a supplier to get raw materials.  
order and order from a customer

covered on page 107 and 109.

I like Jacopo's suggestion  to use the Agreements
from the datamodel book
"An agreement is a set of terms and conditions that govern  
relationships between two parties."

also
You can have product agreements where each product can have this  
relationship both for customers and suppliers.with the company

Re: Why does framework/component-load.xml does not include "base"

[Robert Morley]

On Apr 8, 2010, at 1:16 PM, Adam Heath wrote:


I'd rather fix the duplicate classloader/cobertura thing first, then
apply whatever changes you come up with after that.  Otherwise, it
might be harder to fix if we do this current thread first.


Ok -- let me spend some time working on that and then you can review  
the patch and we can drive to a resolution.  From what you said  
earlier, we will drive to make "base" more like the other components.   
If this is done then we would likely only instrument once for the  
components classpath (rather then being triggered from Start).

Re: Why does framework/component-load.xml does not include "base"

[Robert Morley]

On Apr 8, 2010, at 12:54 PM, Adam Heath wrote:


You misunderstand.  The classes are marked 100% covered, but that is
the problem.  They are *not* 100% covered.  The bug is that the double
class loaders are writing to the same cobertura.dat file, and the
first classloader, that contains framework/base code, gets corrupted
output.

You loading framework/base as a component, so it's testdef files can
be run, will not solve the actual problem, of the double classloaders,
and 2 cobertura instances.

Without loading any of the framework/base tests, we should still get
correct coverage values on base, just because it happens to be called
by everything else in the system.  But we don't, the numbers are  
wrong.


I see your point -- how about this, we put these fixes in which will  
accomplish at the very least ensuring that the base unit testers are  
getting exercised.  I can create another JIRA ticket to handle the two  
class loaders / cobertura.dat file issue.  Once the patch is ready we  
can look it over with an eye towards any adverse affects.

Re: Why does framework/component-load.xml does not include "base"

[Robert Morley]

On Apr 8, 2010, at 2:58 AM, Adam Heath wrote:


Stuff in framework/base is loaded automatically by framework/start, by
reading foo.properties file.

The reason the base metrics are invalid when run-tests is run, is not
because no test cases are run in base, but because there are 2
classloaders, both with cobertura active, and at shutdown, both
classloaders try to write to the same file, and corruption ensues.  I
haven't felt the need to track it down, because base has bare tests
that give coverage.

Plus, actually fixing it would require me ripping framework/start,
base/src config/component/container logic into pieces.


Hey Adam, this is not what my results have shown.  When I execute the  
tests in our current trunk there are 216 tests executed (from the  
JUnit reports) and I get code coverage on UtilValidate based on my  
initial comment in the other thread "Here is my question -- when  
looking at the reports it showed 100% line code coverage in  
UtilValidate (for example) but this was for 111 lines.  Clearly this  
class has many more lines than that, and when I opened it up I saw  
that large portions of it were not marked green or red in the report.   
What gives?  :)"


Now, if I decide to explicitly load the base component (and fix the  
test def) two things happen.  1) My JUnit test report now reports 269  
tests being executed and "basetests" appears in the classes on the  
left drilling in shows 53 tests here (216 + 53 = 269).  2) when I run  
the Cobertura report and drill down into UtilValidate it now shows 23%  
line coverage (111/477 lines) and the class is properly marked green/ 
red.


I really think that our current builds are not executing your base  
tests and there is actually not a problem with how the cobertura is  
collecting its coverage metrics, the problem is really  
TestRunContainer creates a JunitSuiteWrapper who asks  
ComponentConfig.getAllTestSuiteInfos and this implementation uses  
getAllComponents() which serves up the static map of configs which are  
initially populated from the component-load.xml.


If we agree to that then I can propose a solution to ensure a  
ComponentConfig instance exists for "base" but avoids parts of the  
component load that we are not interested in but does perform things  
we are interested in (see current ComponentConfig constructor -  
classpathinfos vs. test suite infos).

Re: Renaming of java junit tests

[Robert Morley]

On Apr 8, 2010, at 6:08 AM, Erwan de FERRIERES wrote:

the only thing I see with the tests, is that test files should not  
be at the same directory level as the source code.


I think that we should have :
/src/test
and not :
/src/org/ofbiz//test

the only point in this change, is when doing code coverage, it's  
looking for coverage on the tests, which is not the best idea.


But maybe someone with more knowledge would be able to tell if I'm  
right or not...


For naming the tests, the only thing we need with JUnit 3.8, is to  
have the test prefixed with test. It's true for minilang tests as  
well.


I remember having a discussion with someone based on that folder  
structure for tests; having come from a place where we did just that I  
was now in a place where they saw benefit in keeping the testing code  
in close proximity to the source code it is testing.  I just took a  
look at a few other projects in Apache to see what they have done ...  
what I typically found was that they follow this folder structure as  
well and they typically name their test classes "TestXXX".


Me thinks if we are going to spend anytime reorganizing our unit tests  
and establishing an Ofbiz best practice, we probably should just agree  
on it before I do anything.  Here is the only real information I could  
find from old trusty google ...


"JUnit 3.8 suggests the following naming conventions:

Test Case Class: Named as [classname]Test.java, where "classname" is  
the name of the class that is being tested. A test case class define  
the fixture to run multiple tests. A test case class must be subclass  
of junit.framework.TestCase.


Test Method: Named test[XXX], where "XXX" is any unique name for this  
test. A test method name should be prefixed with "test" to allow the  
TestSuite class to extract it automatically. A test method must be  
declared as "public".


Test Suite: Can be named any way you want to. But Eclipse uses  
AllTests.java as the name. A test suite is a collection of test cases."


The proposal I put forth is as such --

1) Move the junit test source into a folder structure as indicated by  
Erwan
2) Rename the test classes to follow the JUnit 3.8 naming convention  
above
3) Start separate discussion on splitting our "build" target into  
"compile" and "compile-tests" ensuring that test code is not included  
in the standard ofbiz application jar (ie. ofbiz-party.jar becomes  
ofbiz-party.jar and ofbiz-party-test.jar or something similar).

Re: Security Redesign and Release 10.x Branch

[Robert Morley]

+1 not sure on release overhead but release often is desirable from  
where I sit. Nothing wrong with triggering on a major functional  
addition.


Bob

On 2010-04-07, at 2:08 AM, Jacopo Cappellato > wrote:



I would suggest to:
1) release 10.04 before the merge is done
2) merge the code to the trunk, switch to it, fix any possible issue
3) do another release (10.06?)

I know this is not inline with what we currently think a release  
should be, but this is very inline with what the ASF practices and  
so I will continue to insist with the release-often practice. :-)


Jacopo

On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote:

I would like to start bringing parts of the  
executioncontext20091231 branch into the trunk before we create the  
next release branch. The implementation of the new security design  
is not finished, but it will be disabled - so everything will still  
work the same.


My goal is to allow users of the 10.x release to plan for the  
forthcoming changes, and maybe have the conversion to the new  
design completed by the release that follows 10.x.


I will wait a few days, and if there are no objections I will begin  
merging the design into the trunk.


-Adrian

Re: [jira] Commented: (OFBIZ-3633) Minimum order quantity

[Robert Morley]

+1 for #3 - I think that follows the intended use from the data model

On Apr 6, 2010, at 12:10 AM, Rishi Solanki (JIRA) wrote:



   [ https://issues.apache.org/jira/browse/OFBIZ-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853724 
#action_12853724 ]


Rishi Solanki commented on OFBIZ-3633:
--

Hi Team,
Please let us know whether we need to go as we have following options;
1) Achieve this ProductPrice entity patch is attached with Jira.
2) Add a field to Product entity and go from that way.
3) Achieve this thru SupplierProduct entity.

I personally like all the ways of achieving minimum order quantity,  
all has some pros and cons. Better if community finalize the way to  
achieve the functionality so that we can submit the patch. Thanks to  
all for their valuable suggestion.



Minimum order quantity
--

   Key: OFBIZ-3633
   URL: https://issues.apache.org/jira/browse/OFBIZ-3633
   Project: OFBiz
Issue Type: New Feature
Components: order, specialpurpose/ecommerce
  Reporter: Rishi Solanki
   Fix For: SVN trunk

   Attachments: OFBIZ-3633.patch, OFBIZ-3633.patch


It will work as follows;
We will set the special type price as 'MINIMUM_ORDER_PRICE' for a  
Product in ProductPrice entity. On the basis of it we will get the  
minimum order quantity of the product on the basis of this price  
and sale price.
Will get the minimum order quantity for product by division. For  
example we have selling price of product P1 is $10.00 and its  
MINIMUM_ORDER_PRICE is $100.00 then minimum order quantity for the  
product will be --> 100/10 ==> 10.

To achieve the above ;
write a getMinimumOrderQuantity() method in ShoppingCart.java which  
takes the itemBasePrice and productId as in parameter, and call it  
where we add, update the cart items and change the quantity to  
minmumOrderQuantity if it is less then minimum.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Executing unit tests with Cobertura code coverage metrics

[Robert Morley]

On Apr 6, 2010, at 1:50 PM, Adam Heath wrote:


Bob Morley wrote:


Here is my question -- when looking at the reports it showed 100%  
line code
coverage in UtilValidate (for example) but this was for 111 lines.   
Clearly
this class has many more lines than that, and when I opened it up I  
saw that
large portions of it were not marked green or red in the report.   
What

gives?  :)



Coverage in framework/base sucks when running run-tests at the
top-level.  There are overlapping classloaders, and this confuses
cobertura.

Running component tests directly in framework/base, doing 'ant tests'
does give correct coverage metrics.


Does this only apply to framework/base?  When I looked at coverage of  
UtilAccounting (for example) it looks pretty accurate.


Also, we were talking in the office -- our understanding is that the  
Cobertura license would restrict Ofbiz from redistribution, but it  
should be able to use it as part of their build process.  Do you think  
there would be an issue include a target that downloads and deploys  
Cobertura and executes those targets as part of our build process  
internally?  That way we could get these metrics published as we move  
forward.  (Naturally we would have to fix the issue referred to  
above.  Thoughts? 

Re: shoppingcart serialization, not shoppinglist

[Robert Morley]

Introducing a new type "CART" as an OrderType does not feel right to  
me.  It would seem having an Order of type "SalesOrder" and being able  
to influence which functionality you wish to execute on that entity  
via its status (or additional attribute) might be work considering.   
We had a very similar problem, we wanted to work with a persisted  
version of the SalesOrder which was a more long term object from our  
perspective.


What we have done is only apply payments in a single transaction as  
part of completing the order (obviously not totally desirable) but  
this avoided payment processing as part of saving / updating the  
order.  As for inventory reservations, we actually wanted to reserve  
items as they are added to the order so we left this but then built  
some logic around releasing and re-reserving when items were updated/ 
removed from the order.  There were a number of gotchas in the set of  
services you can do with an order -- for example, the service to load  
an order into a cart for updating is really expecting to "clone" the  
order ... I believe it nulls out the orderId on the shopping cart for  
example to cause a new order to be created.


Can you consider a product store configuration that would indicate  
when reservations should occuring based on the state of the order (if  
this does not already exist).  So when you are cobbling up your order  
(ORDER_CREATED status) it may not be doing reservations, but when you  
change it to ORDER_PROCESSING (or some similar state) it will then do  
the reservations, payment perference processing, etc.


On Apr 6, 2010, at 12:59 PM, Adam Heath wrote:


Using a shoppinglist to save a cart is very poor form.  You'll not be
able to save shipgroup assignments, postal address per shipgroup,
shipping method, virtual product features, payment settings, promo
codes, tons of stuff.  We need to be able to restore *all* these  
things.


Saving the cart to an order is a possibility, but that will end up
causing a bunch of ecas(entity and service) to run.  Things like
inventory reservation, posting of payments, etc.

We(Ean and I) have talked, and the way we'd like to see this done, is
to invent a new order type, CART(or something), to go along with
SALES_ORDER and PURCHASE_ORDER.  We are very close to just having to
go and doing this.  Of course, this could cascade to lots of other
code, that explicitly checks the orderTypeId.

In an ideal world, there were be *no* separate serialization step.
The cart would *always* modify the database view of an order.  Always.
The final step would just then be changing it's type from CART to
SALES_ORDER.  This second phase, however, it more difficult.


Robert Morley
Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
rmor...@emforium.com

Re: svn commit: r931024 - /ofbiz/trunk/applications/order/testdef/OrderTest.xml

[Robert Morley]

On 2010-04-06, at 1:41 AM, Adrian Crum  wrote:


--- On Mon, 4/5/10, doo...@apache.org  wrote:

Author: doogie
Date: Tue Apr  6 05:28:12 2010
New Revision: 931024

URL: http://svn.apache.org/viewvc?rev=931024&view=rev
Log:
Remove testdef to a class that doesn't exist.

Modified:

ofbiz/trunk/applications/order/testdef/OrderTest.xml

Modified:
ofbiz/trunk/applications/order/testdef/OrderTest.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/testdef/OrderTest.xml?rev=931024&r1=931023&r2=931024&view=diff
===
===
===
=
--- ofbiz/trunk/applications/order/testdef/OrderTest.xml
(original)
+++ ofbiz/trunk/applications/order/testdef/OrderTest.xml
Tue Apr  6 05:28:12 2010
@@ -21,13 +21,10 @@ under the License.
http://www.w3.org/2001/XMLSchema-instance";

   xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/test-suite.xsd 
">

-
-
-
 
 
 
 
 
 
-
\ No newline at end of file
+


That should have been two separate commits - one to fix the error,  
and another one to add the newline at end of file (formatting change).




no no no create a stub test class with that name and mark it  
depreciated.

Re: Seperate tenant entity for entitymodel.xml

[Robert Morley]

On Apr 5, 2010, at 2:11 PM, Adrian Crum wrote:


Adam Heath wrote:

Adrian Crum wrote:

One of the things to keep in mind during these discussions is the
forthcoming ExecutionContext - a part of the security redesign.  
Instead
of passing a delegator around the framework, the current delegator  
is
assigned to the current thread and a static method exists to  
retrieve it

at any point in the execution path.

I should have that code committed sometime late this week, or this
weekend at the latest. Even though the new security design is  
disabled,
the ExecutionContext can still be used. In fact, we can use it to  
start

fixing issues like the ones described here.

Global statics, even per-thread, can be very bad.


You are welcome to look at the branch and make any corrections you  
feel are necessary.


Consider something stored into the cache, then referenced from  
another

thread.  What is the correct delegator?


Huh?


I would assume that the GenericEntity would still have an instance  
variable for its delegatorName and use that when it comes out of the  
cache.  The thread delegator would only be used for construction?





Does your branch remove all delegator instance variables and method
parameters?


No, I left that for us to work on as a community. I only have so  
many hands and hours in a day. ;-)




I will hold off on packaging up any changes until this work is in ...

Re: Log level for entity with "never-cache" set to true

[Robert Morley]

Fixed as part of OFBIZ-3646.  Two things ... 1) I hope the use of  
"Patch Available" status does not exclude from your filters and 2) I  
should have made this either minor or trivial; but I left it as  
default (major) - that was not my intent.



On Apr 5, 2010, at 12:13 PM, Adrian Crum wrote:


That sounds like an informational message to me.

-Adrian

Bob Morley wrote:
AbstractEntityConditionCache currently has a warning log message  
when the put
method is called for an entity that has "never-cache" set to true.   
These
messages literally flood our ofbiz log files on our servers because  
it is
our standard practice to make heavy use of the application caching  
in Ofbiz.

Would anyone have issue with changing this from a warning to an info
message?  My line of thinking here, is it is good for people to  
make entity

calls with cache set to true and they should not have to consider the
current configuration of the entity.  If the entity happens to turn  
off
caching, then an info message saying it had done so is probably  
sufficient.
There are other similar messages such as storing by primary key  
that I would
change from warning -> info as well.  Internally we preferred this  
approach
over configuration in log4j.  The javadoc from log4j defined WARN  
as "The
WARN level designates potentially harmful situations." and it does  
not seem

to me that in this scenario that is true.
Thoughts?


Robert Morley
Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
rmor...@emforium.com

Re: Seperate tenant entity for entitymodel.xml

[Robert Morley]

Will do. I seem to recall that I had to change a number of signatures  
in the entity pkg to float down appropriate context so default would  
not be used. I will dig up my work on Monday and compare to latest  
ofbiz trunk.


Bob

On 2010-04-04, at 12:03 AM, Adam Heath  wrote:


Adam Heath wrote:

Robert Morley wrote:
Somewhat related, when we implemented our multi-tenant support we  
found

a number of places where the "default" delegator was hardcoded or
assumed. When we had differences in the entity models for our  
deployment

delegator vs. tenant delegators these issues surfaced.


I fixed a bunch of those recently.  The factory methods that create
values and keys would attempt to initialize the object with


Bother, that got sent way before I was done.

Anyways, ...

I fixed a bunch of those recently.  The factory methods that create
values and keys would attempt to initialize the object with data.
However, during the create calls, the delegator hadn't been set yet.
so, when the model was queried, it would try to fetch the value's
delegator, which wasn't set.  It would then try to look up the
delegator by name.  Since once hadn't been set yet, it fell back on
"default".

Look at revision 921989.

Re: Seperate tenant entity for entitymodel.xml

[Robert Morley]

Somewhat related, when we implemented our multi-tenant support we  
found a number of places where the "default" delegator was hardcoded  
or assumed. When we had differences in the entity models for our  
deployment delegator vs. tenant delegators these issues surfaced.


I admit I have not yet taken the time to go over david's  
implementation in detail, but an approach where the entity model is  
different from default might lead you down this road (not that it  
would be a bad thing).


Ultimately we got to a place where we had no dependancy on a delegator  
named default at all. Atleast I hope we did :) Would be willing to  
package this up if you see any value.


Bob

On 2010-04-03, at 8:20 PM, BJ Freeman  wrote:


not sure we are on the same page
the reader code is modified to not only looke for are reader specified
(seed, demo, seed-intial,ext) but those readers with the delegator
appended to them.
when the install for the default delegator is done
it will look for seed-default readers, as well as just seed is in the
command line

when a tenant install is done it will ignore readers=seed-default.
but look for seed-[tenantID] when seed is in the commandline


=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin




Adam Heath sent the following on 4/3/2010 4:25 PM:

Adam Heath wrote:

BJ Freeman wrote:
That way the entities will only be loaded when the default  
delegator is

loaded on install.
there already is a discussion on how to load tenants data that  
does not

included the demo data for the TenantDemoData.xml
and entry in the ofbiz-componets would reference the tenant  
entity as

reader=seeddefault

seed-tenant instead.


And the ability to let a 'demo' reader include other readers as well.


This way the demo data show that those two are only meant for the
default delagator.


=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin

Re: [jira] Closed: (OFBIZ-3600) specialpurpose - pos

[Robert Morley]

I thought I had tabs set to four spaces, is that what you meant or  
something else?


Bob

On 2010-04-02, at 4:33 PM, "Jacques Le Roux (JIRA)"   
wrote:




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


Jacques Le Roux closed OFBIZ-3600.
--

   Resolution: Fixed
 Assignee: Jacques Le Roux

Thanks Bob,

Your patch is in trunk at r930373


Not much to say, but please take care of tabs ;)


specialpurpose - pos


   Key: OFBIZ-3600
   URL: https://issues.apache.org/jira/browse/OFBIZ-3600
   Project: OFBiz
Issue Type: Sub-task
  Reporter: Bob Morley
  Assignee: Jacques Le Roux
   Fix For: SVN trunk

   Attachments: OFBIZ-3600_ResolveJavaWarningsPos.patch





--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Resolving inconsistency between serialized and non-serialized inventory

[Robert Morley]

Yep; when I attempted to do variance on inventory items for serialized 
inventory I traveled down that path to the ECA you are referring to.  The 
trouble is that there is another ECA defined a couple of lines up ...





And this one does the set the QOH/ATP based on the status (for serialized 
only).  So after the ECA is fired and updates the InventoryItem to put them in 
line based on the detail, this one turns around and updates them again and 
potentially puts them back out of wack.

As for the use case for "held" inventory items.  If that is a reasonable use 
case then I agree 100%.  What we do is use location for these situations -- for 
example, when a PO is received we allow the user to receive the inventory into 
a specific location.  So if there is a "review" location that is not pickable 
then it may move there.  Otherwise, it may move into a stockroom location that 
would be pickable.

Putting inventory items on "hold" is perfectly reasonable.  I would have to 
look at the code again, but I wonder how this is done for non-serialized items. 
 Does it break the "bundle" of items (InventoryItem) into two so that one can 
be on "hold" while the other one can have no status?  Currently, the 
"INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is actually 
somewhat invalid to even set this on non-serialized items.

Jacopo, if I start to make some changes based on our discussions would you be 
willing to to review the changes?

- Original Message -
From: "Jacopo Cappellato" 
To: dev@ofbiz.apache.org
Sent: Saturday, March 27, 2010 12:22:47 PM
Subject: Re: Resolving inconsistency between serialized and non-serialized 
inventory

On Mar 27, 2010, at 3:03 PM, Robert Morley wrote:

> There is a balance inventory items service that executes and keeps the 
> details and materialized QOH/ATP in-line.  And this service does it for both 
> types of inventory items -- the trouble is that there is another service that 
> executes specifically for serialized inventory items and it hardcodes the 
> values based on the status.  Something like if "AVAILABLE" set 1/1, if 
> "DELIVERED" set 0/0, else set it to 1/0.  When you stop doing this I think 
> you notice that the InventoryItemDetail is not created for serialized 
> inventory when products are received.
> 

I was referring to the following eca:






> Your comment about holds is interesting -- I wonder, however, where the use 
> case is to hold individual item pieces.

For example you receive some items into the warehouse, and you want to "hold" 
them before quality control etc..

Jacopo

>  For example, I would have thought if you are doing an order and want to put 
> it on hold it effectively has the items on hold.  Same with a transfer, etc.  
> I would have thought that doing these things would do a reservation against 
> the inventory items and reduce the ATP.  To do otherwise would require 
> breaking non-serialized inventory items into buckets each time you want to 
> "hold" a few.  But I could certainly be wrong here ...
> 
> - Original Message -
> From: "Jacopo Cappellato" 
> To: dev@ofbiz.apache.org
> Sent: Saturday, March 27, 2010 5:15:24 AM
> Subject: Re: Resolving inconsistency between serialized and non-serialized 
> inventory
> 
> 
> On Mar 26, 2010, at 8:46 PM, Bob Morley wrote:
> 
>> - consider an enhancement to existing presentment based services that
>> prevents the QOH/ATP values from being set directly.  The line of thinking
>> is that they should be materialized via ECA based on operations to the
>> InventoryItemDetail entity.
> 
> Isn't this already done in this way?
> 
> Jacopo
> 

Re: Resolving inconsistency between serialized and non-serialized inventory

[Robert Morley]

There is a balance inventory items service that executes and keeps the details 
and materialized QOH/ATP in-line.  And this service does it for both types of 
inventory items -- the trouble is that there is another service that executes 
specifically for serialized inventory items and it hardcodes the values based 
on the status.  Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, 
else set it to 1/0.  When you stop doing this I think you notice that the 
InventoryItemDetail is not created for serialized inventory when products are 
received.

Your comment about holds is interesting -- I wonder, however, where the use 
case is to hold individual item pieces.  For example, I would have thought if 
you are doing an order and want to put it on hold it effectively has the items 
on hold.  Same with a transfer, etc.  I would have thought that doing these 
things would do a reservation against the inventory items and reduce the ATP.  
To do otherwise would require breaking non-serialized inventory items into 
buckets each time you want to "hold" a few.  But I could certainly be wrong 
here ...

- Original Message -
From: "Jacopo Cappellato" 
To: dev@ofbiz.apache.org
Sent: Saturday, March 27, 2010 5:15:24 AM
Subject: Re: Resolving inconsistency between serialized and non-serialized 
inventory


On Mar 26, 2010, at 8:46 PM, Bob Morley wrote:

> - consider an enhancement to existing presentment based services that
> prevents the QOH/ATP values from being set directly.  The line of thinking
> is that they should be materialized via ECA based on operations to the
> InventoryItemDetail entity.

Isn't this already done in this way?

Jacopo

Re: OFBiz Tests and Ant build.xml Files

[Robert Morley]

Adrian --

While this is probably not the best practice, what we have done is create a set 
of abstract base classes that extend the JUnit test case.  Depending on the 
architectural layer we are testing, these may just provide some helper methods 
or they may start the container and allow us to run the JUnit from in Eclipse.  
The penalty we pay on the longer running tests is usually around 15 seconds or 
so; but it does allow us to run a whole suite of test cases in Eclipse with 
only the container start-up penalty.

In an effort to focus specifically on the business logic in service 
implementations, we have also made some use of Mockito.  The 
"StandaloneMockTestCase" that we extend here avoids starting up the container 
and allows us to mock out both the delegator and dispatcher.  This provided 
very targeted unit tests (usually as part of code coverage metrics) while 
mocking out external dependencies.  If at all interested, I created a JIRA 
ticket and attached some source that displayed this technique.

What we have not done is figure out how to integrate our unit tests with the 
standard ones in JUnit and have them all run as part of our automated build 
scripts.  Currently, we only run our own unit tests.  We also have not done 
enough work building up TestSuites at the various architectural layers as well 
as for each component.

To be honest, I am unsure if we are even doing this in the best possible way.  
I started out trying to create debug configurations that would execute specific 
unit tests / component tests with the arguments to Start but I found it rather 
tedious.  Moreover, it did not allow us to leverage the good tooling in the IDE.

- Original Message -
From: Adrian Crum 
To: dev@ofbiz.apache.org
Sent: Sat, 7 Nov 2009 02:08:54 -0500 (EST)
Subject: Re: OFBiz Tests and Ant build.xml Files

Mridul,

Thank you! I have to confess, I don't use the command line often (actually 
never). I was referring to running tests from within Eclipse. But I'll give 
your suggestion a try!

-Adrian


--- On Fri, 11/6/09, Mridul Pathak  wrote:

> From: Mridul Pathak 
> Subject: Re: OFBiz Tests and Ant build.xml Files
> To: dev@ofbiz.apache.org
> Cc: "Mridul Pathak" 
> Date: Friday, November 6, 2009, 8:22 PM
> Hi Adrian,
> 
>     To run a component specific JUnit tests you
> can use java -jar ofbiz.jar -test
> -component='component-name'.  I used it a long ago and
> I can recall pretty surely that it worked.  And if this
> works, I believe ant run-tests -component='component-name'
> should also work.
>     Just in case the above commands do not work
> (which I doubt) then we should add this support to the
> framework.
> 
> --
> Thanks,
> Mridul Pathak
> 
> On 07-Nov-09, at 8:28 AM, Adrian Crum wrote:
> 
> > I've been working a lot in the framework, and I would
> like to get some automated tests in there. The problem is,
> there is no "test" ant target at the component level. Is
> there a way that can be done? I'm not familiar with ant
> build.xml files, so could someone help out with that?
> > 
> > -Adrian
> > 
> > 
> > 
> > 
> 
>