Checkout Tools
  • last updated 1 hour ago
Constraints: committers
Constraints: files
Constraints: dates
Improved: Upgrade Tomcat from 9.0.26 to 9.0.27


Update to Commons Daemon 1.2.2 to pick up the fix for a regression in Commons

Daemon 1.2.0 and 1.2.1 that triggered a crash on startup when running on a

Windows OS that had not been fully updated.

That's where you see how the Tomcat team takes care of their users :)

Improved: Update build.gradle to the latest dependencies


  1. … 1 more file in changeset.
Reverted: JSON entity data import and export utility


Implementation was not matching OFBiz code quality requirements.

  1. … 17 more files in changeset.
Improved: Don't exclude properties and labels file from the Jar


In order to have an independent deployable jar, we need to include the

properties and labels inside the jar.

The properties and labels file was previously excluded from the jar

because it was not possible to replace the compile time values by

invalidating OFBiz caches which is convenient when developing

OFBiz. It was then necessary to reconstruct the jar and restart

OFBiz (See OFBIZ-8321 for more details).

With the recent improvment from revision 1865719 allowing to run OFBiz

without building a jar, it is now possible to enable this cache

invalidation by running both ‘gradle run’ in one shell and ‘gradlew

--continuous classes’ in a separate shell. Doing so make the

combination of editing the label files and clearing the caches use

the new value defined in the source file.

Fixed: Any ecommerce user has the ability to reset anothers password

(including admin) via "Forget Your Password"


Currently, any user (via ecommerce "Forget Your Password") has the ability to

reset another users password, including "admin" without permission.

By simply entering "admin" and clicking "Email Password", the following is


The following occurred:

A new password has been created and sent to you. Please check your Email.

This now forces the user of the ERP to change their password.

It is also possible to generate a dictionary attack against ofbiz because there

is no capta code required. This is serious security risk.

I have modified the patch following comments I made in the Jira, notably

Removed unused Java variables

Removed a check in LoginEvents::forgotPassword which prevented to show error


Changed fr and en SecurityExtPasswordSentToYou

+ SecurityExtThisEmailIsInResponseToYourRequestToHave labels

+ template PasswordEmail.ftl

+ loginservices.token_incorrect labels

Added fr and en SecurityExtIgnoreEmail + SecurityExtLinkOnce labels

Removed changes in

I did not remove the 2 GetSecurityQuestion.ftl files (webpos one was still in)

There is still room for improvement. I'll discuss them on the Jira and dev

ML. But this version is already strong enough to not wait that the patch is


Thanks: mz4wheeler (Mike Z) for the Jira, Nicolas Malin for the patch, I guess

with some Gil's help, and all others for comments and ideas

  1. … 22 more files in changeset.
Fixed: Classpath too long on Windows


Due to OFBIZ-11161 the classpath is now too long on Windows.

This is a known issue and can be fixed using

It's also useful when looking for OFBiz processes on Linux.

Else you get very long results

Improved: Update Freemarker to 2.3.29


Tests and UI are OK

  1. … 1 more file in changeset.
Improved: Make ‘gradlew’ depend on :jar and :test


The default task was previously depending on :build which was requiring to

mess with the dependency graph in order to avoid executing the :distTar and

:distZip tasks which are too big to be executed by default.

It is cleaner to simply define the default tasks to :jar and :test.

Improved: Make ‘gradlew ofbiz’ depend on :classes instead of :build


It is not necessary to build the jar to run OFBiz. It is only

necessary to compile the classes in the build directory. This adapts

‘gradlew ofbiz’ to have the same dependencies as ‘gradlew run’.

Improved: Separate resources from Java source files


This moves the resource files in a dedicated "src/main/resources"

directory. This convention follows the Maven standard directory

layout which is the convention used by default in Gradle.

  1. … 50 more files in changeset.
Improved: Update build.gradle to the latest dependencies


Like for OFBIZ-10922 some updates were not possible. Please refer to the Jira

