from:"Bob Morley"


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

Bob Morley updated OFBIZ-3764:
--

Attachment: OFBIZ-3764_SupplierRel.patch

Quick note: generally I would create individual patches for this; but because 
they were so small I included them in a single patch file.  Feel free to split 
up the "two minor fixes" from the enhancement if so desired.

> Storing supplier relationship sub-class & two related fixes
> ---
>
> Key: OFBIZ-3764
> URL: https://issues.apache.org/jira/browse/OFBIZ-3764
> Project: OFBiz
>  Issue Type: Bug
>  Components: party, product
>Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3764_SupplierRel.patch
>
>
> Despite how much I typed; this is really a very small patch.  :)
> This patch adds a new entity "SupplierRel" which is a sub-class of 
> "PartyRelationship" (as well as a view-entity for convenience).  It provides 
> a new field "accountNumber" that can be used to store the long-term account 
> number assigned to the relationship between the Company and its Supplier.  
> The life of this account number is longer than any agreement between the two, 
> so it has been put on this informal relationship.  Moreover, it is possible 
> to have an informal relationship between a company and a supplier with out an 
> explicit binding agreement -- this was discussed most recently in this thread:
> http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162
> ALSO -- this patch fixes two problems that I encountered when attempting to 
> create a party relationship.
> a) It did not look right to have an empty dropdown for status -- I created 
> the standard "Created" status under the PARTY_REL_STATUS type so that we show 
> the only applicable status.  There does not appear to be any specific logic 
> looking for party relationships with a blank status, so creating ones with 
> this status should not cause any issues.
> b) When creating the PartyRelationship the response in the controller was of 
> type "view-last" which was a problem because the last controller request was 
> typically the ajax one to "FindPartyName" which was used as part of the party 
> lookup field in that form.  The net result, was that on success it would 
> render the PartyName instead of replaying the EditPartyRelationships.  
> Changed form "view-last" to "view" to resolve this issue.

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

[jira] Created: (OFBIZ-3764) Storing supplier relationship sub-class & two related fixes

Storing supplier relationship sub-class & two related fixes
---

Key: OFBIZ-3764
URL: https://issues.apache.org/jira/browse/OFBIZ-3764
Project: OFBiz
Issue Type: Bug
Components: party, product
Reporter: Bob Morley
Fix For: SVN trunk
Attachments: OFBIZ-3764_SupplierRel.patch

Despite how much I typed; this is really a very small patch. :)

This patch adds a new entity "SupplierRel" which is a sub-class of
"PartyRelationship" (as well as a view-entity for convenience). It provides a
new field "accountNumber" that can be used to store the long-term account
number assigned to the relationship between the Company and its Supplier. The
life of this account number is longer than any agreement between the two, so it
has been put on this informal relationship. Moreover, it is possible to have
an informal relationship between a company and a supplier with out an explicit
binding agreement -- this was discussed most recently in this thread:

http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162

ALSO -- this patch fixes two problems that I encountered when attempting to
create a party relationship.

a) It did not look right to have an empty dropdown for status -- I created the
standard "Created" status under the PARTY_REL_STATUS type so that we show the
only applicable status. There does not appear to be any specific logic looking
for party relationships with a blank status, so creating ones with this status
should not cause any issues.

b) When creating the PartyRelationship the response in the controller was of
type "view-last" which was a problem because the last controller request was
typically the ajax one to "FindPartyName" which was used as part of the party
lookup field in that form. The net result, was that on success it would render
the PartyName instead of replaying the EditPartyRelationships. Changed form
"view-last" to "view" to resolve this issue.

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

[jira] Updated: (OFBIZ-3763) Remove reference to EbayStoreScheduledJobs.xml (was removed)


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

Bob Morley updated OFBIZ-3763:
--

Attachment: OFBIZ-3763_RemoveEbayDemoDataBadReference.patch

> Remove reference to EbayStoreScheduledJobs.xml (was removed)
> 
>
> Key: OFBIZ-3763
> URL: https://issues.apache.org/jira/browse/OFBIZ-3763
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ebay
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3763_RemoveEbayDemoDataBadReference.patch
>
>
> The data seed file was removed in r916150 but the reference in 
> ofbiz-component.xml was never removed.  Simply removed this reference to 
> avoid the error when performing an "ant run-install".

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

[jira] Created: (OFBIZ-3763) Remove reference to EbayStoreScheduledJobs.xml (was removed)

Remove reference to EbayStoreScheduledJobs.xml (was removed)


 Key: OFBIZ-3763
 URL: https://issues.apache.org/jira/browse/OFBIZ-3763
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ebay
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


The data seed file was removed in r916150 but the reference in 
ofbiz-component.xml was never removed.  Simply removed this reference to avoid 
the error when performing an "ant run-install".

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

[jira] Commented: (OFBIZ-3749) Field description tooltips show key if help text is not found


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

Bob Morley commented on OFBIZ-3749:
---

Two quick questions ...

1) Since Debug.logInfo ultimately determines if logging for "info" is on, isn't 
it better to just call Debug.logInfo directly (paying the string construction 
penalty of course) ?

2) While it is pretty unlikely that the help key here would be defined in the 
resource bundle with the same value; this code would turn those into empty 
string.  Would it be better to overload getMessage to allow an optional default 
message ... so we could do ...

