Re: Issue with OFBiz Job Scheduler and Daylight Saving Time

[Scott Gray]

Hi Deepak,

A few years ago we modified the JobSandbox table to include a temporal
expression timezone field, that allowed a UTC based OFBiz to schedule
recurring jobs according to a specific timezone but ultimately store the
next runTime back in UTC.  I had thought that improvement had made it back
into OFBiz, but I can't see it so I guess it didn't.

Regards
Scott

On Mon, 6 Nov 2023 at 04:52, Deepak Dixit  wrote:

> Thanks Scott for the review and input.
>
> I agree we can use UTC, but in this case we need to reschedule the job
> timings according to the user timezone.
> eg.
> - Reporting jobs that runs on specific time
> - Some business process, like order routing job etc. that should run on
> specific time,
>
> Please correct me if I am missing something?
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Fri, Nov 3, 2023 at 2:38 PM Scott Gray 
> wrote:
>
> > Hi Deepak,
> >
> > IMO the best general solution is to not run OFBiz or the database
> > configured with a timezone that observes DST, instead use UTC or similar.
> > This achieves the same result but without needing any extra fields.
> >
> > I'm not objecting to your solution, just sharing this tip out loud since
> > the JobSandbox is only one of many places that can have trouble with
> > ambiguous DST date/times and it is very difficult to change timezone at
> the
> > db level once it's filled with production data.
> >
> > Regards
> > Scott
> >
> > On Mon, 30 Oct 2023 at 13:05, Deepak Dixit  wrote:
> >
> > > The issue occurs when DST changes, and OFBiz fails to schedule
> recurring
> > > jobs properly.
> > > This is due to a condition in the PersistedServiceJob.createRecurrence
> > > method where it compares the next scheduled time (next) with the start
> > time
> > > (startTime) for the job.
> > >
> > >
> > > *Proposed Solution:*To address the issue, adding a new field named
> > > JobSandbox.runTimeEpoch. This field would store the UTC epoch
> > milliseconds
> > > of the runtime date.
> > > When scheduling or rescheduling recurring jobs, the system would use
> the
> > > UTC epoch stored in JobSandbox.runTimeEpoch for recurring job
> comparison.
> > >
> > > This solution ensures that the system uses a consistent, UTC-based time
> > for
> > > scheduling and rescheduling recurring jobs, even when DST changes
> affect
> > > the local time.
> > >
> > > To implement this solution, we need to do following things:
> > >
> > > - Modify the PersistedServiceJob.createRecurrence method to calculate
> and
> > > store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> > > - Update the code responsible for polling and rescheduling jobs to use
> > the
> > > JobSandbox.runTimeEpoch field when it is set. If the field is not set,
> It
> > > would fall back to getting the runtime date to filter the jobs.
> > >
> > > By using this approach, the system should be able to handle recurring
> job
> > > scheduling more reliably, especially when DST changes are involved, as
> it
> > > ensures that all time comparisons are made in a consistent UTC format.
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > ofbiz.apache.org
> > >
> > >
> > > On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit 
> wrote:
> > >
> > > > Hi Dev,
> > > >
> > > > I wanted to draw your attention to an issue we've encountered with
> the
> > > > OFBiz job scheduler, particularly when it comes to handling Daylight
> > > Saving
> > > > Time (DST) changes.
> > > >
> > > > It appears that the job scheduler fails to create new recurring jobs
> > when
> > > > DST ends, especially when the tempExprTypeId is set to FREQUENCY
> (e.g.,
> > > 15
> > > > minutes, 30 minutes).
> > > >
> > > > Upon further investigation, we've identified that the following
> > condition
> > > > in PersistedServiceJob.createRecurrence might be the root of the
> issue:
> > > >
> > > > java
> > > >
> > > > if (next > startTime) {
> > > > // ...
> > > > // ...
> > > > }
> > > >
> > > > I'm curious to know if anyone else has encountered a similar problem
> or
> > > if
> > > > you have any insights to share regarding this issue.
> > > >
> > > > Thanks & Regards
> > > >
> > > > --
> > > > Deepak Dixit
> > > > ofbiz.apache.org
> > > >
> > >
> >
>

Re: Issue with OFBiz Job Scheduler and Daylight Saving Time

[Scott Gray]

Hi Deepak,

IMO the best general solution is to not run OFBiz or the database
configured with a timezone that observes DST, instead use UTC or similar.
This achieves the same result but without needing any extra fields.

I'm not objecting to your solution, just sharing this tip out loud since
the JobSandbox is only one of many places that can have trouble with
ambiguous DST date/times and it is very difficult to change timezone at the
db level once it's filled with production data.

Regards
Scott

On Mon, 30 Oct 2023 at 13:05, Deepak Dixit  wrote:

> The issue occurs when DST changes, and OFBiz fails to schedule recurring
> jobs properly.
> This is due to a condition in the PersistedServiceJob.createRecurrence
> method where it compares the next scheduled time (next) with the start time
> (startTime) for the job.
>
>
> *Proposed Solution:*To address the issue, adding a new field named
> JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
> of the runtime date.
> When scheduling or rescheduling recurring jobs, the system would use the
> UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
>
> This solution ensures that the system uses a consistent, UTC-based time for
> scheduling and rescheduling recurring jobs, even when DST changes affect
> the local time.
>
> To implement this solution, we need to do following things:
>
> - Modify the PersistedServiceJob.createRecurrence method to calculate and
> store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> - Update the code responsible for polling and rescheduling jobs to use the
> JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
> would fall back to getting the runtime date to filter the jobs.
>
> By using this approach, the system should be able to handle recurring job
> scheduling more reliably, especially when DST changes are involved, as it
> ensures that all time comparisons are made in a consistent UTC format.
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit  wrote:
>
> > Hi Dev,
> >
> > I wanted to draw your attention to an issue we've encountered with the
> > OFBiz job scheduler, particularly when it comes to handling Daylight
> Saving
> > Time (DST) changes.
> >
> > It appears that the job scheduler fails to create new recurring jobs when
> > DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g.,
> 15
> > minutes, 30 minutes).
> >
> > Upon further investigation, we've identified that the following condition
> > in PersistedServiceJob.createRecurrence might be the root of the issue:
> >
> > java
> >
> > if (next > startTime) {
> > // ...
> > // ...
> > }
> >
> > I'm curious to know if anyone else has encountered a similar problem or
> if
> > you have any insights to share regarding this issue.
> >
> > Thanks & Regards
> >
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
>

Re: Are thruDates inclusive or exclusive?

[Scott Gray]

Hi Daniel,

IMO the rule is defined by
EntityDateFilterCondition#makeCondition(Timestamp, String, String) since
this method is used throughout the framework to make date-based
conditions.  It builds the condition as "fromDate <= moment AND thruDate >
moment", therefore rows where thruDate == moment would not appear in the
resultset.

So it would seem that the demo data is incorrect to use x:59:59.999
timestamps in thruDates.

Regards
Scott


On Tue, 31 Jan 2023 at 16:46, Daniel Watford  wrote:

> Hello,
>
> Although it may seem a minor topic, I would like to see if we can make a
> statement about date ranges defined using fromDate and thruDate in OFBiz
> entities.
>
> In The Data Resource Model Revised Edition volume 1 - Table 1.2 Conventions
> Used In Attribute Naming, thru date is described as specifying the end date
> of a date range and is inclusive of that date.
>
> The book draws a distinction between thruDate and toDate, stating that
> thruDate is clearer for specifying the inclusive end of a date range.
>
> However I'm not sure if OFBiz is always using thruDate as an inclusive
> value.
>
> Personally I'm not keen on using inclusive ranges for continuous
> measurements - such as date times - since it bakes in an assumption on the
> maximum precision of our unit of measure, as illustrated by this (very
> contrived) example:
>
> *** BEGIN Dan's contrived example
>
> A self-service checkout allows customers to buy flour with the customer
> pouring the flour onto the integrated weighing scales themselves.
>
> The pricing table for flour used by the self-checkout uses inclusive
> ranges:
> 0 to 5kg priced at $1.30 per kg.
> 6kg to 10kg priced at $1.25 per kg.
> 11kg or more priced at $1.20 per kg.
>
> Confusion occurs when figuring out what price we should use for 5.5kg of
> the product.
>
> So we adjust the pricing table to:
> 0 to 5.999kg priced at $1.30 per kg.
> 6kg to 10.999kg priced at $1.25 per kg.
> 11kg or more priced at $1.20 per kg.
>
> ... and can then answer that 5.5kg should be sold at $1.25 per kg.
>
> But then the weighing scales are upgraded to provide readings with more
> significant digits and a customer (against the odds) pours 5.9995kg of
> flour. We either need to get some rounding rules agreed or further enhance
> the pricing table to allow for these new significant digits in our
> measurements.
>
> Alternatively we could use exclusive 'to' values in our pricing table
>
> For weight W of flour:
> 0kg <= W < 6kg:   $1.30 per kg.
> 6kg <= W < 11kg: $1.25 per kg.
> 11kg <= W: $1.20 per kg.
>
> *** END Dan's contrived example
>
> So why am I asking about this?
>
> In service computeGlAccountBalanceForTimePeriod we select all transactions
> that occurred BEFORE the time period we are interested in using the
> condition:
>   transactionDate < customTimePeriod.fromDate
>
> The service then selects all transactions that occurred DURING the time
> period we are interested in by using the condition:
>   transactionDate < customTimePeriod.thruDate
>
> The above condition suggests that computeGlAccountBalanceForTimePeriod has
> been implemented with an assumption that the date range for a
> CustomTimePeriod is EXCLUSIVE.
>
> If the date range for a custom time period is INCLUSIVE, the condition be:
>   transactionDate <= customTimePeriod.thruDate ?
>
> If we look at the Fiscal Year time period in the Demo Data (
>
> https://demo-next.ofbiz.apache.org/accounting/control/TimePeriods?organizationPartyId=Company
> )
> we see date:
>   fromDate: 2010-01-01 08:00:00.000
>   thruDate: 2011-01-02 07:59:59.000
>
> Ignoring the fact that the dates don't line up, the use of 07:59:59
> suggests the custom time periods have been defined using inclusive date
> ranges. But given my contrived example above, shouldn't we be using
> 07:59:59.999.
>
> I appreciate this all might be splitting hairs and that I am essentially
> pointing at a 1 second gap for each financial period where some database
> queries might miss out a transaction. And even if the transaction was
> missed, it would be included in the query results the following time
> period. But these gaps are where confusion can occur and subtle and
> difficult to reproduce bugs can appear, so it's nice to get things fully
> specified if possible.
>
> Therefore, do we have a general rule on whether thruDates in OFBiz are
> inclusive or exclusive of the thruDate value itself? Or does the
> inclusivity of the thruDate depend on context?
>
> Thanks for reading :)
>
> Dan.
>
>
> --
> Daniel Watford
>

Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service

[Scott Gray]

Hi Giulio,

It seems to me your problem isn't that you have a reservation containing a
quantityNotAvailable, the real problem is that you have an order you can't
fulfill.  Cancelling the affected order line item would seem to be the best
solution, it removes the reservation and cleans up the order.

I would suggest using a custom SECA that runs after
reassignInventoryReservation completes, it would look for reservations
having a quantityNotAvailable greater than zero and then resolve them in
whatever manner you choose (e.g. sending an email to alert the customer
service team, auto-cancelling the order/order item and notifying the
customer, etc.).

Regards
Scott

On Mon, 11 Jul 2022 at 19:31, Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> wrote:

> Hi Scott,
>
> I'll explain a little in depth the context: the e-commerce sites in OFBiz
> use an ERP as the main source of data, both for products and their
> inventory.
> The ERP has different facilities and every night a scheduled procedure sync
> Inventory quantities between the ERP and the e-commerce.
> One of the ERP facilities, let's say facility A, is used not only for the
> e-commerce availabilities but also for wholesale order, retail orders,
> internal orders of the Company, so there could be more than one "party"
> that could use the same inventory on the facility A: here the rule is: the
> first order that comes in is served.
>
> The logistic service that ships the orders is the same for both ERP and
> ecommerce orders, but the e-commerce orders are not "real-time" synced with
> the ERP system (they are synced once in the evening), and the
> logistic service is notified only once a day (in the morning) for the
> e-commerce orders they have to prepare for shipping.
>
> This could lead to a scenario where an ecommerce order for a Product X
> comes in on OFBiz, and an "ERP" order comes in before the notification for
> the e-commerce order could arrive: since the logistic service is unaware of
> e-commerce orders until the email notification,  happen that they ship the
> ERP order, sending the availability for Product X to 0; during the night
> ERP sync its inventory with OFBiz and at this point we have the problem I
> described.
> The ATP of the inventory item related to the orderItem reservation is no
> longer sufficient to fulfill that order row and the system creates a new
> reservation for quantityNotReserved quantity in a new InventoryItem: the
> problem is that, that item can not and will not be shipped because
> physically the logistic has no stock for the product.
>
> For this reason I suggested checking the store configuration, to have the
> same behaviour in case of an "out-of-stock" order.
>
> I got your point and it makes sense: there is a reservation for an order
> and after an inventory update that reservation disappears in silence.
> Could we think about a SECA notification (like the ones for the order
> status changes) for items that could not be re-reserved ?
>
> I know that inventory reservation is always a critical point and an
> "Out-of-stock" could always happen in some way, so this will not be an
> ultimate solution to this, but we could make the e-commerce
> managers/operators more aware of what is going on.
>
> What do you think about it?
>
> Thanks in advance,
> Giulio
>
>
> Il giorno ven 8 lug 2022 alle ore 17:34 Scott Gray <
> scott.g...@hotwaxsystems.com> ha scritto:
>
> > Hi Giulio,
> >
> > I think the hardcoded "N" is used there because a reservation is being
> > deleted and then recreated.  The assumption there is that if a
> reservation
> > existed before the process, then it should also exist after the process
> and
> > should not simply disappear because a physical inventory was recorded.
> In
> > your situation (if I understand correctly), you require inventory for an
> > order to be created but if you then reduce inventory to the point there
> is
> > no longer enough to cover all orders then you want the reservations to
> > disappear?  What happens to the order?
> >
> > Regards
> > Scott
> >
> > On Fri, 8 Jul 2022 at 12:05, Giulio Speri - MpStyle Srl <
> > giulio.sp...@mpstyle.it> wrote:
> >
> > > Hello devs,
> > >
> > > I hope you're doing good!
> > > I write because I think I found a possible issue in minilang service
> > > *reassignInventoryReservation*.
> > >
> > > This service is called as a SECA on createPhysicalInventoryAndVariance
> > > service and at the end it deletes inventory reservation for an order
> > items
> > > that has quantityNotRe

Re: Codenarc integration, rules to use.

[Scott Gray]

+1 in general from me although some of those rules might be challenging to
resolve.  For example DuplicateStringLiteral could be referring to an
entity name being used in delegator queries more than once, I don't think
we'd prefer to see that extracted to a constant.

SpaceAroundMapEntryColon I'm not so sure about, my preference for
legibility has always been [someKey: someValue].  I find
[someKey:someValue] a bit too condensed and harder to differentiate key
from value.

Regards
Scott

On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne 
wrote:

> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
>
> For this purpose we need to agree about the ruleset to put in place.
>
> I took as a basis the ruleset :
> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>
> And started to fix some in
> https://github.com/apache/ofbiz-framework/pull/517
>
> Before doing the complete work, a first rule made me wonder if that is a
> choice that we will be doing as a community :
>
> IfStatementBraces - Use braces for if statements, even for a single
> statement.
>
> There are 234 occurrences in the project, and I guess that some opinions
> might diverge on this subject.
>
> Moreover, some rules needs lots of fixes in the project (those with more
> than 200 occurrences) :
>
>
> ++-+
> | Number of  | Rule name and details
>  |
> | occurrence |
>  |
>
> ++=+
> | 9883   | UnnecessaryGString  - String objects should be created with
> single  |
> ||  quotes, and GString  objects created with double quotes.
> Creating  |
> ||  normal String objects with  double quotes is confusing to
> readers. |
>
> ++-+
> | 4569   | DuplicateStringLiteral  - Code containing duplicate String
> literals |
> ||  can usually be improved by  declaring the String as a
> constant |
> || field. The ignoreStrings property ()  can optionally
> specify a  |
> || comma-separated list of Strings to ignore.
> |
>
> ++-+
> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting
> of  |
> || whitespace around colons for  literal Map entries.
> |
> || The characterBeforeColonRegex and
> characterAfterColonRegex |
> || properties specify a regular expression that  must match
> the|
> || character before/after the colon.
>  |
>
> ++-+
> | 1448   | LineLength  - Checks the maximum length for each line of
> |
> || source code. It checks for  number of characters, so lines
> |
> ||  that include tabs may appear longer than  the allowed
> number   |
> ||  when viewing the file. The maximum line length can  be
>  |
> || configured by setting the length property, which defaults
> to 120.   |
>
> ++-+
> | 885| UnnecessaryGetter  - Checks for explicit calls to
> getter/accessor   |
> ||  methods which can, for  the most part, be replaced by
> property |
> ||  access. A getter is defined as a  method call that
> matches |
> || get[A-Z] but not getClass() or get[A-Z][A-Z]  such as
> getURL(). |
> ||  Getters do not take method arguments. The
> ignoreMethodNames   |
> || property (null) can specify method names that should  be
> ignored|
> || , optionally containing wildcard characters ('*' or '?').
>  |
>
> ++-+
> | 601| NoDef - def should not be used. You should replace it with
> |
> || concrete type.
> |
>
> ++-+
> | 485| MethodReturnTypeRequired  - Checks that method return
> types |
> ||  are not dynamic, that is they are  explicitly stated and
>  |
> ||  different than def.
> |
>
> ++-+
> | 484| Indentation - Check indentation for class and method
> |
> || declarations, and initial statements.
>  |
>
> ++-

Re: Possible issue in balanceInventoryItems/reassignInventoryReservation service

[Scott Gray]

Hi Giulio,

I think the hardcoded "N" is used there because a reservation is being
deleted and then recreated.  The assumption there is that if a reservation
existed before the process, then it should also exist after the process and
should not simply disappear because a physical inventory was recorded.  In
your situation (if I understand correctly), you require inventory for an
order to be created but if you then reduce inventory to the point there is
no longer enough to cover all orders then you want the reservations to
disappear?  What happens to the order?

Regards
Scott

On Fri, 8 Jul 2022 at 12:05, Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> wrote:

> Hello devs,
>
> I hope you're doing good!
> I write because I think I found a possible issue in minilang service
> *reassignInventoryReservation*.
>
> This service is called as a SECA on createPhysicalInventoryAndVariance
> service and at the end it deletes inventory reservation for an order items
> that has quantityNotReserved .gt. 0 and then re-reserve the inventory
> calling the service *reserveProductInventoryByFacility, *implemented by the
> method *reserveProductInventory*
>
>  
> (applications/product/minilang/product/inventory/InventoryReserveServices.xml).
>
> The *reserveProductInventoryByFacility has some parameters passed in and
> among them there is requireInventory parameter, that is hardcoded to N, to
> allow back-orders (negative ATP).*
>
> In our ecommerce context this is not recommendable and the productStores
> are all configured to requireInventory=Y, because we do not want
> back-orders, but the hard-coded requireInventory "N", overrides the store
> setting, making the order "available" even if stock is not present for an
> order item.
>
> I think that it is better to check the productStore setting of the
> requireInventory parameter, and pass that value to the
> *reserveProductInventoryByFacility,* instead of a hard-coded "N".
>
> What do you think about it?
> If you agree I could take care of it in a Jira Task and provide a patch.
>
> Thanks in advance,
> Giulio
>
> --
> Giulio Speri
>
>
> *Mp Styl**e Srl*
> via Antonio Meucci, 37
> 41019 Limidi di Soliera (MO)
> T 059/684916
> M 347/0965506
>
> www.mpstyle.it
>

Re: New proposal on Jira to drop support for derby and use docker instead

[Scott Gray]

>
> As for my first issue that I expect will end up as a derby constraint,
> I'll start with my most recent issue that I run into regularly:
> Before that, I should mention that I don't actually use derby so may be
> blaming some things are derby that are undue, by misunderstanding some of
> its abilities.  So I'll state it as a question.  It that relates to the
> table names being mangled.  For example: searching the list of tables on
> "employ" (to match either "employee" or "employment") misses the tables
> containing employee position because is is called "empl_position".
> So my question is:  are table names mangled like that because we have the
> convention that index and constraint names include the tablename as a
> prefix, and that not mangling the names would have exceeded a derby limit
> on number of characters in a name?


FWIW I believe the 30 character table name limit originated with Oracle and
not Derby.  I'm not sure if Oracle still has that constraint.

Regards
Scott

On Tue, 8 Mar 2022 at 06:45, Development  wrote:

>
> 
> From: Michael Brohl [michael.br...@ecomify.de]
> Sent: Monday, March 07, 2022 2:22 AM
> To: dev@ofbiz.apache.org
> Subject: Re: New proposal on Jira to drop support for derby and use docker
> instead
>
> >Hi ? (no name given),
> Hi there! :)
>
> So let me try to summarize your response:
>
> #1. The only reason to *keep* derby that you see is that we disagree on
> the relative difficultly of getting a "simple build and run" going using
> docker vs the difficulty of using the traditional "install java and follow
> the current instructions" way
> #2. You'd like me to start going through the list of all the issues that I
> expect will end up as a derby constraint.
>
> Is that correct?
>
>
> As for our disagreeing on the relative difficulty between:
>  * installing docker and doing "docker pull ofbiz/demo" (for a demo) or
> "docker pull ofbiz/release18.12" (for a production/development version)
>  * downloading ofbiz, going through the current instructions, trying to
> run it, {then often downloading the correct version of java and doing it
> again}
>
> Possible differences in our information could be:
>  * Perhaps there are other differences in how we are imagining the final
> docker buildfiles to work for the various cases of #1 demo containers, #2
> development containers, and #3 production containers.
>To be clear, one option for a development build/install is that the
> docker buildfile could link the internal ofbiz directory to a directory on
> the "master/local hard drive", meaning that you can edit the ofbiz code on
> the local hard drive and rerun the docker container to run it.  The java is
> still installed inside the docker image, and the buildfile ensures its the
> correct version, as well as handling all the other build details.  (I see
> this as easier for both the demo and the "simple build and run")
>I guess a potential issue I see would be setting up a full eclipse
> debugging environment, as eclipse won't display from inside the container
> (unless you give the container special permissions), and I suspect that
> having eclipse running outside the container will interfere with it's
> integrated debugging.  Are there any others?
>  * Perhaps we are differing in how difficult we believe it is to install
> docker.  I have not used docker on windows.  Is docker difficult to install
> on windows?
>
>
> As for my first issue that I expect will end up as a derby constraint,
> I'll start with my most recent issue that I run into regularly:
> Before that, I should mention that I don't actually use derby so may be
> blaming some things are derby that are undue, by misunderstanding some of
> its abilities.  So I'll state it as a question.  It that relates to the
> table names being mangled.  For example: searching the list of tables on
> "employ" (to match either "employee" or "employment") misses the tables
> containing employee position because is is called "empl_position".
> So my question is:  are table names mangled like that because we have the
> convention that index and constraint names include the tablename as a
> prefix, and that not mangling the names would have exceeded a derby limit
> on number of characters in a name?
>
>
>
> Misc oddities:
> > Derby is not for production use, we state this clearly in the README's
> and production setup guides.
>
> Yep, and I gave ofbiz props for doing that in the phrase "Derby is already
> not recommended for production systems (which is good)".   :)
>
>
>
>
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
> Am 06.03.22 um 23:20 schrieb Development:
> > I added a new proposal on Jira .  It is a proposal to drop support for
> derby and use docker instead (You'll need to read the issue/proposal for
> that to make sense)  The issue is at:
> https://issues.apache.org/jira/browse/OFBIZ-12588
> >
> >
> > This is a copy of the proposal:
> >
> > Derby is un

Re: [jira] [Commented] (OFBIZ-12489) Product Prices - VIEW permissions

[Scott Gray]

I just want to make it clear to anyone reading that actually yes, there has
been discussion in the past about understanding the context of labels and
that the same word in English can mean different things depending on that
context. For this reason labels shouldn't be merged when they are used for
different contexts, ideally the label key would be clear about the context
a label is being used in.

Michael is currently one of the few committers actively performing code
reviews and to claim he is trolling is an insult to the time he is
volunteering and achieves nothing but to harm the project and community.

My two cents.

Regards
Scott

On Tue, 25 Jan 2022, 14:01 Pierre Smits,  wrote:

> Michael,
>
> I told you before in (other) tickets to stop trolling me through your
> complaints in the tickets I am working on. You continue to do this.
> Your remarks about you not committing the code contributions of
> unprivileged contributors are totally inappropriate.  Not appropriate in
> ticket comments, nor in the mailing lists of the project. Nobody is
> strong-arming you to commit or merge improvements. Nobody is expecting you
> ever will.
> Stop trying to pressure fellow contributors, collaborating to improve
> OFBiz, to follow your dictate by your attempt to frame a narrative that
> there is an agreement about how contributors are to contribute what, where
> and when.
> Such narrative is solely intended to dictate the direction of the project
> for your self serving purposes, resulting in alienating fellow contributors
> from collaborating in the OFBiz project to get improvements into its
> repositories.
>
> There has never been such an agreement on how, what, where and when to
> contribute in the OFBiz community. Nor on the specific subject of what the
> correct translation label that is to be used in OFBiz screens and forms.
> No discussion on that latter subject has ever been started on the dev
> mailing list, nor is there any series of postings on that list that could
> lead to someone being able to claim that a kind of consensus could be
> derived from such a thread.
>
> It appears, IMO, that you don't want what is for the good of the public
> through the deliverables of the OFBiz project.
> Your business needs and goals are not the concerns of the project, nor the
> concerns of the contributors not paid by you(r company).
> You keep your Ecomify rules re OFBiz to yourself and for your employees,
> instead of presenting them as rules (or agreements) of the project. In this
> project there are no such 'contribution' rules.
> There are only guidelines, and precedents established over time within the
> project. And these indicate that anything goes.
>
> If you want to change what the way is how contributions are done to the
> project, you start a discussion on the dev mailing list of the project and
> work that discussion towards a consensus. Alternatively you follow the lead
> of what many of your fellow privileged contributors do in this project
> nowadays.
>
> Again: s*top trolling me*. You bring nothing new to the tickets I am
> working. Keep your complaints to yourself, or use them to create a positive
> change to the project that will make OFBiz more appealing, more
> trustworthy, attracting a greater diversity of contributors instead of a
> negative change.
>
> If you want to improve OFBiz, go work the tickets that have your name as
> the assignee to a successful conclusion (or take those of the contributors
> paid by your company, or - if that is all done - take those that are
> unassigned as there are plenty of possibilities there), instead of
> harassing fellow contributors and me collaborating to improve OFBiz.
>
>
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
> Proud contributor to the ASF since 2006
>
> *Apache Directory , PMC Member*
>
>
> On Mon, Jan 24, 2022 at 3:57 PM Michael Brohl (Jira) 
> wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/OFBIZ-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481153#comment-17481153
> > ]
> >
> > Michael Brohl commented on OFBIZ-12489:
> > ---
> >
> > Thanks Jacques.
> >
> > I think you misunderstood my point respectively I made myself not clear
> > enough. I know that we agreed upon the use of common labels vs. specific
> > labels and simply put a reminder to give context. I didn't meant to say
> > that you don't care about labels and I'm sorry if it came across this
> way.
> >
> > I totally agree with your statement "I have always thought that example
> is
> > better than commanding."
> >
> > In this case, I do not think the lack of example is the problem. We've
> > spent a lot of energy together to explain the points with common vs.
> > specific labels and quite a few issues were resolved as "Won't do" in
> this
> > course.
> >
> > Being unfair was in no 

Re: [Conclusion] PartyRole usage in OFBiz

[Scott Gray]

(Removing the private list since the discussion has no place there)

I don't think this topic needs any further debate at this stage.  Pierre
objects to having the tickets closed, so we can leave them open since that
is the easiest path and doesn't really come at any cost.

We don't need to resolve this disagreement until someone is ready to move
forward on an alternative solution that the community will accept.

Regards
Scott

On Sat, 20 Nov 2021, 09:35 Gil Portenseigne, 
wrote:

> Hello Pierre,
>
> Inline,
>
> On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:
> > Hi Gil, All,
> >
> > My apologies, but I have to object to this and for the following
> reasoning:
> > Objections to pursuing improvements to the entity definition (for
> > PartyRole) and subsequent addressing front-end issues (screens/forms,
> > requests, services etc) for that and other entities impacted were raised,
> > before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole
> was
> > brought forward now 4 days ago.
>
> I'm aware about this page and discussion, if i'm not wrong, it is not
> about adding lifespan into PartyRole entity. That is the point I wanted
> to clarify. I'm not contesting this improvement, that can continue in a
> dedicated thread.
>
> If you think that subject is common please clarify to let us take
> position on the PartyRole case (the only one I want to tackle at the
> moment)
>
> >
> > That page defines the requirements for any and all EntityNameRole entity,
> > including PartyRole. And the validity of what was stated there has not
> been
> > contested up to now. Not even by those objecting to changes to PartyRole
> > (as it is included in the page) before the date/time of the page, and who
> > have remained silent since the availability of the page. I wanted to
> wait a
> > bit longer, so that every contributor (and other readers of the dev ml)
> > could have an informed opinion, before suggesting to claim consensus on
> > that. But alas...
>
> I did not gave date on purpose, there is no hurry, it was a way to
> recenter the discussion about this specific case.
> >
> > So it stands to reason that getting current existing and failing
> > EntityNameRole entities (including the PartyRole entity) compliant is
> > implied and thus warranted. And thus tickets can stay as they are. Just
> the
> > order of improvements coming in is a concern that needs to be addressed
> > when they come in. And if such concerns can be addressed and eliminated
> > beforehand, so much the better.
> >
> > Furthermore, one key aspect I would like to mention here. You mentioned
> in
> > your comment (see [1]): 'The current applications IMO are not meant to be
> > used as is'.
> > This is a very wrong point of view, as the many users/contributors in
> user
> > ml see differently.
>
> That is mine, and claiming it is wrong because others see it differently
> is not a valid argument to me.
>
> Claiming that in webtools and partymgr there can be FK errors while
> deleting PartyRole, is IMO not a good argument since those component are
> *technical* ones that should not be used by *non technical* end users.
>
> The idea is not the same for more business component like HR for
> example, where I agree should be more usable for business end user.
>
> > Otherwise they would not raise a thread about the
> > workings of OFBiz, about functionalities not being good enough. Or a
> ticket
> > in JIRA. They expect OFBiz as a business solutions to be usable as is,
> as a
> > minimal viable product (MVP). They don't expect it to be perfect when
> they
> > start using it. They'll trust that it will come along in due time.  And
> > they also don't expect it to have all the bells and whistles a particular
> > developer thinks necessary (while adding no value to the user). But, any
> > improvement brought forward to benefit all can/should go in. That is what
> > they expect.
>
> > And integrators downstream can take that and enhance for their own
> audience
> > (current and future) as they see fit. It is not up to the integrators (as
> > you proclaimed in the same posting: 'It is our choices as Integrators to
> > decide') to decide what goes into OFBiz that works for all users, not
> just
> > their own clients. System integrators don't contribute to an project to
> the
> > ASF. Even if they would be able to do so, at the end the using company
> > decides).
> You are interpreting my words. I was not talking about contribution, but
> about integrators using Apache OFBiz for their customer. The decision I
> was mentioning was about how they design their product to fill the need
> for their customer, where there is not truth but choice to be made.
>
> I remember discussion with you and others in Budapest (old good time)
> that the applications are too big, present many features that
> demonstrate the power of OFBiz, and this fact leads to being hardly
> usable without customization.
> In my experience, anytime I redevelop specific plugins for 

