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

2019-05-16 Thread Michael Brohl

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 the primary internal and external parties (and their primary roles)
are captured.

What are your thoughts?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Re-designing the ‘Security’ interface

2019-05-11 Thread Michael Brohl

Hi Mathieau,

We had a discussion about deprecation in the past, I currently do not 
have the time to dig it out.


I think we should start annotating  @deprecated with the date/release 
branch when it was introduced. User should have at least time over 2 
releases to move from the old to the new implementation.


In this example, we would introduce the deprecation in trunk, so it will 
first be "visible" for users in release 19.x. We can then remove the 
deprecated code after the 20.x branch was created.


We should also start to track the deprecatations and consequently remove 
deprecated code when its time (see above). Currently there are some 
depretations for years, with no tags when they were introduced so we can 
get better at this.


Just wanted to throws this in for a first feedback, more later.

Thanks for your work!

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.05.19 um 17:53 schrieb Mathieu Lirzin:

Hello,

I have opened the ticket OFBIZ-11019 which deprecates a method in the
‘org.apache.ofbiz.security.Security’ interface (see rationale in the
JIRA ticket). If nobody disagree in the meantime, I will commit the
attached patch in a week.

With OFBIZ-11019, near half of the declarations of that interface are
now deprecated which is a symptom a poor initial design.  As a
consequence I think it is time to consider re-designing a new interface
to superseed ‘org.apache.ofbiz.security.Security’.

In order to achieve a better design, it would help if people currently
implementing ‘org.apache.ofbiz.security.Security’ outside of the
framework could describe their use-case and requirements.

If nobody step-up, It will consider that as a sign that this extension
mechanism might not be useful anymore and could be removed.

Thanks in advance.

[1] https://issues.apache.org/jira/browse/OFBIZ-11019





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Michael Brohl

Hi Aishwary,

can you elaborate a bit more why a history of GoodIdentification is needed?

It is used for identification numbers as ISBN, EAN etc.. Those numbers 
are rarely subject to change for the same product.


I don't see any use case for history tracking so I would appreciate some 
examples.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:

Hello, Devs

We should add support of fromDate and thruDate in the GoodIdentification
entity for tracking and history purpose.

As of now, if we need to update any Good Identification record for a
product, then we have to replace its value and this history isn't
maintained.
It will also enable the user to maintain multiple goodIdentifications of a
product.

Best,
*Aishwary Shrivastava* | HotWax Systems <http://www.hotwaxsystems.com/>





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] JIRA notifications and reaching contributors

2019-04-25 Thread Michael Brohl

I fully agree, Scott.

We should also not forget users using mailing list archives. It would be 
a nightmare to follow dev@ discussions on ponymail with all these Jira 
notifications.


I see no evidence that we attract more new contributors through Jira 
notifications, I assume the contrary.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 21:56 schrieb 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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, 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? And should we not revert the
resolution of the vote to have notif

Re: [DISCUSSION] JIRA notifications and reaching contributors

2019-04-25 Thread Michael Brohl

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? And should we not revert the
resolution of the vote to have notifications go back to dev@ to get more
contributions (potentially leading to more - active - committers that share
and lessen the work load?

What do you think?


[1] [VOTE] Create a "notifications" mailing list
<https://ofbiz.markmail.org/message/6hlbap7a6cam3rm2?q=%22%5BVOTE%5D+Create+a+%22notifications%22+mailing+list+%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward>



Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PROPOSAL] DataModel - Improve Internal Fields injection

2019-04-24 Thread Michael Brohl
I have not time to elaborate in-depth right now, but just a quick food 
for thought:


Having these fields in every entity *by default* allows detailed 
tracking of users which might be unwanted. I know that this is a 
sensible topic in companies and affects privacy protection.


I am not sure how the selection of entities with these fields was done, 
maybe others can add insights.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 12:40 schrieb Pierre Smits:

Thanks Michael,

So we should keep those *TxStamp fields.

But what about the second suggestion about having the  'createdByUserLogin'
and 'lastModifiedByUserLogin'  fields added to the internal fields set?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl 
wrote:


These fields are not the same, they can differ. The TX fields mark the
transaction timestamp while the non TX fields mark the "real" update
time. You can see it when you watch closely in the database. All changes
made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the model

of

each entity:

 - createdStamp
 - createdTxStamp
 - lastUpdatedStamp
 - lastUpdatedTxStamp

All of the fields above are of the field type definition 'date-time',
giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
that the createdTxStamp is the same as createdStamp  and

lastUpdatedTxStamp

is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so that

these

are always injected into the model of each entity, and always filled?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer







smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PROPOSAL] DataModel - Improve Internal Fields injection

2019-04-24 Thread Michael Brohl
These fields are not the same, they can differ. The TX fields mark the 
transaction timestamp while the non TX fields mark the "real" update 
time. You can see it when you watch closely in the database. All changes 
made within an transaction have the same tx timestamp.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the model of
each entity:

- createdStamp
- createdTxStamp
- lastUpdatedStamp
- lastUpdatedTxStamp

All of the fields above are of the field type definition 'date-time',
giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
that the createdTxStamp is the same as createdStamp  and lastUpdatedTxStamp
is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so that these
are always injected into the model of each entity, and always filled?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer





smime.p7s
Description: S/MIME Cryptographic Signature


Re: PrepareLocalesForDropDown.groovy

2019-04-16 Thread Michael Brohl
If functionality is in the codebase it might be used even if it is not 
used in the standard processes/functionality.


Better discuss than revert, I'd say.

I see no problem here.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 16.04.19 um 08:37 schrieb Pierre Smits:

Why is this even a discussion topic? Are we not going overboard here with
having to discuss everything and thus stifling furthering the code and the
project?

We should not keep stuff in the code base that is not used in production
implementations and/or for development.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Tue, Apr 16, 2019 at 8:30 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Nicolas,

Removed at revision: 1857622

Jacques

Le 15/04/2019 à 15:49, Nicolas Malin a écrit :

:) ok for me just go out

Nicolas

On 14/04/2019 20:42, Jacques Le Roux wrote:

This: plugins\example\groovyScripts\PrepareLocalesForDropDown.groovy

Le 14/04/2019 à 19:01, Nicolas Malin a écrit :

Hello

poveglia$ svn up

Actualisé à la révision 1857522.
poveglia$ find . -iname PrepareLocalesForDropDown.groovy
poveglia$

What this file ?

Nicolas

On 14/04/2019 18:44, Jacques Le Roux wrote:

Hi,

PrepareLocalesForDropDown.groovy is not used at all OOTB

Should we not remove it?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-15 Thread Michael Brohl

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-15 Thread Michael Brohl

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






smime.p7s
Description: S/MIME Cryptographic Signature


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

2019-03-20 Thread Michael Brohl

Hi Mathieu,

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.

If these changes affect the documentation, the README.md should also be 
edited to reflect them and stay in sync with the code.


Thanks for your work!

Michael

Am 19.03.19 um 00:19 schrieb m...@apache.org:

Author: mthl
Date: Mon Mar 18 23:19:44 2019
New Revision: 1855798

URL: http://svn.apache.org/viewvc?rev=1855798=rev
Log:
Improved: Merge regexps inside ‘createOfbizCommandTask’

Modified:
 ofbiz/ofbiz-framework/trunk/build.gradle

Modified: ofbiz/ofbiz-framework/trunk/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/build.gradle?rev=1855798=1855797=1855798=diff
==
--- ofbiz/ofbiz-framework/trunk/build.gradle (original)
+++ ofbiz/ofbiz-framework/trunk/build.gradle Mon Mar 18 23:19:44 2019
@@ -984,9 +984,7 @@ def createOfbizCommandTask(taskName, arg
  classpath = files(jar.outputs)
  main = ofbizMainClass
  args arguments
-
-if (taskName ==~ /^ofbiz.*--test.*/
-|| taskName ==~ /^ofbiz.*-t.*/) {
+if (taskName ==~ /^ofbiz.*(--test|-t).*/) {
  finalizedBy(createTestReports)
  }
  }






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OPTIONS] Java 11 and Java JDK origin

2019-02-28 Thread Michael Brohl

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and consequences for the 
project" thread, we created "Upgrade OFBiz to use Java JDK
Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS (Long 
Time Support), which is obviously the best current choice, but also which
Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

  1. Do we agree to use https://adoptopenjdk.net/releases.html as Java JDK 
origin OOTB?
  2. Which branches should switch to Java1? Obviously the trunk and R18 should. 
Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Welcome to Mathieu Lirzin as new committer!

2019-02-19 Thread Michael Brohl

Congratulations and welcome, Mathieu!

Happy to have you on board!

Regards,

Michael


Am 19.02.19 um 18:15 schrieb Taher Alkhateeb:

The OFBiz PMC has invited Mathieu Lirzin to become a new committer and
we are happy to announce that he has accepted this role.

Some of the reasons for inviting Mathieu include:

- He is invested in the OFBiz project and has delivered substantial
work to the code base.
- He has demonstrated solid technical skills.
- He adopts a professional attitude towards coding and software development.
- He engages thoughtfully with others and likes to work with the community.

Please join me in welcoming and congratulating Mathieu!

Cheers,
Taher Alkhateeb




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Pending works from Christian Carlow

2019-02-19 Thread Michael Brohl

Hi Taher,

you can search for issues with status "Patch available" ;-)

Best regards,

Michael


Am 19.02.19 um 16:20 schrieb Taher Alkhateeb:

+1

It would be nice to highlight somehow the tickets that have patches as
I can see some value in the work in these JIRAs.

On Tue, Feb 19, 2019 at 4:22 PM Jacques Le Roux
 wrote:

Hi,

There are a bunch of obsolete patches from Christian Carlow like in 
https://issues.apache.org/jira/browse/OFBIZ-6418 and related (from there)

I suggest we close all of them as won't do and will do so in 1 week

Jacques





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Oracle Java release model changes and consequences for the project

2019-02-13 Thread Michael Brohl

Hi Jacopo,

an alternative would be https://adoptopenjdk.net/ which provides 
prebuild packages. The scripts for package building are Apache 2.0 
licensed and they are providing Java 8 and 11 LTS versions.


Seems a good fit to me.

Since Java 8 is LTS there, we do not necessarily have to upgrade OFBiz 
for the use of Java 11.


Best regards,

Michael


Am 13.02.19 um 11:06 schrieb Jacopo Cappellato:

Considering that now Oracle JDKs are no more free for commercial use, I
think that as a community we should make it a priority to suggest a
different Java build in the README and other public documents.
The simplest alternative (because it is the closest to Oracle JDK) is the
Open JDK 11 maintained by Oracle and distributed from:
https://jdk.java.net/11/

In my opinion our README should point to it rather than:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
as it is now.
However, before we can do it, we have to resolve:
https://issues.apache.org/jira/browse/OFBIZ-10757
which should not be too difficult to achieve.

Just my two cents,

Jacopo


On Wed, Oct 24, 2018 at 2:21 PM James Yong  wrote:


Answering my last question.
 From the download page for Oracle JDK 11, demo purpose is allowed.

On 2018/10/24 07:38:19, James Yong  wrote:

Hi all,

Will the release model and licensing changes impact our demos hosted

with Apache Software Foundation?

Regards,
James

On 2018/10/24 06:54:05, James Yong  wrote:

Hi all,

OFBiz can be used as an application framework and not all business

use-case justify the yearly price-tag of Oracle JDK. Given that more
products(1) are moving to support OpenJDK, should OFBiz follow?

Regards,
James

(1) See plan of Atlasians product to support OpenJDK


https://community.atlassian.com/t5/Jira-discussions/Java-11-and-OpenJDK-support-for-Atlassian-Server-amp-Data-Center/m-p/872998#M4575


On 2018/07/31 06:35:46, Jacques Le Roux 

wrote:

Hi Michael,

How (by which mean) do you envision to "actively inform users about

our roadmap", blog, wiki or embedded documentation?

It seems the blog is not reaching all our users (needs attention).

Maybe an initial statement could be used there though.

The wiki is slowly deprecating in favour of the embedded

documentation. So I guess we will use the embedded documentation for
lasting information, right?

BTW All, I want to close OFBIZ-9226 "Check that OFBiz runs and

compile with Oracle JDK 9 (Java 9)" as unresolved and create a new similar
issue for

Java 11, what do you think?

Jacques


Le 28/07/2018 à 13:29, Michael Brohl a écrit :

Hi Mathieu,

my goal is to actively inform users about our roadmap and provide

information on how the project will deal with the new Java release model.
Users

testing OFBiz for their needs in a professional environment also

check if a project has answers to these questions so I am wrapping my mind
around it.

This is just to make clear that I am not eager to switch to newer

Java versions just for the sake of it.


Am 28.07.18 um 12:54 schrieb Mathieu Lirzin:

I wonder if we should base the OFBiz 17.12 release on Java 8 or

Java

11. We have no fixed release date yet so we might have time to

do it.

Another way would be to make a new branch which will support

Java 11.

What do people think?

I think OFBiz should be conservative in its choices.

I agree!


Given the fact Java 11 is not release yet or is about to be

released,

Java 11 will be released as GA in Sept 18. At the same time,

non-subscribed users will get no updates for Java 8 any more.

OFBiz should keep compatibity with the previous LTS release

meaning java 8.  Of course

Yes, you are right. If you focus on subscribed users, they will

get Java 8 support until September 2023 (2026 for extended subscription).

So following my thoughts to assume that users will subscribe, we

can stay with Java 8 for a while.

On the other hand, if we test Java 11 and find that we will have

few issues we can easily handle, it could be a good idea to make the switch
with

release 17.12.

I am open to both (or other) models and would like to hear more

opinions about that.

This does not mean that OFBiz should not be tested with more

recent Java

releases too.

Having an extra branch has a maintenance burden that should be

balanced

with the benefits it provides.  What benefits do you see in

having a

Java 11 branch?


This is just an alternative to the Java 11 update of the next

branch. I do not favor this because of the extra maintenance burden you
mentioned.

In conclusion, we can stick to Java 8, informing our users that

they have to subscribe for further updates.

If we do this, we should think about a roadmap/ process to change

to Java 11 in the future. This could be, for example, set up during the
release

branch 21.x or 22.x to give us enough time.

We should also, in my opinion, check/test for Java 11 and

following versions compatibility in the next months to be able to inform
users about

compatibiliti

Re: OFBiz Demo not usable

2019-02-04 Thread Michael Brohl

It's the Developer Trunk Demo - Backend Applications

Thanks,

Michael

Am 04.02.19 um 18:30 schrieb Pierre Smits:

Hi Dennis,

With which ofbiz-demo url are you experiencing this issue?

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 Mon, Feb 4, 2019 at 5:32 PM Dennis Balkir 
wrote:


Hi Devs,

it seems like the Trunk Demo is not usable at the moment.
Everytime I open it up, I just get a non-styled version of the page,
with the menu all over it and nothing else. I tried clearing browser
data, but this didn't work either.

The login page looks normal though.

I don't really know what happened, maybe someone can take a look?

Thanks and regards,
Dennis






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-02-04 Thread Michael Brohl

This is now committed, see https://issues.apache.org/jira/browse/OFBIZ-10814

Thanks,

Michael


Am 23.01.19 um 15:12 schrieb Michael Brohl:


[1] https://issues.apache.org/jira/browse/OFBIZ-10814




smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1852532 - /ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java

2019-01-31 Thread Michael Brohl
This is wrong for the monthly blog posts, they are build from the commit 
history.


Michael

Am 31.01.19 um 09:05 schrieb Pierre Smits:

It is a pity that this commit is not associated with a JIRA ticket. Now
this won't be appear in the monthly blog post, and won't appear in release
notes of upcoming releases of branches 17.12 and 18.12.

Best regards,

Pierre Smits


On Thu, Jan 31, 2019 at 8:22 AM Nicolas Malin 
wrote:


Also :),

I will do that

Nicolas

On 30/01/2019 19:55, Jacques Le Roux wrote:

Hi Nicolas,

Not in R17?

Jacques

Le 30/01/2019 à 17:18, nma...@apache.org a écrit :

Author: nmalin
Date: Wed Jan 30 16:18:00 2019
New Revision: 1852532

URL: http://svn.apache.org/viewvc?rev=1852532=rev
Log:
Fixed: Disable widget verbose property on context doesn't works for
rendering ftl template

When OFBiz render a platform specific with a ftl template file, the
widget verbosity throw function ModelWidget.widgetBoundary() was
called with parameters as context. However this function control if a
parameters is already present, so if you set a context.widgetVerbose
= false, is was ignored and widget verbosity was present for ftl
rendering.

Modified:


ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java

Modified:


ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java

URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java?rev=1852532=1852531=1852532=diff
==


---


ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java


(original)
+++


ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/HtmlWidget.java