String fieldDescription = UtilProperties.getMessage(entityResourceName, 
messageId, locale, null);
if (fieldDescription == null) {
...


> Field description tooltips show key if help text is not found
> -
>
> Key: OFBIZ-3749
> URL: https://issues.apache.org/jira/browse/OFBIZ-3749
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS
>Affects Versions: Release Branch 10.04, SVN trunk
>Reporter: chris snow
>Assignee: Erwan de FERRIERES
> Fix For: Release Branch 10.04, SVN trunk
>
> Attachments: UtilHelpText.patch
>
>
> Tooltip currently shows field help message key if no help text has been 
> provided.  For details, see:
> http://ofbiz.135035.n4.nabble.com/New-branch-is-now-available-for-upcoming-releases-of-10-04-series-tp2111929p2122465.html

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

[jira] Commented: (OFBIZ-3748) Remove test specific code in the GenericDelegator


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

Bob Morley commented on OFBIZ-3748:
---

I think separate Factory implementations is appropriate.  Ultimately, one would 
not have the test objects in the production jar at all so there should not be 
reference to them in the "DelegatorFactoryImpl".

I have read that thread and it does make sense.  The trouble is the amount of 
lengths you had to go through to solve what (at that time and at this current 
point in time) is still a theoretical requirement.  My approach is usually to 
attempt to create a flexible solution that does its best not to hamstring 
someone in the future, but does not try to solve problems that currently do not 
exist.  To the best of my knowledge, that probably came out of a lot of years 
with agile practices.  I would have put in your first solution and then if we 
have a need to execute in parallel solve that problem and the raft of other 
problems you would encounter.  When you go to tackle the problem (test 
framework execution) you may solve it with something other than parallel 
execution.

Agree we are intruding on the GenericDelegator implementation; but that is 
really not my intent.  What I would typically do is override just the pieces I 
wanted to make changes; the trouble is that the implementation of these methods 
are while not monolithic, they are still rather lengthy.  Would rather gut it 
up a bit more to make it more modular that would allow sub-classes more degrees 
of freedom.  Perhaps it would be better to have the database operations moved 
into their own methods -- performUpdate, performDelete, performInsert kinda 
deal and then override in the test delegator and add our test behaviours?

> Remove test specific code in the GenericDelegator
> -
>
> Key: OFBIZ-3748
> URL: https://issues.apache.org/jira/browse/OFBIZ-3748
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Attachments: OFBIZ-3748_TestGenericDelegator.patch
>
>
> Adam -- This is the results from our conversation on consistent rolling back 
> of unit testers.  We talked about moving the logic that is in the 
> GenericDelegator that is specific to testing into a sub-class.  This patch is 
> NOT meant to be merged at this time, I wanted to put it up for review before 
> I continue down this path ...
> Here are the key pieces:
> - TestGenericDelegator - test version of a generic delegator that contains 
> the ability to record the list of database operations and then 
> programmatically roll them back in reverse order.  This was from existing 
> code in GenericDelegator.
> - TestDelegatorFactoryImpl - a new service implementation of DelegatoryFactor 
> that will construct instances of TestGenericDelegator.
> Things to consider:
> - Should rollback be on the Delegator interface?  I sort of field it should 
> not be there; but I left it there for now with GenericDelegator reporting an 
> error if it is called.
> - Since there are two implementations of the DelegatorFactory there needs to 
> be a way to determine which one to use; the way I have done this in the past 
> is through configuration.  Usually something like ... 
> service.org.ofbiz.entity.DelegatorFactory=org.ofbiz.entity.DelegatorFactoryImpl
>  that could (for Ofbiz) be placed in the start.properties or test.properties 
> file.  However, looking at the factory unit tester it looks like each factory 
> should be able to determine if it is applicable based on the incoming 
> parameters.  As a result (until more discussion) I have made a choice based 
> on the delegator name -- I know this is clearly NOT the go forward method.  
> But would like some suggestions here ... was considering a new attribute on 
> the entityengine.xml delegator definition, but there should be some mechanism 
> to be able to provide control over which implementation is used I would think 
> ...
> - I got an inkling that "base delegator name" may not be required anymore.  
> This is because I no longer create the standard delegator and then "clone" to 
> a test version.  I simply instantiate the proper version right up front ... 
> Moreover, I let the delegator / dispatcher names be as they are (not adding a 
> random alpha-numeric suffix).  Not sure about this, did not research further.
> Go forward plan --
> - If there are agreement on these changes and a resolution for things to 
> consider point #2 above, I would then re-code my standalone rollback base 
> class for unit tests to leve

Re: Splitting out single and list into separate form widgets

2010-05-03 Thread Bob Morley

Scott Gray-2 wrote:
> 
> On 4/05/2010, at 11:32 AM, Adrian Crum wrote:
> 
>> On 5/3/2010 4:25 PM, Scott Gray wrote:
>>> Sometimes I think using the same schema and class for single forms and
>>> list forms holds us back from implementing features specific to one or
>>> the other and even when we do it results in a messy schema.
>>> 
>>> What if we were to separate the two but have them share a common base? 
>>> We could start by separating the schemas and then work on the code.
>>> 
>>> Thoughts?
>> 
>> Any effort to clean up and improve widget code gets a big thumbs-up from
>> me.
> 

I was kind of amused by this only because it was one of the first thoughts I
had when I started looking at Ofbiz.  One of the first things we wanted to
do was implement a more functional "grid" view of a form of type list.  My
first prototype involved creating a "ModelGrid" which extended / borrowed
heavily from the ModelForm.  ModelGrid gave some separation between
attributes that were form related vs. ones of that were grid related --
things like sorting, grouping, etc come to mind.

Unfortunately (in my mind), I lost the "model off" and we ended up with
"formgrid" that contains the same elements as the "form".  What has happened
is we have created a pile of new attributes that are only applicable to the
grid (and a whole lost more than are not applicable to it).  Our internal
solution right now is to name all of the former as "grid-xxx".

In short, I would be very much in favor into splitting the "form" from the
"list"||"grid".  I still have the "ModelGrid" code around if you wanted to
look at it.  In affect, it was a peer to ModelForm but it leveraged its
field rendering capabilities.  They had their own dtd and resided in their
own file.  So you would see PartyForms.xml and PartyGrids.xml together ...

As a side note; I think my use of "grid" was bad ... to me that really
represents a UI representation of a list of entities; and List is really the
better term to use.  At the time, I had extended the html renderer to
provide an extjs implementation that gave us some nice client-side features
that come with that grid.

Let me know if you think there is any value at seeing what I have done or if
you think I can help out in any way.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Splitting-out-single-and-list-into-separate-form-widgets-tp2124767p2124882.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Storing supplier provided account number

2010-05-03 Thread Bob Morley



Scott Gray-2 wrote:
> 
> I think you missed the second half of my earlier email:
>> I'm not sure how I would handle something like a security card but IMO
>> the Employment entity should be an extension to PartyRelationship, I mean
>> it already shares the same primary key fields.
> 
> Employment already has the same PK fields as PartyRelationship.
> 

Yep; I had definitely glossed over that.  In my head I was thinking that
PartyRelationship had a partyRelationshipId that could be added to
Employment and Employment could have those other fields removed.  But you
are quite correct, we could simply use the existing primary key fields.

Would there be any thought to doing the former?  I don't think I want to
bite that off to be honest, but one could create the entity such that it has
a single primary key and the others would make up a unique index. 
Personally, I don't know if that is a good idea but it would reduce
redundancy in the sub-classes.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-tp2076162p2124868.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Updated: (OFBIZ-3748) Remove test specific code in the GenericDelegator


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

Bob Morley updated OFBIZ-3748:
--

Summary: Remove test specific code in the GenericDelegator  (was: Remove 
test specific code in the GeneralDelegator)

> Remove test specific code in the GenericDelegator
> -
>
> Key: OFBIZ-3748
> URL: https://issues.apache.org/jira/browse/OFBIZ-3748
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Attachments: OFBIZ-3748_TestGenericDelegator.patch
>
>
> Adam -- This is the results from our conversation on consistent rolling back 
> of unit testers.  We talked about moving the logic that is in the 
> GenericDelegator that is specific to testing into a sub-class.  This patch is 
> NOT meant to be merged at this time, I wanted to put it up for review before 
> I continue down this path ...
> Here are the key pieces:
> - TestGenericDelegator - test version of a generic delegator that contains 
> the ability to record the list of database operations and then 
> programmatically roll them back in reverse order.  This was from existing 
> code in GenericDelegator.
> - TestDelegatorFactoryImpl - a new service implementation of DelegatoryFactor 
> that will construct instances of TestGenericDelegator.
> Things to consider:
> - Should rollback be on the Delegator interface?  I sort of field it should 
> not be there; but I left it there for now with GenericDelegator reporting an 
> error if it is called.
> - Since there are two implementations of the DelegatorFactory there needs to 
> be a way to determine which one to use; the way I have done this in the past 
> is through configuration.  Usually something like ... 
> service.org.ofbiz.entity.DelegatorFactory=org.ofbiz.entity.DelegatorFactoryImpl
>  that could (for Ofbiz) be placed in the start.properties or test.properties 
> file.  However, looking at the factory unit tester it looks like each factory 
> should be able to determine if it is applicable based on the incoming 
> parameters.  As a result (until more discussion) I have made a choice based 
> on the delegator name -- I know this is clearly NOT the go forward method.  
> But would like some suggestions here ... was considering a new attribute on 
> the entityengine.xml delegator definition, but there should be some mechanism 
> to be able to provide control over which implementation is used I would think 
> ...
> - I got an inkling that "base delegator name" may not be required anymore.  
> This is because I no longer create the standard delegator and then "clone" to 
> a test version.  I simply instantiate the proper version right up front ... 
> Moreover, I let the delegator / dispatcher names be as they are (not adding a 
> random alpha-numeric suffix).  Not sure about this, did not research further.
> Go forward plan --
> - If there are agreement on these changes and a resolution for things to 
> consider point #2 above, I would then re-code my standalone rollback base 
> class for unit tests to leverage this functionality.  This would ensure we 
> consistently rollback regardless of executing the test directly or through 
> the test infrastructure.

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

[jira] Updated: (OFBIZ-3748) Remove test specific code in the GeneralDelegator


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

Bob Morley updated OFBIZ-3748:
--

Attachment: OFBIZ-3748_TestGenericDelegator.patch

> Remove test specific code in the GeneralDelegator
> -
>
> Key: OFBIZ-3748
> URL: https://issues.apache.org/jira/browse/OFBIZ-3748
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Attachments: OFBIZ-3748_TestGenericDelegator.patch
>
>
> Adam -- This is the results from our conversation on consistent rolling back 
> of unit testers.  We talked about moving the logic that is in the 
> GenericDelegator that is specific to testing into a sub-class.  This patch is 
> NOT meant to be merged at this time, I wanted to put it up for review before 
> I continue down this path ...
> Here are the key pieces:
> - TestGenericDelegator - test version of a generic delegator that contains 
> the ability to record the list of database operations and then 
> programmatically roll them back in reverse order.  This was from existing 
> code in GenericDelegator.
> - TestDelegatorFactoryImpl - a new service implementation of DelegatoryFactor 
> that will construct instances of TestGenericDelegator.
> Things to consider:
> - Should rollback be on the Delegator interface?  I sort of field it should 
> not be there; but I left it there for now with GenericDelegator reporting an 
> error if it is called.
> - Since there are two implementations of the DelegatorFactory there needs to 
> be a way to determine which one to use; the way I have done this in the past 
> is through configuration.  Usually something like ... 
> service.org.ofbiz.entity.DelegatorFactory=org.ofbiz.entity.DelegatorFactoryImpl
>  that could (for Ofbiz) be placed in the start.properties or test.properties 
> file.  However, looking at the factory unit tester it looks like each factory 
> should be able to determine if it is applicable based on the incoming 
> parameters.  As a result (until more discussion) I have made a choice based 
> on the delegator name -- I know this is clearly NOT the go forward method.  
> But would like some suggestions here ... was considering a new attribute on 
> the entityengine.xml delegator definition, but there should be some mechanism 
> to be able to provide control over which implementation is used I would think 
> ...
> - I got an inkling that "base delegator name" may not be required anymore.  
> This is because I no longer create the standard delegator and then "clone" to 
> a test version.  I simply instantiate the proper version right up front ... 
> Moreover, I let the delegator / dispatcher names be as they are (not adding a 
> random alpha-numeric suffix).  Not sure about this, did not research further.
> Go forward plan --
> - If there are agreement on these changes and a resolution for things to 
> consider point #2 above, I would then re-code my standalone rollback base 
> class for unit tests to leverage this functionality.  This would ensure we 
> consistently rollback regardless of executing the test directly or through 
> the test infrastructure.

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

[jira] Created: (OFBIZ-3748) Remove test specific code in the GeneralDelegator

Remove test specific code in the GeneralDelegator
-

 Key: OFBIZ-3748
 URL: https://issues.apache.org/jira/browse/OFBIZ-3748
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3748_TestGenericDelegator.patch

Adam -- This is the results from our conversation on consistent rolling back of 
unit testers.  We talked about moving the logic that is in the GenericDelegator 
that is specific to testing into a sub-class.  This patch is NOT meant to be 
merged at this time, I wanted to put it up for review before I continue down 
this path ...

Here are the key pieces:

- TestGenericDelegator - test version of a generic delegator that contains the 
ability to record the list of database operations and then programmatically 
roll them back in reverse order.  This was from existing code in 
GenericDelegator.

- TestDelegatorFactoryImpl - a new service implementation of DelegatoryFactor 
that will construct instances of TestGenericDelegator.

Things to consider:

- Should rollback be on the Delegator interface?  I sort of field it should not 
be there; but I left it there for now with GenericDelegator reporting an error 
if it is called.

- Since there are two implementations of the DelegatorFactory there needs to be 
a way to determine which one to use; the way I have done this in the past is 
through configuration.  Usually something like ... 
service.org.ofbiz.entity.DelegatorFactory=org.ofbiz.entity.DelegatorFactoryImpl 
that could (for Ofbiz) be placed in the start.properties or test.properties 
file.  However, looking at the factory unit tester it looks like each factory 
should be able to determine if it is applicable based on the incoming 
parameters.  As a result (until more discussion) I have made a choice based on 
the delegator name -- I know this is clearly NOT the go forward method.  But 
would like some suggestions here ... was considering a new attribute on the 
entityengine.xml delegator definition, but there should be some mechanism to be 
able to provide control over which implementation is used I would think ...

- I got an inkling that "base delegator name" may not be required anymore.  
This is because I no longer create the standard delegator and then "clone" to a 
test version.  I simply instantiate the proper version right up front ... 
Moreover, I let the delegator / dispatcher names be as they are (not adding a 
random alpha-numeric suffix).  Not sure about this, did not research further.

Go forward plan --

- If there are agreement on these changes and a resolution for things to 
consider point #2 above, I would then re-code my standalone rollback base class 
for unit tests to leverage this functionality.  This would ensure we 
consistently rollback regardless of executing the test directly or through the 
test infrastructure.

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

Re: Controller Injection

2010-05-02 Thread Bob Morley

Bruno Busco wrote:
> 
> 2010/5/2 Scott Gray 
> 
>> To me extend seems clear but I agree it does conflict with the way that
>> term is used elsewhere in the framework.  I don't really like merge
>> though,
>> it doesn't feel like an accurate description of what is happening.  Any
>> other ideas anyone?
>>
> 
> What about "overrides" ?
> 

When i first read of the feature I felt "override" was appropriate because
the original use case was defined in terms of overriding a view-map entry. 
But (without looking at the implementation) I think you could use this as an
extension as well ... for example, you could likely provide a new
view-handler (extension) to go along with an override view-map, and that
newly rendered form could postback to a new request-map (extension).  So I
understand why Scott felt "extend" was the right term ...

I wonder if this is really just external modification to a controller. 
Terms that felt kinda close were stuff like application,
external-definition, enhance ... perhaps something in that ballpark could be
used to define exactly what is happening here ?
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Controller-Injection-tp2076418p2123369.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Survey Response Validation

2010-04-29 Thread Bob Morley

Scott Gray-2 wrote:
> 
> I need to do some custom survey response validation that happens in
> addition to the OOTB answer validation.  I was hoping to be able to use
> Survey.responseService but this is run asynchronously and looks to be more
> of a post processor.
> 
> Any thoughts about about adding a validationService field to the Survey
> entity?  The service would run before the SurveyResponse is committed but
> after the OOTB answer validation.
> 

We would make use of such a feature.

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

This would allow programmatic ModelForms an entry point for server-side
validation as well as system-wide server-side validation via model
transformation.  It could also be used to separate/share validation from
execution in our standard xml representation of the ModelForm.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Survey-Response-Validation-tp2075211p2076492.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Controller Injection

2010-04-29 Thread Bob Morley



Scott Gray-2 wrote:
> 
> What about adding something like the following to ofbiz-component.xml
> schema
>  include-controller="path/to/controller.xml"
> />
> 
> This would basically be similar to the "include" element available in the
> controller schema except that it would override any elements in the
> web-app's normal controller.
> 
> Doing this would allow us to externally override any requests and views in
> a base application's controller without needing to completely replace the
> existing webapp and could be a good starting point for building "plug-in"
> support.
> 
> Say for example you simply want to make a few changes to the EditProduct
> screen, you could just override the view-mapping to point to a screen in
> your custom component and boom, you're done.
> 

I really like the concept.  Building on this, two variances for your
consideration came to mind ...

 ...

   [standard request & view maps elements]
http://ofbiz.135035.n4.nabble.com/Controller-Injection-tp2076418p2076487.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Storing supplier provided account number

2010-04-29 Thread Bob Morley

Ya perhaps ... but it just doesn't feel right.  The more thought I gave it
the more I started to like the agreement approach.  On my drive home I asked
myself if I could come up with an example of something that represents a
relationship between two parties AND would have some sort of identify
fields.  In the end I could not come up with anything ...  I think all of
our examples are reasonably modeled as agreements and one could argue that
the Employment entity in Ofbiz really should be an agreement as well.  DMR
book Vol1 suggests it as a sub-class of Agreement in fig 4.13.

If PartyRelation is really just hooking up parties for (mostly) navigational
purposes; then anything more than that seems to usually represent some sort
of Agreement between the two parties.  In this way it seems Agreement is
just a specialization of PartyRelationship.

I will do more research and come up with a more concrete proposal for review
(if any changes are required at all).

Adrian Crum wrote:
> 
> We already have PartyIdentification and PartyIdentificationType. Maybe 
> those could be tied to PartyRelationship somehow.
> 

-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-tp2076162p2076460.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Storing supplier provided account number

2010-04-29 Thread Bob Morley


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).
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-tp2076162p2076162.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

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

2010-04-27 Thread Bob Morley



