Re: Welcome to Deepak Nigam as new committer!

2019-06-13 Thread Taher Alkhateeb
Congratulations Deepak, always great to see the team growing.

On Thu, Jun 13, 2019, 9:24 AM Devanshu Vyas 
wrote:

> Many Congratulations Deepak!
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Thu, Jun 13, 2019 at 11:20 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > The OFBiz PMC has invited Deepak to become a new committer and we are
> > pleased  to announce that he has accepted.
> >
> > Deepak  is part of the community since January 2016 and has proved to be
> > committed since.
> >
> > He notably made a great work for OFBIZ-10518 "Inventory (Supply)
> > Allocation Planning "
> >
> > He not only worked in Jira,  but also answered accurately on MLs where he
> > supported our users.
> >
> > Please join me in welcoming and congratulating Deepak.
> >
> > Jacques
> >
> >
>


Re: Welcome to Pawan Verma as new committer!

2019-06-13 Thread Taher Alkhateeb
Congratulations Pawan, looking forward to seeing you in action.

On Thu, Jun 13, 2019, 8:50 AM Jacques Le Roux 
wrote:

> The OFBiz PMC has invited Pawan to become a new committer and we are
> pleased  to announce that he has accepted.
>
> Pawan is part of the community for 2 years and has being quite active and
> proficient, notably these last times with several smart propositions.
>
> He also helps a lot of Jiras and answers properly on MLs.
>
> Please join me in welcoming and congratulating Pawan.
>
> Jacques
>
>


Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-03 Thread Taher Alkhateeb
As a general rule, minilang adds to the technical debt of this project. It
is hard to understand or maintain even simple constructs in minilang.

To generalize this concept... Patch != Good patch. So I recommend that
everything goes through the funnel of good old reviews. Good code has no
shortcuts, it is blood sweat and tears both for the provider and the
reviewer of patches.

On Mon, Jun 3, 2019, 4:20 PM Michael Brohl  wrote:

> I explained my POV in the Jira [1].
>
> Why not encourage the contributors to move their minilang tests to
> Groovy code? I can see that this has already been done, e.g. here [2]
> (thanks everyone involved!).
>
> I'm sure that the remaining patches will get converted soon, no need to
> choose the "easy way" and commit the minilang versions.
>
> If we will allow more minilang commits, we will always have the
> discussion and won't ever get rid of it.
>
> Thanks,
>
> Michael
>
> [1] https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-1463
>
> [2] https://issues.apache.org/jira/browse/OFBIZ-9002
>
>
>
> Am 03.06.19 um 13:21 schrieb Jacques Le Roux:
> > OK if this is a veto, no need to continue the discussion.-
> >
> > Else could you explain your POV Michael, notably about missing to put
> > in some new tests that could be helpful in the meantime?
> >
> > Thanks
> >
> > Le 02/06/2019 à 21:27, Michael Brohl a écrit :
> >> -1 to introduce more minilang code to the codebase. New code should
> >> be provided in either Java or Groovy code.
> >>
> >> Thanks,
> >> Michael
> >>
> >>
> >>
> >>> Am 02.06.2019 um 12:56 schrieb Jacques Le Roux
> >>> :
> >>>
> >>> Hi All,
> >>>
> >>> We started a discussion in OFBIZ-1463 about committing or not the
> >>> Minilang test patches.
> >>>
> >>> There are already few mixed opinions there (Michael, Aditya, Suraj
> >>> and I).
> >>>
> >>> Before voting I'd like to know if we can come to a consensus.
> >>>
> >>> Please read in OFBIZ-1463 and come back with your opinion.
> >>>
> >>> I have just changed mine because I believe using the tests as soon
> >>> they are reading is a good thing.
> >>>
> >>> Waiting would be a waste of not only work done but also time for
> >>> code safety. We can still move them to Groovy later, it's not more
> >>> work, I guess it's
> >>> even less.
> >>>
> >>> Jacques
> >>>
> >>
>
>


Re: Gradle eclipse task - classpath modification

2019-05-26 Thread Taher Alkhateeb
I see, sounds good. No harm in altering the exclusions.

On Sun, May 26, 2019 at 10:01 PM Michael Brohl  wrote:
>
> Hi Taher,
>
> I find it extremely useful to start OFBiz from the IDE ;-)
>
> This way hot code replacement is supported which helps changing code at
> runtime or while debugging.
>
> We add these two classpath entries by hand in Eclipse until now. I think
> there would be no problem to remove the two exclusions which would make
> these extra steps obsolete.
>
> Thanks,
>
> Michael
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 25.05.19 um 19:15 schrieb Taher Alkhateeb:
> > It might be more useful not to launch from the IDE. Instead run gradle
> > "ofbizDebug" and hookup remotely with the debug port. This would maintain a
> > consistent environment instead of being surprised (happened to me in the
> > past). It would also make a consistent experience to development team
> > regardless of the IDE and you won't have to alter the jar file to
> > accommodate an IDE.
> >
> > With that being said I don't think it's a big deal if you wish to remove
> > those exclusions. Up to community to decide.
> >
> >
> >
> > On Sat, May 25, 2019, 6:37 PM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> >> So every IDE provides a shortcut (certain combination of keys) to execute
> >> any java file in a project as a java application, that in turn invokes
> >> *java
> >> *command on that class file. Eclipse applies all classpath entries (list of
> >> jar files from gradle dependency) as -classpath argument.
> >>
> >> Under the hood command that gets executed is -
> >>
> >> java org.apache.ofbiz.base.start.Start -classpath 
> >>
> >> I do this because it saves a lot of time. As soon as you make any change in
> >> any file, especially java, it is compiled instantaneously as soon as you
> >> save it. All you have to do is, just run Start.java as a java application
> >> and you have OFBiz launched quickly.
> >>
> >>
> >>
> >> On Sat, May 25, 2019 at 7:23 PM Taher Alkhateeb <
> >> slidingfilame...@gmail.com>
> >> wrote:
> >>
> >>> start how? what is the command? Are you trying to start _from_ eclipse.
> >> If
> >>> yes why?
> >>>
> >>> On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
> >>> girish.vasmat...@hotwaxsystems.com> wrote:
> >>>
> >>>> I realised Taher's reply after I had sent my response.
> >>>>
> >>>> Following's the command.
> >>>>
> >>>> *./gradlew eclipse*
> >>>>
> >>>> This would do the job of setting up the eclipse workspace with all all
> >>>> gradle dependencies nicely set-up in the classpath.
> >>>>
> >>>> Then I would normally try to start OFBiz using Start.java. Not sure if
> >>> you
> >>>> can see the inline screenshot. Pl see below.
> >>>>
> >>>> [image: image.png]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> >>>> girish.vasmat...@hotwaxsystems.com> wrote:
> >>>>
> >>>>> There is a bit more to it ...
> >>>>>
> >>>>> When the system can't find cache.properties (as it's no more on the
> >>>>> classpath), following happens -
> >>>>>
> >>>>> 1. Exception is thrown (which is obvious)
> >>>>> 2. Code execution halts (which is fine), so no tomcat is launched.
> >>>>> 3. Since execution stops, JVM should be terminated in my opinion. In
> >>>>> other words, JVM should not keep hanging doing nothing, better stop it
> >>> if a
> >>>>> major exception has occurred. The JVM process is never terminated in
> >>> this
> >>>>> case.
> >>>>>
> >>>>> Again, this is a very isolated scenario because it is always expected
> >>>>> that these config files and folders are always going to be on the
> >>>>> classpath. But this is one of those rare scenarios
> >>>>> where that's not the case.
> >>>>>
> >>>>> Log4j2 internal initialization logging.
> >>>>>

Re: Gradle eclipse task - classpath modification

2019-05-25 Thread Taher Alkhateeb
It might be more useful not to launch from the IDE. Instead run gradle
"ofbizDebug" and hookup remotely with the debug port. This would maintain a
consistent environment instead of being surprised (happened to me in the
past). It would also make a consistent experience to development team
regardless of the IDE and you won't have to alter the jar file to
accommodate an IDE.

With that being said I don't think it's a big deal if you wish to remove
those exclusions. Up to community to decide.



On Sat, May 25, 2019, 6:37 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> So every IDE provides a shortcut (certain combination of keys) to execute
> any java file in a project as a java application, that in turn invokes
> *java
> *command on that class file. Eclipse applies all classpath entries (list of
> jar files from gradle dependency) as -classpath argument.
>
> Under the hood command that gets executed is -
>
> java org.apache.ofbiz.base.start.Start -classpath 
>
> I do this because it saves a lot of time. As soon as you make any change in
> any file, especially java, it is compiled instantaneously as soon as you
> save it. All you have to do is, just run Start.java as a java application
> and you have OFBiz launched quickly.
>
>
>
> On Sat, May 25, 2019 at 7:23 PM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > start how? what is the command? Are you trying to start _from_ eclipse.
> If
> > yes why?
> >
> > On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> > > I realised Taher's reply after I had sent my response.
> > >
> > > Following's the command.
> > >
> > > *./gradlew eclipse*
> > >
> > > This would do the job of setting up the eclipse workspace with all all
> > > gradle dependencies nicely set-up in the classpath.
> > >
> > > Then I would normally try to start OFBiz using Start.java. Not sure if
> > you
> > > can see the inline screenshot. Pl see below.
> > >
> > > [image: image.png]
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> > > girish.vasmat...@hotwaxsystems.com> wrote:
> > >
> > >> There is a bit more to it ...
> > >>
> > >> When the system can't find cache.properties (as it's no more on the
> > >> classpath), following happens -
> > >>
> > >> 1. Exception is thrown (which is obvious)
> > >> 2. Code execution halts (which is fine), so no tomcat is launched.
> > >> 3. Since execution stops, JVM should be terminated in my opinion. In
> > >> other words, JVM should not keep hanging doing nothing, better stop it
> > if a
> > >> major exception has occurred. The JVM process is never terminated in
> > this
> > >> case.
> > >>
> > >> Again, this is a very isolated scenario because it is always expected
> > >> that these config files and folders are always going to be on the
> > >> classpath. But this is one of those rare scenarios
> > >> where that's not the case.
> > >>
> > >> Log4j2 internal initialization logging.
> > >>
> > >> java.util.MissingResourceException: Can't find bundle for base name
> > >> cache, locale en
> > >>
> > >> at java.util.ResourceBundle.throwMissingResourceException(
> > >> ResourceBundle.java:1573)
> > >>
> > >> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
> > >>
> > >> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:191)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:173)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:169)
> > >>
> > >> at
> org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
> > >> UtilCache.java:797)
> > >>
> > >> at org.apache.ofbiz.base.util.UtilProperties.(
> > >> UtilProperties.java:75)
> > >>
> > >> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
> > >>
> &g

Re: Gradle eclipse task - classpath modification

2019-05-25 Thread Taher Alkhateeb
start how? what is the command? Are you trying to start _from_ eclipse. If
yes why?

On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> I realised Taher's reply after I had sent my response.
>
> Following's the command.
>
> *./gradlew eclipse*
>
> This would do the job of setting up the eclipse workspace with all all
> gradle dependencies nicely set-up in the classpath.
>
> Then I would normally try to start OFBiz using Start.java. Not sure if you
> can see the inline screenshot. Pl see below.
>
> [image: image.png]
>
>
>
>
>
>
> On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
>> There is a bit more to it ...
>>
>> When the system can't find cache.properties (as it's no more on the
>> classpath), following happens -
>>
>> 1. Exception is thrown (which is obvious)
>> 2. Code execution halts (which is fine), so no tomcat is launched.
>> 3. Since execution stops, JVM should be terminated in my opinion. In
>> other words, JVM should not keep hanging doing nothing, better stop it if a
>> major exception has occurred. The JVM process is never terminated in this
>> case.
>>
>> Again, this is a very isolated scenario because it is always expected
>> that these config files and folders are always going to be on the
>> classpath. But this is one of those rare scenarios
>> where that's not the case.
>>
>> Log4j2 internal initialization logging.
>>
>> java.util.MissingResourceException: Can't find bundle for base name
>> cache, locale en
>>
>> at java.util.ResourceBundle.throwMissingResourceException(
>> ResourceBundle.java:1573)
>>
>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>>
>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:191)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:173)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:169)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
>> UtilCache.java:797)
>>
>> at org.apache.ofbiz.base.util.UtilProperties.(
>> UtilProperties.java:75)
>>
>> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>>
>> at org.apache.ofbiz.base.container.ContainerLoader.load(
>> ContainerLoader.java:61)
>>
>> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
>> StartupControlPanel.java:218)
>>
>> at org.apache.ofbiz.base.start.StartupControlPanel.start(
>> StartupControlPanel.java:71)
>>
>> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>>
>>
>> Best,
>> Girish
>>
>> On Sat, May 25, 2019 at 2:56 PM Girish Vasmatkar <
>> girish.vasmat...@hotwaxsystems.com> wrote:
>>
>>> Hi Mathieu,
>>>
>>> With those entries missing from the classpath, you'd get the following
>>> exceptions and warning -
>>>
>>> 1. For cache.properties (when /framework/base/config entry is missing)
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>
>>> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>>>
>>> at org.apache.ofbiz.base.container.ContainerLoader.load(
>>> ContainerLoader.java:61)
>>>
>>> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
>>> StartupControlPanel.java:218)
>>>
>>> at org.apache.ofbiz.base.start.StartupControlPanel.start(
>>> StartupControlPanel.java:71)
>>>
>>> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>>>
>>> Caused by: java.util.MissingResourceException: Can't find bundle for
>>> base name cache, locale en
>>>
>>> at java.util.ResourceBundle.throwMissingResourceException(
>>> ResourceBundle.java:1573)
>>>
>>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>>>
>>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:177)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:173)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:169)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
>>> UtilCache.java:779)
>>>
>>> at org.apache.ofbiz.base.util.UtilProperties.(
>>> UtilProperties.java:75)
>>>
>>> ... 5 more
>>>
>>> 2. when /framework/base/dtd entry is missing (contains all schema files)
>>>
>>> 2019-05-25 14:48:37,591 |main |ContainerLoader
>>>   |I| [Startup] Loading containers...
>>>
>>> 2019-05-25 14:48:38,431 |main |UtilXml
>>>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL
>>> DTD/Schema with publicId [null] and the file/resource is
>>> [ofbiz-containers.xsd]
>>>
>>> 2019-05-25 14:48:39,139 |main |ContainerLoader
>>>   

Re: Gradle eclipse task - classpath modification

2019-05-25 Thread Taher Alkhateeb
What is the exact command used to run?

On Sat, May 25, 2019, 12:27 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi Mathieu,
>
> With those entries missing from the classpath, you'd get the following
> exceptions and warning -
>
> 1. For cache.properties (when /framework/base/config entry is missing)
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
>
> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>
> at org.apache.ofbiz.base.container.ContainerLoader.load(
> ContainerLoader.java:61)
>
> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
> StartupControlPanel.java:218)
>
> at org.apache.ofbiz.base.start.StartupControlPanel.start(
> StartupControlPanel.java:71)
>
> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>
> Caused by: java.util.MissingResourceException: Can't find bundle for base
> name cache, locale en
>
> at java.util.ResourceBundle.throwMissingResourceException(
> ResourceBundle.java:1573)
>
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:177)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:173)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:169)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
> UtilCache.java:779)
>
> at
> org.apache.ofbiz.base.util.UtilProperties.(UtilProperties.java:75
> )
>
> ... 5 more
>
> 2. when /framework/base/dtd entry is missing (contains all schema files)
>
> 2019-05-25 14:48:37,591 |main |ContainerLoader
>   |I| [Startup] Loading containers...
>
> 2019-05-25 14:48:38,431 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-containers.xsd]
>
> 2019-05-25 14:48:39,139 |main |ContainerLoader
>   |I| Loading container: component-container
>
> 2019-05-25 14:48:39,244 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [component-loader.xsd]
>
> 2019-05-25 14:48:39,596 |main |ComponentContainer
>   |I| Auto-Loading component directory :
> [/Users/grv/git/clients/warbyparker/github/ofbiz/framework]
>
> 2019-05-25 14:48:39,641 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [component-loader.xsd]
>
> 2019-05-25 14:48:39,898 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,210 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,496 |main |ComponentContainer
>   |I| Added class path for component : [base]
>
> 2019-05-25 14:48:40,552 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,923 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:41,162 |main |ComponentContainer
>   |I| Added class path for component : [entity]
>
> 2019-05-25 14:48:41,190 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:41,491 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,300 |main |ComponentContainer
>   |I| Added class path for component : [security]
>
> 2019-05-25 14:48:42,323 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,615 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,865 |main |ComponentContainer
>   |I| Added class path for component : [datafile]
>
> 2019-05-25 14:48:42,883 |main |UtilXml
>   |W| 

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

2019-05-19 Thread Taher Alkhateeb
I'm also in favor of the more flexible design based on roles. Let the
services worry about sorting this stuff out and leave the entity
domain layer solid and well designed.