Re: Help required - calling Minilang Experts

[Scott Gray]

Hi Carsten,

call-simple-method executes in the same manner as if you copied the code
from the method being called directly into your code, i.e. it has the same
variable scope as the method it's being called from.  So the "custRequest"
variable from checkStatusCustRequest was available to updateCustRequest.
Now that the implementation is a service, you'd need to explicitly return
that value from the service in order to be able to use it.

Regards
Scott

On Thu, 28 May 2020 at 04:52, Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:

> Hello MiniLang Experts,
>
>
> I am migrating the checkStatusCustRequest service to Groovy (OFBIZ-11692 <
> https://issues.apache.org/jira/browse/OFBIZ-11692>), part of our May
> CommunityDays scope and sprint.
> In the finalization I now notice that the original Minilang service
> „checkStatusCustRequest“ is called by two other services as an inline
> call-simple-method statement:
>
> Source is /applications/order/minilang/request/CustRequestServices.xml:
>
> #121
> Was:
> 
> 
> 
>  from-field="parameters.custRequestId"/>
> 
> 
>  in-map-name="crqCheck">
> 
> 
> 
>
> And the second service in the same minilang file
>
> #237
> Was:
>  short-description="Create Customer RequestItem Note">
> 
> 
>
> Changed to:
>  short-description="Create Customer RequestItem Note">
>  field="crqCheck.custRequestId"/>
> 
> 
>  in-map-name="crqCheck"/>
> 
>
> While the latter passes testing now, the first does not, complaining that:
>
>name="custrequest-tests.testCreateNewRequest" time="0.101">
>type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
> ERROR: Could not complete the update a request
> [file:/Users/carsten/github/ofbiz-framework/applications/order/minilang/test/CustRequestTests.xml#inlineUpdateRequest]
> process [problem invoking the [updateCustRequest] service with the map
> named [updateRequestMap] containing
> [{userLogin=[GenericEntity:UserLogin][createdStamp,2020-05-25
> 09:59:39.293(java.sql.Timestamp)][createdTxStamp,2020-05-25
> 09:59:39.167(java.sql.Timestamp)][currentPassword,null()][disabledBy,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2020-05-25
> 09:59:41.161(java.sql.Timestamp)][lastUpdatedTxStamp,2020-05-25
> 09:59:41.121(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
> custRequestName=New Test Customer request, fromPartyId=admin,
> statusId=CRQ_ACCEPTED, custRequestId=10530, custRequestTypeId=RF_INFO,
> priority=2, locale=en}]: Outgoing result (in runSync : updateCustRequest)
> does not match expected requirements (The following required parameter is
> missing: [OUT] [updateCustRequest.oldStatusId])]
>at
> org.apache.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:91)
>at
> org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
>at
> org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:156)
>at
> org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:78)
>at
> org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:151)
>at
> org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:71)
>at org.apache.ofbiz.base.start.Start.main(Start.java:90)
>   
> So something in my checkStatusCustRequest call is not digesting the
> response from the sub-service properly I suspect as the test complains that
> the subsequent line originally in line #123 which maps the oldStatusId is
> not executed as that field is missing in the response.
>
> Now I am not an expert at all with these cross-service calls, what would
> you suggest here?
>
> Also, a tactical option could be to extend the story to port all three to
> Groovy knowing that the other two are not called as nested
> call-simple-method statements by other services, but always as call-service
> statements which assumedly makes it fairly easy to port (but will cause
> scope slippage).
>
> Thanks for any views and hints.
> Warm regards
>
>
> Carsten
>
>
>
>

Re: EntityBatchIterator for large data set queries

[Scott Gray]

Hi Pritam,

I'm not sure about PostgreSQL or Derby but I know with MySQL that using a
cursor doesn't really work.  You have to set the result set to
TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size to
INTEGER.MIN_VALUE.  Only then will the driver stream the results and even
then, you may not execute any other SQL commands on the connection until
you have fully read or closed the resultset.

So if an EntityListIterator doesn't really conserve memory, then you need
to take a paging query approach such as this:
EntityQuery query = EntityQuery.use(delegator).from("SomeTable").limit(100)
List results = null
while (!(results = query.queryList()).isEmpty()) {
 for (value : results) {
  // do something with each value
 }
 query.offset(query.getOffset() + query.getLimit())
}

Or with the proposed EntityBatchIterator:
Iterator query =
EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()
while (iterator.hasNext()) {
 result = iterator.next()
 // do something with each value
}

I guess an alternative approach would be to implement something similar
within the EntityListIterator and perhaps a flag to turn it off or on
depending on which database is being used and how well it supports
iterating over results without loading the entire resultset into memory.

Regards
Scott



On Sat, 23 May 2020 at 20:59, Pritam Kute 
wrote:

> Hello Pawan,
>
> I just had a look into the EntityQuery.queryIterator() method and looks
> like we can achieve that by using fetchSize(), fowardOnly(),
> cursorScrollInsensitive(), cursorScrollSensitive() and offset() methods in
> EntityQuery class. Let me know if I am missing anything.
>
> It will be good if you can post a pseudo code or something here so that we
> could get an understanding of the exact design which you have in your mind.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Thu, May 21, 2020 at 7:41 PM Pawan Verma  >
> wrote:
>
> > Hello Devs,
> >
> > While working on the large database we have figured out that very large
> > queries consume all memory and crash ofbiz(because queryIterator()
> doesn't
> > really work, it's no different from queryList())
> >
> > The EntityListIterator attempts to use a cursor to iterate over large
> > result sets but in reality most databases do not give us a cursor unless
> we
> > ask for it in a very specific way, and instead you get back the full
> result
> > set and potentially consume a large amount of memory.  For example, the
> > MySql details are here (ResultSet section):
> >
> >
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html
> >
> > To work around this we've built the EntityBatchIterator which instead
> > basically just pages through results like you would do on a webpage that
> > uses pagination.  The iterator takes an EntityQuery and when next() is
> > called it grabs the first 500 records and returns the first record, call
> > next again and you get the second record, once you've called next 500
> times
> > it runs the query again with an offset and grabs the next 500 and so on
> > until there are no more records.
> >
> > The main downsides to this approach are:
> > 1. Same as when using limit/offset you want to be sure your results will
> > come back in a consistent order to avoid accidentally skipping some rows
> > and seeing other rows twice.
> > 2. Because the results are a combination of many queries rather than a
> > single query, some of the data may change while you are paging through
> it.
> > i.e. if you were to sort by lastUpdatedTxStamp you may see some rows
> twice
> > as they are updated by other transactions (this might be a good thing in
> > some cases).
> >
> > So, the main proposal is to introduce a new EntityBatchIterator for large
> > queries.  If we agree on the proposal I'll create a Jira and provide a
> > patch for the community review. Thanks!
> >
> > --
> > Thanks & Regards
> > Pawan Verma
> > Technical Consultant
> > *HotWax Systems*
> > *Enterprise open source experts*
> > http://www.hotwaxsystems.com
> >
>

Re: Default transaction timeout on screen widget

[Scott Gray]

Hi Paul,

I've never seen a transaction timeout actually cause locks to be released
ahead of time before the transaction finally attempts to commit, are you
saying that happens? In my experience if you have a 60 second timeout but
your transaction doesn't try to commit for 15 minutes then the locks will
be held for the full 15 minutes (before finally rolling back when you
attempt to commit).

But no sooner did I ask this question about the relevance of timeouts than
I came across a good use case for them.  If your transaction is wrapping an
API call and the intermediate gateways (like a proxy server or whatever)
have a timeout, then it can be better to have the transaction timeout
shorter than the gateway timeout.  In this manner the client won't
encounter situations where they receive a gateway timeout error response
but the API call they made is actually successful on the server.

Regards
Scott

On Thu, 26 Sep 2019 at 00:46, Paul Foxworthy 
wrote:

> On Tue, 17 Sep 2019 at 18:45, Scott Gray 
> wrote:
>
> > Has anyone ever had a good experience with transaction timeouts?  I feel
> > like they achieve nothing useful in that:
> > 1. They don't interrupt any work that is taking too long (they just
> prevent
> > it from being committed)
> > 2. By the time the exception is thrown, all the work is already done and
> > the result is that it just gets thrown away in exchange for an error
> >
> > Surely there's a positive side to them, and I've just never seen it?
> >
>
> Hi Scott,
>
> Timeouts are not good for the transaction, they're good for competing
> transactions.
>
> In many DBMSes, a transaction keeps things locked until commit, to
> achieve isolation, the I in ACID. If an unusual error situation arises, or
> somebody has designed a transaction (badly) to include a user's think time,
> it's possible the transaction does not commit at all, blocking access to
> data touched by the transaction for everyone else, indefinitely.
>
> A transaction timeout is an estimate of a reasonable amount of time within
> which the transaction should complete. If it doesn't complete, the timeout
> ensures it will roll back, so other transactions won't have to wait too
> long. It's something like an operating system segfaulting a rogue process
> in order to protect all the others.
>
> Cheers
>
> Paul Foxworthy
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: i...@coherentsoftware.com.au
>

Re: Default transaction timeout on screen widget

[Scott Gray]

Hi Nicolas,

I have no objection but I don't think it is something I would ever use.  I
would either fix the screen or increase the timeout for that specific
screen.

Regards
Scott

On Fri, 20 Sep 2019 at 20:20, Nicolas Malin 
wrote:

> Hello Scott, thanks for your return,
>
> in line ...
>
> On 9/17/19 10:45 AM, Scott Gray wrote:
> > Has anyone ever had a good experience with transaction timeouts?  I feel
> > like they achieve nothing useful in that:
> > 1. They don't interrupt any work that is taking too long (they just
> prevent
> > it from being committed)
> > 2. By the time the exception is thrown, all the work is already done and
> > the result is that it just gets thrown away in exchange for an error
> >
> > Surely there's a positive side to them, and I've just never seen it?
>
> Completely agree, it's also my life :) , transaction timeout it's just a
> pain to be sure that you waste your time.
>
> Currently the advantage that I saw, it's detect an unexpected too long
> service and help to spend enough time to optimize it or thinking about
> an other solution.
>
> > But Nicolas, in your case I think the solution lies elsewhere.  I don't
> > think it's ever ok for a screen to take over a minute to load and tie up
> > the http connection all that time.  Slow pages happen to all of us, but
> IMO
> > the solution always lies in making the screen faster, limiting the amount
> > of data that can be processed in a single request or by making the
> request
> > asynchronous.
>
> Sure, I'll join you there. It's generally my first step, currently I
> most concentrate on the second step, decrease error raise where there is
> no benefit.
>
> Do you have an objection if I implement the properties explained below
> with the current default value (60s)? Like this no change for general
> case, and for server with high load, free will for administrator site to
> adjust it.
>
> Cheers,
>
> Nicolas
>
> >
> > Regards
> > Scott
> >
> > On Wed, 11 Sep 2019 at 06:57, Nicolas Malin 
> > wrote:
> >
> >> Hi all,
> >>
> >> Since I increase the sensibility of error message [1], we have on
> >> different screen that take some time to rendering an  error throw due to
> >> transaction timeout.
> >>
> >> By default each screen is rendering with the default timeout (60s) that
> >> isn't enough when you have big data compilation or some external service
> >> latency.
> >>
> >> Of course it's possible to analyze each case with purpose to increase
> >> the screen velocity or set a transaction-timeout on screen definition,
> >> but as first easy step what do you think if we add a default transaction
> >> timeout for screen to 10 minutes with possibility to override by
> >> properties ?
> >>
> >> Example:
> >>
> >> *
> >>
> >>
> >>
> framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
> >> @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
> >>// wrap the whole screen rendering in a transaction, should
> >> improve performance in querying and such
> >>Map parameters =
> >> UtilGenerics.cast(context.get("parameters"));
> >>boolean beganTransaction = false;
> >> -int transactionTimeout = -1;
> >> +int transactionTimeout =
> >> UtilProperties.getPropertyAsInteger("widget",
> >> "widget.transaction.timeout.default", 600);
> >>if (parameters != null) {
> >>String transactionTimeoutPar =
> >> parameters.get("TRANSACTION_TIMEOUT");
> >>if (transactionTimeoutPar != null) {
> >> @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
> >>// If transaction timeout is present, use it to start the
> >> transaction
> >>// If transaction timeout is set to zero, no transaction
> >> is started
> >>if (useTransaction) {
> >> -if (transactionTimeout < 0) {
> >> -beganTransaction = TransactionUtil.begin();
> >> -}
> >> -if (transactionTimeout > 0) {
> >> -beganTransaction =
> >> TransactionUtil.begin(transactionTimeout);
> >> -}
> >> +beganTransa

Re: Default transaction timeout on screen widget

[Scott Gray]

Has anyone ever had a good experience with transaction timeouts?  I feel
like they achieve nothing useful in that:
1. They don't interrupt any work that is taking too long (they just prevent
it from being committed)
2. By the time the exception is thrown, all the work is already done and
the result is that it just gets thrown away in exchange for an error

Surely there's a positive side to them, and I've just never seen it?

But Nicolas, in your case I think the solution lies elsewhere.  I don't
think it's ever ok for a screen to take over a minute to load and tie up
the http connection all that time.  Slow pages happen to all of us, but IMO
the solution always lies in making the screen faster, limiting the amount
of data that can be processed in a single request or by making the request
asynchronous.

Regards
Scott

On Wed, 11 Sep 2019 at 06:57, Nicolas Malin 
wrote:

> Hi all,
>
> Since I increase the sensibility of error message [1], we have on
> different screen that take some time to rendering an  error throw due to
> transaction timeout.
>
> By default each screen is rendering with the default timeout (60s) that
> isn't enough when you have big data compilation or some external service
> latency.
>
> Of course it's possible to analyze each case with purpose to increase
> the screen velocity or set a transaction-timeout on screen definition,
> but as first easy step what do you think if we add a default transaction
> timeout for screen to 10 minutes with possibility to override by
> properties ?
>
> Example:
>
> *
>
>
> framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
> @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
>   // wrap the whole screen rendering in a transaction, should
> improve performance in querying and such
>   Map parameters =
> UtilGenerics.cast(context.get("parameters"));
>   boolean beganTransaction = false;
> -int transactionTimeout = -1;
> +int transactionTimeout =
> UtilProperties.getPropertyAsInteger("widget",
> "widget.transaction.timeout.default", 600);
>   if (parameters != null) {
>   String transactionTimeoutPar =
> parameters.get("TRANSACTION_TIMEOUT");
>   if (transactionTimeoutPar != null) {
> @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
>   // If transaction timeout is present, use it to start the
> transaction
>   // If transaction timeout is set to zero, no transaction
> is started
>   if (useTransaction) {
> -if (transactionTimeout < 0) {
> -beganTransaction = TransactionUtil.begin();
> -}
> -if (transactionTimeout > 0) {
> -beganTransaction =
> TransactionUtil.begin(transactionTimeout);
> -}
> +beganTransaction =
> TransactionUtil.begin(transactionTimeout);
>   }
>
>   // render the screen, starting with the top-level section
>
> ***
>
> Any remarks ?
>
> In parallel i will investigate why the error message catch is so sensible.
>
> Nicolas
>
> [1] http://svn.apache.org/viewvc?view=revision&revision=1856175
>
> --
> logoNrd 
> Nicolas Malin
> The apache way  : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz |The Apache Way
> |réseau LE 
>

Re: ReturnReason: Is this really required?

[Scott Gray]

Hi Suraj,

I think cancelling an order is quite a different scenario from returns. I
can't think of a use case for customized behaviours depending on an order
cancellation reason. So personally I think using enumerations would be
sufficient.

Flexibility is good, but only if we have a good use for it. Otherwise it's
just unnecessary complexity.

Regards
Scott

On Thu, 5 Sep 2019, 20:43 Suraj Khurana,  wrote:

> Yes, agreed.
>
> So what do you propose for to manage cancel reasons? A new entity or
> something similar in pattern of ReturnReason.
> My thought process was started with something for cancel reason, than I
> looked into ReturnReason and started this discussion, actual need is we
> should have something available to manage cancel reasons as well in similar
> fashion we are managing return reason.
>
> I think we should have a similar entity in the same fashion we have
> ReturnReason. It will be more scalable in future to manage behavior of
> cancellation reasons as well.
>
> Please let me know your thoughts on this.
>
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> cell: 96697-50002
> http://www.hotwaxsystems.com
>
>
>
>
>
>
> On Thu, Sep 5, 2019 at 12:40 AM Scott Gray 
> wrote:
>
> > Hi Suraj,
> >
> > It really depends on what the data will be used for.  If you simply want
> to
> > be able to categorize cancellations into groups for reporting then an
> > Enumeration is fine for that IMO.  If you want to define the behavior of
> > parts of the cancellation depending on the reason selected then a new
> table
> > is better.
> >
> > Regards
> > Scott
> >
> > On Mon, 2 Sep 2019 at 17:33, Suraj Khurana 
> > wrote:
> >
> > > Thanks Scott,
> > >
> > > Agreed with your points, in addition to this, there can be some other
> > > scenarios in e-commerce as well, let me try to put some more light on
> > this,
> > > like currently, we are using ReturnReason to capture customer response
> > > while returning an item, someone can require one more as CancelReason
> to
> > > capture customer response while cancelling order.
> > > There can be another XYZReason entity created for any other specific
> > > requirement.
> > >
> > > I was thinking of some kind of generic entity to be used to fulfill the
> > > purpose, so first thought was enumeration, we can have some other
> entity
> > to
> > > use for this purpose that can serve better.
> > >
> > > Or we can agree that for such kind of requirement, there should be
> > always a
> > > new entity to be use, for example CancelReason.
> > >
> > > Please share your thoughts on this.
> > > --
> > > Best Regards,
> > > Suraj Khurana
> > > Technical Consultant
> > > *HotWax Systems*
> > > *Enterprise open source experts*
> > > cell: 96697-50002
> > > http://www.hotwaxsystems.com
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 30, 2019 at 2:37 AM Scott Gray <
> scott.g...@hotwaxsystems.com
> > >
> > > wrote:
> > >
> > > > Hi Suraj,
> > > >
> > > > One good reason for custom enum/type tables is that it allows you to
> > > > specify behaviors for the values.
> > > >
> > > > As a quick made-up example:
> > > > I could add columns like "storeCredit", "exchange", "replace",
> > > "fullRefund"
> > > > to the ReturnReason table and then set those flags to Y/N depending
> on
> > > the
> > > > return reason.  Now I can easily configure that "Do not want" as a
> > return
> > > > reason is only eligible for store credit, while "Arrived with damage"
> > > > return reason is eligible for replacement or a full refund, while
> > "Wrong
> > > > size" is eligible for exchange.  Adding behaviors like this to
> > > enums/types
> > > > allows a user to introduce new records with a unique combination of
> > > > behaviors without the need for code changes (assuming all of the
> > desired
> > > > behaviors are already supported).
> > > >
> > > > Although for the above example one could argue that the configuration
> > > > should be made in conjunction with a ProductStore or Product rather
> > than
> > > > globally, in which case you could a

Re: ReturnReason: Is this really required?

[Scott Gray]

Hi Suraj,

It really depends on what the data will be used for.  If you simply want to
be able to categorize cancellations into groups for reporting then an
Enumeration is fine for that IMO.  If you want to define the behavior of
parts of the cancellation depending on the reason selected then a new table
is better.

Regards
Scott

On Mon, 2 Sep 2019 at 17:33, Suraj Khurana  wrote:

> Thanks Scott,
>
> Agreed with your points, in addition to this, there can be some other
> scenarios in e-commerce as well, let me try to put some more light on this,
> like currently, we are using ReturnReason to capture customer response
> while returning an item, someone can require one more as CancelReason to
> capture customer response while cancelling order.
> There can be another XYZReason entity created for any other specific
> requirement.
>
> I was thinking of some kind of generic entity to be used to fulfill the
> purpose, so first thought was enumeration, we can have some other entity to
> use for this purpose that can serve better.
>
> Or we can agree that for such kind of requirement, there should be always a
> new entity to be use, for example CancelReason.
>
> Please share your thoughts on this.
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> cell: 96697-50002
> http://www.hotwaxsystems.com
>
>
>
>
>
>
> On Fri, Aug 30, 2019 at 2:37 AM Scott Gray 
> wrote:
>
> > Hi Suraj,
> >
> > One good reason for custom enum/type tables is that it allows you to
> > specify behaviors for the values.
> >
> > As a quick made-up example:
> > I could add columns like "storeCredit", "exchange", "replace",
> "fullRefund"
> > to the ReturnReason table and then set those flags to Y/N depending on
> the
> > return reason.  Now I can easily configure that "Do not want" as a return
> > reason is only eligible for store credit, while "Arrived with damage"
> > return reason is eligible for replacement or a full refund, while "Wrong
> > size" is eligible for exchange.  Adding behaviors like this to
> enums/types
> > allows a user to introduce new records with a unique combination of
> > behaviors without the need for code changes (assuming all of the desired
> > behaviors are already supported).
> >
> > Although for the above example one could argue that the configuration
> > should be made in conjunction with a ProductStore or Product rather than
> > globally, in which case you could also consider adding productStoreId and
> > productId to the ReturnReason table and have the returnReasonId simply
> > become a sequenced id rather than an enum.
> >
> > So even if OFBiz doesn't make use of it currently, I think there's a
> solid
> > use case for return reasons not simply being Enumeration records.
> >
> > Regards
> > Scott
> >
> >
> > On Thu, 29 Aug 2019 at 17:21, Suraj Khurana  wrote:
> >
> > > Hello folks,
> > >
> > > We have an entity ReturnReason in which we have some predefined return
> > > reasons and any custom projects and add more reason to it.
> > > My question is do we really need an entity for this, it can be easily
> > > managed through any enumeration data as well of certain enum type.
> > >
> > > Are there any other cases that I am missing here for which we need this
> > > specific entity?
> > > Please share your thoughts on this.
> > >
> > > --
> > > Best Regards,
> > > Suraj Khurana
> > > Technical Consultant
> > >
> >
>

Re: ReturnReason: Is this really required?

[Scott Gray]

Hi Suraj,

One good reason for custom enum/type tables is that it allows you to
specify behaviors for the values.

As a quick made-up example:
I could add columns like "storeCredit", "exchange", "replace", "fullRefund"
to the ReturnReason table and then set those flags to Y/N depending on the
return reason.  Now I can easily configure that "Do not want" as a return
reason is only eligible for store credit, while "Arrived with damage"
return reason is eligible for replacement or a full refund, while "Wrong
size" is eligible for exchange.  Adding behaviors like this to enums/types
allows a user to introduce new records with a unique combination of
behaviors without the need for code changes (assuming all of the desired
behaviors are already supported).

Although for the above example one could argue that the configuration
should be made in conjunction with a ProductStore or Product rather than
globally, in which case you could also consider adding productStoreId and
productId to the ReturnReason table and have the returnReasonId simply
become a sequenced id rather than an enum.

So even if OFBiz doesn't make use of it currently, I think there's a solid
use case for return reasons not simply being Enumeration records.

Regards
Scott


On Thu, 29 Aug 2019 at 17:21, Suraj Khurana  wrote:

> Hello folks,
>
> We have an entity ReturnReason in which we have some predefined return
> reasons and any custom projects and add more reason to it.
> My question is do we really need an entity for this, it can be easily
> managed through any enumeration data as well of certain enum type.
>
> Are there any other cases that I am missing here for which we need this
> specific entity?
> Please share your thoughts on this.
>
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
>

Re: weird behavior in reply lately

[Scott Gray]

Yeah I don't see any need to vote or discuss going back to the behavior
everyone was used to for the past decade and was changed by accident.

Regards
Scott

On Sat, 29 Jun 2019, 00:49 Deepak Dixit,  wrote:

> I think we should ask infra to set it as it was.
> I agree everybody was happy with it.
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Fri, Jun 28, 2019 at 5:41 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Thanks Deepak,
> >
> > It makes sense indeed and Pierre could apologise :/
> >
> > The question is should we vote?
> >
> > So far it all depends on me and my -0.2 added to Paul's -0.8 after
> Mathieu
> > convinced me that it would be better do to otherwise.
> >
> > If Mathieu does not want to use his veto, I'll not apply mine. It was
> like
> > that for years and it seems everybody was happy, including Mathieu, Paul
> > and I, we never complained.
> >
> > Would that be a lazy consensus and a happy (but hot in some places)
> world?
> >
> > Jacques
> >
> > Le 28/06/2019 à 11:59, Deepak Dixit a écrit :
> > > Reply-to header was there till may end.
> > > It seems something went wrong after the revert process of the following
> > > task.
> > > https://issues.apache.org/jira/browse/INFRA-18553
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > ofbiz.apache.org
> > >
> > >
> > > On Fri, Jun 28, 2019 at 3:21 PM Deepak Dixit 
> wrote:
> > >
> > >> Hi Jacques,
> > >>
> > >> Here are the two reference link one of from Jan 2019 and another one
> is
> > a
> > >> recent one
> > >>
> > >>
> >
> https://lists.apache.org/api/source.lua/f9107f8ca9a17a2df731337fc3d9766ebad33467fea4393fb069552d@%3Cdev.ofbiz.apache.org%3E
> > >>
> > >>
> >
> https://lists.apache.org/api/source.lua/218b191d66f303f19cc2e9f12f9f759d3a11a402bb749ba73b44d891@%3Cdev.ofbiz.apache.org%3E
> > >>
> > >> Please check for reply-to, it was in the older thread but missing in
> the
> > >> recent one.
> > >> I think we need to talk to infra to investigate this issue.
> > >>
> > >> Thanks & Regards
> > >> --
> > >> Deepak Dixit
> > >> ofbiz.apache.org
> > >>
> > >>
> > >> On Fri, Jun 28, 2019 at 3:04 PM Jacques Le Roux <
> > >> jacques.le.r...@les7arts.com> wrote:
> > >>
> > >>> Le 28/06/2019 à 11:23, Taher Alkhateeb a écrit :
> >  I don't even use a mail client. I use web interface and it does not
> > >>> work.
> >  It's also annoying to have to configure mobile client, desktop
> client
> > >>> and
> >  web. I prefer to add the headers back.
> > >>> Are we sure it was there ?
> > >>>
> >
>

Re: weird behavior in reply lately

[Scott Gray]

Appears to me that it happened around the same time that Pierre asked infra
to add unsubscribe footers to list emails.  Was working late May, had
stopped by 4th June.

Regards
Scott

On Fri, 28 Jun 2019 at 21:51, Deepak Dixit  wrote:

> Hi Jacques,
>
> Here are the two reference link one of from Jan 2019 and another one is a
> recent one
>
> https://lists.apache.org/api/source.lua/f9107f8ca9a17a2df731337fc3d9766ebad33467fea4393fb069552d@%3Cdev.ofbiz.apache.org%3E
>
> https://lists.apache.org/api/source.lua/218b191d66f303f19cc2e9f12f9f759d3a11a402bb749ba73b44d891@%3Cdev.ofbiz.apache.org%3E
>
> Please check for reply-to, it was in the older thread but missing in the
> recent one.
> I think we need to talk to infra to investigate this issue.
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Fri, Jun 28, 2019 at 3:04 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 28/06/2019 à 11:23, Taher Alkhateeb a écrit :
> > > I don't even use a mail client. I use web interface and it does not
> work.
> > > It's also annoying to have to configure mobile client, desktop client
> and
> > > web. I prefer to add the headers back.
> > Are we sure it was there ?
> >
>

Re: weird behavior in reply lately

[Scott Gray]

I didn't mean any disrespect, my apologies Mathieu.  My email was written
out of frustration that something worked well for many years and suddenly
changed for the worse (in my opinion).

Regards
Scott

On Fri, 28 Jun 2019 at 20:13, Mathieu Lirzin 
wrote:

> Scott Gray  writes:
>
> > I just did it as well and it's super annoying.  I don't ever want to
> > directly reply to messages on our lists, at least without some manual
> > effort on my part.  Personally I couldn't care less about whether or not
> > some idealists think setting reply-to is harmful.
>
> Should I say then that I don't care about people who don't want to make
> the effort of configuring and using an email client properly? Let us not
> go that path and be respectful to each other.
>
> This topic has nothing to do with “idealism”, it is just about adopting
> some practical and safe conventions.
>
> I acknowledge that your current habits makes things impractical for you,
> since you were expecting "reply" to mean "reply to {list,group,all}" but
> to me this is just confusing.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: weird behavior in reply lately

[Scott Gray]

I just did it as well and it's super annoying.  I don't ever want to
directly reply to messages on our lists, at least without some manual
effort on my part.  Personally I couldn't care less about whether or not
some idealists think setting reply-to is harmful.

On Mon, 24 Jun 2019 at 04:10, Aditya Sharma 
wrote:

> Hi Taher,
>
> It's due to missing reply-to headers.
>
> See the mail thread *Reply-to address missing for dev and user mailing
> list* : https://markmail.org/message/l6z542dowhpl3t36
>
> Thanks and regards,
> Aditya Sharma
>
> On Sun, Jun 23, 2019, 9:10 PM Taher Alkhateeb 
> wrote:
>
> > Hi folks,
> >
> > I'm not sure if something is wrong, but lately I keep replying to
> > individuals instead of the mailing list (or sometimes both). Did
> > something change in our mailing servers? Or could it be that gmail
> > changed its behavior perhaps?
> >
>

Re: Files w/o licenses

[Scott Gray]

I hope you'll name the reviewers that missed them as well :-)

On Sun, 2 Jun 2019 at 07:33, Jacques Le Roux 
wrote:

> OK, I'll do it in a week if nobody beats me on it.
>
> But I'll name those that should have done it before :p
>
> Jacques
>
> Le 28/05/2019 à 14:49, Jacques Le Roux a écrit :
> > Hi Committers,
> >
> > Please guys make an effort:
> https://ci.apache.org/projects/ofbiz/rat-output.html
> >
> > I normally do it (add missing licences) but the RAT build was off for
> months and they piled up
> >
> > (OK now as it specifically depends on lares_ubuntu Buildbot server:
> https://issues.apache.org/jira/browse/INFRA-18500)
> >
> > You should be able to recognise your own commits, and it's better for
> you to learn and remember ;)
> >
> > Thanks
> >
> > Jacques
> >
> >
>

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

[Scott Gray]

In my experience very few things in the business world are immutable.
Dated *Role entities enhance flexibility and provide a decent audit trail
for the inevitable changes that businesses need to support (I placed this
order against the wrong customer, customer A has bought customer B so we
need to transfer over all existing orders).

Having *Role entities alongside from/to partyIds (or any time there's
multiple ways to link two objects) leads to confusion, behavioral
inconsistencies and a complicated code base.

For example why is there an originFacilityId on OrderHeader when there is a
facilityId field on OrderItemShipGroup as well?  That's just an example I
noticed recently, I've noticed a bunch over the years and they only serve
to complicate development.

I'm sure there are scenarios where from/to partyIds are suitable (like
PartyRelationship) but I disagree with a broad proposal such as this to
apply them to a range of entities.  I'd prefer to see us move in the other
direction and remove top-level entitiy from/to fields if there is an
existing *Role entity in order to simplify the datamodel while maintaining
flexibility.

Regards
Scott

On Sun, 19 May 2019 at 22:57, Pierre Smits  wrote:

> I totally agree with
>
> leave the entity designs well designed and solid
>
>
> The Unified Data Model has been designed well and is still withstanding the
> test of time. This design is the reason why our project opted to have this
> at its core for all the business applications.
> It is the digressions from (even more so the explanation regarding the
> applicability of those digressions) that have us going through hoops to
> ensure that what is used where, when, how and why remains consistent. From
> persistence, through service/functions and UI to documentation.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
>
> On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > I'm also in favor of the more flexible design based on roles. Let the
> > services worry about sorting this stuff out and leave the entity
> > domain layer solid and well designed.
> >
> > On Thu, May 16, 2019 at 11:25 PM Michael Brohl  >
> > wrote:
> > >
> > > Hi Pierre,
> > >
> > > I think there are more sophisticated concepts for some of the mentioned
> > > entities, for example
> > >
> > > - OrderRole for orders allows to connect an unlimited number of parties
> > > with different roles
> > >
> > > - CustRequestParty, QuoteRole, CustRequestRole - same principle
> > >
> > > For these, introducing from/toPartyId would be no improvement IMO. *If*
> > > we would want to make a change, I would tend more to implementing the
> > > ...Role principle where it is missing and get rid of the from/toPartyId
> > > pattern. But this would be a big change...
> > >
> > > I'm not sure why we have these in some entities which also have the
> > > ...Role entities, such as Invoice.
> > >
> > > Maybe others can give more insights?
> > >
> > > Regards,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> > > Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > > > Hi All,
> > > >
> > > > Currently several entities capture the (contractual) parties in
> fields
> > like
> > > > fromPartyId and toPartyId. These parties commonly represent the
> > internal
> > > > (accounting) organisation and the external party (the customer,
> > supplier,
> > > > contact, account, carrier etc).
> > > >
> > > > Such entities are:
> > > >
> > > > - Agreement (in party)
> > > > - Employment (in humanres)
> > > > - Invoice (in accounting
> > > > - OrderReportPurchasesGroupByProduct
> > > > - PartyBenefit (in humanres)
> > > > - Payment (in accounting)
> > > > - PayHistory (in humanres)
> > > > - ReturnHeader (in Order)
> > > > - UnemploymentClaim (in humanres
> > > >
> > > >
> > > > However there are a (quite a) few entities that defy these 1-on-1
> > > > relationships (between internal party and the object, and the
> external
> > > > party and the object), like:
> > > >
> > > > - OrderHeader: neither partyIdFrom nor partyIdTo
> > > > - Quote: neither partyIdFrom nor partyIdTo but having a partyId
> > field
> > > > - CustRequest: only having fromPartyid (plus its role
> > > > - Subscription: having originatedFromPartyId (plus the role) and
> > partyId
> > > > - ReorderGuideline: having partyId (plus the role)
> > > >
> > > > And I am confident I am missing a few.
> > > >
> > > > In oder to simplify processes for capturing the main parties in
> various
> > > > entity records I propose to realign these (master) entities to ensure
> > that
> > > > both th

Re: Code Improvement for Groovy

[Scott Gray]

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
 // Not set, use a default
 maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:

> Hello Devs,
>
> As we all know, Groovy is a powerful language with great built-in
> functions. Groovy Truth[1] is one of them, which is not used properly in
> our code base. We have used UtilValidate Class to validate arguments for
> Empty or NotEmpty, which can easily be done in groovy with built-in
> functionality.
>
> Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }
>
> Groovy Built-in Code: if (locations) { ... }
>
> IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
> Please let me know your thoughts on this. Thanks!
> [1] - http://groovy-lang.org/semantics.html#Groovy-Truth
>
> --
> Kind Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
>

Re: ExternalId support in relevant entities

[Scott Gray]

I'd tend to agree with Pierre here, following the {entity}Identification
pattern is probably a better approach long term simply because the
externalId pattern breaks as soon as you need more than one identifier.  If
the likelihood of multiple IDs is low, then the {entity}Attribute pattern
might be a better approach.

But with that said, when customizing a system I'll typically just throw an
additional field on the entity and be done with it.  It doesn't take long
to write a helper method get{Entity}ByExternalId(String) to hook it up.
Because there's very little business logic that OFBiz can attach to these
fields, the amount of time we can save developers by having these fields
available in advance is very small.  That changes with the Identification
pattern because we can provide from/thru dating, enforce unique constraints
and regex patterns etc. which will save developers more time.

Regarding Facility, it's useful to have an external identifier when you're
integrating/syncing with a 3PL system or in general if you don't own the
facility that you're using.  But that could be said of almost any table in
the system when you need to keep it in sync with another.

I almost wonder if a generic entity (EntityIdentification) would be a
better approach that contains something like:
- entityName
- entityId
- fromDate
- thruDate
- idType
- value
We could then provide a set of generic helper methods/services to perform
lookups and update values e.g. GenericValue facility =
getEntityById("Facility", "3PL", "123").  The CRUD services could use
another table (EntityIdentificationType) to help with enforcing contraints:
- entityName
- idType
- requireUnique
- validationRegex

The main downsides would be:
- Duplication with the current Identification pattern (confusion)
- Lack of foreign keys back to the entities being identified
- Largely unused pattern in general currently (I think only EntityAuditLog
is similar)

Regards
Scott

On Fri, 3 May 2019 at 00:33, Pierre Smits  wrote:

> Current methodology of having the externalId field in the various tables is
> limiting the capabilities of OFBiz. With this an object can have only 1
> externalId value. However, it is quite feasible that an object can be
> associated with various external systems with each having a different
> externalId value. This is particularly true for the party entity.
>
> I wonder whether this is necessary for a facility. If a supplier has an Id
> value for one of the internally used facilities, why would the adopter
> care? Similar thoughts are on contact mech and shipment. But a good example
> and explanation for each may help.
>
> The external Id of a product is (as far as it is related to a product
> supplied by a 3rd party) captured in SupplierProduct entity. If the intent
> is to capture the product Id as it is used by a customer and other parties,
> then the same reasoning as used for parties (see above) applies. Why would
> an OFBiz adopter care what the external Ids of downstream parties are?
>
> The identification type SKU can't be used for this purpose, as it is
> intended to have a value based on internally used variation/feature
> combinations. I suggest reading up on [1]. The definitions used by either
> supplier, customer, etc. may lead to conflicts.
>
>
> [1] https://en.wikipedia.org/wiki/Stock_keeping_unit
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
>
> On Thu, May 2, 2019 at 1:44 PM Suraj Khurana 
> wrote:
>
> > Hello team,
> >
> > As far as my understanding, externalId in OrderHeader is used to save
> > orderId reference of any other system into our system.
> >
> > If this is the only case, we should also maintain something similar on
> > following entities as well as consistency and they will be in need in
> case
> > of a full-fledged integration with OFBiz environment with any other
> system:
> >
> >1. ReturnHeader
> >2. ContactMech
> >3. Party (already exist)
> >4. Facility
> >5. Product (can be discussed, Identification type SKU can also do the
> >job)
> >
> > Please let me know your thoughts on this.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Technical Consultant
> >
>

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

[Scott Gray]

Fwiw more often than not I can identify who made a specific change by
searching the logs, assuming they're retained for long enough. Most http
requests log the session ID (when the view is rendered) which can then be
matched to a user via the Visit table.

I'm not sure if that has changed in recent versions but I've used it many
times over the years.

Regards
Scott

On Sat, 27 Apr 2019, 00:23 Pierre Smits,  wrote:

> Gill, all,
>
> The entity_audit_log feature also sprung into my mind shortly after I
> posted my comment.
>
> I wonder how many of our adopters are aware of this feature and the penalty
> aspect in production setups. And of how many do we in this project know
> that these adopters are aware?
> Such info rarely trickles back into our mailing lists.
> Even in this community there hasn't been much traffic regarding that
> subject over the years. Markmail (see [1]) revealed that they have only
> just over a 100 postings registered.
>
> And isn't so, that when an adopter suspects foul play this often already
> has happened. Enabling the entity_audit_log feature after suspicion of foul
> play is like closing the barn after the horse has beens stolen.
>
> But lets address the 'what is required to have the entity_audit_log-feature
> operational' for a moment.
> I did a google search on the subject and I found nothing (substantial)
> about this feature that explains how it functions and what is required to
> have it operational.
> From what I got from memory recollection and recent searches, that this
> only works for fields that have the 'enable-audit-log' attribute set to
> "true" in the entity-models. I found only 10 fields in the various
> applications component have such an attribute setting (only 2 entities in
> order-entity.model: OrderItem and ReturnItem . Non of the other fields in
> the entity models have have the 'enable-audit-log' set to 'false'.
>
> And you are correct, this feature comes with a processing penalty, which
> increases with the number of fields marked for auditing. That is the first
> -1 about having to do analysis on who created and changed what, where and
> when.
>
> The second -1 about the 'enable_audit_log'-feature is that, even when an
> adopter is having the 'audit' and the entity_audit_log feature on his mind
> and wants it operational for more business critical fields in then his
> implementation project will increase as all the entities need to be
> enhanced regarding those fields. Plus in this feature for audit trails and
> fraud detection it requires fields that capture the UserLogin values
> (createdBy and lastModifiedBy). In current code base even less entity have
> a field that captures the userLogin (12, through the changeByUserLoginId
> field).
>
> The third -1 is that this feature doesn't appear have a property setting to
> enable or disable the feature in underlying services. That means it is
> always on, and dependent on the entity-model changes. When the adopter
> suspects foul play he can't simply change a property setting to temporarily
> take the performance penalty to confirm or debunk his suspicion. Nor  does
> he have functionalities available to enable/disable specific fields
> dynamically through the UI (of e.g. web tools).
>
> And last but not least: he fourth -1 regarding the
> 'enable_audit_log'-feature is that it doesn't appear to be working as
> expected. I did a cursory test with an order some moments ago in ofbiz (see
> [1]) and it does not capture the old values on the line items. But I may be
> misunderstanding the screen/process there.
>
> All in all, there are a lot of technical +1s in favour of having the
> createdByUserlogin and lastModifiedByUserLogin added through the internal
> fields injection process. The implementation in the code base by the
> community can be achieved fairly fast. The impact on migration (for
> existing adopters planning to upgrade) is rather small, as it only extends
> the model with 2 fields (added at the end) and easily explained. And it
> offers additional business-case benefits for those considering to use the
> product for their mission critical business processes.
>
> [1]
>
> https://ofbiz.markmail.org/search/?q=enable-audit-log#query:enable-audit-log+page:1+state:facets
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
>
> On Fri, Apr 26, 2019 at 12:17 PM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
>
> > Hello Pierre,
> >
> > If you have specific need of Auditing, after suspition of malicious
> > users, you can enable entity_audit_log feature on the desired table.
> > At a cost of performance loss.
> >
> > I do not understand why impersonation feature appears here, since

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Scott Gray]

The problem is that jira notification volume far exceeds dev list volume
which has the effect of stifling dev list discussions due to them being
pushed far down the list of recent emails.  The only solution to that is to
filter the jira notifications.  Right now in gmail I can see one week's
worth of jira emails and around 6 weeks worth of dev conversations.  Dev
list discussions are far more important that jira notifications, anything
important happening in jira should already have been discussed in the dev
list.  So we took the opinionated approach that dev list users should not
have to set up a filter in order to avoid being bombarded with low value
notifications.  I would much rather have contributors fully engaged in dev
list discussions than drown them in jira notifications.

Regards
Scott

On Fri, 26 Apr 2019 at 06:43, Pierre Smits  wrote:

> We can not prevent those not interested in what is happening to
> unsubscribe. And with modern mail clients (or online solutions) anyone not
> interested to see posting about specific categories (commits, JIRA
> notifications) can set filters there to:
>
>1. have the postings of these categories automatically moved to other
>(sub-)folders, or
>2. have the posting automatically deleted
>
>
> This is not about those of the community who do not want to be informed or
> want to see/do less, but rather about reaching more (potential)
> contributors. The implementation of the result of the vote conveniences
> those not interested. If we suppose that all of the PMC members and all of
> the committers have subscribed to notifications@, then only 11 out of 574
> dev subscribers or out of 926 users@ subscribers see stuff regarding OFBiz
> issues.
>
> Michael makes the point that those interested should subscribe, leaving it
> to them to show interest. But we should turn it around, as it was before,
> in order to attract more. More parties to work with (adpoters) and/or to
> contribute to have a better product faster.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
>
> On Thu, Apr 25, 2019 at 1:59 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > I used to have a filter on "(OFBIZ-" to redirect to my OFBiz Jira folder.
> > Having a specific list is easier indeed.
> >
> > Jacques
> >
> > Le 25/04/2019 à 13:39, Swapnil M Mane a écrit :
> > > I am also inline with Michael's comments.
> > >
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > ofbiz.apache.org
> > >
> > >
> > >
> > > On Thu, Apr 25, 2019 at 4:48 PM Michael Brohl <
> michael.br...@ecomify.de>
> > > wrote:
> > >
> > >> I strongly suggest to stay with the split between notifications@ and
> > dev@.
> > >>
> > >> It makes the dev@ discussions a lot better to follow, these would
> drown
> > >> in the Jira notifications. I suspect that we would make users
> > >> unsubscribe dev@ if we would have notifications@ in there also.
> > >>
> > >> If people are interested in getting the notifications, they can
> > >> subscribe anytime. It might be reasonable to encourage people in the
> > >> dev@/user@ lists to subscribe there if we believe they are not aware
> of
> > >> the notifications@ list.
> > >>
> > >> Regards,
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >> Am 25.04.19 um 12:20 schrieb Pierre Smits:
> > >>> Hi All,
> > >>>
> > >>> Back in 2016 it was decided that notifications go to the separate
> > mailing
> > >>> list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
> > >>> reported regarding subscriptions to our mailing lists, we have:
> > >>>
> > >>>  - user@: 926
> > >>>  - dev@: 574
> > >>>  - commits@: 218
> > >>>  - notifications@: 78
> > >>>
> > >>> The numbers regarding user@, dev@ and notifications@ are from
> > >> 2018-06-20,
> > >>> and the number regarding notifications@ is from 2018-03-20, see [2].
> > >>>
> > >>> The numbers indicate that about 14% of our contributor potential
> > >> subscribed
> > >>> to the dev@ sees these notifications about bugs and improvements,
> and
> > >> less
> > >>> than 9%  of our greater community  (subscribed to user@) are
> reached.
> > >> And
> > >>> when we factor in the impact of PMC members and committers (I can
> only
> > >>> guess how many of those have subscribed) on notifications@) the
> ratios
> > >> are
> > >>> even worse.
> > >>>
> > >>> The effect of the low number of subscriptions to notifications@ is
> > that
> > >> we
> > >>> don't reach our potential and that we don't see the input of dev@
> and
> > >> user@
> > >>> subscribers, leading to an overload of those working tickets.
> > >>>
> > >>> Did we take a wrong turn back in 2016

Re: [OPTIONS] Java 11 and Java JDK origin

[Scott Gray]

Reasons to increase the minimum version:
- compelling new features
- end of support of current minimum

Reasons to not increase the minimum:
- potential instability of new version
- complicates the life of users and contributors who still use the existing
minimum
- lack of expertise in configuring and using new features

I think every few months we should discuss it but I don't think it's worth
shifting any time soon. The pros need to outweigh the cons, and personally
I don't really see it at the moment.

The end of support date for 11 probably shouldn't be a consideration at
this point, by the time we even get close to that java 23 LTS will probably
be a year old :)

Regards
Scott

On Tue, 16 Apr 2019, 00:50 Michael Brohl,  wrote:

> Ah, sorry Taher if I was not clear enough.
>
> Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> trunk, 18.12 and 17.12 to make the project independent from the short
> cycled releases of the Oracle JDK and the subscription for use of the
> Oracle JDK 8 LTS.
>
> I just recognized that Adopt JDK 11 LTS will be available until Sept.
> 2022. If that is not a mistake I have to refine the timeline: we can
> then switch to Adopt Open JDK 11 LTS on trunk right before the release
> branch for 19.x is created. I guess that the future LTS releases will
> have support for at least 4 years.
>
> That means we would remain Java 8 compatible for the releases 16 to 18
> and announce the Java 11 dependency for release 19 and up. This should
> give users enough time to plan, test and migrate.
>
> Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> then.
>
> For the future, I would suggest to introduce a new Open JDK LTS version
> about 3-6 months after the first release, we might want to create a new
> release branch in the course of this.
>
> What do you think?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
> > Hi Michael,
> >
> > So just to understand your suggestion clearly. Are you recommending
> > that we switch from oracle JDK to open JDK now (in 18 and trunk) and
> > introduce open jdk 11 in 2021?
> >
> > On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl 
> wrote:
> >> Hi Scott, all,
> >>
> >> yes, Adopt Open JDK 8 LTS is supported at least untile September 2023
> [1]
> >>
> >> Thinking about this a bit more I second to stay with Open JDK 8 LTS for
> >> release branches 17.12, 18.12 and trunk for now.
> >>
> >> Professional users/ companies have a very conservative update strategy
> >> for base technologies like the JDK and we should support it as long as
> >> it is reasonable.
> >>
> >> So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the
> >> release branch 21.x, meaning that we change to JDK 11 right before the
> >> release branch will be created. This gives us plenty of time to test
> >> with Java 11 and we can introduce Java 11 features in the trunk after
> >> that. So release branch 22.x would be the first to depend on Java 11.
> >>
> >> What do you think?
> >>
> >> Best regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> [1] https://adoptopenjdk.net/support.html
> >>
> >>
> >> Am 15.04.19 um 00:07 schrieb Scott Gray:
> >>> My understanding was that openjdk would support java 8 until 2023.
> >>>
> >>> In the past our strategy used to be that we should ensure the code base
> >>> would operate on newer java versions but keep our minimum required
> version
> >>> as low as possible.  That effectively allows users to run whatever
> version
> >>> they like.  So unless there are some compelling new features in java
> >>> 9/10/11 that we think we must have, I'd prefer it if we kept our
> minimum
> >>> supported version as low as possible.
> >>>
> >>> For myself, all client projects are still running java 8 (openjdk) so
> >>> before I could continue contributing to OFBiz I would have to figure
> out
> >>> how to run both versions on my machine with minimal disruption.  Since
> I
> >>> don't have a huge amount of spare time, I would probably just put it
> off
> >>> for quite a while and work on other things.
> >>>
> >>> I'm not trying to veto the idea, if the community wants to proceed
> then it
> >>> should but I doubt I'm the only contributor we'd 

Re: [OPTIONS] Java 11 and Java JDK origin

[Scott Gray]

My understanding was that openjdk would support java 8 until 2023.

In the past our strategy used to be that we should ensure the code base
would operate on newer java versions but keep our minimum required version
as low as possible.  That effectively allows users to run whatever version
they like.  So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our minimum
supported version as low as possible.

For myself, all client projects are still running java 8 (openjdk) so
before I could continue contributing to OFBiz I would have to figure out
how to run both versions on my machine with minimal disruption.  Since I
don't have a huge amount of spare time, I would probably just put it off
for quite a while and work on other things.

I'm not trying to veto the idea, if the community wants to proceed then it
should but I doubt I'm the only contributor we'd be putting another hurdle
in front of.

Regards
Scott

On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
wrote:

> Well, I could be mistaken but it seems EOL for java 8 is coming soon (2019
> commercial 2020 personal) [1]. This seems to be the case because the new
> LTS is out which is java 11.
>
> Also this new release model from oracle seems to be annoying which is
> pushing developers to adopt the openjdk instead. So I guess the reason for
> the upgrade is to strike two birds with one stone: upgrade java and switch
> to openjdk.
>
> With that being said, I don't have a firm opinion on upgrading and I just
> wanted to highlight things, I leave it to other folks to decide.
>
> [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
>
> On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
> wrote:
>
> > That would probably halt any further contributions from me in the short
> to
> > medium term.
> >
> > Can I ask why we need to require 11 when 8 is supported through to 2023?
> >
> > Regards
> > Scott
> >
> > On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <
> jacques.le.r...@les7arts.com>
> > wrote:
> >
> > > If nobody disagree, I'll make the last move (ie ask for Java 11 in
> > > build.gradle) in 3 days
> > >
> > > Jacques
> > >
> > > Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> > > > On 13/04/2019 11:47, Jacques Le Roux wrote:
> > > >> I just tested, without surprise the trunk HEAD works with Java 11
> > > >
> > > > I did the same with 18.12, works fine
> > > >
> > > > Nicolas
> > > >
> > > >
> > >
> >
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Scott Gray]

That would probably halt any further contributions from me in the short to
medium term.

Can I ask why we need to require 11 when 8 is supported through to 2023?

Regards
Scott

On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, 
wrote:

> If nobody disagree, I'll make the last move (ie ask for Java 11 in
> build.gradle) in 3 days
>
> Jacques
>
> Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> > On 13/04/2019 11:47, Jacques Le Roux wrote:
> >> I just tested, without surprise the trunk HEAD works with Java 11
> >
> > I did the same with 18.12, works fine
> >
> > Nicolas
> >
> >
>

Re: svn commit: r1857084 - /ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java

[Scott Gray]

You'll need to be careful with this one, based on the limited usage of the
iterator here it seems likely that it will be used again later in the
process.

Regards
Scott

On Mon, 8 Apr 2019 at 07:38,  wrote:

> Author: mthl
> Date: Sun Apr  7 19:38:09 2019
> New Revision: 1857084
>
> URL: http://svn.apache.org/viewvc?rev=1857084&view=rev
> Log:
> Fixed: Use try with resource for closing ‘EntityListIterator’
>
> Modified:
>
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java?rev=1857084&r1=1857083&r2=1857084&view=diff
>
> ==
> ---
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/FormRenderer.java
> Sun Apr  7 19:38:09 2019
> @@ -1215,8 +1215,7 @@ public class FormRenderer {
>  }
>  int itemIndex = -1;
>  if (iter instanceof EntityListIterator) {
> -EntityListIterator eli = (EntityListIterator) iter;
> -try {
> +try (EntityListIterator eli = (EntityListIterator) iter) {
>  if(eli.getResultsSizeAfterPartialList() > 0){
>  itemIndex++;
>  }
>
>
>

Re: JobManager/JobPoller issues

[Scott Gray]

Job prioritization is committed in r1857071, thanks everyone who provided
their thoughts.

Regards
Scott

On Sat, 16 Mar 2019, 22:30 Scott Gray,  wrote:

> Patch available at https://issues.apache.org/jira/browse/OFBIZ-10865
>
> Reviews welcome, I probably won't have time to commit it for a few weeks
> so no rush.
>
> By the way I was amazed to notice that jobs are limited to 100 jobs per
> poll with a 30 second poll time, seems extremely conservative.  They would
> have to be very slow jobs to not have the executor be idle most of the
> time.  If no one objects I'd like to increase this to 2000 jobs with a 10
> second poll time.
>
> Thanks
> Scott
>
> On Tue, 26 Feb 2019 at 09:13, Scott Gray 
> wrote:
>
>> Hi Jacques,
>>
>> I'm working on implementing the priority queue approach at the moment for
>> a client.  All things going well it will be in production in a couple of
>> weeks and I'll report back then with a patch.
>>
>> Regards
>> Scott
>>
>> On Tue, 26 Feb 2019 at 03:11, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>> Hi,
>>>
>>> I put this comment there with OFBIZ-10002 trying to document why we have
>>> 5 as hardcoded value of /max-threads/ attribute in /thread-pool/ element
>>> (serviceengine.xml). At this moment Scott already mentioned[1]:
>>>
>>> /Honestly I think the topic is generic enough that OFBiz doesn't
>>> need to provide any information at all. Thread pool sizing is not exclusive
>>> to
>>> OFBiz and it would be strange for anyone to modify the numbers
>>> without first researching sources that provide far more detail than a few
>>> sentences
>>> in our config files will ever cover./
>>>
>>> I agree with Scott and Jacopo that jobs are more likely IO rather than
>>> CPU bounded. So I agree that we should take that into account, change the
>>> current algorithm and remove this somehow misleading comment. Scott's
>>> suggestion in his 2nd email sounds good to me. So If I understood well we
>>> could
>>> use an unbounded but finally limited queue, like it was before.
>>>
>>> Although with all of that said, after a quick second look it appears
>>> that
>>> the current implementation doesn't try poll for more jobs than the
>>> configured limit (minus already queued jobs) so we might be fine
>>> with an
>>> unbounded queue implementation.  We'd just need to alter the call to
>>> JobManager.poll(int limit) to not pass in
>>> executor.getQueue().remainingCapacity() and instead pass in
>>> something like
>>> (threadPool.getJobs() - executor.getQueue().size())
>>>
>>> I'm fine with that as it would continue to prevent hitting physical
>>> limitations and can be tweaked by users as it's now. Note that it seems
>>> though
>>> uneasy to tweak as we received already several "complaints" about it.
>>>
>>> Now one of the advantage of a PriorityBlockingQueue is priority. And to
>>> take advantage of that we can't rely on "/natural ordering"/ and need to
>>> implement Comparable (which does no seem easy). Nicolas provided some
>>> leads below and this should be discussed. The must would be to have that
>>> parametrised, of course.
>>>
>>> My 2 cts
>>> //
>>>
>>> [1] https://markmail.org/message/ixzluzd44rgloa2j
>>>
>>> Jacques
>>>
>>> Le 06/02/2019 à 14:24, Nicolas Malin a écrit :
>>> > Hello Scott,
>>> >
>>> > On a customer project we use massively the job manager with an average
>>> of one hundred thousand job per days.
>>> >
>>> > We have different cases like, huge long jobs, async persistent job,
>>> fast regular job. The mainly problem that we detect has been (as you
>>> notified)
>>> > the long jobs that stuck poller's thread and when we restart OFBiz (we
>>> are on continuous delivery) we hadn't windows this without crash some jobs.
>>> >
>>> > To solve try with Gil to analyze if we can load some weighting on job
>>> definition to help the job manager on what jobs on the pending queue it can
>>> > push on queued queue. We changed own vision to create two pools, one
>>> for system maintenance and huge long jobs managed by two ofbiz instances
>>> and an
>>> > other to manage user activity jobs also man

Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle

[Scott Gray]

I think minor refactors (lots or few is irrelevant) shouldn't need a jira
ticket and aren't worth mentioning in a blog post.  Anything that requires
discussion and/or changes the behavior of the application, the API or
documentation should go through jira.

Regards
Scott

On Thu, 21 Mar 2019 at 10:19, Mathieu Lirzin  wrote:

> Hello Michael,
>
> Michael Brohl  writes:
>
> > don't we have Jira's for all these changes?
> >
> > If yes, please provide the issue number within the commit message so
> > that we have them in the monthly blog post/dev details.
> >
> > If no, we should have them, at least in the future.
>
> Sorry if the process I followed was not the right one.
>
> I must confess that the policy regarding how refactoring (done by
> committers) must be handled in term of JIRA creation, is not clear to
> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
> helping much in that regard.  Maybe there is an implicit consensus in
> that regard that I am not aware of?
>
> My reasoning for not creating a JIRA was that those commits are pure
> refactoring meaning they are implementation details that don't change
> the observable behavior of the build and they are not part of a global
> plan.  Basically those cleanups happened by looking around while working
> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>
> What would you recommend in that scenario?
>
> > If these changes affect the documentation, the README.md should also
> > be edited to reflect them and stay in sync with the code.
>
> Sure I agree that's an important guideline to follow.
>
> Thanks.
>
> [1]
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
> [2] https://issues.apache.org/jira/browse/OFBIZ-10866
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: svn commit: r1855403 - /ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java

[Scott Gray]

Nice one, thanks Swapnil!

Regards
Scott

On Thu, 21 Mar 2019, 01:25 Swapnil M Mane,  wrote:

> Done with the suggested changes Scott.
>
> trunk at rev 1855898
> release18.12 at rev 1855899
> release17.12 at rev 1855900
> release16.11 at rev 1855901
>
> Thanks again for valuable inputs.
>
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Fri, Mar 15, 2019 at 9:52 AM Swapnil M Mane 
> wrote:
>
> > Makes perfect sense, thanks so much for the input Scott.
> > I will do the suggested changes.
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Fri, Mar 15, 2019 at 5:36 AM Scott Gray  >
> > wrote:
> >
> >> Hi Swapnil,
> >>
> >> A minor thing, but I wonder if it would be better to move this check
> >> underneath node.getTextContent()?  If we assume that most nodes will
> >> contain text then it might be more efficient to do a null check after
> >> retrieving nodeValue.
> >>
> >> e.g.
> >> Node node = (Node) obj;
> >> String nodeValue =  node.getTextContent();
> >> if (nodeValue == null) {
> >>   // Check node type and return obj;
> >> }
> >> if ("String".equals(type) || "java.lang.String".equals(type)) {
> >>  return nodeValue;
> >> ...
> >>
> >> Regards
> >> Scott
> >>
> >>
> >> On Thu, 14 Mar 2019, 01:27 ,  wrote:
> >>
> >> > Author: swapnilmmane
> >> > Date: Wed Mar 13 12:27:13 2019
> >> > New Revision: 1855403
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1855403&view=rev
> >> > Log:
> >> > Fixed: simpleTypeConvert always returns Null for Document, Document
> Type
> >> > and Notation Node (OFBIZ-10832)
> >> >
> >> > As per the code, getTextContent() method is used get text content of
> the
> >> > node and its descendants but the node.getTextContent() always return
> >> Null
> >> > for the following Node type
> >> > DOCUMENT_NODE, DOCUMENT_TYPE_NODE, NOTATION_NODE [1]
> >> >
> >> > Since we can't get the text value of Document, Document Type and
> >> Notation
> >> > Node, thus simply return the same object.
> >> >
> >> > [1]
> >> >
> >>
> https://docs.oracle.com/javase/7/docs/api/org/w3c/dom/Node.html#getTextContent()
> >> >
> >> > Thanks: Deepak Dixit for reviewing the code.
> >> >
> >> > Modified:
> >> >
> >> >
> >>
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> >> >
> >> > Modified:
> >> >
> >>
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> >> > URL:
> >> >
> >>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java?rev=1855403&r1=1855402&r2=1855403&view=diff
> >> >
> >> >
> >>
> ==
> >> > ---
> >> >
> >>
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> >> > (original)
> >> > +++
> >> >
> >>
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> >> > Wed Mar 13 12:27:13 2019
> >> > @@ -289,6 +289,17 @@ public class ObjectType {
> >> >  }
> >> >  if (obj instanceof Node) {
> >> >  Node node = (Node) obj;
> >> > +
> >> > +/* We can't get the text value of Document, Document Type
> >> and
> >> > Notation Node,
> >> > + * thus simply returning the same object from
> >> > simpleTypeOrObjectConvert method.
> >> > + * Please refer to OFBIZ-10832 Jira and
> >> > + *
> >> >
> >>
> https://docs.oracle.com/javase/7/docs/api/org/w3c/dom/Node.html#getTextContent()
> >> > for more details.
> >> > + */
> >> > +short nodeType = node.getNodeType();
> >> > +if (Node.DOCUMENT_NODE == nodeType ||
> >> Node.DOCUMENT_TYPE_NODE
> >> > == nodeType || Node.NOTATION_NODE == nodeType) {
> >> > +return obj;
> >> > +}
> >> > +
> >> >  String nodeValue =  node.getTextContent();
> >> >  if ("String".equals(type) ||
> >> "java.lang.String".equals(type))
> >> > {
> >> >  return nodeValue;
> >> >
> >> >
> >> >
> >>
> >
>

Re: JobSandbox temporal expression timezone

[Scott Gray]

Hi Rishi,

Thanks for taking a look!

My only concern with using runAsUser would be that recurring services
typically use the "system" UserLogin and using this approach might require
multiple UserLogin/UserPreference records if there are different recurring
services using different timezones.

Also it should be fine to use RunTime data, as of now I could not see no
> issues with that. The only thing is not possible is if system requires to
> run a service always on specific time zone values and runtime could have
> different values.
>

Yeah I think I don't like the RuntimeData idea after thinking about it, an
opposite use case to my one might cause problems, e.g.:
I want a report to run at midnight UTC every night but I want the
timestamps converted to Pacific Time because that's where my users are so I
would like to use timeZone "America/Los_Angeles" or similar for the service
context.

So I think unless other ideas come along, my preference would be for adding
a new field to JobSandbox.  I'll create a ticket within the next few days
and try to come up with a better field name.  Maybe "recurrenceTimeZone",
seems clear and somewhat concise.

Thanks
Scott

On Tue, 19 Mar 2019 at 22:24, Rishi Solanki  wrote:

> Hello Scott,
> Can we think of using JobSandbox.runAsUser='myuser' and UserPreference.
>
>  userPrefGroupTypeId="GLOBAL_PREFERENCES" userPrefTypeId="defaultTimeZoneId"
> userPrefValue="UTC"/>
>
> Also it should be fine to use RunTime data, as of now I could not see no
> issues with that. The only thing is not possible is if system requires to
> run a service always on specific time zone values and runtime could have
> different values. So having value in database makes sense to me, and okay
> with #1 of having it on JobSandbox level.
>
> I proposed UserPreference so that no field added with possible solution and
> we can achieve it. Could not think of any side effect as of now if we use
> it only for schedule, in case the same can be use for different purpose
> while log in, then it may have several side effects.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems <http://www.hotwaxsystems.com/>
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> Direct: +91-9893287847
>
>
> On Tue, Mar 19, 2019 at 10:56 AM Scott Gray 
> wrote:
>
> > Hi all,
> >
> > Trying to decide on the best way to define a temporal expression for a
> > recurring job where the temporal expression should be evaluated using a
> > timezone other than whatever the default timezone is for the system.
> >
> > Use case is having a system that runs on UTC time, but needs to send a
> > report at 5pm Pacific Time everyday regardless of whether or not daylight
> > savings is in effect.
> >
> > I see two options:
> > 1. Add a field to JobSandbox such as tempExprTzId (or better name!)
> > 2. Use whatever timezone is available in the RunTime data service context
> >
> > #2 seems simplest but I'm not sure if there's scenarios where the service
> > should be run with one timezone while the recurrence should be scheduled
> > based on another?  I can't think of any.
> >
> > Regards
> > Scott
> >
>

JobSandbox temporal expression timezone

[Scott Gray]

Hi all,

Trying to decide on the best way to define a temporal expression for a
recurring job where the temporal expression should be evaluated using a
timezone other than whatever the default timezone is for the system.

Use case is having a system that runs on UTC time, but needs to send a
report at 5pm Pacific Time everyday regardless of whether or not daylight
savings is in effect.

I see two options:
1. Add a field to JobSandbox such as tempExprTzId (or better name!)
2. Use whatever timezone is available in the RunTime data service context

#2 seems simplest but I'm not sure if there's scenarios where the service
should be run with one timezone while the recurrence should be scheduled
based on another?  I can't think of any.

Regards
Scott

Re: JobManager/JobPoller issues

[Scott Gray]

Patch available at https://issues.apache.org/jira/browse/OFBIZ-10865

Reviews welcome, I probably won't have time to commit it for a few weeks so
no rush.

By the way I was amazed to notice that jobs are limited to 100 jobs per
poll with a 30 second poll time, seems extremely conservative.  They would
have to be very slow jobs to not have the executor be idle most of the
time.  If no one objects I'd like to increase this to 2000 jobs with a 10
second poll time.

Thanks
Scott

On Tue, 26 Feb 2019 at 09:13, Scott Gray 
wrote:

> Hi Jacques,
>
> I'm working on implementing the priority queue approach at the moment for
> a client.  All things going well it will be in production in a couple of
> weeks and I'll report back then with a patch.
>
> Regards
> Scott
>
> On Tue, 26 Feb 2019 at 03:11, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi,
>>
>> I put this comment there with OFBIZ-10002 trying to document why we have
>> 5 as hardcoded value of /max-threads/ attribute in /thread-pool/ element
>> (serviceengine.xml). At this moment Scott already mentioned[1]:
>>
>> /Honestly I think the topic is generic enough that OFBiz doesn't need
>> to provide any information at all. Thread pool sizing is not exclusive to
>> OFBiz and it would be strange for anyone to modify the numbers
>> without first researching sources that provide far more detail than a few
>> sentences
>> in our config files will ever cover./
>>
>> I agree with Scott and Jacopo that jobs are more likely IO rather than
>> CPU bounded. So I agree that we should take that into account, change the
>> current algorithm and remove this somehow misleading comment. Scott's
>> suggestion in his 2nd email sounds good to me. So If I understood well we
>> could
>> use an unbounded but finally limited queue, like it was before.
>>
>> Although with all of that said, after a quick second look it appears
>> that
>> the current implementation doesn't try poll for more jobs than the
>> configured limit (minus already queued jobs) so we might be fine with
>> an
>> unbounded queue implementation.  We'd just need to alter the call to
>> JobManager.poll(int limit) to not pass in
>> executor.getQueue().remainingCapacity() and instead pass in something
>> like
>> (threadPool.getJobs() - executor.getQueue().size())
>>
>> I'm fine with that as it would continue to prevent hitting physical
>> limitations and can be tweaked by users as it's now. Note that it seems
>> though
>> uneasy to tweak as we received already several "complaints" about it.
>>
>> Now one of the advantage of a PriorityBlockingQueue is priority. And to
>> take advantage of that we can't rely on "/natural ordering"/ and need to
>> implement Comparable (which does no seem easy). Nicolas provided some
>> leads below and this should be discussed. The must would be to have that
>> parametrised, of course.
>>
>> My 2 cts
>> //
>>
>> [1] https://markmail.org/message/ixzluzd44rgloa2j
>>
>> Jacques
>>
>> Le 06/02/2019 à 14:24, Nicolas Malin a écrit :
>> > Hello Scott,
>> >
>> > On a customer project we use massively the job manager with an average
>> of one hundred thousand job per days.
>> >
>> > We have different cases like, huge long jobs, async persistent job,
>> fast regular job. The mainly problem that we detect has been (as you
>> notified)
>> > the long jobs that stuck poller's thread and when we restart OFBiz (we
>> are on continuous delivery) we hadn't windows this without crash some jobs.
>> >
>> > To solve try with Gil to analyze if we can load some weighting on job
>> definition to help the job manager on what jobs on the pending queue it can
>> > push on queued queue. We changed own vision to create two pools, one
>> for system maintenance and huge long jobs managed by two ofbiz instances
>> and an
>> > other to manage user activity jobs also managed by two instances. We
>> also added on service definition an information to indicate the
>> predilection pool
>> >
>> > This isn't a big deal and not resolve the stuck pool but all blocked
>> jobs aren't vital for daily activity.
>> >
>> > For crashed job, we introduced in trunk service lock that we set before
>> an update and wait a windows for the restart.
>> >
>> > At this time for all OOM detected we reanalyse the origin job and tried
>> to 

Re: svn commit: r1855403 - /ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java

[Scott Gray]

Hi Swapnil,

A minor thing, but I wonder if it would be better to move this check
underneath node.getTextContent()?  If we assume that most nodes will
contain text then it might be more efficient to do a null check after
retrieving nodeValue.

e.g.
Node node = (Node) obj;
String nodeValue =  node.getTextContent();
if (nodeValue == null) {
  // Check node type and return obj;
}
if ("String".equals(type) || "java.lang.String".equals(type)) {
 return nodeValue;
...

Regards
Scott


On Thu, 14 Mar 2019, 01:27 ,  wrote:

> Author: swapnilmmane
> Date: Wed Mar 13 12:27:13 2019
> New Revision: 1855403
>
> URL: http://svn.apache.org/viewvc?rev=1855403&view=rev
> Log:
> Fixed: simpleTypeConvert always returns Null for Document, Document Type
> and Notation Node (OFBIZ-10832)
>
> As per the code, getTextContent() method is used get text content of the
> node and its descendants but the node.getTextContent() always return Null
> for the following Node type
> DOCUMENT_NODE, DOCUMENT_TYPE_NODE, NOTATION_NODE [1]
>
> Since we can't get the text value of Document, Document Type and Notation
> Node, thus simply return the same object.
>
> [1]
> https://docs.oracle.com/javase/7/docs/api/org/w3c/dom/Node.html#getTextContent()
>
> Thanks: Deepak Dixit for reviewing the code.
>
> Modified:
>
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java?rev=1855403&r1=1855402&r2=1855403&view=diff
>
> ==
> ---
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> Wed Mar 13 12:27:13 2019
> @@ -289,6 +289,17 @@ public class ObjectType {
>  }
>  if (obj instanceof Node) {
>  Node node = (Node) obj;
> +
> +/* We can't get the text value of Document, Document Type and
> Notation Node,
> + * thus simply returning the same object from
> simpleTypeOrObjectConvert method.
> + * Please refer to OFBIZ-10832 Jira and
> + *
> https://docs.oracle.com/javase/7/docs/api/org/w3c/dom/Node.html#getTextContent()
> for more details.
> + */
> +short nodeType = node.getNodeType();
> +if (Node.DOCUMENT_NODE == nodeType || Node.DOCUMENT_TYPE_NODE
> == nodeType || Node.NOTATION_NODE == nodeType) {
> +return obj;
> +}
> +
>  String nodeValue =  node.getTextContent();
>  if ("String".equals(type) || "java.lang.String".equals(type))
> {
>  return nodeValue;
>
>
>

Re: Create return till ...

[Scott Gray]

The ability to create a return doesn't necessarily mean that return will be
accepted.  IMO this is a business process where human intervention is
required in order to maintain good customer relations.  Approving/declining
RMAs depend on a number of factors including:
- the reason for return
- length of time since purchase
- value of the purchase
- COGS
- lifetime value of the customer

A hard time limit can make sense when a customer simply changes their mind
about the purchase and wishes to return it but I don't think any other type
of return should be constrained by the system without input from customer
service reps.

IMO a better system would be to have information critical to the RMA
process (such as the items listed above) easily accessible to the CSR so
they can quick make a decision.  Having the system prevent customers from
even creating a return request because X number of days have passed could
well be a bad user experience for the customer.

If the implementation does proceed, I don't think ProductFacility would be
a good place to store the information.  Multiple stores with different
rules could well be fulfilling the same products out of the same warehouse
(particularly for international distribution).

Regards
Scott

On Sat, 9 Mar 2019 at 20:50, Suraj Khurana  wrote:

> Hello,
>
> In OFBiz, we can create a return for order without checking when that order
> is placed, it might be years long.
> IMO, we should have a field something like daysToReturn at product store
> level to allow creating return till after that much days of order
> completion.
>
> I could not find anything else relevant to this and this is a very common
> e-commerce scenario for any business.
>
> Am I missing something?
> Please share your thoughts on the same.
>
> --
> Best Regards
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: +91 9669750002
> email: suraj.khur...@hotwax.co
> www.hotwax.co
>

Re: JobManager/JobPoller issues

[Scott Gray]

Hi Jacques,

I'm working on implementing the priority queue approach at the moment for a
client.  All things going well it will be in production in a couple of
weeks and I'll report back then with a patch.

Regards
Scott

On Tue, 26 Feb 2019 at 03:11, Jacques Le Roux 
wrote:

> Hi,
>
> I put this comment there with OFBIZ-10002 trying to document why we have 5
> as hardcoded value of /max-threads/ attribute in /thread-pool/ element
> (serviceengine.xml). At this moment Scott already mentioned[1]:
>
> /Honestly I think the topic is generic enough that OFBiz doesn't need
> to provide any information at all. Thread pool sizing is not exclusive to
> OFBiz and it would be strange for anyone to modify the numbers without
> first researching sources that provide far more detail than a few sentences
> in our config files will ever cover./
>
> I agree with Scott and Jacopo that jobs are more likely IO rather than CPU
> bounded. So I agree that we should take that into account, change the
> current algorithm and remove this somehow misleading comment. Scott's
> suggestion in his 2nd email sounds good to me. So If I understood well we
> could
> use an unbounded but finally limited queue, like it was before.
>
> Although with all of that said, after a quick second look it appears
> that
> the current implementation doesn't try poll for more jobs than the
> configured limit (minus already queued jobs) so we might be fine with
> an
> unbounded queue implementation.  We'd just need to alter the call to
> JobManager.poll(int limit) to not pass in
> executor.getQueue().remainingCapacity() and instead pass in something
> like
> (threadPool.getJobs() - executor.getQueue().size())
>
> I'm fine with that as it would continue to prevent hitting physical
> limitations and can be tweaked by users as it's now. Note that it seems
> though
> uneasy to tweak as we received already several "complaints" about it.
>
> Now one of the advantage of a PriorityBlockingQueue is priority. And to
> take advantage of that we can't rely on "/natural ordering"/ and need to
> implement Comparable (which does no seem easy). Nicolas provided some
> leads below and this should be discussed. The must would be to have that
> parametrised, of course.
>
> My 2 cts
> //
>
> [1] https://markmail.org/message/ixzluzd44rgloa2j
>
> Jacques
>
> Le 06/02/2019 à 14:24, Nicolas Malin a écrit :
> > Hello Scott,
> >
> > On a customer project we use massively the job manager with an average
> of one hundred thousand job per days.
> >
> > We have different cases like, huge long jobs, async persistent job, fast
> regular job. The mainly problem that we detect has been (as you notified)
> > the long jobs that stuck poller's thread and when we restart OFBiz (we
> are on continuous delivery) we hadn't windows this without crash some jobs.
> >
> > To solve try with Gil to analyze if we can load some weighting on job
> definition to help the job manager on what jobs on the pending queue it can
> > push on queued queue. We changed own vision to create two pools, one for
> system maintenance and huge long jobs managed by two ofbiz instances and an
> > other to manage user activity jobs also managed by two instances. We
> also added on service definition an information to indicate the
> predilection pool
> >
> > This isn't a big deal and not resolve the stuck pool but all blocked
> jobs aren't vital for daily activity.
> >
> > For crashed job, we introduced in trunk service lock that we set before
> an update and wait a windows for the restart.
> >
> > At this time for all OOM detected we reanalyse the origin job and tried
> to decompose it by persistent async service to help loading repartition.
> >
> > If I had more time, I would be oriented job improvement to :
> >
> >  * Define an execution plan rule to link services and poller without
> touch any service definition
> >
> >  * Define configuration by instance for the job vacuum to refine by
> service volumetric
> >
> > This feedback is a little confused Scott, maybe you found interesting
> things
> >
> > Nicolas
> >
> > On 30/01/2019 20:47, Scott Gray wrote:
> >> Hi folks,
> >>
> >> Just jotting down some issues with the JobManager over noticed over the
> >> last few days:
> >> 1. min-threads in serviceengine.xml is never exceeded unless the job
> count
> >> in the queue exceeds 5000 (or whatever is configured).  Is this not
> obvious
> >> to anyone else?  I don't think this was th

Re: sendMail causes NPE (OFBIZ-10706)

[Scott Gray]

Hi Benjamin,

I sent feedback when you asked for it back in December:
https://ofbiz.markmail.org/thread/zgxbefdd2jn3otgk

Regards
Scott

On Sat, 23 Feb 2019 at 05:11, Benjamin Jugl 
wrote:

> Hello fellow developers,
>
> I just checked my open Jira-Issues and look, what I found:
>
> OFBIZ-10706  !
>
> In Short:
> I found an NPE caused by /EmailServices.sendMail/ and provided a Patch
> that expanded the /sendMailOnePartInterface/ to have sendFrom mandatory,
> just as sendTo.
>
> The alternative solution would have been, to catch the NPE and try to
> send the Email without a sendFrom, no matter what.
>
> Jacques Le Roux asked me to ask you, if this change might disrupt custom
> projects of you. So please give me/us notice, if this is the case.
>
>

Re: JobManager/JobPoller issues

[Scott Gray]

Hi Taher,

I say that it isn't a drop-in replacement solely because it is unbounded
whereas the current implementation appears to depend on the queue being
bounded by the number set in the serviceengine.xml thread-pool.jobs
attribute.

The main concern I have about an unbounded queue is the potential for
instability when you have tens or hundreds of thousands of jobs pending.
I'm not sure about the current implementation but I know the previous
implementation had issues if the poll held the lock for too long while
queuing up large numbers of jobs.

Although with all of that said, after a quick second look it appears that
the current implementation doesn't try poll for more jobs than the
configured limit (minus already queued jobs) so we might be fine with an
unbounded queue implementation.  We'd just need to alter the call to
JobManager.poll(int limit) to not pass in
executor.getQueue().remainingCapacity() and instead pass in something like
(threadPool.getJobs() - executor.getQueue().size())

I'll keep pondering other options but a PriorityBlockingQueue might be a
good first step, initially to push PurgeJobs to the back of the queue and
perhaps later ServiceJobs/PersistedServiceJobs can be given a priority via
the LocalDispatcher API.

In regards to OFBIZ-10592, I'd be very surprised if the JobManager itself
was the cause of out of memory errors on a 20GB heap.  It sounds to me like
autoDeleteAutoSaveShoppingList was written expecting a low number of
records to process and it starting hitting transaction timeouts when the
record count got too large, they probably ignored/weren't monitoring those
failures and the load on that specific service continued to grow with each
TTO rollback until now they're finally hitting OOM errors every time it
tries to run.

Regards
Scott



On Mon, 4 Feb 2019 at 09:07, Taher Alkhateeb 
wrote:

> Hi Scott,
>
> It seems we have some issues currently with our job scheduler [1]
> which seems to be some sort of memory leak. We are also experiencing
> some performance issues and other anomalies. It seems like a good time
> to perhaps revisit the whole thing.
>
> Are you suggesting to replace LinkedBlockingQueue with
> PriorityBlockingQueue? If so I think it might actually be a better
> option. I think being unbounded _might_ actually resolve some of the
> pain points we're facing. I didn't get why it's not a drop-in
> replacement though. It matches the signature of the call in the
> executor service unless i'm missing something somewhere?
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-10592
>
> On Wed, Jan 30, 2019 at 10:59 PM Scott Gray
>  wrote:
> >
> > Hi folks,
> >
> > Just jotting down some issues with the JobManager over noticed over the
> > last few days:
> > 1. min-threads in serviceengine.xml is never exceeded unless the job
> count
> > in the queue exceeds 5000 (or whatever is configured).  Is this not
> obvious
> > to anyone else?  I don't think this was the behavior prior to a
> refactoring
> > a few years ago.
> > 2. The advice on the number of threads to use doesn't seem good to me, it
> > assumes your jobs are CPU bound when in my experience they are more
> likely
> > to be I/O bound while making db or external API calls, sending emails
> etc.
> > With the default setup, it only takes two long running jobs to
> effectively
> > block the processing of any others until the queue hits 5000 and the
> other
> > threads are finally opened up.  If you're not quickly maxing out the
> queue
> > then any other jobs are stuck until the slow jobs finally complete.
> > 3. Purging old jobs doesn't seem to be well implemented to me, from what
> > I've seen the system is only capable of clearing a few hundred per minute
> > and if you've filled the queue with them then regular jobs have to queue
> > behind them and can take many minutes to finally be executed.
> >
> > I'm wondering if anyone has experimented with reducing the queue the
> size?
> > I'm considering reducing it to say 100 jobs per thread (along with
> > increasing the thread count).  In theory it would reduce the time real
> jobs
> > have to sit behind PurgeJobs and would also open up additional threads
> for
> > use earlier.
> >
> > Alternatively I've pondered trying a PriorityBlockingQueue for the job
> > queue (unfortunately the implementation is unbounded though so it isn't a
> > drop-in replacement) so that PurgeJobs always sit at the back of the
> > queue.  It might also allow prioritizing certain "user facing" jobs (such
> > as asynchronous data imports) over lower priority less time critical
> jobs.
> > Maybe another option (or in conjunction) is some sort of "swim-lane"
> > queue/executor that allocates jobs to threads based on prior execution
> > speed so that slow running jobs can never use up all threads and block
> > faster jobs.
> >
> > Any thoughts/experiences you have to share would be appreciated.
> >
> > Thanks
> > Scott
>

JobManager/JobPoller issues

[Scott Gray]

Hi folks,

Just jotting down some issues with the JobManager over noticed over the
last few days:
1. min-threads in serviceengine.xml is never exceeded unless the job count
in the queue exceeds 5000 (or whatever is configured).  Is this not obvious
to anyone else?  I don't think this was the behavior prior to a refactoring
a few years ago.
2. The advice on the number of threads to use doesn't seem good to me, it
assumes your jobs are CPU bound when in my experience they are more likely
to be I/O bound while making db or external API calls, sending emails etc.
With the default setup, it only takes two long running jobs to effectively
block the processing of any others until the queue hits 5000 and the other
threads are finally opened up.  If you're not quickly maxing out the queue
then any other jobs are stuck until the slow jobs finally complete.
3. Purging old jobs doesn't seem to be well implemented to me, from what
I've seen the system is only capable of clearing a few hundred per minute
and if you've filled the queue with them then regular jobs have to queue
behind them and can take many minutes to finally be executed.

I'm wondering if anyone has experimented with reducing the queue the size?
I'm considering reducing it to say 100 jobs per thread (along with
increasing the thread count).  In theory it would reduce the time real jobs
have to sit behind PurgeJobs and would also open up additional threads for
use earlier.

Alternatively I've pondered trying a PriorityBlockingQueue for the job
queue (unfortunately the implementation is unbounded though so it isn't a
drop-in replacement) so that PurgeJobs always sit at the back of the
queue.  It might also allow prioritizing certain "user facing" jobs (such
as asynchronous data imports) over lower priority less time critical jobs.
Maybe another option (or in conjunction) is some sort of "swim-lane"
queue/executor that allocates jobs to threads based on prior execution
speed so that slow running jobs can never use up all threads and block
faster jobs.

Any thoughts/experiences you have to share would be appreciated.

Thanks
Scott

Re: OFBiz shell

[Scott Gray]

Hi Mathieu,

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Attic#OFBizAttic-GroovyShell
might be of interest to you.

Regards
Scott

On Sun, 13 Jan 2019, 07:14 Mathieu Lirzin  Hello,
>
> One issue with the current way of writing Groovy tests is that the
> feedback between writing an instruction and checking its result is slow
> because one has to rerun the corresponding test case.
>
> Providing a Groovy shell access with a delegator and dispatcher allows
> developers to interactively execute commands and check their results
> instantly.
>
> I have implemented such feature in OFBIZ-10805 [1] which might be
> interested to follow/review for those who care about interactive
> development.
>
> Thanks.
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-10805
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: EmailServices.sendMail causes a NPE, when sendFrom is missing

[Scott Gray]

Hi Benjamin,

If I were to place a bet, I would say that the system used to provide a
default email address and that code has disappeared for some reason. It
might pay to look at the history of the service and try to determine why it
changed or if it was always broken.

FWIW I always try and look into the history of bugs before fixing them to
better understand the context of how the problem arose.

Regards
Scott

On Fri, 14 Dec 2018, 21:49 Benjamin Jugl  Hello all,
>
> at the moment an NPE can be thrown by sending an Email (via the service
> "sendMail" without giving a value for "sendFrom".
>
> I provided a patch for this in OFBIZ-10706
> . This simply alters
> the service configuration, so that sendFrom is no longer optional.
>
> Since this might interfere with some of your customer projects and the
> usage of sendMail therein, please give me some feedback, if this patch
> is in your interest.
>
> Best wishes, Benjamin
>
>
>

Re: [PROPOSAL] Short Messaging Service(SMS) Gateway Integration

[Scott Gray]

One thing to consider, is it better to have a single table for configuring
communication content generation or multiple?

i.e. would it be better to have a single ProductStoreCommunicationSetting
table instead of ProductStoreEmailSetting and ProductStoreSmsSetting (or
whatever name has been decided).

I don't have a design to propose and haven't read the design for SMS, but I
noticed the table name debate in this thread and it led me to asking the
question.

Regards
Scott

On Mon, 26 Nov 2018 at 03:50, Pritam Kute 
wrote:

> Thanks Pierre and Rishi.
>
> Let's wait for some more days to listen to the feedback from the community
> as it is the first pass of the feature. As per feedback, we can do the
> final improvements and then we can decide how to make it available for the
> community as early as possible.
>
> Thanks and Regards
> --
> Pritam Kute
>
>
> On Sat, Nov 24, 2018 at 7:23 PM Pierre Smits 
> wrote:
>
> > Hi Pritam,
> >
> > Thank you for your initiative to enhance OFBiz with a new pluggable
> > feature. Is there somewhere a Git or SVN repo where the code can be
> pulled
> > from? It might take a long time before this will be part of the code
> base,
> > and (potential) OFBiz adopters might miss (or forget) all the activities
> in
> > JIRA or postings in MLs.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >
> > On Sat, Nov 24, 2018 at 10:38 AM Pritam Kute <
> > pritam.k...@hotwaxsystems.com>
> > wrote:
> >
> > > Thanks all for your inputs.
> > >
> > > I have updated the first pass of the implementation on the ticket [1].
> > >
> > > Request all to have a look and provide feedback.
> > >
> > > [1]: https://issues.apache.org/jira/browse/OFBIZ-10457
> > >
> > > Thanks
> > > --
> > > Pritam Kute
> > >
> > > On Fri, Aug 24, 2018 at 2:12 AM Nicolas Malin <
> nicolas.ma...@nereide.fr>
> > > wrote:
> > >
> > > > Hello Pritam,
> > > >
> > > > Maybe I arrived after the war still I wish sharing my opinion :)
> > > >
> > > > General term Sms seems to be too specific, I would've oriented on
> > > > TelecomGateway
> > > >
> > > > * ProductStoreTelecomGatewaySetting (too long :))
> > > > * TelecomGatewayConfig
> > > > * TelecomGatewayConfigType, and so on
> > > >
> > > > For the attributes :
> > > > * configId is too generic and already use on productConfig entity.
> It's
> > > > preferable to have unique name in OFBiz as primaryKey (same for
> > > settingId)
> > > > * parentSmsConfigTypeId need to rename on parentTypeId if you want to
> > > > follow EntityType pattern.
> > > >
> > > > Why set the purpose (smsTypeId) on SmsTemplateSetting instead of on
> > > > ProductStoreSmsSetting where the template application will be done ?
> > > >
> > > > What do you imagine behind the CustomMethod linked to
> > SmsTemplateSetting
> > > ?
> > > >
> > > > That's all I'll stop bothering you :)
> > > >
> > > > Cheers,
> > > >
> > > > Nicolas
> > > >
> > > > On 02/07/2018 11:22, Pritam Kute wrote:
> > > > > Hello Devs,
> > > > >
> > > > > Sorry for such a long delay.
> > > > >
> > > > > Thanks, Michael for your inputs. I have added design proposal for
> the
> > > SMS
> > > > > gateway integration and can be accessed here
> > > > > :
> > > > > https://cwiki.apache.org/confluence/x/Zgo0BQ
> > > > >
> > > > > Please go through the design and let me know if there are any
> > > questions,
> > > > > suggestions or improvements which we can do.
> > > > >
> > > > > Thanks to Devanshu Vyas and Aishwary Shrivastava for helping me
> with
> > > the
> > > > > design and documentation.
> > > > >
> > > > > Thanks and Regards
> > > > > --
> > > > > Pritam Kute
> > > > >
> > > > > On Sun, Sep 10, 2017 at 4:33 PM Michael Brohl <
> > > michael.br...@ecomify.de>
> > > > > wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> Looking forward to the design proposal.
> > > > >>
> > > > >> You can use the wiki with a new page under
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Requirements+and+Design+Proposals
> > > > >> to provide the details and support collaboration.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Michael
> > > > >>
> > > > >> Am 26.08.17 um 13:31 schrieb Pritam Kute:
> > > > >>> Hi Devs,
> > > > >>>
> > > > >>> Many e-commerce businesses (especially operating in Asian
> > countries)
> > > > >>> nowadays use short messaging service (SMS) in mobile phones to
> > notify
> > > > and
> > > > >>> update customers about order details, shipment statuses etc.
> > > > >>>
> > > > >>> I would like to propose an SMS Gateway Integration in Ofbiz. I
> will
> > > > share
> > > > >>> proposed desig

Re: Using alternate dispatcher and delegator for integration tests

[Scott Gray]

The use of separate individual dispatchers/delegators per test suite was
introduced at the same time as the delegator rollback/reset code, and was
intended to allow for test suites to be run (and data to be reset) in
parallel.

The test framework never sees much love though so that never happened. It's
difficult to accomplish because many test suites rely on the same
underlying demo data.

I don't mind either way, just thought the history lesson might be helpful.

https://issues.apache.org/jira/browse/OFBIZ-2259
https://markmail.org/thread/zjghmk25bllthxme

Regards
Scott

On Sat, 27 Oct 2018, 22:59 Taher Alkhateeb, 
wrote:

> Ahh, Now I understand what you mean by looking at your patch. I
> recommend next time that you copy-paste into the email thread because
> people who try to access this thread using the ML archives might not
> see your attachments.
>
> At a first glance, although this feature is not used in the current
> OFBiz code base. it _might_ be used by some users who are running
> certain tests against specific tenants for example. So although I
> would probably lean towards removing it, I'd recommend making sure
> that not many people depend on this feature. Perhaps you can check in
> the user ML or wait for others to share their opinions.
> On Sun, Oct 21, 2018 at 10:51 PM Mathieu Lirzin
>  wrote:
> >
> > Hello Taher,
> >
> > Taher Alkhateeb  writes:
> >
> > > An example could shed some light here perhaps?
> >
> > What kind of examples would help you?
> >
> > AIUI It would be for the people using this feature outside of the
> > framework to provide examples why we should keep it in.
> >
> > > What do you want to remove from where?
> >
> > Here is what I precisely want to remove.
> >
> >
> > > How is it complex?
> >
> > Basically each time an option is provided it adds complexity.  In this
> > particular case, perhaps a comparaison between the two models of test
> > execution can help describing the added complexity:
> >
> > Current model:
> >1. Launch OFBiz
> >2. Fetch all the tests from the components
> >3. Keep track which delegator/dispatcher correspond to each test suite
> >4. Run each test by setting its corresponding delegator/dispatcher
> >
> > Model without option:
> >1. Launch OFBiz with the test delegator/dispatcher
> >2. Fetch all the tests from the components
> >3. Run the tests.
> >
> > Does it help?
> >
> > --
> > Mathieu Lirzin
> > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: Upgrading the Authorize.net AIM API

[Scott Gray]

Maybe, but I see no reason to have an architecture discussion as a
prerequisite for a simple API update.

Regards
Scott

On Tue, 25 Sep 2018, 06:03 Jacques Le Roux, 
wrote:

> I guess Pierre is referring to
> https://markmail.org/message/zf5tz7qpgokldvtl and above...
>
> Jacques
>
>
> Le 22/09/2018 à 14:12, Pierre Smits a écrit :
> > I believe first the discussion on how we’re going to deal with these kind
> > of 3rd party solution integrations, whether they be fintech, logistic or
> > other,  should be completed first.
> >
> > Many times aspects regarding this has been brought forward in other
> threads
> > and in tickets.
> >
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> > On Sat, Sep 22, 2018 at 1:39 PM, Nameet Jain  wrote:
> >
> >> Hello Team,
> >>
> >> While researching around Advanced Integration Method (AIM) Authorize.net
> >> API, I found that the AIM API has now been deprecated. Authorize.net
> >> suggest upgrading the AIM support to XML or JSON based support. Please
> let
> >> me know your thoughts.
> >>
> >> Here is the link for your reference
> >> https://developer.authorize.net/api/upgrade_guide/
> >> https://developer.authorize.net/api/reference/index.html
> >>
> >> Thanks
> >> --
> >> Regards,
> >> Nameet Jain
> >>
>
>

Re: ProductFacility creation on 'Receive Inventory'

[Scott Gray]

Sounds like there are 3 options available:
1. Improve any view/report screens to not rely on ProductFacility but
instead report on what is actually in the warehouse via InventoryItem.
2. Require ProductFacility but silently create it when it is absent
3. Require ProductFacility and reject receipt of products when it is absent

My first thought is that if ProductFacility were truly required then we
would have a foreign key constraint on InventoryItem to prevent them from
being created.  So I'm guessing the original intent wasn't to require a
ProductFacility record.

IMO we should first look to improving the view/report screens to not
require ProductFacility, if that is not possible or overly complicated then
we could look at requiring ProductFacility.  If we wanted to require
ProductFacility in order to enforce business rules, then that should
probably be configurable.

Regards
Scott

On 19 September 2018 at 10:49, Deepak Nigam 
wrote:

> Thanks, Suraj.
>
> @All, as per the suggestions provided in the Jira ticket, should we
> restrict the receiving of non-associated products and simply return an
> error message? WDYT?
>
> On Wed, Sep 19, 2018 at 2:45 PM Suraj Khurana <
> suraj.khur...@hotwaxsystems.com> wrote:
>
> > Hello Deepak,
> >
> > Please have a look.
> > https://issues.apache.org/jira/browse/OFBIZ-7481
> >
> > HTH.
> >
> > --
> > Thanks and Regards,
> > Suraj Khurana
> > Omnichannel OMS Technical Expert
> > HotWax Systems
> >
> >
> >
> > On Wed, Sep 19, 2018 at 2:38 PM, deepak nigam <
> deepak.nigam1...@gmail.com>
> > wrote:
> >
> > > Hello All,
> > >
> > > We can directly receive inventory of a product into a facility by using
> > the
> > > option 'Facility' -> 'Receive Inventory'. Here we can select a product
> > for
> > > receiving which is not associated with the receiving facility (e.g.
> > product
> > > -> Purple Gizmo GZ-5005, facility -> WebS Store Warehouse).
> > >
> > > After a successful receive also, the product is not getting associated
> > with
> > > the facility. Due to this, we can't find the newly received product
> under
> > > the 'Inventory' section of the facility. Should the product be
> associated
> > > with the facility after receiving?
> > >
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Nigam
> > >
> >
>

Re: HTTP Compression not working for some files (JS and CSS)

[Scott Gray]

See the note under the compression config here:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation

Regards
Scott


On 20 August 2018 at 07:38, girish.vasmat...@hotwaxsystems.com <
girish.vasmat...@hotwaxsystems.com> wrote:

>
>
> On 2018/08/20 07:20:38, Michael Brohl  wrote:
> > Hi Girish,
> >
> > how did you check that these files are not getting compressed before the
> > transfer?
> >
> > They are decompressed by the browser after the transfer so you won't see
> > that they were compressed.
> >
> > Regards,
> >
> > Michael
> >
> >
> > Am 20.08.18 um 09:12 schrieb girish.vasmat...@hotwaxsystems.com:
> > > Hi Devs!!!
> > >
> > > I see that we have enabled HTTP compression in in the HTTP and HTTPS
> connectors, but I am observing that it is not working properly for some of
> the JS and CSS files.
> > >
> > > All medium to large files (more than 50 KB or so) are not getting
> compressed. Has anyone else observed the same? I can definitely see that
> Content-Encoding:gzip response header is set for all the files that are
> compressed and the transfer size does indicate they were compressed based
> on what size I see on the disk.
> > >
> > >
> > > Thanks,
> > > Girish Vasmatkar
> > > HotWax Systems
> > >
> >
> >
> >
> Hi Michael
>
> I can see the response headers in Chrome developers tools. For some files
> for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was
> compressed by the server and received in compressed format.
> For the other ones, no Content-Encoding header is present. Also, there is
> a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79
> KB values respectively. For select2-4.0.6.js which is one of the one I
> don't see come compressed the corresponding values are 143.01 KB and 142.80
> KB and the Content-Encoding header is also absent.
>
> Thanks and Regards,
> Girish Vasmatkar
> HotWax Systems
>
>
>

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Scott Gray]

Hi Jacques,

Assuming I was looking at the correct patch, it looks like I could use this
feature to login as anyone.  All I need to do is send any userLoginId to
getJwtToken and then I can login as that user with the token that comes
back.  Am I missing something?

Regards
Scott

On 15 August 2018 at 07:08, Jacques Le Roux 
wrote:

> Hi,
>
> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>
> I asked for reviews but only Taher answered and he asked to know the goal
> of this new feature.
>
> It was actually developed for a client who needed to get from one OFBiz
> instance on a server (on a domain) to another OFBiz instance on another
> server (on another domain) without having to sign up between the 2 while
> keeping things secure.
>
> There could be many reasons why you want to split OFBiz application on
> servers. In their case it was for performance issues.
>
> The technology used is as secure as possible. Like OAuth 2.0 it uses a
> token but it does not need a middle authorization server (think to
> two-factor authentication) because it's only for OFBiz instances of the
> same version.
>
> To commit this work we need 1st to agree an commit the work done by Deepak
> at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>
> For me there is only one question outstanding: how to store the Token
> secret. But this should not prevent us to commit Deepak's work.
>
> It's now a long time (9 months) since I started this work. And my last
> patch is ready for a month.
>
> I crossed several issues which are now all resolved. So please review and
> answer to this thread.
>
> Without negative comments well argumented I'll commit both OFBIZ-9833 and
> OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>
> Also a veto on a commit is always possible... Of course, as ever, a good
> consensus is preferred.
>
> Let me know if you need more information about the goal. For the technical
> details I think I already provided them the in OFBIZ-10307.
>
> Jacques
>
>

Re: svn commit: r1813640 - in /ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity: GenericDelegator.java GenericEntity.java GenericPK.java GenericValue.java

[Scott Gray]

Thanks Michael!

On Fri, 27 Jul 2018, 08:48 Michael Brohl,  wrote:

> Hi Scott,
>
> thanks for spotting this, I will fix it!
>
> Regards,
>
> Michael
>
>
> Am 26.07.18 um 23:40 schrieb Scott Gray:
> > FYI, I think this commit accidentally introduced a weird import into
> > GenericPK:
> > import org.apache.sis.internal.jdk7.Objects
> >
> > probably intended to be java.util.Objects
> >
> > Regards
> > Scott
> >
> > On 28 October 2017 at 15:19,  wrote:
> >
> >> Author: mbrohl
> >> Date: Sat Oct 28 15:19:56 2017
> >> New Revision: 1813640
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1813640&view=rev
> >> Log:
> >> Improved: Fixing defects reported by FindBugs, package
> >> org.apache.ofbiz.entity.
> >> (OFBIZ-9716)
> >>
> >> I modified the patch slightly.
> >>
> >> Thanks Julian Leichert for reporting and providing the patch.
> >>
> >> Modified:
> >>  ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericDelegator.java
> >>  ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericEntity.java
> >>  ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericPK.java
> >>  ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericValue.java
> >>
> >> Modified: ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericDelegator.java
> >> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> >> framework/entity/src/main/java/org/apache/ofbiz/entity/
> >> GenericDelegator.java?rev=1813640&r1=1813639&r2=1813640&view=diff
> >> 
> >> ==
> >> --- ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericDelegator.java (original)
> >> +++ ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> >> java/org/apache/ofbiz/entity/GenericDelegator.java Sat Oct 28 15:19:56
> >> 2017
> >> @@ -114,9 +114,9 @@ public class GenericDelegator implements
> >>   protected EntityCrypto crypto = null;
> >>
> >>   /** A ThreadLocal variable to allow other methods to specify a
> user
> >> identifier (usually the userLoginId, though technically the Entity
> Engine
> >> doesn't know anything about the UserLogin entity) */
> >> -protected static ThreadLocal> userIdentifierStack =
> new
> >> ThreadLocal>();
> >> +private static final ThreadLocal> userIdentifierStack
> =
> >> new ThreadLocal>();
> >>   /** A ThreadLocal variable to allow other methods to specify a
> >> session identifier (usually the visitId, though technically the Entity
> >> Engine doesn't know anything about the Visit entity) */
> >> -protected static ThreadLocal> sessionIdentifierStack =
> >> new ThreadLocal>();
> >> +private static final ThreadLocal>
> sessionIdentifierStack
> >> = new ThreadLocal>();
> >>
> >>   private boolean testMode = false;
> >>   private boolean testRollbackInProgress = false;
> >> @@ -786,7 +786,7 @@ public class GenericDelegator implements
> >>   value.setDelegator(this);
> >>
> >>   // if audit log on for any fields, save new value with no
> old
> >> value because it's a create
> >> -if (value != null &&
> value.getModelEntity().getHasFieldWithAuditLog())
> >> {
> >> +if (value.getModelEntity().getHasFieldWithAuditLog()) {
> >>   createEntityAuditLogAll(value, false, false);
> >>   }
> >>
> >> @@ -796,7 +796,7 @@ public class GenericDelegator implements
> >>   if (testMode) {
> >>   storeForTestRollback(new
> TestOperation(OperationType.INSERT,
> >> value));
> >>   }
> >> -} catch (GenericEntityException e) {
> >> +} catch (IllegalStateException | GenericEntityException e)
> {
> >>   // see if this was caused by an existing record before
> >> resetting the sequencer and trying again
> >>   // NOTE: use the helper directly so ECA rules,

Re: ‘MapStack’ weirdness.

[Scott Gray]

I looked back through an old copy of the pre-ASF repo and found that the
"context" references were added in 2006 and it had something to do with
making MapStack a LocalizedMap for screen/form widget internalization
rendering.  The commit message and a small explanation in the mailing lists
didn't explain that specific addition unfortunately.  Could be that it
isn't used there anymore, at the time freemarker macros weren't used for
widget rendering, so it's possible that a fix in the freemarker render
could remove the need for it.

Regards
Scott

On 21 July 2018 at 17:12, Mathieu Lirzin  wrote:

> Hello Scott,
>
> Scott Gray  writes:
>
> > I think it relates to the "context" variable that is frequently used in
> > groovy data prep scripts for the script output.
> >
> > I'm not in front of a computer, but looking at it in that light may help.
>
> As shown by this snippet from ‘GroovyUtil.java’, the “context” binding
> is added explicitly so it doesn't require the ‘MapStack’ special case
> for the "context" key.  In fact since the context is copied to an
> ‘HashMap’ before being passed to Groovy, the ‘MapStack’ implementation
> is not used at all from Groovy.
>
> --8<---cut here---start->8---
> public static Binding getBinding(Map context, String
> expression) {
> Map vars = new HashMap<>();
> if (context != null) {
> vars.putAll(context);
> if (UtilValidate.isNotEmpty(expression)) {
>   ...;
> }
> vars.put("context", context);
> ...;
> }
> return new Binding(vars);
> }
>
> public static Object runScriptAtLocation(String location, String
> methodName, Map context) throws GeneralException {
> Script script = InvokerHelper.createScript(
> getScriptClassFromLocation(location), getBinding(context));
> Object result = null;
> if (UtilValidate.isEmpty(methodName)) {
> result = script.run();
> } else {
> result = script.invokeMethod(methodName, new Object[] {
> context });
> }
> return result;
> }
> --8<---cut here---end--->8---
>
> What is nice is that the ‘getBinding’ method has a javadoc explaining
> why the “context” binding is added explicitly.  Thanks to Adrian Crum
> (RIP) for providing it.
>
> --8<---cut here---start->8---
> The ‘context’ Map is added to the ‘Binding’ as a variable called
> "context" so that variables can be passed back to the caller.
> --8<---cut here---end--->8---
>
> Thanks for your input.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: svn commit: r1813640 - in /ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity: GenericDelegator.java GenericEntity.java GenericPK.java GenericValue.java

[Scott Gray]

FYI, I think this commit accidentally introduced a weird import into
GenericPK:
import org.apache.sis.internal.jdk7.Objects

probably intended to be java.util.Objects

Regards
Scott

On 28 October 2017 at 15:19,  wrote:

> Author: mbrohl
> Date: Sat Oct 28 15:19:56 2017
> New Revision: 1813640
>
> URL: http://svn.apache.org/viewvc?rev=1813640&view=rev
> Log:
> Improved: Fixing defects reported by FindBugs, package
> org.apache.ofbiz.entity.
> (OFBIZ-9716)
>
> I modified the patch slightly.
>
> Thanks Julian Leichert for reporting and providing the patch.
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericEntity.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericPK.java
> ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericValue.java
>
> Modified: ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> framework/entity/src/main/java/org/apache/ofbiz/entity/
> GenericDelegator.java?rev=1813640&r1=1813639&r2=1813640&view=diff
> 
> ==
> --- ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java (original)
> +++ ofbiz/ofbiz-framework/trunk/framework/entity/src/main/
> java/org/apache/ofbiz/entity/GenericDelegator.java Sat Oct 28 15:19:56
> 2017
> @@ -114,9 +114,9 @@ public class GenericDelegator implements
>  protected EntityCrypto crypto = null;
>
>  /** A ThreadLocal variable to allow other methods to specify a user
> identifier (usually the userLoginId, though technically the Entity Engine
> doesn't know anything about the UserLogin entity) */
> -protected static ThreadLocal> userIdentifierStack = new
> ThreadLocal>();
> +private static final ThreadLocal> userIdentifierStack =
> new ThreadLocal>();
>  /** A ThreadLocal variable to allow other methods to specify a
> session identifier (usually the visitId, though technically the Entity
> Engine doesn't know anything about the Visit entity) */
> -protected static ThreadLocal> sessionIdentifierStack =
> new ThreadLocal>();
> +private static final ThreadLocal> sessionIdentifierStack
> = new ThreadLocal>();
>
>  private boolean testMode = false;
>  private boolean testRollbackInProgress = false;
> @@ -786,7 +786,7 @@ public class GenericDelegator implements
>  value.setDelegator(this);
>
>  // if audit log on for any fields, save new value with no old
> value because it's a create
> -if (value != null && 
> value.getModelEntity().getHasFieldWithAuditLog())
> {
> +if (value.getModelEntity().getHasFieldWithAuditLog()) {
>  createEntityAuditLogAll(value, false, false);
>  }
>
> @@ -796,7 +796,7 @@ public class GenericDelegator implements
>  if (testMode) {
>  storeForTestRollback(new 
> TestOperation(OperationType.INSERT,
> value));
>  }
> -} catch (GenericEntityException e) {
> +} catch (IllegalStateException | GenericEntityException e) {
>  // see if this was caused by an existing record before
> resetting the sequencer and trying again
>  // NOTE: use the helper directly so ECA rules, etc won't
> be run
>
> @@ -843,7 +843,7 @@ public class GenericDelegator implements
>
>  TransactionUtil.commit(beganTransaction);
>  return value;
> -} catch (Exception e) {
> +} catch (GenericEntityException e) {
>  String entityName = value != null ? value.getEntityName() :
> "invalid Generic Value";
>  String errMsg = "Failure in createSetNextSeqId operation for
> entity [" + entityName + "]: " + e.toString() + ". Rolling back
> transaction.";
>  Debug.logError(e, errMsg, module);
> @@ -877,7 +877,7 @@ public class GenericDelegator implements
>  value.setDelegator(this);
>
>  // if audit log on for any fields, save new value with no old
> value because it's a create
> -if (value != null && 
> value.getModelEntity().getHasFieldWithAuditLog())
> {
> +if (value.getModelEntity().getHasFieldWithAuditLog()) {
>  createEntityAuditLogAll(value, false, false);
>  }
>
> @@ -900,7 +900,7 @@ public class GenericDelegator implements
>
>  TransactionUtil.commit(beganTransaction);
>  return value;
> -} catch (Exception e) {
> +} catch (IllegalStateException | GenericEntityException e) {
>  String errMsg = "Failure in create operation for entity [" +
> (value != null

Re: ‘MapStack’ weirdness.

[Scott Gray]

I think it relates to the "context" variable that is frequently used in
groovy data prep scripts for the script output.

I'm not in front of a computer, but looking at it in that light may help.

Regards
Scott

On Thu, 19 Jul 2018, 09:24 Taher Alkhateeb, 
wrote:

> I didn't get into it before, but my first gut reaction is .. delete
> that thing! :)
>
> Anyway, it seems to have to many references, so I would advise
> investigating how it is constructed to understand what is being pulled
> in. Just begin from the container loader and work your way down with a
> debugger until you hit exactly the reason why this check was in place.
>
> I find this code a bit ugly, and I'd rather get rid of it if doesn't
> add any value (and I think it doesn't)
>
> On Wed, Jul 18, 2018 at 6:53 PM, Mathieu Lirzin
>  wrote:
> > Hello,
> >
> > ‘MapStack’ is a specialization of the ‘MapContext’ class which is an
> > implementation of ‘Map’ interface that has the particularity to store
> > its key-values in separate sub-maps that can mask each others.
> >
> > The whole point of ‘MapStack’ implementation is to override the Map
> > accessors to ensure that the key "context" is associated with ‘this’
> > meaning the ‘MapStack’ instance.
> >
> > --8<---cut here---start->8---
> > @Override
> > public Object get(Object key) {
> > if ("context".equals(key)) {
> > return this;
> > }
> > return super.get(key);
> > }
> >
> > @Override
> > public Object get(String name, Locale locale) {
> > if ("context".equals(name)) {
> > return this;
> > }
> > return super.get(name, locale);
> > }
> >
> > @Override
> > public Object put(K key, Object value) {
> > if ("context".equals(key)) {
> > if (value == null || this != value) {
> > Debug.logWarning("Putting a value in a MapStack with key
> [context] that is not this MapStack, will be hidden by the current MapStack
> self-reference: " + value, module);
> > }
> > }
> > return super.put(key, value);
> > }
> > --8<---cut here---end--->8---
> >
> > I don't understand the purpose of such thing.  So if someone has some
> > rationale to share, I would be grateful.
> >
> > Thanks.
> >
> > --
> > Mathieu Lirzin
> > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: License issue with iText 4.2.0

[Scott Gray]

Are there any genuine doubts about 2.1.7?  Or just a warning from the
company trying to sell the AGL licensed versions?

If we revert back to 2.1.7 then I don't think we need to ask legal anything.

Regards
Scott

On 14 June 2018 at 18:56, Jacques Le Roux 
wrote:

> Le 14/06/2018 à 07:22, Scott Gray a écrit :
>
>> My first inclination is that taking legal advice from a company that is
>> trying to sell you a license, probably isn't a good idea.  They have a
>> vested interest in trying to convince you not to use the MIT version.
>>
>> Regardless, I think Taher's solution works in the short term
>>
> For that I think we need to ask Legal. Anyway better to ask them for both
> versions (2.1.7 or 4.2.0)
>
> and the other
>> alternative is to revert back to a 2.x version until a suitable
>> replacement
>> is found.
>>
> Why a replacement would be needed?
>
> Looking at the commit logs it hasn't been very long since we
>> switched from 2.x to 4.x for no other reason than "let's update
>> everything!".
>>
> Right, I believe using 2.1.7 is the way. We were using it until Oct 13
> 2017, r1812161.
> It's the same than in BIRT distributed runtime packages and I expect
> Eclipse Legal team is aware. Certainly a reason why they never updated.
>
> So the question for our Legal could as simple as:
>
> 1. Eclipse BIRT distributes itext 2.1.7 in their runtime packages under
> the EPL license.
> 2. We want to use the same directly as a declared dependency
> 3. But we wonder what to think about https://developers.itextpdf.co
> m/question/versions-older-than-5
>
> @team: what do you think? I'd not even ask for 4.2.0 because I expect a
> negative answer. But if you prefer we can add it.
>
> Should we say that we use the 2.1.7 version for years?
>
> Jacques
>
>
>
>> Regards
>> Scott
>>
>> On 14 June 2018 at 05:47, Jacques Le Roux 
>> wrote:
>>
>> Hi Jacopo,
>>>
>>> Yes good idea. I'll try to write next week...
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 13/06/2018 à 08:14, Jacopo Cappellato a écrit :
>>>
>>> On Tue, Jun 12, 2018 at 11:47 PM, Jacques Le Roux <
>>>> jacques.le.r...@les7arts.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>> Of course we need to ask the legal team before taking a formal decision
>>>>> about it.
>>>>> I think we have now enough material to ask, and without opposition I'll
>>>>> create a LEGAL Jira in a week.
>>>>>
>>>>> I think it would be useful if you will post the draft of the text for
>>>> the
>>>> Jira ticket to this list for community's review before submitting it to
>>>> Legal.
>>>>
>>>> Thank you,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>

Re: License issue with iText 4.2.0

[Scott Gray]

My first inclination is that taking legal advice from a company that is
trying to sell you a license, probably isn't a good idea.  They have a
vested interest in trying to convince you not to use the MIT version.

Regardless, I think Taher's solution works in the short term and the other
alternative is to revert back to a 2.x version until a suitable replacement
is found.  Looking at the commit logs it hasn't been very long since we
switched from 2.x to 4.x for no other reason than "let's update
everything!".

Regards
Scott

On 14 June 2018 at 05:47, Jacques Le Roux 
wrote:

> Hi Jacopo,
>
> Yes good idea. I'll try to write next week...
>
> Jacques
>
>
>
> Le 13/06/2018 à 08:14, Jacopo Cappellato a écrit :
>
>> On Tue, Jun 12, 2018 at 11:47 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> [...]
>>> Of course we need to ask the legal team before taking a formal decision
>>> about it.
>>> I think we have now enough material to ask, and without opposition I'll
>>> create a LEGAL Jira in a week.
>>>
>>
>> I think it would be useful if you will post the draft of the text for the
>> Jira ticket to this list for community's review before submitting it to
>> Legal.
>>
>> Thank you,
>>
>> Jacopo
>>
>>
>

Re: License issue with iText 4.2.0

[Scott Gray]

Thanks Taher! Perfect simple solution.

Regards
Scott

On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb, 
wrote:

> So we exclude the transitive dependency in build.gradle and if everything
> works then we're fine.
>
> Syntax:
>
> compile('com.lowagie:itext:4.2.0') {
> exclude 'com.itextpdf:itextpdf:5.5.6'
> }
>
> On Fri, Jun 8, 2018, 11:40 AM Scott Gray 
> wrote:
>
> > Hey Jacques,
> >
> > Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
> 4.2.0,
> > does it make sense?
> >
> > Regards
> > Scott
> >
> >
> > On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,  >
> > wrote:
> >
> > > I suggest this comment, a Jira seems appropriate
> > >
> > > -compile 'com.lowagie:itext:4.2.0'
> > > +compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because of
> > > license change
> > >
> > > Jacques
> > >
> > >
> > > Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
> > > > Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
> > > >> Hi Scott,
> > > >>
> > > >> Reading Wikipedia It's OK as long as we don't update to a version
> >= 5
> > > https://en.wikipedia.org/wiki/IText
> > > > Here is another source for MPL licensing:
> > > https://www.eclipse.org/forums/index.php/t/175386/
> > > >
> > > >> < > > Mozilla Public License <
> > > https://en.wikipedia.org/wiki/Mozilla_Public_License>
> > > >> or the GNU Library General Public License <
> > > https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open
> source
> > > licenses. However, as of version
> > > >> 5.0.0 (released Dec 7, 2009) it is distributed under the Affero
> > General
> > > Public License
> > > >> <https://en.wikipedia.org/wiki/Affero_General_Public_License>
> version
> > > 3.>>
> > > >>
> > > >> MPL being OK as binary
> > > >>
> > > >> Jacques
> > > >>
> > > >> Le 08/06/2018 à 03:57, Scott Gray a écrit :
> > > >>> Hi All,
> > > >>>
> > > >>> I just noticed that the iText maven bundle is a bit tricksy and
> > > includes
> > > >>> iText 5.6.6 as a dependency, with the latter being GPL licensed.
> You
> > > can
> > > >>> see it by running "./gradlew -q dependencies":
> > > >>> +--- com.lowagie:itext:4.2.0
> > > >>> |\--- com.itextpdf:itextpdf:5.5.6
> > > >>>
> > > >>> I haven't checked to see if the later version is actually used by
> our
> > > code
> > > >>> and I'm not sure if merely downloading it causes licensing issues,
> > but
> > > I
> > > >>> thought I'd bring the question here in case anyone else has already
> > > looked
> > > >>> into it.  Not sure what the work-around would be if it is an issue.
> > > >>>
> > > >>> Regards
> > > >>> Scott
> > > >>>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
>

Re: License issue with iText 4.2.0

[Scott Gray]

Hey Jacques,

Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of 4.2.0,
does it make sense?

Regards
Scott


On Fri, 8 Jun 2018, 19:30 Jacques Le Roux, 
wrote:

> I suggest this comment, a Jira seems appropriate
>
> -compile 'com.lowagie:itext:4.2.0'
> +compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because of
> license change
>
> Jacques
>
>
> Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
> > Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
> >> Hi Scott,
> >>
> >> Reading Wikipedia It's OK as long as we don't update to a version >= 5
> https://en.wikipedia.org/wiki/IText
> > Here is another source for MPL licensing:
> https://www.eclipse.org/forums/index.php/t/175386/
> >
> >> < Mozilla Public License <
> https://en.wikipedia.org/wiki/Mozilla_Public_License>
> >> or the GNU Library General Public License <
> https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open source
> licenses. However, as of version
> >> 5.0.0 (released Dec 7, 2009) it is distributed under the Affero General
> Public License
> >> <https://en.wikipedia.org/wiki/Affero_General_Public_License> version
> 3.>>
> >>
> >> MPL being OK as binary
> >>
> >> Jacques
> >>
> >> Le 08/06/2018 à 03:57, Scott Gray a écrit :
> >>> Hi All,
> >>>
> >>> I just noticed that the iText maven bundle is a bit tricksy and
> includes
> >>> iText 5.6.6 as a dependency, with the latter being GPL licensed.  You
> can
> >>> see it by running "./gradlew -q dependencies":
> >>> +--- com.lowagie:itext:4.2.0
> >>> |\--- com.itextpdf:itextpdf:5.5.6
> >>>
> >>> I haven't checked to see if the later version is actually used by our
> code
> >>> and I'm not sure if merely downloading it causes licensing issues, but
> I
> >>> thought I'd bring the question here in case anyone else has already
> looked
> >>> into it.  Not sure what the work-around would be if it is an issue.
> >>>
> >>> Regards
> >>> Scott
> >>>
> >>
> >>
> >
> >
>
>

License issue with iText 4.2.0

[Scott Gray]

Hi All,

I just noticed that the iText maven bundle is a bit tricksy and includes
iText 5.6.6 as a dependency, with the latter being GPL licensed.  You can
see it by running "./gradlew -q dependencies":
+--- com.lowagie:itext:4.2.0
|\--- com.itextpdf:itextpdf:5.5.6

I haven't checked to see if the later version is actually used by our code
and I'm not sure if merely downloading it causes licensing issues, but I
thought I'd bring the question here in case anyone else has already looked
into it.  Not sure what the work-around would be if it is an issue.

Regards
Scott

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Scott Gray]

Hi Taher,

I'm simply saying that if we were to provide a complete suite web APIs to
access the full functionality of ofbiz, then the project's choice of UI
technology no longer matters so much in the grand scheme of things. No one
would be forced to live by our choice of UI frameworks because they could
build anything they liked using the APIs without ever touching the
server-side code.

Right now our data gathering logic is tightly coupled to our UI,
inaccessible to other servers and apps, the vast majority of our services
are built to be run internally by ofbiz.  Without heavy modification of the
server side code, I can't build a custom SPA, I can't send orders to ofbiz
from another application, I can't really do anything without interacting
with the OFBiz UI.

The majority of the client projects I've worked on always involve a
completely custom UI and with web APIs I could pick up any flavor of the
month UI framework to build it with.

All I'm trying to add to this conversation is that it would be nice if any
UI overhaul started with making APIs available that could be used both by
our framework of choice and be externally accessible to anyone else's
framework of choice.

Regards
Scott


On Tue, 15 May 2018, 20:27 Taher Alkhateeb, 
wrote:

> Hi Scott,
>
> Again thank you for the input, intriguing. I'm not sure if I fully
> understand though. Are you saying we can introduce web services that can
> sort of do away with the widget system to code directly in html and weaving
> in web service calls? How does that make coding faster? What is inefficient
> in the widget system? What kind of architecture should we have in place?
> What is the routing workflow that you're suggesting?
>
> I would appreciate a bit more elaboration to get a better understanding of
> your point of view since this seems to be a critical architectural
> decision.
>
>
> On Mon, May 14, 2018, 9:39 PM Scott Gray 
> wrote:
>
> > On Mon, 14 May 2018, 20:38 Taher Alkhateeb, 
> > wrote:
> >
> > > Hello Scott, thank you for your thoughts, inline ...
> > >
> > > On Mon, May 14, 2018 at 10:45 AM, Scott Gray
> > >  wrote:
> > > > I think no matter what we use someone will always want something
> > > different.
> > > > I'm beginning to lose count of the number of custom APIs I've written
> > > over
> > > > the years to support custom UIs.
> > > >
> > > > I think the bigger win would be to start providing APIs and rewriting
> > our
> > > > existing screens to use them. From there we could start looking at
> new
> > UI
> > > > frameworks.
> > >
> > > Do you mean by APIs rewriting our XSD files and model objects? Why
> > > rewrite? Why not just enhance them for new / missing functionality?
> > > What are the flaws you'd like to redesign?
> > >
> >
> > No, I'm talking about web services. With well designed web services
> custom
> > projects would be able to build out new user interfaces in a lot less
> time
> > and we'd be able to poc new interfaces for the community project without
> > even touching the existing codebase.
> >
> >
> > >
> > > >
> > > > Most of the projects I've worked on have needed huge amounts of UI
> > > > customization and having prebuilt APIs would have reduced the
> workload
> > > much
> > > > more than having a shinier UI that still needs to be completely
> > > rewritten,
> > > > although I'll admit the latter would probably help the sales process.
> > >
> > > The "shiny" part is a plus, but not the core of my suggestion. The
> > > reasons I suggested these libraries are:
> > > - bootstrap: the grid system, this is the cake for me. You have a
> > > powerful responsive grid system for better layouts. The buttons,
> > > tables and other bling bling are icing on the cake.
> > > - Vue: The core of this technology is to allow binding of your context
> > > model to the DOM so that you don't write oodles of JavaScript and
> > > Jquery to create dynamic behavior. It's really old school in 2018 to
> > > keep jumping between many pages to get something done.
> > >
> > > >
> > > > Does it not worry anyone else that our service engine still only
> > defines
> > > a
> > > > basic map for in/out parameters when the rest of the world is using
> the
> > > > likes of swagger and restful APIs?
> > >
> > > Of course it worries me, and if yo

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Scott Gray]

On Mon, 14 May 2018, 20:38 Taher Alkhateeb, 
wrote:

> Hello Scott, thank you for your thoughts, inline ...
>
> On Mon, May 14, 2018 at 10:45 AM, Scott Gray
>  wrote:
> > I think no matter what we use someone will always want something
> different.
> > I'm beginning to lose count of the number of custom APIs I've written
> over
> > the years to support custom UIs.
> >
> > I think the bigger win would be to start providing APIs and rewriting our
> > existing screens to use them. From there we could start looking at new UI
> > frameworks.
>
> Do you mean by APIs rewriting our XSD files and model objects? Why
> rewrite? Why not just enhance them for new / missing functionality?
> What are the flaws you'd like to redesign?
>

No, I'm talking about web services. With well designed web services custom
projects would be able to build out new user interfaces in a lot less time
and we'd be able to poc new interfaces for the community project without
even touching the existing codebase.


>
> >
> > Most of the projects I've worked on have needed huge amounts of UI
> > customization and having prebuilt APIs would have reduced the workload
> much
> > more than having a shinier UI that still needs to be completely
> rewritten,
> > although I'll admit the latter would probably help the sales process.
>
> The "shiny" part is a plus, but not the core of my suggestion. The
> reasons I suggested these libraries are:
> - bootstrap: the grid system, this is the cake for me. You have a
> powerful responsive grid system for better layouts. The buttons,
> tables and other bling bling are icing on the cake.
> - Vue: The core of this technology is to allow binding of your context
> model to the DOM so that you don't write oodles of JavaScript and
> Jquery to create dynamic behavior. It's really old school in 2018 to
> keep jumping between many pages to get something done.
>
> >
> > Does it not worry anyone else that our service engine still only defines
> a
> > basic map for in/out parameters when the rest of the world is using the
> > likes of swagger and restful APIs?
>
> Of course it worries me, and if you start an initiative I will be the
> first to jump in and volunteer. In fact it's on my todo list, and I
> was looking at multiple options lately and I'm very attracted to
> GraphQL for example because of the reduced visits to the backend.
> However, I don't see this as being related to my proposal here, I'm
> just setting my own priorities of what to work on next. What's wrong
> with starting _both_ initiatives for that matter?
>

Nothing is wrong with both, but as you pointed out many discussions and
efforts have begun and then floundered. I'm simply offering some thoughts
on where I see the most potential benefit from a large scale effort.


>
> >
> > Regards
> > Scott
> >
> > On Sun, 13 May 2018, 06:03 Taher Alkhateeb, 
> > wrote:
> >
> >> Hello Everyone,
> >>
> >> Recently, we at Pythys had some interactions with clients, and the
> >> user interface proved to be a sour point. It is functioning well, but
> >> looks too classic, too rigid, too 2000s really :) We had many
> >> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
> >> [8] [9] [10] just to name a few all of which seemed not to follow
> >> through.
> >>
> >> So what is the problem? Why is this hard to get right? I'm not sure I
> >> have the magic answer, but it seems to me like part of the problem is
> >> simply .. TOO BIG
> >>
> >> So I was thinking about a possible solution, and after some initial
> >> research, I think maybe the solution (like everything else) needs to
> >> be slow, incremental and evolutionary rather than revolutionary. So I
> >> am suggesting the following ideas to try and move forward:
> >>
> >> - We include the assets for Bootstrap in the common theme. Bootstrap
> >> will give us the Grid system which allows for a responsive website
> >> that works on all devices, it will also give us beautiful widgets to
> >> work with.
> >> - We include Vue.js assets in the common theme. Vue.js is an excellent
> >> framework for creating Single Page Applications (SPAs) to give dynamic
> >> behavior to our pages and create ajax-heavy pages
> >> - We slowly migrate our old CSS to bootstrap constructs. We can begin
> >> for example by replacing our menus, then tables, then headers, then
> >> buttons etc ..
> >> - We slowly introduce dynamic screens 

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Scott Gray]

I think no matter what we use someone will always want something different.
I'm beginning to lose count of the number of custom APIs I've written over
the years to support custom UIs.

I think the bigger win would be to start providing APIs and rewriting our
existing screens to use them. From there we could start looking at new UI
frameworks.

Most of the projects I've worked on have needed huge amounts of UI
customization and having prebuilt APIs would have reduced the workload much
more than having a shinier UI that still needs to be completely rewritten,
although I'll admit the latter would probably help the sales process.

Does it not worry anyone else that our service engine still only defines a
basic map for in/out parameters when the rest of the world is using the
likes of swagger and restful APIs?

Regards
Scott

On Sun, 13 May 2018, 06:03 Taher Alkhateeb, 
wrote:

> Hello Everyone,
>
> Recently, we at Pythys had some interactions with clients, and the
> user interface proved to be a sour point. It is functioning well, but
> looks too classic, too rigid, too 2000s really :) We had many
> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
> [8] [9] [10] just to name a few all of which seemed not to follow
> through.
>
> So what is the problem? Why is this hard to get right? I'm not sure I
> have the magic answer, but it seems to me like part of the problem is
> simply .. TOO BIG
>
> So I was thinking about a possible solution, and after some initial
> research, I think maybe the solution (like everything else) needs to
> be slow, incremental and evolutionary rather than revolutionary. So I
> am suggesting the following ideas to try and move forward:
>
> - We include the assets for Bootstrap in the common theme. Bootstrap
> will give us the Grid system which allows for a responsive website
> that works on all devices, it will also give us beautiful widgets to
> work with.
> - We include Vue.js assets in the common theme. Vue.js is an excellent
> framework for creating Single Page Applications (SPAs) to give dynamic
> behavior to our pages and create ajax-heavy pages
> - We slowly migrate our old CSS to bootstrap constructs. We can begin
> for example by replacing our menus, then tables, then headers, then
> buttons etc ..
> - We slowly introduce dynamic screens using controller logic in Vue.js
> - We slowly update our macro library to migrate to the above mentioned
> libraries and widgets
> - We do all of this live in Trunk, without branching. This means that
> for some period of time, there will be transitional code (a little bit
> of bootstrap and a little bit of our current code)
>
> We can start with an initial proof of concept skeleton, and if that
> gets consensus, then we can move forward with a full implementation in
> trunk. I think this issue is many years over due. Our interface looks
> oold and really needs a face lift.
>
> What do you think? Ideas? Suggestions?
>
> [1] https://s.apache.org/rf94
> [2] https://s.apache.org/g5zr
> [3] https://s.apache.org/XpBO
> [4] https://s.apache.org/YIL1
> [5] https://s.apache.org/836D
> [6] https://s.apache.org/DhyB
> [7] https://s.apache.org/Lv9E
> [8] https://s.apache.org/zKIo
> [9] https://s.apache.org/D6jx
> [10] https://issues.apache.org/jira/browse/OFBIZ-5840
>

Re: [Proposal] Make accounting entry configurable

[Scott Gray]

Another additional option we could consider at some point is to extract the
GL out to it's own component. It would simplify evaluation for people who
do want to use it, and removal for that don't or replacement for anyone who
wants to use something else.

Regards
Scott

On Thu, 3 May 2018, 18:12 Aman Agrawal, 
wrote:

> Hello,
>
> In current flow, if we want to disable the accounting then we need to
> disable the set of seca's. We don't have any configurable setting to
> disable accounting.
> So, I have a proposal to make accounting transaction entries configurable.
> We can manage this by adding a new field 'enableAccounting' in the
> 'PartyAcctgPreference' entity. Accounting transaction entries will be
> entertained accordingly.
>
> Thanks and regards,
> *Aman Agrawal*
> Sr. Enterprise Software Engineer
> www.hotwaxsystems.com
> www.hotwax.co
>

Re: svn commit: r1830236 - /ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml

[Scott Gray]

Hi Jacques,

A job won't even be marked as crashed until the restart. The crashed status
is a record of what happened, done in the same breath as rescheduling the
job. So if you see a crashed job in your db, then it has already been dealt
with.

Regards
Scott

On Mon, 30 Apr 2018, 21:55 Jacques Le Roux, 
wrote:

> Hi Scott, Gil,
>
> If I understand well, OOTB crashed jobs are only restarted at startup. So
> maybe adding a link to manually restart them any time makes sense?
>
> Jacques
>
>
> Le 27/04/2018 à 07:48, Gil Portenseigne a écrit :
> > Hello Scott,
> >
> > Thanks for the review and the pointer to reloadCrashedJobs.
> > I decided to add a manual way to reset a crashed job since we met, in
> one of our
> > implementation, the issue that the crashed job wasn't rescheduled.
> > Since only a basic menu was missing to offer a way to reset it, i guess
> it was
> > no harm to commit it into trunk...
> >
> > I will look for an explanation of our issue soon, to check if there is
> > something to fix.
> >
> > Now that I understand better the crashed job mechanism, i'll revert this
> > commit.
> >
> > Regards,
> >
> > Gil
> >
> >
> > Le jeudi 26 avril 2018 à 19:33:48 (+), Scott Gray a écrit :
> >> Hi Gil,
> >>
> >> Maybe I'm missing something but crashed jobs are reset at the same time
> >> that they're marked as crashed (during startup). I don't have the latest
> >> code in front of me but it used to be in JobManager.reloadCrashedJobs().
> >> Basically when an instance restarts, any jobs marked as running are
> moved
> >> to crashed and a new job is created to replace it.
> >>
> >> If that isn't happening for you then that's the problem that needs
> fixing.
> >> I'd suggest reverting this commit.
> >>
> >> Regards
> >> Scott
> >>
> >>
> >>
> >> On Fri, 27 Apr 2018, 03:27 ,  wrote:
> >>
> >>> Author: pgil
> >>> Date: Thu Apr 26 15:27:50 2018
> >>> New Revision: 1830236
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1830236&view=rev
> >>> Log:
> >>> Implemented: Add a link onto a crashed Job to reset it
> >>> (OFBIZ-10371)
> >>>
> >>> Modified:
> >>>
> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> >>>
> >>> Modified:
> >>> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> >>> URL:
> >>>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml?rev=1830236&r1=1830235&r2=1830236&view=diff
> >>>
> >>>
> ==
> >>> ---
> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> >>> (original)
> >>> +++
> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> >>> Thu Apr 26 15:27:50 2018
> >>> @@ -105,6 +105,11 @@ under the License.
> >>>   
> >>>   
> >>>   
> >>> + >>> use-when="'SERVICE_CRASHED'.equals(statusId)"
> widget-style="buttontext">
> >>> + >>> description="${uiLabelMap.WebtoolsResetJob}" target="resetJob">
> >>> +
> >>> +
> >>> +
> >>>   
> >>>   
> >>>>>> default-field-type="display"/>
> >>>
> >>>
> >>>
>
>

Re: svn commit: r1830236 - /ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml

[Scott Gray]

Hi Gil,

Maybe I'm missing something but crashed jobs are reset at the same time
that they're marked as crashed (during startup). I don't have the latest
code in front of me but it used to be in JobManager.reloadCrashedJobs().
Basically when an instance restarts, any jobs marked as running are moved
to crashed and a new job is created to replace it.

If that isn't happening for you then that's the problem that needs fixing.
I'd suggest reverting this commit.

Regards
Scott



On Fri, 27 Apr 2018, 03:27 ,  wrote:

> Author: pgil
> Date: Thu Apr 26 15:27:50 2018
> New Revision: 1830236
>
> URL: http://svn.apache.org/viewvc?rev=1830236&view=rev
> Log:
> Implemented: Add a link onto a crashed Job to reset it
> (OFBIZ-10371)
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml?rev=1830236&r1=1830235&r2=1830236&view=diff
>
> ==
> --- ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> (original)
> +++ ofbiz/ofbiz-framework/trunk/framework/webtools/widget/ServiceForms.xml
> Thu Apr 26 15:27:50 2018
> @@ -105,6 +105,11 @@ under the License.
>  
>  
>  
> + use-when="'SERVICE_CRASHED'.equals(statusId)" widget-style="buttontext">
> + description="${uiLabelMap.WebtoolsResetJob}" target="resetJob">
> +
> +
> +
>  
>  
>   default-field-type="display"/>
>
>
>

Re: Confusing entity names

[Scott Gray]

Just to throw in my 2 cents, I don't think the naming is so confusing that
it warrants changing.  The number of replies in this thread highlights that
it isn't a straightforward thing to change, and personally I don't think
the names are so bad that it's worth any of the pain that might come from
changing them.

IMO "OrderShipGroup" could just as easily imply a group of orders that
should be shipped together as though they were a single order.  So to me,
"OrderItemShipGroup" does make some sense for the parent entity.

The child entity is a bit trickier, because "OrderItemShipGroupOrderItem"
is terrible so I guess that's why "Assoc" was chosen as the suffix.
"OrderItemShipGroupItem" could work but it's not much better than "Assoc".

Sometime's names aren't perfect, but they're usually close enough that it
doesn't matter very much.

Regards
Scott


On 10 April 2018 at 23:24, Suraj Khurana 
wrote:

> Hello,
>
> There are some entities which could be renamed as per their usage.
>
>- *OrderItemShipGroup*: It shows order ship groups and it doesn't
>contain anything at order item level. So, it could be re-named as
>*OrderShipGroup.*
>- *OrderItemShipGroupAssoc: *It do not maintain any association type, it
>just contains order item with respect to ship group, so this could be
>re-named as *OrderItemShipGroup *to maintain consistency and code
>readablity.
>
> I know that these entities are crucial part of OOTB data model since
> inception. Having thought in mind that 'Naming should be self explanatory',
> this is a proposal and It would be great to hear communities thought on
> this topic.
>
> Please share your opinions on this.
>
> --
>
> Thanks and Regards,
> *Suraj Khurana* | Omni-channel OMS Technical Expert
> *HotWax Commerce*  by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
> Cell phone: +91 96697-50002
>

Re: Check for only QOH while doing reservations

[Scott Gray]

Hi Suraj,

I haven't reviewed the code in question so I don't have any comment at this
stage. But one thing I want to point out is that OFBiz has many years of
history available in commit logs, jira and mailing lists. It's often quite
a simple task to look back over that history and determine why a certain
thing was done a certain way.

As part of proposing a change to existing functionality it is extremely
useful to anyone who might review the proposal to have some of that context
provided with the proposal.

In this case it could be a simple matter of a past mistake being overlooked
until now, or it could be that using QOH was found to be beneficial for
some reason that isn't immediately obvious. But without first researching,
we can't ever be sure of the answer.

Regards
Scott

On Fri, 6 Apr 2018, 18:25 Suraj Khurana, 
wrote:

> Hello,
>
> While checking around code around inventory reservations, I was surprised
> to see that *reserveProductInventory *service only checks for QOH quantity
> greater than one apart from that when *reserveFromInventoryItemInline *is
> called, it checks for ATP confirming system to behave as required.
>
> Everything works fine but this is redundant code and we can have check for
> ATP at top level so make reservations logic works faster. Is there any
> other specific case I am missing or we can improve this flow by adding ATP
> check at *reserveProductInventory* service as well.
>
> We can check QOH being on safer side, but ideally a system will always have
> lesser ATP than QOH and logically we should only check for ATP while doing
> reservations.
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Omni-channel OMS Technical Expert
> HotWax Commerce  by  HotWax Systems
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>

Re: Deprecate properties in favour of SystemProperties

[Scott Gray]

My understanding is that Jacques is essentially proposing that:
- Properties should either exist in the db or in files but not both
- System configuration properties should go in files (I assume everything
that isn't applicable to multi-tenanting)
- Everything else should go to the db

If properties are only expected to exist in one of the two places, then the
fallback behavior discussion becomes obsolete.

Hope that helps.  Jacques, sorry if I've misunderstood anything, please
feel free to clarify.

Regards
Scott

On 5 April 2018 at 07:26, Taher Alkhateeb 
wrote:

> There is no need to copy paste! I already read the jira and expressed my
> confusion which is still the case. Your text is long and talks about many
> things and does not provide a concrete proposal or a patch.
>
> What do you want to do? Rename system properties? Move properties? What are
> they? Create tenant readers? Do further analysis? What is the proposal? And
> why is the design discussion in a JIRA and not here?
>
> On Thu, Apr 5, 2018, 9:34 AM Jacques Le Roux  >
> wrote:
>
> > OK, here is a copy of my comment in OFBIZ-7112
> >
> > It's a long time now we have the SystemProperty entity. It was a good
> > idea, that we spoke about <https://markmail.org/message/gdcefnghjtezyn4b
> >
> > even
> > <https://markmail.org/message/gdcefnghjtezyn4b> longer ago <
> > https://markmail.org/message/gdcefnghjtezyn4b> before it was implemented
> > <http://svn.apache.org/viewvc?view=revision&revision=1238998>. I believe
> > it's a good idea but there are 2 flaws in the current implementation.
> >
> > When we discussed about it before the implementation, it was clear that
> > only business (ie not system) properties should be concerned
> > <http://example.com/>. To be clear, for me the system properties are the
> > properties in files at
> > framework/start/src/main/java/org/apache/ofbiz/base/start and some other
> > files like freemarkerTransforms.properties, fop.properties,
> > catalina.properties, debug.properties, owasp.properties,
> > security.properties, requestHandler.properties, url.properties and maybe
> > some others I missed
> >
> >  1. So the 1st flaw was to name this entity SystemProperty. It should
> have
> > been named BusinessProperty. We could consider rename it, but that's
> minor
> > in comparison with the second flaw
> >  2. The second flaw is that we kept the business properties files. To
> > avoid duplication and confusion all the business properties should be in
> the
> > database and a specific UI should be created to easier handled them.
> >
> > We should also remember that when the idea was 1st expressed and
> discussed
> > there were no tenants in OFBiz (introduced in 2010). With now tenants,
> > having business properties in data base is necessary and (almost?) all
> > business properties should be shareable by tenants (to be checked).
> >
> > That's why I suggested to Deprecate properties in favour of
> > SystemProperties <https://markmail.org/message/md6fuoouan377c6w>. I also
> > suggested to have
> > specific multitenant and multitenant-initial readers <
> > https://markmail.org/message/opldepaevls3y3ob> for business properties
> to
> > separate those from
> > other data. One thing I did not check yet is if the data I then called
> > "only for tenants" are the business properties; and those which are not
> are
> > system properties. A deeper analysis is required but the idea seems to
> fit.
> >
> >
> > 
> 
> --
> >
> > TL;DR: We will not resolve the SystemProperties issues w/o no longer
> using
> > properties files but for the system properties. Of course then renaming
> the
> > SystemProperty entity to BusinessProperty is necessary. Having a specific
> > UI for DB access for these properties is also necessary. I foresee the
> > webtools as the best place for this UI. It should be accessible by
> tenants.
> >
> > And to finish the reason why I want to keep Wai's work, is sometimes you
> > need to annul a property. In this case the best way to do it in DB is how
> > Wai
> > implemented it, so it should not be removed. Rather the duplicated
> > properties in files should be removed and replaced by properties in DB
> only.
> >
> > Jacques
> >
> >
> > Le 05/04/2018 à 07:42, Scott Gray a écrit :
> > > If there's an ongoing discuss

Re: Deprecate properties in favour of SystemProperties

[Scott Gray]

If there's an ongoing discussion on the dev list then I don't think it's a
good idea to try to move it to jira until there's some consensus on the
path forward.

Regards
Scott

On 4 April 2018 at 10:14, Taher Alkhateeb 
wrote:

> I am a little lost in this JIRA and cannot follow the discussion. Can
> you please point to what you want to review with others exactly?
>
> On Wed, Apr 4, 2018 at 9:46 AM, Jacques Le Roux
>  wrote:
> > Le 03/04/2018 à 09:16, Jacques Le Roux a écrit :
> >>
> >> I suggest to continue the discussion at
> >> https://issues.apache.org/jira/browse/OFBIZ-7112 where I have
> completed my
> >> proposition
> >
> > Since there were some more comments after is al link to my comment with
> my
> > completed my proposition https://s.apache.org/7uwl
> >
> > Jacques
> >
>

Re: why some fields are set to enable-audit-log true by default?

[Scott Gray]

It would be good to leave it on somewhere in the system like the example
entities maybe

On Wed, 4 Apr 2018, 22:13 Jacques Le Roux, 
wrote:

> Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
> > I'm not sure about the field in the entity component though! it
> > might be needed in some unit tests?
> Yes
>
> Jacques
>
>

Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml

[Scott Gray]

Yeah, I said exactly that elsewhere in the same email.

Regards
Scott

On 26 March 2018 at 21:17, Jacques Le Roux 
wrote:

> Le 24/03/2018 à 18:49, Scott Gray a écrit :
>
>> I'm also not even sure if our custom ObjectType methods for checking this
>> type of thing are necessary any more with so many new java versions since
>> it was decided these were needed for performance reasons.
>>
> We would need some profiling before making any decision, don't you think
> so?
>
> Jacques
>
>

Fwd: [jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity with additional elements

[Scott Gray]

Similar to the discussion around design review for Tomcat SSO, here is
another example below, admittedly it is 2 years old now but I'm only just
seeing it because I'm now using a newer version for work.

IMO it's absolutely critical that any non-minor framework or data model
changes are discussed in the dev mailing list.  It's also absolutely
critical that issues raised in review are discussed rather than ignored,
nothing should ever be committed when the only reviews are doubtful ones.

Regards
Scott

-- Forwarded message ------
From: Scott Gray (JIRA) 
Date: 26 March 2018 at 02:20
Subject: [jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity
with additional elements
To: notificati...@ofbiz.apache.org



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

Scott Gray commented on OFBIZ-6882:
---

I'm surprised you went with houseNumber [~jacques.le.roux]

What if the address is for an office or a warehouse?  Even with review and
doubts from others on some of these fields you still went ahead without
question or even engaging in the discussion. The houseNumber name is poorly
chosen, and Pierre provided no justification for the municipalityGeoId
field.

This wasn't good committer behavior.

> Extend the PostalAddress entity with additional elements
> 
>
> Key: OFBIZ-6882
> URL: https://issues.apache.org/jira/browse/OFBIZ-6882
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>  Labels: 3rdParty, Shipment, integration
> Fix For: 16.11.01
>
> Attachments: OFBIZ-6882-party-PostalAddress.patch
>
>
> Various modern day 3rd party delivery solutions (e.g. PostNL in The
Netherlands) require that elements are delivered separately, so that
addresses can be checked more easily.
> Current definition of the PostalAddress doesn't have separation of:
> * street name
> * house number
> * house number addition or extension



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml

[Scott Gray]

Another option if we don't want to have to care about this service engine
limitation right now is the type-validation child element of attribute.

Just specify a class/method that takes the HttpServletRequest as an Object
parameter and then perform the "getAllInterfaces()" test inside there.
e.g.
UtilValidate.isHttpServletRequest(Object request) {
  // do the new test here
}

In the service definition:

  


That would solve the problem for now until the service engine is improved
and tested or the tomcat SSO login design is improved.

Regards
Scott

On 24 March 2018 at 17:49, Scott Gray  wrote:

> So to summarize your long email ;-)
>
> "The service engine has a limitation in that it only checks the interfaces
> directly implemented by the object being tested.  Tomcat's RequestFacade
> doesn't directly implement javax.servlet.http.HttpServletRequest so it
> fails to pass the type validation."
>
> On the surface your suggested fix looks fine to me, my only concern being
> that we may need to do some performance testing.  For every service that
> specifies an interface we'll now be checking the full type hierarchy which
> I imagine will be more expensive but I'm not sure how expensive.
>
> I'm also not even sure if our custom ObjectType methods for checking this
> type of thing are necessary any more with so many new java versions since
> it was decided these were needed for performance reasons.
>
> Regards
> Scott
>
> On 24 March 2018 at 10:59, Jacques Le Roux 
> wrote:
>
>> Le 23/03/2018 à 17:09, Scott Gray a écrit :
>>
>>> I don't need to try anything, I *know* that the service engine is
>>> supposed
>>> to accept a concrete class of an interface if the interface is specified
>>> as
>>> the attribute type.
>>>
>>> Either the service engine is broken by not accepting concrete
>>> implementations, or the bug report is incorrect.
>>>
>> Neither, it's "unfortunate", and a bit complicated.
>>
>> Tomcat servlet4preview was introduced with Tomcat 8.5
>> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata
>> lina/servlet4preview/package-summary.html
>>
>> Before James introduced Tomcat SSO, we had only one service passing a
>> javax.servlet.http.HttpServletRequest to a service: payPalCheckoutUpdate.
>>
>> AFAIK, we have actually always passed a 
>> org.apache.catalina.connector.RequestFacade
>> to services when asking for javax.servlet.http.HttpServletRequest in
>> services definition.
>> Since Tomcat 8.5 RequestFacade implements 
>> javax.servlet.http.HttpServletRequest
>> indirectly through org.apache.catalina.servlet4pr
>> eview.http.HttpServletRequest
>> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata
>> lina/connector/RequestFacade.html
>>
>> Since we have no tests on the payPalCheckoutUpdate service we did not
>> spot that Tomcat servlet4preview was introduced with Tomcat 8.5
>>
>> The classes check is done by the deeper interfaceOf() method of the
>> ObjectType class using Class.getInterfaces()
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Class.ht
>> ml#getInterfaces--
>> Class.getInterfaces() does not recurse and stops at one level up. So in
>> case of RequestFacade it returns only servlet4preview.http.HttpServletRequest
>> and not javax.servlet.http.HttpServletRequest
>> So when interfaceOf() compares the Classes it fails.
>>
>> What happened with my introduction of the HttpServletRequestWrapper in
>> ContextFilter is it hid the RequestFacade because HttpServletRequestWrapper
>> implements javax.servlet.http.HttpServletRequest
>> https://docs.oracle.com/javaee/7/api/javax/servlet/http/Http
>> ServletRequest.html
>>
>> So when James introduced Tomcat SSO and optionally passed a
>> javax.servlet.http.HttpServletRequest to the userLogin service it did
>> not break.
>> But when I removed HttpServletRequestWrapper from ContextFilter it popped
>> up
>>
>> Summary: it's unfortunate because we have no tests on the
>> payPalCheckoutUpdate service.
>> Because I temporarily introduced HttpServletRequestWrapper James was able
>> to pass a javax.servlet.http.HttpServletRequest, like in
>> payPalCheckoutUpdate.
>> When I reverted (removed HttpServletRequestWrapper  from ContextFilter) I
>> discovered that we had a problem with Tomcat 8.5.
>>
>> I propose this fix which uses 
>> org.apache.commons.lang3.ClassUtils.getAllInterfaces()
>> and works
>> http://commons.apache.org/proper/commons-lang/javadocs/api-r
>> elea

Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml

[Scott Gray]

So to summarize your long email ;-)

"The service engine has a limitation in that it only checks the interfaces
directly implemented by the object being tested.  Tomcat's RequestFacade
doesn't directly implement javax.servlet.http.HttpServletRequest so it
fails to pass the type validation."

On the surface your suggested fix looks fine to me, my only concern being
that we may need to do some performance testing.  For every service that
specifies an interface we'll now be checking the full type hierarchy which
I imagine will be more expensive but I'm not sure how expensive.

I'm also not even sure if our custom ObjectType methods for checking this
type of thing are necessary any more with so many new java versions since
it was decided these were needed for performance reasons.

Regards
Scott

On 24 March 2018 at 10:59, Jacques Le Roux 
wrote:

> Le 23/03/2018 à 17:09, Scott Gray a écrit :
>
>> I don't need to try anything, I *know* that the service engine is supposed
>> to accept a concrete class of an interface if the interface is specified
>> as
>> the attribute type.
>>
>> Either the service engine is broken by not accepting concrete
>> implementations, or the bug report is incorrect.
>>
> Neither, it's "unfortunate", and a bit complicated.
>
> Tomcat servlet4preview was introduced with Tomcat 8.5
> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata
> lina/servlet4preview/package-summary.html
>
> Before James introduced Tomcat SSO, we had only one service passing a
> javax.servlet.http.HttpServletRequest to a service: payPalCheckoutUpdate.
>
> AFAIK, we have actually always passed a 
> org.apache.catalina.connector.RequestFacade
> to services when asking for javax.servlet.http.HttpServletRequest in
> services definition.
> Since Tomcat 8.5 RequestFacade implements 
> javax.servlet.http.HttpServletRequest
> indirectly through org.apache.catalina.servlet4pr
> eview.http.HttpServletRequest
> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/cata
> lina/connector/RequestFacade.html
>
> Since we have no tests on the payPalCheckoutUpdate service we did not spot
> that Tomcat servlet4preview was introduced with Tomcat 8.5
>
> The classes check is done by the deeper interfaceOf() method of the
> ObjectType class using Class.getInterfaces()
> https://docs.oracle.com/javase/8/docs/api/java/lang/Class.
> html#getInterfaces--
> Class.getInterfaces() does not recurse and stops at one level up. So in
> case of RequestFacade it returns only servlet4preview.http.HttpServletRequest
> and not javax.servlet.http.HttpServletRequest
> So when interfaceOf() compares the Classes it fails.
>
> What happened with my introduction of the HttpServletRequestWrapper in
> ContextFilter is it hid the RequestFacade because HttpServletRequestWrapper
> implements javax.servlet.http.HttpServletRequest
> https://docs.oracle.com/javaee/7/api/javax/servlet/http/
> HttpServletRequest.html
>
> So when James introduced Tomcat SSO and optionally passed a
> javax.servlet.http.HttpServletRequest to the userLogin service it did not
> break.
> But when I removed HttpServletRequestWrapper from ContextFilter it popped
> up
>
> Summary: it's unfortunate because we have no tests on the
> payPalCheckoutUpdate service.
> Because I temporarily introduced HttpServletRequestWrapper James was able
> to pass a javax.servlet.http.HttpServletRequest, like in
> payPalCheckoutUpdate.
> When I reverted (removed HttpServletRequestWrapper  from ContextFilter) I
> discovered that we had a problem with Tomcat 8.5.
>
> I propose this fix which uses 
> org.apache.commons.lang3.ClassUtils.getAllInterfaces()
> and works
> http://commons.apache.org/proper/commons-lang/javadocs/api-
> release/src-html/org/apache/commons/lang3/ClassUtils.html
>
> Index: framework/base/src/main/java/org/apache/ofbiz/base/util/Obje
> ctType.java
> ===
> --- framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> (révision 1827594)
> +++ framework/base/src/main/java/org/apache/ofbiz/base/util/ObjectType.java
> (copie de travail)
> @@ -263,7 +263,7 @@
>   */
>  public static boolean interfaceOf(Class objectClass, Class
> interfaceClass) {
>  while (objectClass != null) {
> -Class[] ifaces = objectClass.getInterfaces();
> +List> ifaces = org.apache.commons.lang3.Class
> Utils.getAllInterfaces(objectClass);
>
>  for (Class iface: ifaces) {
>  if (iface == interfaceClass) {
> Index: framework/common/servicedef/services.xml
> =

Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml

[Scott Gray]

I don't need to try anything, I *know* that the service engine is supposed
to accept a concrete class of an interface if the interface is specified as
the attribute type.

Either the service engine is broken by not accepting concrete
implementations, or the bug report is incorrect.

Regards
Scott

On 23 March 2018 at 07:36, Jacques Le Roux 
wrote:

> Did you try what I said?
>
> You can easily check by svn updating to r1819133 and removing the wrapper
> in ContextFilter.java.
>
> Maybe we need to revert Tomcat SSO then?
>
> Jacques
>
>
>
> Le 23/03/2018 à 03:39, Scott Gray a écrit :
>
>> Something else must be wrong Jacques, I can't understand what you're
>> saying
>> in the ticket description or in your reply above but I do know the
>> following:
>> OFBiz is perfectly capable of knowing that
>> org.apache.catalina.connector.RequestFacade
>> implements the javax.servlet.http.HttpServletRequest and it should pass
>> type validation without errors.
>>
>> Since we know that, this commit becomes unnecessary.
>>
>> Regards
>> Scott
>>
>> On 22 March 2018 at 16:06, Jacques Le Roux 
>> wrote:
>>
>> Michael,
>>>
>>> I commited http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>> mework/webapp/src/main/java/org/apache/ofbiz/webapp/contro
>>> l/ContextFilter.java?r1=1813679&r2=1813678&pathrev=1813679
>>>
>>> Where I added a wrapper. Then for "Tomcat SSO" (OFBIZ-10047) James
>>> committed
>>> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>> mework/common/servicedef/services.xml?r1=1819133&r2=1819132&
>>> pathrev=1819133
>>>
>>> If I had not committed the wrapper in ContextFilter.java beforehand,
>>> James
>>> would not have been allowed to commit
>>>
>>> >> optional="true"/>
>>>
>>> Because it's then rejected, because then the userLogin service actually
>>> receive an org.apache.catalina.connector.RequestFacade (RequestFacade
>>> implements HttpServletRequest.)
>>>
>>> You can easily check by svn updating to r1819133 and removing the wrapper
>>> in ContextFilter.java.
>>>
>>> You are right that it ties OFBiz to Tomcat. We took this decision
>>> sometimes ago and we no longer support other webapp servers OOTB, nor
>>> tools
>>> like Jetty.
>>>
>>> So OFBiz OOTB totally depends on Tomcat as the build.gradle file shows.
>>> So
>>> I think it's safe to use a RequestFacade there.
>>>
>>> If an user feels the need to use another webapp servers or Jetty, I think
>>> changing that would not be the most of the worries (the rest being much
>>> more frightening, I know I did it once with Geronimo).
>>>
>>> Since the check is done at the service level, it's hard to do otherwise
>>> But I must say I did not dig too much and it's maybe possible, we can
>>> discuss that...
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Le 22/03/2018 à 16:22, Michael Brohl a écrit :
>>>
>>> Mmhhh, Jacques,
>>>>
>>>> I think this is problematic because it ties a special implementation for
>>>> Tomcat to the service. I didn't see this anywhere else.
>>>>
>>>> The issue (https://issues.apache.org/jira/browse/OFBIZ-10304) is a bit
>>>> unclear and I don't get the purpose of this change.
>>>>
>>>> Can you please explain more clearly which problem this changes solves
>>>> and
>>>> why we'll need org.apache.catalina.connector.RequestFacade as the type?
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>>
>>>>
>>>> Am 21.03.18 um 21:53 schrieb jler...@apache.org:
>>>>
>>>> Author: jleroux
>>>>> Date: Wed Mar 21 20:53:41 2018
>>>>> New Revision: 1827439
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1827439&view=rev
>>>>> Log:
>>>>> Fixed: The "request" attribute type of the userLogin service is wrong
>>>>> (OFBIZ-10304)
>>>>>
>>>>> It should have been org.apache.catalina.connector.RequestFacade"
>>>>> instead of javax.servlet.http.HttpServletRequest see the Jira for
>>>>> details
>>>>>
>>>>> Modified:
>>>>> ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml
>>>>>
>>>>> Modified: ofbiz/ofbiz-framework/trunk/framework/common/servicedef/serv
>>>>> ices.xml
>>>>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>>>> mework/common/servicedef/services.xml?rev=1827439&r1=1827438
>>>>> &r2=1827439&view=diff
>>>>> 
>>>>> ==
>>>>> --- ofbiz/ofbiz-framework/trunk/framework/common/servicedef/serv
>>>>> ices.xml
>>>>> (original)
>>>>> +++ ofbiz/ofbiz-framework/trunk/framework/common/servicedef/serv
>>>>> ices.xml
>>>>> Wed Mar 21 20:53:41 2018
>>>>> @@ -379,7 +379,7 @@ under the License.
>>>>>
>>>>>Used to Automatically Authenticate a
>>>>> username/password; create a UserLogin object
>>>>>
>>>>> ->>>> type="javax.servlet.http.HttpServletRequest" optional="true"/>
>>>>> +>>>> type="org.apache.catalina.connector.RequestFacade" optional="true"/>
>>>>>
>>>>>>>>>location="org.apache.ofbiz.common.login.LoginServices"
>>>>> invoke="createUserLogin">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>

Re: svn commit: r1827439 - /ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml

[Scott Gray]

Something else must be wrong Jacques, I can't understand what you're saying
in the ticket description or in your reply above but I do know the
following:
OFBiz is perfectly capable of knowing that
org.apache.catalina.connector.RequestFacade
implements the javax.servlet.http.HttpServletRequest and it should pass
type validation without errors.

Since we know that, this commit becomes unnecessary.

Regards
Scott

On 22 March 2018 at 16:06, Jacques Le Roux 
wrote:

> Michael,
>
> I commited http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
> mework/webapp/src/main/java/org/apache/ofbiz/webapp/contro
> l/ContextFilter.java?r1=1813679&r2=1813678&pathrev=1813679
>
> Where I added a wrapper. Then for "Tomcat SSO" (OFBIZ-10047) James
> committed
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
> mework/common/servicedef/services.xml?r1=1819133&r2=1819132&
> pathrev=1819133
>
> If I had not committed the wrapper in ContextFilter.java beforehand, James
> would not have been allowed to commit
>
>  type="javax.servlet.http.HttpServletRequest"
> optional="true"/>
>
> Because it's then rejected, because then the userLogin service actually
> receive an org.apache.catalina.connector.RequestFacade (RequestFacade
> implements HttpServletRequest.)
>
> You can easily check by svn updating to r1819133 and removing the wrapper
> in ContextFilter.java.
>
> You are right that it ties OFBiz to Tomcat. We took this decision
> sometimes ago and we no longer support other webapp servers OOTB, nor tools
> like Jetty.
>
> So OFBiz OOTB totally depends on Tomcat as the build.gradle file shows. So
> I think it's safe to use a RequestFacade there.
>
> If an user feels the need to use another webapp servers or Jetty, I think
> changing that would not be the most of the worries (the rest being much
> more frightening, I know I did it once with Geronimo).
>
> Since the check is done at the service level, it's hard to do otherwise
> But I must say I did not dig too much and it's maybe possible, we can
> discuss that...
>
> Jacques
>
>
>
>
> Le 22/03/2018 à 16:22, Michael Brohl a écrit :
>
>> Mmhhh, Jacques,
>>
>> I think this is problematic because it ties a special implementation for
>> Tomcat to the service. I didn't see this anywhere else.
>>
>> The issue (https://issues.apache.org/jira/browse/OFBIZ-10304) is a bit
>> unclear and I don't get the purpose of this change.
>>
>> Can you please explain more clearly which problem this changes solves and
>> why we'll need org.apache.catalina.connector.RequestFacade as the type?
>>
>> Thanks,
>>
>> Michael
>>
>>
>> Am 21.03.18 um 21:53 schrieb jler...@apache.org:
>>
>>> Author: jleroux
>>> Date: Wed Mar 21 20:53:41 2018
>>> New Revision: 1827439
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1827439&view=rev
>>> Log:
>>> Fixed: The "request" attribute type of the userLogin service is wrong
>>> (OFBIZ-10304)
>>>
>>> It should have been org.apache.catalina.connector.RequestFacade"
>>> instead of javax.servlet.http.HttpServletRequest see the Jira for
>>> details
>>>
>>> Modified:
>>> ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml
>>>
>>> Modified: ofbiz/ofbiz-framework/trunk/framework/common/servicedef/serv
>>> ices.xml
>>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>> mework/common/servicedef/services.xml?rev=1827439&r1=1827438
>>> &r2=1827439&view=diff
>>> 
>>> ==
>>> --- ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml
>>> (original)
>>> +++ ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml
>>> Wed Mar 21 20:53:41 2018
>>> @@ -379,7 +379,7 @@ under the License.
>>>   
>>>   Used to Automatically Authenticate a
>>> username/password; create a UserLogin object
>>>   
>>> ->> type="javax.servlet.http.HttpServletRequest" optional="true"/>
>>> +>> type="org.apache.catalina.connector.RequestFacade" optional="true"/>
>>>   
>>>   >>   location="org.apache.ofbiz.common.login.LoginServices"
>>> invoke="createUserLogin">
>>>
>>>
>>>
>>
>>
>

Re: Demo Trunk Break

[Scott Gray]

That's the problem though, this domain isn't available for that purpose
either.

You're also using infra volunteer time for feature development rather than
project support.

Regards
Scott

On 16/03/2018 7:29 PM, "Jacques Le Roux" 
wrote:

> I'm sorry, this is a temporary poor man solution. I have no other domain
> available.
>
> Jacques
>
>
> Le 16/03/2018 à 03:08, Scott Gray a écrit :
>
>> I guess what Michael is getting at, is that the demo server is for demos,
>> it's not intended for use as a development sandbox.
>>
>> As far as I can tell you don't *need* to be using the demo servers for
>> this, it's just convenient for you.  But the problem is, if you're
>> modifying the code on the demos and someone reports a problem, the rest of
>> us will go looking for a problem in the branches that doesn't exist.
>>
>> Long story short, probably not an appropriate use of the demo instances.
>>
>> Regards
>> Scott
>>
>> On 16 March 2018 at 08:34, Jacques Le Roux 
>> wrote:
>>
>> Before Jacopo asked to revert my work on OFBIZ-9833 I continued to work on
>>> a replacing solution.
>>>
>>> This other solution still uses the same (slightly modified)
>>> externalServerLoginCheck preprocessor.
>>> FYI this solution is still based on AutoUserLogin cookies, and uses now
>>> Ajax and CORS, instead of  ContextFilter.
>>>
>>> So to test that on a server I need a small modification on the current
>>> code:
>>>
>>> Index: framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
>>> ol/ExternalLoginKeysManager.java
>>> ===
>>> --- framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
>>> ol/ExternalLoginKeysManager.java (revision 1826773)
>>> +++ framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
>>> ol/ExternalLoginKeysManager.java (working copy)
>>> @@ -182,18 +182,15 @@
>>>   Delegator delegator = (Delegator)
>>> request.getAttribute("delegato
>>> r");
>>>   HttpSession session = request.getSession();
>>>
>>> -// The target server does not allow external login by default
>>> -boolean useExternalServer = EntityUtilProperties.getProper
>>> tyAsBoolean("security",
>>> "use-external-server", false);
>>> -String sourceWebappName = request.getParameter(SOURCE_SE
>>> RVER_WEBAPP_NAME);
>>> -if (!useExternalServer || sourceWebappName == null) return
>>> "success"; // Nothing to do here
>>> -
>>>   try {
>>>   String userLoginId = null;
>>>   String authorizationHeader = request.getHeader("Authorizati
>>> on");
>>>   if (authorizationHeader != null) {
>>>   Claims claims = returnsClaims(authorizationHeader);
>>>   userLoginId = getSourceUserLoginId(claims );
>>> -boolean jwtOK = checkJwt(authorizationHeader,
>>> userLoginId, getTargetServerUrl(request), UtilHttp.getApplicationName(re
>>> quest));
>>> +boolean jwtOK = checkJwt(authorizationHeader,
>>> userLoginId, "","");
>>>   if (!jwtOK) {
>>>   // Something unexpected happened here
>>>   Debug.logWarning("*** There was a problem with the
>>> JWT token, not signin in the user login " + userLoginId, module);
>>>
>>> I did this modification on the trunk demo. I have no other solution to
>>> test my work.
>>>
>>> Also I had to request the installation of HTTPS headers handling by
>>> infra:
>>> https://issues.apache.org/jira/browse/INFRA-16189
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 15/03/2018 à 17:37, Michael Brohl a écrit :
>>>
>>> I still do not understand why you had to change the demo instance for
>>>> your developments. What was this change?
>>>>
>>>> Michael
>>>>
>>>>
>>>> Am 15.03.18 um 14:46 schrieb Jacques Le Roux:
>>>>
>>>> Because for testing changes for OFBIZ-9833 I had to make a slight change
>>>>> on the trunk demo instance and needed to restart but
>>>>>
>>>>> ./gradlew --no-daemon "ofbiz --shutdown"
>>>>&g

Re: Demo Trunk Break

[Scott Gray]

I guess what Michael is getting at, is that the demo server is for demos,
it's not intended for use as a development sandbox.

As far as I can tell you don't *need* to be using the demo servers for
this, it's just convenient for you.  But the problem is, if you're
modifying the code on the demos and someone reports a problem, the rest of
us will go looking for a problem in the branches that doesn't exist.

Long story short, probably not an appropriate use of the demo instances.

Regards
Scott

On 16 March 2018 at 08:34, Jacques Le Roux 
wrote:

> Before Jacopo asked to revert my work on OFBIZ-9833 I continued to work on
> a replacing solution.
>
> This other solution still uses the same (slightly modified)
> externalServerLoginCheck preprocessor.
> FYI this solution is still based on AutoUserLogin cookies, and uses now
> Ajax and CORS, instead of  ContextFilter.
>
> So to test that on a server I need a small modification on the current
> code:
>
> Index: framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
> ol/ExternalLoginKeysManager.java
> ===
> --- framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
> ol/ExternalLoginKeysManager.java (revision 1826773)
> +++ framework/webapp/src/main/java/org/apache/ofbiz/webapp/contr
> ol/ExternalLoginKeysManager.java (working copy)
> @@ -182,18 +182,15 @@
>  Delegator delegator = (Delegator) request.getAttribute("delegato
> r");
>  HttpSession session = request.getSession();
>
> -// The target server does not allow external login by default
> -boolean useExternalServer = 
> EntityUtilProperties.getPropertyAsBoolean("security",
> "use-external-server", false);
> -String sourceWebappName = request.getParameter(SOURCE_SE
> RVER_WEBAPP_NAME);
> -if (!useExternalServer || sourceWebappName == null) return
> "success"; // Nothing to do here
> -
>  try {
>  String userLoginId = null;
>  String authorizationHeader = request.getHeader("Authorizati
> on");
>  if (authorizationHeader != null) {
>  Claims claims = returnsClaims(authorizationHeader);
>  userLoginId = getSourceUserLoginId(claims );
> -boolean jwtOK = checkJwt(authorizationHeader,
> userLoginId, getTargetServerUrl(request), UtilHttp.getApplicationName(re
> quest));
> +boolean jwtOK = checkJwt(authorizationHeader,
> userLoginId, "","");
>  if (!jwtOK) {
>  // Something unexpected happened here
>  Debug.logWarning("*** There was a problem with the
> JWT token, not signin in the user login " + userLoginId, module);
>
> I did this modification on the trunk demo. I have no other solution to
> test my work.
>
> Also I had to request the installation of HTTPS headers handling by infra:
> https://issues.apache.org/jira/browse/INFRA-16189
>
> Jacques
>
>
>
> Le 15/03/2018 à 17:37, Michael Brohl a écrit :
>
>> I still do not understand why you had to change the demo instance for
>> your developments. What was this change?
>>
>> Michael
>>
>>
>> Am 15.03.18 um 14:46 schrieb Jacques Le Roux:
>>
>>> Because for testing changes for OFBIZ-9833 I had to make a slight change
>>> on the trunk demo instance and needed to restart but
>>>
>>> ./gradlew --no-daemon "ofbiz --shutdown"
>>>
>>> Does not always behaves well, at least on demos VM where there is 3
>>> instances
>>>
>>> So you get unstable situation and have to use "kill -9".
>>>
>>> Anyway some data were not well loaded. A loadAll fixed it.
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>>
>>> Le 15/03/2018 à 13:56, Michael Brohl a écrit :
>>>
 Of course it should read: "I try to understand why trunk demo was
 broken while the trunk codebase seems to have no issues."

 Michael


 Am 15.03.18 um 13:51 schrieb Michael Brohl:

> To be more clear: I try to understand why trunk demo was broken while
> the trunk demo seems to have no issues.
>
> Michael
>
>
> Am 15.03.18 um 13:36 schrieb Jacques Le Roux:
>
>> Ho, it would be convoluted, please wait, WIP...
>>
>> Jacques
>>
>>
>> Le 15/03/2018 à 12:37, Michael Brohl a écrit :
>>
>>> Jacques did changes he already reverted in the mantime, see his post
>>> this morning.
>>>
>>> Jacques, can you please explain what happened?
>>>
>>>
>>> Am 15.03.18 um 12:24 schrieb Taher Alkhateeb:
>>>
 Hi Rishi, I'm not getting any errors in the demo on my side? Could
 it
 be a web browser cache thing? I always fall in that trap myself.

 On Thu, Mar 15, 2018 at 10:59 AM, Rishi Solanki <
 rishisolan...@gmail.com> wrote:

> It seems something specific with deployment/data at demo instance,
> locally
> It is working. No issue with latest trunk fresh data.
>
> Best,

Re: tenant handling in XMLRPC

[Scott Gray]

You're completely right Rajesh, sorry, I jumped the gun without having a
proper look in my reply.

Your fix looks correct except that we need to move dispatcher/delegator to
local variables rather than instance fields.  The EventHandler objects are
singletons shared among all incoming requests so we don't want to store
request-specific objects in fields that are accessed by all requests or the
results will get pretty unpredictable for concurrent requests across
multiple tenants.

Regards
Scott


On 16 March 2018 at 07:01, Rajesh Mallah  wrote:

> Hi Scott ,
>
> I could get it to work by setting dispatcher and delegator only.
> I referred SOAPEventHandler.java which handles tenants fine.
>
> I could not see userLogin handling tenantId as suggested by you,
> can you please see the below and tell if it is correct.
>
> Do we have test coverage to see if does not break anything else?
>
> $ diff  -u5 XmlRpcEventHandler.java.orig   XmlRpcEventHandler.java
> --- XmlRpcEventHandler.java.orig2018-03-15 23:29:46.954352066 +0530
> +++ XmlRpcEventHandler.java 2018-03-15 23:29:51.734435105 +0530
> @@ -91,10 +91,12 @@
>  /**
>   * @see
> org.apache.ofbiz.webapp.event.EventHandler#invoke(ConfigXMLReader.Event,
> ConfigXMLReader.RequestMap, javax.servlet.http.HttpServletRequest,
> javax.servlet.http.HttpServletResponse)
>   */
>  public String invoke(Event event, RequestMap requestMap,
> HttpServletRequest request, HttpServletResponse response) throws
> EventHandlerException {
>  String report = request.getParameter("echo");
> +dispatcher = (LocalDispatcher) request.getAttribute("
> dispatcher");
> +delegator = (Delegator) request.getAttribute("delegator");
>  if (report != null) {
>  BufferedReader reader = null;
>  StringBuilder buf = new StringBuilder();
>  try {
>  // read the inputstream buffer
>
>
>
> On Thu, Mar 15, 2018 at 9:51 PM, Scott Gray 
> wrote:
>
> > Hi Rajesh,
> >
> > It looks like the XmlRpcEventHandler class doesn't support this but it
> > could easily be modified to do so.  I'd suggest filing a ticket, and
> > perhaps even providing a patch :-)
> >
> > The tenantId just needs to be derived from the url and then passed into
> the
> > userLogin service in the OfbizRpcAuthHandler.isAuthorized(...) method.
> >
> > Regards
> > Scott
> >
> > On 16 March 2018 at 00:22, Rajesh Mallah 
> wrote:
> >
> > > Hello All ,
> > >
> > > Is it possible to direct the webservice call to a particular tenant
> using
> > > XMLRPC?
> > >
> > > I am referring to
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/OFBIZ/Using+XMLRPC+as+an+
> > > alternative+to+SOAP
> > >
> > >
> > > consider the snippet
> > >
> > > ===
> > >   XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
> > > config.setServerURL(new URL("
> > > http://127.0.0.1/webtools/control/xmlrpc";
> > > <http://127.0.0.1/webtools/control/xmlrpc>));
> > > config.setEnabledForExceptions(true);
> > > config.setEnabledForExtensions(true);
> > >
> > > XmlRpcClient client = new XmlRpcClient();
> > > client.setConfig(config);
> > >
> > > Map paramMap = new HashMap();
> > > paramMap.put("login.username", "admin");
> > > paramMap.put("login.password", "ofbiz");
> > > paramMap.put("idToFind", "admin");
> > > 
> ===
> > > I tried setting the host part of serverUrl to domain_name of
> > > tenant_domain_name .
> > >
> > > I find that the requests always work on the first tenant .
> > > i need to work with a specific tenant .
> > >
> > > Any help is solicited.
> > >
> > > regds
> > > mallah.
> > >
> >
>

Re: tenant handling in XMLRPC

[Scott Gray]

Hi Rajesh,

It looks like the XmlRpcEventHandler class doesn't support this but it
could easily be modified to do so.  I'd suggest filing a ticket, and
perhaps even providing a patch :-)

The tenantId just needs to be derived from the url and then passed into the
userLogin service in the OfbizRpcAuthHandler.isAuthorized(...) method.

Regards
Scott

On 16 March 2018 at 00:22, Rajesh Mallah  wrote:

> Hello All ,
>
> Is it possible to direct the webservice call to a particular tenant using
> XMLRPC?
>
> I am referring to
>
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Using+XMLRPC+as+an+
> alternative+to+SOAP
>
>
> consider the snippet
>
> ===
>   XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
> config.setServerURL(new URL("
> http://127.0.0.1/webtools/control/xmlrpc";
> ));
> config.setEnabledForExceptions(true);
> config.setEnabledForExtensions(true);
>
> XmlRpcClient client = new XmlRpcClient();
> client.setConfig(config);
>
> Map paramMap = new HashMap();
> paramMap.put("login.username", "admin");
> paramMap.put("login.password", "ofbiz");
> paramMap.put("idToFind", "admin");
> ===
> I tried setting the host part of serverUrl to domain_name of
> tenant_domain_name .
>
> I find that the requests always work on the first tenant .
> i need to work with a specific tenant .
>
> Any help is solicited.
>
> regds
> mallah.
>

Re: buildbot failure in on ofbizTrunkFramework

[Scott Gray]

It's easy to just search the log output for "JUNIT (failure)", which
reports this test failed:

2018-03-13 13:18:52,725 |main |TestRunContainer
  |W| [JUNIT (failure)] -
auto-accounting-transaction-tests-purchase.testAcctgTransOnPaymentSentToSupplier
: Assertion failed: [acctgTrans.glJournalId=ERROR_JOURNAL] not-equals
ERROR_JOURNAL as

Regards
Scott

On 14 March 2018 at 03:34, Jacques Le Roux 
wrote:

> Hi Rishi,
>
> Sorry I did not check the tests at https://ci.apache.org/projects
> /ofbiz/logs/trunk/framework/html/ as I use to do in such cases. So now
> they show nothing abnormal.
>
> Sometimes BuildBot (actually the machines under it, which are under very
> heavy load, actually like 100% on all parts I guess, because they always
> have something on their plates) have some hiccups, and then the tests fail
> when they should not.
>
> If tests pass locally, please commit again to see if the same happen. If
> the same happen then if possible check with a team mate locally again or
> ask for the same here :)
>
> HTH
>
> Jacques
>
>
>
> Le 13/03/2018 à 14:50, Rishi Solanki a écrit :
>
>> I have reverted my commit for now, not sure what went wrong with commit as
>> I have tested the functionality before commit. I'll check and get back on
>> this.
>>
>> Also I'll reopen the ticket.
>>
>> Rishi Solanki
>> Sr Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Tue, Mar 13, 2018 at 6:55 PM,  wrote:
>>
>> The Buildbot has detected a new failure on builder ofbizTrunkFramework
>>> while building . Full details are available at:
>>>  https://ci.apache.org/builders/ofbizTrunkFramework/builds/128
>>>
>>> Buildbot URL: https://ci.apache.org/
>>>
>>> Buildslave for this Build: lares_ubuntu
>>>
>>> Build Reason: The AnyBranchScheduler scheduler named
>>> 'onTrunkFrameworkCommit' triggered this build
>>> Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1826627
>>> Blamelist: rishi
>>>
>>> BUILD FAILED: failed shell_2
>>>
>>> Sincerely,
>>>   -The Buildbot
>>>
>>>
>>>
>>>
>>>
>

Re: svn commit: r1825436 - /ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml

[Scott Gray]

Ah so you did, sorry!  I just picked a random commit from my inbox to
review without looking at the subsequent ones.

Regards
Scott

On 1 March 2018 at 10:57, Taher Alkhateeb 
wrote:

> Hi Scott, yeah I reverted this commit.
>
> I realized that the reason for the crash is actually the order of
> writing the readers in the command line. There are still some issues
> in other areas of loading, so I need to study it a bit further.
>
> On Thu, Mar 1, 2018 at 12:46 AM, Scott Gray
>  wrote:
> > Hi Taher,
> >
> > I'm not sure I understand or if something has changed in the last few
> years
> > but seed-initial should always expect to be loaded after seed data so it
> > shouldn't be a problem for seed-initial to depend on seed data.  You
> would
> > never just load seed-initial into an empty database.
> >
> > Regards
> > Scott
> >
> > On 27 February 2018 at 23:41,  wrote:
> >
> >> Author: taher
> >> Date: Tue Feb 27 10:41:14 2018
> >> New Revision: 1825436
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1825436&view=rev
> >> Log:
> >> Fixed: a bug in loading seed-only data into the system
> >>
> >> When calling OFBiz with the command gradlew "ofbiz -l
> readers=seed-initial"
> >> the system crashes. The reason is because of a faulty dependency of
> >> "seed-initial" data in the entityext component to "seed" data in the
> >> security
> >> component. The fix is simply to change the type of reader for the
> requested
> >> data in SecurityPermissionSeedData.xml from "seed" to "seed-initial"
> >>
> >> Modified:
> >> ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
> >>
> >> Modified: ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-
> >> component.xml
> >> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> >> framework/security/ofbiz-component.xml?rev=1825436&r1=
> >> 1825435&r2=1825436&view=diff
> >> 
> >> ==
> >> --- ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
> >> (original)
> >> +++ ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
> >> Tue Feb 27 10:41:14 2018
> >> @@ -26,7 +26,7 @@ under the License.
> >>  
> >>
> >>   >> location="entitydef/entitymodel.xml"/>
> >> - >> location="data/SecurityPermissionSeedData.xml"/>
> >> + loader="main"
> >> location="data/SecurityPermissionSeedData.xml"/>
> >>  
> >>   >> location="data/PasswordSecurityDemoData.xml"/>
> >>   >> location="data/SecurityGroupDemoData.xml"/>
> >>
> >>
> >>
>

Re: svn commit: r1825436 - /ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml

[Scott Gray]

Hi Taher,

I'm not sure I understand or if something has changed in the last few years
but seed-initial should always expect to be loaded after seed data so it
shouldn't be a problem for seed-initial to depend on seed data.  You would
never just load seed-initial into an empty database.

Regards
Scott

On 27 February 2018 at 23:41,  wrote:

> Author: taher
> Date: Tue Feb 27 10:41:14 2018
> New Revision: 1825436
>
> URL: http://svn.apache.org/viewvc?rev=1825436&view=rev
> Log:
> Fixed: a bug in loading seed-only data into the system
>
> When calling OFBiz with the command gradlew "ofbiz -l readers=seed-initial"
> the system crashes. The reason is because of a faulty dependency of
> "seed-initial" data in the entityext component to "seed" data in the
> security
> component. The fix is simply to change the type of reader for the requested
> data in SecurityPermissionSeedData.xml from "seed" to "seed-initial"
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
>
> Modified: ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-
> component.xml
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> framework/security/ofbiz-component.xml?rev=1825436&r1=
> 1825435&r2=1825436&view=diff
> 
> ==
> --- ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
> (original)
> +++ ofbiz/ofbiz-framework/trunk/framework/security/ofbiz-component.xml
> Tue Feb 27 10:41:14 2018
> @@ -26,7 +26,7 @@ under the License.
>  
>
>   location="entitydef/entitymodel.xml"/>
> - location="data/SecurityPermissionSeedData.xml"/>
> + location="data/SecurityPermissionSeedData.xml"/>
>  
>   location="data/PasswordSecurityDemoData.xml"/>
>   location="data/SecurityGroupDemoData.xml"/>
>
>
>

Re: svn commit: r1824807 - /ofbiz/branches/release16.11/framework/webapp/src/main/java/org/apache/ofbi z/webapp/control/LoginWorker.java

[Scott Gray]

Jacques, as a first step, please consider not using "no functional change"
any longer.  It used to be that it was simply used for basic formatting
fixes, but now that I look closer, I notice you've had a trend going for a
while now that you're using it for anything you consider to be minor.
Examples include library upgrades, documentation changes, bug fixes, code
comments, etc.  Aside from the current commit which was a fix, I think you
could simply replace "No functional change" with "Improves:" and you'd
suddenly be mostly inline with the community guidelines on commit messages.

Additionally, I see that you've made 89 edits to your commit messages this
year, out of 191 commits.  Surely you can agree that is quite excessive and
perhaps you need to slow down and think a little more before pushing your
commits?

Regards
Scott

On 20 February 2018 at 10:27, Michael Brohl 
wrote:

> Jacques,
>
> I won't correct you commit messages. This is a repeating issue.
>
> From now on, we will just not include those commits in the blog dev
> details.
>
> Am 19.02.18 um 22:07 schrieb Jacques Le Roux:
>
> Please Michael,
>>
>> I had a very rude day, we are a team, if you fill it needs a log change
>> please do
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 19/02/2018 à 20:59, Michael Brohl a écrit :
>>
>>> So this is a bugfix and should read "Fixed: ..."
>>>
>>> *sigh*
>>>
>>>
>>> Am 19.02.18 um 20:43 schrieb jler...@apache.org:
>>>
 Author: jleroux
 Date: Mon Feb 19 19:43:15 2018
 New Revision: 1824807

 URL: http://svn.apache.org/viewvc?rev=1824807&view=rev
 Log:
 No functional change, this missed an import in last backported commit

 Modified:
 ofbiz/branches/release16.11/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/LoginWorker.java

 Modified: ofbiz/branches/release16.11/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/LoginWorker.java
 URL: http://svn.apache.org/viewvc/ofbiz/branches/release16.11/fra
 mework/webapp/src/main/java/org/apache/ofbiz/webapp/contro
 l/LoginWorker.java?rev=1824807&r1=1824806&r2=1824807&view=diff
 ==

 --- ofbiz/branches/release16.11/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/LoginWorker.java (original)
 +++ ofbiz/branches/release16.11/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/LoginWorker.java Mon Feb 19 19:43:15
 2018
 @@ -24,6 +24,7 @@ import java.math.BigInteger;
   import java.security.cert.X509Certificate;
   import java.sql.Timestamp;
   import java.util.ArrayList;
 +import java.util.Arrays;
   import java.util.Collection;
   import java.util.LinkedList;
   import java.util.List;



>>>
>>>
>>
>
>

Re: svn commit: r1823562 - /ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbi z/webapp/control/ExternalLoginKeysManager.java

[Scott Gray]

Every code change is at a minimum an improvement. Our other tags are just
more specific improvements e.g. a fix is an improvement to something that
was previously broken.

Regards
Scott

On 9/02/2018 06:19, "Jacques Le Roux"  wrote:

> I use completed for these cases because it's not really an improvement,
> just syntax sugar, that's OK (we agreed when we created the template)
>
> Jacques
>
>
> Le 08/02/2018 à 18:12, Jacques Le Roux a écrit :
>
>> Yes sure
>>
>> Jacques
>>
>>
>> Le 08/02/2018 à 16:16, Michael Brohl a écrit :
>>
>>> Hi Jacques,
>>>
>>> can you please use "Improved:..." for these commit messages?
>>>
>>> The "No functional change" message permanently requires extra work to
>>> sort out when we prepare the blog details.
>>>
>>> Thank you,
>>>
>>> Michael
>>>
>>>
>>> Am 08.02.18 um 16:01 schrieb jler...@apache.org:
>>>
 Author: jleroux
 Date: Thu Feb  8 15:01:54 2018
 New Revision: 1823562

 URL: http://svn.apache.org/viewvc?rev=1823562&view=rev
 Log:
 No functional change, just better syntax

 Modified:
 ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/ExternalLoginKeysManager.java

 Modified: ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/ExternalLoginKeysManager.java
 URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
 mework/webapp/src/main/java/org/apache/ofbiz/webapp/contro
 l/ExternalLoginKeysManager.java?rev=1823562&r1=1823561&
 r2=1823562&view=diff
 
 ==
 --- ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/ExternalLoginKeysManager.java
 (original)
 +++ ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/
 org/apache/ofbiz/webapp/control/ExternalLoginKeysManager.java Thu Feb
 8 15:01:54 2018
 @@ -183,7 +183,7 @@ public class ExternalLoginKeysManager {
   HttpSession session = request.getSession();
 // The target server does not allow external login by
 default
 -boolean useExternalServer = 
 "Y".equals(EntityUtilProperties.getPropertyValue("security",
 "use-external-server", "N", delegator));
 +boolean useExternalServer = 
 EntityUtilProperties.getPropertyAsBoolean("security",
 "use-external-server", false);
   String sourceWebappName = request.getParameter(SOURCE_SE
 RVER_WEBAPP_NAME);
   if (!useExternalServer || sourceWebappName == null) return
 "success"; // Nothing to do here



>>>
>>>
>>
>>
>

Re: [Proposal] OR search criteria within performFind

[Scott Gray]

A little bit off topic but I recently wrote an EntityCondition converter
for use with the rsql-parser[1] library.  Using it on an html client to
write free-form queries would need some javascript wizardry but it's worth
looking at if we ever wanted to implement something like Jira's JQL
capability.

Regards
Scott

[1] https://github.com/jirutka/rsql-parser

On 8 February 2018 at 00:11, Taher Alkhateeb 
wrote:

> Awesome Gil, you rock! Rubbing hands in anticipation :)
>
> On Feb 7, 2018 1:52 PM, "gil portenseigne" 
> wrote:
>
> After reanalysing the performFind mechanism, i realized that i was mistaken
> and just write down the logic you proposed, i will make it available for
> review, with I hope a little test, when i'll find the time.
>
> Just letting you know i am on it :).
>
> Gil
>
>
>
> On 03/02/2018 10:17, Taher Alkhateeb wrote:
>
> > Not really, you just add an if condition to check if any search groups
> > exist, and if they do then apply the additional search logic.
> >
>

Re: Permission overrides auth parameter of service

[Scott Gray]

Ok I see, so there is a need for permission services to be able to run
without a userLogin value in some cases.  Specifically in situations where
the other parameters provided can determine whether an anonymous user is
authorized to execute the given service.

Thanks for providing the additional info.

Regards
Scott

On 24 December 2017 at 00:38, Chinmay Patidar <
chinmay.pati...@hotwaxsystems.com> wrote:

> Hello All,
>
> Adding to the Suraj's example of CreateShoppingList, I would like to
> elaborate more on the same.
>
> In current implementation, 'checkShoppingListSecurity' service is a
> permission-service for 'createShoppingList' service. The system creates a
> shopping list for an anonymous user on the ecommerce when adding an item to
> the cart (try in incognito window so it doesn't pick party from the cache).
> But with the current implementation, checkShoppingListSecurity returns an
> error saying that "You must be logged in to complete the process". In
> simple words, the 'createShoppingList' service gets called for an anonymous
> user which eventually triggers 'checkShoppingListSecurity' service.
>
> The above explanation gives an example of a use case where one could
> possibly have no userLogin but has a permission service implemented(for
> covering use cases of userLogin).
>
> Also, it seems that one can't use a permission-service when no
> userLogin would be present.
>
> Also, for now, to fix the issue we can call the "checkShoppingListSecurity"
> service from the service declaration/implementation to overcome the error
> of no userLogin. Although, it creates confusion to me that the same service
> when called internally works fine but when called as a permission service,
> returns an error.
>
> Please let me know if calling the security service internally would be the
> proper approach.
>
> Thanks,
> *Chinmay Patidar* | Sr. Enterprise Software Engineer
> HotWax Commerce by HotWax Systems
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P, India - 452010
> Cell phone: +91-9713978795
>
> On Mon, Dec 11, 2017 at 5:43 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi Suraj,
> >
> > I don't see how you could check permissions for an anonymous user.
> > Maybe by giving anonymous users specific permissions in the context of
> > ecommerce?
> >
> > But does it makes sense, I'm not sure. Then maybe as mentioned Rishi we
> > should fix services like CreateShoppingList
> > BTW did you cross any issues with anonymous users or is that only you
> > thinking?
> >
> > Jacques
> >
> >
> >
> > Le 01/12/2017 à 09:41, Suraj Khurana a écrit :
> >
> >> Thanks everyone for your inputs.
> >>
> >> Yes, there are similar occurrences where permission service is defined
> and
> >> service is used in case of an anonymous user as well.
> >> Example: *CreateShoppingList* and related services
> >>
> >> I was presuming we can execute any service as permission service
> >> irrespective of taking *userLogin *into consideration. Please correct me
> >> if
> >> I am wrong or missing something.
> >>
> >> --
> >> Thanks and Regards,
> >> *Suraj Khurana* | Sr. Enterprise Software Engineer
> >> *HotWax Commerce*  by  *HotWax Systems*
> >> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
> >>
> >>
> >> On Wed, Nov 29, 2017 at 7:35 PM, Rishi Solanki  >
> >> wrote:
> >>
> >> If an service implements and  do checks for the permissions then it must
> >>> have the auth set as true. If any occurrences found then it should be
> by
> >>> mistake and service definition should be fix to match.
> >>>
> >>> So I think the behavior we have is correct, whenever we want to check
> the
> >>> permission it should have the user in context.
> >>>
> >>> Suraj, Any scenario you have in mind where we only require permission
> >>> service without user?
> >>>
> >>>
> >>> Rishi Solanki
> >>> Sr Manager, Enterprise Software Development
> >>> HotWax Systems Pvt. Ltd.
> >>> Direct: +91-9893287847
> >>> http://www.hotwaxsystems.com
> >>> www.hotwax.co
> >>>
> >>> On Wed, Nov 29, 2017 at 1:39 PM, Scott Gray <
> >>> scott.g...@hotwaxsystems.com>
> >>> wrote:
> >>>
> >>> auth="false" and

Re: [DISCUSSION] Disentanglement of the ExampleExt component

[Scott Gray]

My memory is vague on security-ext but I think the purpose was to extend
the security component for application-level functionality (as opposed to
framework-level). For example the UserLogin.partyId field was added to the
schema in this component because the framework wasn't supposed to have any
concept of the Party model.

Regards
Scott

On 9/01/2018 7:14 AM, "Taher Alkhateeb"  wrote:

> I stand corrected, Scott made a very good point regarding entityext
> that I did not pay enough attention to. Perhaps the name is misleading
> though, entityext means an enhancement or extension of the
> capabilities of the entity component which does not make a lot of
> sense. If it was called entity-service or entity-service-map or
> something like might have been more direct and self explanatory.
>
> I think Jacopo's comment of moving away from components to jars as the
> building blocks (at least for the framework) is a fantastic idea. It
> might involve a heavy amount of work but is definitely doable if we
> get focused. Meanwhile, back to the subject of ext components, perhaps
> many of them need to be merged and or replaced. That might include:
> - securityext: not sure why it exists
> - commonext: that's a difficult one, lots of entanglements, but none
> the less I'm not sure why does it exist and why does it depend on
> other "application" components.
> - exampleext: no idea why, but probably least useful.
>
> So following Pierre's suggestion perhaps we should generalize this
> thread and consider removing all three?
>
> On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
>  wrote:
> > Scott is making a good point about entity-ext: in my opinion the design
> is
> > good (but can be improved).
> > I suspect that commonext and exampleext have a less clean implementation
> > and maybe they do not even implement that pattern, I see less value in
> them.
> >
> > One comment on entity-ext: In my opinion we should (for this and for
> > several other parts of the framework) continue the work to make the
> > framework code more modular (with core independent modules and with
> > extended modules that depend on them etc...) but I don't think that the
> > building block should be the "OFBiz component" as it is now. It would be
> > better to rely on jar files instead.
> > For example:
> > entity-core-api.jar
> >   entity-core-impl.jar
> > service-core-api.jar
> >   service-core-impl.jar
> >
> > service-entity.jar that provides the integration of services with the
> > entity engine and depends on entity-core-api.jar and service-core-api.jar
> >
> > We could define several granular modules that would allow to deploy
> > different flavors of the framework, e.g.:
> > 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
> > legacy applications (built from scratch)
> > 2) service-core-api.jar + service-core-impl.jar: service engine available
> > to legacy applications (built from scratch)
> > 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity
> engine
> > available to legacy applications (built from scratch)
> > etc...
> >
> > Jacopo
> >
> > On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray  >
> > wrote:
> >
> >> I'm not familiar with commonext or exampleext, but the purpose of the
> >> entity-ext component was to allow the entity engine to exist without the
> >> service engine.  That's why all the entity-related logic that relies on
> the
> >> service engine is implemented there (EECAs, EntitySync, DCC).  The
> >> alternative would be to have that stuff in the service engine, it can't
> >> exist in the entity engine because you'd have a circular compile-time
> >> dependency.
> >>
> >> It effectively exists as a "disentanglement" of the entity and service
> >> engines.
> >>
> >> Regards
> >> Scott
> >>
> >>
> >> On 8 January 2018 at 09:18, Taher Alkhateeb  >
> >> wrote:
> >>
> >> > I think all -ext components (entityext, commonext, exampleext) are
> >> > redundant and do not add value. Any patches to fix this issue and
> >> > merge these components would be great.
> >> >
> >> >
> >> >
> >> > On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits 
> >> > wrote:
> >> > > Hi all,
> >> > >
> >> > > The ExampleExt components provides functionality to extend widgets
> >> across
> >> > > components. In this soluti

Re: [jira] [Commented] (OFBIZ-8230) Disentangle platform specific entity engine schemas

[Scott Gray]

The argument was that the configs weren't being used by default, so the
same would, in theory, apply to those files.

Regards
Scott

On 9/01/2018 5:14 AM, "Jacques Le Roux" 
wrote:

Le 08/01/2018 à 01:36, Scott Gray a écrit :

> The same goes for the fieldtype definitions.
>
I agree with you for entityengine.xml, but those are separated, so I don't
see the relationship.

Jacques

Re: [jira] [Commented] (OFBIZ-8230) Disentangle platform specific entity engine schemas

[Scott Gray]

I'm in favor of the status quo. It's useful to have them available out of
the box to be able to pick the one you need and proceed without having to
look elsewhere. The same goes for the fieldtype definitions.

Regards
Scott


On 8/01/2018 6:26 AM, "Pierre Smits"  wrote:

We could consider having example configurations (entityengine.xml files)
for applicable database solutions in the documentation (in confluence).
Removing unused code snippets is always worth the effort put forward.




Best regards,

Pierre Smits

V.P. Apache Trafodion

On Sun, Jan 7, 2018 at 5:36 PM, jler...@apache.org 
wrote:

> Le 07/01/2018 à 11:43, Jacques Le Roux a écrit :
>
>> My answer to your question is: we should keep them of course, except if a
>> better way would be proposed, I see none for now...
>>
> I must have said: I see none PROVIDED for now...
>
> We could consider a modular solution which would include split parts of
> the file in the remaining main, but  I'm not sure it's worth it
>

Re: [DISCUSSION] Disentanglement of the ExampleExt component

[Scott Gray]

I'm not familiar with commonext or exampleext, but the purpose of the
entity-ext component was to allow the entity engine to exist without the
service engine.  That's why all the entity-related logic that relies on the
service engine is implemented there (EECAs, EntitySync, DCC).  The
alternative would be to have that stuff in the service engine, it can't
exist in the entity engine because you'd have a circular compile-time
dependency.

It effectively exists as a "disentanglement" of the entity and service
engines.

Regards
Scott


On 8 January 2018 at 09:18, Taher Alkhateeb 
wrote:

> I think all -ext components (entityext, commonext, exampleext) are
> redundant and do not add value. Any patches to fix this issue and
> merge these components would be great.
>
>
>
> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits 
> wrote:
> > Hi all,
> >
> > The ExampleExt components provides functionality to extend widgets across
> > components. In this solution, the ExampleExt component has form widgets
> > extending similar widgets in the Example component.
> >
> > This kind of functionality (both within one component and across, and
> with
> > more variants) already/also exists in other components in the
> > ofbiz-framework code base.
> >
> > So, do we still want to entertain/maintain a component that adds little
> to
> > no unique value for our (potential) adopters, even though it is in the
> > ofbiz-plugin code base?
> >
> > For what it is worth: the ExampleExt widgets can easily be integrated in
> > the Example component, and the existence of extended/extending widgets in
> > the ofbiz-framework code base also serves as examples of what can be
> > achieved by adopters/contributors.
> >
> > What are your thoughts?
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > V.P. Apache Trafodion
> > PMC Member Apache Directory
>

Re: [OFBIZ] - Job schedules and Multi instance

[Scott Gray]

You can treat each instance as a separate pool in serviceengine.xml, so
that instance A sends jobs and runs jobs from poolA and instance B uses
poolB.

Regards
Scott




On 3/01/2018 03:04, "Nicolas Malin"  wrote:

When a job is created by an instance, there are no information on who will
be run it. So if you generate a job form an async service by the instance
A, the instance B can execute it.

Check on GenericAsyncEngine.java:108 (trunk) the job creation. If you want
to improve this, all contribution are welcome ;)

Nicolas



Le 02/01/2018 à 11:16, Trà Đá Một Mình a écrit :

> Hi all,
>
> I met a problem. I have more than one instance running my application. When
> I schedules some services using runAsync, ofbiz auto create jobs. And when
> job is started, ofbiz pick one of my instances to process. But, in my case:
> when I made an request, I dedicated this to instance A, but after that,
> when job start, it run on another instance B. I just want to it running on
> A.
>
> Thanks!
>
>

Re: Permission overrides auth parameter of service

[Scott Gray]

auth="false" and a permission service are completely incompatible
scenarios.  In what situation could you possibly have no userLogin and
successfully run a permission service?

What would you expect to happen instead of the current behavior?

Regards
Scott

On 3 November 2017 at 17:35, Suraj Khurana 
wrote:

> Hello team,
>
> I noticed that in any service definition if auth is set to false and
> permission service is also the service definition, it overrides the auth
> parameter to true by itself.
>
> For quick reference, it is written at *createPermission* method of
> *ModelServiceReader* class.
> Can someone please elaborate this behavior. IMO, this should not happen.
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> *HotWax* *Commerce* by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>

Re: [PROPOSAL] Extend returnId and shipmentId in FinAccountTrans entity

[Scott Gray]

I agree with Paul that FinAccountTrans shouldn't reference orderId or
returnId.  I have nothing to add, his reasoning is spot on.

Regards
Scott

On 21 November 2017 at 16:56, Paul Foxworthy  wrote:

> Hi Vaibhav,
>
> I'm really uncomfortable about this.
>
> As Pierre said, FinAccountTrans is for a transaction for a financial
> account (likely a bank account), rather than a transaction on an account in
> the accounting sense, i.e. an account in your chart of accounts.
>
> So a FinAccountTrans records a deposit or withdrawal to a financial
> account.
>
> It has a foreign key for a Payment. The Payment has related
> PaymentApplications, each of which apply some of the payment to an invoice.
> An order may have one or more invoices, and an order may have one or more
> shipments.
>
> So a FinAccountTrans may have several associated orders, and several
> associated shipments. Wouldn't it be an oversimplification to carry one and
> only one shipmentId in a FinAccountTrans? And if there was one in
> FinAccountTrans and anything in OFBiz used it, that would break the more
> flexible data model that we have at the moment.
>
> By the same token, I think a FinAccountTrans should not have an orderId
> either - there might be more than one.
>
> Am I missing something? Maybe what you really need is a view that
> conveniently shows the shipment or shipments related to a FinAccountTrans .
>
> Thanks
>
> Paul Foxworthy
>
>
> On 20 November 2017 at 23:41, Vaibhav Jain  >
> wrote:
>
> > Hello all,
> >
> > Currently, orderId field is available and returnId, shipmentId fields can
> > be introduced in the FinAccountTrans entity.
> >
> > These fields are useful while recording fin account transactions.
> >
> > Please let me know your thoughts on it.
> >
> > Thanks in advance
> >
> > Vaibhav Jain
> > Hotwax Systems,
> > vaibhav.j...@hotwaxsystems.com
> >
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: i...@coherentsoftware.com.au
>

Re: Service returning incorrect records

[Scott Gray]

I'm in favor of removing, it's been there since at least 2003 and is most
likely from a legacy search screen that has since been superseded.

Regards
Scott

On 15 November 2017 at 21:14, Suraj Khurana  wrote:

> Thanks, Jacques and Michael for your inputs,
>
> I agree with both the points, either such services should be removed as
> they are not being used and not written properly, or refactoring of the
> whole class with proper names as per their functionality to justify their
> name.
>
> I am willing to participate in this effort if we are more intended towards
> refactoring. Please let me know how we are proceeding in this.
>
> I have created a Jira here
> .
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> *HotWax Commerce*  by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>
>
> On Wed, Nov 15, 2017 at 2:54 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 14/11/2017 à 21:39, Michael Brohl a écrit :
> >
> >>
> >> Am 14.11.17 um 19:15 schrieb Jacques Le Roux:
> >>
> >>>
> >>> I see no reasons to drop those services if some find them useful. I get
> >>> they do since someone wrote it, even with a misleading name. Not having
> >>> them used OOTB is not a sufficient indication of removal.
> >>>
> >> I do not agree. This functionality is not used since a decade and the
> >> code is in bad shape.
> >>
> >> I think it makes much more sense to put effort in the many other fields
> >> of action we have in this project.
> >>
> >> Michael
> >>
> >>
> >>
> >> I can take care of renaming the methods, don't worry
> >
> > Jacques
> >
> >
>

Re: Unable to Launch 16.11.x in Isolation

[Scott Gray]

Yeah I learned this one the hard way after boarding a 12 hour flight.
Fortunately I had a few old copies of OFBiz lying around from back in the
good old days.

Regards
Scott

On 15 November 2017 at 05:15, Michael Brohl 
wrote:

> Reminder to self: update the (great) README.md for this switch :-)
>
> Regards,
>
> Michael
>
>
> Am 14.11.17 um 16:33 schrieb Taher Alkhateeb:
>
> ./gradlew --offline
>>
>> This question is perhaps better suited for the user mailing list.
>>
>>
>> On Nov 14, 2017 6:21 PM, "Craig Parker"  wrote:
>>
>> You're on a deserted island. Which ERP do you take with you? I'd initially
>> be thinking OFBiz, because I can be passing the time and learning it while
>> I wait for a rescue plane, but...
>>
>> I get nothing when I launch if there's no internet connection. Is there a
>> way to launch in isolation? I'm on the road, minus the internet usually,
>> but then I got to thinking that some of the more paranoid customers where
>> I
>> used to work kept their servers offline; the server and any clients
>> connecting to it were on networks totally separate from the rest of the
>> computers at their business.
>>
>> Do I really need to be connecting to the things
>> $OFBIZ_HOME/runtime/logs/console.log is indicating? I haven't tooled
>> around
>> a whole bunch, but this morning (after the server was up and running) it
>> looked like I was able to log in and click a couple links without the
>> server able to access the internet (as in, I shut my phone's hot spot
>> off).
>> Are these external calls necessary just to fire the server up? Is there a
>> way I should have gotten them sitting locally first? Google Guava appears
>> to be what I'm missing.
>>
>> Build file '/ofbiz/build.gradle' line: 976
>>
>> * What went wrong:
>> A problem occurred evaluating root project 'ofbiz'.
>>
>>> Could not resolve all dependencies for configuration ':runtime'.
>>>
>> > Could not resolve com.google.guava:guava:[11.0,).
>>   Required by:
>>   :ofbiz:unspecified > com.googlecode.owasp-java-html
>> -sanitizer:owasp-java-html-sanitizer:20160628.1
>>> Could not resolve com.google.guava:guava:[11.0,).
>>   > Failed to list versions for com.google.guava:guava.
>>  > Unable to load Maven meta-data from
>> https://jcenter.bintray.com/com/google/guava/guava/maven-metadata.xml.
>> > Could not GET 'https://jcenter.bintray.com/c
>> om/google/guava/guava/maven-metadata.xml'.
>>> jcenter.bintray.com: Temporary failure in name
>> resolution
>>
>>
>
>

Re: Updates to EntityQuery

[Scott Gray]

I think it's better to have for-update available for use for the majority
of use-cases than it is to exclude it altogether.  I'd rather lose the
databases that don't support it than constrain the ones that do and are
used most by pretty much everyone.  It would be nice to hear from anyone
using a database that doesn't support it since I'm just guessing most of us
use postgres or mysql.

Has anyone actually looked at how NoSQL databases might work with the OFBiz
entity engine or are the concepts too far removed from SQL for it to even
be workable?

If we did want to support for-update globally, we could always have the
delegator simulate it by issuing an UPDATE to lock the rows prior to
performing the SELECT.  Although it might not work perfectly in all cases,
it could be a good compromise. e.g.
UPDATE table SET lastUpdatedTxStamp = NOW() WHERE ...conditions -- lock the
rows
SELECT * FROM table WHERE ...conditions -- select the rows

Regards
Scott



On 26 October 2017 at 13:45, Paul Foxworthy  wrote:

> Hi Gareth,
>
> FOR UPDATE is standard SQL, but even so SQLite for one doesn't support it:
>
> http://sqlite.1065341.n5.nabble.com/SELECT-FOR-UPDATE-td89630.html
> https://sqlite.org/lang_select.html
>
> FOR UPDATE only makes sense for relational databases. Adding assumptions
> it's available would make it harder to use a NoSQL database in future.
>
> In the case of SQLite, in effect it's got serialized isolation anyway, so
> the FOR UPDATE is not strictly necessary.
>
> I suggest OFBiz shouldn't have a method that generates syntactically
> incorrect SQL for any database we want to support, and we claim to support
> several. Where there are variations between SQL dialects, we have
> attributes in the data source, such as "join-style".
>
> So think our choices are:
>
> 1. Add an attribute to say "SELECT ... FOR UPDATE" is supported by a data
> source. OFBiz would only add the "FOR UPDATE" if it is supported. In the
> case of SQLite, I suspect we'd get away without it, but there may be other
> databases where the absence of "FOR UPDATE" might bring on unexpected
> behaviour.
>
> 2. Don't provide a method to expose FOR UPDATE.
>
> Could you achieve the results you want with a higher transaction isolation
> level like repeatable read, or with optimistic locking (enable-lock)?
>
> What do you think?
>
> Cheers
>
> Paul Foxworthy
>
>
> On 26 October 2017 at 07:50, Gareth Carter 
> wrote:
>
> > Ok I will create a Jira with patch for review.
> >
> >
> >
> > Sent from my Samsung Galaxy smartphone.
> >
> >
> >
> > Gareth Carter
> >
> >
> > Software Development Analyst
> >
> >
> > Stannah Management Services Ltd
> >
> >
> > IT Department
> >
> >
> > Ext:
> >
> >
> > 7036
> >
> >
> > DDI:
> >
> >
> > 01264 364311
> >
> >
> >
> >
> > [http://logos.stannah.co.uk/stan150.jpg]
> >
> >
> > [http://logos.stannah.co.uk/enviro.jpg]Please consider the environment
> > before printing this email.
> >
> >
> >  Original message 
> > From: deepak nigam 
> > Date: 25/10/2017 14:06 (GMT+00:00)
> > To: dev@ofbiz.apache.org
> > Subject: Re: Updates to EntityQuery
> >
> > Looking good to me also. Let me know if I can be of any help.
> >
> >
> > Thanks & Regards
> > --
> > Deepak Nigam
> >
> > On Wed, Oct 25, 2017 at 6:26 PM, Yash Sharma <
> > yash.sha...@hotwaxsystems.com>
> > wrote:
> >
> > > I am all up for it, please let me know if I could help.
> > >
> > > Thanks & Regards,
> > > --
> > > *Pradhan Yash Sharma*
> > > *HotWax Systems* | www.hotwaxsystems.com
> > >
> > > On Wed, Oct 25, 2017 at 6:23 PM, Yash Sharma <
> > > yash.sha...@hotwaxsystems.com>
> > > wrote:
> > >
> > > > Yes, Usage of the stream will surely enhance performance to a certain
> > > > extent and removes ceremony from the code base. I think Parallel
> > streams
> > > > will add enhancements in many folds as we are using a multicore
> > processor
> > > > (I have not tested yet), but the Functional approach seems promising.
> > > >
> > > > Thanks & Regards,
> > > > --
> > > > *Pradhan Yash Sharma*
> > > > *HotWax Systems* | www.hotwaxsystems.com www.hotwaxsystems.com>
> > > >
> > > > On Wed, Oct 25, 2017 at 5:59 PM, Gareth Carter <
> > > > gareth.car...@stannah.co.uk> wrote:
> > > >
> > > >> forUpdate
> > > >>
> > > >> We patched EntityFindOptions with a new field "forUpdate" with
> > shorthand
> > > >> methods in EntityQuery to enable. We then made a change to
> > > >> GenericDAO.selectListIteratorByCondition to add "FOR UPDATE" on the
> > end
> > > >> of the SQL select statement - this allows for DB row locks (we use
> > > postgres
> > > >> and works but have not tested other databases). I believe there may
> > have
> > > >> been a discussion about this before
> > > >>
> > > >>
> > > >> forEach on EntityQuery
> > > >>
> > > >> Use Consumer in java and groovy to iterate over a query. This can
> > reduce
> > > >> memory consumption (replacement for queryList()) and boiler plate
> code
> > > (eg
> > > >> queryIterator(), whi

Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Scott Gray]

Honestly I think the topic is generic enough that OFBiz doesn't need to
provide any information at all.  Thread pool sizing is not exclusive to
OFBiz and it would be strange for anyone to modify the numbers without
first researching sources that provide far more detail than a few sentences
in our config files will ever cover.

Regards
Scott

On 12 October 2017 at 12:49, Michael Brohl  wrote:

> Hi Jacques,
>
> yes, in general I think it's best to document at the place where users do
> the configuration.
>
> In this case, I cannot say if the statement makes any sense. It can be
> from ancient times where you only had single core systems not making sense
> anymore and it can also be correct today.
>
> Maybe someone with more knowledege in this area can give us more info.
>
> Regards,
>
> Michael
>
>
> Am 12.10.17 um 14:17 schrieb Jacques Le Roux:
>
> Right, thanks Michael
>>
>> Thought some documentation is present in ThreadPool.java, I think we
>> should document that at the service serviceengine.xml level
>>
>> I mean, in general, we should document at the level used to configure,
>> not below.
>>
>> Here for instance something like "Values higher than 5 might slow things
>> down depending of your cores numbers"
>>
>> Also before written so we would have to verify why the 5 value was picked
>>
>> What do you think?
>>
>> Jacques
>>
>>
>> Le 12/10/2017 à 13:03, Michael Brohl a écrit :
>>
>>> Hi Jacques,
>>>
>>> as you said, it's just a default and the value can be configured through
>>> "max-threads".
>>>
>>> I would leave it as is.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 11.10.17 um 07:58 schrieb Jacques Le Roux:
>>>
 MAX_THREADS = 5

>>>
>>>
>>>
>>
>
>

Re: All roleType entities should maintain lifespan

[Scott Gray]

Hi Suraj,

I still haven't seen an example of a useful use case for adding
from/thruDate fields to the PartyRole table.  Did you have anything in mind
that it might help with?

I'd honestly prefer to remove it rather than expand it.

Regards
Scott

On 29 September 2017 at 20:41, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

> Hello,
>
> There has been already a discussion under OFBIZ-5959
>  regarding this.
> I would like to bring this point again into attention and would like to
> suggest that we should introduce lifespan to all such entities.
> Also, PartyRole FK constraint should be removed while adding a record of
> that party in any other role entity, earlier it was also discussed that it
> becomes cumbersome to manage that and there is not any specific need to
> have that in real time as well.
>
> Let me know your thoughts on this.
> --
> Thanks and Regards
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> *HotWax Commerce*  by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>