Scott Gray-2 wrote:
> 
> But since you did, can I just say that the event handlers aren't really
> intended for data preparation which should be done in the view handling
> :-)
> 
> Regards
> Scott
> 
> HotWax Media
> http://www.hotwaxmedia.com
> 
> On 27/04/2010, at 10:53 AM, Marc Morin wrote:
> 
>> Not sure you wanted to post this to d...@ofbiz mailing list
> 

Ahh crap my mistake heh!  Scott -- I agree and will look closer at what we
are doing here.  We had an number of formerly navigation (anchor) links that
got converted to hidden form when we changed how they were being represented
in xml for the screen/form.  I suspect Ofbiz might have the same ... any
controller request that is a simple page render should not have an "event"
coded or it would exhibit this behaviour.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Proper-modeling-of-parameters-and-impact-to-page-refresh-SVN-13393-tp2065627p2067450.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

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

2010-04-25 Thread Bob Morley (JIRA)


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

Bob Morley commented on OFBIZ-3700:
---

Adrian -- I am working through a production run and ran into a slight glitch 
related to this.  The ProductionRun class has a quantity on it defined as a 
BigDecimal.  In the store() method on this class, it uses this to set the value 
on the WorkEffortGoodStandard.  In our source, this entities 
"estimatedQuantity" field is a java double which causes a big fat stack trace 
(but does do the conversion).  My hope is you will include 
WorkEffortGoodStandard in your conversion efforts.

Also -- take a look at getProductProduced which figures out how many products 
will be produced for this production run (by getting the WorkEffortGoodStandard 
product to be delivered).  This qty is originally set in createProductionRun by 
the production run's desired quantity.  However, when store() is called it does 
not update the qty on the ProductionRun -- just the underlying 
WorkEffortGoodStandard value.  It seems to me we should consider having it 
update the ProductionRun's work effort "quantityToProduce" as well.

> Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
> --
>
> Key: OFBIZ-3700
> URL: https://issues.apache.org/jira/browse/OFBIZ-3700
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>    Affects Versions: SVN trunk
>Reporter: Bob Morley
>Assignee: Adrian Crum
>Priority: Minor
> Fix For: SVN trunk
>
>
> It appears that this entity was missed from the BigDecimal conversion.  Ran 
> into this when ProductionRunServices was attempting to create a WorkEffort 
> (it is passing the quantity to produce as a BigDecimal).  A different bug in 
> OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
> (which was allowing ProductionRuns to be created).  At any rate, we should 
> convert this entity and any other quantity related entities in the WorkEffort 
> component.

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

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

2010-04-25 Thread Bob Morley



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

Ok I have created a patch ->
https://issues.apache.org/jira/browse/OFBIZ-3740.  We can continue any
discussion on that patch; but it should be noted that this patch will not do
anything unless an order-by is updated to include "NULLS FIRST" or "NULLS
LAST".
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Bug-Not-Null-Values-are-at-top-when-fetching-list-from-database-in-Release-9-04-tp2062221p206.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Updated: (OFBIZ-3740) Support for order by nulls first/last

2010-04-25 Thread Bob Morley (JIRA)


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

Bob Morley updated OFBIZ-3740:
--

Attachment: OFBIZ-3740_SupportOrderByNulls.patch

> Support for order by nulls first/last
> -
>
> Key: OFBIZ-3740
> URL: https://issues.apache.org/jira/browse/OFBIZ-3740
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3740_SupportOrderByNulls.patch
>
>
> This patch provides the fundamentals to resolve an issue where the sorting of 
> null values were inconsistent (sometimes sorting first and other times 
> sorting last).  Specifically, this patch allows one to create an order-by 
> clause via any of the order-by elements of "-myField NULLS LAST" where this 
> text parses out the - (as descending) and the "nulls last".
> Since not all databases support the "nulls" argument on an order by clause 
> (it was introduced as part of the OLAP support specification) , our 
> entity-engine.xml file allows each data source to indicate if it has this 
> support.  If the support does not exist and nulls first/last is specified, 
> the sql that is generated uses native sql to simulate the nulls first/last 
> intent.  At this time, the derby, postgres, and oracle databases are marked 
> to use the nulls first grammar.
> Right now, if you do not specify "NULLS XXX" in the field-name for the 
> order-by it makes no change whatsever (naturally this assumption could be 
> changed to have a default).
> It should be noted, that my intent here was ultimately to "properly" model 
> the order by into something whose xml representation could look something 
> like ...
> 

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

[jira] Created: (OFBIZ-3740) Support for order by nulls first/last

2010-04-25 Thread Bob Morley (JIRA)

Support for order by nulls first/last
-

 Key: OFBIZ-3740
 URL: https://issues.apache.org/jira/browse/OFBIZ-3740
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
Priority: Minor
 Fix For: SVN trunk
 Attachments: OFBIZ-3740_SupportOrderByNulls.patch

This patch provides the fundamentals to resolve an issue where the sorting of 
null values were inconsistent (sometimes sorting first and other times sorting 
last).  Specifically, this patch allows one to create an order-by clause via 
any of the order-by elements of "-myField NULLS LAST" where this text parses 
out the - (as descending) and the "nulls last".

Since not all databases support the "nulls" argument on an order by clause (it 
was introduced as part of the OLAP support specification) , our 
entity-engine.xml file allows each data source to indicate if it has this 
support.  If the support does not exist and nulls first/last is specified, the 
sql that is generated uses native sql to simulate the nulls first/last intent.  
At this time, the derby, postgres, and oracle databases are marked to use the 
nulls first grammar.

Right now, if you do not specify "NULLS XXX" in the field-name for the order-by 
it makes no change whatsever (naturally this assumption could be changed to 
have a default).

It should be noted, that my intent here was ultimately to "properly" model the 
order by into something whose xml representation could look something like ...



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

Re: Consistent required field indicators

2010-04-24 Thread Bob Morley



Bilgin Ibryam-2 wrote:
> 
> 1. Cleaning up the forms: remove the "required" label 
> (tooltip="${uiLabelMap.CommonRequired}") and css style 
> (widget-style="required") and add in their place required-field="true"
> 2. Change macro renderer so that if a field is required it is indicated 
> by asterix (as it is right now) plus a css style (the same as 
> widget-style="required")
> 
> Are there any objections to this?
> 

I very much like it.

Would it be possible to include an element with a class around the
required-marker?  Perhaps something like * ?  Thinking people could
remove/change the styling of the marking in a particular theme.  Would also
like to see the marker rendering in a single place rather than rendered in
the macro for each widget.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Consistent-required-field-indicators-tp2062702p2063457.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Regarding SVN commit r892904

2010-04-21 Thread Bob Morley

Adrian Crum wrote:
> 
> Joda Time claims to fix the problems with the Java date/time API, while 
> it duplicates the problems in the Java date/time API. The only real 
> advantage to Joda Time is the additional calendars - which OFBiz already 
> has in the ICU4J library.
> 
> The author of JSR-310 complains about Joda in the spec and claims that 
> JSR-310 is better than the Joda Time API. I don't believe JSR-310 will 
> become a part of the Java spec any time soon. JSR-275 is more mature and 
> has seen a lot more activity than JSR-310, yet even that doesn't have 
> enough votes to get it into the Java spec.
> 
> If we actually had a choice, I would vote for using JSR-310 over Joda 
> Time. The problem is, there is no library that I can find. So far it 
> appears to be a draft specification only.
> 
> In the meantime we could really use a simple set of date/time classes 
> that take the guesswork out of handling dates/times. I started with the 
> Quantity pattern and included some good ideas from JSR-275 and JSR-310. 
> I believe the result is easy to use and reliable.
> 
> Mini-language has a set-calendar element - maybe that is the end result 
> of the conversation you were thinking of.
> 

Ahh that is good info -- what made me think of it was a Java Posse podcast I
had been listening to when they were going through some of the proposed Java
7 enhancements.  I had remembered them talking about Joda rather favorably
at the time.  At any rate, I am more than happy to use TimeDuration in its
current form and cut over to whatever you provide going forward.  If I made
an changes I will post them up so we can review and discuss if they have any
merit.

This conversation has forked quite a bit from its starting point.  I think
we had agreed that it is probably better to handle "setup" as a separate
WorkEffort rather than coupling setup and actual task time in a single
WorkEffort.  Time constraints as they are, what I am going to do for our
project is re-activate the creation of the TimeEntry and only make use of
"task time".  If one of our customers is interested in "setup" they would
create a related WorkEffort and manage it consistently with other WorkEffort
entities (in regards to time tracking, estimate, and task time).

Once I have something complete I will wrap it up in a patch for you guys to
review.  This would include UI elements to make use of the TimeEntries that
are created in relation to the WorkEffort both in that component and in
Manufacturing (as per Jacopo's suggestions).  I suspect this thread or its
related JIRA will get more legs once I am closer to delivering something.
-- 
View this message in context: 
http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2019187.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Regarding SVN commit r892904

2010-04-21 Thread Bob Morley



Adrian Crum-2 wrote:
> 
> In the meantime, I'm working on a date/time library that includes an
> ElapsedTime class (an improved TimeDuration class) that follows Martin
> Fowler's Quantity pattern.
> 

I am certainly not interested in re-inventing the wheel here.  I know in our
solution we are going to allow entry against a ProductionRun task in hours
and I will want to leverage this TimeDuration as you have in
WorkEffortServices.

Way back in 2006 - 2007 there was talk of including Joda time into Ofbiz (at
the time the thread dealt with wrapping up time related functionality in
minilang).  Do you know why we decided to back-off Joda time (if there was a
conscious decision there)?  My understanding is that JSR 310 (new java
date/time apis) that has been proposed for Java 7 is largely based on Joda
time.  Being that the lic. is favorable, I would have thought pulling in and
using their Duration might make sense vs. maintaining our own TimeDuration
and/or a new date/time library?  Very interested in your thoughts because
this really appears to be something in your wheel house.
-- 
View this message in context: 
http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2019014.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Regarding SVN commit r892904

2010-04-20 Thread Bob Morley

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: svn commit: r936100 - in /ofbiz/trunk: applications/product/entitydef/ applications/product/servicedef/ applications/product/src/org/ofbiz/product/category/ applications/product/widget/catalog/ fr

2010-04-20 Thread Bob Morley

Adam Heath-2 wrote:
> 
> introductionDate is when the store actually added the product to their
> catalog, and started making it available, which may be completely
> different then when it was first published.
> 

What struck me about this is that products in all sorts of enterprise
verticals may have a whole host of "dates" and other product metadata that
may be pertinent.  As a result, I would have thought use of ProductFeature
or perhaps a ProductAttribute might be have been a better fit from a
business pov (ignoring benefits with a strongly typed field).

When selling books, is it not possible that you have a "publish date" which
may be different from a "pre-order" date (which appears to be your use case
here)?  I would want to look at the model but I would have thought that
there is some control of what products may be back-ordered (aka a pre-order)
already in place ... perhaps the only support is a boolean flag at this time
... hmmm

Definitely willing to be completely wrong here; but those things struck me
when I read this a few hours ago ...
-- 
View this message in context: 
http://n4.nabble.com/Re-svn-commit-r936100-in-ofbiz-trunk-applications-product-entitydef-applications-product-servicedef--tp2018179p2018370.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Regarding SVN commit r892904

2010-04-20 Thread Bob Morley


I had accidentally replied via nabble to the Ofbiz - Commits sub-form; so I
am going to move my response to Ofbiz - Dev.  If anyone saw that, I am going
to rework my response here because after some consideration and discussion
in our office, I think we have a better proposal.

-- 

Part of this revision caused the TimeEntry to no longer be created for work
performed on the ProductionRun task.  Was the comment out intentional?

Let's say this was an accident ...

I think it is valuable to be creating the TimeEntry for the WorkEffort.  It
provides valuable information about a resource allocating time to the
particular task.  The trouble with the original implementation is that the
data model resource book seemed to have a single "time" for this purpose --
"hours" on TimeEntry along with "hours" on the WorkEffort (in terms of the
total hours spent).

There are good reasons to be able to have separation on the Work Effort for
various classifications of "time worked" on a specific Task.  Currently,
there are two classifications "setup" and "task" hours (specified in
milliseconds).  The trouble is that a single TimeEntry is not going to
provide us with this split.

My initial recommendation was to create a new entity WorkEffortTimeEntry
that would allow a single WorkEffort to be bound to many TimeEntry entities. 
These entities could have different types so you would have the details of
the materialized amount that is stored on the WorkEffort itself.  However, I
think it would actually be better to consider going with two (or more)
WorkEfforts and each of them having its own TimeEntry.

The idea here is if you have a production run and you have a Task which has
some Setup and some Task work, then it really should be modeled as two
dependent work efforts.  Each of those work efforts would have
"estimated/actual" "hours" column as per the Data Model Resource Book volume
1.  We could use WorkEffort association to bind them together if you wanted
to navigate a particular task that is related to others (naturally it could
also be modeled as a separate ProductionRun if you were so inclined).

At any rate, by doing this it would be possible to have a setup, task,
teardown and any other arbitrary set of "pieces" of a particular Work
Effort.  Each of these would have their own estimate / actual (rather than
being bound to two specific ones as it is now).  Moreover, the TimeEntry
would be the details that produce the materialized "hours" on the work
effort.

Would should also entertain changing both the "hours" on TimeEntry and the
"estimatedMilliSeconds" / "actualMilliSeconds" to a generic "time" field
with an associated Unit of Measure.  This would allow folks to do these
things at the milli second granularity if they really want, otherwise any
other "time" UOM could be used (I suspect hours would be the norm).
-- 
View this message in context: 
http://n4.nabble.com/Regarding-SVN-commit-r892904-tp2018084p2018084.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Created: (OFBIZ-3727) Create migration service for ProductionRun cloning of work effort cost calc entities

2010-04-20 Thread Bob Morley (JIRA)

Create migration service for ProductionRun cloning of work effort cost calc 
entities


 Key: OFBIZ-3727
 URL: https://issues.apache.org/jira/browse/OFBIZ-3727
 Project: OFBiz
  Issue Type: Bug
  Components: manufacturing
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


OFBIZ-3724 contains a patch that should really have a migration service that 
can properly clone work effort cost calcs.

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

[jira] Commented: (OFBIZ-3724) Copying WorkEffortCostCalc as part of a ProductionRun

2010-04-20 Thread Bob Morley (JIRA)


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

Bob Morley commented on OFBIZ-3724:
---

Will do -- I have created a new ticket that will ultimately have that patch -- 
OFBIZ-3727.

> Copying WorkEffortCostCalc as part of a ProductionRun
> -
>
> Key: OFBIZ-3724
> URL: https://issues.apache.org/jira/browse/OFBIZ-3724
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Assignee: Jacopo Cappellato
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3724_CloneWorkEffortCostCalc.patch
>
>
> Currently when a ProductionRun is created the WorkEffortCostCalc relations 
> are not cloned from the routing tasks.  This results in not being able to 
> change the CostCalc as part of a ProductionRun unless you were to change the 
> routing task template for all production runs.  As part of reviewing this 
> patch I would like two things to be considered --
> I created this patch which includes an enhancement to the production run unit 
> tests to test for the creation of these newly cloned relationships.
> 1) createWorkEffortCostCalc service requires ACCOUNTING_CREATE permission; 
> this does not feel right -- it caused me to add that permission into the 
> sample user/security group to execute the services.  I wonder if these 
> services should be in the WorkEffort component with appropriate work effort 
> permission.
> 2) migration concerns -- if people have existing production runs in place, 
> the new createProductionRunTaskCosts will not pickup the cost calcs that were 
> not copied.  Rather than put "backwards compatible" code in, I would prefer 
> (if we want to handle this) to create a service that performs this clone on 
> non-completed/closed production runs that is executed as part of a migration. 
>  Would like community discussion on this.

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