Wed Jan 30 16:18:00 2019
@@ -149,8 +149,7 @@ public class HtmlWidget extends ModelScr
 if (location.endsWith(".ftl")) {
   try {
-Map parameters =
UtilGenerics.checkMap(context.get("parameters"));
-boolean insertWidgetBoundaryComments =
ModelWidget.widgetBoundaryCommentsEnabled(parameters);
+boolean insertWidgetBoundaryComments =
ModelWidget.widgetBoundaryCommentsEnabled(context);
   if (insertWidgetBoundaryComments) {
writer.append(HtmlWidgetRenderer.formatBoundaryComment("Begin",
"Template", location));
   }







smime.p7s
Description: S/MIME Cryptographic Signature


Re: future of OFBiz: REST is essential.

2019-01-29 Thread Michael Brohl

Hi Hans,

several people in the community are already working on REST 
implementations, I'm sure we will have one soon.


Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 29.01.19 um 06:12 schrieb Hans Bakker:

Good morning, fellow developers.

It is now almost 15 years ago i started with OFBiz. I always followed 
new technology developments and used them when they became usable in a 
production environment. That is why i joined OFBiz early. I also 
proposed years ago to go from svn to git that now finally is approved 
for OFBiz. I also proposed to replace the OFBiz framework with 
Moqui.org, yes I know a much bigger change but believe me, that will 
also happen one time for you.


We now support Moqui for about a year and the main reason we switched 
over is the excellent REST interface Moqui has. This allows you to 
have a user interface fully independent from Moqui, yes a website or a 
mobile application just using the data from Moqui via REST. All screen 
rendering is now done with for example the vue.js framework using 
javascript in the client, not using ftl at all, improving the user 
interface experience dramatically. So all templates and the rendering 
is in the client making it completely static and can be loaded from 
cdn networks.


My advise? If you want to extend the life of OFBiz implement a REST 
interface quickly...or copy it over from Moqui, no problem, the 
license allows it.


Regards,

Hans Bakker,
CEO antwebsystems.com





smime.p7s
Description: S/MIME Cryptographic Signature


Re: git commit workflow for ofbiz

2019-01-25 Thread Michael Brohl

Hi everyone,

thank you all for your feedback. It seems that we have consensus to 
switch over to Git.


I'll prepare a Wiki page to start documentation on the processes and the 
needed steps to make the switch. I'll take over the topics mentioned in 
this thread (Taher's initial proposed workflow, Jacques notes about 
build scripts, auto-props etc.).


We should then finish the process description, maybe discuss and decide 
upon and then plan the technical switch.


Makes sense?

Best regards,

Michael



Am 23.01.19 um 07:37 schrieb Jacopo Cappellato:

+1 for Git!

Jacopo

On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl 
wrote:


Hi all,

I'd like to revive this discussion again.

Personally, I am now working with git for a few years and almost all
customer and company related projects have moved to git over time. In
the beginning, I found git complicated and less straight forward, a bit
like Adrian mentioned in [1]. But once I have understood the main
principles and get used to it, I won't like to switch back to svn ever
since.

In my opinion, using git would make things much easier for
collaboration. Taher thoroughly described them in the inital thread
message.

An important point for me would be that we could prevent premature
commits just to get things to be tested. Features which take some time
to be worked on or tested can be in separate branches which can be
updated with the main branch constantly.

So, from my point of view, we should again have a disussion and/or vote
to see if the overall opinions have changed and if we could move to git.

Thanks,

Michael


[1] http://markmail.org/message/m4z5b5qevqx7n6u7

Am 24.10.15 um 10:23 schrieb Taher Alkhateeb:

Hello Everyone,

I refer to the discussion about moving to git initiated by Hans Bakker

back in April. After a long, long discussion followed by a vote the
community agreed that we should develop a more elaborate and formal
workflow to vote on, as the initial vote was not detailed enough. Based on
that, I have proposed a workflow to see if people are interested in it. But
the topic just slowly died out.

The links to both threads are listed below. I understand that there was

a lot of interest in the community as the thread was really long. I would
like to revive the discussion and see if people are still interested in
implementing / amending the proposed workflow if they find it appealing.

discussion and vote thread :

http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev=1

workflow proposition thread :

http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow

Taher Alkhateeb
- Original Message -

From: "Taher Alkhateeb" 
To: dev@ofbiz.apache.org
Sent: Wednesday, 24 June, 2015 5:25:31 PM
Subject: Re: git commit workflow for ofbiz


Hi Jacques,

Very good read, thank you for sharing.

The person who wrote complaining about gitflow (I think Adam Ruka) makes

a good point. He prefers linear to branched history. I do not mind branched
history myself as I know how to navigate it but to each his own. Either
way, The workflow can be accomplished the way he suggested by rebasing
rather than merging the history and making a few other changes like
dropping "develop". It is up to community to decide, and git is flexible
enough to accommodate any model.

Taher Alkhateeb

- Original Message -

From: "Jacques Le Roux" 
To: dev@ofbiz.apache.org
Sent: Wednesday, 24 June, 2015 4:19:42 PM
Subject: Re: git commit workflow for ofbiz

Le 24/06/2015 14:06, Jacques Le Roux a écrit :

If you get a chance to read these articles I highly recommend them



http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/

Of course don't miss

http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/

Jacques


http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful

Jacques


Le 12/05/2015 19:28, Adam Heath a écrit :

Nice. This is quite thorough. There is an option missing. SVN

committers who use git offline. In this case, their changes can be
published as

primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and

as an SVN branch, for an example.

I've read through most of what follows, and am in agreement, but I'm

dealing with hardware problems, so I need to let it sink in first.

On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:

Hi everyone,

This email refers to the thread for voting to move to git (link at

bottom) in which the vote decision was to delay and elaborate on the
workflow

first. I am not well versed in ASF guidelines and appreciate any help

and feedback and also please note some of the below is my opinion and not

necessarily 100% factual.

## First, identified problems

1. patches can quickly be outdated if not applied quickly
2. big patches are hard to audit and not desired nor preferred and It

is hard t

Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-01-23 Thread Michael Brohl

Hi Jacopo,

thanks for your repsonse!

I think it would be better to divide the concerns of the different 
concerns here and have a separate configuration to turn internal SSO 
on/off and to provide a secret for the JWT handling.


For example, if you want to use the JWT handling for another reason than 
internal SSO (e.g. REST interfaces) you would also be forced to use the 
internal SSO feature.


I'll provide my latest patch soon for review.

Best regards,Michael


Am 23.01.19 um 07:34 schrieb Jacopo Cappellato:

+1 to disabling it by default.
We could consider, rather than adding a new configuration flag, to disable
the feature if no secret is set in the configuration files (and do not
provide a secret out of the box).

Jacopo


On Sat, Jan 19, 2019 at 12:57 PM Michael Brohl 
wrote:


Hi all,

during my work in [1] I realized that the OOTB JWT authorization /
single sign on is switched on by default. The logic to retrieve the
secret key uses a default if there is no configuration in SystemProperty
or security.properties.

This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and login
using a guessed userLoginId and this token (which can be retrieved from
the code).

I think we should secure this so that this cannot be done in an OOTB
setting with the following additions:

1. make it configurable through a property which is initially turned
off. I think thi is better than commenting the preprocessor in/out
because it can be better integrated in (custom) configuration mechanisms.

2. don't use a default secret key if none is provided. The
user/administrator must explicitly set a secret key and should know what
he is doing then.

3. don't proceed if no secret key can be found (do not attempt a login
using the JWT)


I think that we should turn this feature off by default for the
following reasons:

1. it opens up a security hole if the user does not remove the
checkJWTLogin preprocessor (see above)

2. the functionality to have a single sign on between two OFBiz
instances will only be used in rare cases (I think). It is only designed
for this special case and cannot be used for standard single sign on
scenarios with other systems.

3. if it is not used, it will still try to read the authorization
header, key etc. *on every request*


What do think?

Regards,

Michael


[1] https://issues.apache.org/jira/browse/OFBIZ-10814

[2] https://jwt.io/

[3] http://jwtbuilder.jamiekurtz.com/









smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-01-22 Thread Michael Brohl

Hi Jacques,

inline...

Am 22.01.19 um 09:51 schrieb Jacques Le Roux:

Hi Michael,

It seems there is a consensus for disabling the JWT feature OOTB and 
it makes sense after testing with Postman.


Thanks, Jacques.



Rest inline:

Le 22/01/2019 à 07:43, Michael Brohl a écrit :

2. the functionality to have a single sign on between two OFBiz
instances will only be used in rare cases (I think). It is only designed
for this special case and cannot be used for standard single sign on
scenarios with other systems.


If we make this feature implicitly non-operational, what about showing 
it in example?
I guess showing it should depend of the property which switch on/off 
the JWT feature.


Yes, this would be another improvement.






3. if it is not used, it will still try to read the authorization
header, key etc. *on every request*


Yes, that's not a problem it's only few ms (if even) as long as there 
is no JWT passed. Else all the other pre-processors would also be 
concerned...



The problem is: without explicitely switching it off, it will parse a 
provided JWT token on every request *even if you don't want to use the 
SSO feature*. You might want to use the Authorization: Bearer  
header for other scenarios than SSO. Implementing a REST service for 
example, which is the reason I stumbled upon this.


Implicitely turning the feature on when the header is present is not a 
good idea, we should separate concerns.


I'm going to provide an enhanced patch for all this.

Thanks,

Michael





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-01-21 Thread Michael Brohl

Thank you all,

if there are no objections I will enhance the patch in [1] to make this 
configurable and switched off as default.


Regards,

Michael

[1] https://issues.apache.org/jira/browse/OFBIZ-10814



Am 21.01.19 um 11:41 schrieb Dennis Balkir:

+1 for off as default

Am 21.01.19 um 10:03 schrieb Taher Alkhateeb:

+1 to default off

On Sat, Jan 19, 2019 at 7:25 PM Michael Brohl 
 wrote:
No, we are mainly discussing if we should turn off the JWT 
functionality

in the default setting and what could be done to make the current
implementation more secure / fail proof.


Am 19.01.19 um 16:54 schrieb Shi Jinghai:
I've just reviewed the code of JWT implements. Sorry for my bad 
English, I'm a bit lost, are we discussing which one is more 
secure, the tomcat session or JWT?



-邮件原件-
发件人: Michael Brohl [mailto:michael.br...@ecomify.de]
发送时间: 2019年1月19日 19:58
收件人: dev@ofbiz.apache.org
主题: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

Hi all,

during my work in [1] I realized that the OOTB JWT authorization /
single sign on is switched on by default. The logic to retrieve the
secret key uses a default if there is no configuration in 
SystemProperty

or security.properties.

This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and 
login
using a guessed userLoginId and this token (which can be retrieved 
from

the code).

I think we should secure this so that this cannot be done in an OOTB
setting with the following additions:

1. make it configurable through a property which is initially turned
off. I think thi is better than commenting the preprocessor in/out
because it can be better integrated in (custom) configuration 
mechanisms.


2. don't use a default secret key if none is provided. The
user/administrator must explicitly set a secret key and should know 
what

he is doing then.

3. don't proceed if no secret key can be found (do not attempt a login
using the JWT)


I think that we should turn this feature off by default for the
following reasons:

1. it opens up a security hole if the user does not remove the
checkJWTLogin preprocessor (see above)

2. the functionality to have a single sign on between two OFBiz
instances will only be used in rare cases (I think). It is only 
designed

for this special case and cannot be used for standard single sign on
scenarios with other systems.

3. if it is not used, it will still try to read the authorization
header, key etc. *on every request*


What do think?

Regards,

Michael


[1] https://issues.apache.org/jira/browse/OFBIZ-10814

[2] https://jwt.io/

[3] http://jwtbuilder.jamiekurtz.com/








smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-01-19 Thread Michael Brohl
No, we are mainly discussing if we should turn off the JWT functionality 
in the default setting and what could be done to make the current 
implementation more secure / fail proof.



Am 19.01.19 um 16:54 schrieb Shi Jinghai:

I've just reviewed the code of JWT implements. Sorry for my bad English, I'm a 
bit lost, are we discussing which one is more secure, the tomcat session or JWT?


-邮件原件-
发件人: Michael Brohl [mailto:michael.br...@ecomify.de]
发送时间: 2019年1月19日 19:58
收件人: dev@ofbiz.apache.org
主题: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

Hi all,

during my work in [1] I realized that the OOTB JWT authorization /
single sign on is switched on by default. The logic to retrieve the
secret key uses a default if there is no configuration in SystemProperty
or security.properties.

This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and login
using a guessed userLoginId and this token (which can be retrieved from
the code).

I think we should secure this so that this cannot be done in an OOTB
setting with the following additions:

1. make it configurable through a property which is initially turned
off. I think thi is better than commenting the preprocessor in/out
because it can be better integrated in (custom) configuration mechanisms.

2. don't use a default secret key if none is provided. The
user/administrator must explicitly set a secret key and should know what
he is doing then.

3. don't proceed if no secret key can be found (do not attempt a login
using the JWT)


I think that we should turn this feature off by default for the
following reasons:

1. it opens up a security hole if the user does not remove the
checkJWTLogin preprocessor (see above)

2. the functionality to have a single sign on between two OFBiz
instances will only be used in rare cases (I think). It is only designed
for this special case and cannot be used for standard single sign on
scenarios with other systems.

3. if it is not used, it will still try to read the authorization
header, key etc. *on every request*


What do think?

Regards,

Michael


[1] https://issues.apache.org/jira/browse/OFBIZ-10814

[2] https://jwt.io/

[3] http://jwtbuilder.jamiekurtz.com/








smime.p7s
Description: S/MIME Cryptographic Signature


[DISCUSSION] turn off OOTB JWT authorization/SSO functionality

2019-01-19 Thread Michael Brohl

Hi all,

during my work in [1] I realized that the OOTB JWT authorization / 
single sign on is switched on by default. The logic to retrieve the 
secret key uses a default if there is no configuration in SystemProperty 
or security.properties.


This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and login 
using a guessed userLoginId and this token (which can be retrieved from 
the code).


I think we should secure this so that this cannot be done in an OOTB 
setting with the following additions:


1. make it configurable through a property which is initially turned 
off. I think thi is better than commenting the preprocessor in/out 
because it can be better integrated in (custom) configuration mechanisms.


2. don't use a default secret key if none is provided. The 
user/administrator must explicitly set a secret key and should know what 
he is doing then.


3. don't proceed if no secret key can be found (do not attempt a login 
using the JWT)



I think that we should turn this feature off by default for the 
following reasons:


1. it opens up a security hole if the user does not remove the 
checkJWTLogin preprocessor (see above)


2. the functionality to have a single sign on between two OFBiz 
instances will only be used in rare cases (I think). It is only designed 
for this special case and cannot be used for standard single sign on 
scenarios with other systems.


3. if it is not used, it will still try to read the authorization 
header, key etc. *on every request*



What do think?

Regards,

Michael


[1] https://issues.apache.org/jira/browse/OFBIZ-10814

[2] https://jwt.io/

[3] http://jwtbuilder.jamiekurtz.com/






smime.p7s
Description: S/MIME Cryptographic Signature


Re: git commit workflow for ofbiz

2019-01-12 Thread Michael Brohl

Hi all,

I'd like to revive this discussion again.

Personally, I am now working with git for a few years and almost all 
customer and company related projects have moved to git over time. In 
the beginning, I found git complicated and less straight forward, a bit 
like Adrian mentioned in [1]. But once I have understood the main 
principles and get used to it, I won't like to switch back to svn ever 
since.


In my opinion, using git would make things much easier for 
collaboration. Taher thoroughly described them in the inital thread message.


An important point for me would be that we could prevent premature 
commits just to get things to be tested. Features which take some time 
to be worked on or tested can be in separate branches which can be 
updated with the main branch constantly.


So, from my point of view, we should again have a disussion and/or vote 
to see if the overall opinions have changed and if we could move to git.


Thanks,

Michael


[1] http://markmail.org/message/m4z5b5qevqx7n6u7

Am 24.10.15 um 10:23 schrieb Taher Alkhateeb:

Hello Everyone,

I refer to the discussion about moving to git initiated by Hans Bakker back in 
April. After a long, long discussion followed by a vote the community agreed 
that we should develop a more elaborate and formal workflow to vote on, as the 
initial vote was not detailed enough. Based on that, I have proposed a workflow 
to see if people are interested in it. But the topic just slowly died out.

The links to both threads are listed below. I understand that there was a lot 
of interest in the community as the thread was really long. I would like to 
revive the discussion and see if people are still interested in implementing / 
amending the proposed workflow if they find it appealing.

discussion and vote thread : 
http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev=1

workflow proposition thread : 
http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow

Taher Alkhateeb
- Original Message -

From: "Taher Alkhateeb" 
To: dev@ofbiz.apache.org
Sent: Wednesday, 24 June, 2015 5:25:31 PM
Subject: Re: git commit workflow for ofbiz


Hi Jacques,

Very good read, thank you for sharing.

The person who wrote complaining about gitflow (I think Adam Ruka) makes a good point. He 
prefers linear to branched history. I do not mind branched history myself as I know how 
to navigate it but to each his own. Either way, The workflow can be accomplished the way 
he suggested by rebasing rather than merging the history and making a few other changes 
like dropping "develop". It is up to community to decide, and git is flexible 
enough to accommodate any model.

Taher Alkhateeb

- Original Message -

From: "Jacques Le Roux" 
To: dev@ofbiz.apache.org
Sent: Wednesday, 24 June, 2015 4:19:42 PM
Subject: Re: git commit workflow for ofbiz

Le 24/06/2015 14:06, Jacques Le Roux a écrit :

If you get a chance to read these articles I highly recommend them

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/

Of course don't miss 
http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/

Jacques


http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful

Jacques


Le 12/05/2015 19:28, Adam Heath a écrit :

Nice. This is quite thorough. There is an option missing. SVN committers who 
use git offline. In this case, their changes can be published as
primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and as an SVN 
branch, for an example.

I've read through most of what follows, and am in agreement, but I'm dealing 
with hardware problems, so I need to let it sink in first.

On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:

Hi everyone,

This email refers to the thread for voting to move to git (link at bottom) in 
which the vote decision was to delay and elaborate on the workflow
first. I am not well versed in ASF guidelines and appreciate any help and 
feedback and also please note some of the below is my opinion and not
necessarily 100% factual.

## First, identified problems

1. patches can quickly be outdated if not applied quickly
2. big patches are hard to audit and not desired nor preferred and It is hard 
to break big patches to smaller ones because if any of those patches
is outdated or modified then everything needs to be re-patched
3. to collaborate with other people (non-committers) freely on big features, we 
need a separate branch. On svn this is lengthy and heavily
controlled. If we create a git repository then we need to constantly update 
from svn and merge . Another solution is to clone the ofbiz read-only
git repository but then there are some patch issues to convert them to clean 
svn patches (I faced a few including things like white space)
4. a lot of _local_ offline freedom to branch, merge, commit, share and 
experiment cannot 

Re: Unused jQuery MockJax Plugin

2019-01-10 Thread Michael Brohl

Hi Aditya,

a quick search shows that it was added in r1815824 by Jacques for the 
update from Jquery 1.11.0 to JQuery 3.2.1.


Maybe it's a dependency or part of the Jquery stack?

Regards,

Michael

Am 10.01.19 um 10:07 schrieb Aditya Sharma:

Hello all,

I can't find any use of the jQuery MockJax
 Plugin included in OFBiz. If
it is not used anywhere, we can remove it.

Is there anything I am missing?

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Commerce  by HotWax Systems

[image: https://www.linkedin.com/in/aditya-p-sharma/]






smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1845558 - in /ofbiz: ofbiz-framework/trunk/framework/base/dtd/ ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/component/ ofbiz-framework/trunk/framework/comm

2019-01-07 Thread Michael Brohl

Hi Jacques,

inline...

Am 02.11.18 um 10:46 schrieb jler...@apache.org:

+// Set an autologin cookie for the webapp if it requests it
  public static String autoLoginSet(HttpServletRequest request, 
HttpServletResponse response) {
  Delegator delegator = (Delegator) request.getAttribute("delegator");
  HttpSession session = request.getSession();
  GenericValue userLogin = (GenericValue) 
session.getAttribute("userLogin");
-String domain = EntityUtilProperties.getPropertyValue("url", 
"cookie.domain", delegator);
-if (userLogin != null) {
+WebappInfo webappInfo = 
ComponentConfig.getWebappInfo("default-server", 
UtilHttp.getApplicationName(request));



This looks like it only works for webapps of the "default-server". This 
name is configurable in the ofbiz-component.xml and and should not be 
hard-coded in the code.


Am I right or do I miss something?

Regards,

Michael



+
+if (userLogin != null && webappInfo != null && 
webappInfo.isAutologinCookieUsed()) {
  Cookie autoLoginCookie = new Cookie(getAutoLoginCookieName(request), 
userLogin.getString("userLoginId"));
  autoLoginCookie.setMaxAge(60 * 60 * 24 * 365);
-autoLoginCookie.setDomain(domain);
-autoLoginCookie.setPath("/");
+autoLoginCookie.setDomain(EntityUtilProperties.getPropertyValue("url", 
"cookie.domain", delegator));
+autoLoginCookie.setPath("/" + 
UtilHttp.getApplicationName(request));
  autoLoginCookie.setSecure(true);
  autoLoginCookie.setHttpOnly(true);
  response.addCookie(autoLoginCookie);
-
+
  return autoLoginCheck(delegator, session, 
userLogin.getString("userLoginId"));
  } else {
  return "success";
  }
  }
  




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Planning for the creation of new 18.12 branches

2018-12-27 Thread Michael Brohl

Yes, that would be a solution.

I'm also fine if we would do a 19.x branch. For the future, we could aim 
to have a release more towards the middle of the year to avoid 
last-minute branching between Christmas and New Year ;-)


The above would fit perfectly with this plan:

1. create an 18.12 branch and stabilize it

2. release 17.12 ;-)

3. create a 19.x (x = {6..10} branch with the Java Upgrade


This would not break the yearly release branch and give us time for the 
Java 11 Update in 19.x. 19.x would be earlier next year so we get out of 
the end of year-hurries .


Thanks,

Michael


Am 27.12.18 um 12:38 schrieb Taher Alkhateeb:

yeah I guess that would work too if it is okay to push a big change
into that branch


On Thu, Dec 27, 2018 at 1:44 PM Deepak Dixit  wrote:

We can create a branch and can backport java upgrade changes to 18.12 as
well.
Thanks & Regards
--
Deepak Dixit



On Thu, Dec 27, 2018 at 3:21 PM Taher Alkhateeb 
wrote:


It's okay whatever folks decide, but I think it would be nice if we
can upgrade Java for a new branch.

On Thu, Dec 27, 2018 at 12:05 PM Nicolas Malin 
wrote:

Four days before the end of year :)

If no opposition, I will create it tomorrow

Nicolas

On 19/12/2018 11:44, Deepak Dixit wrote:

I agree,

We should create the next release (18.12) for framework and plugins.
I'll check for issues, and if found will share here.
Thanks & Regards
--
Deepak Dixit



On Wed, Dec 19, 2018 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 19/12/2018 à 10:14, Nicolas Malin a écrit :

Hello,

The time pass and the end year is near, maybe it's the time to

prepare

next releases branches.

Two questions :

   * Are you agree to create releases 18.12 branches for framework and

plugin ?

   * Do you have some priority issue that you absolutely need fbefore

create theses branches ?

I see for my point of view OFBIZ-4361 and OFBIZ-10145. I

believe/will/try to free some time for working on.

Cheers,

Nicolas


Hi Nicolas, All,

As I think we agreed, we need to check all the blocker before

releasing

(not freezing) .

So IMO OFBIZ-4361 and OFBIZ-10145 are not blocker for freezing a

possible

18.12 branches (trunk+plugins)

Thanks

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Plan for Releasing 17.12 branch

2018-12-22 Thread Michael Brohl
I see 56 issues to do with 
https://issues.apache.org/jira/projects/OFBIZ/versions/12338772


Thanks,

Michael

Am 19.12.18 um 11:51 schrieb Deepak Dixit:

I think we should start prepration for this as well.
Three are total 32 issues with 17.12 as affected verstion.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Resolved%2C%20%22Patch%20Available%22)%20AND%20affectedVersion%20in%20(17.12.01%2C%20%22Release%20Branch%2017.12%22)
Thanks & Regards
--
Deepak Dixit



On Thu, Nov 1, 2018 at 11:10 AM Arun Patidar 
wrote:


Hello Deepak,

Currently, don't know about any existing release plan for this but yes, we
should start planning to release 17.12.  Let's see what  other members
think about this.



Thanks & Regards
---
Arun Patidar
Director of Information SystemsHotWax Commerce 



On Thu, Oct 11, 2018 at 3:09 PM Deepak Nigam 
wrote:


Hello All,

Do we have a plan for releasing 17.12 branch of OFBiz? As it has been
almost a year since we cut the branch 17.12, we can start preparing for
this release.

Any thoughts?


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [SUGGESTION] Common .derived file and AutoDeriv Eclipse plugin

2018-12-17 Thread Michael Brohl

Hi Jacques,

who is going to decide which files you want to see and which you don't 
want so see? People have different taste on that and so you would be 
struggling with different settings checked in to the code repository.


