Hi Markus,

thank you for your interest in Apache OFBiz and welcome to the community!

This is definetely an interesting contribution and we would be happy to review your work.

I suggest to create a Jira issue explaining your thoughts and solution. You can apply code via patch files against trunk to enable the community to review and test.

Thanks again and have fun,


Am 01.12.16 um 12:58 schrieb of...@mk-multimedia.de:
Hi all,

my name is Markus Küspert and I am a software developer from Germany that writes mainly J2EE applications. I found the OFBiz project some months ago on the Internet and really like it.

I also followed your discussion about defining an OFBiz project strategy. For me one of the main disadvantages of the project is the lack of using modern standards. OFBiz is a complex software that is to be used in a complex environment. In my opinion there is no "user" that downloads the software and starts using it because a "user" knows how to do its work and not setting up a complex software. I think there always has to be a software solutions company that wants to use OFBiz for their customers. But such a company focuses on using standards and well known design patterns to get things done in a reasonable time (see http://stackoverflow.com/q/5862995/5223047). And without such companies there are no users. The classloader mechanism that was used in previous releases was a bad example for reinventing the wheel and making things unneccessary complex. The current "trunk" version of the project is much cleaner, less complicated and a huge improvement! But there is still a lot of code that is used to write a framework (e.g. caching, transaction handling, web service interfaces) that already exists or could be realised much easier with a (full) J2EE application server. By using existing standards all developers could focus on the business logic for the ERP system.

I am interested in contributing code and I think I can write a drop in replacement for the current delegator that uses the Java Persistence API (JPA) instead. The reasons for doing this are:

- Mature and standard library that does the cache and entity persistence handling - By using JPA entities the code becomes much more typesafe because there are either named queries that are automatically checked for correct field names or the criteria API that automatically generates a metamodel that can be used for queries. Existing modules can still use the current query style (and can be rewritten step by step) but new modules can use the power and type safety of JPA named queries or the criteria API. - Creating RESTful webservice without writing code (see https://docs.oracle.com/middleware/1212/toplink/TLADG/restful_jpa.htm)
- Another step to move the project to a modern J2EE application.

Are you interested?


Markus Küspert

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to