[jira] Commented: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode

2010-04-20 Thread Bob Morley (JIRA)


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

Bob Morley commented on OFBIZ-3670:
---

I dug in a little bit further based on your direction and now I see what you 
are referring to wrt suspended transactions in a new service.  Thought of a 
potential problem with the current approach and would like to run it by you -- 
it appears that in all the code that does a DelegatorFactory.getDelegator will 
get the original delegator (not the "test" version) and consequently would not 
rollback.  Perhaps I am missing where the test version of the delegator is 
stuffed into the delegator cache in DelegatorFactory ?

Reflecting on what the intent seems to be here, I would recommend that we 
consider a few minor changes.

1. We consider moving the test specific artifacts from GenericDelegator into 
either a TestGenericDelegator proxy or sub-class.  I am kind of a big proponent 
of not having test specific code in production code; this proxy/sub-class could 
live in a org.ofbiz.entity.test package.

2. We consider a new implementation of DelegatorFactoryImpl which constructs 
"test" versions of the GenericDelegators.  The very nice factory pattern would 
provide us with the ability to have this new test factory implementation and 
(hopefully) be able to easily plug it in when we run from the TestRunContainer 
or from a JUnit test case.

By doing number 2 what we would ensure is that all delegators created in a 
container that is for "test" would use test variants, would record their 
operations, and would "play them back" on rollback.  My guess is that we may 
want to play a rollback on all delegators cached from a test run which would 
account for any multi-tenancy tests, etc.

I think we are now on the same page with this work and ensuring that the tests 
run in a consistent way.  If you would like I could take a crack at these 
proposed changes for your review if you have not had time to start on your 
updates to my patch.  Thoughts?

> TestCase base classes providing ability to execute unit tests in Eclipse in 
> "standalone" mode
> -
>
> Key: OFBIZ-3670
> URL: https://issues.apache.org/jira/browse/OFBIZ-3670
> Project: OFBiz
>  Issue Type: Improvement
>      Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Assignee: Scott Gray
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch
>
>
> This patch provides the framework that allows junit unit tests to be executed 
> directly in Eclipse (without having to invoke Start directly).  It total it 
> contains:
> - BaseTestCase - very top of the TestCase stack containing ofbiz specific 
> assertions
> - StandaloneTestCase - determines if application has executed "Start"; if not 
> it will execute a scaled down "Start unittest" that is used in Eclipse
> - RollbackTestCase - extends standalone and provides a transaction w/ 
> auto-rollback
> - TestRunContainer - provides ability to disable dispatcher attributes via 
> configuration (used for unittest-containers.xml)
> - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can 
> be executed from Eclipse or from command-line as it is plugged into standard 
> testdef framework.  Creates its own entities with transaction start/rollback 
> so it can be re-executed.
> Would appreciate if this can be a priority so I can provide additional test 
> cases to boost our code coverage that will utilize these features.

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

[jira] Created: (OFBIZ-3724) Copying WorkEffortCostCalc as part of a ProductionRun

Copying WorkEffortCostCalc as part of a ProductionRun
-

 Key: OFBIZ-3724
 URL: https://issues.apache.org/jira/browse/OFBIZ-3724
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk
 Attachments: OFBIZ-3724_CloneWorkEffortCostCalc.patch

Currently when a ProductionRun is created the WorkEffortCostCalc relations are 
not cloned from the routing tasks.  This results in not being able to change 
the CostCalc as part of a ProductionRun unless you were to change the routing 
task template for all production runs.  As part of reviewing this patch I would 
like two things to be considered --

I created this patch which includes an enhancement to the production run unit 
tests to test for the creation of these newly cloned relationships.

1) createWorkEffortCostCalc service requires ACCOUNTING_CREATE permission; this 
does not feel right -- it caused me to add that permission into the sample 
user/security group to execute the services.  I wonder if these services should 
be in the WorkEffort component with appropriate work effort permission.

2) migration concerns -- if people have existing production runs in place, the 
new createProductionRunTaskCosts will not pickup the cost calcs that were not 
copied.  Rather than put "backwards compatible" code in, I would prefer (if we 
want to handle this) to create a service that performs this clone on 
non-completed/closed production runs that is executed as part of a migration.  
Would like community discussion on this.

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

[jira] Updated: (OFBIZ-3724) Copying WorkEffortCostCalc as part of a ProductionRun


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

Bob Morley updated OFBIZ-3724:
--

Attachment: OFBIZ-3724_CloneWorkEffortCostCalc.patch

> Copying WorkEffortCostCalc as part of a ProductionRun
> -
>
> Key: OFBIZ-3724
> URL: https://issues.apache.org/jira/browse/OFBIZ-3724
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3724_CloneWorkEffortCostCalc.patch
>
>
> Currently when a ProductionRun is created the WorkEffortCostCalc relations 
> are not cloned from the routing tasks.  This results in not being able to 
> change the CostCalc as part of a ProductionRun unless you were to change the 
> routing task template for all production runs.  As part of reviewing this 
> patch I would like two things to be considered --
> I created this patch which includes an enhancement to the production run unit 
> tests to test for the creation of these newly cloned relationships.
> 1) createWorkEffortCostCalc service requires ACCOUNTING_CREATE permission; 
> this does not feel right -- it caused me to add that permission into the 
> sample user/security group to execute the services.  I wonder if these 
> services should be in the WorkEffort component with appropriate work effort 
> permission.
> 2) migration concerns -- if people have existing production runs in place, 
> the new createProductionRunTaskCosts will not pickup the cost calcs that were 
> not copied.  Rather than put "backwards compatible" code in, I would prefer 
> (if we want to handle this) to create a service that performs this clone on 
> non-completed/closed production runs that is executed as part of a migration. 
>  Would like community discussion on this.

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

[jira] Commented: (OFBIZ-3646) Change log level on never-cache related messages from "warn" to "info"


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

Bob Morley commented on OFBIZ-3646:
---

I guess I would think that there is no potential mistake here.  As the 
application developer you likely always want to fetch from cache (if you are 
not updating); if that item will never be from the cache (because it is 
non-cachable) or if the entity just happens not to be in the cache for that 
request, there isn't much difference.  I would not expect the application 
developer to look at each entity and set the "cache query" appropriately, only 
to have the underlying entity change and be forced to find all of those queries 
and change them to be cachable.

> Change log level on never-cache related messages from "warn" to "info"
> --
>
> Key: OFBIZ-3646
> URL: https://issues.apache.org/jira/browse/OFBIZ-3646
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3646_ChangeLogLevelForNeverCacheMessages.patch
>
>
> When you use caching there are a number of warning messages that are produced 
> indicating that various entity instances will not be cached (because the 
> entity is configured not to cache).  Changing these from "warn" to "info" 
> which better reflects what they are and reduces warn threshold log noise.

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

[jira] Commented: (OFBIZ-3663) Re-executing the tests cause unit test failures


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

Bob Morley commented on OFBIZ-3663:
---

I am not convinced this is the problem at all -- the one failure I would point 
to is EntityTestSuite.testMakeValue which creates four "TestingType" entities 
and executes to get exactly 4 back.  The trouble is that the "test data files" 
in service/testdef/data also create "TestingType" entities in the database and 
they do not appear to be doing a rollback.  So a couple of things --

a) Tests only work because (by happenstance) the entity test suite runs before 
the services related tests based on how the testdefs are loaded in.
b) On subsequent run, the entity test suite now gets 13 "TestingTypes" the 9 
provided by the services and its own set of 4

The short-term solution would be to make the entity test more intelligent.  
(aka find how many are there pre-create, do your create, make sure you have 4 
more than what you started with).

A different solution would be to enhance "servicetests" such that the 
"" can 
have an equivalent "finally" step with action "unload" or something similar to 
clean these things up.

But in general, I think it is a better practice to have a self-contained unit 
test that is well behaved typically cleaning up after itself via a rollback.  
This is different from integration or acceptance tests that would potentially 
build on each other.

> Re-executing the tests cause unit test failures
> ---
>
> Key: OFBIZ-3663
> URL: https://issues.apache.org/jira/browse/OFBIZ-3663
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
>
> After a successful unit test run (from completely empty derby database) I 
> attempted a re-execution of the tests after some programming changes.  A 
> number of tests started to fail (I think 4) which I believe were in the 
> Accounting area (but I could be wrong on that).  Test execution ideally 
> should cause no state change to the database, but at a minimum should not 
> fail if executed more than one time.

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

[jira] Commented: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode


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

Bob Morley commented on OFBIZ-3670:
---