On Thu, May 16, 2019 at 11:25 PM Michael Brohl  wrote:
>
> Hi Pierre,
>
> I think there are more sophisticated concepts for some of the mentioned
> entities, for example
>
> - OrderRole for orders allows to connect an unlimited number of parties
> with different roles
>
> - CustRequestParty, QuoteRole, CustRequestRole - same principle
>
> For these, introducing from/toPartyId would be no improvement IMO. *If*
> we would want to make a change, I would tend more to implementing the
> ...Role principle where it is missing and get rid of the from/toPartyId
> pattern. But this would be a big change...
>
> I'm not sure why we have these in some entities which also have the
> ...Role entities, such as Invoice.
>
> Maybe others can give more insights?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> > - Agreement (in party)
> > - Employment (in humanres)
> > - Invoice (in accounting
> > - OrderReportPurchasesGroupByProduct
> > - PartyBenefit (in humanres)
> > - Payment (in accounting)
> > - PayHistory (in humanres)
> > - ReturnHeader (in Order)
> > - UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> > - OrderHeader: neither partyIdFrom nor partyIdTo
> > - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> > - CustRequest: only having fromPartyid (plus its role
> > - Subscription: having originatedFromPartyId (plus the role) and partyId
> > - ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > 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
> >
>


Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-19 Thread Taher Alkhateeb
It's already done. I'm suggesting future actions for future JDKs

On Fri, Apr 19, 2019, 8:53 PM Jacques Le Roux 
wrote:

> Hi Taher,
>
> Sounds like a plan, will you create those Jiras Taher?
>
> Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it
> until we swap?
>
> I believe the later is the easiest for all of us, but could be confusing
> after a moment.
>
> Jacques
>
> Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :
> > I see no problem in sticking with 8. It would also probably be
> > beneficial to get the code base to be compatible with Java 11 so that
> > people who want to upgrade are not restricted from doing so (which we
> > have done already). In other words, like Scott said, it should be a
> > "minimum" instead of a "maximum". When we were trying to upgrade we
> > faced some obstacles and resolved them. which means this needs to be a
> > task regularly done.
> >
> > So we could perhaps regularly create JIRAs like "Ensure OFBiz can
> > operate on Java version X" so that the code base is always forward
> > compatible.
> >
> > On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
> >  wrote:
> >> Reasons to increase the minimum version:
> >> - compelling new features
> >> - end of support of current minimum
> >>
> >> Reasons to not increase the minimum:
> >> - potential instability of new version
> >> - complicates the life of users and contributors who still use the
> existing
> >> minimum
> >> - lack of expertise in configuring and using new features
> >>
> >> I think every few months we should discuss it but I don't think it's
> worth
> >> shifting any time soon. The pros need to outweigh the cons, and
> personally
> >> I don't really see it at the moment.
> >>
> >> The end of support date for 11 probably shouldn't be a consideration at
> >> this point, by the time we even get close to that java 23 LTS will
> probably
> >> be a year old :)
> >>
> >> Regards
> >> Scott
> >>
> >> On Tue, 16 Apr 2019, 00:50 Michael Brohl, 
> wrote:
> >>
> >>> Ah, sorry Taher if I was not clear enough.
> >>>
> >>> Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> >>> trunk, 18.12 and 17.12 to make the project independent from the short
> >>> cycled releases of the Oracle JDK and the subscription for use of the
> >>> Oracle JDK 8 LTS.
> >>>
> >>> I just recognized that Adopt JDK 11 LTS will be available until Sept.
> >>> 2022. If that is not a mistake I have to refine the timeline: we can
> >>> then switch to Adopt Open JDK 11 LTS on trunk right before the release
> >>> branch for 19.x is created. I guess that the future LTS releases will
> >>> have support for at least 4 years.
> >>>
> >>> That means we would remain Java 8 compatible for the releases 16 to 18
> >>> and announce the Java 11 dependency for release 19 and up. This should
> >>> give users enough time to plan, test and migrate.
> >>>
> >>> Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> >>> then.
> >>>
> >>> For the future, I would suggest to introduce a new Open JDK LTS version
> >>> about 3-6 months after the first release, we might want to create a new
> >>> release branch in the course of this.
> >>>
> >>> What do you think?
> >>>
> >>> Regards,
> >>>
> >>> Michael Brohl
> >>>
> >>> ecomify GmbH - www.ecomify.de
> >>>
> >>>
> >>> Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
> >>>> Hi Michael,
> >>>>
> >>>> So just to understand your suggestion clearly. Are you recommending
> >>>> that we switch from oracle JDK to open JDK now (in 18 and trunk) and
> >>>> introduce open jdk 11 in 2021?
> >>>>
> >>>> On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl <
> michael.br...@ecomify.de>
> >>> 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.
> >>>>>
> >>>>> Prof

Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-17 Thread Taher Alkhateeb
I see no problem in sticking with 8. It would also probably be
beneficial to get the code base to be compatible with Java 11 so that
people who want to upgrade are not restricted from doing so (which we
have done already). In other words, like Scott said, it should be a
"minimum" instead of a "maximum". When we were trying to upgrade we
faced some obstacles and resolved them. which means this needs to be a
task regularly done.

So we could perhaps regularly create JIRAs like "Ensure OFBiz can
operate on Java version X" so that the code base is always forward
compatible.

On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
 wrote:
>
> Reasons to increase the minimum version:
> - compelling new features
> - end of support of current minimum
>
> Reasons to not increase the minimum:
> - potential instability of new version
> - complicates the life of users and contributors who still use the existing
> minimum
> - lack of expertise in configuring and using new features
>
> I think every few months we should discuss it but I don't think it's worth
> shifting any time soon. The pros need to outweigh the cons, and personally
> I don't really see it at the moment.
>
> The end of support date for 11 probably shouldn't be a consideration at
> this point, by the time we even get close to that java 23 LTS will probably
> be a year old :)
>
> Regards
> Scott
>
> On Tue, 16 Apr 2019, 00:50 Michael Brohl,  wrote:
>
> > Ah, sorry Taher if I was not clear enough.
> >
> > Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> > trunk, 18.12 and 17.12 to make the project independent from the short
> > cycled releases of the Oracle JDK and the subscription for use of the
> > Oracle JDK 8 LTS.
> >
> > I just recognized that Adopt JDK 11 LTS will be available until Sept.
> > 2022. If that is not a mistake I have to refine the timeline: we can
> > then switch to Adopt Open JDK 11 LTS on trunk right before the release
> > branch for 19.x is created. I guess that the future LTS releases will
> > have support for at least 4 years.
> >
> > That means we would remain Java 8 compatible for the releases 16 to 18
> > and announce the Java 11 dependency for release 19 and up. This should
> > give users enough time to plan, test and migrate.
> >
> > Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> > then.
> >
> > For the future, I would suggest to introduce a new Open JDK LTS version
> > about 3-6 months after the first release, we might want to create a new
> > release branch in the course of this.
> >
> > What do you think?
> >
> > Regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
> > > Hi Michael,
> > >
> > > So just to understand your suggestion clearly. Are you recommending
> > > that we switch from oracle JDK to open JDK now (in 18 and trunk) and
> > > introduce open jdk 11 in 2021?
> > >
> > > On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl 
> > wrote:
> > >> Hi Scott, all,
> > >>
> > >> yes, Adopt Open JDK 8 LTS is supported at least untile September 2023
> > [1]
> > >>
> > >> Thinking about this a bit more I second to stay with Open JDK 8 LTS for
> > >> release branches 17.12, 18.12 and trunk for now.
> > >>
> > >> Professional users/ companies have a very conservative update strategy
> > >> for base technologies like the JDK and we should support it as long as
> > >> it is reasonable.
> > >>
> > >> So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the
> > >> release branch 21.x, meaning that we change to JDK 11 right before the
> > >> release branch will be created. This gives us plenty of time to test
> > >> with Java 11 and we can introduce Java 11 features in the trunk after
> > >> that. So release branch 22.x would be the first to depend on Java 11.
> > >>
> > >> What do you think?
> > >>
> > >> Best regards,
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >> [1] https://adoptopenjdk.net/support.html
> > >>
> > >>
> > >> Am 15.04.19 um 00:07 schrieb Scott Gray:
> > >>> My understanding was that openjdk would support java 8 until 2023.
> > >>>
> > >>> In the past our strategy used to b

Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-15 Thread 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
> >>>>>
> >>>>>
>


Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-15 Thread Taher Alkhateeb
Hi Scott,

I'm not sure if this helps with running two versions simultaneously, but I
have multiple versions on my machine, and I setup the $JAVA_HOME to point
to /opt/jdk which in turn is a symlink to the JDK found in /opt/java/jdk8.
This way changing the jdk version is as fast as changing the symlink. I
even wrote a little script that looks up versions and I select the one most
appropriate.

Of course this is a side note, staying on Java 8 is fine by me given
getting more contributions from the community including yourself. I remain
on the fence.


On Mon, Apr 15, 2019, 1:08 AM Scott Gray 
wrote:

> My understanding was that openjdk would support java 8 until 2023.
>
> In the past our strategy used to be that we should ensure the code base
> would operate on newer java versions but keep our minimum required version
> as low as possible.  That effectively allows users to run whatever version
> they like.  So unless there are some compelling new features in java
> 9/10/11 that we think we must have, I'd prefer it if we kept our minimum
> supported version as low as possible.
>
> For myself, all client projects are still running java 8 (openjdk) so
> before I could continue contributing to OFBiz I would have to figure out
> how to run both versions on my machine with minimal disruption.  Since I
> don't have a huge amount of spare time, I would probably just put it off
> for quite a while and work on other things.
>
> I'm not trying to veto the idea, if the community wants to proceed then it
> should but I doubt I'm the only contributor we'd be putting another hurdle
> in front of.
>
> Regards
> Scott
>
> On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
> wrote:
>
> > Well, I could be mistaken but it seems EOL for java 8 is coming soon
> (2019
> > commercial 2020 personal) [1]. This seems to be the case because the new
> > LTS is out which is java 11.
> >
> > Also this new release model from oracle seems to be annoying which is
> > pushing developers to adopt the openjdk instead. So I guess the reason
> for
> > the upgrade is to strike two birds with one stone: upgrade java and
> switch
> > to openjdk.
> >
> > With that being said, I don't have a firm opinion on upgrading and I just
> > wanted to highlight things, I leave it to other folks to decide.
> >
> > [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >
> > On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
> > wrote:
> >
> > > That would probably halt any further contributions from me in the short
> > to
> > > medium term.
> > >
> > > Can I ask why we need to require 11 when 8 is supported through to
> 2023?
> > >
> > > Regards
> > > Scott
> > >
> > > On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <
> > jacques.le.r...@les7arts.com>
> > > wrote:
> > >
> > > > If nobody disagree, I'll make the last move (ie ask for Java 11 in
> > > > build.gradle) in 3 days
> > > >
> > > > Jacques
> > > >
> > > > Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> > > > > On 13/04/2019 11:47, Jacques Le Roux wrote:
> > > > >> I just tested, without surprise the trunk HEAD works with Java 11
> > > > >
> > > > > I did the same with 18.12, works fine
> > > > >
> > > > > Nicolas
> > > > >
> > > > >
> > > >
> > >
> >
>


Re: [OPTIONS] Java 11 and Java JDK origin

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


Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-12 Thread Taher Alkhateeb
I would suggest to make the move as soon as ready. This includes a
final patch and an update of README

On Fri, Apr 12, 2019 at 3:28 PM Jacques Le Roux
 wrote:
>
> Hi All,
>
> This is now done. When should we switch the trunk and R18 to Java 11?
>
> Thanks
>
> Jacques
>
> Le 05/03/2019 à 17:53, Nicolas Malin a écrit :
> > I agree with all proposal that make sens :)
> >
> > Nicolas
> >
> > On 04/03/2019 12:31, Jacques Le Roux wrote:
> >> +1
> >>
> >> Jacques
> >>
> >> Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :
> >>> I think that the simplest way to convey this message is to edit the README
> >>> document with a link to OpenJDK rather than Oracle JDK.
> >>>
> >>> Jacopo
> >>>
> >>> On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> We should then make clear to our users that they will need to switch to
> >>>> OpenJDK if they want free security support.
> >>>>
> >>>> I guess most are aware, but maybe not small companies or single users.
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 28/02/2019 à 18:48, Michael Brohl a écrit :
> >>>>> +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
> >>>>>>>
> >>
> >


Re: Reformat and homogenize displaying number

2019-04-09 Thread Taher Alkhateeb
looks good. I'm not sure what's the difference between accounting and
default formats though? And why do we have Integer format?

I would probably limit the types of formatting to percentage and
currency and quantity. Between those three you probably have all cases
covered no?

On Fri, Apr 5, 2019 at 7:58 PM Nicolas Malin  wrote:
>
> Hello
>
> I would improve an idea present by Charles STELTZLEN on issue OFBIZ-7532 [1]
>
> Currently when you display a number you have different possibility to
> format it :
>   * by ftl with <@ofbizAmount>
>   * by widget with 
>   * or everywhere with UtilFormatOut.formatDecimalNumber(number,
> template, locale)
>
> Main problem, we haven't a simple solution to homogenize display
> template number by purpose without check each case on source code.
> A example, if you display your invoice amount on 3 digits and your order
> amount on 6 digits, you can't use ofbizAmount or accounting-number so
> you do raw call :
>   * for invoice: UtilFormatOut.formatDecimalNumber(invoiceAmount,
> '##0.000', locale)
>   * for order: UtilFormatOut.formatDecimalNumber(invoiceAmount,
> '##0.00', locale)
>
> on ftl
> ${Static["org.apache.ofbiz.base.util.UtilFormatOut"].formatDecimalNumber(invoiceAmount,
> '##0.000', locale)}
> on widget
>  
>
> All displaying template pass through new util
> *UtilFormatOut.formatNumber* as generic function to works with a format
> type present on properties. With this idea, you can use on you specific
> source code your own format and override standard ofbiz format.
>
> I will suggest a patch on issue OFBIZ-7532 [1]
>
> I thinks it's important feature to help customization so if you have a
> suggest, your welcome :)
>
> Cheers,
> Nicolas
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-7532
>
> --
> logoNrd 
> Nicolas Malin
> The apache way  : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz |The Apache Way
> |réseau LE 


Re: Strong dependency of OFBiz build on JCenter

2019-03-23 Thread Taher Alkhateeb
Ahh I get it now.

In that case the challenge might be making sure the naming and transitive
dependencies are equivalent on both sides.

Maybe another solution is to create two files, one for maven and the other
for jcenter each with its own unique set of dependencies that can be tested
and ensured correct behavior. This way differences in names or transitive
dependencies are not an issue.

On Sat, Mar 23, 2019, 5:09 PM Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Just to clarify, I was suggesting that we could add more repositories, not
> replace Jcenter with another one: the redundancy would mitigate the risk of
> unavailability.
>
> Jacopo
>
> On Fri, Mar 22, 2019 at 6:07 PM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > Whatever repository you choose, there is always the risk of going down.
> >
> > To mitigate this risk, you can (after deploying the system) use the -
> > -offline flag when running gradle. Alternatively you can simply run the
> > java - jar command.
> >
> > On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane <
> > swapnil.m...@hotwaxsystems.com> wrote:
> >
> > > Hello team,
> > >
> > > Yesterday JCenter was down for some time, due to which I was unable to
> > > start the OFBiz server (because the build was failed).
> > > Status of JCenter can be found at [1].
> > >
> > > This is a severe issue because it may be possible during any production
> > > deployment, JCenter is down. Do we have any solution for the issue?
> > > Please let me know if I am missing anything.
> > >
> > > [1] https://status.bintray.com/
> > >
> > > Here is stacktrace of build failure.
> > > ==
> > > *> Task :compileTestJava* FAILED
> > >
> > > FAILURE: Build failed with an exception.
> > >
> > > * What went wrong:
> > > Execution failed for task ':compileTestJava'.
> > > > Could not resolve all files for configuration
> ':testCompileClasspath'.
> > >> Could not resolve org.mockito:mockito-core:2.+.
> > >  Required by:
> > >  project :
> > >   > Failed to list versions for org.mockito:mockito-core.
> > >  > Unable to load Maven meta-data from
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > .
> > > > Could not HEAD '
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > '.
> > >> jcenter.bintray.com
> > >   > Failed to list versions for org.mockito:mockito-core.
> > >  > Unable to load Maven meta-data from
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > .
> > > > Could not HEAD '
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > '.
> > >> jcenter.bintray.com
> > >
> > > * Try:
> > > Run with *--stacktrace* option to get the stack trace. Run with
> *--info*
> > or
> > > *--debug* option to get more log output. Run with *--scan* to get full
> > > insights.
> > >
> > > * Get more help at *https://help.gradle.org
> > > <
> > >
> >
> https://www.google.com/url?q=https://help.gradle.org=D=hangouts=1553323118761000=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q
> > > >*
> > >
> > > *BUILD FAILED* in 1m 14s
> > > ==
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > www.hotwax.co
> > >
> >
>


Re: Strong dependency of OFBiz build on JCenter

2019-03-22 Thread Taher Alkhateeb
Whatever repository you choose, there is always the risk of going down.

To mitigate this risk, you can (after deploying the system) use the -
-offline flag when running gradle. Alternatively you can simply run the
java - jar command.

On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane <
swapnil.m...@hotwaxsystems.com> wrote:

> Hello team,
>
> Yesterday JCenter was down for some time, due to which I was unable to
> start the OFBiz server (because the build was failed).
> Status of JCenter can be found at [1].
>
> This is a severe issue because it may be possible during any production
> deployment, JCenter is down. Do we have any solution for the issue?
> Please let me know if I am missing anything.
>
> [1] https://status.bintray.com/
>
> Here is stacktrace of build failure.
> ==
> *> Task :compileTestJava* FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':compileTestJava'.
> > Could not resolve all files for configuration ':testCompileClasspath'.
>> Could not resolve org.mockito:mockito-core:2.+.
>  Required by:
>  project :
>   > Failed to list versions for org.mockito:mockito-core.
>  > Unable to load Maven meta-data from
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> .
> > Could not HEAD '
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> '.
>> jcenter.bintray.com
>   > Failed to list versions for org.mockito:mockito-core.
>  > Unable to load Maven meta-data from
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> .
> > Could not HEAD '
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> '.
>> jcenter.bintray.com
>
> * Try:
> Run with *--stacktrace* option to get the stack trace. Run with *--info* or
> *--debug* option to get more log output. Run with *--scan* to get full
> insights.
>
> * Get more help at *https://help.gradle.org
> <
> https://www.google.com/url?q=https://help.gradle.org=D=hangouts=1553323118761000=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q
> >*
>
> *BUILD FAILED* in 1m 14s
> ==
>
> - Best Regards,
> Swapnil M Mane,
> www.hotwax.co
>


Re: Removing the ‘:terminateOfbiz’ Gradle task

2019-03-17 Thread Taher Alkhateeb
I think I might prefer to keep it. Perhaps adjusting the ps command might
better solve the issue. I use this feature regularly myself.

On Sun, Mar 17, 2019, 11:59 PM Mathieu Lirzin 
wrote:

> Hello,
>
> The ‘:terminateOfbiz’ Gradle task is meant to be run when ‘./gradlew
> ofbiz --shutdown’ doesn't work.  Unfortunately this task is not working
> on my GNU/linux system because the output of ‘ps ax’ cuts long lines.
> As a consequence Gradle is not able to grep
> "org.apache.ofbiz.base.start.Start" even if it is actually part of the
> process command line as seen by the operating system.  As a reminder,
> here is the implementation of that task:
>
> task terminateOfbiz(group: ofbizServer,
> description: 'Force termination of any running OFBiz servers, only
> use if \"--shutdown\" command fails') {
> doLast {
> if (os.contains('windows')) {
> Runtime.getRuntime().exec("wmic process where
> \"CommandLine Like \'%org.apache.ofbiz.base.start.Start%\'\" Call
> Terminate")
> } else {
> def processOutput = new ByteArrayOutputStream()
> exec {
> commandLine 'ps', 'ax'
> standardOutput = processOutput
> }
>
> processOutput.toString().split(System.lineSeparator()).each { line ->
> if (line ==~
> /.*org\.apache\.ofbiz\.base\.start\.Start.*/) {
> exec { commandLine 'kill', '-9',
> line.tokenize().first() }
> }
> }
> }
> }
> }
>
> While it might be considered a bug at first hand, I personnally think
> this failure is more a symptom of a desperate endeavour which is to
> guess how the system of a user is managing its processes.  As a
> consequence I will suggest to simply remove this task to not make false
> promises to users and let them manage the processes on their system by
> themselves. :-)
>
> What do people think?
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>


Re: [OPTIONS] Java 11 and Java JDK origin

2019-02-28 Thread 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
>


Re: Pending works from Christian Carlow

2019-02-19 Thread Taher Alkhateeb
I think it's not a big deal just a side comment. We have too many JIRAs and
we really could benefit from cleaning them up. Perhaps after you close them
all you can just mention those tickets here as a reference for the future.

On Tue, Feb 19, 2019, 8:41 PM Jacques Le Roux  I agree about the value of these Jiras.
>
> What do you mean/think-about exactly by
>
> <>
>
> ?
>
> Is Michael's answer sufficient? You can indeed search for Christian's
> closed Jira with patches.
>
> Jacques
>
> Le 19/02/2019 à 16:20, Taher Alkhateeb a écrit :
> > +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
> >>
>


Welcome to Mathieu Lirzin as new committer!

2019-02-19 Thread 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


Re: Pending works from Christian Carlow

2019-02-19 Thread 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
>


Re: Enabling HTTP/2 in the embedded Tomcat connectors

2019-02-19 Thread Taher Alkhateeb
clean and simple implementation, +1

on a side note, I wonder if we need to set any of the http2 attributes
listed in [1] or whether the defaults are okay.

[1] https://tomcat.apache.org/tomcat-8.5-doc/config/http2.html

On Mon, Feb 18, 2019 at 5:58 PM Jacques Le Roux
 wrote:
>
> Hi Jacopo,
>
> Sounds good to me, we can always easily revert in case of unexpected issue 
> anyway
>
> Thanks
>
> Jacques
>
> Le 18/02/2019 à 11:43, Jacopo Cappellato a écrit :
> > Hi all,
> >
> > I think it is time to enable the instance of Tomcat that is embedded in
> > OFBiz to communicate using the HTTP/2 protocol, when the client supports it.
> > For your review, before I commit, I am pasting here the patch that will
> > enable it (it is quite simple) .
> > In it I have enabled HTTP/2 by default, by setting upgradeProtocol=true, in
> > the http and https connectors (but they will continue to support also
> > HTTP/1.1); if the new property "upgradeProtocol", that I have introduced
> > for this specific purpose, is not set (as it would be the case in custom
> > configuration files) then the new protocol will not be enabled. Does the
> > approach look good to you?
> >
> > Thanks,
> >
> > Jacopo
> >
> > PS: you can test it, for example, using curl:
> >
> > curl -vso /dev/null --http2 http://localhost:8080
> >
> >
> > Index: framework/catalina/ofbiz-component.xml
> > ===
> > --- framework/catalina/ofbiz-component.xml (revision 1853787)
> > +++ framework/catalina/ofbiz-component.xml (working copy)
> > @@ -99,6 +99,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -128,6 +129,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -183,6 +185,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -194,6 +197,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > Index:
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > ===
> > ---
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > (revision
> > 1853787)
> > +++
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > (working
> > copy)
> > @@ -63,6 +63,7 @@
> >   import org.apache.catalina.util.ServerInfo;
> >   import org.apache.catalina.valves.AccessLogValve;
> >   import org.apache.catalina.webresources.StandardRoot;
> > +import org.apache.coyote.http2.Http2Protocol;
> >   import org.apache.ofbiz.base.component.ComponentConfig;
> >   import org.apache.ofbiz.base.concurrent.ExecutionPool;
> >   import org.apache.ofbiz.base.container.Container;
> > @@ -417,9 +418,12 @@
> >   private Connector prepareConnector(Property connectorProp) {
> >   Connector connector = new
> > Connector(ContainerConfig.getPropertyValue(connectorProp, "protocol",
> > "HTTP/1.1"));
> >   connector.setPort(ContainerConfig.getPropertyValue(connectorProp,
> > "port", 0) + Start.getInstance().getConfig().portOffset);
> > -
> > +if ("true".equals(ContainerConfig.getPropertyValue(connectorProp,
> > "upgradeProtocol", "false"))) {
> > +connector.addUpgradeProtocol(new Http2Protocol());
> > +Debug.logInfo("Tomcat " + connector + ": enabled HTTP/2",
> > module);
> > +}
> >   connectorProp.properties.values().stream()
> > -.filter(prop -> !"protocol".equals(prop.name) &&
> > !"port".equals(prop.name))
> > +.filter(prop -> !"protocol".equals(prop.name) &&
> > !"upgradeProtocol".equals(prop.name) && !"port".equals(prop.name))
> >   .forEach(prop -> {
> >   if (IntrospectionUtils.setProperty(connector, prop.name,
> > prop.value)) {
> >   if (prop.name.indexOf("Pass") != -1) {
> >


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

2019-02-13 Thread Taher Alkhateeb
I think it would be great to upgrade to JDK 11 on openjdk and get this
issue over with. For those who want to switch to oracle JDK, they can
easily do so, but we should perhaps stabilize on openjdk by default
and get the build system and documentation pointing to openjdk as a
long term solution to this problem.

On Wed, Feb 13, 2019 at 2:39 PM Michael Brohl  wrote:
>
> 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.
> >>

Re: JobManager/JobPoller issues

2019-02-03 Thread Taher Alkhateeb
Hi Scott,

It seems we have some issues currently with our job scheduler [1]
which seems to be some sort of memory leak. We are also experiencing
some performance issues and other anomalies. It seems like a good time
to perhaps revisit the whole thing.

Are you suggesting to replace LinkedBlockingQueue with
PriorityBlockingQueue? If so I think it might actually be a better
option. I think being unbounded _might_ actually resolve some of the
pain points we're facing. I didn't get why it's not a drop-in
replacement though. It matches the signature of the call in the
executor service unless i'm missing something somewhere?

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

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


Re: Writing a Simple-service for simple-methods

2019-01-26 Thread Taher Alkhateeb
Hi Rahul,

Generally it is recommend to avoid simple services as they are deprecated
and being phased out. You might want to use Java, groovy or entity-auto
services instead.

On Sat, Jan 26, 2019, 10:49 AM Rahul Utkoor
 Hello,
> I just started working on ofbiz. As a part of my work I was supposed to
> write a service for "*create customer*" functionality in Party application.
> I wonder why there are no services written for some of the simple-method
> events.
> And also why there is no java service written for "*create customer*" while
> there is java service for "*create Person*"?
> And what are the complexities involved in defining a service for "*create
> customer*" simple-method?
> Please help me by pointing in the right direction.
> --
>
> *Thanks & Regards,*
> *Rahul.*
>


Re: git commit workflow for ofbiz

2019-01-25 Thread Taher Alkhateeb
+1

On Fri, Jan 25, 2019, 1:29 PM Deepak Dixit  Looks good Michael.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl 
> wrote:
>
> > 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 <
> michael.br...@ecomify.de>
> > > 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 

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

2019-01-21 Thread 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/
> >
> >
> >
> >
>


Re: git commit workflow for ofbiz

2019-01-16 Thread Taher Alkhateeb
Hi Jacques, I know you are a GUI fan, and for that I recommend this
tool https://git-cola.github.io

Make sure to install all requirements for a full enjoyable experience
including viewing the history visually and whatnot

On Wed, Jan 16, 2019 at 12:56 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> We have some tasks to do (like revert and merge scripts) but I see no 
> problems with that.
>
> Apart that I have to think a bit more about the workflow (I guess Taher's 
> proposition should be fine)
>
> I must though say that you will certainly see a slow-down on my side. I'm 
> used to a bunch of svn tools I use and will have to find similar for Git. I
> already use TortoiseGit for 5 years so it should not be a big deal...
>
> Jacques
>
> Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
> > +1 for using Git.
> > Personally, my experience is also very good with Git.
> >
> >
> > - Best Regards,
> > Swapnil M Mane
> >
> > On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin 
> > wrote:
> >
> >> On 12/01/2019 20:56, Taher Alkhateeb wrote:
> >>> It's awesome to revive this discussion Michael. +1 of course.
> >>>
> >>> We need to think practically of our workflows though and whether we
> >>> want a linear vs non-linear history model. I prefer the latter to
> >>> allow proper decentralized workflows but it's up to everyone here to
> >>> decide. I think the overall process is described thoroughly and we can
> >>> adhere to it for the most part.
> >> We can easily switch from svn to git without change own commit process
> >> on first time by patch application.
> >>
> >> If a commiter want use merge feature, the squash function simulate the
> >> application patch.
> >>
> >> So no opposite to move with this few remark
> >>
> >> Nicolas
> >>
> >>


Re: OFBiz shell

2019-01-14 Thread Taher Alkhateeb
So I believe Groovysh is taking the classloader as an argument to bind
within the context of OFBiz hence using the current thread (OFBiz)
class loader to inject itself.

Now if you are going to eventually shutdown OFBiz, no problem, the
shutdown hook will kick in and kill anything running in memory in a
clean way including Groovysh because it's registered on the
classloader. However, if you crash, or disconnect from the server for
example, what happens to that session? Does it terminate? Does it
linger in memory? If so, you need to create a hook (maybe a timeout
hook) to ensure termination. I find this feature nice, So I might use
it often and if I do, I might have ghost sessions that pile up over
time (Assuming I'm not missing anything and my understanding of how
the shell works is correct).

If we can ensure that we won't likely have ghost sessions for whatever
reason, then we ensure memory safety and no leaks happening (unless
maybe someone writes an infinite loop or something).

On Sun, Jan 13, 2019 at 12:33 AM Mathieu Lirzin
 wrote:
>
> Hello Taher,
>
> Taher Alkhateeb  writes:
>
> > On a quick review of the code, and given that we're populating the
> > class loader of current thread, can we ensure clean termination of
> > shells?
>
> This work is experimental, so be prepared to ruff edges. :-)
>
> I didn't thought about the implications of using the current thread
> class loader.  What kind of scenario of non-clean termination of shells
> have you in mind?
>
> Thanks for your comment.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: Getting rid of the Script helper abstractions

2019-01-14 Thread Taher Alkhateeb
Design patterns gone awry :) Anyway, I don't see the need to delete
the interface, just instantiate it without a factory.

On Sun, Jan 13, 2019 at 11:20 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> While trying to understand the Groovy engine implemenation details, I
> discovered the mechanism used to add some bindings to scripts. Those
> bindings are meant to make it convenient for programmers to write those
> scripts in the context of OFBiz by letting them invoke a service and
> query the database easily.
>
> This feature has been introduced in 2012 by Adrian Crum while he was
> working on the Script Engine which allows OFBiz to interact generically
> with scripting languages implementing the JSR-223 specification. [1]
>
> Adrian chose to use the Abstract Factory pattern combined with the
> service loader [2] for an obscure reason since there is only one
> implementation of the ‘ScriptHelperFactory’ and only one implementation
> of the ‘ScriptHelper’ interface.  This give me the feeling that this set
> of abstraction is unnecessary and only make things harder to reason
> about.
>
> As a consequence I propose to simplify the implementation by removing
> the abstract factory pattern and merging the ‘ScriptHelper’ interface
> with its sole implementation.
>
> What do people think?
>
> [1] 
> https://github.com/apache/ofbiz/commit/39eaa0b48d836b143a2c03f44654cd1cab7f031f
> [2] https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: OFBiz shell

2019-01-12 Thread Taher Alkhateeb
+1, very cool idea. A proper review of the code might be in order.

On a quick review of the code, and given that we're populating the
class loader of current thread, can we ensure clean termination of
shells?

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


Re: git commit workflow for ofbiz

2019-01-12 Thread Taher Alkhateeb
It's awesome to revive this discussion Michael. +1 of course.

We need to think practically of our workflows though and whether we
want a linear vs non-linear history model. I prefer the latter to
allow proper decentralized workflows but it's up to everyone here to
decide. I think the overall process is described thoroughly and we can
adhere to it for the most part.

On Sat, Jan 12, 2019 at 9:35 PM Deepak Dixit  wrote:
>
> We are using git since long and it's a great tool for collaboration.
> It has distributed version control system so you don't need an internet
> connection to view history and branch switching.
>
> Thanks Taher for nicly describing it.
>
> +1 for Git.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma <
> aditya.sha...@hotwaxsystems.com> wrote:
>
> > +1 for Git
> >
> > Thanks and Regards,
> > Aditya Sharma
> >
> > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana  > wrote:
> >
> > > +1 to move from SVN to Git.
> > >
> > > --
> > > Best Regards,
> > > Suraj Khurana
> > > Technical Consultant
> > >
> > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <
> > mathieu.lir...@nereide.fr>
> > > wrote:
> > >
> > > > Hello Michael,
> > > >
> > > > Michael Brohl  writes:
> > > >
> > > > > I'd like to revive this discussion again.
> > > >
> > > > Do we still need to discuss it?  If the response is not obviously “yes
> > > > we should move to Git” now that Git has become ubiquitous and that SVN
> > > > is a moribund tool, then this community has a serious problem.  :-)
> > > >
> > > > Joke aside I think the question should rather be:
> > > >
> > > >Is there anyone here opposing to the move from SVN to Git?
> > > >
> > > > Thanks for reviving this topic!
> > > >
> > > > --
> > > > Mathieu Lirzin
> > > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> > > >
> > >
> >


Re: [Discussion] Upgrading OFBiz to work with Java 11

2018-12-31 Thread Taher Alkhateeb
Created JIRA [1] to start working on this.

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

On Thu, Dec 27, 2018 at 4:08 PM Deepak Dixit  wrote:
>
> I tried to run ofbiz with JDK 11, with following entry in build.gradle I am
> able to build and run ofbiz.
>
>
> runtime 'javax.xml.soap:javax.xml.soap-api:1.4.0'
>
>
>
> There are around 75 warnings (framework + plugins)
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Wed, Dec 26, 2018 at 10:48 AM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
> > Hi Taher
> >
> > I haven't tried upgrading myself but I'm in for this effort. I think it
> > only makes sense to do the upgrade. I'll also try Java 11 and see how it
> > goes.
> >
> > Best,
> > Girish
> >
> > On Wed, Dec 26, 2018 at 1:25 AM Taher Alkhateeb <
> > slidingfilame...@gmail.com>
> > wrote:
> >
> > > Hi Folks,
> > >
> > > Now that we upgraded Gradle, I think we should consider moving to the
> > > new LTS (JDK 11)? I tried to upgrade to java 11 and got lots of
> > > issues. Some deprecated packages are removed and others changed
> > > signature. I got 2 errors and about 53 warnings for things that should
> > > be fixed.
> > >
> > > Should we go ahead and attempt the upgrade? Anyone already went
> > > through the effort and can help out?
> > >
> > > Taher Alkhateeb
> > >
> >


Re: Planning for the creation of new 18.12 branches

2018-12-27 Thread 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
> > > >>
> > > >>
> >


Re: Planning for the creation of new 18.12 branches

2018-12-27 Thread Taher Alkhateeb
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
> >>
> >>


[Discussion] Upgrading OFBiz to work with Java 11

2018-12-25 Thread Taher Alkhateeb
Hi Folks,

Now that we upgraded Gradle, I think we should consider moving to the
new LTS (JDK 11)? I tried to upgrade to java 11 and got lots of
issues. Some deprecated packages are removed and others changed
signature. I got 2 errors and about 53 warnings for things that should
be fixed.

Should we go ahead and attempt the upgrade? Anyone already went
through the effort and can help out?

Taher Alkhateeb


Re: Gradle daemons in demos and Buildbot builds?

2018-12-25 Thread Taher Alkhateeb
I recommend not to run the daemon in CI. It's not worth the
instability to gain a few seconds on each run.

On Mon, Dec 24, 2018 at 7:45 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> So far, from Gradle team recommendation, we were not using Gradle daemons in 
> demos and Buildbot builds.
>
> In both, I recently noticed warnings like
>
> To honour the JVM settings for this build a new JVM will be forked. 
> Please consider using the daemon:
> https://docs.gradle.org/5.0/userguide/gradle_daemon.html. Daemon will be 
> stopped at the end of the build stopping after processing
>
> There I can read:
>
> /Continuous integration//
> //Since Gradle 3.0, we enable Daemon by default and recommend using it 
> for both developers' machines and Continuous Integration servers. However,
> if you suspect that Daemon makes your CI builds unstable, you can disable 
> it to use a fresh runtime for each build since the runtime is
> //completely//isolated from any previous builds./
>
> I think we can try it, what do you think?
>
> Also, I'm using --/parallel /for quite a moment now. Since we switched to 
> Gradle 5 I no longer see warnings about that. Should we not use it in demos
> and Buildbot builds and maybe enforce it generally?
>
> Thank you for your opinions.
> //
>
> Jacques
>


Re: [Discussion] Browser Unresponsive when Loading Entity with Large Results

2018-12-16 Thread Taher Alkhateeb
Ahh, so you want an auto complete text box that fetches from server on
the fly using jQuery right? If so, sure +1

On Sun, Dec 16, 2018 at 11:41 AM Deepak Dixit  wrote:
>
> Pagination widget tries to generate select with a huge number of options so
> browser takes too much time to prepare dom and causing unresponsiveness.
>
> So we can say that the root cause is in the pagination widget that
> prepares select option. We need a different pattern rather than select
> element for rendering the page (VIEW_INDEX)
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb 
> wrote:
>
> > Yeah so what you are describing is a pagination issue right? The root
> > cause is pagination, not type of widget being used? I'm a little
> > confused by the proposal?
> >
> > On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas 
> > wrote:
> > >
> > > Hello Taher,
> > >
> > > The browser becomes unresponsive to a user in this case, as the browser
> > is
> > > busy in preparing the large '*select*' DOM element(a drop-down with
> > around
> > > 250,000 options).
> > > I found some points related to our discussion here
> > > <https://developers.google.com/web/tools/lighthouse/audits/dom-size>.
> > >
> > >
> > > Thanks & Regards,
> > > Devanshu Vyas.
> > >
> > >
> > > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas  > >
> > > wrote:
> > >
> > > > Hello Taher,
> > > >
> > > > The FTL is trying to render a list(select box) with a large number of
> > > > options(around 250,000 in my case) which takes a lot of time and the
> > > > browser usually asks to either kill the page or wait for it to load
> > > > completely.
> > > >
> > > > Thanks & Regards,
> > > > Devanshu Vyas.
> > > >
> > > >
> > > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > > > slidingfilame...@gmail.com> wrote:
> > > >
> > > >> before proposing the solution we need a diagnosis. What is the strain
> > > >> happening on the browser?
> > > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <
> > vyas.devansh...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > Hello Guys,
> > > >> >
> > > >> > Recently, I came across a situation where an entity was taking too
> > much
> > > >> of
> > > >> > a time(browser asked me to either wait or kill) while
> > loading/searching
> > > >> > results in the Webtools application. The entity had close to 5M
> > records,
> > > >> > and I checked the server responded timely but the rendering of the
> > > >> screen
> > > >> > was taking time.
> > > >> > When I explored the issue I came across a macro which renders the
> > > >> > pagination on the screen, and it had a code block which was causing
> > the
> > > >> > screen rendering delay.
> > > >> > {code}
> > > >> >
> > > >> > <#assign x=(listSize/viewSize)?ceiling>
> > > >> >   <#list 1..x as i>
> > > >> > <#if i == (viewIndex+1)> > > >> > value="<#else>${i}
> > > >> >   
> > > >> >
> > > >> > {code}
> > > >> > This code seems logical enough to me, and what I gather from this is
> > > >> that
> > > >> > the list will render a select box with 250,000 options.
> > > >> >
> > > >> > I would like to propose a change in this UI/UX from select box to an
> > > >> input
> > > >> > text box so a user can navigate to any page, similar to a navigation
> > > >> input
> > > >> > box in a PDF document reader application.
> > > >> >
> > > >> > Please let me know your thoughts on this and share some more ideas
> > to
> > > >> how
> > > >> > we can improve/resolve this issue. Looking forward to your replies!
> > > >> >
> > > >> >
> > > >> >
> > > >> > Thanks & Regards,
> > > >> > Devanshu Vyas.
> > > >>
> > > >
> >


Re: [Discussion] Browser Unresponsive when Loading Entity with Large Results

2018-12-15 Thread Taher Alkhateeb
Yeah so what you are describing is a pagination issue right? The root
cause is pagination, not type of widget being used? I'm a little
confused by the proposal?

On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas  wrote:
>
> Hello Taher,
>
> The browser becomes unresponsive to a user in this case, as the browser is
> busy in preparing the large '*select*' DOM element(a drop-down with around
> 250,000 options).
> I found some points related to our discussion here
> <https://developers.google.com/web/tools/lighthouse/audits/dom-size>.
>
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas 
> wrote:
>
> > Hello Taher,
> >
> > The FTL is trying to render a list(select box) with a large number of
> > options(around 250,000 in my case) which takes a lot of time and the
> > browser usually asks to either kill the page or wait for it to load
> > completely.
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > slidingfilame...@gmail.com> wrote:
> >
> >> before proposing the solution we need a diagnosis. What is the strain
> >> happening on the browser?
> >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas 
> >> wrote:
> >> >
> >> > Hello Guys,
> >> >
> >> > Recently, I came across a situation where an entity was taking too much
> >> of
> >> > a time(browser asked me to either wait or kill) while loading/searching
> >> > results in the Webtools application. The entity had close to 5M records,
> >> > and I checked the server responded timely but the rendering of the
> >> screen
> >> > was taking time.
> >> > When I explored the issue I came across a macro which renders the
> >> > pagination on the screen, and it had a code block which was causing the
> >> > screen rendering delay.
> >> > {code}
> >> >
> >> > <#assign x=(listSize/viewSize)?ceiling>
> >> >   <#list 1..x as i>
> >> > <#if i == (viewIndex+1)> >> > value="<#else>${i}
> >> >   
> >> >
> >> > {code}
> >> > This code seems logical enough to me, and what I gather from this is
> >> that
> >> > the list will render a select box with 250,000 options.
> >> >
> >> > I would like to propose a change in this UI/UX from select box to an
> >> input
> >> > text box so a user can navigate to any page, similar to a navigation
> >> input
> >> > box in a PDF document reader application.
> >> >
> >> > Please let me know your thoughts on this and share some more ideas to
> >> how
> >> > we can improve/resolve this issue. Looking forward to your replies!
> >> >
> >> >
> >> >
> >> > Thanks & Regards,
> >> > Devanshu Vyas.
> >>
> >


Re: [DISCUSSION] Remove mask feature for date-time fields

2018-12-15 Thread Taher Alkhateeb
why not resolve conflicts?

On Sat, Dec 15, 2018 at 3:48 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> I was looking at https://issues.apache.org/jira/browse/OFBIZ-6734 and 
> specifically the comment I made there about mask feature for date-time fields.
> The masked input for date-time fields does not work as it should (compare 
> behaviour of the 1st field of
> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples and 
> https://igorescobar.github.io/jQuery-Mask-Plugin/)
> I think there is a conflict between the calendar which is used by default 
> with date-time fields and the masked input feature. So masked input feature
> is ignored and adds nothing to date-time fields which is confusing.
>
> I propose to remove this feature, what do you think?
>
> Also the // is demonstrated there, and only used 
> there, but does nothing.
> As it ever working or is / replacement/?
> /Should we not clear that also (ie remove this demonstrating field and the 
> feature at large)?
> //
>
> Thanks
>
> Jacques
>


Re: Successor for elRTE

2018-12-15 Thread Taher Alkhateeb
those things are hard to google for. Looking forward for your research outcome.

On Fri, Dec 14, 2018 at 12:42 PM Benjamin Jugl  wrote:
>
> Hello all!
>
> The visual editor for Textareas that is used by Ofbiz is elRTE. This
> editor has been abandoned for quite some time, as you can see in
> OFBIZ-10093 . Since
> it is a factor in some security issues as well, I would really like to
> replace it with an up-to-date alternative.
>
> For this, I created a new Decision
> 
> page in Confluence. First goal of this is to throw in all the demands
> that have to be met by an alternative and rate them, so we have a basis
> for evaluation.
>
> Best wishes, Benjamin
>
>


Re: [Discussion] Browser Unresponsive when Loading Entity with Large Results

2018-12-14 Thread Taher Alkhateeb
before proposing the solution we need a diagnosis. What is the strain
happening on the browser?
On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas  wrote:
>
> Hello Guys,
>
> Recently, I came across a situation where an entity was taking too much of
> a time(browser asked me to either wait or kill) while loading/searching
> results in the Webtools application. The entity had close to 5M records,
> and I checked the server responded timely but the rendering of the screen
> was taking time.
> When I explored the issue I came across a macro which renders the
> pagination on the screen, and it had a code block which was causing the
> screen rendering delay.
> {code}
>
> <#assign x=(listSize/viewSize)?ceiling>
>   <#list 1..x as i>
> <#if i == (viewIndex+1)> value="<#else>${i}
>   
>
> {code}
> This code seems logical enough to me, and what I gather from this is that
> the list will render a select box with 250,000 options.
>
> I would like to propose a change in this UI/UX from select box to an input
> text box so a user can navigate to any page, similar to a navigation input
> box in a PDF document reader application.
>
> Please let me know your thoughts on this and share some more ideas to how
> we can improve/resolve this issue. Looking forward to your replies!
>
>
>
> Thanks & Regards,
> Devanshu Vyas.


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

2018-12-11 Thread Taher Alkhateeb
The official documentation mentions that performance is hit [1] with metrics.

[1] https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams
On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin
 wrote:
>
> Hello Michael,
>
> Michael Brohl  writes:
>
> > 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.
>
> According to Rémi Forax's numbers this assumption is *not* verified! [1]
>
> He gets exactly the same performance results (1.08× ns/op) with either
> of the following options:
>
>1) Debug.log("...")
>2) if (Debug.isEnabled()) { Debug.log("...") }
>3) Debug.log(() -> "...")
>
> > 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...
>
> I think that any claim of performance gain/loss must be backed by an
> actual measurement, and this has not been the case in this discussion.
>
> Personnally I care about the readability of the code and choosing the
> option 2 is not helping in that regard.
>
> [1] https://youtu.be/z5UkoLaW6ME?t=213
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


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 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:
>
> Author: jleroux
> Date: Tue Dec 11 13:33:49 2018
> New Revision: 1848673
>
> URL: http://svn.apache.org/viewvc?rev=1848673=rev
> Log:
> Improved: Fix or Silence various warnings
> (OFBIZ-10701)
>
> In order to detect potential issues early, the linting compiler option should 
> be
> used by default and disabled with {{./gradlew -PXlint:none build}}.
>
> Additionally it is important to reduce the number of warnings otherwise new
> warnings will remain unnoticed.
>
> The warning related to the com.googlecode.concurrentlinkedhashmap dependency
> should resolves itself once we handle upgrade to Caffeine like proposed in
> OFBIZ-6747.
>
> Thanks: Mathieu Lirzin
>
> Removed:
> 
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/portal/PortalPageWorkerInterface.java
> 
> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/org/apache/ofbiz/widget/portal/WidgetPortalPageWorker.java
> Modified:
> ofbiz/ofbiz-framework/trunk/README.adoc
> 
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/InvoiceWorker.java
> 
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/ContentManagementServices.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/cms/ContentJsonEvents.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/content/ContentServices.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/content/PermissionRecorder.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/content/UploadContentAndImage.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/data/DataResourceWorker.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/data/DataServices.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/layout/LayoutEvents.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/survey/PdfSurveyServices.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/CheckPermissionTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/EditRenderSubContentCacheTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/EditRenderSubContentTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/InjectNodeTrailCsvTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/LimitedSubContentCacheTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/LoopSubContentTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/OfbizContentAltUrlTransforms.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderContentAndSubContent.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderContentAsText.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderContentTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderSubContentAsText.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderSubContentCacheTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/RenderSubContentTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/TraverseSubContentCacheTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/TraverseSubContentTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/content/src/main/java/org/apache/ofbiz/content/webapp/ftl/WrapSubContentCacheTransform.java
> 
> ofbiz/ofbiz-framework/trunk/applications/manufacturing/src/main/java/org/apache/ofbiz/manufacturing/bom/BOMNode.java
> 
> 

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