for more information

  1. … 7 more files in changeset.
Improved: Upgrade Hamcrest library to version 2.1


Improved: Remove unnecessary dependency on ‘junit-dep’ artifact


Prior to Junit 4.11, Junit was distributed in two forms ‘junit’ and

‘junit-dep’ where the first was embedding the hamcrest matchers the

second was defining a dependency to it which is more desirable in the

context of package managers like Maven or Gradle. Starting with Junit

4.11 only the second form is distributed which makes ‘junit-dep’


Fixed: All local XML schema files are now present in classpath


Previously there was some warnings about missing “.xsd” files that

‘UtilXml#resolveEntity’ failed to find in classpath. This has been

fixed by declaring all “dtd” directories inside components as resources.

Implemented: JSON entity data import and export utility


Currently, we support import/export entity data in XML format.

Nowadays JSON is widely used in industry, we can have support for JSON format

which looks quite similar to XML support.

Here is example of XML data and it's JSON version

<Party partyId="123456" partyTypeId="PERSON" statusId="PARTY_ENABLED"/>

{“Party”: {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}

Design Proposal

We can write entityImportJson and entityImportDirJson services for importing

JSON from screen and directory respectively.

And the entityExportAllJson service for exporting entity data in JSON.

Import Design

The import service will perform following operations:

1.) Validate the input JSON data

2.) On successful validation, convert JSON to OFBiz's entity model


3.) The GenericValue will be inserted in database by some handler class for e.g

we can write JsonDataHandler, it will convert given JSON to

List<GenericValue>, and finally write it to database

(Similar pattern is used in XML import).

Export Design

Based on existing XML pattern the writeXmlText method of GenericEntity class

write the exported data in XML format.

In the similar way, we can implement writeJsonText to export data in JSON format.

jleroux: I fixed 2 trivials things and at my request in last patch Jayansh added

"JSON Data Export All" and "JSON Data Import Dir

Thanks: Jayansh Shinde

  1. … 17 more files in changeset.
Improved: Removed old pattern directory for groovy scripts.


Thanks Deepak Dixit for reporting.

Improved: Made Gradle createPlugin task reflect the actual file/folder structure.


Modified Gradle createPlugin task to reflect the groovyScripts and minilang directory instead old script directory.

Thanks, Michael Brohl for reporting.

Improved: Update Tomcat to 9.0.21


Mostly because of various concurrency and stability fixes for HTTP/2 as reported

in the official announcement

Fixed: Gradle eclipse task - classpath modification (Add exclusion for

<OFBiz>/framework/base/config and <OFBiz>/framework/base/dtd)


Eclipse task removes all classpath entries that affects following entries also -

* <OFBiz>/framework/base/config

* <OFBiz>/framework/base/dtd

These two entries are essential to start OFBiz successfully.

Developer has to manually add these entries back to start OFBiz from IDE.

Following this discussion:

Thanks: Girish Vasmatkar

Fixed: Services allow arbitrary HTML for parameters with allow-html set to "safe"


The testCreateNewRequest was failing due to escaped single quotes in related

data in OrderTypeData.xml:

subject="OFBiz - Your Request is received: '${custRequestName}' #CR${custRequestId}"

This was a peculiar case that could be generalised to all escapable characters.

The general solution is to compare the original value with the filtered value

unescaped in UtilCodec::checkStringForHtmlSafe.

BTW, weirdly enough StringEscapeUtils::escapeHtml4 does not escape single quote.

Another weirdness is the test was passing with plugins data loaded. This is due

to duplicated demo data in scrumTypeData.xml (which is actually not only type

data, as ever the scrum component is a mess, that's not new and always wonder

if we should not get rid of it!)

  1. … 1 more file in changeset.
Improved: Update build.gradle to the latest dependencies


Completes the previous commits, that will be it. I'll explain in the Jira...

Improved: Update build.gradle to the latest dependencies