Hey Scott,

1) This base test case uses the standard transaction rollback system.

2) The individual writing the unit test can decide what they should extend -- I 
am not suggesting that all unit tests should extend the RollbackTestCase; they 
may extend the StandaloneTestCase (which does not have the rollback nature).  
There were tests in my travels which were explicitly calling a "rollback" at 
the end of their test which this pattern would avoid.  I would also argue that 
it is bad practice for having dependency in your test classes in the first 
place.

3) This is not providing a different approach at all; it merely provides extra 
functionality into the exist test framework.  The tests remain in the testdef 
and are executed through standard means, you simply have the ability to execute 
the test immediately from Eclipse and get all of the tooling associated with 
that.

There is a method of executing the TestRunContainer to pass in arguments on 
which test to run.  It is cumbersome to use in the IDE; but if people choose to 
execute their tests in that way then there is nothing about this patch that 
prevents that.  In fact, I write the unit test and execute it through eclipse 
(individual methods, the whole class) get the tooling in Eclipse (or any other 
IDE) and then I add it to the testdef and execute the entire suite of tests 
form the command-line before creating any patch.

> TestCase base classes providing ability to execute unit tests in Eclipse in 
> "standalone" mode
> -
>
> Key: OFBIZ-3670
> URL: https://issues.apache.org/jira/browse/OFBIZ-3670
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>    Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch
>
>
> This patch provides the framework that allows junit unit tests to be executed 
> directly in Eclipse (without having to invoke Start directly).  It total it 
> contains:
> - BaseTestCase - very top of the TestCase stack containing ofbiz specific 
> assertions
> - StandaloneTestCase - determines if application has executed "Start"; if not 
> it will execute a scaled down "Start unittest" that is used in Eclipse
> - RollbackTestCase - extends standalone and provides a transaction w/ 
> auto-rollback
> - TestRunContainer - provides ability to disable dispatcher attributes via 
> configuration (used for unittest-containers.xml)
> - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can 
> be executed from Eclipse or from command-line as it is plugged into standard 
> testdef framework.  Creates its own entities with transaction start/rollback 
> so it can be re-executed.
> Would appreciate if this can be a priority so I can provide additional test 
> cases to boost our code coverage that will utilize these features.

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

Re: svn commit: r934179 - in /ofbiz/trunk/framework/base: build.xml src/org/ofbiz/base/util/Assert.java src/org/ofbiz/base/util/test/AssertTests.java

2010-04-14 Thread Bob Morley

Adrian Crum wrote:
> 
>> Comments are welcome.
> 
Your first mistake!  heh

It does not appear my trunk checkout has these classes in them ... I am
guessing that the use here is in standard classes (not in junit testers). 
If you have a second to look at my patch associated with OFBIZ-3670; I
provided a BaseTestCase that provides similar assertions that add-on to the
set provided by junit (I am taking assertEmpty type guys that use the
UtilValidate.isEmpty) ... If the intent was to do this from unit testers I
would consider putting them in this base class.

As for comments, I would _consider_ the following minor tweaks ...

a) (if possible) create an org.ofbiz.base.util.Validate that extends the one
from Apache commons with your enhancement
b) would consider overloading "notNull" rather than introducing a new method
c) without seeing the class, my guess is that you have it overloaded to
support n name/value pairs (where n is arbitrarily largish ... like 6)  :)
d) may consider creating a Pair object so we could have a signature
something like ..

Validate.notNull(Pair.create("foo", foo), Pair.create("bar", bar));

public static void notNull(Pair... objects) {
...
}

You can also provide a notNull that just takes an open-ended set of objects
and does what the apache commons implementation does (just on each one).  Ok
those are my ramblings ...
-- 
View this message in context: 
http://n4.nabble.com/Re-svn-commit-r934179-in-ofbiz-trunk-framework-base-build-xml-src-org-ofbiz-base-util-Assert-java-sra-tp1840515p1840770.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

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


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

Bob Morley commented on OFBIZ-3700:
---

Not sure if you mean "Work Effort component" or "Work Effort entity" ?  For the 
latter the answer is no; the former is a pretty loaded question.  :)  To be 
honest, we have just started to really get into the manufacturing / work effort 
areas of the application so my knowledge of that space is pretty skimpy.  BJ 
has been very valuable shedding some light on how stock Ofbiz works.

The only thing that seems odd to me is the handling of tasks in the PR as it 
relates to "WorkEffortPartyAssignment".  I see how these are copied from the 
routing task when they are adding the PR, but it does not appear that you can 
update the party who will be doing that work after the task has been added.  
Moreover, in the Work Effort component these tasks do not appear at all 
(without looking, it appears that the PR header / routing tasks are excluded 
form the WE find).  If you know anything off the top of your head about that it 
would be much appreciated; otherwise I am going to continue my reading.

> Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
> --
>
> Key: OFBIZ-3700
> URL: https://issues.apache.org/jira/browse/OFBIZ-3700
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>    Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
>
> It appears that this entity was missed from the BigDecimal conversion.  Ran 
> into this when ProductionRunServices was attempting to create a WorkEffort 
> (it is passing the quantity to produce as a BigDecimal).  A different bug in 
> OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
> (which was allowing ProductionRuns to be created).  At any rate, we should 
> convert this entity and any other quantity related entities in the WorkEffort 
> component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Bob Morley commented on OFBIZ-3700:
---

Sure, but this is not suggesting that at all.  It is suggesting that when the 
entities were changed to use a BigDecimal instead of a Double for storage (work 
that Scott had completed I believe) and this set of entities appear to be 
missed.  The suggesting is changing the entity model from "floating-point" to 
"fixed-point" in the exact same manner as what was done with the other entities 
that went through this conversion.

The trouble with the service definition approach is that for general CRUD type 
services the definition is usually defined using an "auto-attributes" element.  
So what we run into now is a call to "createProductionRun" requires a quantity 
as a BigDecimal (as per its entity model).  The implementation takes that 
context and uses it to call "createWorkEffort" that requires a quantity as a 
Double ... and *poof*

The solution here was to either say "Double" is right for WorkEffort and the 
service implementation needs to convert from BgiDecimal -> Double before 
calling runSync OR the entity model is incorrect and we should convert it to 
"BigDecimal".  The latter is the one that Scott indicated was probably the 
correct solution.

> Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
> --
>
> Key: OFBIZ-3700
> URL: https://issues.apache.org/jira/browse/OFBIZ-3700
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
>
> It appears that this entity was missed from the BigDecimal conversion.  Ran 
> into this when ProductionRunServices was attempting to create a WorkEffort 
> (it is passing the quantity to produce as a BigDecimal).  A different bug in 
> OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
> (which was allowing ProductionRuns to be created).  At any rate, we should 
> convert this entity and any other quantity related entities in the WorkEffort 
> component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Bob Morley commented on OFBIZ-3700:
---

Right and in the fieldtypepostgres.xml ...




So these "floating-point" types translate to java Doubles when hydrated from 
the database.  If you look at "InventoryItem" for example, its field definition 
is  (for QOH).

> Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
> --
>
> Key: OFBIZ-3700
> URL: https://issues.apache.org/jira/browse/OFBIZ-3700
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>    Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
>
> It appears that this entity was missed from the BigDecimal conversion.  Ran 
> into this when ProductionRunServices was attempting to create a WorkEffort 
> (it is passing the quantity to produce as a BigDecimal).  A different bug in 
> OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
> (which was allowing ProductionRuns to be created).  At any rate, we should 
> convert this entity and any other quantity related entities in the WorkEffort 
> component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Bob Morley commented on OFBIZ-3700:
---

Adrian - this is referring to the quantities on WorkEffort (and any WorkEffort 
related entities) such as the quantityToProduce ... quantities is in the title 
but perhaps it was abstracted by the "and related entities".  :)

> Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
> --
>
> Key: OFBIZ-3700
> URL: https://issues.apache.org/jira/browse/OFBIZ-3700
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
>
> It appears that this entity was missed from the BigDecimal conversion.  Ran 
> into this when ProductionRunServices was attempting to create a WorkEffort 
> (it is passing the quantity to produce as a BigDecimal).  A different bug in 
> OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
> (which was allowing ProductionRuns to be created).  At any rate, we should 
> convert this entity and any other quantity related entities in the WorkEffort 
> component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: "Magically" converted types from simpleTypeConvert

2010-04-14 Thread Bob Morley


I have captures the pertinent bits from this thread and created two new JIRAs
...

OFBIZ-3699 - ServiceDispatcher.checkAuth modifies the context if the
invocation service has a permissionServiceName
OFBIZ-3700 - Convert WorkEffort (and related entities) quantities from
Double -> BigDecimal

Not sure when I will get a chance to work on these tickets, but we can move
the conversation to them if more discussion is warranted.
-- 
View this message in context: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1839821.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

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

Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
--

 Key: OFBIZ-3700
 URL: https://issues.apache.org/jira/browse/OFBIZ-3700
 Project: OFBiz
  Issue Type: Bug
  Components: workeffort
Affects Versions: SVN trunk
Reporter: Bob Morley
Priority: Minor
 Fix For: SVN trunk


It appears that this entity was missed from the BigDecimal conversion.  Ran 
into this when ProductionRunServices was attempting to create a WorkEffort (it 
is passing the quantity to produce as a BigDecimal).  A different bug in 
OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double 
(which was allowing ProductionRuns to be created).  At any rate, we should 
convert this entity and any other quantity related entities in the WorkEffort 
component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3699) ServiceDispatcher.checkAuth modifies the context if the invocation service has a permissionServiceName

ServiceDispatcher.checkAuth modifies the context if the invocation service has 
a permissionServiceName
--

 Key: OFBIZ-3699
 URL: https://issues.apache.org/jira/browse/OFBIZ-3699
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


Created as a result of thread: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-td1838891.html

The follow code in the ServiceDispatcher ...