2018-12-11 Thread Taher Alkhateeb
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 
> >> <https://issues.apache.org/jira/browse/OFBIZ-10448>:
> >>
> >>  I'd be all for removing the 312 useless cases but not the "if 
> >> (Debug.verboseOn())">>
> >>
> >> To what Michael answered
> >>
> >>  < >> run them on debug level info, verbose or debug.
> >>  In my view, at least these 3 debug levels should be checked. At 
> >> least, existing checks should not be removed.>>
> >>
> >> I think Michael's point is perfectly valid. So I answered:
> >>
> >>  < >> in production needing an info or debug level.
> >>  OK then we need to see things otherwise and rather enforce the checks 
> >> to these 2 levels at least in all the source (Java and Groovy). That's what
> >>  I'll ask in the convo to come in dev ML.>>
> >>
> >> 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:
> >>
> >>  < >> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mbrohl>,
> >>
> >>  If you care about the impact of loggers on performance you should 
> >> take a look at the Beautiful Logger 
> >> <https://github.com/forax/beautiful_logger>
> >>  library by Remi Forax which implements a truly transparent logger. In 
> >> a recent Devoxx talk <https://www.youtube.com/watch?v=z5UkoLaW6ME> (in
> >>  french) he showed that even doing if (Debug.logXXX()) has a 3x 
> >> slowdown compared to a no-op.>>
> >>
> >> So maybe we should have a closer look at  Beautiful Logger before taking 
> >> any decision? Note that it uses JitPack, hence seems to need "Java 11 to 
> >> build".
> >>
> >> Thanks
> >>
> >> Jacques
> >>


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

2018-12-10 Thread Taher Alkhateeb
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
>
> < them on debug level info, verbose or debug.
> In my view, at least these 3 debug levels should be checked. At least, 
> existing checks should not be removed.>>
>
> I think Michael's point is perfectly valid. So I answered:
>
> < production needing an info or debug level.
> OK then we need to see things otherwise and rather enforce the checks to 
> these 2 levels at least in all the source (Java and Groovy). That's what
> I'll ask in the convo to come in dev ML.>>
>
> 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 
> library by Remi Forax which implements a truly transparent logger. In a 
> recent Devoxx talk  (in
> french) he showed that even doing if (Debug.logXXX()) has a 3x slowdown 
> compared to a no-op.>>
>
> So maybe we should have a closer look at  Beautiful Logger before taking any 
> decision? Note that it uses JitPack, hence seems to need "Java 11 to build".
>
> Thanks
>
> Jacques
>


Re: [QUESTION] What about TypeScript?

2018-12-10 Thread Taher Alkhateeb
Try it where? How?
On Mon, Dec 10, 2018 at 7:41 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> I was reading https://www.thoughtworks.com/radar/languages-and-frameworks, 
> for a long time I'm interested by TypeScript. This is what they say:
>
> ** is a carefully 
> considered language and its consistently improving tools and IDE support 
> continues
> to impress us. With a good repository  of 
> TypeScript-type definitions, we benefit from all the rich JavaScript
> libraries while gaining type safety. This is particularly important as 
> our browser-based code base continues to grow. The type safety in
> TypeScript lets you use IDEs and other tools to provide deeper context 
> into your code and make changes and refactor code with safety. TypeScript,
> being a superset of JavaScript, and documentation and the community has 
> helped ease the learning curve.>>
>
> Has anybody considered using it? Should we not try it?
>
> Thanks
>
> Jacques
>


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

2018-12-08 Thread Taher Alkhateeb
My recommendation is to remove the functionality. It seems immature
and incomplete, and hence probably not used.
On Sat, Dec 8, 2018 at 2:45 PM Michael Brohl  wrote:
>
> 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
>
>
>


Re: [DOCUMENTATION] TOCs level and numbers

2018-12-06 Thread Taher Alkhateeb
Section numbers are nice and we use them in all our documents. They help
you keep track of where you are and in large documents this becomes very
helpful.

So I would prefer keeping them.

On Fri, Dec 7, 2018, 12:09 AM 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 <
> jacques.le.r...@les7arts.com>:
> >
> >> 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: Upgrading gradle to version 5.0

2018-12-03 Thread Taher Alkhateeb
upgraded in r1848062 and referenced in OFBIZ-9972. Thank you all folks
On Thu, Nov 29, 2018 at 11:52 AM Deepak Dixit  wrote:
>
> +1,
> After applying patch its working fine.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Thu, Nov 29, 2018 at 1:53 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Thanks for the tip Girish!
> >
> > Jacques
> >
> >
> > Le 29/11/2018 à 07:34, Girish Vasmatkar a écrit :
> > > Hi Taher
> > >
> > > I'm all for it. I have also updated the version and it seems to be
> > working
> > > just fine in my workspace.
> > >
> > > Just a very minor caveat I noticed with the upgrade is that you don't see
> > > what all tasks gradle executed, while the earlier versions showed the
> > > executed tasks and their corresponding output.
> > >
> > > With the newer version you see -  Build Successful on the terminal. More
> > > often than not we are not going to be bothered by this, but having it
> > > display the executed tasks helps debugging, I feel.
> > >
> > > Here's
> > > <
> > https://stackoverflow.com/questions/45883963/gradle-4-0-does-not-display-executed-tasks-in-command-line
> > >
> > > the
> > > solution that worked for me.
> > >
> > > Best,
> > > Girish
> > >
> > > On Wed, Nov 28, 2018 at 11:26 PM Taher Alkhateeb <
> > slidingfilame...@gmail.com>
> > > wrote:
> > >
> > >> Hello Everyone,
> > >>
> > >> I just received some good news from Mathieu Lirzin (Thank you Mathieu)
> > >> on the state of Gradle. Essentially, we were worried about gradle
> > >> deprecating spaces used in task names which led to problems in issuing
> > >> our standard server commands [1]. Thankfully, it seems this issue is
> > >> resolved, the gradle folks seem to have changed their minds and we can
> > >> continue as usual.
> > >>
> > >> Therefore, I recommend we upgrade gradle to version 5. It is a lot
> > >> faster for loading (it runs parallel processes for downloading
> > >> dependencies) and it is also more compatible with newer versions of
> > >> Java.
> > >>
> > >> https://issues.apache.org/jira/browse/OFBIZ-9972
> > >>
> >
> >


Upgrading gradle to version 5.0

2018-11-28 Thread Taher Alkhateeb
Hello Everyone,

I just received some good news from Mathieu Lirzin (Thank you Mathieu)
on the state of Gradle. Essentially, we were worried about gradle
deprecating spaces used in task names which led to problems in issuing
our standard server commands [1]. Thankfully, it seems this issue is
resolved, the gradle folks seem to have changed their minds and we can
continue as usual.

Therefore, I recommend we upgrade gradle to version 5. It is a lot
faster for loading (it runs parallel processes for downloading
dependencies) and it is also more compatible with newer versions of
Java.

https://issues.apache.org/jira/browse/OFBIZ-9972


Re: OFBiz as Marketplace

2018-11-21 Thread Taher Alkhateeb
Oh, I guess I am probably completely mistaken if what you explained is
correct. My bad :)
On Wed, Nov 21, 2018 at 1:03 AM Michael Brohl  wrote:
>
> 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 

Re: OFBiz as Marketplace

2018-11-20 Thread 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 applicati

Re: Using plain Groovy classes for services.

2018-11-17 Thread Taher Alkhateeb
So I think we cannot look at things purely from a theoretical point of
view. There has to be a balance between clean code and continued
usability.

Pros of your approach:
- cleaner semantics
- less pollution of the global namespace
- the other benefits you mentioned

Cons of your approach:
- less orientation towards business focused individuals
- more work on part of the developer. The DSL was always historically
a comfort point for OFBiz not just the groovy DSL but XML and
everything else.
- Major amount of work to refactor all the services.

I'm also not sure the problems you're facing are really that critical.
For example, you mentioned a con in unit-testing support functions?
Really? It's a support function for a service, you _must_ have an
integration test for that thing anyway. You cannot apply TDD on
services, the nature of it is just not workable. And If you add unit
tests your support functions you have now mixed production with test
code without an obvious advantage (TDD is about millisecond tests).

So weighing the pros and cons, and listening also to Jacopo's
feedback, I'm not sure this would be a highly valuable move.
On Wed, Nov 14, 2018 at 7:35 PM Mathieu Lirzin
 wrote:
>
> Hello Jacopo,
>
> Jacopo Cappellato  writes:
>
> > thank you for starting this interesting conversation.
> > I think it is fine to implement services in plain Java or in plain Groovy
> > methods and you have highlighted some of the advantages over their
> > implementation using the Groovy DSL.
> > However in my opinion the Groovy DSL (even in its current "basic" version,
> > implemented thru a few lines of code, that could be enhanced and extended)
> > has some advantages too and may be preferred by a different audience of
> > "users" that are more focused on business rules than on programming; data
> > preparation scripts are also a good fit for the DSL.
>
> Sure, allowing “business oriented” people to adapt OFBiz to their needs
> by letting them to automate a process in terms of business rules is
> *very* valuable.
>
> I never had the chance to exchange with people focused on business rules
> working with OFBiz which are able to write services/ECA/handlers.
> However I am rather skeptic regarding your claim that the Groovy service
> DSL allows a wider audience to adapt/compose OFBiz services to their
> needs.  I guess it serves more as a “fun” thing for programmers to play
> with, than something with an effective business value.
>
> In my opinion improving simplicity (locality, uniformity, value
> orientation, ...)  would be far more effective at empowering both
> business and code oriented programmers. [1]
>
> Thanks for sharing your view.
>
> [1] https://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: OFBiz as Marketplace