I'm not in favor of putting these files into the repository. I think 
these are specific for each developer and it's no problem to keep them 
locally.


For your specific examples: I don't see any .class files when searching, 
that must be a configuration problem on your side. For searching, you 
can also set up filters which provide an efficient mechanism to search 
(or don't search) specific files.


Thanks,

Michael


Am 17.12.18 um 14:11 schrieb Jacques Le Roux:

Hi,

I know we don't all use Eclipse but I though want to make a suggestion.

2 years ago I put this tip at 
https://cwiki.apache.org/confluence/display/OFBIZ/Eclipse+Tips#EclipseTips-Hidefoldersfromsearches 
:



   >
   

As it's convenient, I suggest now to put the .derived file and its 
content (maybe updated) into the svn repo as we have .xmlcatalog.xml 
which is also Eclipse specific.


Can I get a consensus about that?

Jacques







smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1848673 [1/4] - in /ofbiz: ofbiz-framework/trunk/ ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/ ofbiz-framework/trunk/applications/a

2018-12-11 Thread Michael Brohl
Although I appreciate this kind of work, we should definetely commit in 
smaller chunks (package or even class level).


I thought that we agreed upon that.

Thanks,

Michael


Am 11.12.18 um 14:54 schrieb Taher Alkhateeb:

This smells very much like a mass-update which we objected to many
times before. I think without proper review this could very well
introduce bugs or issues.
On Tue, Dec 11, 2018 at 4:33 PM  wrote:






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] Checking debug levels in Java and Groovy files

2018-12-11 Thread Michael Brohl

Hi Jacques,

inline...


Am 11.12.18 um 13:42 schrieb Jacques Le Roux:

Because

1. The if condition has a cost (3 times more than nothing according to 
Mathieu's reference[1])


Yes, right, but it's certainly less costly than the direct execution of 
Debug.logXxxx... And that's the point. You don't want to run these 
statments thousands of times within a minute (in production systems), 
which is the case in central functionality like the controller.


You can only leave out the if conditions if you are sure that the 
correpsonding debug level is always on.


As I said earlier, this is not the case for verbose, debug and info on 
production systems.



2. and is not consistently used.


Who cares? Each improvement is a gain and if we only introduce these 
conditions in the hotspot functionality, it's an improvement.


It's not only black and white...

3. Using "Beautiful Logger" could be a better solution: 
https://github.com/forax/beautiful_logger

   drawbacks:
 *   needs Java 11 to build. But will we use Java 8 forever? Can 
run with Java 8.
 * "put more pressure to the JITs so it may lengthen the time to 
steady state of an application."


[1] https://www.youtube.com/watch?v=z5UkoLaW6ME (French)


Although this seems interesting, it is fairly new with the first release 
early this year. I won't recommend to introduce it until it's field 
tested (in production).


Thanks,
Michael




Jacques

Le 11/12/2018 à 12:15, Taher Alkhateeb a écrit :

We already agreed and decided to keep the if condition. I'm not sure
why this subject is being reopened.
On Mon, Dec 10, 2018 at 9:49 PM Jacques Le Roux
 wrote:
The question is quite simple. It's about always using or not the /if 
(Debug.levelOn()) {/ expression for the info and debug level as 
suggests Michael.


Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend 
for the reasons explained.


I think we all agree the /if/ /(Debug.verboseOn()) { /should always 
be used and enforced when missing.


I put all the details/arguments to easily refer to them if needed.

Also Mathieu suggested to Michael to have a look at "Beautiful 
Logger" because he is concerned by the logging performance. We could 
also have a look

at it, to see if it could be integrated OOTB.

HTH

Jacques

Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time 
to have another discussion following 
https://markmail.org/message/mplvusuqn7oshl4v

which was one year ago.

In OFBIZ-10697 I wrote:

  <  By default OOTB debug.properties sets all debug levels to be 
used but verbose. So there is no point checking other levels than 
verbose to see if
  they are used, they are anyway. So OOTB only checking 
verbose is needed. That's what developers need.


  Now you invoked production where a different 
debug.properties setting would be used. Sincerely I'd never, 
never, remove the other levels than
  verbose from a production setting (as it's OOTB). I'd even 
be quite reluctant to remove any of those levels from a production 
site running for
  years! *You never know what can happen*, and those debug 
levels are your only lifebelt in case of issues, small and big ones.


  That's my point, and that's why I see checking if a level is 
used as premature optimisation but for verbose. We need them 
anyway and IMO setting
  false for any but verbose in debug.properties in production 
would be conceited if not "suicidal" . But maybe you have use 
cases I ignore?


  Anway, I'll start a discussion in dev ML about this point. 
Like I said above and in OFBIZ-10448 
:


  I'd be all for removing the 312 useless cases but not 
the "if (Debug.verboseOn())">>


To what Michael answered

  >


I think Michael's point is perfectly valid. So I answered:

  >

So what are your opinion about that? Should we enforce as suggest 
Michael or should we remove for the reasons I wrote.


I'd prefer to be consistent. So either we enforce the checks to 
the info, verbose and debug levels. Either we only keep the 
verbose checks.


Finally Mathieu has added a grain of salt:

  <,


  If you care about the impact of loggers on performance you 
should take a look at the Beautiful Logger 

[DISCUSSION] Fix or remove CompDoc funtionality of the content manager

2018-12-08 Thread Michael Brohl

Hi all,

I'd like to drag your attention to the Jira issue Dennis created a few 
months ago [1]. The CompDoc functionality of the content manager has 
several bugs and does not seem to work properly. We should discuss if we 
either


a. fix these bugs and make the funtionality work properly? or

b. remove the functionality?

What are your thoughts?

Thanks and regards,

Michael

[1] https://issues.apache.org/jira/browse/OFBIZ-10476





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DOCUMENTATION] TOCs level and numbers

2018-12-06 Thread Michael Brohl
I‘m also in favour of keeping the section numbers.

Thanks,
Michael 

-- 
Michael Brohl
Geschäftsführer

Fon   +49 521 448 157-91
Fax   +49 521 448 157-99
Mobil +49 160 3664918

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Straße 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

> Am 06.12.2018 um 18:30 schrieb Jacques Le Roux :
> 
>> Le 03/12/2018 à 22:46, Jacques Le Roux a écrit :
>>> Le 02/12/2018 à 13:49, Mathieu Lirzin a écrit :
>>> Hello Jacques,
>>> 
>>> Jacques Le Roux  writes:
>>> 
>>>> I did not get any attention so far. So, in build.gradle, I suggest to set :
>>>> 
>>>> 'toclevels': '3'
>>>> :!sectnums:
>>> I agree with limiting the table of content level to 3, However I
>>> strongly disagree with the removal of section numbers which IME helps
>>> both in understanding the structure of the manual and in making
>>> references to a specific section.
>>> 
>> Hi Mathieu,
>> 
>> I did abuse of section numbers myself, and I now don't see what they bring. 
>> Can't we refer to the section itself? So we need a cluttering number for 
>> that, and why? What does it had? Is it not cargo cult?
>> 
>> Jacques
>> 
>> 
> No other opinions?
> 
> Jacques
> 


Re: OFBiz as Marketplace

2018-11-20 Thread Michael Brohl

Hi Taher,

I only read the thread briefly but I have the feeling that there is a 
fundamental misunderstanding with the term "marketplace".


I guess that Rishi is talking about a marketplace for selling goods by 
several independent merchants (like Amazon) while you are talking about 
a plugin marketplace.


Am I right or is it a misunderstanding on my side?

Best regards,

Michael


Am 20.11.18 um 13:50 schrieb Taher Alkhateeb:

Hi Rishi,

The plugin APIs would dominate and drive how we can use and publish
plugins, and therefore, dominate how you design the plugin market
place. So I think it might be a bit difficult to write something
without knowing how it works. Take these as an example:

- Can I push to a remote maven repository? Can I pull from a remote
maven repository? Is it only one official repository (apache) or can I
pass a command in the command line to change the repo.
- Can I protect some plugins from downloads with a username and
password (I want to sell plugins and after that you get access to my
repo)
- Should I make plugins depend on other plugins? How should that work,
manually or automatically?
- Who / how can plugins be published? What versioning scheme do we
use? How can we _upgrade_ plugins?
- What are the coding conventions for plugins? What kind of usual
install / uninstall steps are necessary

These questions and some others are affected by the technology itself.
The technology could hinder your stories if does not have the capacity
to do this or that. That's why I suggested thinking about this process
through the APIs.

I wrote the below tasks for plugins management a while ago. But they
are still not complete and require reviews and improvements to satisfy
all the stories. But this is where our starting point is:

createPlugin - create a new plugin component based on specified templates
installPlugin - executes plugin install task if it exists
pullAllPluginsSource - Download and install all plugins from source
control. Warning! deletes existing plugins
pullPlugin - Download and install a plugin with all dependencies
pullPluginSource - Download and install a plugin from source control
pushPlugin - push an existing plugin to local maven repository
removePlugin - Uninstall a plugin and delete its files
uninstallPlugin - executes plugin uninstall task if it exists

The pull and push are currently hardcoded, so we need to parameterize
the maven repository to accommodate different repos both public and
private.

I hope this is all useful and helpful, otherwise you can just ignore
everything I wrote :)

On Tue, Nov 20, 2018 at 7:37 AM Rishi Solanki  wrote:

Thanks Jacopo for your suggestion, so we will go with new plugin for
marketplace and will name it marketplace. I hope all are agree with name.

Taher, we would require at least one month (may be more) to spend on user
stories for marketplace, before writing single line of code for it. I would
be happy if I could help to complete the plugins api and deploying on maven
nexus repository. Please let me know how to proceed further and how I can
be useful. In the mean time we will proceed with user stories for
marketplace. I'm considering both as independent work can go parallel.

Please raise flag in case I misunderstood something and requires hold on
marketplace work. Thanks!

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Sat, Nov 17, 2018 at 3:05 PM Taher Alkhateeb 
wrote:


It's been a while since we worked on this, but the most important
thing to do in my opinion is the following:
1- complete the plugin API (currently written as gradle tasks) to
pull, push, and handle plugins
2- complete the work around deploying our official plugins on maven
nexus repository belonging to apache.

If anyone is willing to help, I'd love to give you an update on
everything I've done so far. But I think without having a solid plugin
API for managing plugins then adoption and a market place would be a
more challenging.
On Fri, Nov 16, 2018 at 1:50 PM Jacopo Cappellato
 wrote:

+1 to the plugin option!

Jacopo

On Fri, Nov 16, 2018 at 3:51 PM Rishi Solanki 
wrote:


Thank you Jacopo for detailed reply. It is like roadmap for

implementation

with questions may come during implementation.
Thanks Pritam, Devanshu for help offer.

I have similar line of items in my mind before proceeding with the idea
with some additional concerns on how to proceed below;

- We have two options to go with, add marketplace operator features to
ordermgr, seller profiles to partymgr and customer facing to ecommerce.
Alternatively, I preferred to add separate plugin which extends these
applications and have its own functionality. Which also take care of

any

impact on base applications.
- By adding separate plugin we will have free hand to incorporate the
marketplace specific features. Like you said that, drop ship flow is

near

to what marketplace requires. But in 

Re: svn commit: r1816105 - in /ofbiz/ofbiz-framework/trunk/themes/common: webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js webapp/images/OpenLayers-2.13.1.js widget/CommonScreens.xml widget/Theme.

2018-11-19 Thread Michael Brohl
Stumbling across this while evaluating OpenStreetMap.org integration 
with OFBiz in a customer project.


This still does not work. If I see it right, the cause are wrong image 
paths pointing to the outdated framework image folders instead of the 
theme folders.


Am 23.11.17 um 08:16 schrieb jler...@apache.org:

Author: jleroux
Date: Thu Nov 23 07:16:25 2017
New Revision: 1816105

URL: http://svn.apache.org/viewvc?rev=1816105=rev
Log:
Fixed: OpenStreetMap geolocation no longer works
(OFBIZ-)

Easily checked at
//demo-trunk.ofbiz.apache.org/example/control/ExampleOsmGeoLocationPointSet1

It "works" but OpenStreetMap images are not showing. Locally there are no errors
in log. So hopefully it could be just an OpenStreetMap needed setting change.

Since Pierre said it worked, I searched the reason.

Turned it out it was a CSP exception in my main browser (FF) due to a setting
I'm not sure about. But anyway there are CSP errors reported in browsers tools
console.

I tried to use OpenLayers-4.5.0.js but it did not work as is.

I then tried in GeoLocation.ftl to follow the officially way to use the
Official OSM tileset as protocol-independent URLs

-map.addLayer(new OpenLayers.Layer.OSM());
+<#-- Official OSM tileset as protocol-independent URLs -->
+<#noparse>
+map.addLayer(new OpenLayers.Layer.OSM(['
//a.tile.openstreetmap.org/${z}/${x}/${y}.png',
'//b.tile.openstreetmap.org/${z}/${x}/${y}.png',
'//c.tile.openstreetmap.org/${z}/${x}/${y}.png']));
+

But for a reason I did not get it did not work either.

Out of desperation this fixes it by using a modified
OpenLayers-2.13.1-modified-for-CSP-.js lib

Thanks: Pierre Smits for initially saying it was working in Safari

Added:
 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js
   - copied, changed from r1816103, 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1.js
Removed:
 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1.js
Modified:
 ofbiz/ofbiz-framework/trunk/themes/common/widget/CommonScreens.xml
 ofbiz/ofbiz-framework/trunk/themes/common/widget/Theme.xml

Copied: 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js
 (from r1816103, 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1.js)
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js?p2=ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js=ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1.js=1816103=1816105=1816105=diff
==
--- 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1.js 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/themes/common/webapp/images/OpenLayers-2.13.1-modified-for-CSP-.js
 Thu Nov 23 07:16:25 2017
@@ -606,7 +606,7 @@ b.id));a.appendChild(c);c=this.createEle
  
h=d.getAttribute("owsURL")):""!=d.getAttribute("wfs")?(g="WFS",h=d.getAttribute("wfs")):""!=d.getAttribute("wcs")&&(g="WCS",h=d.getAttribute("wcs"));d=d.getElementsByTagName("Query");0http://a.tile.openstreetmap.org/${z}/${x}/${y}.png","http://b.tile.openstreetmap.org/${z}/${x}/${y}.png","http://c.tile.openstreetmap.org/${z}/${x}/${y}.png"],attribution:";
 OpenStreetMap 