if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
...
if (hasPermission.booleanValue()) {
context.putAll(permResp);
context = origService.makeValid(context, 
ModelService.IN_PARAM); 

... causes the incoming context to be modified both by adding values from the 
results of the permission service but also by converting any datatypes to match 
those in the service definition.  This hides any invalid service invocations 
(from a data type pov) and if the permisionServiceName is removed, the code 
would start failing with the incorrect data types.

Suggest is to change this to something like ...

Map permRespContext = ServiceUtil.setServiceFields(dctx, 
serviceName, permResp);
context.putAll(permRespContext); 

The concern is that by doing this there may be some services that were relying 
on the data type conversion (because they were invalid requests) which would 
start to fail.  Appropriate impact analysis of services that define 
"permissionServiceName" and appropriate resolutions need to be included with 
this change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: "Magically" converted types from simpleTypeConvert

2010-04-13 Thread Bob Morley

Scott Gray-2 wrote:
> 
> Firstly and without verifying, the automatic conversion sounds wrong and
> yes I'm quite sure it intentional never used to be that way.
> 
> Secondly, I'm not sure why quantityToProduce is a floating point instead
> of a fixed point data type.  I'm surprised and can't imagine why I skipped
> these when I was doing the double -> BigDecimal conversion of everything.
> 

A HA!  Ok I did more digging and it appears that the call to
ModelService.makeValid would always do these type of conversions
"magically".  I suspect the main intent here was to take a context that may
or may not exactly match a service definition (parms & parm types) and
select the desirable parameters into a new context that can be used for
invocation.  There is no difference between the old and new in terms of this
method being called.

However, there appears to be some problem code, here it is from
ServiceDispatcher ...

if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
...
if (hasPermission.booleanValue()) {
context.putAll(permResp);
context = origService.makeValid(context,
ModelService.IN_PARAM);

Effectively what happens is if a ModelService has a permissionServiceName,
it will invoke that permission and if it is successful it adds the
permission response to the context and converts it to match the service that
will be invoked.  I suspect this gives us the ability to have the service
permission provide arguments to the underlying service.

Someone on our team overrode the "createWorkEffort" and removed the
permissionServiceName.  So this code would not execute, we had the context
with the Double in it, and service dispatcher produced the standard
violation.

My suggestion is we change this code to make use of
ServiceUtil.setServiceFields, something like this ...

Map permRespContext = ServiceUtil.setServiceFields(dctx,
serviceName, permResp);
context.putAll(permRespContext);

Effectively, we would take the permission response and grab the things from
it that match our service signature and then add those to the context (and
ultimately return it).  This would ensure that only replaces are added
without impacting anything else.  The second part to this would be either
changing WorkEffort to use BigDecimal OR change the service implementation
to pass in a Double when invoking those services.

Make sense?
-- 
View this message in context: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1839077.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Updated: (OFBIZ-3586) application - manufacturing


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

Bob Morley updated OFBIZ-3586:
--

Attachment: (was: OFBIZ-3586_ResolveWarningsManufacturing.patch)

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3586) application - manufacturing


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

Bob Morley updated OFBIZ-3586:
--

Attachment: OFBIZ-3586_ResolveWarningsManufacturing.patch

Corrected patch.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (OFBIZ-3586) application - manufacturing


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

Bob Morley commented on OFBIZ-3586:
---

Please hold off on this one -- I attached the patch as I was building / testing 
via ant and there were a few compilation issues related to generic checking 
(differences between Eclipse building and ant building).  Will resolve and 
provide a replacement attachment.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

"Magically" converted types from simpleTypeConvert

2010-04-13 Thread Bob Morley


We have just started to make use of ProductionRun in our project and we were
having a problem in the create because the ProductionRunServices (around
line 274) makes a call to "createWorkEffort" using a "quantityToProduce"
that is a BigDecimal.  The field on the WorkEffort entity is actually a
Double, so in our solution it was causing a "bad type error" and failing.

I jumped to trunk to try to figure out why it was working in stock Ofbiz. 
After some digging, it turns out that the conversion enhancements now
(appear to) silently do this conversion, resulting in a context that
contains that field as a Double.

This happens because the ServiceDispatcher's runSync method calls
"checkAuth" which (if the user can call the service) calls
ModelService.makeValid which ultimately calls ObjectType.simpleTypeConvert
that handles the BigDecimal -> Double conversion.

Is this the intended behavior?  To be honest, it seems to me that the
complaint that the parameter was not the proper data type was more
desirable.  I understand that when we are handling a postback, values need
to be converted from String to their desired types; but if I am making a
call in our back-end to another service I would think I should be forced to
adhere to that service definition's signature.
-- 
View this message in context: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1838891.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Updated: (OFBIZ-3586) application - manufacturing


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

Bob Morley updated OFBIZ-3586:
--

Attachment: OFBIZ-3586_ResolveWarningsManufacturing.patch

Rather large set of changes here; typically very minor things -- but there was 
some changes with the BOMTree which was taking a generic ArrayList and now 
takes a List.  There were also a number of services that were not 
explicitly returning a success/error return code; so these were fixed as well.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3590) application - product


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

Bob Morley updated OFBIZ-3590:
--

Attachment: OFBIZ-3590_ResolveWarningsProduct.patch

Medium set of changes; most very trivial (adding suppress serial, filling in 
Collection generics signature, removing or commenting out unused variables, etc.

> application - product
> -
>
> Key: OFBIZ-3590
> URL: https://issues.apache.org/jira/browse/OFBIZ-3590
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3590_ResolveWarningsProduct.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3589) application - party


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

Bob Morley updated OFBIZ-3589:
--

Attachment: OFBIZ-3589_ResolveWarningsParty.patch

Party was very clean; only a few minor changes - also added a 
@SupressWarnings("serial") in framework's MimeMessageWrapper (noticed when 
fixing iteration from this in Party).

> application - party
> ---
>
> Key: OFBIZ-3589
> URL: https://issues.apache.org/jira/browse/OFBIZ-3589
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3589_ResolveWarningsParty.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3587) application - marketing


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

Bob Morley updated OFBIZ-3587:
--

Attachment: OFBIZ-3587_ResolveWarningsMarketing.patch

Very minor change to VCard.java - now using unknown generic in iterator 
(Iterator).

> application - marketing
> ---
>
> Key: OFBIZ-3587
> URL: https://issues.apache.org/jira/browse/OFBIZ-3587
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3587_ResolveWarningsMarketing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3591) application - securityext


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

Bob Morley updated OFBIZ-3591:
--

Attachment: OFBIZ-3591_ResolveWarningsSecurityExt.patch

One little unused import was removed.

> application - securityext
> -
>
> Key: OFBIZ-3591
> URL: https://issues.apache.org/jira/browse/OFBIZ-3591
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
> Attachments: OFBIZ-3591_ResolveWarningsSecurityExt.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3691) Create PeriodWorker unit tester


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

Bob Morley updated OFBIZ-3691:
--

Attachment: OFBIZ-3691_PeriodWorkerTestCase.patch

NOTE: This patch relies on OFBIZ-3670 as it extends the "RollbackTestCase" 
introduced in that patch.

> Create PeriodWorker unit tester
> ---
>
> Key: OFBIZ-3691
> URL: https://issues.apache.org/jira/browse/OFBIZ-3691
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3691_PeriodWorkerTestCase.patch
>
>
> Add unit tests for the functionality in the PeriodWorker.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3691) Create PeriodWorker unit tester

Create PeriodWorker unit tester
---

 Key: OFBIZ-3691
 URL: https://issues.apache.org/jira/browse/OFBIZ-3691
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


Add unit tests for the functionality in the PeriodWorker.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (OFBIZ-3316) Edit/Navigate Global GL Account - Found URL parameter [glAccountId] passed to secure (https) request-map with uri [updateGlAccount]

2010-04-11 Thread Bob Morley (JIRA)


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

Bob Morley commented on OFBIZ-3316:
---

Attempted to reproduce this in trunk; but it appears the only link to 
updateGlAccount is in GlobalGlAccountsForms.xml -> EditGlAccount which worked 
correctly.  Checked the 9.04 branch and it appears to be correct as well.

> Edit/Navigate Global GL Account - Found URL parameter [glAccountId] passed to 
> secure (https) request-map with uri [updateGlAccount]
> ---
>
> Key: OFBIZ-3316
> URL: https://issues.apache.org/jira/browse/OFBIZ-3316
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: chris snow
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-2894) Creating New Employment Application (non secure)

2010-04-11 Thread Bob Morley (JIRA)


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

Bob Morley updated OFBIZ-2894:
--

Attachment: OFBIZ-2894_NewEmploymentApplicationNonSecure.patch

Removed the query string parms from the form action.  The applicationId was 
already in the form but the partyId had to be added.

> Creating New Employment Application (non secure)
> 
>
> Key: OFBIZ-2894
> URL: https://issues.apache.org/jira/browse/OFBIZ-2894
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: humanres
>Affects Versions: Release Branch 9.04, SVN trunk
> Environment: N/A
>Reporter: Jacques Le Roux
> Attachments: OFBIZ-2894_NewEmploymentApplicationNonSecure.patch
>
>
> https://localhost:8443/humanres/control/NewEmploymentApp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Derby not honoring order by clause (insight requested)

2010-04-11 Thread Bob Morley



BJ Freeman wrote:
> 
> if I read this correct
> summary:
> using the entity engine you get the correct results
> using SQL you don't.
> since the entity engine returns the correct results what is it sending
> to the dB and how is it sorting.
> If you are sending sql(sql pass through) then you by-passing ofbiz and
> just the JBDC and databse are concerned.
> 
> =
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation
> 
> Specialtymarket.com 
> 
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> Linkedin
> 
> 

Hi BJ -- I think you misunderstood.  I am using the entity model via the
findByAnd method on the standard delegator implementation.  When debugging I
stepped down to the generation for the sql statement and just posted the raw
sql that Ofbiz was generating.

BTW - I had edited my original post to fix a mis-spelling in the title, so I
just quoted your post back to this thread.
-- 
View this message in context: 
http://n4.nabble.com/Derby-not-honoring-order-by-clause-insight-requested-tp1835819p1836051.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Derby not honoring order by clause (inslight requested)

2010-04-10 Thread Bob Morley


I was working on a unit tester as part of OFBIZ-3670.  This unit tester makes
use of a RollbackTestCase that starts a transaction in setup and then rolls
it back in teardown.  At any rate, I was a testing a method that will do a
select against an entity and includes an order by clause "from_date DESC". 
The entities are created inside this same transaction as where I fetch them,
but regardless if I changed it to "from_date ASC" derby was always returning
back the records in the same order.

Here is a snippet if you do not want to apply the patch --

Timestamp date01 = UtilDateTime. nowTimestamp();
Timestamp date02 = UtilDateTime.addDaysToTimestamp(date01, 5);
getDelegator().create("Agreement", UtilMisc.toMap("agreementId",
"TEST_AGMT_01", "agreementTypeId", "EULA", "description", "test01",
"fromDate", date01));
getDelegator().create("Agreement", UtilMisc.toMap("agreementId",
"TEST_AGMT_02", "agreementTypeId", "EULA",  "description", "test02",
"fromDate", date02));
...
gptList = delegator.findByAnd(entityName, UtilMisc.toMap(mainId,
mainValueId), UtilMisc.toList("-fromDate"));

Am I missing something obvious here?  I can't imagine this is a derby bug;
but the dates look good on debugging (5 days apart) and the findByAnd
definition returns back a list of two entities (with their fromDate fields
properly set).  If I change the "-fromDate" to just "fromDate" it makes no
difference on the result.

When debugging I worked down to the generated SQL (it was not getting the
values from cache) ...

SELECT AGREEMENT_ID, PRODUCT_ID, PARTY_ID_FROM, PARTY_ID_TO,
ROLE_TYPE_ID_FROM, ROLE_TYPE_ID_TO, AGREEMENT_TYPE_ID, AGREEMENT_DATE,
FROM_DATE, THRU_DATE, DESCRIPTION, TEXT_DATA, LAST_UPDATED_STAMP,
LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP FROM OFBIZ.AGREEMENT
WHERE (AGREEMENT_TYPE_ID = ?) ORDER BY FROM_DATE DESC

For now I commented out my assertion that I am getting back the exepected
GenericValue so that the unit test passes; but in reality it is not
returning the "latest" as it is designed to do.
-- 
View this message in context: 
http://n4.nabble.com/Derby-not-honoring-order-by-clause-inslight-requested-tp1835819p1835819.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Created: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode

TestCase base classes providing ability to execute unit tests in Eclipse in 
"standalone" mode
-

 Key: OFBIZ-3670
 URL: https://issues.apache.org/jira/browse/OFBIZ-3670
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk
 Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch

This patch provides the framework that allows junit unit tests to be executed 
directly in Eclipse (without having to invoke Start directly).  It total it 
contains:

- BaseTestCase - very top of the TestCase stack containing ofbiz specific 
assertions
- StandaloneTestCase - determines if application has executed "Start"; if not 
it will execute a scaled down "Start unittest" that is used in Eclipse
- RollbackTestCase - extends standalone and provides a transaction w/ 
auto-rollback
- TestRunContainer - provides ability to disable dispatcher attributes via 
configuration (used for unittest-containers.xml)

- GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can be 
executed from Eclipse or from command-line as it is plugged into standard 
testdef framework.  Creates its own entities with transaction start/rollback so 
it can be re-executed.

Would appreciate if this can be a priority so I can provide additional test 
cases to boost our code coverage that will utilize these features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode


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

Bob Morley updated OFBIZ-3670:
--

Attachment: OFBIZ-3670_StandaloneTestEnhancement.patch

> TestCase base classes providing ability to execute unit tests in Eclipse in 
> "standalone" mode
> -
>
> Key: OFBIZ-3670
> URL: https://issues.apache.org/jira/browse/OFBIZ-3670
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch
>
>
> This patch provides the framework that allows junit unit tests to be executed 
> directly in Eclipse (without having to invoke Start directly).  It total it 
> contains:
> - BaseTestCase - very top of the TestCase stack containing ofbiz specific 
> assertions
> - StandaloneTestCase - determines if application has executed "Start"; if not 
> it will execute a scaled down "Start unittest" that is used in Eclipse
> - RollbackTestCase - extends standalone and provides a transaction w/ 
> auto-rollback
> - TestRunContainer - provides ability to disable dispatcher attributes via 
> configuration (used for unittest-containers.xml)
> - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can 
> be executed from Eclipse or from command-line as it is plugged into standard 
> testdef framework.  Creates its own entities with transaction start/rollback 
> so it can be re-executed.
> Would appreciate if this can be a priority so I can provide additional test 
> cases to boost our code coverage that will utilize these features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3669) Data seeding to support ability to return products of type RAW_MATERIAL


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