2018-11-17 Thread Taher Alkhateeb
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 my experience I see marketplace
> > optionally owns the shipment from sellers to customers using third party
> > support.
> >
> > On the whole I would like to propose separate plugin and once we are okay
> > with separate plugin or inject features in existing ordermgr, partymgr and
> > ecommerce application then we can start writing user stories to take
> > community feedback. I completely agree on the fact we have gaps but we have
> > most building blocks in place to achieve this.
> >
> > Please let me know your opinion on having separate plugin. Also looking
> > forward to see opinion from community, so that we can move with better plan
> > to execute.
> >
> > Best Regards,
> > --
> > Rishi Solanki
> > Sr Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: +91-9893287847
> > http://www.hotwaxsystems.com
> > www.hotwax.co
> >
> >
> > On Thu, Nov 15, 2018 at 5:52 PM Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > Hi Rishi,
> > >
> > > this is an interesting initiative, thank you.
> > > There are various types of online marketplaces, each with unique and
> > > significant requirements, but if we focus on the ones like Amazon (since
> > > you have mentioned it) then we the following notes may apply pretty well.
> > >
> > > Main actors:
> > > * the marketplace operator: it owns the site (e.g. Amazon)
> > > * consumers: browse the content of the site and place (sales) orders to
> > the
> > > marketplace operator
> > > * retailers/wholesalers/sellers: define price (and cost to the
> > marketplace
> > > operator), shipping options and shipping cost
> > >
> > > Main transactions (drop shipment scenario):
> > > 0) seller publishes product price with shipping costs (for the consumer)
> > > and product cost (for the
> > > 1) consumers orders product (from the retailer) to the marketplace
> > operator
> > > 2) marketplace operator orders product to the retailer
> > > 3) retailer fulfills the order (#2) that is shipped to the consumer
> > > 4) marketplace operator invoices the order (#1) to the consumer
> > > 5) consumer pays the invoice (#4)
> > > 6) retailer invoices the order (#2) to the marketplace operator
> > > 7) marketplace operator pays the invoice (#6)
> > >
> > > These online marketplaces often have one global product catalog and
> > global
> > > products, to which the retailers' specific prices and shipping options
> > are
> > > attached.
> > >
> > > In OFBiz the "drop shipment" workflow is probably the one that most
> > closely
> > > covers the scenario described above.
> > >
> > > As regards the data model:
> > > * Product, ProductContent, ProductCategory etc..: global products and the
> > > global catalog
> > > * ProductPrice, SupplierProduct: the price for the consumer and the cost
> > > for the marketplace operator
> > > * PartyRole: "end user customer" (for the consumer), "supplier" (for the
> > > retailer), "internal organization" (for the marketplace operator)
> > >
> > > There are gaps that needs to be implemented (both in the data model and
> > in
> > > the business logic) and there are many more requirements and nuances to
> > be
> > > discovered but we have most of the building blocks in place.
> > > Some of the outstanding gaps are for example: how to apply the right
> > sales
> > > price when the consumer selects a product from one of its many retailers;
> > > how to specify the retailer in the sales order; how to reserve 

Re: Using plain Groovy classes for services.

2018-11-12 Thread Taher Alkhateeb
Hi Mathieu,

Can you explain hat you want to do exactly? How do these services
access the delegator and whatnot?
On Sun, Nov 11, 2018 at 5:32 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> While I think using Groovy for implementing services is a better choice
> than Java, I am not convinced by the rationale of using Groovy DSL
> features. Here are the various drawbacks I see:
>
>   - The service DSL breaks the function/method local scoping goodness by
> introducing various global variables (parameters, delegator, ...)
>
>   - There is no clear disctinction between services and helper methods
> (private/public)
>
>   - When Unit testing a helper method defined in a DSL script, a
> cumbersome mechanism for accessing the groovy method is required
>
>   - DSL implicit class context abstraction is leaky, for example it is
> hard to understand what is the proper way to define a variable
> outside of a method and how to refer to it from this method.
>
> def foo = "foo"
> def barService() {
> print foo // => ERROR: No such property: foo for class: ...
> }
>
> IMO DSL features introduce accidental complexity with very little
> benefits.  Since plain Groovy classes doesn't suffer from the downsides
> I described above and preserve the Groovy goodness (map literals,
> optional typing, ...), I recommend transitioning from DSL scripts to
> classes.
>
> What do people think?
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: svn commit: r1845418 - in /ofbiz/ofbiz-framework/trunk/framework: base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.ja

2018-11-01 Thread Taher Alkhateeb
it is usually not good practice to add commented-out code to the code
base. I recommend removing it. I also think the comments might benefit
from better formatting and structuring instead of this sporadic "//"
sprinkled all over the place
On Thu, Nov 1, 2018 at 12:36 PM  wrote:
>
> Author: jleroux
> Date: Thu Nov  1 09:36:35 2018
> New Revision: 1845418
>
> URL: http://svn.apache.org/viewvc?rev=1845418=rev
> Log:
> Fixed: Missing Security and Cache Headers in CMS Events
> Fixed:
> (OFBIZ-10597)
>
> While rendering the view through the controller request we set the important
> security headers like x-frame-options, strict-transport-security,
> x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
> response object. (Please see the 'rendervView' method of RequestHandler 
> class.)
>
> In the similar line, we set the cache related headers like Expires,
> Last-Modified, Cache-Control, Pragma.
>
> But these security headers are missing in the pages rendered through CMS.
> (Please visit the CmsEvents class).
>
> These headers are very crucial for the security of the application as they 
> help
> to prevent various security threats like cross-site scripting,
> cross-site request forgery, clickjacking etc.
>
> Thanks: Deepak Nigam for initial patch and review
>
> Modified:
> 
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java
> 
> ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
>
> Modified: 
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java?rev=1845418=1845417=1845418=diff
> ==
> --- 
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java
>  (original)
> +++ 
> ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java
>  Thu Nov  1 09:36:35 2018
> @@ -57,6 +57,7 @@ import org.apache.http.impl.client.Close
>  import org.apache.http.impl.client.HttpClients;
>  import org.apache.http.ssl.SSLContexts;
>  import org.apache.ofbiz.entity.util.EntityUtilProperties;
> +import org.apache.ofbiz.webapp.control.ConfigXMLReader;
>  import org.apache.ofbiz.widget.renderer.VisualTheme;
>  import org.apache.oro.text.regex.MalformedPatternException;
>  import org.apache.oro.text.regex.Pattern;
> @@ -980,6 +981,58 @@ public final class UtilHttp {
>  response.setHeader("Cache-Control", "no-store, no-cache, 
> must-revalidate, private"); // HTTP/1.1
>  response.setHeader("Pragma", "no-cache"); // HTTP/1.0
>  }
> +
> +public static void 
> setResponseBrowserDefaultSecurityHeaders(HttpServletResponse resp, 
> ConfigXMLReader.ViewMap viewMap) {
> +// See 
> https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers 
> for details and how to test
> +String xFrameOption = null;
> +if (viewMap != null) {
> +xFrameOption = viewMap.xFrameOption;
> +}
> +// default to sameorigin
> +if (UtilValidate.isNotEmpty(xFrameOption)) {
> +if(!"none".equals(xFrameOption)) {
> +resp.addHeader("x-frame-options", xFrameOption);
> +}
> +} else {
> +resp.addHeader("x-frame-options", "sameorigin");
> +}
> +
> +String strictTransportSecurity = null;
> +if (viewMap != null) {
> +strictTransportSecurity = viewMap.strictTransportSecurity;
> +}
> +// default to "max-age=31536000; includeSubDomains" 31536000 secs = 
> 1 year
> +if (UtilValidate.isNotEmpty(strictTransportSecurity)) {
> +if (!"none".equals(strictTransportSecurity)) {
> +resp.addHeader("strict-transport-security", 
> strictTransportSecurity);
> +}
> +} else {
> +if (EntityUtilProperties.getPropertyAsBoolean("requestHandler", 
> "strict-transport-security", true)) { // FIXME later pass 
> req.getAttribute("delegator") as last argument
> +resp.addHeader("strict-transport-security", 
> "max-age=31536000; includeSubDomains");
> +}
> +}
> +
> +//The only x-content-type-options defined value, "nosniff", prevents 
> Internet Explorer from MIME-sniffing a response away from the declared 
> content-type.
> +// This also applies to Google Chrome, when downloading extensions.
> +resp.addHeader("x-content-type-options", "nosniff");
> +
> +// This header enables the Cross-site scripting (XSS) filter built 
> into most recent web browsers.
> +// It's usually enabled by default anyway, so the role of this 
> header is to re-enable the filter for this particular website if it was 
> 

Re: Using alternate dispatcher and delegator for integration tests

2018-10-28 Thread Taher Alkhateeb
I keep forgetting this project carries a lot of history with it. Maybe
it's because I'm a relatively new. Thank you for sharing Scott, quite
informative.

If the main advantage is parallelization but that was not really used,
then maybe it's not super necessary. Maybe one way to think about this
is instead of making our tests faster, let's make them lighter. For
example we can switch out from integration tests to unit tests and do
away with the extra layer of resources being consumed.

Anyway, all options on the table, like Scott no firm opinion here.

On Mon, Oct 29, 2018 at 1:16 AM Scott Gray  wrote:
>
> The use of separate individual dispatchers/delegators per test suite was
> introduced at the same time as the delegator rollback/reset code, and was
> intended to allow for test suites to be run (and data to be reset) in
> parallel.
>
> The test framework never sees much love though so that never happened. It's
> difficult to accomplish because many test suites rely on the same
> underlying demo data.
>
> I don't mind either way, just thought the history lesson might be helpful.
>
> https://issues.apache.org/jira/browse/OFBIZ-2259
> https://markmail.org/thread/zjghmk25bllthxme
>
> Regards
> Scott
>
> On Sat, 27 Oct 2018, 22:59 Taher Alkhateeb, 
> wrote:
>
> > Ahh, Now I understand what you mean by looking at your patch. I
> > recommend next time that you copy-paste into the email thread because
> > people who try to access this thread using the ML archives might not
> > see your attachments.
> >
> > At a first glance, although this feature is not used in the current
> > OFBiz code base. it _might_ be used by some users who are running
> > certain tests against specific tenants for example. So although I
> > would probably lean towards removing it, I'd recommend making sure
> > that not many people depend on this feature. Perhaps you can check in
> > the user ML or wait for others to share their opinions.
> > On Sun, Oct 21, 2018 at 10:51 PM Mathieu Lirzin
> >  wrote:
> > >
> > > Hello Taher,
> > >
> > > Taher Alkhateeb  writes:
> > >
> > > > An example could shed some light here perhaps?
> > >
> > > What kind of examples would help you?
> > >
> > > AIUI It would be for the people using this feature outside of the
> > > framework to provide examples why we should keep it in.
> > >
> > > > What do you want to remove from where?
> > >
> > > Here is what I precisely want to remove.
> > >
> > >
> > > > How is it complex?
> > >
> > > Basically each time an option is provided it adds complexity.  In this
> > > particular case, perhaps a comparaison between the two models of test
> > > execution can help describing the added complexity:
> > >
> > > Current model:
> > >1. Launch OFBiz
> > >2. Fetch all the tests from the components
> > >3. Keep track which delegator/dispatcher correspond to each test suite
> > >4. Run each test by setting its corresponding delegator/dispatcher
> > >
> > > Model without option:
> > >1. Launch OFBiz with the test delegator/dispatcher
> > >2. Fetch all the tests from the components
> > >3. Run the tests.
> > >
> > > Does it help?
> > >
> > > --
> > > Mathieu Lirzin
> > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> >


Re: Using alternate dispatcher and delegator for integration tests

2018-10-27 Thread Taher Alkhateeb
Ahh, Now I understand what you mean by looking at your patch. I
recommend next time that you copy-paste into the email thread because
people who try to access this thread using the ML archives might not
see your attachments.

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


Re: Does ‘StartupControlPanel#loadStartupLoaders’ really require introspection?

2018-10-27 Thread Taher Alkhateeb
Hi Mathieu,

This is code which I refactored from a very messy startup code, and
yes you are right, we don't need java reflection, and we do not even
need a startup loader in the first place. The code could be much
simpler.

We used to have 2 startup loaders, the existing one, and also a loader
for the GUI POS system which we deleted during refactoring. The idea
back in the day was that the startup code could be instantiated by
multiple loaders to customize the behavior of the system.

The refactoring work is not yet done, and we got side tracked by many
issues, but I would say maybe 50% or more of the existing java code
base could be trimmed down and simplified.

My recommendation is to completely delete the startup loaders API, but
there are a few technical challenges to it because there is some state
linked to it here and there, so it's a matter of catching everything,
re-routing ,and getting a simpler startup logic.
On Mon, Oct 22, 2018 at 12:37 AM Mathieu Lirzin
 wrote:
>
> Hello,
>
> I have a question regarding the
> ‘org.apache.ofbiz.base.start.StartupControlPanel#loadStartupLoaders()’
> current implementation:
>
> --8<---cut here---start->8---
> private static void loadStartupLoaders(Config config,
> List loaders,
> List ofbizCommands,
> AtomicReference serverState) throws StartupException 
> {
>
> String startupLoaderName = 
> "org.apache.ofbiz.base.container.ContainerLoader";
> ClassLoader classloader = 
> Thread.currentThread().getContextClassLoader();
>
> synchronized (loaders) {
> if (serverState.get() == ServerState.STOPPING) {
> return;
> }
> try {
> Class loaderClass = 
> classloader.loadClass(startupLoaderName);
> StartupLoader loader = (StartupLoader) 
> loaderClass.newInstance();
> loaders.add(loader); // add before loading, so unload can 
> occur if error during loading
> loader.load(config, ofbizCommands);
> } catch (ReflectiveOperationException e) {
> throw new StartupException(e);
> }
> }
> serverState.compareAndSet(ServerState.STARTING, ServerState.RUNNING);
> }
> --8<---cut here---end--->8---
>
> I don't understand the goal of using reflection for instantiating the
> ‘ContainerLoader’ class. Can't we just have something like the following
> instead?
>
> --8<---cut here---start->8---
> private static void loadStartupLoaders(Config config,
> List loaders,
> List ofbizCommands,
> AtomicReference serverState) throws StartupException 
> {
>
> ClassLoader classloader = 
> Thread.currentThread().getContextClassLoader();
>
> synchronized (loaders) {
> if (serverState.get() == ServerState.STOPPING) {
> return;
> }
> StartupLoader loader = new ContainerLoader();
> loaders.add(loader); // add before loading, so unload can occur 
> if error during loading
> loader.load(config, ofbizCommands);
> }
> serverState.compareAndSet(ServerState.STARTING, ServerState.RUNNING);
> }
> --8<---cut here---end--->8---
>
> If this is required, I will be happy if someone could add an inline
> comment giving a rationale for the current implementation.  If that's
> not the case, I can open a JIRA with a proper patch if needed.
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: Pursuing the “120 chars max” guideline (was: svn commit: r1844729 - in /ofbiz/ofbiz-framework/trunk/framework/webapp: dtd/site-conf.xsd src/main/java/org/apache/ofbiz/webapp/control/RequestHandler

2018-10-27 Thread Taher Alkhateeb
As I said countless times so far, mostly to Jacques, let's please try
to avoid the "I have an idea, now let's do it everywhere in the code
base" kind of approach. Slow gradual refactoring is the way to go to
ensure sustainable quality and stability.

Therefore, I'm in favor of Mathieu's approach.

On Fri, Oct 26, 2018 at 12:13 PM Mathieu Lirzin
 wrote:
>
> 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?
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: svn commit: r1844880 - in /ofbiz: ofbiz-framework/trunk/ ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/ ofbiz-framework/trunk/framework/common/webcommon/WEB-INF/ ofb

2018-10-27 Thread Taher Alkhateeb
For the record I did not review and approve, I had concerns and they
are noted in the JIRA
On Fri, Oct 26, 2018 at 12:32 PM  wrote:
>
> Author: jleroux
> Date: Fri Oct 26 09:32:46 2018
> New Revision: 1844880
>
> URL: http://svn.apache.org/viewvc?rev=1844880=rev
> Log:
> Implemented: Navigate from a domain to another with automated signed in
> authentication
> (OFBIZ-10307)
>
> This uses a JWT Token authentication to get from one domain, where you are
> signed in, to another domain where you get signed in automatically.
> Something like ExternalLoginKey or Tomcat SSO, but not on the same domain.
>
> In the example component, the FormWidgetExamples screen contains 2 new fields
> in the LinksExampleForm which demonstrate the use from a local instance to the
> trunk demo instance.
>
> A simple documentation is available in
>   framework\webapp\src\docs\asciidoc\_include\wa-cross-domains-SSO.adoc
>
> Thanks: Taher for review
>
> Modified:
> ofbiz/ofbiz-framework/trunk/build.gradle
> 
> ofbiz/ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/CommonEvents.java
> 
> ofbiz/ofbiz-framework/trunk/framework/common/webcommon/WEB-INF/common-controller.xml
> ofbiz/ofbiz-framework/trunk/framework/security/config/security.properties
> 
> ofbiz/ofbiz-framework/trunk/framework/webapp/src/docs/asciidoc/_include/wa-cross-domains-SSO.adoc
> 
> ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ExternalLoginKeysManager.java
> 
> ofbiz/ofbiz-framework/trunk/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java
> 
> ofbiz/ofbiz-framework/trunk/themes/common-theme/webapp/common/js/util/OfbizUtil.js
> ofbiz/ofbiz-plugins/trunk/example/config/ExampleUiLabels.xml
> 
> ofbiz/ofbiz-plugins/trunk/example/widget/example/FormWidgetExampleForms.xml
>
> Modified: ofbiz/ofbiz-framework/trunk/build.gradle
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/build.gradle?rev=1844880=1844879=1844880=diff
> ==
> --- ofbiz/ofbiz-framework/trunk/build.gradle (original)
> +++ ofbiz/ofbiz-framework/trunk/build.gradle Fri Oct 26 09:32:46 2018
> @@ -162,6 +162,7 @@ dependencies {
>  compile 'oro:oro:2.0.8'
>  compile 'wsdl4j:wsdl4j:1.6.3'
>  compile 'org.jsoup:jsoup:1.11.2'
> +compile 'io.jsonwebtoken:jjwt:0.9.0'
>
>  // ofbiz unit-test compile libs
>  testCompile 'org.mockito:mockito-core:2.13.0'
>
> Modified: 
> ofbiz/ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/CommonEvents.java
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/CommonEvents.java?rev=1844880=1844879=1844880=diff
> ==
> --- 
> ofbiz/ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/CommonEvents.java
>  (original)
> +++ 
> ofbiz/ofbiz-framework/trunk/framework/common/src/main/java/org/apache/ofbiz/common/CommonEvents.java
>  Fri Oct 26 09:32:46 2018
> @@ -51,6 +51,8 @@ import org.apache.ofbiz.entity.Delegator
>  import org.apache.ofbiz.entity.GenericEntityException;
>  import org.apache.ofbiz.entity.GenericValue;
>  import org.apache.ofbiz.entity.util.EntityUtilProperties;
> +import org.apache.ofbiz.webapp.control.JWTManager;
> +import org.apache.ofbiz.webapp.control.LoginWorker;
>  import org.apache.ofbiz.widget.model.ThemeFactory;
>  import org.apache.ofbiz.widget.renderer.VisualTheme;
>
> @@ -379,4 +381,20 @@ public class CommonEvents {
>  return "success";
>  }
>
> +public static String loadJWT(HttpServletRequest request, 
> HttpServletResponse response) throws UnsupportedEncodingException {
> +Delegator delegator = (Delegator) request.getAttribute("delegator");
> +Map types = new HashMap<>();
> +String webAppName = UtilHttp.getApplicationName(request);
> +String securedUserLoginId = 
> LoginWorker.getSecuredUserLoginId(request, webAppName);
> +if (securedUserLoginId != null) {
> +types.put("userLoginId", securedUserLoginId);
> +int ttlSeconds =  (int) 
> Long.parseLong(EntityUtilProperties.getPropertyValue("security", 
> "security.jwt.token.expireTime", "10", delegator));
> +String token = JWTManager.createJwt(delegator, types, 
> ttlSeconds);
> +writeJSONtoResponse(JSON.from(token), request, response);
> +} else {
> +Debug.logWarning("No securedUserLoginId cookie was found for 
> this application", module);
> +}
> +return "success";
> +}
> +
>  }
>
> Modified: 
> ofbiz/ofbiz-framework/trunk/framework/common/webcommon/WEB-INF/common-controller.xml
> URL: 
> 

Re: Using alternate dispatcher and delegator for integration tests

2018-10-21 Thread Taher Alkhateeb
An example could shed some light here perhaps? What do you want to
remove from where? How is it complex?
On Sun, Oct 21, 2018 at 5:17 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> I am trying to simplify the way integration tests are currently run.
> While looking at ‘org.apache.ofbiz.testtools.ModelTestSuite’ I have
> found that it is possible to define alternate dispatcher and delegator
> for specific tests.
>
> This feature is not used anywhere in the framework and introduces a ton
> of complexity since we can't assume that there is only one dispatcher
> and delegator shared by all the tests cases.
>
> As a consequence I would like to know if we could agree on removing this
> unused feature?
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: Groovy DSL runService Exception Management ?

2018-10-18 Thread Taher Alkhateeb
Well, I'm not sure what's the best approach, but your suggestion would
perhaps add more verbosity and so needs to have a reason.

Exceptions are not always necessarily a "bad" thing, they're just a
language feature to indicate a different path of execution, so
bubbling an exception to stop a service sounds reasonable and might be
even a better approach because if you have very complex logic then you
can just let the exception bubble up until it stop the service hence
reverting all DB changes.

I could be wrong or missing something of course, so opinions might
enrich the discussion here.
On Thu, Oct 18, 2018 at 11:45 AM Gil Portenseigne
 wrote:
>
> Hello !
>
> While we are working on Groovy migration at Nereide, we figured out that
> using ‘run service’ DSL method instead of returning the errorMap, a
> ‘ExecutionServiceException’ is thrown :
>
> if (ServiceUtil.isError(result)) {
> throw new
> ExecutionServiceException(ServiceUtil.getErrorMessage(result))
> }
>
> Can anyone explain the intention behind that implementation ?
>
> I suppose that we need to catch any service call like :
>
> try {
> serviceResult = run service: 'createQuoteAdjustment', with:
> [*: quoteAdjustement, quoteId: quoteIdTo]
> } catch (ExecutionServiceException e) {
> return ServiceUtil.returnError(e.getMessage())
> }
>
> instead of :
>
> serviceResult = run service: 'createQuoteAdjustment', with:
> [*: quoteAdjustement, quoteId: quoteIdTo]
>
> if (ServiceUtil.isError(serviceResult)) {
> return serviceResult
> }
>
> I wonder if exception management is more costly than simple return.
> May the GroovyEngine should handle the exception ? I do not grasp yet
> the benenit of this implementation.
>
> What is the good way to handle service errors within services in Groovy?
>
> Thanks
>
> Gil


Re: Missing Security Headers in CMS Events

2018-10-08 Thread Taher Alkhateeb
Hi Deepak,

Sounds good. Are these headers applied everywhere except CMS? If no then
why not apply them everywhere?


On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
wrote:

> Hello All,
>
> While rendering the view through the controller request we set the
> important security headers like x-frame-options, strict-transport-security,
> x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
> response object. (Please see the 'rendervView' method of RequestHandler
> class.) But these security headers are missing in the pages rendered
> through CMS. (Please visit the CmsEvents class).
>
> These headers are very crucial for the security of the application as they
> help to prevent various security threats like cross-site scripting,
> cross-site request forgery, clickjacking etc.
>
> IMO, we should add these security headers in the response object prepared
> through the CMS also. WDYT?
>
> Thanks & Regards
> --
> Deepak Nigam
> HotWax Systems Pvt. Ltd.
>


Re: svn commit: r1842921 - /ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml

2018-10-05 Thread Taher Alkhateeb
This workaround looks ugly, can't we relocate this URL?
On Fri, Oct 5, 2018 at 5:22 PM  wrote:
>
> Author: jleroux
> Date: Fri Oct  5 14:22:15 2018
> New Revision: 1842921
>
> URL: http://svn.apache.org/viewvc?rev=1842921=rev
> Log:
> Fixed: The query iCalendar/CALENDAR_PUB_DEMO/ no longer work
> (OFBIZ-10595)
>
> ControlFilter does not allow the untypical iCalendar/CALENDAR_PUB_DEMO/ query
> to pass.
> I have not checked deep, but since R13 works I believe it's due to OFBIZ-6760
> where ControlFilter was added. Then CALENDAR_PUB_DEMO/ is considered a
> [Filtered request] and the whole iCalendar process in Thunderbird Calendar is
> broken
>
> Thanks:  Jyri Sillanpaa for the detailled report
>
> Modified:
> 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml
>
> Modified: 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml?rev=1842921=1842920=1842921=diff
> ==
> --- 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml
>  (original)
> +++ 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml
>  Fri Oct  5 14:22:15 2018
> @@ -44,7 +44,7 @@ under the License.
>  
> org.apache.ofbiz.webapp.control.ControlFilter
>  
>  allowedPaths
> -
> /error:/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images
> +
> /error:/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images:/CALENDAR_PUB_DEMO
>  
>  
>  redirectPath
>
>


[SECURITY] CVE-2011-3600 Apache OFBiz XML-RPC XXE Vulnerability

2018-10-05 Thread Taher Alkhateeb

Severity:
Important

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz 16.11.01 to 16.11.04

Description:
The OFBiz XML-RPC event handler 
(org.apache.ofbiz.webapp.event.XmlRpcEventHandler.java)
acts as a wrapper for any OFBiz service that provides XML-RPC web 
services via

the /webtools/control/xmlrpc endpoint. This endpoint is exposed to External
Entity Injection by passing DOCTYPE declarations with executable 
payloads that
discloses the contents of files in the filesystem. In addition, it can 
also be

used to probe for open network ports, and figure out from returned error
messages whether a file exists or not.

Mitigation:
Upgrade to 16.11.05
or manually apply the following commits on branch 16
r1833724
r1833708
r1836141

Example:
# Payload to find an exposed port

http://localhost:8080;>

    ping


# Payload to display file contents


]>

    


Credit:
James Parfet 

References:
http://ofbiz.apache.org/download.html#vulnerabilities



Re: Build failed

2018-10-01 Thread Taher Alkhateeb
Ahhh I see the tests were dependant on the remote dtds. Weird design

On Mon, Oct 1, 2018, 11:18 PM Deepak Dixit  wrote:

> I am sure that this is due to the changes done in the ofbiz website, After
> updating the redirect rule condition it's fixed.
> http to https redirect affect all the older version as well, all the ofbiz
> versions usinging http://ofbiz.apache.org/dtds/* as a namespace.
>
> Thanks Benjamin Jugl and Pierre Smits for your suggestion :)
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
> On Tue, Oct 2, 2018 at 12:56 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > I have a feeling this has nothing to do with this commit, I have an
> > older working copy that is also crashing.
> >
> > This could mean that the problem is somewhere in the gradle
> > dependencies, something corrupted or wrong in JCenter perhaps?
> > On Mon, Oct 1, 2018 at 4:42 PM Deepak Dixit 
> > wrote:
> > >
> > > This should be fixed at r#1842499
> > >
> > > Here is the ticket for further work as mentioned by Michale.
> > > https://issues.apache.org/jira/browse/OFBIZ-10590
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > >
> > >
> > > On Mon, Oct 1, 2018 at 5:59 PM, Pierre Smits 
> > wrote:
> > >
> > > > Upgrading the references in the code base to
> > > > https://ofbiz.apache.org/dtds/entity-config.xsd should do the trick,
> > > > correct?
> > > >
> > > > 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 Mon, Oct 1, 2018 at 1:42 PM Deepak Dixit 
> > > > wrote:
> > > >
> > > > > 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:
> > > > > > >
> > > > > > > ===
>

Re: Build failed

2018-10-01 Thread Taher Alkhateeb
I have a feeling this has nothing to do with this commit, I have an
older working copy that is also crashing.

This could mean that the problem is somewhere in the gradle
dependencies, something corrupted or wrong in JCenter perhaps?
On Mon, Oct 1, 2018 at 4:42 PM Deepak Dixit  wrote:
>
> This should be fixed at r#1842499
>
> Here is the ticket for further work as mentioned by Michale.
> https://issues.apache.org/jira/browse/OFBIZ-10590
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
> On Mon, Oct 1, 2018 at 5:59 PM, Pierre Smits  wrote:
>
> > Upgrading the references in the code base to
> > https://ofbiz.apache.org/dtds/entity-config.xsd should do the trick,
> > correct?
> >
> > 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, Oct 1, 2018 at 1:42 PM Deepak Dixit 
> > wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >


Re: "Not Secure" in the Google Chrome browser

2018-09-30 Thread Taher Alkhateeb
+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 
>


Re: [VOTE] [RELEASE] Apache OFBiz 16.11.05

2018-09-23 Thread Taher Alkhateeb
+1

tests are good, smoke tests don't reveal anything out of the ordinary,
and everything seems to be in proper order.
On Sat, Sep 22, 2018 at 3:28 PM Michael Brohl  wrote:
>
> +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
> >
>
>


Re: POM relocation to an other version number is not fully supported in Gradle

2018-09-21 Thread Taher Alkhateeb
I think we can safely ignore. If a problem arises we hardwire the
dependency, so not a big deal at all

On Fri, Sep 21, 2018, 6:15 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi Jacques
>
> It looks like every transitive dependency defined in our build.gradle to
> xml-apis is getting resolved to xml-apis:2.0.2.
>
> +--- xom:xom:1.2.5
>
> ||+--- xml-apis:xml-apis:1.3.03 -> 2.0.2
>
> +--- xml-apis:xml-apis:1.3.04 -> 2.0.2
>
> org.apache.xmlrpc:xmlrpc-client:3.1.3
>
> |\--- org.apache.xmlrpc:xmlrpc-common:3.1.3
>
> | \--- org.apache.ws.commons.util:ws-commons-util:1.0.2
>
> |  +--- junit:junit:3.8.1 -> 4.11 (*)
>
> |  \--- xml-apis:xml-apis:1.0.b2 -> 2.0.2
>
> Apparently, this has been occurring since earlier gradle versions as well
> and no support yet.
>
> Does the build fail due to this? If it is just a warning, then may be we
> can live with it. And if there is a hard dependency on it, then may be we
> should try forcing the version as shown in the SOF link you sent.
>
> While I do not have any particular opinion on this, may be others can weigh
> in and take a call as to what should be done.
>
> Best,
> Girish
> HotWax Systems
>
>
> On Fri, Sep 21, 2018 at 5:28 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 21/09/2018 à 13:29, Jacques Le Roux a écrit :
> > > Hi,
> > >
> > > I cleared by Gradle cache, so had to reload all.
> > my
> >
> > >
> > > I stumbled upon this is in log
> > >
> > >Download
> > https://jcenter.bintray.com/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
> > >POM relocation to an other version number is not fully supported in
> > Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
> > >Please update your dependency to directly use the correct version
> > 'xml-apis:xml-apis:1.0.b2'.
> > >
> > > xml-apis-2.0.2 is not a dependency we define in build.gradle.
> > >
> > > We could use this trick
> >
> https://stackoverflow.com/questions/22613596/gradle-download-dependency-error
> > >
> > > But should we or should we simply neglect and wait it resolves by
> itself?
> > >
> > > Jacques
> > >
> > >
> >
> >
>


Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

2018-09-20 Thread Taher Alkhateeb
Agree with Arun, every company has its own security setup, but permissions
are shared and hard wired into screens / services / etc...

On Fri, Sep 21, 2018, 8:50 AM Arun Patidar  wrote:

> Deepak,
>
> IMO,  'SecurityPermission' data should always be part of seed data. but
> SecurityGroup and SecurityGroupPermission like a sample data so should be
> part of demo data.
>
>
>
>
> Kind Regards,
>
> Arun Patidar
> Director of Information Systems
>
> *HotWax CommerceReal OmniChannel. Real Results.*
> m: +91 9827353082
> w: www.hotwax.co
>
>  
> 
> 
>
>
>
> On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam 
> wrote:
>
> > Hello All,
> >
> > Currently, SecurityPermission, SecurityGroup and SecurityGroupPermission
> > data are mixed in demo and seed data files. Shouldn't these all data be
> > part of seed data files only?
> >
> > Most of the SecurityPermission data is already part of seed data except
> the
> > files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but there
> > is not any fixed pattern for the SecurityGroup and
> > SecurityGroupPermissionData.
> >
> > A Jira ticket OFBIZ-10575
> >  is available for the
> > same.
> >
> >
> > Thanks & Regards
> > --
> > Deepak Nigam
> > HotWax Systems Pvt. Ltd.
> >
>


Re: Preparing the new release 16.11.05

2018-09-14 Thread Taher Alkhateeb
I don't think this issue is a blocker for a new release, nor does it
necessarily warrant a release just for that. It can just be part of a batch
as usual.

On Fri, Sep 14, 2018, 12:09 PM Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> On Mon, Sep 10, 2018 at 2:47 PM Pierre Smits 
> wrote:
>
> > Should OFBIZ-4361 not get resolved for this?
>
>
> It makes sense, thank you.
> I have posted a comment in the ticket and hopefully we will come up with a
> quick resolution.
> Should we wait a few more days to see if we can commit and test that work
> before we start the release voting process? However I wouldn't delay the
> release preparation more than a few days and I would rather issue this
> release and then issue another one in a few weeks.
>
> Regards,
>
> Jacopo
>


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 Taher Alkhateeb
One way to make the transition smooth, is to do the following:
1- create a new service definition (the renamed service)
2- rename the implementation service (where the source code lives)
3- point both the old and new service definitions to the same new and
renamed implementation
4- Mark the old service definition as deprecated and specify _when_
you would intend to remove it.
On Wed, Sep 12, 2018 at 3:39 PM Taher Alkhateeb
 wrote:
>
> +1 to Michael's suggestion. We are changing core services in core 
> applications.
> On Wed, Sep 12, 2018 at 3:22 PM Michael Brohl  
> wrote:
> >
> > 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>
> > > 
> > > -  > > action="/facility/control/quickShipPurchaseOrder?externalLoginKey=${externalLoginKey}"
> > >  method="post">
> > > +  > > action="/facility/control/quickReceivePurchaseOrder?externalLoginKey=${externalLoginKey}"
> > >  method="post">
> > >   > > value="Y"/>
> > >   > > value="${orderId}"/>
> > >  <#-- 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.
> > >
> > > 
> > > 
> > > - > > action="/facility/control/quickShipPurchaseOrder?externalLoginKey=${externalLoginKey}"
> > >  method="post">
> > > + > > action="/facility/control/quickReceivePurchaseOrder?externalLoginKey=${externalLoginKey}"
> > >  method="post">
> > >  > > value="Y"/>

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 Taher Alkhateeb
+1 to Michael's suggestion. We are changing core services in core applications.
On Wed, Sep 12, 2018 at 3:22 PM Michael Brohl  wrote:
>
> 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>
> > 
> > -  > action="/facility/control/quickShipPurchaseOrder?externalLoginKey=${externalLoginKey}"
> >  method="post">
> > +  > action="/facility/control/quickReceivePurchaseOrder?externalLoginKey=${externalLoginKey}"
> >  method="post">
> >   > value="Y"/>
> >   > value="${orderId}"/>
> >  <#-- 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.
> >
> > 
> > 
> > - > action="/facility/control/quickShipPurchaseOrder?externalLoginKey=${externalLoginKey}"
> >  method="post">
> > + > action="/facility/control/quickReceivePurchaseOrder?externalLoginKey=${externalLoginKey}"
> >  method="post">
> >  > value="Y"/>
> >  > value="${orderId}"/>
> >  > value="${orderId}"/>
> >
> > 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.
> >   
> >   
> >
> > - > short-description="Quick ships an entire purchase order to a facility">
> > + > short-description="Quick receives an entire purchase order in a facility">
> >   
> >   
> >   
> >> method-name="createShipmentForFacilityAndShipGroup"/>
> > -
> > +
> >   
> >   
> >
> >
> > 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
> > 

Re: svn commit: r1840446 - /ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml

2018-09-12 Thread Taher Alkhateeb
I am confused, this is not a rename, but rather changing the service
being invoked. Also this has nothing to do with the javascript files
mentioned but rather controller entries?
On Mon, Sep 10, 2018 at 12:52 PM  wrote:
>
> Author: jleroux
> Date: Mon Sep 10 09:52:43 2018
> New Revision: 1840446
>
> URL: http://svn.apache.org/viewvc?rev=1840446=rev
> Log:
> Improved: Rename the misnamed setUserLocale.js to setUserTimeZone.js
> (OFBIZ-10472)
>
> At the same time renames setLocaleFromBrowser to SetTimeZoneFromBrowser
> everywhere it's needed. FORGOT IT in WEBPOS!
>
> Modified:
> ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml
>
> Modified: 
> ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml?rev=1840446=1840445=1840446=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml 
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/webpos/webapp/webpos/WEB-INF/controller.xml Mon 
> Sep 10 09:52:43 2018
> @@ -473,9 +473,9 @@
>  
>
>  
> -
> +
>  
> -
> +
>  
>  
>  
>
>


Re: Impersonation and Documentation

2018-09-10 Thread Taher Alkhateeb
Actually, Mathieu made a very good point. Asciidoc does indeed support
variables. I think that's the best middle solution.
On Mon, Sep 10, 2018 at 3:21 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> Gil Portenseigne  writes:
>
> > A tool for this purpose is in my opinion do not fit, we need
> > to commit ourselves to doc maintainment, when the code base is changed.
> > I do not see any good working automation around that, this has to be
> > done manually to ensure a good documenation.
>
> Even if people try to be thorough, it is very likely that they will
> eventually overlook that the documentation needs to be updated.
>
> While I sympathize with any effort of avoiding the over-tooling trap, I
> think it is *very* important to have consistency between the
> documentation and the actual code in use for example ensuring that the
> code examples provided in the documentation are still working.  Given
> the complexity of OFBiz, it would be really harmful for newcomers if
> that was not the case.  AIUI having a mismatch of images while not being
> as damaging as a code example mismatch is still something that is
> important to avoid.  As a consequence I would be in favour of some
> tooling that helps in that regard.
>
> I personnally don't mind the “../../..” thing if the documentation build
> process fails when the providing file name is incorrect.  However if the
> issue is about readability, maybe Asciidoc provides a way to define
> variables?  If so, file name prefixes could be defined with a variable
> with a meaningful name that could then be reused when referring to an
> external file.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37


Re: Impersonation and Documentation

2018-09-10 Thread Taher Alkhateeb
perhaps you can place a copy of whatever you want in
$OFBIZ_HOME/docs/asciidoc/images/
On Mon, Sep 10, 2018 at 10:22 AM Gil Portenseigne
 wrote:
>
> Hello Jacques !
>
> Anytime I see "../../../ ...", i feel like it's a bad design.
>
> Moreover i think that documentation should be auto-sufficient, and should not 
> be
> code dependant. So a direct reference to theme material in this way
> should be avoided.
>
> Gil
>
>
> Le lundi 10 sept. 2018 à 08:14:14 (+0200), Jacques Le Roux a écrit :
> > Le 07/09/2018 à 16:19, Gil Portenseigne a écrit :
> > > On another hand, i wanted to reference an icon within common-theme, i
> > > set the property :
> > > :imagesdir: ../../../../../../themes/common-theme/webapp/images/img/
> > >
> > > Which is in my opinion a bad choice. I guess it's better to duplicate
> > > the image within the documentation tree.
> > Hi Gil,
> >
> > To enlighten myself, why do you consider it a bad choice?
> >
> > Jacques
> >


Re: Impersonation and Documentation

2018-09-08 Thread Taher Alkhateeb
The asciidoc design is really simple: you have two main documents in
the system found under docs/asciidoc. One is the user manual and the
other one is the developer manual.

Each one of these documents is in turn, pointing to other documents
that by default are placed in /src/docs/asciidoc in each component and
holds the same component name. So if you want to add this
documentation, you will:
- Add an "include" section in the main documentation document
- Create your document in src/docs/asciidoc
- Provide the contents
- Test using ./gradlew generateOfbizDocumentation
On Fri, Sep 7, 2018 at 5:20 PM Gil Portenseigne
 wrote:
>
> Hello,
>
> I just published a new version of impersonation feature (OFBIZ-10515),
> and i wrote down some asciidoc documentation.
>
> I got some questions to documentation team to get the best practice
> around it.
>
> I write down a documentation within:
> framework/security/src/doc/asciidoc/_include/security-impersonation.adoc
> but i'm not sure about the location, since the gradle doc tasks do not
> take it into account. I guess i'm wrong. If you can point me where is
> the best place for this kind of documentation.
>
> On another hand, i wanted to reference an icon within common-theme, i
> set the property :
> :imagesdir: ../../../../../../themes/common-theme/webapp/images/img/
>
> Which is in my opinion a bad choice. I guess it's better to duplicate
> the image within the documentation tree.
>
> Thanks and regards,
>
> Gil


Re: Async persist service on error restart indefinitely by default

2018-09-08 Thread Taher Alkhateeb
I could be wrong, but, wouldn't it make sense that if your service is
failing continuously then perhaps something is wrong with the service?
I would imagine that perhaps resilience in the design of the service
might be the better route?
On Fri, Sep 7, 2018 at 6:22 PM Nicolas Malin  wrote:
>
> Hi,
>
> On a customer site, we have huge services that call different rest api
> to collect information
> To increase the velocity we run all them by persistence asynchrone then
> the job pooler manage them with available resources.
>
> The problem is, when a call failed and the service threw an error, the
> service engine reschedule it, ... and it failed, rescheduled, failed,
> rescheduled, failed ... with beautiful result to overload your pool with
> zombie services.
>
> The solution is easy, set on your service definition attribute max-retry
> to 0 (or 1, if you want one retry) but I didn't understand why we have
> this configuration to reschedule indefinitely a service if it is in error.
>
> This configuration exists before apache migration so I'd happy to have
> your vision about this.
>  From my view, I'm in favor to set max retry to 0 by default and left
> the developer set him self when he wants that a service restart after a
> failure.
>
> Easy change  :
> Index:
> framework/service/src/main/java/org/apache/ofbiz/service/job/PersistedServiceJob.java
>
> @@ -80,7 +80,7 @@
>   this.jobValue = jobValue;
>   Timestamp storedDate = jobValue.getTimestamp("runTime");
>   this.startTime = storedDate.getTime();
> -this.maxRetry = jobValue.get("maxRetry") != null ?
> jobValue.getLong("maxRetry") : -1;
> +this.maxRetry = jobValue.get("maxRetry") != null ?
> jobValue.getLong("maxRetry") : 0;
>
> Nicolas
>
> --
> logoNrd 
> Nicolas Malin
> The apache way  : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz |The Apache Way
> |réseau LE 


Re: Error in groovy files only inside docker

2018-09-05 Thread Taher Alkhateeb
Probably nothing to do with docker but rather the environment setup. Check
Java version and your build script and make sure everything is setup
correctly.

On Wed, Sep 5, 2018, 11:05 AM albertooli...@gmail.com <
albertooli...@gmail.com> wrote:

> Hello everyone!
>
> I am customizing a plugin with ofbiz (new screens and entities, not groovy
> at all), and in my local computer (Windows 10, jdk8_171) works prety fine,
> but when I build a docker image and deploy it (Linux), some screens have
> Exceptions, and also lookups show groovy errors.
>
>
> This screen is webTools -> Service Engine
>
> 2018-09-04 12:57:07,268 |http-nio-8443-exec-1 |ControlServlet
>   |E| Error in request handler:
> org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
> screen [component://webtools/widget/ServiceScreens.xml#ServiceList]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://webtools/groovyScripts/service/AvailableServices.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
> [component://webtools/groovyScripts/service/AvailableServices.groovy]:
> (startup failed:
> component://webtools/groovyScripts/service/AvailableServices.groovy: 334:
> A transform used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> AvailableServices directly. You are not supposed to do this. Please create
> a new ClassNode referring to the old ClassNode and use the new ClassNode
> instead of the old one. Otherwise the compiler will create wrong
> descriptors and a potential NullPointerException in TypeResolver in the
> OpenJDK. If this is not your own doing, please report this bug to the
> writer of the transform.
> @ line 334, column 1.
>dispArrList = new TreeSet()
>^
>
> 1 error
>
>
> Then, in Log Screen:
>
> 2018-09-04 12:57:36,416 |http-nio-8443-exec-7 |ModelScreen
>|E| Error rendering screen
> [component://webtools/widget/LogScreens.xml#LogView]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://webtools/groovyScripts/log/FetchLogs.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
> [component://webtools/groovyScripts/log/FetchLogs.groovy]:  (startup failed:
> component://webtools/groovyScripts/log/FetchLogs.groovy: 23: A transform
> used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> FetchLogs directly. You are not supposed to do this. Please create a new
> ClassNode referring to the old ClassNode and use the new ClassNode instead
> of the old one. Otherwise the compiler will create wrong descriptors and a
> potential NullPointerException in TypeResolver in the OpenJDK. If this is
> not your own doing, please report this bug to the writer of the transform.
> @ line 23, column 1.
>String ofbizLogDir = UtilProperties.getPropertyValue("debug",
> "log4j.appender.css.dir", "runtime/logs/")
>^
>
> 1 error
>
>
> And in my custom Lookpus, the screen does not fails completly, but shows
> this error in the dinamic groovy part of the field:
>
>
> org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
> screen [component://common/widget/CommonScreens.xml#LookupDecorator]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script
> at [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
> (startup failed:
> component://common/groovyScripts/FindAutocompleteOptions.groovy: 32:
> A transform used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> FindAutocompleteOptions directly.
> You are not supposed to do this. Please create a new ClassNode referring
> to the old ClassNode and use the new ClassNode instead of the old one.
> Otherwise the compiler will create wrong descriptors and a potential
> NullPointerException in TypeResolver in the OpenJDK.
> If this is not your own doing, please report this bug to the writer of the
> transform. @ line 32, column 1. def mainAndConds = [] ^ 1 error )
> (Error running script at location
> [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
>
>
> Any suggestions why only fails in docker/linux?
>
> Thanks in advance!
>


Re: [QUESTION] Should we not check fields consistency?

2018-09-03 Thread Taher Alkhateeb
Julien makes a good point. This is too specific and context sensitive to
apply across the board.

On Mon, Sep 3, 2018, 4:28 PM Julien NICOLAS 
wrote:

> Hello
>
> I've already implemented this kind of things and if you want to be
> exhaustive, you have to do it at least in service AND in UI.
>
> However, it really depend on use cases that it depend on the customer
> tastes. When it depend on customer tastes, I prefer to keep it open in
> the framework / OOTB webapp than limit the OFBiz possibilities.
>
> The only reason that we can do it is for legal locking features...
> but... it could depend on the country, so...
>
> My 2 cents,
>
> Julien.
>
>
> Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
> > By root I mean the point where things begin. And for entering data for
> > end users it all start in UI. If you can stop things at this level,
> > you don't have to worry for sequel. That's what I mean by "root in
> > UI". Maybe "seed in UI" would have been a better image :)
> >
> > It would be more to prevent users's typo errors, fat fingers and such,
> > without ambition to rule all cases, notably for later actions.
> >
> > Rest inline...
> >
> > Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :
> >> I don't know what it means by the root in UI, but we are arriving at a
> >> complex topic: Validation.
> > Yep, I know. Let's try to keep it as simple as possible
> >
> >> Validation is something that can happen on many levels like:
> >> - entity definition level
> >> - entity-auto level
> >> - service level
> >> - UI level
> >> - route level
> >>
> >> Each one of those has advantages and disadvantages. So I don't think
> >> this is something we can make a rule for. What if a user wants to
> >> enter a back-dated order?
> > Good question. They are cases, as in my examples, where common sense
> > applies and there are no doubts (eg shipping before creating comes to
> > mind). A case like you suggest should not stop us to think about all
> > the others.
> >
> >> What if a user wants to be able to search
> >> for a date range in the past,
> > That should not be a problem. It's all about keeping things
> > consistent. For instance not reserving after shipping. I'm sure there
> > are plenty other cases where common sense applies. I only speak about
> > dates here, but I don't suggest to restrict only to date fields.
> > There also case where it's not as simple and then we need to think
> > about it. In this case do you think at something particularly? An URL
> > would help.
> >
> >> what if the site owner wants validation
> >> on the service level for security because users can break out of
> >> browser validation and enter a back-dated dates?
> > That's another topic I'd say. I'm not sure, but maybe we can enforce
> > this rule, even on the client side.
> > To begin with baby steps, we should try to deliver common sense rules
> > OOTB and let users adapt them to their needs.
> > Maybe we can even have a vision to help them. But my intention here is
> > to keep things as simple as possible to begin.
> >
> >
> >> I think this proposal needs more information and details. Otherwise
> >> it's hard to determine what is the right decision as circumstances
> >> vary widely
> > It was not a proposal so far, only a [QUESTION] to see if we are
> > interested in researching this. I know it's not that simple, thank you
> > for your questions. Let's see if others believe we should make it a
> > [PROPOSAL]
> >
> > Jacques
> >
> >> On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
> >>  wrote:
> >>> It's only about checking at the root in UI when entering data and
> >>> not let things go as long as the value is not correct
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
> >>>> Well, it depends on where the cross checks happen. Are you talking
> >>>> about UI? entity-auto? somewhere else?
> >>>> On Mon, Sep 3, 2018 at 11:52 AM deepak nigam
> >>>>  wrote:
> >>>>> +1.
> >>>>>
> >>>>> Thanks for the putting this forward. Please count me in for this
> >>>>> effort.
> >>>>>
> >>>>>
> >>>>> Thanks & Regards
> >>>>> --
> >>>>> Deepak Nigam
> >>>>> HotWax Sy

Re: Move accounting ap and ar to plugin ?

2018-09-03 Thread Taher Alkhateeb
Sounds good to me then. +1

On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin  wrote:

> Yeah thanks all for your constructive return :)
>
> I saw two specific features: commission invoicing and batch payment. As
> Sharan spot it, all functional process are present on the accounting
> component, I have the feeling that we are all agree on this idea with a
> attention to doesn't lost important part possibly hidden on AP/AR.
>
> Taher, I have two reasons to don't just delete them:
> * The code current works and seem to be easy to maintain
> * Load in official plugins an example on business screen who simplify
> generic screen with potential problem that can be raise by the split :)
>
> I will try to split it.
> Thanks
>
> Nicolas
>
>
> On 03/09/2018 13:07, Taher Alkhateeb wrote:
> > Very interesting thoughts Sharan, Jacopo and everyone.
> >
> > Thinking about this some more, and given that -- as I understood it --
> > the AP and AR are really nothing more than specialized filtration
> > screens of the general purpose screens in the accounting webapp, then
> > why not delete them? Are people depending on these screens? Is it
> > worth writing and maintaining a plugin for it?
> > On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
> >>
> >>
> >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin  >
> >>> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> After analyze the webapp accounting AR and accounting AP, I didn't see
> >>>> any logic to keep them on the functional framework. The main webapp is
> >>>> accounting, AP/AR are a business orientation that we can load at
> demand
> >>>> through plugins.
> >>>>
> >>>> Your opinion ?
> >>>>
> >>> As far as I remember, the AP/AR web applications were created as a
> >>> specialized versions of the user interfaces for some business processes
> >>> (account receivables and account payables related tasks) that were
> already
> >>> available in the more general "accounting" web application. I like the
> idea
> >>> to move them to plugins but, as mentioned by Taher, we should also
> verify
> >>> if there are specific features that are available only in the AP/AR
> version
> >>> and not in the "accounting" application: if we find some, then we
> should
> >>> migrate the basic artifacts to the main "accounting" app and then move
> the
> >>> specialized screens to plugins. I think such cases will be rare but one
> >>> possible candidate is the "batch payment" functionality of the AR app.
> >> I thought the batch payment was one of the options for the Payment
> Group which is on the main accounting menu so any processing can be done
> from there too.
> >>
> >> Thanks
> >> Sharan
> >>
> >>>
> >>>> PS: In the same idea we can move on separate plugin all thirdparty
> >>>> accounting element to slimdown the accounting component and must
> harness
> >>>> the plugin system :)
> >>>>
> >>> +1
> >>>
> >>> Jacopo
> >>>
> >>>
> >>>> Nicolas
> >>>>
> >>>>
>
>


Re: [QUESTION] Should we not check fields consistency?

2018-09-03 Thread Taher Alkhateeb
I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order? What if a user wants to be able to search
for a date range in the past, what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?

I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:
>
> It's only about checking at the root in UI when entering data and not let 
> things go as long as the value is not correct
>
> Jacques
>
>
> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
> > Well, it depends on where the cross checks happen. Are you talking
> > about UI? entity-auto? somewhere else?
> > On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  
> > wrote:
> >> +1.
> >>
> >> Thanks for the putting this forward. Please count me in for this effort.
> >>
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Nigam
> >> HotWax Systems Pvt. Ltd.
> >>
> >>
> >> On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
> >> 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I have always found that not having dates cross-checks in OFBiz is a 
> >>> minus.
> >>>
> >>> For instance while creating/editing an order we can enter
> >>>
> >>>* an anti-dated shipping date (eg 2018-08-1 entered today)
> >>>* The recently added reserved date can be after the shipping date
> >>>* etc. (not only dates but mostly)
> >>>
> >>> Should we not make an effort to check the consistency of fields values
> >>> when they are entered?
> >>>
> >>> Because this is a simple question to see if we agree about making an
> >>> effort on that, I don't get into more details yet
> >>>
> >>> Thanks for your opinions
> >>>
> >>> Jacques
> >>>
> >>>
>


Re: [QUESTION] Should we not check fields consistency?

2018-09-03 Thread Taher Alkhateeb
Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:
>
> +1.
>
> Thanks for the putting this forward. Please count me in for this effort.
>
>
> Thanks & Regards
> --
> Deepak Nigam
> HotWax Systems Pvt. Ltd.
>
>
> On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
> wrote:
>
> > Hi,
> >
> > I have always found that not having dates cross-checks in OFBiz is a minus.
> >
> > For instance while creating/editing an order we can enter
> >
> >   * an anti-dated shipping date (eg 2018-08-1 entered today)
> >   * The recently added reserved date can be after the shipping date
> >   * etc. (not only dates but mostly)
> >
> > Should we not make an effort to check the consistency of fields values
> > when they are entered?
> >
> > Because this is a simple question to see if we agree about making an
> > effort on that, I don't get into more details yet
> >
> > Thanks for your opinions
> >
> > Jacques
> >
> >


Re: Move accounting ap and ar to plugin ?

2018-09-03 Thread Taher Alkhateeb
Very interesting thoughts Sharan, Jacopo and everyone.

Thinking about this some more, and given that -- as I understood it --
the AP and AR are really nothing more than specialized filtration
screens of the general purpose screens in the accounting webapp, then
why not delete them? Are people depending on these screens? Is it
worth writing and maintaining a plugin for it?
On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
>
>
>
> On 2018/09/03 08:11:26, Jacopo Cappellato 
>  wrote:
> > On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
> > wrote:
> >
> > > Hello,
> > >
> > > After analyze the webapp accounting AR and accounting AP, I didn't see
> > > any logic to keep them on the functional framework. The main webapp is
> > > accounting, AP/AR are a business orientation that we can load at demand
> > > through plugins.
> > >
> > > Your opinion ?
> > >
> >
> > As far as I remember, the AP/AR web applications were created as a
> > specialized versions of the user interfaces for some business processes
> > (account receivables and account payables related tasks) that were already
> > available in the more general "accounting" web application. I like the idea
> > to move them to plugins but, as mentioned by Taher, we should also verify
> > if there are specific features that are available only in the AP/AR version
> > and not in the "accounting" application: if we find some, then we should
> > migrate the basic artifacts to the main "accounting" app and then move the
> > specialized screens to plugins. I think such cases will be rare but one
> > possible candidate is the "batch payment" functionality of the AR app.
>
> I thought the batch payment was one of the options for the Payment Group 
> which is on the main accounting menu so any processing can be done from there 
> too.
>
> Thanks
> Sharan
>
> >
> >
> > >
> > > PS: In the same idea we can move on separate plugin all thirdparty
> > > accounting element to slimdown the accounting component and must harness
> > > the plugin system :)
> > >
> >
> > +1
> >
> > Jacopo
> >
> >
> > >
> > > Nicolas
> > >
> > >
> >


Re: Move accounting ap and ar to plugin ?

2018-09-01 Thread Taher Alkhateeb
Hi Nicolas,

I'm not an expert accountant, but if I'm not mistaken then accounts
receivable and accounts payable are a fundamental accounting function
that comes with any accounting system, and perhaps the only reason we
notice them is because they are defined as separate webapps.

I have no strong opinion, but I would suggest perhaps an opposite
direction, as in integrating the the accounts receivable and payable
to the accounting component. I don't understand why they were
separated to different webapps in the first place.
On Sat, Sep 1, 2018 at 3:22 PM Jacques Le Roux
 wrote:
>
> That's a great idea Nicolas!
>
> +1
>
> Jacques
>
>
> Le 01/09/2018 à 14:09, Nicolas Malin a écrit :
> > Hello,
> >
> > After analyze the webapp accounting AR and accounting AP, I didn't see any 
> > logic to keep them on the functional framework. The main webapp is
> > accounting, AP/AR are a business orientation that we can load at demand 
> > through plugins.
> >
> > Your opinion ?
> >
> > PS: In the same idea we can move on separate plugin all thirdparty 
> > accounting element to slimdown the accounting component and must harness the
> > plugin system :)
> >
> > Nicolas
> >
>


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

2018-08-29 Thread Taher Alkhateeb
I couldn't find the testing mechanism and the JIRA is filled with too
much information. Sharing a simple testing mechanism would help
On Wed, Aug 29, 2018 at 12:33 PM Jacques Le Roux
 wrote:
>
> Hi Taher,
>
> Before creating the last patch, I have reviewed the code a last time again,  
> it's totally OK now. Did you test from
> https://localhost:8443/catalog/control/FindCatalog with the provided test 
> patch?
>
> I'll now provide a simple and concise AsciiDoc documentation. Maybe with a 
> graph, but that's not sure, I have to try...
>
> For the test part I'll wait for the user ML "OFBiz Sanity Test Automation" 
> thread https://markmail.org/message/nxoyqxn7lqfupf55 to conclude before
> endeavouring in web tests
>
> I don't think it should stop to commit this work, which can be tested 
> manually using the provided patches (though the one from example needs the
> commit to be done)
>
> Anyway I'll wait more feedbacks before committing, I'm not in a hurry and I 
> know it's a sensitive feature.
>
> Jacques
>
>
> Le 27/08/2018 à 14:55, Taher Alkhateeb a écrit :
> > I already found problems in this code to give me pause and to show
> > that it is not properly studied and designed. If you want to continue
> > the effort, then I recommend reviewing your code thoroughly, providing
> > a clear testing mechanism (especially the web scripts), and ask for
> > reviews and tests.
> > On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
> >  wrote:
> >> Hi Taher,
> >>
> >> Thanks for your review, much appreciated.
> >>
> >>
> >> Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :
> >>> I reviewed the code and explanation in the beginning of this thread
> >>> and I have the following comments:
> >>>
> >>> - First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
> >>> you are still returning "success". Does not make sense at all.
> >> You are right I should have used "error".
> >> I did not notice (actually forgot a last own review after much variations 
> >> in code) because it's an event preprocessor and no response is
> >> expected/handled.
> >> Not to bad, in case of error just an EventHandlerException was not thrown.
> >>
> >>> - Also the comments are unnecessary and do not make sense in the same 
> >>> code block
> >> You mean "// Something unexpected happened here", or ?
> >>
> >>> - The comment you wrote: "Check it's the right tenant in case username
> >>> and password are the same in different tenants. Not sure this is
> >>> really useful in the case of external server, does not hurt anyway" is
> >>> self-defeating. Never put in code you won't use. We have enough mess
> >>> in the code base.
> >> I must say I initially copied that from 
> >> ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the 
> >> context. It's roughly the same code.
> >> I let it there because I was then unsure. But when you think about it, 
> >> there is no reason to not make this check. So I'll simply remove the 
> >> comment. I
> >> should have put a TODO.
> >>
> >> BTW this is out of subject and I'll start a new thread about it after 
> >> reading
> >> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
> >> The subject will be: "Should we keep the multi-tenants feature in OFBiz."
> >> I though think the tenants in OFBiz are still useful when you only needs 
> >> dozens or maybe even few hundreds tenants (begin to be a lot of DBs!).
> >> But 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.
> >>
> >>> - Calling LoginWorker.doBasicLogin(userLogin, request) after the
> >>> if/else block does not make sense. The else block guarantees falling
> >>> into the exception. This whole code block needs refactoring
> >> You are totally right, I have uploaded a new patch where I put the call of
> >>   LoginWorker.doBasicLogin(userLogin, request);
> >> in the positive part of the if and used the same block pattern than above 
> >> where there is a warning log then returning an error.
> >> I was so focused on the other parts of the mechanism, especially to secure 
> >> it, than I forgot to review the Java part.
> >> My bad, thank you again for your review.
> >>
> >>> - A testing me

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

2018-08-29 Thread Taher Alkhateeb
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
>


Re: Gradle, Less, Css : Transpile and minify

2018-08-27 Thread Taher Alkhateeb
Can you elaborate on how you want to design this feature? Are you
going to minify the existing file or generate a new one. If you
generate a new one how will you update the screens to refer to the
minified version? Some elaboration on the design might help to make a
better decision here perhaps?
On Mon, Aug 27, 2018 at 3:20 PM Julien NICOLAS
 wrote:
>
> Yes ! This is exactly what I have in mind ;)
>
> Using this feature in production using Gulp, It's a pain when you have
> to debbug in minified version.
>
> Julien.
>
>
> Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :
> > Hello Julien,
> >
> > Julien NICOLAS  writes:
> >
> >> I would like to optimize css and less management using gradle.
> >> I saw that some gradle plugins exists for transpilation (or
> >> compilation...) less to css and minify and gzip css files.
> >>
> >> What do you think if I try to set it in trunk ? I saw that a minifier
> >> was already implemented in the past but was also removed. Is there any
> >> technical reasons to remove minifier ?
> > I think it is a good idea.  However if we do that, it will be very
> > important to have a convenient way to run OFBiz either in development
> > mode (without minification) and in production mode (with minification)
> > to ease the Javascript debugging.  Since this is a very common
> > requirement, I guess those Gradle plugins already provide such facility
> > or describe how to customize the impacted tasks.
> >
> > Thanks.
> >
>


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

2018-08-27 Thread Taher Alkhateeb
I already found problems in this code to give me pause and to show
that it is not properly studied and designed. If you want to continue
the effort, then I recommend reviewing your code thoroughly, providing
a clear testing mechanism (especially the web scripts), and ask for
reviews and tests.
On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
 wrote:
>
> Hi Taher,
>
> Thanks for your review, much appreciated.
>
>
> Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :
> > I reviewed the code and explanation in the beginning of this thread
> > and I have the following comments:
> >
> > - First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
> > you are still returning "success". Does not make sense at all.
> You are right I should have used "error".
> I did not notice (actually forgot a last own review after much variations in 
> code) because it's an event preprocessor and no response is
> expected/handled.
> Not to bad, in case of error just an EventHandlerException was not thrown.
>
> > - Also the comments are unnecessary and do not make sense in the same code 
> > block
> You mean "// Something unexpected happened here", or ?
>
> > - The comment you wrote: "Check it's the right tenant in case username
> > and password are the same in different tenants. Not sure this is
> > really useful in the case of external server, does not hurt anyway" is
> > self-defeating. Never put in code you won't use. We have enough mess
> > in the code base.
> I must say I initially copied that from 
> ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the 
> context. It's roughly the same code.
> I let it there because I was then unsure. But when you think about it, there 
> is no reason to not make this check. So I'll simply remove the comment. I
> should have put a TODO.
>
> BTW this is out of subject and I'll start a new thread about it after reading
> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
> The subject will be: "Should we keep the multi-tenants feature in OFBiz."
> I though think the tenants in OFBiz are still useful when you only needs 
> dozens or maybe even few hundreds tenants (begin to be a lot of DBs!).
> But 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.
>
> > - Calling LoginWorker.doBasicLogin(userLogin, request) after the
> > if/else block does not make sense. The else block guarantees falling
> > into the exception. This whole code block needs refactoring
> You are totally right, I have uploaded a new patch where I put the call of
>  LoginWorker.doBasicLogin(userLogin, request);
> in the positive part of the if and used the same block pattern than above 
> where there is a warning log then returning an error.
> I was so focused on the other parts of the mechanism, especially to secure 
> it, than I forgot to review the Java part.
> My bad, thank you again for your review.
>
> > - A testing method needs to be provided in detail. For example I'm not
> > sure how the Javascript portions will execute and when. So some
> > provision of a clear testing mechanism is necessary.
> Yep, right, I'll document all the mechanism and how to use it. Pierre even 
> proposed to make a graph in AsciiDoc, not sure I'll be able to, by I'll try.
> Actually it's only a matter of following what should be in the example 
> component, see last OFBIZ-10307-test from example.patch.
> I thought it would be enough for devs. I understand it's not, a bit of clear 
> documentation is always welcomed, and I often advocate for it.
>
> > - Finally, I'm not sure this feature is needed at all. Why not just
> > assign an LDAP server to take care of OFBiz and non-OFBiz in a single
> > sign-on environment.
> Because you don't need to have (install, maintain, etc.) a LDAP server, or 
> whatnot (CAS, Oauth2, SAML, you name it) if you use this code, it's ready 
> OOTB.
>
> >   I see too much code being written for something
> > that might not be of great value and there are other better solutions
> > out there.
> Which ones do you think about? And why they are better at doing this specific 
> feature?
>
> > Using JWT tokens might come with problems [1] that need to
> > be justified before we adopt it.
> That's very interesting, let's check, after reading 
> https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities
>
>  1. Never let the JWT header alone drive verification
>   * Not our case, we have the loginUserId ciphered in and checked. The 
> crucial point was how to send the loginU

Re: Old demo restarted

2018-08-26 Thread Taher Alkhateeb
VisualVM is a desktop application, JMX is a specification and set of
libraries / specs. So I think both are not suitable. I'm not going to
read through your email with all these links as that's confusing and
boring.

You asked for my help, and now you're again participating in this
thread (the most!) and pushing your own opinion. Why did you ask me to
take on this task when you cut through with all these suggestions. If
you already have the time as you mentioned then I recommend not to
drag me into initiatives and waste my time.
On Sun, Aug 26, 2018 at 12:56 PM Jacques Le Roux
 wrote:
>
> Thanks Taher,
>
> Why did you not consider VisualVM and JMX (apart that it would be more work)?
>
> Do we need a complex tool to do this task (report alerts, allow simple 
> post-mortem)? Have you something else in mind?
>
> Also, as I said at https://markmail.org/message/byu2ivjn7wckayzz
>
> After using Eclipse Mat, I have used https://www.yourkit.com/ in the past 
> after reading
> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
>  from Mark Thomas https://whimsy4.apache.org/roster/committer/markt
>
> It's really the most complete tool I used then, I guess it's still. I checked 
> committers can still ask for a free license:
> https://www.yourkit.com/purchase/#os_license
>
> So that's how I worked so far: I waited for an alert (sometimes none in 
> months, sometimes several in a week) and then got to the VM to analyse the
> dump with the YourKit Java Profiler.
>
> As you certainly understood I'm especially asking for help doing something 
> similar. Not much because I don't want to do it, or I'm too busy, but
> because we need to share, not the burden, but the role.
>
> Jacques
>
> Le 25/08/2018 à 13:46, Taher Alkhateeb a écrit :
> > I did a little bit of research and although there are many solutions
> > out there, the top two I shortlisted to based on many criteria
> > (community, plugins, eco-system, features) are zabbix and nagios, and
> > I list below the pros and cons from my perspective.
> >
> > Given that our needs are not too complex, I find my self leaning
> > slightly towards zabbix.
> >
> > # nagios pros
> > - mature and battle tested
> > - massive plugin collection
> > - highly customizable
> > - Configuration can be stored in a revision system (config files)
> > - No database, simpler
> >
> > # nagios cons
> > - steep learning curve (everything is a config file)
> > - The web interface is limited
> > - because of the huge eco-system some plugins are abandoned or not
> > well maintained
> > - community is a bit fragmented with many forks out there (e.g. icinga, etc 
> > ...)
> >
> > # zabbix pros
> > - Powerful web interface
> > - Excellent template system that makes complex flows
> > - Easy to deploy and configure
> > - Easy to learn and use
> > - More functionality OOTB
> >
> > # zabbix cons
> > - More complex architecture with a database backend
> > - Less customizable
> > - Smaller community and eco-system, plugins not as numerous
> >
> > On Sat, Aug 25, 2018 at 12:30 PM Jacques Le Roux
> >  wrote:
> >> Mind you, I already asked when the infra stopped providing it. Then Daniel 
> >> (Gruno) told me I could use the free tool his company provided. I used that
> >> for months, but it's now discontinued. So I had to find the one which 
> >> suited me best and I explained that at the start of this thread.
> >>
> >> The problem for me is how to share the burden and especially have more 
> >> brains around it. It's years I handle the demos alone...
> >>
> >> Jacques
> >>
> >> Le 25/08/2018 à 11:07, Pierre Smits a écrit :
> >>> Since we're talking about our demo instances on the infrastructure of the
> >>> ASF I suggest getting in touch with INFRA and work out a solution with 
> >>> them
> >>> that favours both parties. They surely will have monitoring solutions in
> >>> place and can advice on what is achievable.
> >>>
> >>>
> >>>
> >>> 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

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

2018-08-25 Thread 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 p

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

2018-08-25 Thread Taher Alkhateeb
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 value is being added with the same key (in this
> example, first Cancelled status is put in this Map and then Declined), only
> Declined status is put in this Map.
>
> Hope, this clears the confusion. I will be happy to provide more
> information if needed.
>
> On Fri, Aug 24, 2018 at 1:46 PM Taher Alkhateeb 
> wrote:
>
> > Not enough information. What happens exactly? What is the bug? What do you
> > mean by it does not let us do that?
> >
> > On Fri, Aug 24, 2018, 11:09 AM Ritesh Kumar <
> > ritesh.ku...@hotwaxsystems.com>
> > wrote:
> >
> > > Hello Taher,
> > >
> > > Changing form method to GET is just to make the query parameters visible
> > in
> > > the URL so that a user is able to bookmark or share it. Using the POST
> > > method does not let us do that.
> > >
> > > On Fri, Aug 24, 2018 at 11:54 AM Taher Alkhateeb <
> > > slidingfilame...@gmail.com>
> > > wrote:
> > >
> > > > Why did you change the method to GET?
> > > >
> > > > On Fri, Aug 24, 2018, 9:20 AM Ritesh Kumar <
> > > ritesh.ku...@hotwaxsystems.com
> > > > >
> > > > wrote:
> > > >
> > > > > Just to put my point more clearly, let me add the steps to generate
> > the
> > > > > above-mentioned case. Please refer demo-trunk
> > > > > <https://demo-trunk.ofbiz.apache.org/webtools/control/main>.
> > > > >
> > > > > 1. Open this link, FindWorkEffort
> > > > > <
> > https://demo-trunk.ofbiz.apache.org/workeffort/control/FindWorkEffort
> > > >.
> > > > > Find Work Effort screen will be rendered.
> > > > > 2. Inspect and change the form method to "GET".
> > > > > 3. Apply any of the two statuses (say, Cancelled and Declined). Click
> > > on
> > > > > Find.
> > > > > 4. Records will be fetched according to the applied filters.
> > > > > 5. Check the URL. Cancelled and Declined statuses must be there in
> > the
> > > > URL.
> > > > > 6. Bookmark this page and log out.
> > > > > 7. Now, open the bookmark.
> > > > > 8. The login page will be rendered. Check the URL here. It will be
> > the
> > > > same
> > > > > as it was when the page was being bookmarked.
> > > > > 9. Type in the credentials and log in.
> > > > > 10. The result may be different. Check the URL. One of the statuses
> > is
> > > > > gone.
> > > > >
> > > > > Due to b

Re: Old demo restarted

2018-08-25 Thread Taher Alkhateeb
I did a little bit of research and although there are many solutions
out there, the top two I shortlisted to based on many criteria
(community, plugins, eco-system, features) are zabbix and nagios, and
I list below the pros and cons from my perspective.

Given that our needs are not too complex, I find my self leaning
slightly towards zabbix.

# nagios pros
- mature and battle tested
- massive plugin collection
- highly customizable
- Configuration can be stored in a revision system (config files)
- No database, simpler

# nagios cons
- steep learning curve (everything is a config file)
- The web interface is limited
- because of the huge eco-system some plugins are abandoned or not
well maintained
- community is a bit fragmented with many forks out there (e.g. icinga, etc ...)

# zabbix pros
- Powerful web interface
- Excellent template system that makes complex flows
- Easy to deploy and configure
- Easy to learn and use
- More functionality OOTB

# zabbix cons
- More complex architecture with a database backend
- Less customizable
- Smaller community and eco-system, plugins not as numerous

On Sat, Aug 25, 2018 at 12:30 PM Jacques Le Roux
 wrote:
>
> Mind you, I already asked when the infra stopped providing it. Then Daniel 
> (Gruno) told me I could use the free tool his company provided. I used that
> for months, but it's now discontinued. So I had to find the one which suited 
> me best and I explained that at the start of this thread.
>
> The problem for me is how to share the burden and especially have more brains 
> around it. It's years I handle the demos alone...
>
> Jacques
>
> Le 25/08/2018 à 11:07, Pierre Smits a écrit :
> > Since we're talking about our demo instances on the infrastructure of the
> > ASF I suggest getting in touch with INFRA and work out a solution with them
> > that favours both parties. They surely will have monitoring solutions in
> > place and can advice on what is achievable.
> >
> >
> >
> > 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 Fri, Aug 24, 2018 at 4:36 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Agreed, I have used VisualVMin the past, it's a simple and efficient tool
> >>
> >> I have planned to make a VOTE about options if needed. Let's see if it
> >> will be necessary (consensus being preferred)
> >>
> >> Jacques
> >>
> >>
> >> Le 24/08/2018 à 16:06, Girish Vasmatkar a écrit :
> >>> Speaking of monitoring tools and if we don't want to go for third party
> >>> tools, we can also use VisualVM that comes bundled with Oracle JDK. It
> >> can
> >>> connect to the remote VM (OFBiz process) and start displaying various
> >>> information.
> >>>
> >>> Very minimal configuration is needed in the form of VM argument to allow
> >>> for remote monitoring. Also, to enable further analysis of what went
> >> wrong,
> >>> why JVM crashed etc, we should also dump heap as the JVM shuts down.
> >>>
> >>> Too many ways and too many options. Probably need to reach a unanimous
> >>> decision, IMO.
> >>>
> >>> Thanks and Best regards,
> >>> Girish Vasmatkar
> >>>
> >>> On Fri, Aug 24, 2018 at 4:56 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> Thanks Michael,
> >>>>
> >>>> Best idea so far!
> >>>>
> >>>> Jacques
> >>>>
> >>>>
> >>>> Le 24/08/2018 à 11:08, Michael Brohl a écrit :
> >>>>> 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
> &g

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

2018-08-24 Thread Taher Alkhateeb
Not enough information. What happens exactly? What is the bug? What do you
mean by it does not let us do that?

On Fri, Aug 24, 2018, 11:09 AM Ritesh Kumar 
wrote:

> Hello Taher,
>
> Changing form method to GET is just to make the query parameters visible in
> the URL so that a user is able to bookmark or share it. Using the POST
> method does not let us do that.
>
> On Fri, Aug 24, 2018 at 11:54 AM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > Why did you change the method to GET?
> >
> > On Fri, Aug 24, 2018, 9:20 AM Ritesh Kumar <
> ritesh.ku...@hotwaxsystems.com
> > >
> > wrote:
> >
> > > Just to put my point more clearly, let me add the steps to generate the
> > > above-mentioned case. Please refer demo-trunk
> > > <https://demo-trunk.ofbiz.apache.org/webtools/control/main>.
> > >
> > > 1. Open this link, FindWorkEffort
> > > <https://demo-trunk.ofbiz.apache.org/workeffort/control/FindWorkEffort
> >.
> > > Find Work Effort screen will be rendered.
> > > 2. Inspect and change the form method to "GET".
> > > 3. Apply any of the two statuses (say, Cancelled and Declined). Click
> on
> > > Find.
> > > 4. Records will be fetched according to the applied filters.
> > > 5. Check the URL. Cancelled and Declined statuses must be there in the
> > URL.
> > > 6. Bookmark this page and log out.
> > > 7. Now, open the bookmark.
> > > 8. The login page will be rendered. Check the URL here. It will be the
> > same
> > > as it was when the page was being bookmarked.
> > > 9. Type in the credentials and log in.
> > > 10. The result may be different. Check the URL. One of the statuses is
> > > gone.
> > >
> > > Due to business requirement, I need to show query parameters in the URL
> > so
> > > that the user is able to bookmark the page. And, we normally pass Id in
> > the
> > > parameters, but, due to some reason, I may have to pass values with
> space
> > > characters.
> > >
> > > I hope, this demo puts forth my concern.
> > >
> > >
> > >
> > > On Thu, Aug 23, 2018 at 6:27 PM Ritesh Kumar <
> > > ritesh.ku...@hotwaxsystems.com>
> > > wrote:
> > >
> > > > Hello All,
> > > >
> > > > I faced an issue while trying to open a bookmarked page with OFBiz.
> > > >
> > > > Suppose, the URL of this bookmarked page contains a parameter with
> > > > multiple values and the value may have space character. The query
> > string
> > > in
> > > > the URL looks somewhat like this
> > > >
> > > >
> > >
> >
> "?categoryHierarchy=3%2FCompany+Catalog%2FBrowse+Root%2FCloths%2FMen%2F"=approved=created".
> > > > The "%2F" and "+" are encoded value of  "/", a separator and space
> > > > character respectively. The status id parameter appears twice and the
> > > > category hierarchy value has space character.
> > > >
> > > > The user is logged out at this instance and this bookmarked page is
> > > > opened. Since the user is not logged in, the login page is rendered.
> I
> > > feed
> > > > in the credentials and the intended URL is hit. Here, I do not get
> the
> > > > required result.
> > > >
> > > > When I check the URL, the parameter with multiple values just has the
> > > last
> > > > value of the list and "+" is encoded into "%2B". The URL now is
> > > >
> > > >
> > >
> >
> "?categoryHierarchy=3%2FCompany%2BCatalog%2FBrowse%2BRoot%2FCloths%2FMen%2F"==created."
> > > >
> > > > I did some digging and found out that LoginWorker.checkLogin() comes
> > into
> > > > action and what it does is that it creates a new session object
> > (because
> > > > the previous session becomes invalid) and in the session object, it
> > puts
> > > > the previous URL parameters. This previous URL parameters are fetched
> > > using
> > > > UtilHttp.getUrlOnlyParameterMap(request) which internally calls
> > > > getQueryStringOnlyParameterMap(). This method returns a map by
> breaking
> > > the
> > > > query string into key and value pair. A map can not have duplicate
> keys
> > > (in
> > > > this case removes the approved status) and the value is not decoded
> > > before
> > > > putting it into the map ('+' is not decoded). This map is then used
> to
> > > > create an encoded ('+' is encoded into '%2B' ) redirect target and
> then
> > > > callRedirect() is called on this new redirect target, ending up with
> > > > unintended URL (inside RequestHandler.doRequest()).
> > > >
> > > > I could resolve this issue by decoding the already encoded value
> before
> > > > putting it into the Map and if the key is already present in the Map,
> > it
> > > > must create a list of the values.
> > > >
> > > > Am I missing something or is this really a bug and needs to be
> > addressed
> > > > OOTB?
> > > > If this is a bug, is proposed solution the right one?
> > > >
> > > > --
> > > > Best,
> > > > Ritesh Kumar
> > > >
> > > >
> > >
> >
>


Re: Old demo restarted

2018-08-24 Thread 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, then it can also be worth it's salt. Yes, CRON will be

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

2018-08-24 Thread Taher Alkhateeb
I have just reviewed the links again, and the example provided by Jacques
is to access the ecommerce product page from the product component as a
menu item.

Honestly, I think for this example it should simply be deleted. It serves
no substantial value to me:

- I most likely will not use the standard ecommerce component
- I can easily view all the products directly from the ecommerce component.
There is no terrible need to access it from the product component.
- It does not even make sense to access the product page from the product
component. The purpose of the product component is to define and control
products, not view their ecommerce pages, heck you might have them on an
external system all together.

Furthermore, I'm not sure we need another superman initiative in the widget
system? The price to pay for this does not seem to be worth the added
value, I would hardly call it a value but maybe I'm wrong?

On Aug 24, 2018 9:55 AM, "Julien NICOLAS"  wrote:

Hi Nicolas,

With your proposal, I'm afraid that we can't simply add a new menu in an
application from a plugin. Maybe it's another subject but it could be
interesting to manage it in the same times.

Technically I understand your proposal but it's difficult for me to
understand the impact ^^

Julien.



Le 23/08/2018 à 11:19, Nicolas Malin a écrit :
> Hello
>
> This thread about a "simple" problem highlights the difficulty for a
> plugin to extend the framework on different elements. Since many years
> I search different solution to how surcharge correctly the framework
> and it was not easy :)
>
> in line
>
> On 22/08/2018 18:52, Taher Alkhateeb wrote:
>> Hi Julien,
>>
>> Good ideas, and this is a good start to try and tackle the problem.
>> Whatever we do, we must not keep "ghosts" or things that are waiting
>> for specific outside plugins. The framework should _never_ know
>> anything about the outside. This is a fundamental architectural
>> concept in any layered software system.
> Absolutely right, I knew a ghost history with addons that changed
> source code base to load plugin's specificsinstead of understandingwhy
> we can't surcharge the framework :)
>> I'm ready to help if needed, and I think there are many ways to fix
>> this problem. As you said one way is to extend webapps, another is
>> perhaps to optionally include freemarker templates that match a
>> certain pattern if they exist. In other words, you provide a generic
>> plugin-like mechanism for enhancing the system, but the direction is
>> _always_ from the outside to the inside, and not the other way around.
>> And that is what I mean with a root-cause analysis and solutions.
>
> Maybe I have two different solutions, based on theidea to usethemodel
> pattern toload all plugin surcharge at the ofbiz start like services
> and entities
> * The first, load all screen engine modelsin memory at start, but I
> fearthatit would be too expensive on memory (load unnecessary screens)

> * The second, create an'extend model' who permit to surcharge all
> screen engine model elements,andload it on ofbiz start and when we
> load a model, we check on extend model if the element have surcharge
> to apply just before settingit as immutable and put it in cache.

>
> example :
>  name='ViewPartyGroup'>
> 
>  target="/myplugin/control/viewprofile" target-type="inter-app"
> target-window="blank_">
> 
> 
> 
> 
>
> With this, we would have a plugin that can surcharge a screen, a form,
> a menu without changingnothing in the framework, identify clearly what
> change has been made and a failure support when the extend can't be
> applied.
>
> Currently I didn't found a solution to surcharge ftl.
>
> If you feel that it's a good way to explore, I will start a new thread.
>
> Nicolas
>> So I'm all for a generic solution, but not for hard-wiring any
>> component or any link that is specific to a certain component. That is
>> definitely a code smell and beats the entire purpose of splitting the
>> repositories in the first place. [...]
>
>


  1   2   3   4   5   6   7   8   9   10   >