contributors",sphericalMercator:!0,wrapDateLine:!0,tileOptions:null,initialize:function(a,b,c){OpenLayers.Layer.XYZ.prototype.initialize.apply(this,arguments);this.tileOptions=
+arguments);this.tileOrigin||(this.tileOrigin=new 
OpenLayers.LonLat(this.maxExtent.left,this.maxExtent.bottom))},CLASS_NAME:"OpenLayers.Layer.XYZ"});OpenLayers.Layer.OSM=OpenLayers.Class(OpenLayers.Layer.XYZ,{name:"OpenStreetMap",url:["//a.tile.openstreetmap.org/${z}/${x}/${y}.png","//b.tile.openstreetmap.org/${z}/${x}/${y}.png","//c.tile.openstreetmap.org/${z}/${x}/${y}.png"],attribution:"
 OpenStreetMap 
contributors",sphericalMercator:!0,wrapDateLine:!0,tileOptions:null,initialize:function(a,b,c){OpenLayers.Layer.XYZ.prototype.initialize.apply(this,arguments);this.tileOptions=
  
OpenLayers.Util.extend({crossOriginKeyword:"anonymous"},this.options&)},clone:function(a){null==a&&(a=new
 OpenLayers.Layer.OSM(this.name,this.url,this.getOptions()));return 
a=OpenLayers.Layer.XYZ.prototype.clone.apply(this,[a])},CLASS_NAME:"OpenLayers.Layer.OSM"});OpenLayers.Renderer=OpenLayers.Class({container:null,root:null,extent:null,locked:!1,size:null,resolution:null,map:null,featureDx:0,initialize:function(a,b){this.container=OpenLayers.Util.getElement(a);OpenLayers.Util.extend(this,b)},destroy:function(){this.map=this.resolution=this.size=this.extent=this.container=null},supported:function(){return!1},setExtent:function(a,b){this.extent=a.clone();if(this.map.baseLayer&){var
 c=a.getWidth()/this.map.getExtent().getWidth();
  

Re: svn commit: r1845824 - /ofbiz/site/dtds/ofbiz-component.xsd

2018-11-05 Thread Michael Brohl

Hi Jacques,

isn't this an unreleased change in 17.12?

I think we should keep the version corresponding to the released 16.12 
at least until 17.12 ist released.


Much better would it be to keep consistent sets of dtds for each release 
but this would be another discussion...


Best regards,

Michael


Am 05.11.18 um 18:13 schrieb jler...@apache.org:

Author: jleroux
Date: Mon Nov  5 17:13:53 2018
New Revision: 1845824

URL: http://svn.apache.org/viewvc?rev=1845824=rev
Log:
Updates dtds on site

Modified:
 ofbiz/site/dtds/ofbiz-component.xsd

Modified: ofbiz/site/dtds/ofbiz-component.xsd
URL: 
http://svn.apache.org/viewvc/ofbiz/site/dtds/ofbiz-component.xsd?rev=1845824=1845823=1845824=diff
==
--- ofbiz/site/dtds/ofbiz-component.xsd (original)
+++ ofbiz/site/dtds/ofbiz-component.xsd Mon Nov  5 17:13:53 2018
@@ -258,7 +258,7 @@ under the License.
  
  
  
-
+
  
  
  







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Pursuing the “120 chars max” guideline

2018-10-26 Thread Michael Brohl

+1 for not reformatting all at once but only if there are changes anyway.

The patch should mention this because it will make reviews more complex.

Regards,

Michael


Am 26.10.18 um 11:13 schrieb Mathieu Lirzin:

Hello Jacques,

Jacques Le Roux  writes:


Yes you are right, the whole file should be reformatted.

This "around 120 chars max" rule is "new" (few years) and most of the
code there is more than a decade.

OK, sure.


If nobody disagree we could have a task Jira to reformat the code of
the most important classes (with subtasks maybe, or simply patches for
concerned classes).

I sympathise but I am not sure about this strategy, which depending on
the capabilities of your VCS might obscure the commit history.  I would
recommend to simply use the “120 chars max” guideline for newly added
code and when refactoring existing one.

WDYT?






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Build failed

2018-10-01 Thread Michael Brohl

Yes, you are right, Deepak.

Renaming only works for coming releases. So wee need exceptional 
conditions for the https redirect. Better file a Jira and collect what 
we have to serve on the http port, there might be other resources as 
well (no time to check now).


Thanks,

Michael


Am 01.10.18 um 13:55 schrieb Deepak Dixit:

+1
Thanks, Michale, We can do for newer releases/trunk.
But for older releases, we need to have backward compatibility as well.

Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 5:23 PM, Michael Brohl 
wrote:


I think we should consequently rename the schema location and any other
resources depending on the official website to the https address.

Regards,

Michael


Am 01.10.18 um 13:41 schrieb Deepak Dixit:

I think its due to changes done at r#1842437

While build using debug mode found following warning


17:04:57.839 [DEBUG] [TestEventLogger] 2018-10-01 17:04:57,839 |Test
worker  |UtilXml   |W|
[UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
with
publicId [null] and the file/resource is [entity-config.xsd]


UtilXml fails to read the entity-config.xsd file as entityengine.xml using
the following URL

http://ofbiz.apache.org/dtds/entity-config.xsd


I think we need to update the noNamespaceSchemaLocation or exclude the
dtds folder in redirect rule.
Exclusion looks good to me in this case.

any other opinion?


Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 4:56 PM, Pritam Kute <
pritam.k...@hotwaxsystems.com>
wrote:

Same here. About to write an email. :)

Thanks and Regards
--
Pritam Kute

On Mon, Oct 1, 2018 at 4:43 PM Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

Hello team,

I am getting this exception after re-starting OFBiz server. I used
./gradlew cleanAll ofbiz and got this exception:

===

:test

org.apache.ofbiz.entity.util.EntitySaxReaderTests > parse FAILED
  java.lang.IllegalStateException at EntitySaxReaderTests.java:82

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingConstructorFailsIfConfigurationIsMissing FAILED
  java.lang.AssertionError

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingFactoryGetDelegator FAILED
  java.lang.AssertionError at DelegatorUnitTests.java:87

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingFactoryGetInstance FAILED
  java.lang.AssertionError at DelegatorUnitTests.java:75

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingConstructor FAILED
  org.apache.ofbiz.entity.GenericEntityConfException at
DelegatorUnitTests.java:63

29 tests completed, 5 failed
:test FAILED

FAILURE: Build failed with an exception.

===

Is anyone else facing similar issue ?

--
Best Regards,
Suraj Khurana
Omnichannel OMS Technical Expert
HotWax Systems









smime.p7s
Description: S/MIME Cryptographic Signature


Re: Build failed

2018-10-01 Thread Michael Brohl
I think we should consequently rename the schema location and any other 
resources depending on the official website to the https address.


Regards,

Michael


Am 01.10.18 um 13:41 schrieb Deepak Dixit:

I think its due to changes done at r#1842437

While build using debug mode found following warning


17:04:57.839 [DEBUG] [TestEventLogger] 2018-10-01 17:04:57,839 |Test
worker  |UtilXml   |W|
[UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with
publicId [null] and the file/resource is [entity-config.xsd]


UtilXml fails to read the entity-config.xsd file as entityengine.xml using
the following URL

http://ofbiz.apache.org/dtds/entity-config.xsd


I think we need to update the noNamespaceSchemaLocation or exclude the
dtds folder in redirect rule.
Exclusion looks good to me in this case.

any other opinion?


Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 4:56 PM, Pritam Kute 
wrote:


Same here. About to write an email. :)

Thanks and Regards
--
Pritam Kute

On Mon, Oct 1, 2018 at 4:43 PM Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:


Hello team,

I am getting this exception after re-starting OFBiz server. I used
./gradlew cleanAll ofbiz and got this exception:

===

:test

org.apache.ofbiz.entity.util.EntitySaxReaderTests > parse FAILED
 java.lang.IllegalStateException at EntitySaxReaderTests.java:82

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingConstructorFailsIfConfigurationIsMissing FAILED
 java.lang.AssertionError

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingFactoryGetDelegator FAILED
 java.lang.AssertionError at DelegatorUnitTests.java:87

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingFactoryGetInstance FAILED
 java.lang.AssertionError at DelegatorUnitTests.java:75

org.apache.ofbiz.entity.DelegatorUnitTests >
delegatorCreationUsingConstructor FAILED
 org.apache.ofbiz.entity.GenericEntityConfException at
DelegatorUnitTests.java:63

29 tests completed, 5 failed
:test FAILED

FAILURE: Build failed with an exception.

===

Is anyone else facing similar issue ?

--
Best Regards,
Suraj Khurana
Omnichannel OMS Technical Expert
HotWax Systems






smime.p7s
Description: S/MIME Cryptographic Signature


Re: "Not Secure" in the Google Chrome browser

2018-10-01 Thread Michael Brohl

Thank you, Deepak!

Regards,

Michael


Am 01.10.18 um 10:25 schrieb Deepak Dixit:

Thanks Michael,

I just discuss this with our sysadmin, and he suggests the same as your
solution :)

Let me commit this.


Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 1:45 PM, Michael Brohl 
wrote:


Hi Deepak,

I would suggest

===

RewriteCond %{HTTPS} off
RewriteRule ^\/?(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

===


1st statement just checks if https is not active, independent of the ports
used.

2nd statement does a 301 redirect telling Google that it is permanent.

Regards,

Michael


Am 01.10.18 um 08:32 schrieb Deepak Dixit:

Thanks Jacques,

Following rule should work.
=
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://ofbiz.apache.org/$1 [R,L]
=

Please confirm if it looks good.

Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 11:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

That's quite a  good idea Deepak

Jacques



Le 01/10/2018 à 07:30, Deepak Dixit a écrit :

We have .htaccess file, we can write redirect rule in this file.

Thanks & Regards
--
Deepak Dixit


On Sun, Sep 30, 2018 at 3:51 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Few important articles from Google's official security blog site:


https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html
https://security.googleblog.com/2015/12/indexing-https-
pages-by-default.html
https://security.googleblog.com/2017/04/next-steps-toward-
more-connection.html
https://security.googleblog.com/2018/02/a-secure-web-is-here
-to-stay.html

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 <http://www.hotwaxsystems.com/>



On Sun, Sep 30, 2018 at 3:31 PM Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Thanks, Jacques, Please feel free to get it done and let me know if
some


help is required from my side. Thanks!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 <http://www.hotwaxsystems.com/>



On Sun, Sep 30, 2018 at 1:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

We can handle it ourselves. It's puppetised. The file is


infrastructure-puppet\data\roles\tlpserver.yaml at
https://github.com/apache/infrastructure-puppet.git in

origin/deployment

branch


OFBiz block is

ofbiz:
vhost_name: '*'
port: 80
servername: 'www.ofbiz.org'
docroot: '/www/ofbiz.apache.org'
manage_docroot: false
serveraliases:
  - 'ofbiz.org'
serveradmin: 'us...@infra.apache.org'
access_log_file: '/x1/logs/weblog.log'
error_log_file: '/x1/logs/errorlog.log'
custom_fragment: |
  Redirect permanent / http://ofbiz.apache.org/
  UseCanonicalName On
  RewriteEngine On
  RewriteOptions inherit

  # bigfiles.ofbiz.org
  RewriteCond ${lowercase:%%{}{HTTP_HOST}}
^bigfiles(?:\.\w+)?\.ofbiz\.org$
  RewriteRule (.*) http://ofbiz-bigfiles.apache.org/ [L]

So we should add a ssl block and redirect http block to https as
explained at https://wiki.apache.org/httpd/RedirectSSL

We can do a PR for that. Then it's better with an INFRA Jira because

it's

then seen and prioritised by the Infra team


Jacques


Le 30/09/2018 à 08:03, Taher Alkhateeb a écrit :

+1

I'm not sure any effort is needed from our side? We just need to

coordinate

with infra right?

On Sun, Sep 30, 2018, 8:01 AM Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Hello Team,


I think we should put some effort and make it work like if some
user

hits

http://ofbiz.apache.org(default port http) then the user is
redirected to
https://ofbiz.apache.org(Secure port https)


For now, the user sees a message "Not Secure" in the Google Chrome

browser

URL if the user comes to the official ofbiz website. This message
can


confuse the end user and he can move away if he is the new user

visiting

the project website.


This issue can be easily addressed by setting up the apache

redirects.

This
change will also help the project URLs from SEO point of view.

Please share your thoughts then we can plan the things accordingly.
Thanks!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 <http://www.hotwaxsystems.com/>










smime.p7s
Description: S/MIME Cryptographic Signature


Re: "Not Secure" in the Google Chrome browser

2018-10-01 Thread Michael Brohl

Hi Deepak,

I would suggest

===

RewriteCond %{HTTPS} off
RewriteRule ^\/?(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

===


1st statement just checks if https is not active, independent of the 
ports used.


2nd statement does a 301 redirect telling Google that it is permanent.

Regards,

Michael


Am 01.10.18 um 08:32 schrieb Deepak Dixit:

Thanks Jacques,

Following rule should work.
=
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://ofbiz.apache.org/$1 [R,L]
=

Please confirm if it looks good.

Thanks & Regards
--
Deepak Dixit


On Mon, Oct 1, 2018 at 11:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


That's quite a  good idea Deepak

Jacques



Le 01/10/2018 à 07:30, Deepak Dixit a écrit :


We have .htaccess file, we can write redirect rule in this file.

Thanks & Regards
--
Deepak Dixit


On Sun, Sep 30, 2018 at 3:51 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Few important articles from Google's official security blog site:

https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html
https://security.googleblog.com/2015/12/indexing-https-
pages-by-default.html
https://security.googleblog.com/2017/04/next-steps-toward-
more-connection.html
https://security.googleblog.com/2018/02/a-secure-web-is-here
-to-stay.html

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 



On Sun, Sep 30, 2018 at 3:31 PM Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Thanks, Jacques, Please feel free to get it done and let me know if some

help is required from my side. Thanks!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 



On Sun, Sep 30, 2018 at 1:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

We can handle it ourselves. It's puppetised. The file is

infrastructure-puppet\data\roles\tlpserver.yaml at
https://github.com/apache/infrastructure-puppet.git in


origin/deployment
branch

OFBiz block is

ofbiz:
   vhost_name: '*'
   port: 80
   servername: 'www.ofbiz.org'
   docroot: '/www/ofbiz.apache.org'
   manage_docroot: false
   serveraliases:
 - 'ofbiz.org'
   serveradmin: 'us...@infra.apache.org'
   access_log_file: '/x1/logs/weblog.log'
   error_log_file: '/x1/logs/errorlog.log'
   custom_fragment: |
 Redirect permanent / http://ofbiz.apache.org/
 UseCanonicalName On
 RewriteEngine On
 RewriteOptions inherit

 # bigfiles.ofbiz.org
 RewriteCond ${lowercase:%%{}{HTTP_HOST}}
^bigfiles(?:\.\w+)?\.ofbiz\.org$
 RewriteRule (.*) http://ofbiz-bigfiles.apache.org/ [L]

So we should add a ssl block and redirect http block to https as
explained at https://wiki.apache.org/httpd/RedirectSSL

We can do a PR for that. Then it's better with an INFRA Jira because


it's
then seen and prioritised by the Infra team

Jacques


Le 30/09/2018 à 08:03, Taher Alkhateeb a écrit :


+1

I'm not sure any effort is needed from our side? We just need to


coordinate


with infra right?

On Sun, Sep 30, 2018, 8:01 AM Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

Hello Team,

I think we should put some effort and make it work like if some user


hits
http://ofbiz.apache.org(default port http) then the user is
redirected to
https://ofbiz.apache.org(Secure port https)

For now, the user sees a message "Not Secure" in the Google Chrome


browser
URL if the user comes to the official ofbiz website. This message can

confuse the end user and he can move away if he is the new user


visiting
the project website.

This issue can be easily addressed by setting up the apache


redirects.

This

change will also help the project URLs from SEO point of view.

Please share your thoughts then we can plan the things accordingly.
Thanks!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Upgrading the Authorize.net AIM API

2018-09-26 Thread Michael Brohl

+1

Once there is an agreement for the integration strategy, we can update 
all 3rd party integrations accordingly.


This should not block any work on integration updates.

Regards,

Michael


Am 26.09.18 um 03:00 schrieb 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








smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1841675 - /ofbiz/tools/verify-ofbiz-release.sh

2018-09-22 Thread Michael Brohl

Hi Mathieu,

thanks for the hint!

There is no portability requirement, I once wrote this script to ease 
the release checks and shared it with the community.


I changed the code so that there is no need for exporting the setting 
anymore.


Regards,

Michael


Am 22.09.18 um 14:41 schrieb Mathieu Lirzin:

Hello Michael,

mbr...@apache.org writes:


  # use english gpg output
-LC_MESSAGES=en_EN.UTF-8
+export LC_MESSAGES=en_EN.UTF-8

This syntax is a bashism.  I don't know the portability requirements for
this script, but I would recommend using this syntax instead:

   LC_MESSAGES=en_EN.UTF-8
   export LC_MESSAGES

Thanks.






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [VOTE] [RELEASE] Apache OFBiz 16.11.05

2018-09-22 Thread Michael Brohl

+1

Everything is ok:

$ ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-16.11.05.zip
sha check of file: apache-ofbiz-16.11.05.zip
Using sha file: apache-ofbiz-16.11.05.zip.sha512
apache-ofbiz-16.11.05.zip: 9D0C613C C3D88C37 A5A41F53 55F0D6A0 A465AB29 
00987DF6 5070BBA6 4DCA43B4 1C8C44DB E7A1BBA5 4528AE17 04B45DE8 722F702E 
9C13508A 0CD900A1 3F1D3B1B
apache-ofbiz-16.11.05.zip: 9D0C613C C3D88C37 A5A41F53 55F0D6A0 A465AB29 
00987DF6 5070BBA6 4DCA43B4 1C8C44DB E7A1BBA5 4528AE17 04B45DE8 722F702E 
9C13508A 0CD900A1 3F1D3B1B

sha checksum OK

GPG verification output
gpg: Signature made Mon Sep 17 11:02:30 2018 CEST using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
" [ultimate]



$ ./gradlew loadDefault testIntegration

...

BUILD SUCCESSFUL


Thanks Jacopo,

Michael

Am 21.09.18 um 16:26 schrieb Jacopo Cappellato:

  This is the vote thread to release a new bug fix release for the
release16.11 branch. This new release, "Apache OFBiz 16.11.05" will
supersede all the previous releases from the same branch.

The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-16.11.05.zip
* KEYS: text file with keys
* apache-ofbiz-16.11.05.zip.asc: the detached signature file
* apache-ofbiz-16.11.05.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 16.11.05
[ -1] do not release

This vote will be open for at least 5 days.

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

Kind Regards,

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature


Re: OFBiz CRM for ASF Fundraising Team

2018-09-17 Thread Michael Brohl
FYI: 
https://lists.apache.org/thread.html/0d6f8fb7006f8a8c291df3cf0c15c1a743532e6b1a74b2f6c5fcdd53@%3Cdev.community.apache.org%3E


Best regards,

Michael

Am 29.07.18 um 16:15 schrieb Sharan Foga:

Hi All

I’ve received an enquiry from Daniel Ruggeri from the ASF Fundraising team 
asking about the possibility of using OFBiz CRM to manage their processes. I’m 
hoping to setup a call with him later this week to talk about their 
requirements.

This could be great news for OFBiz so will let you know what happens and bring 
that information back to this list.

Thanks
Sharan





smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1840659 - in /ofbiz/ofbiz-framework/trunk/applications: order/template/order/OrderShippingInfo.ftl product/minilang/shipment/shipment/ShipmentServices.xml product/servicedef/services_

2018-09-12 Thread Michael Brohl

Hi Jacques, all,

I think these renames are problematic for exitsing users who might use 
these services in their productive environments.


We should agree upon a "deprecation period" where these changes are 
announced but not implemented and implement them in the next major release.


We also need a proper documentation/changelog for these changes between 
major releases to allow for easy migration. The changelog and/or 
documentation should be part of the commit.


What do you and others think?

Regards,

Michael

Am 12.09.18 um 13:09 schrieb jler...@apache.org:

Author: jleroux
Date: Wed Sep 12 11:09:50 2018
New Revision: 1840659

URL: http://svn.apache.org/viewvc?rev=1840659=rev
Log:
Improved: [Naming Convention] Change 'quickShipPurchaseOrder' to
'quickReceivePurchaseOrder'
(OFBIZ-10558)

We have the option of 'Quick Receive Purchase Order' from Order Overview screen.
In the feature, the request and service name is 'quickShipPurchaseOrder which
is confusing. Change the name to 'quickReceivePurchaseOrder'.

Thanks: Deepak Nigam for the patch and Suraj Khurana for review

Modified:
 
ofbiz/ofbiz-framework/trunk/applications/order/template/order/OrderShippingInfo.ftl
 
ofbiz/ofbiz-framework/trunk/applications/product/minilang/shipment/shipment/ShipmentServices.xml
 
ofbiz/ofbiz-framework/trunk/applications/product/servicedef/services_shipment.xml
 
ofbiz/ofbiz-framework/trunk/applications/product/webapp/facility/WEB-INF/controller.xml

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/template/order/OrderShippingInfo.ftl
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/template/order/OrderShippingInfo.ftl?rev=1840659=1840658=1840659=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/template/order/OrderShippingInfo.ftl
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/template/order/OrderShippingInfo.ftl
 Wed Sep 12 11:09:50 2018
@@ -69,7 +69,7 @@ under the License.
  <#if ownedFacilities?has_content>
<#if !allShipments?has_content>

- 
+ 
 
 
 <#-- destination form 
(/facility/control/ReceiveInventory) wants purchaseOrderId instead of orderId, so we 
set it here as a workaround -->
@@ -83,7 +83,7 @@ under the License.
   


-
+




Modified: 
ofbiz/ofbiz-framework/trunk/applications/product/minilang/shipment/shipment/ShipmentServices.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/product/minilang/shipment/shipment/ShipmentServices.xml?rev=1840659=1840658=1840659=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/product/minilang/shipment/shipment/ShipmentServices.xml
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/product/minilang/shipment/shipment/ShipmentServices.xml
 Wed Sep 12 11:09:50 2018
@@ -1359,12 +1359,12 @@ under the License.
  
  
  
-

+
  
  
  
  
-
+
  
  
  


Modified: 
ofbiz/ofbiz-framework/trunk/applications/product/servicedef/services_shipment.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/product/servicedef/services_shipment.xml?rev=1840659=1840658=1840659=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/product/servicedef/services_shipment.xml
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/product/servicedef/services_shipment.xml
 Wed Sep 12 11:09:50 2018
@@ -85,8 +85,8 @@ under the License.
  
  
  
-
+
  The mirror of quickShipEntireOrder, this service 
automatically creates shipments for an entire purchase order.
All order items on each ship group is created as a Shipment.  All 
items on a Shipment are automatically issued to a Package.
The shipment's status is first set to CREATED and then set as 
SHIPPED.  The facilityId is used to set the destinationFacilityId

Modified: 
ofbiz/ofbiz-framework/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/product/webapp/facility/WEB-INF/controller.xml?rev=1840659=1840658=1840659=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
 Wed Sep 12 11:09:50 2018
@@ 

Re: Should we keep the multi-tenants feature in OFBiz?

2018-08-29 Thread Michael Brohl
Before we deprecate this feature (if ever) we should provide a well 
designed, fully tested and established alternative as well as a 
migration path and good documentation.


I propose to do any work on this in another branch to prevent any 
distraction in trunk until this change is fully established. I assume 
that this is going to be a longer task...


Regards,

Michael


Am 29.08.18 um 12:36 schrieb Jacques Le Roux:

Yes you are right, I'll start a discussion on user ML.

I already know that Pierre Smits uses it for his own projects, and 
indeed we know there are more people using it.


This said it should not prevent us to deprecate it and users to 
continue to use it based on R17 branch.


They could then switch later to the replacing feature. If we do so, we 
should try to deliver a migration tool, maybe with their interested 
help...


At the end it's the dev community to decide, we can get blocked by our 
users, notably because there are issues pending for too long, w/o much 
interest.


Let's see on user ML

Jacques


Le 29/08/2018 à 12:05, Taher Alkhateeb a écrit :

Multi-tenancy complicates things, and the code could be made simpler
by removing it in many areas of the system. So technically, I'm for
that.

However, the issue here is whether enough people depend on it. I saw
multiple questions in the mailing list in the past about multi-tenancy
in the past, so I'm just not sure if people depend on it or not. Maybe
shooting that question in the user ML would help shed some perspective
on it?

With our appreciation for all the good work people are doing in their
projects, I think we should be focused on OFBiz and what is best for
_this_ project. If some project decides to drop multi-tenancy I don't
think we should be influenced or automatically follow suit. So naming
who-did-what might not important for this discussion and we need to
bake our own bread.
On Wed, Aug 29, 2018 at 12:45 PM Jacques Le Roux
 wrote:

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe 
even few hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not 
millions (actually they failed), of tenants, obviously OFBiz can't 
do that.


I don't break any secret to say that I was working with David (and 
Andrew) on a project in 2010 when David had to quickly answer to the 
client's
demand who wanted to have tenants. David brilliantly and quickly 
delivered, but it was only a start.


After many improvements, this feature still have some issues
  https://issues.apache.org/jira/browse/OFBIZ-6066
  https://issues.apache.org/jira/browse/OFBIZ-7900
  https://issues.apache.org/jira/browse/OFBIZ-6164
  https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
  https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
  https://issues.apache.org/jira/browse/OFBIZ-7112
  https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article

https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ 



and, after my experiences with multi-tenant as is in OFBiz, it made 
me wonder if we should not think about how it's done now in OFBiz in 
2018 with the

clouds being everywhere!

Before sending this email, I quickly exchanged with David about how 
Moqui handles that now. And we are on the same page, see


https://www.linkedin.com/groups/4640689/4640689-6180851287941201924

https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 
[1]


[1] Initially David gave me this link

https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ 



but it seems LinkedIn has lost it, as said in the stackoverflow 
comment.


So IMO why not deprecating the multi-tenants as is now and rather 
push a multi-instances way?


Opinions?

Jacques








smime.p7s
Description: S/MIME Cryptographic Signature


Re: Issue with opening a bookmarked page when the user is logged out

2018-08-26 Thread Michael Brohl
OFBiz handles multiple request parameters with the same name well if you 
use POST requests.


For GET requests, there seem to be no standard for multiple parameters 
with the same name, see [1]. I thinks it would be good to investigate 
further and see if we can fix this.


I don't see a problem with REST here, the data will most probably 
transferred in some kind of JSON structure.


[1] 
https://stackoverflow.com/questions/24059773/correct-way-to-pass-multiple-values-for-same-parameter-name-in-get-request#24728298


Regards,

Michael


Am 26.08.18 um 07:09 schrieb Taher Alkhateeb:

Hmmm, based on Girish's feedback I think perhaps the next step should be to
open a JIRA and further investigate. Thinking about it some more, maybe
this would have an impact on the REST API project we're working on.

On Sun, Aug 26, 2018, 7:57 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hi Ritesh

It does look like an issue to me.

I believe (correct me if I am wrong) it is not so much about whether GET is
appropriate here, it is more about that the framework is unable to handle
multiple request parameters with same name, which is a common case when we
talk about multiple check boxes on a form representing a single entity. The
fact that GET is doing it's job correctly when the user is logged in (means
when you change the method from POST to GET and the user is already logged
in) and not so much when the user is logged out and the request is made via
bookmark, shows that the code is not working properly.

Then, there is also an issue with URL encoding and decoding that becomes
apparent with executing your scenario. Whether it is correct to change the
form method is arguable, but the code should be able to handle it. If a
form were to be designed with GET method and the only elements present on
the form are two check boxes and a text field and if you were to select
both check boxes and have value with spaces in the text box, this scenario
would still fail.

I think the simplest approach would have been to just store query string
(request.getQueryString()) in the session attribute instead of Map (but I
think it was well pondered upon to use Map) and then just redirecting to
the saved URL once the user loges in. I did it on my local workstation and
it just worked perfectly. May be one reason why a map was used instead of
storing query string was to handle unencoded requests coming from browsers
such as IE. I may be wrong so please correct me if anyone has an idea
around this piece of code as to why Map was used instead of storing the
query string in session to be used later on.

If you can do something to fix the existing code, that would be better
approach, IMO.

May be it is not a major issue but certainly worthy of having a dedicated
JIRA for. Everybody, please chime in and provide your thoughts.

Thanks and Best regards,
Girish Vasmatkar
HotWax Systems

On Sat, Aug 25, 2018 at 8:03 PM Taher Alkhateeb <
slidingfilame...@gmail.com>
wrote:


Okay, I understand this issue. I don't think it is possible to
abstract away a complex search screen with http GET method for
bookmarks. The performFind service is quite complex and it is
difficult to replicate the requirements using GET. GET is not designed
to handle multiple languages, spaces, and other peculiarities that are
needed for such a screen to work.

There are multiple solutions that I can see here. One of them is
simply to create a new entity, let's call it SearchFilter, that saves
search parameters, which can be applied later on. Either way, you need
to customize, your problem is not OFBiz, your problem is http GET
limitations.
On Fri, Aug 24, 2018 at 12:35 PM Ritesh Kumar
 wrote:

Using the POST method does not append form data to the URL, i.e, the
parameters will not be visible in the URL.
For example, take a Find Screen (say, FindWorkEffort) which send data
through a form with POST method. Apply some filters (say, status). No
applied filters appear in the URL.  Bookmark this page. Next time when

I

open this bookmark, those applied filters will not be there as this

page

is

being rendered using data from the URL and since the applied filters

were

not there in the bookmarked URL, this page is rendered without the

applied

filters. That is why I used GET form method so that I am able to get

the

page with applied filters when I open a bookmarked page.

The bug here is (supposing the GET method is used)
1. On opening the bookmark, the page is rendered with double encoding

(if

the value had a space character initially, the space character was

already

encoded into '+' in the URL and when this bookmark is opened, this '+'

is

again encoded).
2. Suppose the bookmarked URL had multiple values from the same filter
(say, Cancelled and Declined status), it renders with just one of the
statutes applied. It is because the request handler prepares a Map of
parameters from the query string and as is the property of Map to

replace

the old value if a new 

Re: Old demo restarted

2018-08-24 Thread Michael Brohl
There is no need to implement anything in OFBiz to monitor it's metrics 
or the underlying OS.


For the metrics, we can simply use JMX and the OS metrics can be 
retrieved by onboard tools or additional tools on the server.


I would be in favor of not using any third party tools from outside 
which collect data like Jacques has already setup. We should use tools 
running on the server itself or running on other ASF servers.


Reagrds,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 24.08.18 um 11:20 schrieb Pierre Smits:

I may be mistaken, but it seems to me that a lot of functions of OS
monitoring tools (think Nagios, Munin, and more commercial products like
DataDog) cover several aspects mentioning in this thread and some of the
features therein are to be replicated into the OFBiz solution.

If that is the case I expect a lot work (and a lengthy implementation
track) to be required with minimal added value to adopters.


Best regards,

Pierre Smits


On Fri, Aug 24, 2018 at 10:07 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


Okay all neat ideas, I'm not sure if the energy you will put into something
like this is equal to the value produced but if you want to make this
happen I would be happy to assist.

How much time will it take to make something like this happen? I ask
because it seems Jacques ia getting annoyed with these crashes and we'd
like to help him out.







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Old demo restarted

2018-08-24 Thread Michael Brohl

We are monitoring our OFBiz instances with JMX and self hosted Zabbix [1].

Zabbix gives you a nice overview about the system health and metrics 
like memory  consumption etc. It also sends out warnings (Email, SMS or 
else) if metrics are exceeded (like CPU load or memory consumption) as 
well as the system is not accessible.


Looks like this: [2]

There is no programming needed, just some configuration for JMX and Zabbix.

[1] https://www.zabbix.com/
[2] https://www.ecomify.de/wp-content/uploads/2018/08/Zabbix_Monitoring.png

If we want to see why the demos crash, it might be useful. If we only 
want to monitor if the system is up, a simple cron job which sends a 
mail might be enough...


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 24.08.18 um 10:07 schrieb Taher Alkhateeb:

Okay all neat ideas, I'm not sure if the energy you will put into something
like this is equal to the value produced but if you want to make this
happen I would be happy to assist.

How much time will it take to make something like this happen? I ask
because it seems Jacques ia getting annoyed with these crashes and we'd
like to help him out.

On Fri, Aug 24, 2018, 10:59 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hi Taher

Please see my reply below in-line.

On Fri, Aug 24, 2018 at 12:22 PM Taher Alkhateeb <
slidingfilame...@gmail.com>
wrote:


Hi Girish, inline...

On Thu, Aug 23, 2018, 7:25 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


I had earlier replied to this thread but looks like the email did not

go

through. I had leaned towards using the tool (only just) instead of may

be

having a CRON job or an alternative.

What I feel now is that may be we can use JMX here and try to use

various

in build MBeans that provide CPU usage for the system and also for the

JVM

process we are concerned about that is OFBiz instance. We should also

be

able to get the memory usage of the JVM and if reaches a particular
threshold we can be notified.


Do you have a PoC for all of this?


GV : I can have one ready; and there is going to be much doing involved.


In addition, I think we already add a shutdown hook to the JVM

process... I

am not sure and have not used it much but may be we can use it to send

some

notifications? Of course, it is applicable for graceful exits of JVM

only

and if you just happen to kill the process it won't be of much help.


The shutdown hook is used for shutting down. I'm not sure what is the
purpose of mentioning it here?


 GV : The reason I mentioned shutdown hook was it can be used to send
notification (may be email) or anything per our needs indicating that the
demo process was shut down. Per my understanding, shutdown   hook gets
called whenever JVM shuts down gracefully. Graceful word is very important
here because we won't be able to do much if someone just kills the process.
The only thing a shutdown hook will add to this is that we will be notified
then and there.


Hope it makes sense and correct me if I am wrong.

Well I'm struggling a bit. I didn't understand exactly what needs to be
done? I see mixed topics about JMX, Mbeans, Memory monitors and shutdown
hooks. First this seems to be more like coding than a tool, and second I
have no idea how you want to implement this?


 GV: Yes, it would mostly be coding rather than being a substitute for
the tool. My idea was that to have a timer service run within the JVM and
it access various MBeans for the CPU usage and Memory usages just for our
monitoring purpose and raise an alert if it reaches a threshold. It was
just to have a glance over how JVM is performing. The disadvantage? The
service will run in OFBiz JVM and there will be considerable amount of
coding involved.


My idea for example is simple: create a cronjob that checks the system
periodically and if the demo process stopped, restart it (or maybe

rebuild

and restart). To go with your suggestion we need to perhaps first
understand it.


GV: There is nothing wrong with creating a CRON job, per se. The only
reason why I introduced MBeans in the mix was to be able to sort of having
OFBiz monitor itself within it's realm, hence use of MBeans. I believe a
CRON will be able to do it as well. I probably did not get that we probably
want something that take some action after the JVM has crashed and not
having something that monitors the process and alerts concerned parties
that the process is occupying more than say 2 GB or it's CPU usage has
spiked above 80%.

All in all, I feel we should choose the solution based on what we want to
do and whether we want to take it further as well. I do not know what the
tool does now or whether it can build the system again and restart it
automatically. I also do not know what measures we take in such an event. I
agree CRON will be simplest of them all, but if the tool provides all of
these (be able to take corrective measures) and not just send
notifications

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-22 Thread Michael Brohl

Jacques,

just 2 days are not much for discussion in an open source community. 
Please have in mind that people might not have the time to think about 
and answer to the discussion in such a short timeframe. Most of us are 
working full time.


I see no need to hurry and propose to put down the vote and wait for at 
least a week to see if there are additional opinions.


Thanks,

Michael


Am 22.08.18 um 14:02 schrieb Jacques Le Roux:

Thanks Julien,

At this stage, after 2 days, we already have diverse answers and it's 
hard to see a clear answer/consensus from that.

So after this [PROPOSITION] I'll start 2 [VOTE]s, for:

1. Demos: replace old by trunk framework only?
2. Hide, remove or let as is UI links in framework (including 
applications) to plugins?


BTW Julien, no need to put me in copy, I assiduously follow the OFBiz 
MLs ;)


Jacques


Le 22/08/2018 à 10:13, Julien NICOLAS a écrit :

Hi all,

My opinion is to hide the link instead of delete it. I don't know if 
we have other link in this case but it could be important to keep it 
in source code. It could be convenient to have it for replacement by 
the good solution


But in the same time, we need to think about inter-webapp connection. 
How a menu from webapp A could be extended by webapp B without 
putting code in webapp A.


It could be interesting to have a new tool bar in product to manage 
ecommerce when ecommerce is installed. If we have this kind of 
feature, it could work as well for OOTB webapp like product and 
stock, party and order, etc.


Julien.


Le 21/08/2018 à 10:10, Jacques Le Roux a écrit :
OK, that your and Michael's opinions. So you prefer NPEs in code 
than hiding them when necessary?


What others think?

Jacques


Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :
Again, hiding is not a solution and is correcting an error with 
another

error.

-1

On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux 


wrote:

See my answer in the Jira, we can't tolerate NPEs, they are 
already there

for too long

Being smart is cool, being smart and clean is better ;)

Jacques


Le 21/08/2018 à 08:57, Michael Brohl a écrit :
We should neither simply remove those links nor should we have 
anything

hard coded.
Let's look for a smarter solution. No need to hurry, better take 
some

time to implement something sustainable.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.08.18 um 07:00 schrieb Jacques Le Roux:

Of course, but I like to be able to get from the backend to the

frontend when it's possible.
I don't see any troubles keeping them once it's handled that 
way, but

theoretical ones .
Of course if the community prefers to remove them it's far 
easier and
was what I wanted to do initially before having this idea of 
hiding links

Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
Simple, don't put any logic that points outwards from the 
framework.

That

is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
Makes sense. However, i note reading in the JIRA that "we can 
simply

hide
the button when the ecommerce component is not present". That 
sounds

like

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the 
framework

only

and

the
framework+plugins

I must add:

 * since the old is often no longer supported and a 
release of

it is
always available (today R13) for users. I think removing the 
old

demo is

maybe
   not a big deal.
 * I found several cases where people, new to OFBiz, 
considered

OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques




















smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-08-21 Thread Michael Brohl
I mean the concerns which already were raised, e.g. by Taher and Scott, 
who made you rethink your work you were going to commit.


You cannot simply ignore them and say you will commit your work.

The history of this issue clearly shows that it is necessary to have a 
close look at this work. So please wait until committers have had enough 
time to review the updated/corrected patches.


Thanks,

Michael


Am 21.08.18 um 11:40 schrieb Jacques Le Roux:

Le 21/08/2018 à 10:41, Michael Brohl a écrit :

Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of 
this work shows. This work is now ready and good, so I'll soon 
commit it.


So you want to ignore raised concerns and commit despite of them?



What are your raised concerns? Are they technically sustained?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-08-21 Thread Michael Brohl

Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of this 
work shows. This work is now ready and good, so I'll soon commit it.


So you want to ignore raised concerns and commit despite of them?




smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-08-21 Thread Michael Brohl

Jacques,

just a remark on this:


> Remember this is only trunk and will not be released before at least 
1 year and most possibly 2, you have plenty of time.


Even this is trunk and can be unstable, we should treat trunk with the 
same care as we do with release branches. trunk is not meant to put 
everything in and see if it works or someone finds a bug. We all know 
that this ist the root cause for some problematic code we have to deal with.


And we should not forget that new users also check out trunk to evaluate 
OFBiz, so it is important to have it as stable and bug free as possible.


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 20.08.18 um 09:28 schrieb Jacques Le Roux:

Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :

Wow, so after having a long, long email (as usual) talking about how
good the work is and you deployed for a client (my god!), now you
reverted because of a fundamental flaw pointed out by Scott.
I did not revert, it was not committed. I updated my patch and it was 
really a small change.
Initially I already planned to not use the client side to grab the 
loginId with OFBIZ-10206. But forgot about it because I stumbled upon 
many other issues since.
This work was challenging at many levels, believe me. I'll not drop it 
without really good arguments!



And now you want to apply lazy consensus despite my objections and the
obvious flaw which you acknowledged. This makes me skeptical of the
entire approach and the quality of the code in question. I would
prefer if you halt all work and study what you're doing instead of
falling into more mistakes.
Again, please give me good *technical* arguments. My work works and is 
safe, prove the contrary.



I'm also distressed with your phrase "Without negative comments well
argumented I'll commit both". In other words if you can't convince me
i'm pushing this code, why, because I want to. That's not how
community works.
Keep calm, you can still prevent me to commit if  you give me good 
argument as Scoot did.
And if you can't find them now you will still be able to veto if you 
find some later.
And again as explained at 
https://www.apache.org/foundation/voting.html#Veto you need arguments:


   /To prevent vetos from being used capriciously, they must be 
accompanied by a technical justification showing why the change is bad 
(opens a
   security exposure, negatively affects performance, //etc.//). A 
veto without a justification is invalid and has no weight./


Remember this is only trunk and will not be released before at least 1 
year and most possibly 2, you have plenty of time.


I'm all ears

Jacques


On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
 wrote:

ôOps missed some words...

Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
I simply send a JWT token: 
https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
allow an user to connect to another OFBiz instance (using same 
version than source) on another server (target) on another domain 
w/o signing in.


Jacques









smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-08-21 Thread Michael Brohl

Hi Shi,

what do you mean when you say you are going to release the plugin? Where 
will this take place?


Regards,

Michael


Am 19.08.18 um 22:00 schrieb Shi Jinghai:

Thanks Jacques!

If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. 
I have cas 4.2.x version running in production environment, I'll upgrade it to 
cas 5.2.x and then release it.



-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月19日 18:34
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

Actually I did not pick auth0 (not to be confused with 
https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those 
need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and 
https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed 
in authentication"

Thanks for your interest.

Jacques


Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

Hi Jacques,

OK, I think the redis topic is jumped to next step.

I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose 
auth0[2] rather than CAS. And is the implement OAuth2 alliance?

[1] https://github.com/apereo/cas
[2] https://auth0.com/

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月16日 2:08
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and 
https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks

Jacques


Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

Dear Jacques,

On how to store the Tokens, as a token is a key, value is the UserLogin entity 
and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in 
db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs 
invested Redis team in last year[3]. It's common view now in China that Redis 
is better than any others including Gemfire of Pivotal, the railway ticket 
system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year 
and then there are much less complains on how difficulties to buy spring 
festival tickets.

Mr. Dai Haipeng contributed a Redis component in Jira[4].

[1] https://redis.io/
[2] https://db-engines.com/en/ranking
[3] 
https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
[4] https://issues.apache.org/jira/browse/OFBIZ-9829

BTW, I'll try to review the patches.

Kind Regards,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月15日 15:09
收件人: dev@ofbiz.apache.org
主题: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

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






smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-08-21 Thread Michael Brohl

Great, learned something new. Thank you Scott!

Reagrds,

Michael

Am 20.08.18 um 19:09 schrieb 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








smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Michael Brohl
We should neither simply remove those links nor should we have anything 
hard coded.


Let's look for a smarter solution. No need to hurry, better take some 
time to implement something sustainable.


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
Of course, but I like to be able to get from the backend to the 
frontend when it's possible.
I don't see any troubles keeping them once it's handled that way, but 
theoretical ones .


Of course if the community prefers to remove them it's far easier and 
was what I wanted to do initially before having this idea of hiding links


Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
Simple, don't put any logic that points outwards from the framework. 
That

is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux 


wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
Makes sense. However, i note reading in the JIRA that "we can 
simply hide
the button when the ecommerce component is not present". That 
sounds like

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework 
only

and

the
framework+plugins

I must add:

    * since the old is often no longer supported and a release of 
it is
always available (today R13) for users. I think removing the old 
demo is

maybe
  not a big deal.
    * I found several cases where people, new to OFBiz, considered 
OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques











smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Michael Brohl

Hi Jacques,

for my comments on 
https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-9241 see Jira.


For the proposal, I think we should provide the demo with the framwork + 
plugins. It shows the portential of the whole ecosystem and I see no 
reason why we should not make it available?


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 20.08.18 um 16:31 schrieb Jacques Le Roux:

Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few 
differences in UI (and presence of js files) between the framework 
only and the framework+plugins


I must add:

 * since the old is often no longer supported and a release of it is 
always available (today R13) for users. I think removing the old demo 
is maybe

   not a big deal.
 * I found several cases where people, new to OFBiz, considered OFBiz 
as what we call the framework, and were considering the plugins as 
optional.


What do you think?

Jacques







smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

2018-08-20 Thread Michael Brohl

Jacques,

inline...

Am 20.08.18 um 11:27 schrieb Jacques Le Roux:

Hi Michael,

Yes but at this point the session misses the dispatcher, that's why I use

   request.getSession().setAttribute("dispatcher",dispatcher)

to put it in. As shown at

https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context

 the dispatcher is always available in screen context. Not sure why 
the session misses the dispatcher there, I did not want to digg in...


I think you should do that. If we normally expect the dispatcher to be 
always in the session and it is not in this case, there might be an 
error somewhere.

Implementing a workaround just covers this error but does not fix it.

Regards,
Michael



Jacques


Le 20/08/2018 à 09:12, Michael Brohl a écrit :

Hi Jacques,

maybe I am missing something but you should be able to get the 
session with request.getSession(), no?


Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative 
signature for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple 
way at the root in Groovy


Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we 
can fix

the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session 
because

the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 
15:30:42 2018

@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 
15:30:42 2018

@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apac

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

2018-08-20 Thread Michael Brohl

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

2018-08-20 Thread Michael Brohl

Hi Jacques,

maybe I am missing something but you should be able to get the session 
with request.getSession(), no?


Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative 
signature for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple way 
at the root in Groovy


Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session 
because

the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42 
2018

@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 
2018

@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
ecommerce/groovyScripts/catalog/LayeredNavigation.
groovy?rev=1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy (original)
+++ ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy Sun Aug 19 15:30:42 2018
@@ -47,6 +47,7 @@ if (!parameters.clearSearch || !"N".equa
  ProductSearchSession.searchClear(session)
  }

+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)










smime.p7s
Description: S/MIME 

Re: svn commit: r1838320 - in /ofbiz/ofbiz-framework/trunk/applications: datamodel/data/seed/OrderSeedData.xml datamodel/data/seed/ProductSeedData.xml order/src/main/java/org/apache/ofbiz/order/shoppi

2018-08-19 Thread Michael Brohl
I have not the time to dig into the specific details right now so will 
just give my thoughts on the process in general because of the citations:


1. we have to distinguish between (a) completely new functionality or 
major refactorings and (b) the enhancement of functionality which is 
already in the code base


2. for (a), we should first have consenus that we want the proposed 
solution and we should look for a complete, well designed and carefully 
tested solution before the first commit will be done. This is to prevent 
the introduction of new problematic code.


3. for (b), I think every improvement of existing code/functionality 
helps and should be committed if there are no flaws in the design or 
technical solution and it does not break existing funtionality. of 
course, it should be complete within the *scope* of the improvement.


4. if the solution for (b) does not cover other wishes or things which 
could be enhanced also, this would be no reason to not commit the 
improvement. If people have further requirements, they can provide 
concepts and solutions/patches anytime to make things better.


In this case, for me it is important if Suraj's commit

a. breaks anything?

b. is vetoed by other committers in view of code quality or design flaws?

If none of these questions get a "yes", then I see no reason to revert.

If you have additional requirements, you are encouraged to provide 
solutions or concepts for them.


Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 19.08.18 um 09:25 schrieb Pierre Smits:

Please read the comment in the related ticket [1]

https://issues.apache.org/jira/browse/OFBIZ-7482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584721#comment-16584721


Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Sat, Aug 18, 2018 at 9:01 PM, Michael Brohl 
wrote:


How do these citations relate to Suraj‘s work?

Please provide arguments in your own words if you think someone‘s work has
flaws and should be reverted.

Thanks,
Michael



Am 18.08.2018 um 13:54 schrieb Pierre Smits :

As Michael recently pointed out in another thread:

{quote}

*If it does break anything or introduces functionality which is not

working

completely, we should revert.*

{quote}

And:

{quote}

*We are struggling with half baked, incomplete or buggy code in several
areas which often shows up a long time after it was committed. In other
cases, even if problems are raised soon after the commit, the code is

left

untouched for a long time until it is work on again or simply is

forgotten.*

{quote}


Best regards,

Pierre Smits

On Sat, Aug 18, 2018 at 10:52 AM, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:


Hi Pierre,

This is not a new patch, this is updated version of two years old patch
which has been already reviewed if you follow comments on ticket.
We need to add updated patch as well since many file path have been

changed

and we have data files refactoring as well.

HTH.
--
Best Regards,
Suraj Khurana | Omni-channel OMS Technical Expert
HotWax Commerce  by  HotWax Systems

On Sat, Aug 18, 2018 at 2:13 PM, Pierre Smits 
wrote:


Hi Suraj,

Please revert! Within 10 minutes you posted a new patch and committed

it

to

trunk and closed the issue. It is customary to follow the 72 hr delay

rule

to allow the community to review the changes and assess the impact.


Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
Apache Steve <https://steve.apache.org>, committer


On Sat, Aug 18, 2018 at 10:34 AM,  wrote:

Author: surajk
Date: Sat Aug 18 08:34:18 2018
New Revision: 1838320

URL: http://svn.apache.org/viewvc?rev=1838320=rev
Log:
Improved: Added support to calculate deposit price as well while

creating

shopping cart item.
(OFBIZ-7482)

Modified:
ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
seed/OrderSeedData.xml
ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
seed/ProductSeedData.xml
ofbiz/ofbiz-framework/trunk/applications/order/src/main/
java/org/apache/ofbiz/order/shoppingcart/ShoppingCartItem.java

Modified: ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
seed/OrderSeedData.xml
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/datamodel/data/seed/OrderSeedData.xml?rev=
1838320=1838319=1838320=diff

==
--- ofbi

Re: svn commit: r1838320 - in /ofbiz/ofbiz-framework/trunk/applications: datamodel/data/seed/OrderSeedData.xml datamodel/data/seed/ProductSeedData.xml order/src/main/java/org/apache/ofbiz/order/shoppi

2018-08-18 Thread Michael Brohl
How do these citations relate to Suraj‘s work?

Please provide arguments in your own words if you think someone‘s work has 
flaws and should be reverted.

Thanks,
Michael


> Am 18.08.2018 um 13:54 schrieb Pierre Smits :
> 
> As Michael recently pointed out in another thread:
> 
> {quote}
> 
> *If it does break anything or introduces functionality which is not working
> completely, we should revert.*
> 
> {quote}
> 
> And:
> 
> {quote}
> 
> *We are struggling with half baked, incomplete or buggy code in several
> areas which often shows up a long time after it was committed. In other
> cases, even if problems are raised soon after the commit, the code is left
> untouched for a long time until it is work on again or simply is forgotten.*
> 
> {quote}
> 
> 
> Best regards,
> 
> Pierre Smits
> 
> On Sat, Aug 18, 2018 at 10:52 AM, Suraj Khurana <
> suraj.khur...@hotwaxsystems.com> wrote:
> 
>> Hi Pierre,
>> 
>> This is not a new patch, this is updated version of two years old patch
>> which has been already reviewed if you follow comments on ticket.
>> We need to add updated patch as well since many file path have been changed
>> and we have data files refactoring as well.
>> 
>> HTH.
>> --
>> Best Regards,
>> Suraj Khurana | Omni-channel OMS Technical Expert
>> HotWax Commerce  by  HotWax Systems
>> 
>> On Sat, Aug 18, 2018 at 2:13 PM, Pierre Smits 
>> wrote:
>> 
>>> Hi Suraj,
>>> 
>>> Please revert! Within 10 minutes you posted a new patch and committed it
>> to
>>> trunk and closed the issue. It is customary to follow the 72 hr delay
>> rule
>>> to allow the community to review the changes and assess the impact.
>>> 
>>> 
>>> Best regards,
>>> 
>>> Pierre Smits
>>> 
>>> Apache Trafodion , Vice President
>>> Apache Directory , PMC Member
>>> Apache Incubator , committer
>>> Apache OFBiz , contributor since 2008
>>> Apache Steve , committer
>>> 
 On Sat, Aug 18, 2018 at 10:34 AM,  wrote:
 
 Author: surajk
 Date: Sat Aug 18 08:34:18 2018
 New Revision: 1838320
 
 URL: http://svn.apache.org/viewvc?rev=1838320=rev
 Log:
 Improved: Added support to calculate deposit price as well while
>> creating
 shopping cart item.
 (OFBIZ-7482)
 
 Modified:
ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
 seed/OrderSeedData.xml
ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
 seed/ProductSeedData.xml
ofbiz/ofbiz-framework/trunk/applications/order/src/main/
 java/org/apache/ofbiz/order/shoppingcart/ShoppingCartItem.java
 
 Modified: ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
 seed/OrderSeedData.xml
 URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
 applications/datamodel/data/seed/OrderSeedData.xml?rev=
 1838320=1838319=1838320=diff
 
 ==
 --- ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
>>> seed/OrderSeedData.xml
 (original)
 +++ ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
>>> seed/OrderSeedData.xml
 Sat Aug 18 08:34:18 2018
 @@ -49,6 +49,7 @@ under the License.
 >>> orderAdjustmentTypeId="ADDITIONAL_FEATURE"/>
 >>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT"/>
 >>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"/>
 +>>> orderAdjustmentTypeId="DEPOSIT_ADJUSTMENT"/>
 
 >>> description="Addresss"/>
 >>> description="Credit Card"/>
 
 Modified: ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
 seed/ProductSeedData.xml
 URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
 applications/datamodel/data/seed/ProductSeedData.xml?rev=
 1838320=1838319=1838320=diff
 
 ==
 --- ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
>>> seed/ProductSeedData.xml
 (original)
 +++ ofbiz/ofbiz-framework/trunk/applications/datamodel/data/
>>> seed/ProductSeedData.xml
 Sat Aug 18 08:34:18 2018
 @@ -281,6 +281,7 @@ under the License.
 >>> productPriceTypeId="MINIMUM_ORDER_PRICE"/>
 >>> productPriceTypeId="SHIPPING_ALLOWANCE"/>
 
 +>>> productPricePurposeId="DEPOSIT"/>
 >>> productPricePurposeId="PURCHASE"/>
 >>> productPricePurposeId="RECURRING_CHARGE"/>
 >>> productPricePurposeId="USAGE_CHARGE"/>
 
 Modified: ofbiz/ofbiz-framework/trunk/applications/order/src/main/
 java/org/apache/ofbiz/order/shoppingcart/ShoppingCartItem.java
 URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
 applications/order/src/main/java/org/apache/ofbiz/order/
 shoppingcart/ShoppingCartItem.java?rev=1838320=1838319&
 r2=1838320=diff
 

Password hashing algorithm changed?

2018-08-17 Thread Michael Brohl

Hi devs,

I just noticed that we seem to have a password hashing change in trunk, 
see example:


Old has for a password: |{SHA}47b56994cbc2b6d10...|
New hash for the same password: |$SHA$.VskyitfRUpf$oXN|

Can someone point me to the discussion and/or Jira/commit for further 
informations?


Thanks,

Michael





smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1835869 - in /ofbiz/ofbiz-framework/trunk: framework/widget/dtd/ framework/widget/src/main/java/org/apache/ofbiz/widget/model/ framework/widget/src/main/java/org/apache/ofbiz/widget/r

2018-07-30 Thread Michael Brohl

Hi Suraj,

my interpretion of the feedbacks was that the commit has problems or is 
incomplete.


If it does break anything or introduces functionality which is not 
working completely, we should revert.


If this is not the case and you have the chance to implement the 
discussed issues in due time, I think it is not a problem and we do not 
need to revert.



Why am I so sensible here?

We are struggling with half baked, incomplete or buggy code in several 
areas which often shows up a long time after it was committed. In other 
cases, even if problems are raised soon after the commit, the code is 
left untouched for a long time until it is work on again or simply is 
forgotten.


(I do not assume these both szenarios fit in your case).

To avoid this, I am more in favor of reverting immediately instead of 
leaving the code in the codebase.



Thanks for your valuable work and best regards,

Michael


Am 30.07.18 um 12:45 schrieb Suraj Khurana:

Hello,

Thanks Deepak for pointing this out.
I noted down your feedback and soon will update things accordingly.

@Nicolas, Gil
Yes, I think you are suggesting right. It would be better to change things
as per your suggestion. I am working on it as soon provide patch for review.

@Michael,
Please suggest, what should be the right way to proceed, IMO, if it is not
breaking something functional (yes, it is not), we can do required
improvements in another commit.

Current patch has been there for quite enough time for review, and many of
us have discussed on it on various aspects. These are small enhancements in
process of code re-view which is actual beauty of working in community and
I guess these improvements should be honored in another commit.

I agree on both things whatever we choose to follow either to commit
suggested enhancements or to revert, do changes and than again commit.

--
Thanks and Regards
Suraj Khurana | Omni-channel OMS Technical Expert



On Mon, Jul 30, 2018 at 2:22 PM, Michael Brohl 
wrote:


There's also a remark by Deepak.

I'm in favor of reverting and providing a new solution once it covers all
remarks. We should not leave it in the codebase in this state.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 30.07.18 um 10:14 schrieb Gil Portenseigne:

Hello Suraj,

Regarding Nicolas feedback and mine onto Jira
https://issues.apache.org/jira/browse/OFBIZ-7598, did you find time to
look into it ?

Thanks,

Gil

Le mardi 17 juil. 2018 à 14:04:06 (+0200), Nicolas Malin a écrit :


Hello Suraj,

On 14/07/2018 07:10, sur...@apache.org wrote:


Modified: ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/o
rg/apache/ofbiz/widget/model/ModelForm.java
URL:http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk
/framework/widget/src/main/java/org/apache/ofbiz/widget/mode
l/ModelForm.java?rev=1835869=1835868=1835869=diff

==
--- ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/o
rg/apache/ofbiz/widget/model/ModelForm.java (original)
+++ ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/o
rg/apache/ofbiz/widget/model/ModelForm.java Sat Jul 14 05:10:00 2018
@@ -147,7 +147,7 @@ public abstract class ModelForm extends
private final String formWidgetAreaStyle;
private final boolean groupColumns;
private final String headerRowStyle;
-private final boolean hideHeader;
+private boolean hideHeader;


With this commit you change the model during ofbiz execution and this
break
the thread safe. I will try to found an other to correct this

Nicolas








smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1835869 - in /ofbiz/ofbiz-framework/trunk: framework/widget/dtd/ framework/widget/src/main/java/org/apache/ofbiz/widget/model/ framework/widget/src/main/java/org/apache/ofbiz/widget/r

2018-07-30 Thread Michael Brohl

There's also a remark by Deepak.

I'm in favor of reverting and providing a new solution once it covers 
all remarks. We should not leave it in the codebase in this state.


Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 30.07.18 um 10:14 schrieb Gil Portenseigne:

Hello Suraj,

Regarding Nicolas feedback and mine onto Jira 
https://issues.apache.org/jira/browse/OFBIZ-7598, did you find time to look 
into it ?

Thanks,

Gil

Le mardi 17 juil. 2018 à 14:04:06 (+0200), Nicolas Malin a écrit :

Hello Suraj,

On 14/07/2018 07:10, sur...@apache.org wrote:

Modified: 
ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelForm.java
URL:http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelForm.java?rev=1835869=1835868=1835869=diff
==
--- 
ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelForm.java
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelForm.java
 Sat Jul 14 05:10:00 2018
@@ -147,7 +147,7 @@ public abstract class ModelForm extends
   private final String formWidgetAreaStyle;
   private final boolean groupColumns;
   private final String headerRowStyle;
-private final boolean hideHeader;
+private boolean hideHeader;

With this commit you change the model during ofbiz execution and this break
the thread safe. I will try to found an other to correct this

Nicolas





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Oracle Java release model changes and consequences for the project

2018-07-28 Thread Michael Brohl

Hi Mathieu,

my goal is to actively inform users about our roadmap and provide 
information on how the project will deal with the new Java release 
model. Users testing OFBiz for their needs in a professional environment 
also check if a project has answers to these questions so I am wrapping 
my mind around it.


This is just to make clear that I am not eager to switch to newer Java 
versions just for the sake of it.



Am 28.07.18 um 12:54 schrieb Mathieu Lirzin:

I wonder if we should base the OFBiz 17.12 release on Java 8 or Java
11. We have no fixed release date yet so we might have time to do it.

Another way would be to make a new branch which will support Java 11.

What do people think?

I think OFBiz should be conservative in its choices.


I agree!


Given the fact Java 11 is not release yet or is about to be released,


Java 11 will be released as GA in Sept 18. At the same time, 
non-subscribed users will get no updates for Java 8 any more.



OFBiz should keep compatibity with the previous LTS release meaning java 8.  Of 
course


Yes, you are right. If you focus on subscribed users, they will get Java 
8 support until September 2023 (2026 for extended subscription).
So following my thoughts to assume that users will subscribe, we can 
stay with Java 8 for a while.


On the other hand, if we test Java 11 and find that we will have few 
issues we can easily handle, it could be a good idea to make the switch 
with release 17.12.


I am open to both (or other) models and would like to hear more opinions 
about that.



This does not mean that OFBiz should not be tested with more recent Java
releases too.

Having an extra branch has a maintenance burden that should be balanced
with the benefits it provides.  What benefits do you see in having a
Java 11 branch?

This is just an alternative to the Java 11 update of the next branch. I 
do not favor this because of the extra maintenance burden you mentioned.


In conclusion, we can stick to Java 8, informing our users that they 
have to subscribe for further updates.


If we do this, we should think about a roadmap/ process to change to 
Java 11 in the future. This could be, for example, set up during the 
release branch 21.x or 22.x to give us enough time.


We should also, in my opinion, check/test for Java 11 and following 
versions compatibility in the next months to be able to inform users 
about compatibilities/incompatibilities with this version. Maybe we can 
provide some compatibility matrix or else.


Thanks for your thoughts,
Michael










smime.p7s
Description: S/MIME Cryptographic Signature


Re: Oracle Java release model changes and consequences for the project

2018-07-28 Thread Michael Brohl

Hi Taher,

I would prefer if you start a new thread for this because it's a 
complete new topic.


If it turns out that the community wants to work on a Java 11 update, I 
would file an umbrella task for it and your issue OFBIZ-9972 would be a 
sub-task (not the only one I think) of this.


Thanks you,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 28.07.18 um 11:29 schrieb Taher Alkhateeb:

I see. well this means we have to do multiple things:

- First we need to upgrade gradle
- I have no preference with release 17 Java version support

Now the problem with upgrading gradle in a nutshell is that you can no
longer have spaces in server commands. So ./gradlew "ofbiz --start"
will not work because of the space between "ofbiz" and "--start" and
that's why I created a JIRA for this issue [1]. I'm not sure what is
the best solution, one idea that came to me is perhaps to pass the
args to a string. So for example:

./gradlew ofbiz -Pcmd1="--load-data readers=seed" ofbiz
-Pcmd2="--start --portoffset=1"

Maybe another option is to just run one "ofbiz" task and then pass
multiple commands each in a project paramter -Pcmd1= -Pcmd2= -Pcmd3=
... Another option is to hard wire all commands like we did back in
Ant days.

I'm not sure what is the best solution there, and I don't mean to
hijack this thread, but one thing depends on another thing. Should we
start a new thread for that? Collect ideas from the community?

[1] https://issues.apache.org/jira/browse/OFBIZ-9972

On Sat, Jul 28, 2018 at 11:47 AM, Michael Brohl
 wrote:

Because OpenJDK is the base for the Oracle JDK and Oracle is working on Open
JDK, I  assume we will have the same problems. It can also be that the two
will be one product soon. Why should Oracle support Open JDK with long term
updates for free?

I did not find a clear roadmap for Open JDK so it's unclear to me how long
the versions will be supported.

I think Linux distributions will follow the LTS release cycle also, because
of the same reasons. Here's a statement for Red Hat:
https://access.redhat.com/articles/1299013 (at the bottom).

Most sources of information describe the Open JDK as a reference
implementation which is less stable than the Oracle JDK.

Personally, I have almost no experience using Open JDK in productive,
professional environments. There were problems years ago which I do not
remember exactly and we use Oracle JDK since then.

I think we should support Oracle JDK because professional users most likely
will use it and it would be a bad sign if OFBiz shows no official support
for it.

I also don't like the release model but the costs are moderate and using the
LTS version, there is no headache feature wise. Java 11 LTS will be stable
until 2023 or 2026 if you choose the extended subscription. Lots of time to
prepare for the next LTS version...

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 28.07.18 um 10:06 schrieb Taher Alkhateeb:


I am beginning to wonder if we should consider moving to OpenJDK. I think
I
really dislike this release model with all the extra costs and headache
involved.

Are we stuck with Oracle JDK? Does anyone know of limitations or problems
with OpenJDK? I vaguely remember font problems with the BIRT plugin but I
cannot recall any serious issues.

On Sat, Jul 28, 2018, 10:56 AM Michael Brohl 
wrote:


Hi devs,

a quick heads up for this topic.

After following the release strategy and thinking more about it, I think
that most users will go with a subscription model and subscribe for an
LTS version. The costs are moderate [1] and I assume that few users will
go through a repeating 6 month "early access - update - test - go live"
circle for free Java versions.

Java 11 EA is available [2] so we could start to test with it.

The latest Intellij Idea already has support for Java 11, I suppose that
it will come for Eclipse Photon shortly also.

I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
We have no fixed release date yet so we might have time to do it.

Another way would be to make a new branch which will support Java 11.

What do people think?

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


[1]


http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html

[2] http://jdk.java.net/11/




Michael Brohl
Geschäftsführer

Fon  +49 521 448 157-91
Fax  +49 521 448 157-99
Mobil+49 160 3664918
Xing xing.com/profile/Michael_Brohl
LinkedIn linkedin.com/in/michaelbrohl

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

Am 29.01.18 um 17:21 schrieb Michael Brohl:

Hi devs,

this is just an initial information and dicussion starter to make
everyone aware of this:

th

Re: Oracle Java release model changes and consequences for the project

2018-07-28 Thread Michael Brohl
Because OpenJDK is the base for the Oracle JDK and Oracle is working on 
Open JDK, I  assume we will have the same problems. It can also be that 
the two will be one product soon. Why should Oracle support Open JDK 
with long term updates for free?


I did not find a clear roadmap for Open JDK so it's unclear to me how 
long the versions will be supported.


I think Linux distributions will follow the LTS release cycle also, 
because of the same reasons. Here's a statement for Red Hat: 
https://access.redhat.com/articles/1299013 (at the bottom).


Most sources of information describe the Open JDK as a reference 
implementation which is less stable than the Oracle JDK.


Personally, I have almost no experience using Open JDK in productive, 
professional environments. There were problems years ago which I do not 
remember exactly and we use Oracle JDK since then.


I think we should support Oracle JDK because professional users most 
likely will use it and it would be a bad sign if OFBiz shows no official 
support for it.


I also don't like the release model but the costs are moderate and using 
the LTS version, there is no headache feature wise. Java 11 LTS will be 
stable until 2023 or 2026 if you choose the extended subscription. Lots 
of time to prepare for the next LTS version...


Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 28.07.18 um 10:06 schrieb Taher Alkhateeb:

I am beginning to wonder if we should consider moving to OpenJDK. I think I
really dislike this release model with all the extra costs and headache
involved.

Are we stuck with Oracle JDK? Does anyone know of limitations or problems
with OpenJDK? I vaguely remember font problems with the BIRT plugin but I
cannot recall any serious issues.

On Sat, Jul 28, 2018, 10:56 AM Michael Brohl 
wrote:


Hi devs,

a quick heads up for this topic.

After following the release strategy and thinking more about it, I think
that most users will go with a subscription model and subscribe for an
LTS version. The costs are moderate [1] and I assume that few users will
go through a repeating 6 month "early access - update - test - go live"
circle for free Java versions.

Java 11 EA is available [2] so we could start to test with it.

The latest Intellij Idea already has support for Java 11, I suppose that
it will come for Eclipse Photon shortly also.

I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
We have no fixed release date yet so we might have time to do it.

Another way would be to make a new branch which will support Java 11.

What do people think?

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


[1]

http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html

[2] http://jdk.java.net/11/




Michael Brohl
Geschäftsführer

Fon  +49 521 448 157-91
Fax  +49 521 448 157-99
Mobil+49 160 3664918
Xing xing.com/profile/Michael_Brohl
LinkedIn linkedin.com/in/michaelbrohl

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

Am 29.01.18 um 17:21 schrieb Michael Brohl:

Hi devs,

this is just an initial information and dicussion starter to make
everyone aware of this:

the Oracle Java release model is changing from a feature based to a
time based model [1]. One major drawback is that there will be no more
public patch releases for older versions once a new release is
published, if I understand correctly.

We'll have to discuss if this affects the project in terms of support
for the latest public Java releases. If we want to stay up-to-date
according to the public releases, we'll have to establish a process to
early check the new features and changes of a coming release and maybe
release more often.

We might even have to support the latest Java release along with the
current LTS release to cover both users with and without commercial
support? I'm not sure.

What do you think?

Best regards,

Michael

[1] https://www.azul.com/java-stable-secure-free-choose-two-three/











smime.p7s
Description: S/MIME Cryptographic Signature


Re: Oracle Java release model changes and consequences for the project

2018-07-28 Thread Michael Brohl

Hi devs,

a quick heads up for this topic.

After following the release strategy and thinking more about it, I think 
that most users will go with a subscription model and subscribe for an 
LTS version. The costs are moderate [1] and I assume that few users will 
go through a repeating 6 month "early access - update - test - go live" 
circle for free Java versions.


Java 11 EA is available [2] so we could start to test with it.

The latest Intellij Idea already has support for Java 11, I suppose that 
it will come for Eclipse Photon shortly also.


I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11. 
We have no fixed release date yet so we might have time to do it.


Another way would be to make a new branch which will support Java 11.

What do people think?

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


[1] 
http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html


[2] http://jdk.java.net/11/




Michael Brohl
Geschäftsführer

Fon  +49 521 448 157-91
Fax  +49 521 448 157-99
Mobil+49 160 3664918
Xing xing.com/profile/Michael_Brohl
LinkedIn linkedin.com/in/michaelbrohl

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

Am 29.01.18 um 17:21 schrieb Michael Brohl:

Hi devs,

this is just an initial information and dicussion starter to make 
everyone aware of this:


the Oracle Java release model is changing from a feature based to a 
time based model [1]. One major drawback is that there will be no more 
public patch releases for older versions once a new release is 
published, if I understand correctly.


We'll have to discuss if this affects the project in terms of support 
for the latest public Java releases. If we want to stay up-to-date 
according to the public releases, we'll have to establish a process to 
early check the new features and changes of a coming release and maybe 
release more often.


We might even have to support the latest Java release along with the 
current LTS release to cover both users with and without commercial 
support? I'm not sure.


What do you think?

Best regards,

Michael

[1] https://www.azul.com/java-stable-secure-free-choose-two-three/








smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-07-27 Thread Michael Brohl

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=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=1813639=1813640=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 ? value.getEntityName() : "value is null") + "]: " +
e.toString() + ". Rolling 

Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Michael Brohl

Hi Pradhan, Taher,

I think this would be a huge undertaking and I am not sure if this would 
be a project goal for the near future.


We have many fields of action which should have more focus like UI, 
functionality, documentation etc..


So yes, nice goal but more on the long view...

Regrds,

Michael


Am 26.07.18 um 11:27 schrieb Yash Sharma:

Hello Mathieu,

I have tried jRebel link: https://zeroturnaround.com/software/jrebel/
  with IntelliJ.

+1 Taher for the change in architecture from a single huge monolithic to
some microservice hot swap (dynamic loading) flexible architecture.


Thanks & Regards,
Pradhan Yash Sharma

On Thu, Jul 26, 2018 at 2:38 PM, Mathieu Lirzin 
wrote:


Hello,

Being a bit frustrated by the slowness of having to stop/compile/restart
OFBiz manually each time a java file is changed, I have been searching
for a way to make Java code hot-deployable, meaning recompiling and
redeploying Java classes each time a ‘.java’ file is saved.

The ‘gretty’ Gradle plugin seems to provide such feature [1][2].

I would like to know if somebody has already tried to integrate it in
OFBiz build system? and if there is any OFBiz singularitiy preventing
its use?

Thanks.

[1] https://guides.gradle.org/building-java-web-applications/
[2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Gradle ‘gretty’ Plugin

2018-07-26 Thread Michael Brohl

Hi Mathieu,

hot code replacement works fine in Eclipse if you have updated the 
Eclipse classpath through ./gradlew eclipse.


You can run/debug OFBiz in Eclipse without problems mostly. Sometimes 
you have to restart, depending of the changes.


For me this is working sufficiently.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 26.07.18 um 11:08 schrieb Mathieu Lirzin:

Hello,

Being a bit frustrated by the slowness of having to stop/compile/restart
OFBiz manually each time a java file is changed, I have been searching
for a way to make Java code hot-deployable, meaning recompiling and
redeploying Java classes each time a ‘.java’ file is saved.

The ‘gretty’ Gradle plugin seems to provide such feature [1][2].

I would like to know if somebody has already tried to integrate it in
OFBiz build system? and if there is any OFBiz singularitiy preventing
its use?

Thanks.

[1] https://guides.gradle.org/building-java-web-applications/
[2] https://akhikhl.github.io/gretty-doc/Hot-deployment.html






smime.p7s
Description: S/MIME Cryptographic Signature


Double posts in the dev list?

2018-07-03 Thread Michael Brohl

Hey all,

anyone else who is receiving every mail in this list twice?

I experience this since 30th June.

Thanks for a feedback,

Michael





smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1834662 - /ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ConfigXMLReader.java

2018-06-29 Thread Michael Brohl

Jacques,

didn't we just agreed upon a slower process and review from more 
committers when changing these core aspects of the framework?


Especially when you change the patch there is no chance for anyone to 
review before it gets committed {#emotions_dlg.sad}


Michael

Am 29.06.18 um 12:03 schrieb jler...@apache.org:

Author: jleroux
Date: Fri Jun 29 10:03:22 2018
New Revision: 1834662

URL: http://svn.apache.org/viewvc?rev=1834662=rev
Log:
Improved: Factorize code logic from ‘ConfigXMLReader’
(OFBIZ-10453)

There is a lot of repetitive code in ConfigXMLReader.
Using a functional interface as a parameter of a generic algorithm avoids those
repetitions.

Thanks: Mathieu Lirzin

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

Modified: 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ConfigXMLReader.java
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ConfigXMLReader.java?rev=1834662=1834661=1834662=diff
==
--- 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ConfigXMLReader.java
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ConfigXMLReader.java
 Fri Jun 29 10:03:22 2018
@@ -32,6 +32,7 @@ import java.util.List;
  import java.util.Map;
  import java.util.Objects;
  import java.util.Set;
+import java.util.function.Function;
  import java.util.stream.Collectors;
  
  import javax.servlet.ServletContext;

@@ -218,120 +219,67 @@ public class ConfigXMLReader {
  }
  }
  
-public Map getAfterLoginEventList() throws WebAppConfigurationException {

-MapContext result = MapContext.getMapContext();
-for (URL includeLocation : includes) {
-ControllerConfig controllerConfig = 
getControllerConfig(includeLocation);
-result.push(controllerConfig.getAfterLoginEventList());
+private  Map pushIncludes(Function> f) throws WebAppConfigurationException {
+MapContext res = MapContext.getMapContext();
+for (URL include : includes) {
+res.push(getControllerConfig(include).pushIncludes(f));
+}
+res.push(f.apply(this));
+return res;
+}
+
+private String getIncludes(Function f) 
throws WebAppConfigurationException {
+String val = f.apply(this);
+if (val != null) {
+return val;
+}
+for (URL include : includes) {
+String inc = getControllerConfig(include).getIncludes(f);
+if (inc != null) {
+return inc;
+}
  }
-result.push(afterLoginEventList);
-return result;
+return null;
+}
+
+public Map getAfterLoginEventList() throws 
WebAppConfigurationException {
+return pushIncludes(ccfg -> ccfg.afterLoginEventList);
  }
  
  public Map getBeforeLogoutEventList() throws WebAppConfigurationException {

-MapContext result = MapContext.getMapContext();
-for (URL includeLocation : includes) {
-ControllerConfig controllerConfig = 
getControllerConfig(includeLocation);
-result.push(controllerConfig.getBeforeLogoutEventList());
-}
-result.push(beforeLogoutEventList);
-return result;
+return pushIncludes(ccfg -> ccfg.beforeLogoutEventList);
  }
  
  public String getDefaultRequest() throws WebAppConfigurationException {

-if (defaultRequest != null) {
-return defaultRequest;
-}
-for (URL includeLocation : includes) {
-ControllerConfig controllerConfig = 
getControllerConfig(includeLocation);
-String defaultRequest = controllerConfig.getDefaultRequest();
-if (defaultRequest != null) {
-return defaultRequest;
-}
-}
-return null;
+return getIncludes(ccfg -> ccfg.defaultRequest);
  }
  
  public String getErrorpage() throws WebAppConfigurationException {

-if (errorpage != null) {
-return errorpage;
-}
-for (URL includeLocation : includes) {
-ControllerConfig controllerConfig = 
getControllerConfig(includeLocation);
-String errorpage = controllerConfig.getErrorpage();
-if (errorpage != null) {
-return errorpage;
-}
-}
-return null;
+return getIncludes(ccfg -> ccfg.errorpage);
  }
  
  

Re: [Discussion]: Add method attribute to request-map (Was: svn commit: r1834389 - in /ofbiz/ofbiz-framework/trunk/framework...)

2018-06-28 Thread Michael Brohl

A strong +1 to your recommendations.

There were several commits in the OFBiz core recently which were not 
properly discussed before they were committed. We should avoid this.


People should have in mind that other committers might not have the time 
to review, think and discuss these patches in the course of a few days. 
These things are not urgent and can take their time.


Thanks and regards,

Michael


Am 28.06.18 um 09:15 schrieb Taher Alkhateeb:

A few comments:

1- I would suggest to try and avoid in the future committing any
design changes to the framework without discussing it properly in the
mailing list first
2- I think it would be better to revert this work. I noticed in the
JIRA for example that Mathieu Lirzin asked for some time to review his
work when you just committed his work without checking what he wanted
to do, and he later provided refactoring patches.
3- I would recommend providing a summary of what you want to commit.
The commit was too long and I don't want to read line-by-line
everything in the code to understand what was achieved. Let's first
discuss in here what is being done, agree on the general direction,
and THEN apply a commit.

Those are my recommendations, and I don't know about the rest of the
folks opinion here so I invite everyone else to have their input.

On Thu, Jun 28, 2018 at 6:46 AM, Shi Jinghai  wrote:

Hi all,

Thanks Jacques, Taher and Nicolas mentioned our community rule, "a proper 
discussion".

I created an issue "Add method attribute to request-map to controll a uri can be 
called GET or POST only" a week ago:
https://issues.apache.org/jira/browse/OFBIZ-10438

Thanks Mathieu, he submitted his patches very quickly while I was preparing 
mine. I tested them and submitted to trunk. Please be aware, the latest 
versions are r1834465 and r1834570, and the implement requires JDK 1.8.

Is the implement acceptable for trunk? Further improvement to do? Would we 
backport it to releases?

If it's not acceptable, I'll revert the implement.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Paul Foxworthy [mailto:p...@cohsoft.com.au]
发送时间: 2018年6月26日 19:31
收件人: dev@ofbiz.apache.org
主题: Re: svn commit: r1834389 - in /ofbiz/ofbiz-framework/trunk/framework: 
base/src/main/java/org/apache/ofbiz/base/util/collections/ webapp/config/ 
webapp/dtd/ webapp/src/main/java/org/apache/ofbiz/webapp/control/ 
webapp/src/test/java/org/apache/ofbiz/weba...

On 26 June 2018 at 17:58, Taher Alkhateeb 
wrote:


I could be mistaken, but this seems like a very major change that did
not have a thorough and proper discussion at the mailing list? I would
rather at least have an explanation of what was committed and to
discuss the merits and cons of the implementation.


Hi all,

I haven't found the specific issue, but wasn't there a major change several
years ago from GET to POST to help guard against XSS attacks?

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





smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1832930 - /ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml

2018-06-05 Thread Michael Brohl

Improved: ...


Am 05.06.18 um 13:29 schrieb jler...@apache.org:

Author: jleroux
Date: Tue Jun  5 11:29:11 2018
New Revision: 1832930

URL: http://svn.apache.org/viewvc?rev=1832930=rev
Log:
No functional change, fixes a typo in comment while at it

Modified:
 ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml

Modified: ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml?rev=1832930=1832929=1832930=diff
==
--- ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml 
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/entity/config/entityengine.xml Tue 
Jun  5 11:29:11 2018
@@ -114,7 +114,7 @@ access. For a detailed description see t
  For DAO/JDBC Helper: Tries:
1. JNDI Datasource IF jdbc.jndi.name, context.provider, etc are 
specified
2. Embedded (JOTM) if available (uses jdbc.driver, jdbc.uri, 
jdbc.username, jdbc.password, isolation.level)
-  3. Direct to manually laoded JDBC driver (uses jdbc.driver, jdbc.uri, 
jdbc.username, jdbc.password)
+  3. Direct to manually loaded JDBC driver (uses jdbc.driver, jdbc.uri, 
jdbc.username, jdbc.password)
  
  Transaction Isolation Levels - (.isolation.level) can be as follows:

   * None







smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1832662 - /ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java

2018-06-03 Thread Michael Brohl

Hi Jacques,

I would *always* prefer a Jira, patch and discussion *first* before a 
commit in these core areas of the application.


Regards,

Michael


Am 03.06.18 um 10:28 schrieb Jacques Le Roux:

Hi Taher,

Thanks for asking.

I created the Jira afterwards and then updated the commits comments. 
More a pattern to prevent security disclosures. I must say in this 
case not of much use, anyway I prefer to keep this habit.


I called session.invalidate() because at this stage we already have a 
session. Actually an 
org.apache.catalina.session.StandardSessionFacade, Tomcat handles it. 
So request.getSession() does not create one.


But I had a new look and I can do better. I was unaware of 
request.changeSessionId() which is better here since I only need to 
change the session id.


I'll change that

Jacques


Le 03/06/2018 à 00:33, Taher Alkhateeb a écrit :

I can't find the JIRA reference for this commit, can you place share a
JIRA if it exists? Also, I'm not sure why you're calling
session.invalidate()? Doesn't request.getSession() already assign a
new session depending on client settings?

On Fri, Jun 1, 2018 at 10:37 AM,   wrote:

Author: jleroux
Date: Fri Jun  1 07:37:27 2018
New Revision: 1832662

URL: http://svn.apache.org/viewvc?rev=1832662=rev
Log:
Fixes a session fixation security issue discovered by a client with 
the security

  audit tool "IBM Security AppScan Enterprise , Version : 9.0.3.7"

Prevents the session fixation by making Tomcat generate a new 
jsessionId

(ultimately put in cookie).

Only do when really signing in to avoid unnecessary calls
Though if the client has disabled the use of cookies, then a session 
will be

new on each request, not a good choice on client side!



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

Modified: 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java?rev=1832662=1832661=1832662=diff
== 

--- 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java 
Fri Jun  1 07:37:27 2018

@@ -328,6 +328,14 @@ public class LoginWorker {
   */
  public static String login(HttpServletRequest request, 
HttpServletResponse response) {

  HttpSession session = request.getSession();
+
+    // Prevent session fixation by making Tomcat generate a new 
jsessionId (ultimately put in cookie).

+    if (!session.isNew()) {  // Only do when really signing in.
+    session.invalidate(); // If the client has disabled the 
use of cookies, then a session will be new on each request, not a 
good choice on client side!

+    session = request.getSession(true);
+    UtilHttp.setInitialRequestInfo(request); // We need to 
put that in place again

+    }
+
  Delegator delegator = (Delegator) 
request.getAttribute("delegator");

  String username = request.getParameter("USERNAME");
  String password = request.getParameter("PASSWORD");









smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1831567 - /ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/META-INF/

2018-05-18 Thread Michael Brohl

Hi Nicolas, Taher,

thanks for reporting. It still looks ugly to have this META-INF 
directory but I've reverted the commit.


Sorry for the noise,

Michael


Am 17.05.18 um 10:36 schrieb Taher Alkhateeb:

If I remember correctly I think I put it there for this exact reason. It
used to be declared inside ant scripts and when we moved to gradle I
thought it looked ugly in the script so I moved it out as a declared
service.

On Thu, May 17, 2018, 11:34 AM Nicolas Malin 
wrote:


Hello Michael,

This commit break base tests :

~/workspace/apache-svn/ofbiz-trunk-test

poveglia$ svn up -r1831566

poveglia$ ./gradlew  "ofbiz --test component=base --test
suitename=basetests"

[...]

BUILD SUCCESSFUL in 2m 7s

poveglia$ svn up -r1831567

Mise à jour de '.' :

Dframework/base/src/main/java/META-INF

Actualisé à la révision 1831567.

~/workspace/apache-svn/ofbiz-trunk-test

poveglia$ ./gradlew  "ofbiz --test component=base --test
suitename=basetests"B

BUILD FAILED in 57s


with in test result log :



  java.lang.ClassNotFoundException:
java.lang.Class

  at
org.apache.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:205)...



Can you have the time to check or do you want some help to fix this issue ?
Nicolas

On 14/05/2018 15:34, mbr...@apache.org wrote:

Author: mbrohl
Date: Mon May 14 13:34:03 2018
New Revision: 1831567

URL: http://svn.apache.org/viewvc?rev=1831567=rev
Log:
Fixed: Removed unnecessary class and folders.

Removed:
  ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/META-INF/









smime.p7s
Description: S/MIME Cryptographic Signature


Re: New ASF Member from OFBiz Community

2018-05-03 Thread Michael Brohl

Congratulations, Deepak. Well deserved!

Best regards,

Michael

Am 02.05.18 um 17:38 schrieb Jacopo Cappellato:

Hi Everyone,

today the ASF has published the list of newly nominated members and "our"
Deepak Dixit is one of them:

https://blogs.apache.org/foundation/entry/the-apache-software-foundation-welcomes2


Congratulations Deepak!

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Confusing entity names

2018-04-14 Thread Michael Brohl

Suraj,

I still do not see much value in this change, compared to the effort 
needed for development and testing as well as the migration the users 
have to do.


Please consider to not do this change.

Thanks,

Michael


Am 13.04.18 um 10:09 schrieb Suraj Khurana:

Thanks everyone for your thoughts.

One more point is we also manage Data Migration By release document so it
will help existing uses. Such as https://cwiki.apache.org/confl
uence/display/OFBIZ/Data+Migration+by+releases

Handling of deprecated entities is also properly defined at
https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview,
we can easily follow these steps.

We will change entity name and its occurrence everywhere in code base,
provide a data migration service which will be helpful for existing uses.
Further on, thanks to Arun's suggestion, there will not be any confusion
related to entity name as well.

@Nicolas, Arun also suggested two names to avoid confusion, may be anyone
of them makes more sense to you.

--
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
Cell phone: +91 96697-50002

On Fri, Apr 13, 2018 at 1:22 PM, Nicolas Malin 
wrote:


Hi

On 10/04/2018 13: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.


It's big modification with potential side-effect.
I suggest to move carefully and migrate entities one by one and not all in
one :)

For the renaming OrderItemShipGroupto OrderShipGroupit's ok but I'm
against OrderItemShipGroupAssoc to OrderItemShipGroup. As pragmatic
OrderItemShipGroupAssoc isn't perfect like you spotted but it's easily
understandable.

Nicolas


--

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







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Confusing entity names

2018-04-12 Thread Michael Brohl

Hi Suraj,

thanks for your proposal.

Looking at it in isolation, it seems a good idea to just rename these 
entities.


Having the users in mind, I'm not sure if this is worth the need for 
data migrations they have to do if they want to stay up-to-date.


I'm not sure where the original names came from. When I'm in the office 
tomorrow, I'll consult the Data Model Resource Book. I'll be back then.


Thanks and regards,

Michael


Am 10.04.18 um 13:24 schrieb Suraj Khurana:

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1828569 - /ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml

2018-04-07 Thread Michael Brohl

Hi Taher,

I think this is correct. The javascript library itself is in the common 
theme, it is only referenced in the ecommerce plugin because it is 
needed there to fix the bug.


Regarding the commit message, Jacques: it would be good if you could 
take more time to write clear and brief commit messages. We have the 
reference to the Jira so it is not necessary to write down the steps to 
reproduce the problem again in the message.


I also would prefer if the commit messages are formulated in a neutral 
way and free of personal insights or first person narrative.


In this case, the type of change, title, Jira reference and thanks part 
would have been enough to get an impression of the change, all other 
information can easily be retrieved from the Jira.


Thanks,

Michael


Am 07.04.18 um 08:22 schrieb Taher Alkhateeb:

Hi Jacques,

I think the commit message is a bit confusing. What you did is simply add a
missing jQuery plugin.

Also, why did you add it to ecommerce and not the common-theme?

On Sat, Apr 7, 2018, 12:06 AM  wrote:


Author: jleroux
Date: Fri Apr  6 21:06:48 2018
New Revision: 1828569

URL: http://svn.apache.org/viewvc?rev=1828569=rev
Log:
Fixed: One Page Checkout page cannot move to Step 5 due to javascript
errors
(OFBIZ-10329)

I was trying to give one page checkout a try..
But seems like no matter which browser(used IE & Chrome) or version of
ofbiz
(used 17.12 and trunk demo) is used, one cannot go beyond  Step 4 :
Billing.
I.e. when you click on continue to step 5 we encounter some javascript
exception
which makes the checkout process hit the wall.

For actual error messges etc. please refer to screenshot attached.

Thanks: Sameer Gajanan Apte

Modified:
 ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml?rev=1828569=1828568=1828569=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml (original)
+++ ofbiz/ofbiz-plugins/trunk/ecommerce/widget/CommonScreens.xml Fri Apr
6 21:06:48 2018
@@ -48,6 +48,7 @@ under the License.

  
  
+
  
  
  








smime.p7s
Description: S/MIME Cryptographic Signature


Re: Deprecate properties in favour of SystemProperties

2018-04-05 Thread Michael Brohl

I made some clear propositions in my first answer to this thread.

Essentially, I'm against deprecating file based properties and be in 
favor of a general fallback solution (SystemProperty -> .properties) for 
all properties *except* properties which cannot be read from the 
database (system startup properties etc.)


It is extremely helpful to maintain file based properties along with 
templates and a build solution to populate system specific sets of 
settings (we had a discussion about it). This cannot be achieved 
reasonably with pure database based properties.



And again some remark: the initial problem was simply SystemProperty 
demo data overriding file based properties, which can be solved by 
preventing to load them by default.


Thanks,

Michael


Am 05.04.18 um 11:41 schrieb Taher Alkhateeb:

If my understanding is correct from Scott's suggestion, then this
entails substantial work as we need to:

- Identify "everything else" which is not a system configuration
property. Maybe some examples
- Find, and fix code related to properties which should not exist in
both db and files (remove fallback mechanism). Again, some examples
would be good.
- Figure out the implications from code design.
- Also, I'm assuming this has nothing to do with JVM system properties
correct? For example, take a look at
StartupControlPanel.loadGlobalOfbizSystemProperties(...).

So, to me the change in this proposal is still not crystal clear. AND
reading this thread I see objections on the idea from both myself and
Michael. So a clear strategy for what to do exactly and where would
help. A big idea without a clear implementation strategy might lead to
confusion.

On Thu, Apr 5, 2018 at 12:10 PM, Jacques Le Roux
 wrote:

Thanks Scott,

This is indeed essentially it.

I'll get into details in a new thread. Notably about how to load data.

Jacques


Le 05/04/2018 à 10:39, Scott Gray a écrit :

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
 longer ago <
https://markmail.org/message/gdcefnghjtezyn4b> before it was implemented
. 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
. 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 . I also
suggested to have
specific multitenant and multitenant-initial readers <
https://markmail.org/message/opldepaevls3y3ob> for business 

Re: buildbot exception in on ofbizTrunkFramework

2018-03-27 Thread Michael Brohl

Hi Rishi,

no worries, this seems to be a connection problem to jcenter:

FAILURE: Build failed with an exception. * What went wrong: A problem 
occurred configuring root project 'ofbiz'. > Could not resolve all 
dependencies for configuration ':classpath'. > Could not resolve 
at.bxm.gradleplugins:gradle-svntools-plugin:latest.release. Required by: 
project : > Could not resolve 
at.bxm.gradleplugins:gradle-svntools-plugin:latest.release. > Failed to 
list versions for at.bxm.gradleplugins:gradle-svntools-plugin. > Unable 
to load Maven meta-data from 
https://jcenter.bintray.com/at/bxm/gradleplugins/gradle-svntools-plugin/maven-metadata.xml. 
> Could not GET 
'https://jcenter.bintray.com/at/bxm/gradleplugins/gradle-svntools-plugin/maven-metadata.xml'. 
Received status code 502 from server: Bad Gateway


I guess it has nothing to do with your commit.

Regards,

Michael


Am 27.03.18 um 13:41 schrieb Rishi Solanki:

Tested again, no test failure. So not reverting the changes and will close
the ticket soon.

Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Tue, Mar 27, 2018 at 4:15 PM, Rishi Solanki 
wrote:


Not sure why this failure, my recent commit passes all the tests locally
and working fine. I will be surely monitor the upcoming builds and act
accordingly.

Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Tue, Mar 27, 2018 at 4:10 PM,  wrote:


The Buildbot has detected a build exception on builder
ofbizTrunkFramework while building . Full details are available at:
 https://ci.apache.org/builders/ofbizTrunkFramework/builds/171

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named
'onTrunkFrameworkCommit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1827827
Blamelist: rishi

BUILD FAILED: exception shell upload

Sincerely,
  -The Buildbot









smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-03-26 Thread Michael Brohl
We are using the new versions for some time now and found a lot of 
similar issues. Several of them were introduced in the same way by 
committing code which is badly designed or simply wrong.


I agree that we need another approach to prevent these changes slipping 
into the codebase without proper review. And it should be a no-go to 
commit changes or new functionality when there are already concerns by 
others.


Regards,

Michael


Am 26.03.18 um 04:39 schrieb 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=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)






smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-03-25 Thread Michael Brohl
ved 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<Class> ifaces = org.apache.commons.lang3.Class
Utils.getAllInterfaces(objectClass);

  for (Class iface: ifaces) {
  if (iface == interfaceClass) {
Index: framework/common/servicedef/services.xml
===
--- framework/common/servicedef/services.xml(révision 1827594)
+++ framework/common/servicedef/services.xml(copie de travail)
@@ -379,7 +379,7 @@
  
  Used to Automatically Authenticate a
username/password; create a UserLogin object
  
-
connector.RequestFacade"

optional="true"/>
+
HttpServletRequest"

optional="true"/>
  
  

Jacques





Regards
Scott

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

jacques.le.r...@les7arts.com>

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 <
jacques.le.r...@les7arts.com>
wrote:

Michael,


I commited http://svn.apache.org/viewvc/o
fbiz/ofbiz-framework/trunk/fra
mework/webapp/src/main/java/org/apache/ofbiz/webapp/contro
l/ContextFilter.java?r1=1813679=1813678=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=1819132&
pathrev=1819133

If I had not committed the wrapper in ContextFilter.java beforehand,
James
would not have been allowed to commit



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=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/fr
amework/common/servicedef/serv
ices.xml
UR

Re: Documentation commits (.adoc file type)

2018-03-22 Thread Michael Brohl

Done in r1827510

Michael


Am 22.03.18 um 10:46 schrieb Jacques Le Roux:

Le 22/03/2018 à 10:31, Jacques Le Roux a écrit :

So all should be OK after that.

Michael,

For educational purpose, I still let you complete 
ofbiz/tools/rat-excludes.txt


Thanks

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature


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

2018-03-22 Thread Michael Brohl

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=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/services.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/common/servicedef/services.xml?rev=1827439=1827438=1827439=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
  
-
+
  
  







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Oracle Java release model changes and consequences for the project

2018-03-21 Thread Michael Brohl
FYI: http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html

Regards,
Michael 

> Am 31.01.2018 um 17:44 schrieb Taher Alkhateeb <slidingfilame...@gmail.com>:
> 
> I suspect that there is no difference between openjdk and oracle jdk as far
> as the release cycle because oracle steers both.
> 
> However, like Jacopo I am not too concerned. The quick release cycle they
> want to adopt means that there will be perhaps less drastic changes between
> the versions.
> 
> I am open to changing our release cycle, but then we have to think
> carefully about releases and more importantly we _must_ automate updates.
> Something we can get ideas from is the upgrade package that a software
> system like suitecrm provides to allow users to upgrade with a click.
> 
> However, I prefer sticking with our release cycle until we have a complete
> idea of how to proceed.
> 
> On Jan 31, 2018 5:41 PM, "James Yong" <jamesy...@apache.org> wrote:
> 
> Hi all,
> 
> Not sure if this is workable.
> Can we do open-source development against OpenJDK using a version that is
> close to an Oracle JDK with LTS? Customers can choose the corresponding
> Oracle JDK with LTS in production if they want to.
> 
> Regards,
> James Yong
> 
>> On 2018/01/29 16:21:50, Michael Brohl <michael.br...@ecomify.de> wrote:
>> Hi devs,
>> 
>> this is just an initial information and dicussion starter to make
>> everyone aware of this:
>> 
>> the Oracle Java release model is changing from a feature based to a time
>> based model [1]. One major drawback is that there will be no more public
>> patch releases for older versions once a new release is published, if I
>> understand correctly.
>> 
>> We'll have to discuss if this affects the project in terms of support
>> for the latest public Java releases. If we want to stay up-to-date
>> according to the public releases, we'll have to establish a process to
>> early check the new features and changes of a coming release and maybe
>> release more often.
>> 
>> We might even have to support the latest Java release along with the
>> current LTS release to cover both users with and without commercial
>> support? I'm not sure.
>> 
>> What do you think?
>> 
>> Best regards,
>> 
>> Michael
>> 
>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>> 
>> 
>> 
>> 


Re: Welcome Paul Foxworthy as a new PMC member

2018-03-21 Thread Michael Brohl
Good to have you on board, Paul. Congratulations!

Regards,

Michael


> Am 21.03.2018 um 09:42 schrieb Jacopo Cappellato 
> :
> 
> The OFBiz PMC has invited Paul Foxworthy to become a new member of the
> committee and we are glad to announce that Paul has accepted the nomination.
> 
> Welcome on board Paul!
> 
> Jacopo Cappellato (on behalf of the OFBiz PMC)



Re: Documentation commits (.adoc file type)

2018-03-19 Thread Michael Brohl
Sure. I‘m off for a few days so it will take some time if not someone else 
beats me to it ;-)

Regards,
Michael



> Am 19.03.2018 um 11:26 schrieb Jacques Le Roux <jacques.le.r...@les7arts.com>:
> 
> I forgot that I looked at 
> https://ci.apache.org/builders/ofbizTrunkFrameworkRat few days ago and then 
> said in this thread
> 
>>> Weirdly Buildbot did not grasp the commit
>>> Let's wait, it's OK anyway
> 
> So I double checked today and still ofbizTrunkFrameworkRat was last ran few 
> days ago.
> 
> I started it manually from IRC and it worked 
> https://ci.apache.org/projects/ofbiz/rat-output.html. I'll have a look to see 
> why Buildbot did not grasp 
> the recent commits.
> 
> Please Michael, could you fill the ofbiz/tools/rat-excludes.txt ?
> 
> TIA
> 
> Jacques
> 
> 
>> Le 19/03/2018 à 10:09, Jacques Le Roux a écrit :
>> Not at all, it checks that we are putting the license header in our files as 
>> it's requested by ASF policy
>> 
>> Jacques
>> 
>> 
>>> Le 19/03/2018 à 09:44, Taher Alkhateeb a écrit :
>>> I'm not sure why we're using RAT anymore? I thought this is mostly for
>>> incubating projects to help them transition and license their files.
>>> Perhaps it might be simpler to remove it from the build script to
>>> reduce complexity?
>>> 
>>> On Mon, Mar 19, 2018 at 11:23 AM, Jacques Le Roux
>>> <jacques.le.r...@les7arts.com> wrote:
>>>> Hi Michael,
>>>> 
>>>> RAT still reports .adoc files as missing a license header
>>>> https://ci.apache.org/projects/ofbiz/rat-output.html
>>>> 
>>>> I see 2 reasons:
>>>> 
>>>>   * RAT does not know how to handle comment in .adoc files (more likely) so
>>>> does not find the license header
>>>>   * It's not the right way to comment a license header in .adoc files (at
>>>> least from RAT POV)
>>>> 
>>>> Could you please create a Jira request in CREADUR to clarify?
>>>> 
>>>> https://issues.apache.org/jira/projects/RAT/issues/RAT-248?filter=allopenissues
>>>> 
>>>> Thanks
>>>> 
>>>> Jacques
>>>> 
>>>> 
>>>> 
>>>>> Le 18/03/2018 à 14:36, Jacques Le Roux a écrit :
>>>>> Thanks Michael,
>>>>> 
>>>>> Weirdly Buildbot did not grasp the commit
>>>>> 
>>>>> Let's wait, it's OK anyway
>>>>> 
>>>>> Jacques
>>>>> 
>>>>> 
>>>>>> Le 18/03/2018 à 14:06, Michael Brohl a écrit :
>>>>>> Done.
>>>>>> 
>>>>>> Michael
>>>>>> 
>>>>>>> Am 18.03.18 um 13:27 schrieb Michael Brohl:
>>>>>>> Thanks for the hint, Pierre.
>>>>>>> 
>>>>>>> I will take care of it and complete the existing .adoc files, also leave
>>>>>>> a notice in the wiki.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Michael
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 18.03.18 um 12:28 schrieb Pierre Smits:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Please be aware that when an .adoc artefact is committed to the repo
>>>>>>>> that
>>>>>>>> the file has the Apache header in place.
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> 
>>>>>>>> Pierre Smits
>>>>>>>> 
>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>>>>>> OFBiz based solutions & services
>>>>>>>> 
>>>>>>>> OEM - The OFBiz Extensions Marketplace1
>>>>>>>> http://oem.ofbizci.net/oci-2/
>>>>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>> 
>> 
> 


Re: [DOC] Example asciidoc file as guideline

2018-03-18 Thread Michael Brohl

Maybe I was not clear enough... I am suggesting some kind of style guide.

I think if we provide it in the early stage, people might get inspired 
from it and have examples in a very compressed form. I find the several 
examples that I've studied very helpful but they are cluttered all over 
the internet so it could be a shortcut for others.


I will provide an example to make it clearer. Will take some days as I 
am off until coming Wednesday.


Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 18.03.18 um 17:46 schrieb Taher Alkhateeb:

Hmmm, Sounds like a good idea, but perhaps maybe a bit early? We might
be still evolving and learning how to structure our documents.

Also, maybe if we keep our documents clean and consistent, then they
themselves offer an example for how to write stuff? Examples usually
run out of date quickly unless we have some kind of mechanism in place
for always keeping them up to date. Anyway, if we decide to go that
route, [1] serves as a nice sample for us to imitate but with
instructions specific to OFBiz

[1] https://asciidoctor.org/docs/asciidoc-recommended-practices/

On Sun, Mar 18, 2018 at 7:35 PM, Michael Brohl <michael.br...@ecomify.de> wrote:

Heyho,

I played around with asciidoc a bit and did some minor changes to display a
nice title page and did some configurations for the user/developer manuals.

I studied a few example .adoc files and wonder if we should provide a best
practice example .adoc file. This could contain all formatting, guidelines
to mark special contents (info, attention, citations etc.) or how to format
code examples.

It would be a guideline as well as an example to learn from. I am hoping
that it is easier for people to get started and it could also improve the
quality.

This document itself could be in the codebase and evolve over time.

What do you think?

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de








smime.p7s
Description: S/MIME Cryptographic Signature


Re: svn commit: r1827146 - in /ofbiz/ofbiz-framework/trunk/docs/asciidoc: developer-manual.adoc images/OFBiz-Logo.svg user-manual.adoc

2018-03-18 Thread Michael Brohl

Hi Taher,

thank you :-)

The release number is just meant as an example in the course of playing 
with the documentation framework. I know it's wrong and should be adjusted.


I think it might be helpful to have the exact release version (if in a 
release branch) so we can provide generated pdf files for every release. 
If we have significant content in there and move the documentation from 
wiki to asciidoc, I hope that we have less trouble with outdated 
documentation or users using the wrong documentation for their release.


So for releases, I am in favor of (manually?) adjusting the release 
number in the doc or including the VERSION file (there's an open 
proposal in [1]). I am not sure if this is possible in the configuration 
section of asciidoc.


For the trunk, we could render just trunk or the build revision (if 
possible).


Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] https://issues.apache.org/jira/browse/OFBIZ-10141


Am 18.03.18 um 17:31 schrieb Taher Alkhateeb:

Now that I think about it, maybe we can actually even go as far as
publishing the subversion revision number on each call to
generateOfbizDocumentation if you folks think this is useful?

On Sun, Mar 18, 2018 at 7:29 PM, Taher Alkhateeb
<slidingfilame...@gmail.com> wrote:

Beautiful :) I love it