Something went wrong with r1857590 and reverted Tomcat to 9.0.17

Back to 9.0.19 with this commit

Improved: Update build.gradle to the latest dependencies


At Ben Manes suggests to

have a look at few Gradle plugins which depends on his own plugin.

I checked and there is one which is interesting:

It does much of the work you would have to do manually when updating libs.

Beware though that this is only a help. If you use it without check you will

need to check things by yourself (can be as tedious as not using this plugin)

Improved: Update build.gradle to the latest dependencies


Some updates were not possible, I'll detail later which ones and why due to

OFBIZ-10913 waiting for an improvement

Please refer to the Jira for more information

Fixed: Update Tomcat to 9.0.18 due to CVE-2019-0232


CVE-2019-0232 Apache Tomcat Remote Code Execution on Windows

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

Apache Tomcat 9.0.0.M1 to 9.0.17

Apache Tomcat 8.5.0 to 8.5.39

Apache Tomcat 7.0.0 to 7.0.93


When running on Windows with enableCmdLineArguments enabled, the CGI

Servlet is vulnerable to Remote Code Execution due to a bug in the way

the JRE passes command line arguments to Windows. The CGI Servlet is

disabled by default. The CGI option enableCmdLineArguments is disabled

by default in Tomcat 9.0.x (and will be disabled by default in all

versions in response to this vulnerability). For a detailed explanation

of the JRE behaviour, see Markus Wulftange's blog [1] and this archived

MSDN blog [2].


Users of affected versions should apply one of the following mitigations:

- Ensure the CGI Servlet initialisation parameter enableCmdLineArguments

is set to false

- Upgrade to Apache Tomcat 9.0.18 or later when released

- Upgrade to Apache Tomcat 8.5.40 or later when released

- Upgrade to Apache Tomcat 7.0.93 or later when released

This announcement is being made before the releases are available as the

change to fix this issue is obviously security related.


This issue was identified by an external security researcher and

reported to the Apache Tomcat security team via the bug bounty program

sponsored by the EU FOSSA-2 project.

jleroux: actually Tomcat 9.0.19 was released, here it is

  1. … 1 more file in changeset.
Fixed: ‘./gradlew generateOfbizDocumentation’ fails with Gradle 5.0


This definitely fixes the problem in trunk

Fixed: Update Tomcat to 9.0.16 due to CVE-2019-0199


The HTTP/2 implementation accepted streams with excessive numbers of

SETTINGS frames and also permitted clients to keep streams open without

reading/writing request/response data. By keeping streams open for

requests that utilised the Servlet API's blocking I/O, clients were able

to cause server-side threads to block eventually leading to thread

exhaustion and a DoS.

  1. … 1 more file in changeset.
Improved: Rewrite ‘getJarManifestClasspathForCurrentOs’ (OFBIZ-10872)

Simplify the code logic and rename it ‘getJarClasspath’.

Improved: Do not use deprecated Gradle dependency types (OFBIZ-10871)

The ‘compile’, ‘testCompile’ and ‘runtime’ dependency types has been

superseded by ‘implementation’, ‘testImplementation’ and ‘runtimeOnly’

in recent Gradle versions [1].

The ‘runtimeClasspath’ property from the configurations is now used to

define the classpath in the jar manifest.


Improved: Add ‘:distTar’ and ‘:distZip’ gradle tasks (OFBIZ-10866)

Gradle provides some useful standard plugins for packaging

applications via the ‘distribution’ and ‘application’ plugins.

* The ‘distribution’ plugin [1] is providing a straightforward and

easy way to distribute OFBiz with its dependencies which is

convenient in a deployment context. This is achieved by the new

‘distTar’ and ‘distZip’ tasks.

* The ‘application’ plugin [2] is complementing the ‘distribution’

plugin by adding both a robust shell script and a batch script

inside the distribution archives to allow launching OFBiz easily.



Thanks to Antoine Ouvrard for contributing to this work.

  1. … 1 more file in changeset.