Bob Morley updated OFBIZ-3669:
--

Attachment: OFBIZ-3669_DataSeedToReturnRawMaterials.patch

> Data seeding to support ability to return products of type RAW_MATERIAL
> ---
>
> Key: OFBIZ-3669
> URL: https://issues.apache.org/jira/browse/OFBIZ-3669
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting, order
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3669_DataSeedToReturnRawMaterials.patch
>
>
> This patch contains data seeding that supports the ability to have return 
> items that contain products of type RAW_MATERIAL.  This allows an enterprise 
> to return raw materials back to suppliers as well as customers returning them 
> (if the enterprise sells raw materials to customers).  There is no code in 
> this patch, just the data model wiring to map the raw material product types 
> to the proper return types / accounting types.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3669) Data seeding to support ability to return products of type RAW_MATERIAL

Data seeding to support ability to return products of type RAW_MATERIAL
---

 Key: OFBIZ-3669
 URL: https://issues.apache.org/jira/browse/OFBIZ-3669
 Project: OFBiz
  Issue Type: Bug
  Components: accounting, order
Affects Versions: SVN trunk
Reporter: Bob Morley
Priority: Minor
 Fix For: SVN trunk
 Attachments: OFBIZ-3669_DataSeedToReturnRawMaterials.patch

This patch contains data seeding that supports the ability to have return items 
that contain products of type RAW_MATERIAL.  This allows an enterprise to 
return raw materials back to suppliers as well as customers returning them (if 
the enterprise sells raw materials to customers).  There is no code in this 
patch, just the data model wiring to map the raw material product types to the 
proper return types / accounting types.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3599) specialpurpose - oagis


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

Bob Morley updated OFBIZ-3599:
--

Attachment: OFBIZ-3599_FixBadSerialNumberRetrieval.patch

This fixes the problem Jacques has found in his review -- I had missed the loop 
and thought that it was only using the first serial number; as a result I was 
getting the 0th index in the list.  The code originally had an iterator that I 
got away from using.  The for loop that this is used in is doing it from the 
Oagis feed which reports the quantity and determines the maximum number based 
on what was provided, so we should not get an index violation here as this 
quantity is based on the maximum number of serial numbers that would be in the 
list (that is consistent with what the original code was doing).

As for the cast -- in general I was creating the inputs to adhere to the 
parameter for the delegator.findByPrimaryKey -- in this case it expects a 
Map.  In my mind I would have had to check each parameter to 
ensure it was a String; in reality the compiler would have handled that.  At 
any rate, I generally code it as Map for consistency and 
casting the first String to a Object tricks the compiler into having the 
UtilValidate method return a Map.  In fact, this is our typical 
internal compile error -- in Eclipse it will allow Map x = 
UtilValidate.toMap("a", "b"); but when compiling from the command-line it will 
fail.

At any rate, if we can just correct the one mistake I am think we are good.  :)

> specialpurpose - oagis
> --
>
> Key: OFBIZ-3599
> URL: https://issues.apache.org/jira/browse/OFBIZ-3599
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
>Assignee: Jacques Le Roux
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3599_FixBadSerialNumberRetrieval.patch, 
> OFBIZ-3599_ResolveJavaWarningsOagis.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (OFBIZ-3599) specialpurpose - oagis


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

Bob Morley reopened OFBIZ-3599:
---


> specialpurpose - oagis
> --
>
> Key: OFBIZ-3599
> URL: https://issues.apache.org/jira/browse/OFBIZ-3599
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Bob Morley
>Assignee: Jacques Le Roux
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3599_ResolveJavaWarningsOagis.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision

2010-04-09 Thread Bob Morley (JIRA)


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

Bob Morley commented on OFBIZ-3666:
---

I agree specifying any precision seemed incorrect; but the reality is these 
services were specifying a precision of 2 and I simply wanted to correct this 
with the maximum precision of the data type so that rounding would not occur.  
So in this case I am just making it work without a "higher risk" change that 
may break the implementation.

As for the set field; we are a little out of step but has the type conversion 
changed?  I would have thought that value would be picked up by the 
FlexibleStringExpander so you would get a properly typed result which would 
then be converted to a String and assigned to the field.  We ran into problems 
with this when we corrected localization which would cause the value to be 
formatted with a comma which would later cause problems parsing back to the 
numeric field.  Keep in mind we are working with a trunk that we last merged 
about six months ago, so I understand some of this may have changed.

> Errors attempting to use quantities with more than 2 decimals of precision
> --
>
> Key: OFBIZ-3666
> URL: https://issues.apache.org/jira/browse/OFBIZ-3666
> Project: OFBiz
>  Issue Type: Bug
>  Components: order, product
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch
>
>
> We have a need to handle inventory items with quantities up to four decimal 
> places.  The data model currently supports 6 decimals so I thought I would 
> try to complete a purchase order, sales order, and a return for an item that 
> has this many digits of precision.  What I found was ...
> - The order item was calculated properly (including the total for the line) 
> but the totals for the entire sales order were incorrect.  This was because 
> when OrderReadHelper was getting the OrderItemQuantity as part of calculating 
> the subtotal it would round it to the order's configured scale (2).  Since 
> this is being used as a calculation it should not be rounded -- the total 
> itself should be rounded.
> - In a number of spots in issuance and reservation services values were 
> (sometimes) being rounded.  For example, when an order item was created it 
> would create an InventoryItemDetail record that would reduce the ATP by the 
> precise quantity, however when the order was placed the QOH was reduced by 
> the rounded value.  All of these issues were the result of the mini-lang 
> calculate element being used which by default uses a scale of 2 decimals 
> (from the dtd).  The solution was when working with quantities pass in the 
> precision scale (6) to ensure we do not lose precision.  Again, when order 
> totals, taxes, things like that are being done the configured scale should 
> take over, but the intermediate calculations should not be losing precision.

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

[jira] Updated: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision

2010-04-09 Thread Bob Morley (JIRA)


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

Bob Morley updated OFBIZ-3666:
--

Attachment: OFBIZ-3666_DoNotRoundPreciseQuantity.patch

> Errors attempting to use quantities with more than 2 decimals of precision
> --
>
> Key: OFBIZ-3666
> URL: https://issues.apache.org/jira/browse/OFBIZ-3666
> Project: OFBiz
>  Issue Type: Bug
>  Components: order, product
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch
>
>
> We have a need to handle inventory items with quantities up to four decimal 
> places.  The data model currently supports 6 decimals so I thought I would 
> try to complete a purchase order, sales order, and a return for an item that 
> has this many digits of precision.  What I found was ...
> - The order item was calculated properly (including the total for the line) 
> but the totals for the entire sales order were incorrect.  This was because 
> when OrderReadHelper was getting the OrderItemQuantity as part of calculating 
> the subtotal it would round it to the order's configured scale (2).  Since 
> this is being used as a calculation it should not be rounded -- the total 
> itself should be rounded.
> - In a number of spots in issuance and reservation services values were 
> (sometimes) being rounded.  For example, when an order item was created it 
> would create an InventoryItemDetail record that would reduce the ATP by the 
> precise quantity, however when the order was placed the QOH was reduced by 
> the rounded value.  All of these issues were the result of the mini-lang 
> calculate element being used which by default uses a scale of 2 decimals 
> (from the dtd).  The solution was when working with quantities pass in the 
> precision scale (6) to ensure we do not lose precision.  Again, when order 
> totals, taxes, things like that are being done the configured scale should 
> take over, but the intermediate calculations should not be losing precision.

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

[jira] Created: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision

2010-04-09 Thread Bob Morley (JIRA)

Errors attempting to use quantities with more than 2 decimals of precision
--

 Key: OFBIZ-3666
 URL: https://issues.apache.org/jira/browse/OFBIZ-3666
 Project: OFBiz
  Issue Type: Bug
  Components: order, product
Affects Versions: SVN trunk
Reporter: Bob Morley
Priority: Minor
 Fix For: SVN trunk


We have a need to handle inventory items with quantities up to four decimal 
places.  The data model currently supports 6 decimals so I thought I would try 
to complete a purchase order, sales order, and a return for an item that has 
this many digits of precision.  What I found was ...

- The order item was calculated properly (including the total for the line) but 
the totals for the entire sales order were incorrect.  This was because when 
OrderReadHelper was getting the OrderItemQuantity as part of calculating the 
subtotal it would round it to the order's configured scale (2).  Since this is 
being used as a calculation it should not be rounded -- the total itself should 
be rounded.
- In a number of spots in issuance and reservation services values were 
(sometimes) being rounded.  For example, when an order item was created it 
would create an InventoryItemDetail record that would reduce the ATP by the 
precise quantity, however when the order was placed the QOH was reduced by the 
rounded value.  All of these issues were the result of the mini-lang calculate 
element being used which by default uses a scale of 2 decimals (from the dtd).  
The solution was when working with quantities pass in the precision scale (6) 
to ensure we do not lose precision.  Again, when order totals, taxes, things 
like that are being done the configured scale should take over, but the 
intermediate calculations should not be losing precision.

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

[jira] Created: (OFBIZ-3663) Re-executing the tests cause unit test failures

Re-executing the tests cause unit test failures
---

 Key: OFBIZ-3663
 URL: https://issues.apache.org/jira/browse/OFBIZ-3663
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


After a successful unit test run (from completely empty derby database) I 
attempted a re-execution of the tests after some programming changes.  A number 
of tests started to fail (I think 4) which I believe were in the Accounting 
area (but I could be wrong on that).  Test execution ideally should cause no 
state change to the database, but at a minimum should not fail if executed more 
than one time.

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

[jira] Updated: (OFBIZ-3662) Resolve base unit tests not executing and not contributing to code coverage


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

Bob Morley updated OFBIZ-3662:
--

Attachment: OFBIZ-3662_ResolveBaseUnitTestsAndCoverage.patch

> Resolve base unit tests not executing and not contributing to code coverage
> ---
>
> Key: OFBIZ-3662
> URL: https://issues.apache.org/jira/browse/OFBIZ-3662
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3662_ResolveBaseUnitTestsAndCoverage.patch
>
>
> When you run the suite of tests from the ofbiz home folder, the base unit 
> tests do not execute and there is some confusion as to if their code coverage 
> metrics are being properly reflected.
> My investigation has determined that there does not appear to be an issue 
> with the two classpaths and them "stomping on the code coverage metrics".
> What I found was that because the TestContainer expects all components to be 
> loaded creating a ContainerConfig for each, "base" was not being executed (as 
> it was only manually referenced via Start).  The manual reference in Start 
> would set the classpath entries, but would not allow the base component to 
> have any other goodies like entitydef, servicedef, or testdef artifacts.
> Once you have this component loading like the rest, the second problem was 
> that the basetests.xml file (its testdef) had further problems in it.  Two of 
> the junit-test-suites had trailing ".java" in the classname, one had a typo, 
> and the JSONTests was not referenced.
> My simple solution (requires review) is to add the "base" component into 
> component-load.xml which solves issue #1 and fix-up the problems for #2.
> I spent quite a bit of time on this; initially I thought I could get away 
> with not instrumenting in Start at all -- this was because the component 
> loader (once it loads base) has all the jars required and can instrument 
> them.  The trouble is that the Start's classpath that is generated includes 
> three jars (including ofbiz-base) at the top of the classpath.  The 
> instrumenting logic actually does clean replacements of the jars it 
> instruments at the place they are in the classpath (obviously this is smart). 
>  Trouble is you end up with a non-instrumented ofbiz-base at the top which 
> kills your metrics.
> After these changes the unit tests jumped from 216 -> 285 and the overall 
> project coveage is sitting at around 18%.  Base specifically has quite good 
> coverage, but the application/specialpurpose are really lacking.

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