Release 17.12 though? Shouldn't we call it trunk / snapshot for now
and then rename it for each release?

On Sun, Mar 18, 2018 at 7:24 PM,  <mbr...@apache.org> wrote:

Author: mbrohl
Date: Sun Mar 18 16:24:31 2018
New Revision: 1827146

URL: http://svn.apache.org/viewvc?rev=1827146=rev
Log:
Improved: Added title page image in vector format, some basic author
and version information and table of contents configuration.

Added:
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg   (with 
props)
Modified:
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/developer-manual.adoc
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/user-manual.adoc

Modified: ofbiz/ofbiz-framework/trunk/docs/asciidoc/developer-manual.adoc
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/developer-manual.adoc?rev=1827146=1827145=1827146=diff
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/developer-manual.adoc (original)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/developer-manual.adoc Sun Mar 18 
16:24:31 2018
@@ -17,9 +17,17 @@ specific language governing permissions
  under the License.
  
  = Apache OFBiz Developer Manual
+The Apache OFBiz Project
+Release 17.12:
+:doctype: book
  :sectnums:
+:toc:
+:toclevels: 5
  :imagesdir: ./images
+ifdef::backend-pdf[]
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center]
+endif::[]

-image::OFBiz-Logo-250w.png[Apache OFBiz Logo, align="center"]
+== Intro

  content goes here

Added: ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg?rev=1827146=auto
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg (added)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg Sun Mar 18 
16:24:31 2018
@@ -0,0 +1,23 @@
+
+http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink;>
+
+OFBiz-Logo
+Created with Sketch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file

Propchange: ofbiz/ofbiz-framework/trunk/docs/asciidoc/images/OFBiz-Logo.svg
--
 svn:executable = *

Modified: ofbiz/ofbiz-framework/trunk/docs/asciidoc/user-manual.adoc
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/user-manual.adoc?rev=1827146=1827145=1827146=diff
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/user-manual.adoc (original)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/user-manual.adoc Sun Mar 18 
16:24:31 2018
@@ -17,10 +17,16 @@ specific language governing permissions
  under the License.
  
  = Apache OFBiz User Manual
+The Apache OFBiz Project
+Release 17.12:
+:doctype: book
  :sectnums:
+:toc:
+:toclevels: 5
  :imagesdir: ./images
-
-image::OFBiz-Logo-250w.png[Apache OFBiz Logo, align="center"]
+ifdef::backend-pdf[]
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center]
+endif::[]

  == Introduction to OFBiz








smime.p7s
Description: S/MIME Cryptographic Signature


[DOC] Example asciidoc file as guideline

2018-03-18 Thread Michael Brohl