[jira] Created: (OFBIZ-3662) Resolve base unit tests not executing and not contributing to code coverage

Resolve base unit tests not executing and not contributing to code coverage
---

 Key: OFBIZ-3662
 URL: https://issues.apache.org/jira/browse/OFBIZ-3662
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


When you run the suite of tests from the ofbiz home folder, the base unit tests 
do not execute and there is some confusion as to if their code coverage metrics 
are being properly reflected.

My investigation has determined that there does not appear to be an issue with 
the two classpaths and them "stomping on the code coverage metrics".

What I found was that because the TestContainer expects all components to be 
loaded creating a ContainerConfig for each, "base" was not being executed (as 
it was only manually referenced via Start).  The manual reference in Start 
would set the classpath entries, but would not allow the base component to have 
any other goodies like entitydef, servicedef, or testdef artifacts.

Once you have this component loading like the rest, the second problem was that 
the basetests.xml file (its testdef) had further problems in it.  Two of the 
junit-test-suites had trailing ".java" in the classname, one had a typo, and 
the JSONTests was not referenced.

My simple solution (requires review) is to add the "base" component into 
component-load.xml which solves issue #1 and fix-up the problems for #2.

I spent quite a bit of time on this; initially I thought I could get away with 
not instrumenting in Start at all -- this was because the component loader 
(once it loads base) has all the jars required and can instrument them.  The 
trouble is that the Start's classpath that is generated includes three jars 
(including ofbiz-base) at the top of the classpath.  The instrumenting logic 
actually does clean replacements of the jars it instruments at the place they 
are in the classpath (obviously this is smart).  Trouble is you end up with a 
non-instrumented ofbiz-base at the top which kills your metrics.

After these changes the unit tests jumped from 216 -> 285 and the overall 
project coveage is sitting at around 18%.  Base specifically has quite good 
coverage, but the application/specialpurpose are really lacking.

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

Re: InventoryItem QOH/ATP missing Unit of Measure

2010-04-08 Thread Bob Morley



David E Jones-4 wrote:
> 
> The inventory units come from the product, specifically the  
> quantityIncluded and quantityUomId fields.
> 

Thanks David -- this was foolish on my part (twice); it should have occurred
to me modeling the Uom on the inventory would give you lots of inconsistent
Uom problems and second I should have done a quick search on the forum. 
Bah!

My speculative guess would be when doing POs in Ofbiz you are currently
forced to adhere to the Uom set on the product.  Thinking that without a Uom
on the OrderItem it would have to either force you into that Uom or the
ShoppingCart would have to invoke a conversion as part of makeOrderItems. 
No response necessary, I can look into this when I get some time.
-- 
View this message in context: 
http://n4.nabble.com/InventoryItem-QOH-ATP-missing-Unit-of-Measure-tp1777324p1809785.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Updated: (OFBIZ-3661) Fix basetests.xml - should be a test-group not a test-case


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

Bob Morley updated OFBIZ-3661:
--

Attachment: OFBIZ-3661_ChangeBasetestToTestGroup.patch

> Fix basetests.xml - should be a test-group not a test-case
> --
>
> Key: OFBIZ-3661
> URL: https://issues.apache.org/jira/browse/OFBIZ-3661
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: SVN trunk
>    Reporter: Bob Morley
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3661_ChangeBasetestToTestGroup.patch
>
>
> Very minor change here, the "basetests" test-case should actually be a 
> test-group because it houses more than one junit-test-suite.  As it  is, only 
> the first junit-test-suite would be loaded by the ModelTestSuite in its 
> constructor.  I marked this Major because it is preventing unit tests from 
> running as part of the build.

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

[jira] Created: (OFBIZ-3661) Fix basetests.xml - should be a test-group not a test-case

Fix basetests.xml - should be a test-group not a test-case
--

 Key: OFBIZ-3661
 URL: https://issues.apache.org/jira/browse/OFBIZ-3661
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Fix For: SVN trunk


Very minor change here, the "basetests" test-case should actually be a 
test-group because it houses more than one junit-test-suite.  As it  is, only 
the first junit-test-suite would be loaded by the ModelTestSuite in its 
constructor.  I marked this Major because it is preventing unit tests from 
running as part of the build.

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

Re: InventoryItem QOH/ATP missing Unit of Measure

2010-04-08 Thread Bob Morley



Scott Gray-2 wrote:
> 
> The first thing I would suggest doing is searching for previous
> discussions in the mailing list archives, I can't help but feel that the
> uom topic has been discussed at least a million times (maybe more).
> 

Duh I violated the first principle!  I will refer myself to
http://n4.nabble.com/New-field-to-specify-the-internal-uom-of-products-td171281.html#a171281.

Thanks ;)
-- 
View this message in context: 
http://n4.nabble.com/InventoryItem-QOH-ATP-missing-Unit-of-Measure-tp1777324p1781270.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

InventoryItem QOH/ATP missing Unit of Measure

2010-04-08 Thread Bob Morley


Does anyone know of a good reason why the InventoryItem (and many other
entities) that deal with quantities does not have a Uom?  I referenced the
Data Model Resource Book volume 1 and even though it says that an Inventory
Item could represent 100 reams of ... it only stores the 100 as the quantity
not the reams.

This is important for us because we will model a raw material of "gold"
which can be purchased/sold in ounces or pennyweight (I think that is what
she said).  While a particular enterprise may select a standard unit of
measure, they could certainly create POs from suppliers that use a different
Uom.  One would think that Ofbiz would handle this and use the UomConversion
entity to do the conversion when it creates the InventoryItemDetail records.

Anyone have any opinions?  This would be quite a large change so I don't
want to bite this off at this moment, but I could capture any resolution
into a JIRA for future considerations.
-- 
View this message in context: 
http://n4.nabble.com/InventoryItem-QOH-ATP-missing-Unit-of-Measure-tp1777324p1777324.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [VOTE] [RELEASE] Apache OFBiz 09.04

2010-04-08 Thread Bob Morley



Jacopo Cappellato-4 wrote:
> 
> This is the vote thread to transform our release candidate 09.04 into an
> official release. 
> 
> [ +1] release as Apache OFBiz 09.04
> [ -1] do not release
> 

+1
-- 
View this message in context: 
http://n4.nabble.com/VOTE-RELEASE-Apache-OFBiz-09-04-tp1773832p1774235.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with


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

Bob Morley commented on OFBIZ-3659:
---

Adrian -- That is precisely what I did and I don't really see what you are 
getting at.  I just went and grabbed the fantastic mr. convert as well ... It 
is not distinctively different from what we are doing, if you ignore the fact 
that we can not use ant junit targets because we have to invoke our tests 
through start.  They have a nicely isolated dependency grab; but the compile 
depends on it ... the only piece I see is it can be shutoff based on a a 
sysclasspath.  What am I missing?

> Download cobertura code coverage jar so it can be used to compile and execute 
> tests with
> 
>
> Key: OFBIZ-3659
> URL: https://issues.apache.org/jira/browse/OFBIZ-3659
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch
>
>
> Framework executed around allowing use of cobertura to create code coverage 
> metrics as part of the Ofbiz build process.  Licensing restricts distribution 
> of cobertura with Ofbiz, so we have taken the approach to attempt to download 
> it before doing our build so it is available for any container that wants 
> instrumentation turned on (currently only test-container).  Net result is 
> when we run our tests we will now get very nice code coverage metrics being 
> generated.
> There is an existing target to generate the cobertura report (html) which is 
> not automatically being executed.  Once we get more reasonable code coverage 
> via unit testing we can automatically generate this and expose it as 
> appropriate.

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

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

2010-04-07 Thread Bob Morley


It appears that our current unit test run excludes all of the "base" unit
testers.  Two reasons I have found ...

1) basetests.xml was coded as a test-case but attempted to have multiple
junit-test-suite elements in it (it is only allow to have one).  Changing
this to a test-group would ensure that they are loaded.

2) ComponentConfig.getAllComponents was not including the "base" component. 
Tracked this down to framework/component-load.xml not including it.  My
guess is that there is probably a reason for this; but I don't know what it
could be.

This may also be the reason why the code coverage metrics are inaccurate
when you run from the top.  I have executed on my dev machine w/o code
coverage, and the tests all passed increasing the # from 216 to 269.

If there is no known reason, I would like to submit these two changes as a
patch.
-- 
View this message in context: 
http://n4.nabble.com/Why-does-framework-component-load-xml-does-not-include-base-tp1759711p1759711.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with


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

Bob Morley commented on OFBIZ-3659:
---

Scott -- I have just left the two targets here that can be invoked manually.  
After verifying and doing a check-in, can you modify the Buildbot to do an ant 
download-cobertura after the svn checkout (but before the run-install).

Adrian -- I hunted around Apache Commons; but not being very familiar I was not 
sure what I was looking for.  I looked at IO because it had an old Cobertura 
report generated from 2008; but it appears they no longer generate code 
coverage that way.  Commons Lang has code coverage but they use Bamboo/Clover.  
The one build file that had download-dependency target (it was for junit) was 
very nice, but all it really did was have their "run-tests" have dependency on 
it ...

Whatever we do, if we are going to move the deployment of the jar so it is not 
a pre-req for our build, we will have to refactor so we can build our Cobertura 
integration pieces after the fact.  This could manifest in a 
"run-coverage-tests" target, or something else -- but some work would have to 
be done.

> Download cobertura code coverage jar so it can be used to compile and execute 
> tests with
> 
>
> Key: OFBIZ-3659
> URL: https://issues.apache.org/jira/browse/OFBIZ-3659
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>    Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch
>
>
> Framework executed around allowing use of cobertura to create code coverage 
> metrics as part of the Ofbiz build process.  Licensing restricts distribution 
> of cobertura with Ofbiz, so we have taken the approach to attempt to download 
> it before doing our build so it is available for any container that wants 
> instrumentation turned on (currently only test-container).  Net result is 
> when we run our tests we will now get very nice code coverage metrics being 
> generated.
> There is an existing target to generate the cobertura report (html) which is 
> not automatically being executed.  Once we get more reasonable code coverage 
> via unit testing we can automatically generate this and expose it as 
> appropriate.

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

[jira] Updated: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with


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

Bob Morley updated OFBIZ-3659:
--

Attachment: OFBIZ-3659_AutomateDownloadOfCobertura.patch

Ok this is the real proper patch now (the last one I manually modified and 
messed it up).

> Download cobertura code coverage jar so it can be used to compile and execute 
> tests with
> 
>
> Key: OFBIZ-3659
> URL: https://issues.apache.org/jira/browse/OFBIZ-3659
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch
>
>
> Framework executed around allowing use of cobertura to create code coverage 
> metrics as part of the Ofbiz build process.  Licensing restricts distribution 
> of cobertura with Ofbiz, so we have taken the approach to attempt to download 
> it before doing our build so it is available for any container that wants 
> instrumentation turned on (currently only test-container).  Net result is 
> when we run our tests we will now get very nice code coverage metrics being 
> generated.
> There is an existing target to generate the cobertura report (html) which is 
> not automatically being executed.  Once we get more reasonable code coverage 
> via unit testing we can automatically generate this and expose it as 
> appropriate.

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

[jira] Updated: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with


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

Bob Morley updated OFBIZ-3659:
--

Attachment: (was: OFBIZ-3659_AutomateDownloadOfCobertura.patch)

> Download cobertura code coverage jar so it can be used to compile and execute 
> tests with
> 
>
> Key: OFBIZ-3659
> URL: https://issues.apache.org/jira/browse/OFBIZ-3659
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch
>
>
> Framework executed around allowing use of cobertura to create code coverage 
> metrics as part of the Ofbiz build process.  Licensing restricts distribution 
> of cobertura with Ofbiz, so we have taken the approach to attempt to download 
> it before doing our build so it is available for any container that wants 
> instrumentation turned on (currently only test-container).  Net result is 
> when we run our tests we will now get very nice code coverage metrics being 
> generated.
> There is an existing target to generate the cobertura report (html) which is 
> not automatically being executed.  Once we get more reasonable code coverage 
> via unit testing we can automatically generate this and expose it as 
> appropriate.

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

[jira] Updated: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with