Heyho,

I played around with asciidoc a bit and did some minor changes to 
display a nice title page and did some configurations for the 
user/developer manuals.


I studied a few example .adoc files and wonder if we should provide a 
best practice example .adoc file. This could contain all formatting, 
guidelines to mark special contents (info, attention, citations etc.) or 
how to format code examples.


It would be a guideline as well as an example to learn from. I am hoping 
that it is easier for people to get started and it could also improve 
the quality.


This document itself could be in the codebase and evolve over time.

What do you think?

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Documentation commits (.adoc file type)

2018-03-18 Thread Michael Brohl

Thanks Taher,

for file in $( find . -name "*.adoc" ); do cat ../license.txt ${file} > 
${file}.tmp; mv ${file}.tmp ${file}; done


did the trick ;-)

Regards,

Michael


Am 18.03.18 um 14:23 schrieb Taher Alkhateeb:

That was quick! Great work Michael

On Sun, Mar 18, 2018, 4:06 PM Michael Brohl <michael.br...@ecomify.de>
wrote:


Done.

Michael

Am 18.03.18 um 13:27 schrieb Michael Brohl:

Thanks for the hint, Pierre.

I will take care of it and complete the existing .adoc files, also
leave a notice in the wiki.

Thanks,

Michael


Am 18.03.18 um 12:28 schrieb Pierre Smits:

Hi All,

Please be aware that when an .adoc artefact is committed to the repo
that
the file has the Apache header in place.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project











smime.p7s
Description: S/MIME Cryptographic Signature


Re: Documentation commits (.adoc file type)

2018-03-18 Thread Michael Brohl

Done.

Michael

Am 18.03.18 um 13:27 schrieb Michael Brohl:

Thanks for the hint, Pierre.

I will take care of it and complete the existing .adoc files, also 
leave a notice in the wiki.


Thanks,

Michael


Am 18.03.18 um 12:28 schrieb Pierre Smits:

Hi All,

Please be aware that when an .adoc artefact is committed to the repo 
that

the file has the Apache header in place.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project









smime.p7s
Description: S/MIME Cryptographic Signature


Re: Documentation commits (.adoc file type)

2018-03-18 Thread Michael Brohl

Thanks for the hint, Pierre.

I will take care of it and complete the existing .adoc files, also leave 
a notice in the wiki.


Thanks,

Michael


Am 18.03.18 um 12:28 schrieb Pierre Smits:

Hi All,

Please be aware that when an .adoc artefact is committed to the repo that
the file has the Apache header in place.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project






smime.p7s
Description: S/MIME Cryptographic Signature


  1   2   3   4   5   6   7   8   9   10   >