Why A Framework Rewrite Is Necessary

[Adrian Crum-3]

I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further action
on this subject, because I've brought it up before without success, and
I'm tired of discussing it. It is my hope that the light bulb will click
on in someone's head and they will take action.

My Background
-------------

I became a member of the OFBiz community in 2004. I immediately started
making contributions to the project by supplying patches to the issue
tracker. In 2007, I became a committer. Most of my initial work was on
the UI and some work in the applications (mainly Asset Maintenance and
Work Effort). I stayed away from touching the framework code because it
was deep, dark, and scary.

Eventually, I started to understand how the framework code works and I
made some minor modifications. As my understanding grew, I progressed to
rewriting large swaths of framework code - making it thread-safe, fault
tolerant, efficient, and easier to use.

I will list some of my contributions here, so everyone can have a clear
understanding of my experience with the framework code:

     New Features

         User Preferences

         Visual Themes

         Custom UI Label XML File Format

         Temporal Expressions

         Data Type Conversion Framework

         Screen Widget Boundary Comments

         Metrics

     Integrations

         UEL

         iCalendar

         JSR 223

         WebDAV

         LDAP

     Refactorings/Improvements

         FlexibleStringExpander

         FlexibleMapExpander

         FOP Integration

         FreeMarkerWorker

         Date-Time Handling

         Mini-language

         Job Scheduler

In addition, I have performed innumerable framework bug fixes.

So, the contents of this message come from years of experience mucking
about in the framework code.

Okay, let's get started...

Initial Problem Statement
-------------------------

In 2009, David Jones started a framework rewrite in a branch:

https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716

At the time, there was some agreement that a rewrite was necessary, but
there was disagreement as to how the rewrite should be incorporated into
the project:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E

There were concerns that a rewrite would break backward compatibility.
Work on the rewrite branch stopped. Eventually, Jacopo suggested the
community be more accepting of backward-incompatible changes:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e

Despite an effort to convince David to proceed with the framework
rewrite, he ended up doing it in a separate project:

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E

This page describes differences between OFBiz and Moqui, and within it
you can extract information on the problems David was trying to solve:

http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/

There was an email he sent out on the OFBiz dev list where he listed the
problems he saw in the framework, but I can't find it. The rest of this
message will include the issues he mentioned (the ones I remember). I
was in agreement with him at the time, and I still agree that a
framework rewrite is necessary.

The Problems
------------

Code is scattered everywhere - due to an initial effort to make the
framework modular. This causes serious problems. The mere fact that
components like entityext and securityext EXIST makes it clear that
there are problems - those components should not be there. Also, we run
into the recurring problem of circular dependencies (component A will
not build unless component B is built, and component B will not build
unless component A is built).

Bad separation of concerns. There are far too many examples of classes
that try to be everything to everyone. This makes debugging difficult,
and it makes maintenance/improvements a nightmare. [Using an analogy,
consider an automobile design where a spark plug is not separate from a
transmission. Instead, the automobile uses a spark-plug-transmission. So
when the engine is running rough because the spark plug is bad, you have
to replace the spark plug AND the transmission.] A good framework
example can be found in my rewrite of the mini-language code.
Originally, the models AND the script execution context both contained
script behaviors - making debugging/improvements difficult. I changed it
so only the models contain script behavior and the script execution
context contains only the script execution state.

Lack of good OO design. There are many places where a bit of framework
functionality is contained in a single method that is hundreds or
thousands of lines long. There is a term for that: Brittle Code. Code
isn't reused. Instead, it is copy-and-pasted all over - so when a
problem is found in the C&P code, it has to be fixed in many places
instead of one.

Fail-slow design. There are a lot of places in low-level code where an
error condition is encountered, but instead of throwing an exception,
the error is ignored and maybe it is logged, or the code tries to
"guess" at a solution and then provide an arbitrary default behavior.
I've seen many developers struggle with debugging a problem because they
didn't look at the logs, or because the error was not logged and there
is no way of knowing what caused it. They end up spending hours
single-stepping through code until it reaches the error.

Out-of-date code. A good example is the use of Javolution. That library
was beneficial in the Java 1.4 days, but it is not necessary today
because of improved garbage collection. Another good example is DCL
code. DCL was used extensively in OFBiz, but it is clearly documented to
be an unreliable design (I can get it to fail 90% of the time). Some DCL
code has been replaced, but a lot of it is still there.

Portions of the API are overly complicated. Some methods require a
collection of user-specified artifacts/arguments, which makes client
code complicated and verbose. (David solved that problem with his
Execution Context.) Portions of the API are cluttered with unnecessary
"convenience methods" - making the API harder to learn and memorize. In
some places, a domain-specific API is spread across instance methods and
static methods and across different classes - making the API hard to
understand and use. Yes, there can be good designs that require
something like that, but in the OFBiz framework, it exists because of a
bad design, not a good one.

Use of thread-local variables. This makes multi-threaded design
impossible. The J2EE specification and the Servlet API require one
thread per request (and most J2EE libraries depend on that behavior), so
the current design makes sense from a J2EE perspective, but what if I
don't want to run the framework in a J2EE container? Which leads to the
next problem...

Dependence on J2EE designs/APIs/libraries. There are developers in the
Java community (myself included) who are beginning to question if J2EE
is really necessary to run web applications. The folks at Atomikos are a
good example. OFBiz does not use EJBs, so tying the framework to J2EE
does not make sense. It would be better if the framework was designed to
run outside a J2EE container, and then have container integration as an
option.

Configuration files are scattered everywhere. Anyone who has deployed
OFBiz in a production environment will agree this is a problem. Try
changing the HTTP/HTTPS and port settings - it is a nightmare. Some
configuration settings are in nonsensical places.

An abysmal lack of unit testing. I don't have an exact figure for code
coverage, but my gut feeling is coverage is less than 10%. Basically, we
all have our fingers crossed - hoping that the framework code works as
expected. This was made painfully obvious a while back when I was
looking at some entity caching code and thought to myself "this code
can't work." So I wrote some entity cache unit tests and confirmed that
the entity cache had serious problems. Think about that - years passed
with no entity cache unit tests and consequently we had no idea it
wasn't working.

Fix Versus Rewrite
------------------

Jira issues could be created for these problems and teams of developers
could work to fix them.

Or, we could create a branch and start over from scratch. This time
around, there should be less push-back from people concerned about
backwards compatibility. A rewrite offers the advantage of reconsidering
everything - like API design, general problem solving, and new features.

I created a Wiki page for a framework design:

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

but there hasn't been much interest in it. If the community decides to
go ahead with a rewrite, then please feel free to use the Wiki pages as
a guide.

Sandglass Foundation
--------------------

Like David, I came to the conclusion that a framework rewrite would be
easier outside the OFBiz community. So, I created my own library called
Foundation:

http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf

(PDF)

and I only mention it here to stress how wonderful it can be to start
with a clean slate and design an API that is concise yet powerful.
(Please do not discuss Foundation here, contact me privately if you want
more information.)

Some examples of what can be done with a rewrite:

     A single configuration file
     Use ANSI/ISO SQL SELECT statement strings instead of constructing
complicated Java structures
     Simultaneous asynchronous queries
     Relational integrity across multiple datasources
     Multi-table SELECT across multiple datasources
     Automatic and transparent row version control
     Automatic and transparent multi-language datasource support
     Abstract entities (similar to SQL user types)
     Service engine throttling (protects against server over-utilization)
     Simplified security (authorization)
(https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
     Pure interface-based API - so developers are free to modify
framework behavior by using decorators
     Thorough unit tests

Benefits of a rewrite:

     Reduced resource requirements (lower hosting fees)
     Reduce application development time - due to a simplified API
     Easier framework code maintenance
     Better reliability

Conclusion
----------

Like I said at the start, this is all I will say about the subject. I'm
done trying to convince everyone. I hope someone agrees with me and they
are able to build support for the idea.

--
Adrian Crum
Sandglass Software
www.sandglass-software.com

[Sharan-F]

 Hi Adrian

Thanks for bringing the framework topic up again as I've seen quite a few disucussions about it but nothing has gained enough momentum to do anything about it.

At Apachecon it was one of the main subjects that I wanted to raise because it sounded like an " elephant in the room " topic (i;e ; something so big and obvious that no one wants to look at). In the end we concluded to do something on it even something small just to get some work started on it;

I'm not a technical person so a lot of what you describe is a bit over my head but thanks for including some good examples that at least give me a feel for what the problem is ;

I think that some of the previous discussions have got caught up in defining the solution before we'd agreed to fix the problem ; First we need to acknowledge that we have a problem and second we need find out how many people are willing to help fix it ;

I know that we have people in the community that are really motivated to do work to help work on the framework ; and I think all that's missing (if we decide to go ahead) will be planning and organisation ; (we plan what we want to do and then break it down into tasks that people can pick up and do) :

Personally I think you have made a really compelling and important  case and I think we do have a really important problem that needs work and community support. I would be happy to support it in whatever capacity I can;

Adrian - if the community does come out in support of a framework rewrite ;would you would be willing to help oversee it ? (as I think your input and experience would be invaluable)

Thanks
Sharan

[taher]

Hi Adrian, Sharan and everyone,

Thank you so much for this great input. I wholeheartedly agree with a rewrite (that is so badly needed) and we had a few other threads trying to push that. Adrian if the ball gets rolling on the vision you put forward then count me in. I would absolutely love to be a part of this.

Taher Alkhateeb.

----- Original Message -----

From: "Sharan-F" <[hidden email]>
To: [hidden email]
Sent: Wednesday, 14 October, 2015 11:27:19 PM
Subject: Re: Why A Framework Rewrite Is Necessary

Hi Adrian

Thanks for bringing the framework topic up again as I've seen quite a few
disucussions about it but nothing has gained enough momentum to do anything
about it.

At Apachecon it was one of the main subjects that I wanted to raise because
it sounded like an " elephant in the room " topic (i;e ; something so big
and obvious that no one wants to look at). In the end we concluded to do
something on it even something small just to get some work started on it;

I'm not a technical person so a lot of what you describe is a bit over my
head but thanks for including some good examples that at least give me a
feel for what the problem is ;

I think that some of the previous discussions have got caught up in defining
the solution before we'd agreed to fix the problem ; First we need to
acknowledge that we have a problem and second we need find out how many
people are willing to help fix it ;

I know that we have people in the community that are really motivated to do
work to help work on the framework ; and I think all that's missing (if we
decide to go ahead) will be planning and organisation ; (we plan what we
want to do and then break it down into tasks that people can pick up and
do) :

Personally I think you have made a really compelling and important case and
I think we do have a really important problem that needs work and community
support. I would be happy to support it in whatever capacity I can;

Adrian - if the community does come out in support of a framework rewrite
;would you would be willing to help oversee it ? (as I think your input and
experience would be invaluable)

Thanks
Sharan





--
View this message in context: http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673386.html 
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Ron Wheeler]

How much of the Foundation core either overlaps with Spring or could be
implemented using Spring?

How much of the design for an API has been thought out?
Are there other documents that give use cases and general instructions
for writing an application using the framework?
Is there any hypothetical code demonstrating how a developer could write
a trivial application with security, persistence, logging, etc. or is
the assumption that the current OFBiz framework API be preserved?

A sub-project under Apache OFBiz would be an alternative if the
community wanted to get behind a rewite.
This would allow people interested in framework concerns as opposed to
business applications to work together.


Ron

On 14/10/2015 3:21 PM, Adrian Crum wrote:

> I understand that Sharan brought up the framework rewrite subject at
> ApacheCon, and some attendees felt that the framework is fine and no
> action needs to be taken.
>
> In this message, I will try to give a detailed explanation of why a
> framework rewrite is necessary. I don't plan to take any further
> action on this subject, because I've brought it up before without
> success, and I'm tired of discussing it. It is my hope that the light
> bulb will click on in someone's head and they will take action.
>
> My Background
> -------------
>
> I became a member of the OFBiz community in 2004. I immediately
> started making contributions to the project by supplying patches to
> the issue tracker. In 2007, I became a committer. Most of my initial
> work was on the UI and some work in the applications (mainly Asset
> Maintenance and Work Effort). I stayed away from touching the
> framework code because it was deep, dark, and scary.
>
> Eventually, I started to understand how the framework code works and I
> made some minor modifications. As my understanding grew, I progressed
> to rewriting large swaths of framework code - making it thread-safe,
> fault tolerant, efficient, and easier to use.
>
> I will list some of my contributions here, so everyone can have a
> clear understanding of my experience with the framework code:
>
>     New Features
>
>         User Preferences
>
>         Visual Themes
>
>         Custom UI Label XML File Format
>
>         Temporal Expressions
>
>         Data Type Conversion Framework
>
>         Screen Widget Boundary Comments
>
>         Metrics
>
>     Integrations
>
>         UEL
>
>         iCalendar
>
>         JSR 223
>
>         WebDAV
>
>         LDAP
>
>     Refactorings/Improvements
>
>         FlexibleStringExpander
>
>         FlexibleMapExpander
>
>         FOP Integration
>
>         FreeMarkerWorker
>
>         Date-Time Handling
>
>         Mini-language
>
>         Job Scheduler
>
> In addition, I have performed innumerable framework bug fixes.
>
> So, the contents of this message come from years of experience mucking
> about in the framework code.
>
> Okay, let's get started...
>
> Initial Problem Statement
> -------------------------
>
> In 2009, David Jones started a framework rewrite in a branch:
>
> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>
> At the time, there was some agreement that a rewrite was necessary,
> but there was disagreement as to how the rewrite should be
> incorporated into the project:
>
> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E 
>
>
> There were concerns that a rewrite would break backward compatibility.
> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
> community be more accepting of backward-incompatible changes:
>
> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e 
>
>
> Despite an effort to convince David to proceed with the framework
> rewrite, he ended up doing it in a separate project:
>
> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E 
>
>
> This page describes differences between OFBiz and Moqui, and within it
> you can extract information on the problems David was trying to solve:
>
> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>
> There was an email he sent out on the OFBiz dev list where he listed
> the problems he saw in the framework, but I can't find it. The rest of
> this message will include the issues he mentioned (the ones I
> remember). I was in agreement with him at the time, and I still agree
> that a framework rewrite is necessary.
>
> The Problems
> ------------
>
> Code is scattered everywhere - due to an initial effort to make the
> framework modular. This causes serious problems. The mere fact that
> components like entityext and securityext EXIST makes it clear that
> there are problems - those components should not be there. Also, we
> run into the recurring problem of circular dependencies (component A
> will not build unless component B is built, and component B will not
> build unless component A is built).
>
> Bad separation of concerns. There are far too many examples of classes
> that try to be everything to everyone. This makes debugging difficult,
> and it makes maintenance/improvements a nightmare. [Using an analogy,
> consider an automobile design where a spark plug is not separate from
> a transmission. Instead, the automobile uses a
> spark-plug-transmission. So when the engine is running rough because
> the spark plug is bad, you have to replace the spark plug AND the
> transmission.] A good framework example can be found in my rewrite of
> the mini-language code. Originally, the models AND the script
> execution context both contained script behaviors - making
> debugging/improvements difficult. I changed it so only the models
> contain script behavior and the script execution context contains only
> the script execution state.
>
> Lack of good OO design. There are many places where a bit of framework
> functionality is contained in a single method that is hundreds or
> thousands of lines long. There is a term for that: Brittle Code. Code
> isn't reused. Instead, it is copy-and-pasted all over - so when a
> problem is found in the C&P code, it has to be fixed in many places
> instead of one.
>
> Fail-slow design. There are a lot of places in low-level code where an
> error condition is encountered, but instead of throwing an exception,
> the error is ignored and maybe it is logged, or the code tries to
> "guess" at a solution and then provide an arbitrary default behavior.
> I've seen many developers struggle with debugging a problem because
> they didn't look at the logs, or because the error was not logged and
> there is no way of knowing what caused it. They end up spending hours
> single-stepping through code until it reaches the error.
>
> Out-of-date code. A good example is the use of Javolution. That
> library was beneficial in the Java 1.4 days, but it is not necessary
> today because of improved garbage collection. Another good example is
> DCL code. DCL was used extensively in OFBiz, but it is clearly
> documented to be an unreliable design (I can get it to fail 90% of the
> time). Some DCL code has been replaced, but a lot of it is still there.
>
> Portions of the API are overly complicated. Some methods require a
> collection of user-specified artifacts/arguments, which makes client
> code complicated and verbose. (David solved that problem with his
> Execution Context.) Portions of the API are cluttered with unnecessary
> "convenience methods" - making the API harder to learn and memorize.
> In some places, a domain-specific API is spread across instance
> methods and static methods and across different classes - making the
> API hard to understand and use. Yes, there can be good designs that
> require something like that, but in the OFBiz framework, it exists
> because of a bad design, not a good one.
>
> Use of thread-local variables. This makes multi-threaded design
> impossible. The J2EE specification and the Servlet API require one
> thread per request (and most J2EE libraries depend on that behavior),
> so the current design makes sense from a J2EE perspective, but what if
> I don't want to run the framework in a J2EE container? Which leads to
> the next problem...
>
> Dependence on J2EE designs/APIs/libraries. There are developers in the
> Java community (myself included) who are beginning to question if J2EE
> is really necessary to run web applications. The folks at Atomikos are
> a good example. OFBiz does not use EJBs, so tying the framework to
> J2EE does not make sense. It would be better if the framework was
> designed to run outside a J2EE container, and then have container
> integration as an option.
>
> Configuration files are scattered everywhere. Anyone who has deployed
> OFBiz in a production environment will agree this is a problem. Try
> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
> configuration settings are in nonsensical places.
>
> An abysmal lack of unit testing. I don't have an exact figure for code
> coverage, but my gut feeling is coverage is less than 10%. Basically,
> we all have our fingers crossed - hoping that the framework code works
> as expected. This was made painfully obvious a while back when I was
> looking at some entity caching code and thought to myself "this code
> can't work." So I wrote some entity cache unit tests and confirmed
> that the entity cache had serious problems. Think about that - years
> passed with no entity cache unit tests and consequently we had no idea
> it wasn't working.
>
> Fix Versus Rewrite
> ------------------
>
> Jira issues could be created for these problems and teams of
> developers could work to fix them.
>
> Or, we could create a branch and start over from scratch. This time
> around, there should be less push-back from people concerned about
> backwards compatibility. A rewrite offers the advantage of
> reconsidering everything - like API design, general problem solving,
> and new features.
>
> I created a Wiki page for a framework design:
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision 
>
>
> but there hasn't been much interest in it. If the community decides to
> go ahead with a rewrite, then please feel free to use the Wiki pages
> as a guide.
>
> Sandglass Foundation
> --------------------
>
> Like David, I came to the conclusion that a framework rewrite would be
> easier outside the OFBiz community. So, I created my own library
> called Foundation:
>
> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf 
>
>
> (PDF)
>
> and I only mention it here to stress how wonderful it can be to start
> with a clean slate and design an API that is concise yet powerful.
> (Please do not discuss Foundation here, contact me privately if you
> want more information.)
>
> Some examples of what can be done with a rewrite:
>
>     A single configuration file
>     Use ANSI/ISO SQL SELECT statement strings instead of constructing
> complicated Java structures
>     Simultaneous asynchronous queries
>     Relational integrity across multiple datasources
>     Multi-table SELECT across multiple datasources
>     Automatic and transparent row version control
>     Automatic and transparent multi-language datasource support
>     Abstract entities (similar to SQL user types)
>     Service engine throttling (protects against server over-utilization)
>     Simplified security (authorization)
> (https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>     Pure interface-based API - so developers are free to modify
> framework behavior by using decorators
>     Thorough unit tests
>
> Benefits of a rewrite:
>
>     Reduced resource requirements (lower hosting fees)
>     Reduce application development time - due to a simplified API
>     Easier framework code maintenance
>     Better reliability
>
> Conclusion
> ----------
>
> Like I said at the start, this is all I will say about the subject.
> I'm done trying to convince everyone. I hope someone agrees with me
> and they are able to build support for the idea.
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Adrian Crum-3]

On 10/14/2015 2:09 PM, Ron Wheeler wrote:
> How much of the Foundation core either overlaps with Spring or could be
> implemented using Spring?
>
> How much of the design for an API has been thought out?

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

Please take some time to follow the links I provided in my original message.

> Are there other documents that give use cases and general instructions
> for writing an application using the framework?
> Is there any hypothetical code demonstrating how a developer could write
> a trivial application with security, persistence, logging, etc. or is
> the assumption that the current OFBiz framework API be preserved?
>
> A sub-project under Apache OFBiz would be an alternative if the
> community wanted to get behind a rewite.
> This would allow people interested in framework concerns as opposed to
> business applications to work together.
>
>
> Ron
>
> On 14/10/2015 3:21 PM, Adrian Crum wrote:
>> I understand that Sharan brought up the framework rewrite subject at
>> ApacheCon, and some attendees felt that the framework is fine and no
>> action needs to be taken.
>>
>> In this message, I will try to give a detailed explanation of why a
>> framework rewrite is necessary. I don't plan to take any further
>> action on this subject, because I've brought it up before without
>> success, and I'm tired of discussing it. It is my hope that the light
>> bulb will click on in someone's head and they will take action.
>>
>> My Background
>> -------------
>>
>> I became a member of the OFBiz community in 2004. I immediately
>> started making contributions to the project by supplying patches to
>> the issue tracker. In 2007, I became a committer. Most of my initial
>> work was on the UI and some work in the applications (mainly Asset
>> Maintenance and Work Effort). I stayed away from touching the
>> framework code because it was deep, dark, and scary.
>>
>> Eventually, I started to understand how the framework code works and I
>> made some minor modifications. As my understanding grew, I progressed
>> to rewriting large swaths of framework code - making it thread-safe,
>> fault tolerant, efficient, and easier to use.
>>
>> I will list some of my contributions here, so everyone can have a
>> clear understanding of my experience with the framework code:
>>
>>     New Features
>>
>>         User Preferences
>>
>>         Visual Themes
>>
>>         Custom UI Label XML File Format
>>
>>         Temporal Expressions
>>
>>         Data Type Conversion Framework
>>
>>         Screen Widget Boundary Comments
>>
>>         Metrics
>>
>>     Integrations
>>
>>         UEL
>>
>>         iCalendar
>>
>>         JSR 223
>>
>>         WebDAV
>>
>>         LDAP
>>
>>     Refactorings/Improvements
>>
>>         FlexibleStringExpander
>>
>>         FlexibleMapExpander
>>
>>         FOP Integration
>>
>>         FreeMarkerWorker
>>
>>         Date-Time Handling
>>
>>         Mini-language
>>
>>         Job Scheduler
>>
>> In addition, I have performed innumerable framework bug fixes.
>>
>> So, the contents of this message come from years of experience mucking
>> about in the framework code.
>>
>> Okay, let's get started...
>>
>> Initial Problem Statement
>> -------------------------
>>
>> In 2009, David Jones started a framework rewrite in a branch:
>>
>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>
>> At the time, there was some agreement that a rewrite was necessary,
>> but there was disagreement as to how the rewrite should be
>> incorporated into the project:
>>
>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>
>>
>> There were concerns that a rewrite would break backward compatibility.
>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>> community be more accepting of backward-incompatible changes:
>>
>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>
>>
>> Despite an effort to convince David to proceed with the framework
>> rewrite, he ended up doing it in a separate project:
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>
>>
>> This page describes differences between OFBiz and Moqui, and within it
>> you can extract information on the problems David was trying to solve:
>>
>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>
>> There was an email he sent out on the OFBiz dev list where he listed
>> the problems he saw in the framework, but I can't find it. The rest of
>> this message will include the issues he mentioned (the ones I
>> remember). I was in agreement with him at the time, and I still agree
>> that a framework rewrite is necessary.
>>
>> The Problems
>> ------------
>>
>> Code is scattered everywhere - due to an initial effort to make the
>> framework modular. This causes serious problems. The mere fact that
>> components like entityext and securityext EXIST makes it clear that
>> there are problems - those components should not be there. Also, we
>> run into the recurring problem of circular dependencies (component A
>> will not build unless component B is built, and component B will not
>> build unless component A is built).
>>
>> Bad separation of concerns. There are far too many examples of classes
>> that try to be everything to everyone. This makes debugging difficult,
>> and it makes maintenance/improvements a nightmare. [Using an analogy,
>> consider an automobile design where a spark plug is not separate from
>> a transmission. Instead, the automobile uses a
>> spark-plug-transmission. So when the engine is running rough because
>> the spark plug is bad, you have to replace the spark plug AND the
>> transmission.] A good framework example can be found in my rewrite of
>> the mini-language code. Originally, the models AND the script
>> execution context both contained script behaviors - making
>> debugging/improvements difficult. I changed it so only the models
>> contain script behavior and the script execution context contains only
>> the script execution state.
>>
>> Lack of good OO design. There are many places where a bit of framework
>> functionality is contained in a single method that is hundreds or
>> thousands of lines long. There is a term for that: Brittle Code. Code
>> isn't reused. Instead, it is copy-and-pasted all over - so when a
>> problem is found in the C&P code, it has to be fixed in many places
>> instead of one.
>>
>> Fail-slow design. There are a lot of places in low-level code where an
>> error condition is encountered, but instead of throwing an exception,
>> the error is ignored and maybe it is logged, or the code tries to
>> "guess" at a solution and then provide an arbitrary default behavior.
>> I've seen many developers struggle with debugging a problem because
>> they didn't look at the logs, or because the error was not logged and
>> there is no way of knowing what caused it. They end up spending hours
>> single-stepping through code until it reaches the error.
>>
>> Out-of-date code. A good example is the use of Javolution. That
>> library was beneficial in the Java 1.4 days, but it is not necessary
>> today because of improved garbage collection. Another good example is
>> DCL code. DCL was used extensively in OFBiz, but it is clearly
>> documented to be an unreliable design (I can get it to fail 90% of the
>> time). Some DCL code has been replaced, but a lot of it is still there.
>>
>> Portions of the API are overly complicated. Some methods require a
>> collection of user-specified artifacts/arguments, which makes client
>> code complicated and verbose. (David solved that problem with his
>> Execution Context.) Portions of the API are cluttered with unnecessary
>> "convenience methods" - making the API harder to learn and memorize.
>> In some places, a domain-specific API is spread across instance
>> methods and static methods and across different classes - making the
>> API hard to understand and use. Yes, there can be good designs that
>> require something like that, but in the OFBiz framework, it exists
>> because of a bad design, not a good one.
>>
>> Use of thread-local variables. This makes multi-threaded design
>> impossible. The J2EE specification and the Servlet API require one
>> thread per request (and most J2EE libraries depend on that behavior),
>> so the current design makes sense from a J2EE perspective, but what if
>> I don't want to run the framework in a J2EE container? Which leads to
>> the next problem...
>>
>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>> Java community (myself included) who are beginning to question if J2EE
>> is really necessary to run web applications. The folks at Atomikos are
>> a good example. OFBiz does not use EJBs, so tying the framework to
>> J2EE does not make sense. It would be better if the framework was
>> designed to run outside a J2EE container, and then have container
>> integration as an option.
>>
>> Configuration files are scattered everywhere. Anyone who has deployed
>> OFBiz in a production environment will agree this is a problem. Try
>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>> configuration settings are in nonsensical places.
>>
>> An abysmal lack of unit testing. I don't have an exact figure for code
>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>> we all have our fingers crossed - hoping that the framework code works
>> as expected. This was made painfully obvious a while back when I was
>> looking at some entity caching code and thought to myself "this code
>> can't work." So I wrote some entity cache unit tests and confirmed
>> that the entity cache had serious problems. Think about that - years
>> passed with no entity cache unit tests and consequently we had no idea
>> it wasn't working.
>>
>> Fix Versus Rewrite
>> ------------------
>>
>> Jira issues could be created for these problems and teams of
>> developers could work to fix them.
>>
>> Or, we could create a branch and start over from scratch. This time
>> around, there should be less push-back from people concerned about
>> backwards compatibility. A rewrite offers the advantage of
>> reconsidering everything - like API design, general problem solving,
>> and new features.
>>
>> I created a Wiki page for a framework design:
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>
>>
>> but there hasn't been much interest in it. If the community decides to
>> go ahead with a rewrite, then please feel free to use the Wiki pages
>> as a guide.
>>
>> Sandglass Foundation
>> --------------------
>>
>> Like David, I came to the conclusion that a framework rewrite would be
>> easier outside the OFBiz community. So, I created my own library
>> called Foundation:
>>
>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>
>>
>> (PDF)
>>
>> and I only mention it here to stress how wonderful it can be to start
>> with a clean slate and design an API that is concise yet powerful.
>> (Please do not discuss Foundation here, contact me privately if you
>> want more information.)
>>
>> Some examples of what can be done with a rewrite:
>>
>>     A single configuration file
>>     Use ANSI/ISO SQL SELECT statement strings instead of constructing
>> complicated Java structures
>>     Simultaneous asynchronous queries
>>     Relational integrity across multiple datasources
>>     Multi-table SELECT across multiple datasources
>>     Automatic and transparent row version control
>>     Automatic and transparent multi-language datasource support
>>     Abstract entities (similar to SQL user types)
>>     Service engine throttling (protects against server over-utilization)
>>     Simplified security (authorization)
>> (https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>
>>     Pure interface-based API - so developers are free to modify
>> framework behavior by using decorators
>>     Thorough unit tests
>>
>> Benefits of a rewrite:
>>
>>     Reduced resource requirements (lower hosting fees)
>>     Reduce application development time - due to a simplified API
>>     Easier framework code maintenance
>>     Better reliability
>>
>> Conclusion
>> ----------
>>
>> Like I said at the start, this is all I will say about the subject.
>> I'm done trying to convince everyone. I hope someone agrees with me
>> and they are able to build support for the idea.
>>
>
>

[Paul Foxworthy]

Hi all,

I am in total agreement about the problems.

I am hesitant about the solution.

OFBiz is not perfect, we all know that. A rewrite will not be perfect
either.

A major rewrite will distract attention from OFBiz, which currently works.
Shipping is a feature. Joel Spolsky had a good discussion of these issues
here: http://www.joelonsoftware.com/articles/fog0000000069.html .

Can we refactor what we have, putting a priority on having a working system
at all times?

If a major rewrite is being done on a separate branch, how can we ensure it
will be straightforward to convert existing OFBiz implementations to the
new system?

Why would anyone adopt OFBiz if we're saying "the current version has
significant flaws, but all our best developers are busy working on a major
rewrite which might produce some results in a year or two"?

Thanks

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Fax: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

Small. Complete. Perfect.
Your business with BonsaiERP.
http://www.bonsaierp.com.au/

[Scott Gray-3]

My advice is as follows:
1. If people are interested, then get them together and start working on it.
2. Find somewhere to do the work.  I don't think a branch is appropriate
because it's completely new development rather than a refactoring.  I don't
have any objections to it being done under the ASF OFBiz umbrella (although
I don't really see the need either).
3. Set up a separate mailing list for discussion.  Generally I'd try and
keep quiet about it in the early stages on the dev/user lists or other
marketing channels because it could potentially harm adoption of our
existing framework (think AngularJS 2.0).

There really isn't any need to get early stage sign-off from the PMC or
anyone else in the community.  You only need enough PMC approval to get the
required infrastructure sorted, which I don't think would be an issue.
From there, it's really up to the community to decide whether or not the
thing will fly.

Regards
Scott


On 15 October 2015 at 08:21, Adrian Crum <[hidden email]
> wrote:

> I understand that Sharan brought up the framework rewrite subject at
> ApacheCon, and some attendees felt that the framework is fine and no action
> needs to be taken.
>
> In this message, I will try to give a detailed explanation of why a
> framework rewrite is necessary. I don't plan to take any further action on
> this subject, because I've brought it up before without success, and I'm
> tired of discussing it. It is my hope that the light bulb will click on in
> someone's head and they will take action.
>
> My Background
> -------------
>
> I became a member of the OFBiz community in 2004. I immediately started
> making contributions to the project by supplying patches to the issue
> tracker. In 2007, I became a committer. Most of my initial work was on the
> UI and some work in the applications (mainly Asset Maintenance and Work
> Effort). I stayed away from touching the framework code because it was
> deep, dark, and scary.
>
> Eventually, I started to understand how the framework code works and I
> made some minor modifications. As my understanding grew, I progressed to
> rewriting large swaths of framework code - making it thread-safe, fault
> tolerant, efficient, and easier to use.
>
> I will list some of my contributions here, so everyone can have a clear
> understanding of my experience with the framework code:
>
>     New Features
>
>         User Preferences
>
>         Visual Themes
>
>         Custom UI Label XML File Format
>
>         Temporal Expressions
>
>         Data Type Conversion Framework
>
>         Screen Widget Boundary Comments
>
>         Metrics
>
>     Integrations
>
>         UEL
>
>         iCalendar
>
>         JSR 223
>
>         WebDAV
>
>         LDAP
>
>     Refactorings/Improvements
>
>         FlexibleStringExpander
>
>         FlexibleMapExpander
>
>         FOP Integration
>
>         FreeMarkerWorker
>
>         Date-Time Handling
>
>         Mini-language
>
>         Job Scheduler
>
> In addition, I have performed innumerable framework bug fixes.
>
> So, the contents of this message come from years of experience mucking
> about in the framework code.
>
> Okay, let's get started...
>
> Initial Problem Statement
> -------------------------
>
> In 2009, David Jones started a framework rewrite in a branch:
>
> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>
> At the time, there was some agreement that a rewrite was necessary, but
> there was disagreement as to how the rewrite should be incorporated into
> the project:
>
>
> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>
> There were concerns that a rewrite would break backward compatibility.
> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
> community be more accepting of backward-incompatible changes:
>
>
> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>
> Despite an effort to convince David to proceed with the framework rewrite,
> he ended up doing it in a separate project:
>
>
> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>
> This page describes differences between OFBiz and Moqui, and within it you
> can extract information on the problems David was trying to solve:
>
> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>
> There was an email he sent out on the OFBiz dev list where he listed the
> problems he saw in the framework, but I can't find it. The rest of this
> message will include the issues he mentioned (the ones I remember). I was
> in agreement with him at the time, and I still agree that a framework
> rewrite is necessary.
>
> The Problems
> ------------
>
> Code is scattered everywhere - due to an initial effort to make the
> framework modular. This causes serious problems. The mere fact that
> components like entityext and securityext EXIST makes it clear that there
> are problems - those components should not be there. Also, we run into the
> recurring problem of circular dependencies (component A will not build
> unless component B is built, and component B will not build unless
> component A is built).
>
> Bad separation of concerns. There are far too many examples of classes
> that try to be everything to everyone. This makes debugging difficult, and
> it makes maintenance/improvements a nightmare. [Using an analogy, consider
> an automobile design where a spark plug is not separate from a
> transmission. Instead, the automobile uses a spark-plug-transmission. So
> when the engine is running rough because the spark plug is bad, you have to
> replace the spark plug AND the transmission.] A good framework example can
> be found in my rewrite of the mini-language code. Originally, the models
> AND the script execution context both contained script behaviors - making
> debugging/improvements difficult. I changed it so only the models contain
> script behavior and the script execution context contains only the script
> execution state.
>
> Lack of good OO design. There are many places where a bit of framework
> functionality is contained in a single method that is hundreds or thousands
> of lines long. There is a term for that: Brittle Code. Code isn't reused.
> Instead, it is copy-and-pasted all over - so when a problem is found in the
> C&P code, it has to be fixed in many places instead of one.
>
> Fail-slow design. There are a lot of places in low-level code where an
> error condition is encountered, but instead of throwing an exception, the
> error is ignored and maybe it is logged, or the code tries to "guess" at a
> solution and then provide an arbitrary default behavior. I've seen many
> developers struggle with debugging a problem because they didn't look at
> the logs, or because the error was not logged and there is no way of
> knowing what caused it. They end up spending hours single-stepping through
> code until it reaches the error.
>
> Out-of-date code. A good example is the use of Javolution. That library
> was beneficial in the Java 1.4 days, but it is not necessary today because
> of improved garbage collection. Another good example is DCL code. DCL was
> used extensively in OFBiz, but it is clearly documented to be an unreliable
> design (I can get it to fail 90% of the time). Some DCL code has been
> replaced, but a lot of it is still there.
>
> Portions of the API are overly complicated. Some methods require a
> collection of user-specified artifacts/arguments, which makes client code
> complicated and verbose. (David solved that problem with his Execution
> Context.) Portions of the API are cluttered with unnecessary "convenience
> methods" - making the API harder to learn and memorize. In some places, a
> domain-specific API is spread across instance methods and static methods
> and across different classes - making the API hard to understand and use.
> Yes, there can be good designs that require something like that, but in the
> OFBiz framework, it exists because of a bad design, not a good one.
>
> Use of thread-local variables. This makes multi-threaded design
> impossible. The J2EE specification and the Servlet API require one thread
> per request (and most J2EE libraries depend on that behavior), so the
> current design makes sense from a J2EE perspective, but what if I don't
> want to run the framework in a J2EE container? Which leads to the next
> problem...
>
> Dependence on J2EE designs/APIs/libraries. There are developers in the
> Java community (myself included) who are beginning to question if J2EE is
> really necessary to run web applications. The folks at Atomikos are a good
> example. OFBiz does not use EJBs, so tying the framework to J2EE does not
> make sense. It would be better if the framework was designed to run outside
> a J2EE container, and then have container integration as an option.
>
> Configuration files are scattered everywhere. Anyone who has deployed
> OFBiz in a production environment will agree this is a problem. Try
> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
> configuration settings are in nonsensical places.
>
> An abysmal lack of unit testing. I don't have an exact figure for code
> coverage, but my gut feeling is coverage is less than 10%. Basically, we
> all have our fingers crossed - hoping that the framework code works as
> expected. This was made painfully obvious a while back when I was looking
> at some entity caching code and thought to myself "this code can't work."
> So I wrote some entity cache unit tests and confirmed that the entity cache
> had serious problems. Think about that - years passed with no entity cache
> unit tests and consequently we had no idea it wasn't working.
>
> Fix Versus Rewrite
> ------------------
>
> Jira issues could be created for these problems and teams of developers
> could work to fix them.
>
> Or, we could create a branch and start over from scratch. This time
> around, there should be less push-back from people concerned about
> backwards compatibility. A rewrite offers the advantage of reconsidering
> everything - like API design, general problem solving, and new features.
>
> I created a Wiki page for a framework design:
>
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>
> but there hasn't been much interest in it. If the community decides to go
> ahead with a rewrite, then please feel free to use the Wiki pages as a
> guide.
>
> Sandglass Foundation
> --------------------
>
> Like David, I came to the conclusion that a framework rewrite would be
> easier outside the OFBiz community. So, I created my own library called
> Foundation:
>
>
> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>
> (PDF)
>
> and I only mention it here to stress how wonderful it can be to start with
> a clean slate and design an API that is concise yet powerful. (Please do
> not discuss Foundation here, contact me privately if you want more
> information.)
>
> Some examples of what can be done with a rewrite:
>
>     A single configuration file
>     Use ANSI/ISO SQL SELECT statement strings instead of constructing
> complicated Java structures
>     Simultaneous asynchronous queries
>     Relational integrity across multiple datasources
>     Multi-table SELECT across multiple datasources
>     Automatic and transparent row version control
>     Automatic and transparent multi-language datasource support
>     Abstract entities (similar to SQL user types)
>     Service engine throttling (protects against server over-utilization)
>     Simplified security (authorization) (
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>     Pure interface-based API - so developers are free to modify framework
> behavior by using decorators
>     Thorough unit tests
>
> Benefits of a rewrite:
>
>     Reduced resource requirements (lower hosting fees)
>     Reduce application development time - due to a simplified API
>     Easier framework code maintenance
>     Better reliability
>
> Conclusion
> ----------
>
> Like I said at the start, this is all I will say about the subject. I'm
> done trying to convince everyone. I hope someone agrees with me and they
> are able to build support for the idea.
>
> --
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>

[Shi Jinghai-3]

As Jacques mentioned, OFBiz is a bit special in Apache. Why special? Personally, I think OFBiz is built for Sharan, for consultants. The other projects in Apache are for developers.

So my vote will follow Sharan's. :)


-----邮件原件-----
发件人: Adrian Crum [mailto:[hidden email]]
发送时间: 2015年10月15日 3:21
收件人: [hidden email]
主题: Why A Framework Rewrite Is Necessary

I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further action
on this subject, because I've brought it up before without success, and
I'm tired of discussing it. It is my hope that the light bulb will click
on in someone's head and they will take action.

My Background
-------------

I became a member of the OFBiz community in 2004. I immediately started
making contributions to the project by supplying patches to the issue
tracker. In 2007, I became a committer. Most of my initial work was on
the UI and some work in the applications (mainly Asset Maintenance and
Work Effort). I stayed away from touching the framework code because it
was deep, dark, and scary.

Eventually, I started to understand how the framework code works and I
made some minor modifications. As my understanding grew, I progressed to
rewriting large swaths of framework code - making it thread-safe, fault
tolerant, efficient, and easier to use.

I will list some of my contributions here, so everyone can have a clear
understanding of my experience with the framework code:

     New Features

         User Preferences

         Visual Themes

         Custom UI Label XML File Format

         Temporal Expressions

         Data Type Conversion Framework

         Screen Widget Boundary Comments

         Metrics

     Integrations

         UEL

         iCalendar

         JSR 223

         WebDAV

         LDAP

     Refactorings/Improvements

         FlexibleStringExpander

         FlexibleMapExpander

         FOP Integration

         FreeMarkerWorker

         Date-Time Handling

         Mini-language

         Job Scheduler

In addition, I have performed innumerable framework bug fixes.

So, the contents of this message come from years of experience mucking
about in the framework code.

Okay, let's get started...

Initial Problem Statement
-------------------------

In 2009, David Jones started a framework rewrite in a branch:

https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716

At the time, there was some agreement that a rewrite was necessary, but
there was disagreement as to how the rewrite should be incorporated into
the project:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E

There were concerns that a rewrite would break backward compatibility.
Work on the rewrite branch stopped. Eventually, Jacopo suggested the
community be more accepting of backward-incompatible changes:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e

Despite an effort to convince David to proceed with the framework
rewrite, he ended up doing it in a separate project:

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E

This page describes differences between OFBiz and Moqui, and within it
you can extract information on the problems David was trying to solve:

http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/

There was an email he sent out on the OFBiz dev list where he listed the
problems he saw in the framework, but I can't find it. The rest of this
message will include the issues he mentioned (the ones I remember). I
was in agreement with him at the time, and I still agree that a
framework rewrite is necessary.

The Problems
------------

Code is scattered everywhere - due to an initial effort to make the
framework modular. This causes serious problems. The mere fact that
components like entityext and securityext EXIST makes it clear that
there are problems - those components should not be there. Also, we run
into the recurring problem of circular dependencies (component A will
not build unless component B is built, and component B will not build
unless component A is built).

Bad separation of concerns. There are far too many examples of classes
that try to be everything to everyone. This makes debugging difficult,
and it makes maintenance/improvements a nightmare. [Using an analogy,
consider an automobile design where a spark plug is not separate from a
transmission. Instead, the automobile uses a spark-plug-transmission. So
when the engine is running rough because the spark plug is bad, you have
to replace the spark plug AND the transmission.] A good framework
example can be found in my rewrite of the mini-language code.
Originally, the models AND the script execution context both contained
script behaviors - making debugging/improvements difficult. I changed it
so only the models contain script behavior and the script execution
context contains only the script execution state.

Lack of good OO design. There are many places where a bit of framework
functionality is contained in a single method that is hundreds or
thousands of lines long. There is a term for that: Brittle Code. Code
isn't reused. Instead, it is copy-and-pasted all over - so when a
problem is found in the C&P code, it has to be fixed in many places
instead of one.

Fail-slow design. There are a lot of places in low-level code where an
error condition is encountered, but instead of throwing an exception,
the error is ignored and maybe it is logged, or the code tries to
"guess" at a solution and then provide an arbitrary default behavior.
I've seen many developers struggle with debugging a problem because they
didn't look at the logs, or because the error was not logged and there
is no way of knowing what caused it. They end up spending hours
single-stepping through code until it reaches the error.

Out-of-date code. A good example is the use of Javolution. That library
was beneficial in the Java 1.4 days, but it is not necessary today
because of improved garbage collection. Another good example is DCL
code. DCL was used extensively in OFBiz, but it is clearly documented to
be an unreliable design (I can get it to fail 90% of the time). Some DCL
code has been replaced, but a lot of it is still there.

Portions of the API are overly complicated. Some methods require a
collection of user-specified artifacts/arguments, which makes client
code complicated and verbose. (David solved that problem with his
Execution Context.) Portions of the API are cluttered with unnecessary
"convenience methods" - making the API harder to learn and memorize. In
some places, a domain-specific API is spread across instance methods and
static methods and across different classes - making the API hard to
understand and use. Yes, there can be good designs that require
something like that, but in the OFBiz framework, it exists because of a
bad design, not a good one.

Use of thread-local variables. This makes multi-threaded design
impossible. The J2EE specification and the Servlet API require one
thread per request (and most J2EE libraries depend on that behavior), so
the current design makes sense from a J2EE perspective, but what if I
don't want to run the framework in a J2EE container? Which leads to the
next problem...

Dependence on J2EE designs/APIs/libraries. There are developers in the
Java community (myself included) who are beginning to question if J2EE
is really necessary to run web applications. The folks at Atomikos are a
good example. OFBiz does not use EJBs, so tying the framework to J2EE
does not make sense. It would be better if the framework was designed to
run outside a J2EE container, and then have container integration as an
option.

Configuration files are scattered everywhere. Anyone who has deployed
OFBiz in a production environment will agree this is a problem. Try
changing the HTTP/HTTPS and port settings - it is a nightmare. Some
configuration settings are in nonsensical places.

An abysmal lack of unit testing. I don't have an exact figure for code
coverage, but my gut feeling is coverage is less than 10%. Basically, we
all have our fingers crossed - hoping that the framework code works as
expected. This was made painfully obvious a while back when I was
looking at some entity caching code and thought to myself "this code
can't work." So I wrote some entity cache unit tests and confirmed that
the entity cache had serious problems. Think about that - years passed
with no entity cache unit tests and consequently we had no idea it
wasn't working.

Fix Versus Rewrite
------------------

Jira issues could be created for these problems and teams of developers
could work to fix them.

Or, we could create a branch and start over from scratch. This time
around, there should be less push-back from people concerned about
backwards compatibility. A rewrite offers the advantage of reconsidering
everything - like API design, general problem solving, and new features.

I created a Wiki page for a framework design:

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

but there hasn't been much interest in it. If the community decides to
go ahead with a rewrite, then please feel free to use the Wiki pages as
a guide.

Sandglass Foundation
--------------------

Like David, I came to the conclusion that a framework rewrite would be
easier outside the OFBiz community. So, I created my own library called
Foundation:

http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf

(PDF)

and I only mention it here to stress how wonderful it can be to start
with a clean slate and design an API that is concise yet powerful.
(Please do not discuss Foundation here, contact me privately if you want
more information.)

Some examples of what can be done with a rewrite:

     A single configuration file
     Use ANSI/ISO SQL SELECT statement strings instead of constructing
complicated Java structures
     Simultaneous asynchronous queries
     Relational integrity across multiple datasources
     Multi-table SELECT across multiple datasources
     Automatic and transparent row version control
     Automatic and transparent multi-language datasource support
     Abstract entities (similar to SQL user types)
     Service engine throttling (protects against server over-utilization)
     Simplified security (authorization)
(https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
     Pure interface-based API - so developers are free to modify
framework behavior by using decorators
     Thorough unit tests

Benefits of a rewrite:

     Reduced resource requirements (lower hosting fees)
     Reduce application development time - due to a simplified API
     Easier framework code maintenance
     Better reliability

Conclusion
----------

Like I said at the start, this is all I will say about the subject. I'm
done trying to convince everyone. I hope someone agrees with me and they
are able to build support for the idea.

--
Adrian Crum
Sandglass Software
www.sandglass-software.com

[Ron Wheeler]

There are no details about the API on that page.
I was hoping that you might have some more details not yet added to the
page.

Ron

On 14/10/2015 8:05 PM, Adrian Crum wrote:

> On 10/14/2015 2:09 PM, Ron Wheeler wrote:
>> How much of the Foundation core either overlaps with Spring or could be
>> implemented using Spring?
>>
>> How much of the design for an API has been thought out?
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision 
>
>
> Please take some time to follow the links I provided in my original
> message.
>
>
>> Are there other documents that give use cases and general instructions
>> for writing an application using the framework?
>> Is there any hypothetical code demonstrating how a developer could write
>> a trivial application with security, persistence, logging, etc. or is
>> the assumption that the current OFBiz framework API be preserved?
>>
>> A sub-project under Apache OFBiz would be an alternative if the
>> community wanted to get behind a rewite.
>> This would allow people interested in framework concerns as opposed to
>> business applications to work together.
>>
>>
>> Ron
>>
>> On 14/10/2015 3:21 PM, Adrian Crum wrote:
>>> I understand that Sharan brought up the framework rewrite subject at
>>> ApacheCon, and some attendees felt that the framework is fine and no
>>> action needs to be taken.
>>>
>>> In this message, I will try to give a detailed explanation of why a
>>> framework rewrite is necessary. I don't plan to take any further
>>> action on this subject, because I've brought it up before without
>>> success, and I'm tired of discussing it. It is my hope that the light
>>> bulb will click on in someone's head and they will take action.
>>>
>>> My Background
>>> -------------
>>>
>>> I became a member of the OFBiz community in 2004. I immediately
>>> started making contributions to the project by supplying patches to
>>> the issue tracker. In 2007, I became a committer. Most of my initial
>>> work was on the UI and some work in the applications (mainly Asset
>>> Maintenance and Work Effort). I stayed away from touching the
>>> framework code because it was deep, dark, and scary.
>>>
>>> Eventually, I started to understand how the framework code works and I
>>> made some minor modifications. As my understanding grew, I progressed
>>> to rewriting large swaths of framework code - making it thread-safe,
>>> fault tolerant, efficient, and easier to use.
>>>
>>> I will list some of my contributions here, so everyone can have a
>>> clear understanding of my experience with the framework code:
>>>
>>>     New Features
>>>
>>>         User Preferences
>>>
>>>         Visual Themes
>>>
>>>         Custom UI Label XML File Format
>>>
>>>         Temporal Expressions
>>>
>>>         Data Type Conversion Framework
>>>
>>>         Screen Widget Boundary Comments
>>>
>>>         Metrics
>>>
>>>     Integrations
>>>
>>>         UEL
>>>
>>>         iCalendar
>>>
>>>         JSR 223
>>>
>>>         WebDAV
>>>
>>>         LDAP
>>>
>>>     Refactorings/Improvements
>>>
>>>         FlexibleStringExpander
>>>
>>>         FlexibleMapExpander
>>>
>>>         FOP Integration
>>>
>>>         FreeMarkerWorker
>>>
>>>         Date-Time Handling
>>>
>>>         Mini-language
>>>
>>>         Job Scheduler
>>>
>>> In addition, I have performed innumerable framework bug fixes.
>>>
>>> So, the contents of this message come from years of experience mucking
>>> about in the framework code.
>>>
>>> Okay, let's get started...
>>>
>>> Initial Problem Statement
>>> -------------------------
>>>
>>> In 2009, David Jones started a framework rewrite in a branch:
>>>
>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716 
>>>
>>>
>>> At the time, there was some agreement that a rewrite was necessary,
>>> but there was disagreement as to how the rewrite should be
>>> incorporated into the project:
>>>
>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E 
>>>
>>>
>>>
>>> There were concerns that a rewrite would break backward compatibility.
>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>> community be more accepting of backward-incompatible changes:
>>>
>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e 
>>>
>>>
>>>
>>> Despite an effort to convince David to proceed with the framework
>>> rewrite, he ended up doing it in a separate project:
>>>
>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E 
>>>
>>>
>>>
>>> This page describes differences between OFBiz and Moqui, and within it
>>> you can extract information on the problems David was trying to solve:
>>>
>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>
>>> There was an email he sent out on the OFBiz dev list where he listed
>>> the problems he saw in the framework, but I can't find it. The rest of
>>> this message will include the issues he mentioned (the ones I
>>> remember). I was in agreement with him at the time, and I still agree
>>> that a framework rewrite is necessary.
>>>
>>> The Problems
>>> ------------
>>>
>>> Code is scattered everywhere - due to an initial effort to make the
>>> framework modular. This causes serious problems. The mere fact that
>>> components like entityext and securityext EXIST makes it clear that
>>> there are problems - those components should not be there. Also, we
>>> run into the recurring problem of circular dependencies (component A
>>> will not build unless component B is built, and component B will not
>>> build unless component A is built).
>>>
>>> Bad separation of concerns. There are far too many examples of classes
>>> that try to be everything to everyone. This makes debugging difficult,
>>> and it makes maintenance/improvements a nightmare. [Using an analogy,
>>> consider an automobile design where a spark plug is not separate from
>>> a transmission. Instead, the automobile uses a
>>> spark-plug-transmission. So when the engine is running rough because
>>> the spark plug is bad, you have to replace the spark plug AND the
>>> transmission.] A good framework example can be found in my rewrite of
>>> the mini-language code. Originally, the models AND the script
>>> execution context both contained script behaviors - making
>>> debugging/improvements difficult. I changed it so only the models
>>> contain script behavior and the script execution context contains only
>>> the script execution state.
>>>
>>> Lack of good OO design. There are many places where a bit of framework
>>> functionality is contained in a single method that is hundreds or
>>> thousands of lines long. There is a term for that: Brittle Code. Code
>>> isn't reused. Instead, it is copy-and-pasted all over - so when a
>>> problem is found in the C&P code, it has to be fixed in many places
>>> instead of one.
>>>
>>> Fail-slow design. There are a lot of places in low-level code where an
>>> error condition is encountered, but instead of throwing an exception,
>>> the error is ignored and maybe it is logged, or the code tries to
>>> "guess" at a solution and then provide an arbitrary default behavior.
>>> I've seen many developers struggle with debugging a problem because
>>> they didn't look at the logs, or because the error was not logged and
>>> there is no way of knowing what caused it. They end up spending hours
>>> single-stepping through code until it reaches the error.
>>>
>>> Out-of-date code. A good example is the use of Javolution. That
>>> library was beneficial in the Java 1.4 days, but it is not necessary
>>> today because of improved garbage collection. Another good example is
>>> DCL code. DCL was used extensively in OFBiz, but it is clearly
>>> documented to be an unreliable design (I can get it to fail 90% of the
>>> time). Some DCL code has been replaced, but a lot of it is still there.
>>>
>>> Portions of the API are overly complicated. Some methods require a
>>> collection of user-specified artifacts/arguments, which makes client
>>> code complicated and verbose. (David solved that problem with his
>>> Execution Context.) Portions of the API are cluttered with unnecessary
>>> "convenience methods" - making the API harder to learn and memorize.
>>> In some places, a domain-specific API is spread across instance
>>> methods and static methods and across different classes - making the
>>> API hard to understand and use. Yes, there can be good designs that
>>> require something like that, but in the OFBiz framework, it exists
>>> because of a bad design, not a good one.
>>>
>>> Use of thread-local variables. This makes multi-threaded design
>>> impossible. The J2EE specification and the Servlet API require one
>>> thread per request (and most J2EE libraries depend on that behavior),
>>> so the current design makes sense from a J2EE perspective, but what if
>>> I don't want to run the framework in a J2EE container? Which leads to
>>> the next problem...
>>>
>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>> Java community (myself included) who are beginning to question if J2EE
>>> is really necessary to run web applications. The folks at Atomikos are
>>> a good example. OFBiz does not use EJBs, so tying the framework to
>>> J2EE does not make sense. It would be better if the framework was
>>> designed to run outside a J2EE container, and then have container
>>> integration as an option.
>>>
>>> Configuration files are scattered everywhere. Anyone who has deployed
>>> OFBiz in a production environment will agree this is a problem. Try
>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>> configuration settings are in nonsensical places.
>>>
>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>>> we all have our fingers crossed - hoping that the framework code works
>>> as expected. This was made painfully obvious a while back when I was
>>> looking at some entity caching code and thought to myself "this code
>>> can't work." So I wrote some entity cache unit tests and confirmed
>>> that the entity cache had serious problems. Think about that - years
>>> passed with no entity cache unit tests and consequently we had no idea
>>> it wasn't working.
>>>
>>> Fix Versus Rewrite
>>> ------------------
>>>
>>> Jira issues could be created for these problems and teams of
>>> developers could work to fix them.
>>>
>>> Or, we could create a branch and start over from scratch. This time
>>> around, there should be less push-back from people concerned about
>>> backwards compatibility. A rewrite offers the advantage of
>>> reconsidering everything - like API design, general problem solving,
>>> and new features.
>>>
>>> I created a Wiki page for a framework design:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision 
>>>
>>>
>>>
>>> but there hasn't been much interest in it. If the community decides to
>>> go ahead with a rewrite, then please feel free to use the Wiki pages
>>> as a guide.
>>>
>>> Sandglass Foundation
>>> --------------------
>>>
>>> Like David, I came to the conclusion that a framework rewrite would be
>>> easier outside the OFBiz community. So, I created my own library
>>> called Foundation:
>>>
>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf 
>>>
>>>
>>>
>>> (PDF)
>>>
>>> and I only mention it here to stress how wonderful it can be to start
>>> with a clean slate and design an API that is concise yet powerful.
>>> (Please do not discuss Foundation here, contact me privately if you
>>> want more information.)
>>>
>>> Some examples of what can be done with a rewrite:
>>>
>>>     A single configuration file
>>>     Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>> complicated Java structures
>>>     Simultaneous asynchronous queries
>>>     Relational integrity across multiple datasources
>>>     Multi-table SELECT across multiple datasources
>>>     Automatic and transparent row version control
>>>     Automatic and transparent multi-language datasource support
>>>     Abstract entities (similar to SQL user types)
>>>     Service engine throttling (protects against server
>>> over-utilization)
>>>     Simplified security (authorization)
>>> (https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>
>>>
>>>     Pure interface-based API - so developers are free to modify
>>> framework behavior by using decorators
>>>     Thorough unit tests
>>>
>>> Benefits of a rewrite:
>>>
>>>     Reduced resource requirements (lower hosting fees)
>>>     Reduce application development time - due to a simplified API
>>>     Easier framework code maintenance
>>>     Better reliability
>>>
>>> Conclusion
>>> ----------
>>>
>>> Like I said at the start, this is all I will say about the subject.
>>> I'm done trying to convince everyone. I hope someone agrees with me
>>> and they are able to build support for the idea.
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Adrian Crum-3]

There is a link at the bottom of the page that leads to a draft design
overview.

The design is short on details because no one expressed an interest in
it and contributed to it. I wasn't going to do it by myself because I
didn't want it to become "an Adrian thing."

Some of the truly amazing code in OFBiz came from collaboration within
the community, and my hope was our skilled developers would all pitch in
and help with the design. But that never happened. Maybe Sharan will
have better luck.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/14/2015 5:44 PM, Ron Wheeler wrote:

> There are no details about the API on that page.
> I was hoping that you might have some more details not yet added to the
> page.
>
> Ron
>
> On 14/10/2015 8:05 PM, Adrian Crum wrote:
>> On 10/14/2015 2:09 PM, Ron Wheeler wrote:
>>> How much of the Foundation core either overlaps with Spring or could be
>>> implemented using Spring?
>>>
>>> How much of the design for an API has been thought out?
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>
>>
>> Please take some time to follow the links I provided in my original
>> message.
>>
>>
>>> Are there other documents that give use cases and general instructions
>>> for writing an application using the framework?
>>> Is there any hypothetical code demonstrating how a developer could write
>>> a trivial application with security, persistence, logging, etc. or is
>>> the assumption that the current OFBiz framework API be preserved?
>>>
>>> A sub-project under Apache OFBiz would be an alternative if the
>>> community wanted to get behind a rewite.
>>> This would allow people interested in framework concerns as opposed to
>>> business applications to work together.
>>>
>>>
>>> Ron
>>>
>>> On 14/10/2015 3:21 PM, Adrian Crum wrote:
>>>> I understand that Sharan brought up the framework rewrite subject at
>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>> action needs to be taken.
>>>>
>>>> In this message, I will try to give a detailed explanation of why a
>>>> framework rewrite is necessary. I don't plan to take any further
>>>> action on this subject, because I've brought it up before without
>>>> success, and I'm tired of discussing it. It is my hope that the light
>>>> bulb will click on in someone's head and they will take action.
>>>>
>>>> My Background
>>>> -------------
>>>>
>>>> I became a member of the OFBiz community in 2004. I immediately
>>>> started making contributions to the project by supplying patches to
>>>> the issue tracker. In 2007, I became a committer. Most of my initial
>>>> work was on the UI and some work in the applications (mainly Asset
>>>> Maintenance and Work Effort). I stayed away from touching the
>>>> framework code because it was deep, dark, and scary.
>>>>
>>>> Eventually, I started to understand how the framework code works and I
>>>> made some minor modifications. As my understanding grew, I progressed
>>>> to rewriting large swaths of framework code - making it thread-safe,
>>>> fault tolerant, efficient, and easier to use.
>>>>
>>>> I will list some of my contributions here, so everyone can have a
>>>> clear understanding of my experience with the framework code:
>>>>
>>>>     New Features
>>>>
>>>>         User Preferences
>>>>
>>>>         Visual Themes
>>>>
>>>>         Custom UI Label XML File Format
>>>>
>>>>         Temporal Expressions
>>>>
>>>>         Data Type Conversion Framework
>>>>
>>>>         Screen Widget Boundary Comments
>>>>
>>>>         Metrics
>>>>
>>>>     Integrations
>>>>
>>>>         UEL
>>>>
>>>>         iCalendar
>>>>
>>>>         JSR 223
>>>>
>>>>         WebDAV
>>>>
>>>>         LDAP
>>>>
>>>>     Refactorings/Improvements
>>>>
>>>>         FlexibleStringExpander
>>>>
>>>>         FlexibleMapExpander
>>>>
>>>>         FOP Integration
>>>>
>>>>         FreeMarkerWorker
>>>>
>>>>         Date-Time Handling
>>>>
>>>>         Mini-language
>>>>
>>>>         Job Scheduler
>>>>
>>>> In addition, I have performed innumerable framework bug fixes.
>>>>
>>>> So, the contents of this message come from years of experience mucking
>>>> about in the framework code.
>>>>
>>>> Okay, let's get started...
>>>>
>>>> Initial Problem Statement
>>>> -------------------------
>>>>
>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>
>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>
>>>>
>>>> At the time, there was some agreement that a rewrite was necessary,
>>>> but there was disagreement as to how the rewrite should be
>>>> incorporated into the project:
>>>>
>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>
>>>>
>>>>
>>>> There were concerns that a rewrite would break backward compatibility.
>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>> community be more accepting of backward-incompatible changes:
>>>>
>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>
>>>>
>>>>
>>>> Despite an effort to convince David to proceed with the framework
>>>> rewrite, he ended up doing it in a separate project:
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>
>>>>
>>>>
>>>> This page describes differences between OFBiz and Moqui, and within it
>>>> you can extract information on the problems David was trying to solve:
>>>>
>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>
>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>> the problems he saw in the framework, but I can't find it. The rest of
>>>> this message will include the issues he mentioned (the ones I
>>>> remember). I was in agreement with him at the time, and I still agree
>>>> that a framework rewrite is necessary.
>>>>
>>>> The Problems
>>>> ------------
>>>>
>>>> Code is scattered everywhere - due to an initial effort to make the
>>>> framework modular. This causes serious problems. The mere fact that
>>>> components like entityext and securityext EXIST makes it clear that
>>>> there are problems - those components should not be there. Also, we
>>>> run into the recurring problem of circular dependencies (component A
>>>> will not build unless component B is built, and component B will not
>>>> build unless component A is built).
>>>>
>>>> Bad separation of concerns. There are far too many examples of classes
>>>> that try to be everything to everyone. This makes debugging difficult,
>>>> and it makes maintenance/improvements a nightmare. [Using an analogy,
>>>> consider an automobile design where a spark plug is not separate from
>>>> a transmission. Instead, the automobile uses a
>>>> spark-plug-transmission. So when the engine is running rough because
>>>> the spark plug is bad, you have to replace the spark plug AND the
>>>> transmission.] A good framework example can be found in my rewrite of
>>>> the mini-language code. Originally, the models AND the script
>>>> execution context both contained script behaviors - making
>>>> debugging/improvements difficult. I changed it so only the models
>>>> contain script behavior and the script execution context contains only
>>>> the script execution state.
>>>>
>>>> Lack of good OO design. There are many places where a bit of framework
>>>> functionality is contained in a single method that is hundreds or
>>>> thousands of lines long. There is a term for that: Brittle Code. Code
>>>> isn't reused. Instead, it is copy-and-pasted all over - so when a
>>>> problem is found in the C&P code, it has to be fixed in many places
>>>> instead of one.
>>>>
>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>> error condition is encountered, but instead of throwing an exception,
>>>> the error is ignored and maybe it is logged, or the code tries to
>>>> "guess" at a solution and then provide an arbitrary default behavior.
>>>> I've seen many developers struggle with debugging a problem because
>>>> they didn't look at the logs, or because the error was not logged and
>>>> there is no way of knowing what caused it. They end up spending hours
>>>> single-stepping through code until it reaches the error.
>>>>
>>>> Out-of-date code. A good example is the use of Javolution. That
>>>> library was beneficial in the Java 1.4 days, but it is not necessary
>>>> today because of improved garbage collection. Another good example is
>>>> DCL code. DCL was used extensively in OFBiz, but it is clearly
>>>> documented to be an unreliable design (I can get it to fail 90% of the
>>>> time). Some DCL code has been replaced, but a lot of it is still there.
>>>>
>>>> Portions of the API are overly complicated. Some methods require a
>>>> collection of user-specified artifacts/arguments, which makes client
>>>> code complicated and verbose. (David solved that problem with his
>>>> Execution Context.) Portions of the API are cluttered with unnecessary
>>>> "convenience methods" - making the API harder to learn and memorize.
>>>> In some places, a domain-specific API is spread across instance
>>>> methods and static methods and across different classes - making the
>>>> API hard to understand and use. Yes, there can be good designs that
>>>> require something like that, but in the OFBiz framework, it exists
>>>> because of a bad design, not a good one.
>>>>
>>>> Use of thread-local variables. This makes multi-threaded design
>>>> impossible. The J2EE specification and the Servlet API require one
>>>> thread per request (and most J2EE libraries depend on that behavior),
>>>> so the current design makes sense from a J2EE perspective, but what if
>>>> I don't want to run the framework in a J2EE container? Which leads to
>>>> the next problem...
>>>>
>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>> Java community (myself included) who are beginning to question if J2EE
>>>> is really necessary to run web applications. The folks at Atomikos are
>>>> a good example. OFBiz does not use EJBs, so tying the framework to
>>>> J2EE does not make sense. It would be better if the framework was
>>>> designed to run outside a J2EE container, and then have container
>>>> integration as an option.
>>>>
>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>> OFBiz in a production environment will agree this is a problem. Try
>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>> configuration settings are in nonsensical places.
>>>>
>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>>>> we all have our fingers crossed - hoping that the framework code works
>>>> as expected. This was made painfully obvious a while back when I was
>>>> looking at some entity caching code and thought to myself "this code
>>>> can't work." So I wrote some entity cache unit tests and confirmed
>>>> that the entity cache had serious problems. Think about that - years
>>>> passed with no entity cache unit tests and consequently we had no idea
>>>> it wasn't working.
>>>>
>>>> Fix Versus Rewrite
>>>> ------------------
>>>>
>>>> Jira issues could be created for these problems and teams of
>>>> developers could work to fix them.
>>>>
>>>> Or, we could create a branch and start over from scratch. This time
>>>> around, there should be less push-back from people concerned about
>>>> backwards compatibility. A rewrite offers the advantage of
>>>> reconsidering everything - like API design, general problem solving,
>>>> and new features.
>>>>
>>>> I created a Wiki page for a framework design:
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>
>>>>
>>>>
>>>> but there hasn't been much interest in it. If the community decides to
>>>> go ahead with a rewrite, then please feel free to use the Wiki pages
>>>> as a guide.
>>>>
>>>> Sandglass Foundation
>>>> --------------------
>>>>
>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>> easier outside the OFBiz community. So, I created my own library
>>>> called Foundation:
>>>>
>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>
>>>>
>>>>
>>>> (PDF)
>>>>
>>>> and I only mention it here to stress how wonderful it can be to start
>>>> with a clean slate and design an API that is concise yet powerful.
>>>> (Please do not discuss Foundation here, contact me privately if you
>>>> want more information.)
>>>>
>>>> Some examples of what can be done with a rewrite:
>>>>
>>>>     A single configuration file
>>>>     Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>> complicated Java structures
>>>>     Simultaneous asynchronous queries
>>>>     Relational integrity across multiple datasources
>>>>     Multi-table SELECT across multiple datasources
>>>>     Automatic and transparent row version control
>>>>     Automatic and transparent multi-language datasource support
>>>>     Abstract entities (similar to SQL user types)
>>>>     Service engine throttling (protects against server
>>>> over-utilization)
>>>>     Simplified security (authorization)
>>>> (https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>
>>>>
>>>>     Pure interface-based API - so developers are free to modify
>>>> framework behavior by using decorators
>>>>     Thorough unit tests
>>>>
>>>> Benefits of a rewrite:
>>>>
>>>>     Reduced resource requirements (lower hosting fees)
>>>>     Reduce application development time - due to a simplified API
>>>>     Easier framework code maintenance
>>>>     Better reliability
>>>>
>>>> Conclusion
>>>> ----------
>>>>
>>>> Like I said at the start, this is all I will say about the subject.
>>>> I'm done trying to convince everyone. I hope someone agrees with me
>>>> and they are able to build support for the idea.
>>>>
>>>
>>>
>>
>
>

[Ron Wheeler]

This seems to be very good advice.
A completely separate sub-project under OFBiz with its own mailing lists
would keep the people together yet all allow the new framework the
flexibility to move forward.

Ron
On 14/10/2015 8:27 PM, Scott Gray wrote:

> My advice is as follows:
> 1. If people are interested, then get them together and start working on it.
> 2. Find somewhere to do the work.  I don't think a branch is appropriate
> because it's completely new development rather than a refactoring.  I don't
> have any objections to it being done under the ASF OFBiz umbrella (although
> I don't really see the need either).
> 3. Set up a separate mailing list for discussion.  Generally I'd try and
> keep quiet about it in the early stages on the dev/user lists or other
> marketing channels because it could potentially harm adoption of our
> existing framework (think AngularJS 2.0).
>
> There really isn't any need to get early stage sign-off from the PMC or
> anyone else in the community.  You only need enough PMC approval to get the
> required infrastructure sorted, which I don't think would be an issue.
> >From there, it's really up to the community to decide whether or not the
> thing will fly.
>
> Regards
> Scott
>
>
> On 15 October 2015 at 08:21, Adrian Crum <[hidden email]
>> wrote:
>> I understand that Sharan brought up the framework rewrite subject at
>> ApacheCon, and some attendees felt that the framework is fine and no action
>> needs to be taken.
>>
>> In this message, I will try to give a detailed explanation of why a
>> framework rewrite is necessary. I don't plan to take any further action on
>> this subject, because I've brought it up before without success, and I'm
>> tired of discussing it. It is my hope that the light bulb will click on in
>> someone's head and they will take action.
>>
>> My Background
>> -------------
>>
>> I became a member of the OFBiz community in 2004. I immediately started
>> making contributions to the project by supplying patches to the issue
>> tracker. In 2007, I became a committer. Most of my initial work was on the
>> UI and some work in the applications (mainly Asset Maintenance and Work
>> Effort). I stayed away from touching the framework code because it was
>> deep, dark, and scary.
>>
>> Eventually, I started to understand how the framework code works and I
>> made some minor modifications. As my understanding grew, I progressed to
>> rewriting large swaths of framework code - making it thread-safe, fault
>> tolerant, efficient, and easier to use.
>>
>> I will list some of my contributions here, so everyone can have a clear
>> understanding of my experience with the framework code:
>>
>>      New Features
>>
>>          User Preferences
>>
>>          Visual Themes
>>
>>          Custom UI Label XML File Format
>>
>>          Temporal Expressions
>>
>>          Data Type Conversion Framework
>>
>>          Screen Widget Boundary Comments
>>
>>          Metrics
>>
>>      Integrations
>>
>>          UEL
>>
>>          iCalendar
>>
>>          JSR 223
>>
>>          WebDAV
>>
>>          LDAP
>>
>>      Refactorings/Improvements
>>
>>          FlexibleStringExpander
>>
>>          FlexibleMapExpander
>>
>>          FOP Integration
>>
>>          FreeMarkerWorker
>>
>>          Date-Time Handling
>>
>>          Mini-language
>>
>>          Job Scheduler
>>
>> In addition, I have performed innumerable framework bug fixes.
>>
>> So, the contents of this message come from years of experience mucking
>> about in the framework code.
>>
>> Okay, let's get started...
>>
>> Initial Problem Statement
>> -------------------------
>>
>> In 2009, David Jones started a framework rewrite in a branch:
>>
>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>
>> At the time, there was some agreement that a rewrite was necessary, but
>> there was disagreement as to how the rewrite should be incorporated into
>> the project:
>>
>>
>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>
>> There were concerns that a rewrite would break backward compatibility.
>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>> community be more accepting of backward-incompatible changes:
>>
>>
>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>
>> Despite an effort to convince David to proceed with the framework rewrite,
>> he ended up doing it in a separate project:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>
>> This page describes differences between OFBiz and Moqui, and within it you
>> can extract information on the problems David was trying to solve:
>>
>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>
>> There was an email he sent out on the OFBiz dev list where he listed the
>> problems he saw in the framework, but I can't find it. The rest of this
>> message will include the issues he mentioned (the ones I remember). I was
>> in agreement with him at the time, and I still agree that a framework
>> rewrite is necessary.
>>
>> The Problems
>> ------------
>>
>> Code is scattered everywhere - due to an initial effort to make the
>> framework modular. This causes serious problems. The mere fact that
>> components like entityext and securityext EXIST makes it clear that there
>> are problems - those components should not be there. Also, we run into the
>> recurring problem of circular dependencies (component A will not build
>> unless component B is built, and component B will not build unless
>> component A is built).
>>
>> Bad separation of concerns. There are far too many examples of classes
>> that try to be everything to everyone. This makes debugging difficult, and
>> it makes maintenance/improvements a nightmare. [Using an analogy, consider
>> an automobile design where a spark plug is not separate from a
>> transmission. Instead, the automobile uses a spark-plug-transmission. So
>> when the engine is running rough because the spark plug is bad, you have to
>> replace the spark plug AND the transmission.] A good framework example can
>> be found in my rewrite of the mini-language code. Originally, the models
>> AND the script execution context both contained script behaviors - making
>> debugging/improvements difficult. I changed it so only the models contain
>> script behavior and the script execution context contains only the script
>> execution state.
>>
>> Lack of good OO design. There are many places where a bit of framework
>> functionality is contained in a single method that is hundreds or thousands
>> of lines long. There is a term for that: Brittle Code. Code isn't reused.
>> Instead, it is copy-and-pasted all over - so when a problem is found in the
>> C&P code, it has to be fixed in many places instead of one.
>>
>> Fail-slow design. There are a lot of places in low-level code where an
>> error condition is encountered, but instead of throwing an exception, the
>> error is ignored and maybe it is logged, or the code tries to "guess" at a
>> solution and then provide an arbitrary default behavior. I've seen many
>> developers struggle with debugging a problem because they didn't look at
>> the logs, or because the error was not logged and there is no way of
>> knowing what caused it. They end up spending hours single-stepping through
>> code until it reaches the error.
>>
>> Out-of-date code. A good example is the use of Javolution. That library
>> was beneficial in the Java 1.4 days, but it is not necessary today because
>> of improved garbage collection. Another good example is DCL code. DCL was
>> used extensively in OFBiz, but it is clearly documented to be an unreliable
>> design (I can get it to fail 90% of the time). Some DCL code has been
>> replaced, but a lot of it is still there.
>>
>> Portions of the API are overly complicated. Some methods require a
>> collection of user-specified artifacts/arguments, which makes client code
>> complicated and verbose. (David solved that problem with his Execution
>> Context.) Portions of the API are cluttered with unnecessary "convenience
>> methods" - making the API harder to learn and memorize. In some places, a
>> domain-specific API is spread across instance methods and static methods
>> and across different classes - making the API hard to understand and use.
>> Yes, there can be good designs that require something like that, but in the
>> OFBiz framework, it exists because of a bad design, not a good one.
>>
>> Use of thread-local variables. This makes multi-threaded design
>> impossible. The J2EE specification and the Servlet API require one thread
>> per request (and most J2EE libraries depend on that behavior), so the
>> current design makes sense from a J2EE perspective, but what if I don't
>> want to run the framework in a J2EE container? Which leads to the next
>> problem...
>>
>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>> Java community (myself included) who are beginning to question if J2EE is
>> really necessary to run web applications. The folks at Atomikos are a good
>> example. OFBiz does not use EJBs, so tying the framework to J2EE does not
>> make sense. It would be better if the framework was designed to run outside
>> a J2EE container, and then have container integration as an option.
>>
>> Configuration files are scattered everywhere. Anyone who has deployed
>> OFBiz in a production environment will agree this is a problem. Try
>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>> configuration settings are in nonsensical places.
>>
>> An abysmal lack of unit testing. I don't have an exact figure for code
>> coverage, but my gut feeling is coverage is less than 10%. Basically, we
>> all have our fingers crossed - hoping that the framework code works as
>> expected. This was made painfully obvious a while back when I was looking
>> at some entity caching code and thought to myself "this code can't work."
>> So I wrote some entity cache unit tests and confirmed that the entity cache
>> had serious problems. Think about that - years passed with no entity cache
>> unit tests and consequently we had no idea it wasn't working.
>>
>> Fix Versus Rewrite
>> ------------------
>>
>> Jira issues could be created for these problems and teams of developers
>> could work to fix them.
>>
>> Or, we could create a branch and start over from scratch. This time
>> around, there should be less push-back from people concerned about
>> backwards compatibility. A rewrite offers the advantage of reconsidering
>> everything - like API design, general problem solving, and new features.
>>
>> I created a Wiki page for a framework design:
>>
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>
>> but there hasn't been much interest in it. If the community decides to go
>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>> guide.
>>
>> Sandglass Foundation
>> --------------------
>>
>> Like David, I came to the conclusion that a framework rewrite would be
>> easier outside the OFBiz community. So, I created my own library called
>> Foundation:
>>
>>
>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>
>> (PDF)
>>
>> and I only mention it here to stress how wonderful it can be to start with
>> a clean slate and design an API that is concise yet powerful. (Please do
>> not discuss Foundation here, contact me privately if you want more
>> information.)
>>
>> Some examples of what can be done with a rewrite:
>>
>>      A single configuration file
>>      Use ANSI/ISO SQL SELECT statement strings instead of constructing
>> complicated Java structures
>>      Simultaneous asynchronous queries
>>      Relational integrity across multiple datasources
>>      Multi-table SELECT across multiple datasources
>>      Automatic and transparent row version control
>>      Automatic and transparent multi-language datasource support
>>      Abstract entities (similar to SQL user types)
>>      Service engine throttling (protects against server over-utilization)
>>      Simplified security (authorization) (
>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>      Pure interface-based API - so developers are free to modify framework
>> behavior by using decorators
>>      Thorough unit tests
>>
>> Benefits of a rewrite:
>>
>>      Reduced resource requirements (lower hosting fees)
>>      Reduce application development time - due to a simplified API
>>      Easier framework code maintenance
>>      Better reliability
>>
>> Conclusion
>> ----------
>>
>> Like I said at the start, this is all I will say about the subject. I'm
>> done trying to convince everyone. I hope someone agrees with me and they
>> are able to build support for the idea.
>>
>> --
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Adrian Crum-3]

I agree that a sub-project would be nice to have. Once the new framework
is up and running, applications could be pulled down and adapted to it.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/14/2015 5:53 PM, Ron Wheeler wrote:

> This seems to be very good advice.
> A completely separate sub-project under OFBiz with its own mailing lists
> would keep the people together yet all allow the new framework the
> flexibility to move forward.
>
> Ron
> On 14/10/2015 8:27 PM, Scott Gray wrote:
>> My advice is as follows:
>> 1. If people are interested, then get them together and start working
>> on it.
>> 2. Find somewhere to do the work.  I don't think a branch is appropriate
>> because it's completely new development rather than a refactoring.  I
>> don't
>> have any objections to it being done under the ASF OFBiz umbrella
>> (although
>> I don't really see the need either).
>> 3. Set up a separate mailing list for discussion.  Generally I'd try and
>> keep quiet about it in the early stages on the dev/user lists or other
>> marketing channels because it could potentially harm adoption of our
>> existing framework (think AngularJS 2.0).
>>
>> There really isn't any need to get early stage sign-off from the PMC or
>> anyone else in the community.  You only need enough PMC approval to
>> get the
>> required infrastructure sorted, which I don't think would be an issue.
>> >From there, it's really up to the community to decide whether or not the
>> thing will fly.
>>
>> Regards
>> Scott
>>
>>
>> On 15 October 2015 at 08:21, Adrian Crum
>> <[hidden email]
>>> wrote:
>>> I understand that Sharan brought up the framework rewrite subject at
>>> ApacheCon, and some attendees felt that the framework is fine and no
>>> action
>>> needs to be taken.
>>>
>>> In this message, I will try to give a detailed explanation of why a
>>> framework rewrite is necessary. I don't plan to take any further
>>> action on
>>> this subject, because I've brought it up before without success, and I'm
>>> tired of discussing it. It is my hope that the light bulb will click
>>> on in
>>> someone's head and they will take action.
>>>
>>> My Background
>>> -------------
>>>
>>> I became a member of the OFBiz community in 2004. I immediately started
>>> making contributions to the project by supplying patches to the issue
>>> tracker. In 2007, I became a committer. Most of my initial work was
>>> on the
>>> UI and some work in the applications (mainly Asset Maintenance and Work
>>> Effort). I stayed away from touching the framework code because it was
>>> deep, dark, and scary.
>>>
>>> Eventually, I started to understand how the framework code works and I
>>> made some minor modifications. As my understanding grew, I progressed to
>>> rewriting large swaths of framework code - making it thread-safe, fault
>>> tolerant, efficient, and easier to use.
>>>
>>> I will list some of my contributions here, so everyone can have a clear
>>> understanding of my experience with the framework code:
>>>
>>>      New Features
>>>
>>>          User Preferences
>>>
>>>          Visual Themes
>>>
>>>          Custom UI Label XML File Format
>>>
>>>          Temporal Expressions
>>>
>>>          Data Type Conversion Framework
>>>
>>>          Screen Widget Boundary Comments
>>>
>>>          Metrics
>>>
>>>      Integrations
>>>
>>>          UEL
>>>
>>>          iCalendar
>>>
>>>          JSR 223
>>>
>>>          WebDAV
>>>
>>>          LDAP
>>>
>>>      Refactorings/Improvements
>>>
>>>          FlexibleStringExpander
>>>
>>>          FlexibleMapExpander
>>>
>>>          FOP Integration
>>>
>>>          FreeMarkerWorker
>>>
>>>          Date-Time Handling
>>>
>>>          Mini-language
>>>
>>>          Job Scheduler
>>>
>>> In addition, I have performed innumerable framework bug fixes.
>>>
>>> So, the contents of this message come from years of experience mucking
>>> about in the framework code.
>>>
>>> Okay, let's get started...
>>>
>>> Initial Problem Statement
>>> -------------------------
>>>
>>> In 2009, David Jones started a framework rewrite in a branch:
>>>
>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>
>>> At the time, there was some agreement that a rewrite was necessary, but
>>> there was disagreement as to how the rewrite should be incorporated into
>>> the project:
>>>
>>>
>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>
>>>
>>> There were concerns that a rewrite would break backward compatibility.
>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>> community be more accepting of backward-incompatible changes:
>>>
>>>
>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>
>>>
>>> Despite an effort to convince David to proceed with the framework
>>> rewrite,
>>> he ended up doing it in a separate project:
>>>
>>>
>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>
>>>
>>> This page describes differences between OFBiz and Moqui, and within
>>> it you
>>> can extract information on the problems David was trying to solve:
>>>
>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>
>>> There was an email he sent out on the OFBiz dev list where he listed the
>>> problems he saw in the framework, but I can't find it. The rest of this
>>> message will include the issues he mentioned (the ones I remember). I
>>> was
>>> in agreement with him at the time, and I still agree that a framework
>>> rewrite is necessary.
>>>
>>> The Problems
>>> ------------
>>>
>>> Code is scattered everywhere - due to an initial effort to make the
>>> framework modular. This causes serious problems. The mere fact that
>>> components like entityext and securityext EXIST makes it clear that
>>> there
>>> are problems - those components should not be there. Also, we run
>>> into the
>>> recurring problem of circular dependencies (component A will not build
>>> unless component B is built, and component B will not build unless
>>> component A is built).
>>>
>>> Bad separation of concerns. There are far too many examples of classes
>>> that try to be everything to everyone. This makes debugging
>>> difficult, and
>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>> consider
>>> an automobile design where a spark plug is not separate from a
>>> transmission. Instead, the automobile uses a spark-plug-transmission. So
>>> when the engine is running rough because the spark plug is bad, you
>>> have to
>>> replace the spark plug AND the transmission.] A good framework
>>> example can
>>> be found in my rewrite of the mini-language code. Originally, the models
>>> AND the script execution context both contained script behaviors -
>>> making
>>> debugging/improvements difficult. I changed it so only the models
>>> contain
>>> script behavior and the script execution context contains only the
>>> script
>>> execution state.
>>>
>>> Lack of good OO design. There are many places where a bit of framework
>>> functionality is contained in a single method that is hundreds or
>>> thousands
>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>> reused.
>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>> in the
>>> C&P code, it has to be fixed in many places instead of one.
>>>
>>> Fail-slow design. There are a lot of places in low-level code where an
>>> error condition is encountered, but instead of throwing an exception,
>>> the
>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>> at a
>>> solution and then provide an arbitrary default behavior. I've seen many
>>> developers struggle with debugging a problem because they didn't look at
>>> the logs, or because the error was not logged and there is no way of
>>> knowing what caused it. They end up spending hours single-stepping
>>> through
>>> code until it reaches the error.
>>>
>>> Out-of-date code. A good example is the use of Javolution. That library
>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>> because
>>> of improved garbage collection. Another good example is DCL code. DCL
>>> was
>>> used extensively in OFBiz, but it is clearly documented to be an
>>> unreliable
>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>> replaced, but a lot of it is still there.
>>>
>>> Portions of the API are overly complicated. Some methods require a
>>> collection of user-specified artifacts/arguments, which makes client
>>> code
>>> complicated and verbose. (David solved that problem with his Execution
>>> Context.) Portions of the API are cluttered with unnecessary
>>> "convenience
>>> methods" - making the API harder to learn and memorize. In some
>>> places, a
>>> domain-specific API is spread across instance methods and static methods
>>> and across different classes - making the API hard to understand and
>>> use.
>>> Yes, there can be good designs that require something like that, but
>>> in the
>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>
>>> Use of thread-local variables. This makes multi-threaded design
>>> impossible. The J2EE specification and the Servlet API require one
>>> thread
>>> per request (and most J2EE libraries depend on that behavior), so the
>>> current design makes sense from a J2EE perspective, but what if I don't
>>> want to run the framework in a J2EE container? Which leads to the next
>>> problem...
>>>
>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>> Java community (myself included) who are beginning to question if
>>> J2EE is
>>> really necessary to run web applications. The folks at Atomikos are a
>>> good
>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>> not
>>> make sense. It would be better if the framework was designed to run
>>> outside
>>> a J2EE container, and then have container integration as an option.
>>>
>>> Configuration files are scattered everywhere. Anyone who has deployed
>>> OFBiz in a production environment will agree this is a problem. Try
>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>> configuration settings are in nonsensical places.
>>>
>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>> coverage, but my gut feeling is coverage is less than 10%. Basically, we
>>> all have our fingers crossed - hoping that the framework code works as
>>> expected. This was made painfully obvious a while back when I was
>>> looking
>>> at some entity caching code and thought to myself "this code can't
>>> work."
>>> So I wrote some entity cache unit tests and confirmed that the entity
>>> cache
>>> had serious problems. Think about that - years passed with no entity
>>> cache
>>> unit tests and consequently we had no idea it wasn't working.
>>>
>>> Fix Versus Rewrite
>>> ------------------
>>>
>>> Jira issues could be created for these problems and teams of developers
>>> could work to fix them.
>>>
>>> Or, we could create a branch and start over from scratch. This time
>>> around, there should be less push-back from people concerned about
>>> backwards compatibility. A rewrite offers the advantage of reconsidering
>>> everything - like API design, general problem solving, and new features.
>>>
>>> I created a Wiki page for a framework design:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>
>>>
>>> but there hasn't been much interest in it. If the community decides
>>> to go
>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>> guide.
>>>
>>> Sandglass Foundation
>>> --------------------
>>>
>>> Like David, I came to the conclusion that a framework rewrite would be
>>> easier outside the OFBiz community. So, I created my own library called
>>> Foundation:
>>>
>>>
>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>
>>>
>>> (PDF)
>>>
>>> and I only mention it here to stress how wonderful it can be to start
>>> with
>>> a clean slate and design an API that is concise yet powerful. (Please do
>>> not discuss Foundation here, contact me privately if you want more
>>> information.)
>>>
>>> Some examples of what can be done with a rewrite:
>>>
>>>      A single configuration file
>>>      Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>> complicated Java structures
>>>      Simultaneous asynchronous queries
>>>      Relational integrity across multiple datasources
>>>      Multi-table SELECT across multiple datasources
>>>      Automatic and transparent row version control
>>>      Automatic and transparent multi-language datasource support
>>>      Abstract entities (similar to SQL user types)
>>>      Service engine throttling (protects against server
>>> over-utilization)
>>>      Simplified security (authorization) (
>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>
>>>      Pure interface-based API - so developers are free to modify
>>> framework
>>> behavior by using decorators
>>>      Thorough unit tests
>>>
>>> Benefits of a rewrite:
>>>
>>>      Reduced resource requirements (lower hosting fees)
>>>      Reduce application development time - due to a simplified API
>>>      Easier framework code maintenance
>>>      Better reliability
>>>
>>> Conclusion
>>> ----------
>>>
>>> Like I said at the start, this is all I will say about the subject. I'm
>>> done trying to convince everyone. I hope someone agrees with me and they
>>> are able to build support for the idea.
>>>
>>> --
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>
>

[Jacques Le Roux]

I'm in the same mood than Paul and Scott. So a sub-project could indeed be a solution.

Jacques

Le 15/10/2015 03:11, Adrian Crum a écrit :

> I agree that a sub-project would be nice to have. Once the new framework is up and running, applications could be pulled down and adapted to it.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>> This seems to be very good advice.
>> A completely separate sub-project under OFBiz with its own mailing lists
>> would keep the people together yet all allow the new framework the
>> flexibility to move forward.
>>
>> Ron
>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>> My advice is as follows:
>>> 1. If people are interested, then get them together and start working
>>> on it.
>>> 2. Find somewhere to do the work.  I don't think a branch is appropriate
>>> because it's completely new development rather than a refactoring.  I
>>> don't
>>> have any objections to it being done under the ASF OFBiz umbrella
>>> (although
>>> I don't really see the need either).
>>> 3. Set up a separate mailing list for discussion.  Generally I'd try and
>>> keep quiet about it in the early stages on the dev/user lists or other
>>> marketing channels because it could potentially harm adoption of our
>>> existing framework (think AngularJS 2.0).
>>>
>>> There really isn't any need to get early stage sign-off from the PMC or
>>> anyone else in the community.  You only need enough PMC approval to
>>> get the
>>> required infrastructure sorted, which I don't think would be an issue.
>>> >From there, it's really up to the community to decide whether or not the
>>> thing will fly.
>>>
>>> Regards
>>> Scott
>>>
>>>
>>> On 15 October 2015 at 08:21, Adrian Crum
>>> <[hidden email]
>>>> wrote:
>>>> I understand that Sharan brought up the framework rewrite subject at
>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>> action
>>>> needs to be taken.
>>>>
>>>> In this message, I will try to give a detailed explanation of why a
>>>> framework rewrite is necessary. I don't plan to take any further
>>>> action on
>>>> this subject, because I've brought it up before without success, and I'm
>>>> tired of discussing it. It is my hope that the light bulb will click
>>>> on in
>>>> someone's head and they will take action.
>>>>
>>>> My Background
>>>> -------------
>>>>
>>>> I became a member of the OFBiz community in 2004. I immediately started
>>>> making contributions to the project by supplying patches to the issue
>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>> on the
>>>> UI and some work in the applications (mainly Asset Maintenance and Work
>>>> Effort). I stayed away from touching the framework code because it was
>>>> deep, dark, and scary.
>>>>
>>>> Eventually, I started to understand how the framework code works and I
>>>> made some minor modifications. As my understanding grew, I progressed to
>>>> rewriting large swaths of framework code - making it thread-safe, fault
>>>> tolerant, efficient, and easier to use.
>>>>
>>>> I will list some of my contributions here, so everyone can have a clear
>>>> understanding of my experience with the framework code:
>>>>
>>>>      New Features
>>>>
>>>>          User Preferences
>>>>
>>>>          Visual Themes
>>>>
>>>>          Custom UI Label XML File Format
>>>>
>>>>          Temporal Expressions
>>>>
>>>>          Data Type Conversion Framework
>>>>
>>>>          Screen Widget Boundary Comments
>>>>
>>>>          Metrics
>>>>
>>>>      Integrations
>>>>
>>>>          UEL
>>>>
>>>>          iCalendar
>>>>
>>>>          JSR 223
>>>>
>>>>          WebDAV
>>>>
>>>>          LDAP
>>>>
>>>>      Refactorings/Improvements
>>>>
>>>>          FlexibleStringExpander
>>>>
>>>>          FlexibleMapExpander
>>>>
>>>>          FOP Integration
>>>>
>>>>          FreeMarkerWorker
>>>>
>>>>          Date-Time Handling
>>>>
>>>>          Mini-language
>>>>
>>>>          Job Scheduler
>>>>
>>>> In addition, I have performed innumerable framework bug fixes.
>>>>
>>>> So, the contents of this message come from years of experience mucking
>>>> about in the framework code.
>>>>
>>>> Okay, let's get started...
>>>>
>>>> Initial Problem Statement
>>>> -------------------------
>>>>
>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>
>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>
>>>> At the time, there was some agreement that a rewrite was necessary, but
>>>> there was disagreement as to how the rewrite should be incorporated into
>>>> the project:
>>>>
>>>>
>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>
>>>>
>>>> There were concerns that a rewrite would break backward compatibility.
>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>> community be more accepting of backward-incompatible changes:
>>>>
>>>>
>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>
>>>>
>>>> Despite an effort to convince David to proceed with the framework
>>>> rewrite,
>>>> he ended up doing it in a separate project:
>>>>
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>
>>>>
>>>> This page describes differences between OFBiz and Moqui, and within
>>>> it you
>>>> can extract information on the problems David was trying to solve:
>>>>
>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>
>>>> There was an email he sent out on the OFBiz dev list where he listed the
>>>> problems he saw in the framework, but I can't find it. The rest of this
>>>> message will include the issues he mentioned (the ones I remember). I
>>>> was
>>>> in agreement with him at the time, and I still agree that a framework
>>>> rewrite is necessary.
>>>>
>>>> The Problems
>>>> ------------
>>>>
>>>> Code is scattered everywhere - due to an initial effort to make the
>>>> framework modular. This causes serious problems. The mere fact that
>>>> components like entityext and securityext EXIST makes it clear that
>>>> there
>>>> are problems - those components should not be there. Also, we run
>>>> into the
>>>> recurring problem of circular dependencies (component A will not build
>>>> unless component B is built, and component B will not build unless
>>>> component A is built).
>>>>
>>>> Bad separation of concerns. There are far too many examples of classes
>>>> that try to be everything to everyone. This makes debugging
>>>> difficult, and
>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>> consider
>>>> an automobile design where a spark plug is not separate from a
>>>> transmission. Instead, the automobile uses a spark-plug-transmission. So
>>>> when the engine is running rough because the spark plug is bad, you
>>>> have to
>>>> replace the spark plug AND the transmission.] A good framework
>>>> example can
>>>> be found in my rewrite of the mini-language code. Originally, the models
>>>> AND the script execution context both contained script behaviors -
>>>> making
>>>> debugging/improvements difficult. I changed it so only the models
>>>> contain
>>>> script behavior and the script execution context contains only the
>>>> script
>>>> execution state.
>>>>
>>>> Lack of good OO design. There are many places where a bit of framework
>>>> functionality is contained in a single method that is hundreds or
>>>> thousands
>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>> reused.
>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>> in the
>>>> C&P code, it has to be fixed in many places instead of one.
>>>>
>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>> error condition is encountered, but instead of throwing an exception,
>>>> the
>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>> at a
>>>> solution and then provide an arbitrary default behavior. I've seen many
>>>> developers struggle with debugging a problem because they didn't look at
>>>> the logs, or because the error was not logged and there is no way of
>>>> knowing what caused it. They end up spending hours single-stepping
>>>> through
>>>> code until it reaches the error.
>>>>
>>>> Out-of-date code. A good example is the use of Javolution. That library
>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>> because
>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>> was
>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>> unreliable
>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>> replaced, but a lot of it is still there.
>>>>
>>>> Portions of the API are overly complicated. Some methods require a
>>>> collection of user-specified artifacts/arguments, which makes client
>>>> code
>>>> complicated and verbose. (David solved that problem with his Execution
>>>> Context.) Portions of the API are cluttered with unnecessary
>>>> "convenience
>>>> methods" - making the API harder to learn and memorize. In some
>>>> places, a
>>>> domain-specific API is spread across instance methods and static methods
>>>> and across different classes - making the API hard to understand and
>>>> use.
>>>> Yes, there can be good designs that require something like that, but
>>>> in the
>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>
>>>> Use of thread-local variables. This makes multi-threaded design
>>>> impossible. The J2EE specification and the Servlet API require one
>>>> thread
>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>> current design makes sense from a J2EE perspective, but what if I don't
>>>> want to run the framework in a J2EE container? Which leads to the next
>>>> problem...
>>>>
>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>> Java community (myself included) who are beginning to question if
>>>> J2EE is
>>>> really necessary to run web applications. The folks at Atomikos are a
>>>> good
>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>> not
>>>> make sense. It would be better if the framework was designed to run
>>>> outside
>>>> a J2EE container, and then have container integration as an option.
>>>>
>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>> OFBiz in a production environment will agree this is a problem. Try
>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>> configuration settings are in nonsensical places.
>>>>
>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>> coverage, but my gut feeling is coverage is less than 10%. Basically, we
>>>> all have our fingers crossed - hoping that the framework code works as
>>>> expected. This was made painfully obvious a while back when I was
>>>> looking
>>>> at some entity caching code and thought to myself "this code can't
>>>> work."
>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>> cache
>>>> had serious problems. Think about that - years passed with no entity
>>>> cache
>>>> unit tests and consequently we had no idea it wasn't working.
>>>>
>>>> Fix Versus Rewrite
>>>> ------------------
>>>>
>>>> Jira issues could be created for these problems and teams of developers
>>>> could work to fix them.
>>>>
>>>> Or, we could create a branch and start over from scratch. This time
>>>> around, there should be less push-back from people concerned about
>>>> backwards compatibility. A rewrite offers the advantage of reconsidering
>>>> everything - like API design, general problem solving, and new features.
>>>>
>>>> I created a Wiki page for a framework design:
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>
>>>>
>>>> but there hasn't been much interest in it. If the community decides
>>>> to go
>>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>>> guide.
>>>>
>>>> Sandglass Foundation
>>>> --------------------
>>>>
>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>> easier outside the OFBiz community. So, I created my own library called
>>>> Foundation:
>>>>
>>>>
>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>
>>>>
>>>> (PDF)
>>>>
>>>> and I only mention it here to stress how wonderful it can be to start
>>>> with
>>>> a clean slate and design an API that is concise yet powerful. (Please do
>>>> not discuss Foundation here, contact me privately if you want more
>>>> information.)
>>>>
>>>> Some examples of what can be done with a rewrite:
>>>>
>>>>      A single configuration file
>>>>      Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>> complicated Java structures
>>>>      Simultaneous asynchronous queries
>>>>      Relational integrity across multiple datasources
>>>>      Multi-table SELECT across multiple datasources
>>>>      Automatic and transparent row version control
>>>>      Automatic and transparent multi-language datasource support
>>>>      Abstract entities (similar to SQL user types)
>>>>      Service engine throttling (protects against server
>>>> over-utilization)
>>>>      Simplified security (authorization) (
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>
>>>>      Pure interface-based API - so developers are free to modify
>>>> framework
>>>> behavior by using decorators
>>>>      Thorough unit tests
>>>>
>>>> Benefits of a rewrite:
>>>>
>>>>      Reduced resource requirements (lower hosting fees)
>>>>      Reduce application development time - due to a simplified API
>>>>      Easier framework code maintenance
>>>>      Better reliability
>>>>
>>>> Conclusion
>>>> ----------
>>>>
>>>> Like I said at the start, this is all I will say about the subject. I'm
>>>> done trying to convince everyone. I hope someone agrees with me and they
>>>> are able to build support for the idea.
>>>>
>>>> --
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>
>>
>

[Hans Bakker]

Why not skip this step, using moqui which is already up and running and
then as Adrian states as a next step: applications could be pulled down
and adapted to it.

Hans


On 15/10/15 16:51, Jacques Le Roux wrote:

> I'm in the same mood than Paul and Scott. So a sub-project could
> indeed be a solution.
>
> Jacques
>
> Le 15/10/2015 03:11, Adrian Crum a écrit :
>> I agree that a sub-project would be nice to have. Once the new
>> framework is up and running, applications could be pulled down and
>> adapted to it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>> This seems to be very good advice.
>>> A completely separate sub-project under OFBiz with its own mailing
>>> lists
>>> would keep the people together yet all allow the new framework the
>>> flexibility to move forward.
>>>
>>> Ron
>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>> My advice is as follows:
>>>> 1. If people are interested, then get them together and start working
>>>> on it.
>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>> appropriate
>>>> because it's completely new development rather than a refactoring.  I
>>>> don't
>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>> (although
>>>> I don't really see the need either).
>>>> 3. Set up a separate mailing list for discussion.  Generally I'd
>>>> try and
>>>> keep quiet about it in the early stages on the dev/user lists or other
>>>> marketing channels because it could potentially harm adoption of our
>>>> existing framework (think AngularJS 2.0).
>>>>
>>>> There really isn't any need to get early stage sign-off from the
>>>> PMC or
>>>> anyone else in the community.  You only need enough PMC approval to
>>>> get the
>>>> required infrastructure sorted, which I don't think would be an issue.
>>>> >From there, it's really up to the community to decide whether or
>>>> not the
>>>> thing will fly.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>>
>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>> <[hidden email]
>>>>> wrote:
>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>> action
>>>>> needs to be taken.
>>>>>
>>>>> In this message, I will try to give a detailed explanation of why a
>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>> action on
>>>>> this subject, because I've brought it up before without success,
>>>>> and I'm
>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>> on in
>>>>> someone's head and they will take action.
>>>>>
>>>>> My Background
>>>>> -------------
>>>>>
>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>> started
>>>>> making contributions to the project by supplying patches to the issue
>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>> on the
>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>> Work
>>>>> Effort). I stayed away from touching the framework code because it
>>>>> was
>>>>> deep, dark, and scary.
>>>>>
>>>>> Eventually, I started to understand how the framework code works
>>>>> and I
>>>>> made some minor modifications. As my understanding grew, I
>>>>> progressed to
>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>> fault
>>>>> tolerant, efficient, and easier to use.
>>>>>
>>>>> I will list some of my contributions here, so everyone can have a
>>>>> clear
>>>>> understanding of my experience with the framework code:
>>>>>
>>>>>      New Features
>>>>>
>>>>>          User Preferences
>>>>>
>>>>>          Visual Themes
>>>>>
>>>>>          Custom UI Label XML File Format
>>>>>
>>>>>          Temporal Expressions
>>>>>
>>>>>          Data Type Conversion Framework
>>>>>
>>>>>          Screen Widget Boundary Comments
>>>>>
>>>>>          Metrics
>>>>>
>>>>>      Integrations
>>>>>
>>>>>          UEL
>>>>>
>>>>>          iCalendar
>>>>>
>>>>>          JSR 223
>>>>>
>>>>>          WebDAV
>>>>>
>>>>>          LDAP
>>>>>
>>>>>      Refactorings/Improvements
>>>>>
>>>>>          FlexibleStringExpander
>>>>>
>>>>>          FlexibleMapExpander
>>>>>
>>>>>          FOP Integration
>>>>>
>>>>>          FreeMarkerWorker
>>>>>
>>>>>          Date-Time Handling
>>>>>
>>>>>          Mini-language
>>>>>
>>>>>          Job Scheduler
>>>>>
>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>
>>>>> So, the contents of this message come from years of experience
>>>>> mucking
>>>>> about in the framework code.
>>>>>
>>>>> Okay, let's get started...
>>>>>
>>>>> Initial Problem Statement
>>>>> -------------------------
>>>>>
>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>
>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716 
>>>>>
>>>>>
>>>>> At the time, there was some agreement that a rewrite was
>>>>> necessary, but
>>>>> there was disagreement as to how the rewrite should be
>>>>> incorporated into
>>>>> the project:
>>>>>
>>>>>
>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E 
>>>>>
>>>>>
>>>>>
>>>>> There were concerns that a rewrite would break backward
>>>>> compatibility.
>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>> community be more accepting of backward-incompatible changes:
>>>>>
>>>>>
>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e 
>>>>>
>>>>>
>>>>>
>>>>> Despite an effort to convince David to proceed with the framework
>>>>> rewrite,
>>>>> he ended up doing it in a separate project:
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E 
>>>>>
>>>>>
>>>>>
>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>> it you
>>>>> can extract information on the problems David was trying to solve:
>>>>>
>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>
>>>>> There was an email he sent out on the OFBiz dev list where he
>>>>> listed the
>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>> this
>>>>> message will include the issues he mentioned (the ones I remember). I
>>>>> was
>>>>> in agreement with him at the time, and I still agree that a framework
>>>>> rewrite is necessary.
>>>>>
>>>>> The Problems
>>>>> ------------
>>>>>
>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>> framework modular. This causes serious problems. The mere fact that
>>>>> components like entityext and securityext EXIST makes it clear that
>>>>> there
>>>>> are problems - those components should not be there. Also, we run
>>>>> into the
>>>>> recurring problem of circular dependencies (component A will not
>>>>> build
>>>>> unless component B is built, and component B will not build unless
>>>>> component A is built).
>>>>>
>>>>> Bad separation of concerns. There are far too many examples of
>>>>> classes
>>>>> that try to be everything to everyone. This makes debugging
>>>>> difficult, and
>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>> consider
>>>>> an automobile design where a spark plug is not separate from a
>>>>> transmission. Instead, the automobile uses a
>>>>> spark-plug-transmission. So
>>>>> when the engine is running rough because the spark plug is bad, you
>>>>> have to
>>>>> replace the spark plug AND the transmission.] A good framework
>>>>> example can
>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>> models
>>>>> AND the script execution context both contained script behaviors -
>>>>> making
>>>>> debugging/improvements difficult. I changed it so only the models
>>>>> contain
>>>>> script behavior and the script execution context contains only the
>>>>> script
>>>>> execution state.
>>>>>
>>>>> Lack of good OO design. There are many places where a bit of
>>>>> framework
>>>>> functionality is contained in a single method that is hundreds or
>>>>> thousands
>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>> reused.
>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>> in the
>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>
>>>>> Fail-slow design. There are a lot of places in low-level code
>>>>> where an
>>>>> error condition is encountered, but instead of throwing an exception,
>>>>> the
>>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>>> at a
>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>> many
>>>>> developers struggle with debugging a problem because they didn't
>>>>> look at
>>>>> the logs, or because the error was not logged and there is no way of
>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>> through
>>>>> code until it reaches the error.
>>>>>
>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>> library
>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>> because
>>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>>> was
>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>> unreliable
>>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>>> replaced, but a lot of it is still there.
>>>>>
>>>>> Portions of the API are overly complicated. Some methods require a
>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>> code
>>>>> complicated and verbose. (David solved that problem with his
>>>>> Execution
>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>> "convenience
>>>>> methods" - making the API harder to learn and memorize. In some
>>>>> places, a
>>>>> domain-specific API is spread across instance methods and static
>>>>> methods
>>>>> and across different classes - making the API hard to understand and
>>>>> use.
>>>>> Yes, there can be good designs that require something like that, but
>>>>> in the
>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>
>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>> thread
>>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>> don't
>>>>> want to run the framework in a J2EE container? Which leads to the
>>>>> next
>>>>> problem...
>>>>>
>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in
>>>>> the
>>>>> Java community (myself included) who are beginning to question if
>>>>> J2EE is
>>>>> really necessary to run web applications. The folks at Atomikos are a
>>>>> good
>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>>> not
>>>>> make sense. It would be better if the framework was designed to run
>>>>> outside
>>>>> a J2EE container, and then have container integration as an option.
>>>>>
>>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>> configuration settings are in nonsensical places.
>>>>>
>>>>> An abysmal lack of unit testing. I don't have an exact figure for
>>>>> code
>>>>> coverage, but my gut feeling is coverage is less than 10%.
>>>>> Basically, we
>>>>> all have our fingers crossed - hoping that the framework code
>>>>> works as
>>>>> expected. This was made painfully obvious a while back when I was
>>>>> looking
>>>>> at some entity caching code and thought to myself "this code can't
>>>>> work."
>>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>>> cache
>>>>> had serious problems. Think about that - years passed with no entity
>>>>> cache
>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>
>>>>> Fix Versus Rewrite
>>>>> ------------------
>>>>>
>>>>> Jira issues could be created for these problems and teams of
>>>>> developers
>>>>> could work to fix them.
>>>>>
>>>>> Or, we could create a branch and start over from scratch. This time
>>>>> around, there should be less push-back from people concerned about
>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>> reconsidering
>>>>> everything - like API design, general problem solving, and new
>>>>> features.
>>>>>
>>>>> I created a Wiki page for a framework design:
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision 
>>>>>
>>>>>
>>>>>
>>>>> but there hasn't been much interest in it. If the community decides
>>>>> to go
>>>>> ahead with a rewrite, then please feel free to use the Wiki pages
>>>>> as a
>>>>> guide.
>>>>>
>>>>> Sandglass Foundation
>>>>> --------------------
>>>>>
>>>>> Like David, I came to the conclusion that a framework rewrite
>>>>> would be
>>>>> easier outside the OFBiz community. So, I created my own library
>>>>> called
>>>>> Foundation:
>>>>>
>>>>>
>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf 
>>>>>
>>>>>
>>>>>
>>>>> (PDF)
>>>>>
>>>>> and I only mention it here to stress how wonderful it can be to start
>>>>> with
>>>>> a clean slate and design an API that is concise yet powerful.
>>>>> (Please do
>>>>> not discuss Foundation here, contact me privately if you want more
>>>>> information.)
>>>>>
>>>>> Some examples of what can be done with a rewrite:
>>>>>
>>>>>      A single configuration file
>>>>>      Use ANSI/ISO SQL SELECT statement strings instead of
>>>>> constructing
>>>>> complicated Java structures
>>>>>      Simultaneous asynchronous queries
>>>>>      Relational integrity across multiple datasources
>>>>>      Multi-table SELECT across multiple datasources
>>>>>      Automatic and transparent row version control
>>>>>      Automatic and transparent multi-language datasource support
>>>>>      Abstract entities (similar to SQL user types)
>>>>>      Service engine throttling (protects against server
>>>>> over-utilization)
>>>>>      Simplified security (authorization) (
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>>
>>>>>
>>>>>      Pure interface-based API - so developers are free to modify
>>>>> framework
>>>>> behavior by using decorators
>>>>>      Thorough unit tests
>>>>>
>>>>> Benefits of a rewrite:
>>>>>
>>>>>      Reduced resource requirements (lower hosting fees)
>>>>>      Reduce application development time - due to a simplified API
>>>>>      Easier framework code maintenance
>>>>>      Better reliability
>>>>>
>>>>> Conclusion
>>>>> ----------
>>>>>
>>>>> Like I said at the start, this is all I will say about the
>>>>> subject. I'm
>>>>> done trying to convince everyone. I hope someone agrees with me
>>>>> and they
>>>>> are able to build support for the idea.
>>>>>
>>>>> --
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>
>>>
>>

[Jacques Le Roux]

Forgot to add, even if Java 9 will not be available before a year, it would be good to think about what the Jigsaw project (part of Java 9) could
bring to such a endeavour in term of modularisation and dependency...

Jacques

Le 15/10/2015 11:51, Jacques Le Roux a écrit :

> I'm in the same mood than Paul and Scott. So a sub-project could indeed be a solution.
>
> Jacques
>
> Le 15/10/2015 03:11, Adrian Crum a écrit :
>> I agree that a sub-project would be nice to have. Once the new framework is up and running, applications could be pulled down and adapted to it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>> This seems to be very good advice.
>>> A completely separate sub-project under OFBiz with its own mailing lists
>>> would keep the people together yet all allow the new framework the
>>> flexibility to move forward.
>>>
>>> Ron
>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>> My advice is as follows:
>>>> 1. If people are interested, then get them together and start working
>>>> on it.
>>>> 2. Find somewhere to do the work.  I don't think a branch is appropriate
>>>> because it's completely new development rather than a refactoring.  I
>>>> don't
>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>> (although
>>>> I don't really see the need either).
>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try and
>>>> keep quiet about it in the early stages on the dev/user lists or other
>>>> marketing channels because it could potentially harm adoption of our
>>>> existing framework (think AngularJS 2.0).
>>>>
>>>> There really isn't any need to get early stage sign-off from the PMC or
>>>> anyone else in the community.  You only need enough PMC approval to
>>>> get the
>>>> required infrastructure sorted, which I don't think would be an issue.
>>>> >From there, it's really up to the community to decide whether or not the
>>>> thing will fly.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>>
>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>> <[hidden email]
>>>>> wrote:
>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>> action
>>>>> needs to be taken.
>>>>>
>>>>> In this message, I will try to give a detailed explanation of why a
>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>> action on
>>>>> this subject, because I've brought it up before without success, and I'm
>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>> on in
>>>>> someone's head and they will take action.
>>>>>
>>>>> My Background
>>>>> -------------
>>>>>
>>>>> I became a member of the OFBiz community in 2004. I immediately started
>>>>> making contributions to the project by supplying patches to the issue
>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>> on the
>>>>> UI and some work in the applications (mainly Asset Maintenance and Work
>>>>> Effort). I stayed away from touching the framework code because it was
>>>>> deep, dark, and scary.
>>>>>
>>>>> Eventually, I started to understand how the framework code works and I
>>>>> made some minor modifications. As my understanding grew, I progressed to
>>>>> rewriting large swaths of framework code - making it thread-safe, fault
>>>>> tolerant, efficient, and easier to use.
>>>>>
>>>>> I will list some of my contributions here, so everyone can have a clear
>>>>> understanding of my experience with the framework code:
>>>>>
>>>>>      New Features
>>>>>
>>>>>          User Preferences
>>>>>
>>>>>          Visual Themes
>>>>>
>>>>>          Custom UI Label XML File Format
>>>>>
>>>>>          Temporal Expressions
>>>>>
>>>>>          Data Type Conversion Framework
>>>>>
>>>>>          Screen Widget Boundary Comments
>>>>>
>>>>>          Metrics
>>>>>
>>>>>      Integrations
>>>>>
>>>>>          UEL
>>>>>
>>>>>          iCalendar
>>>>>
>>>>>          JSR 223
>>>>>
>>>>>          WebDAV
>>>>>
>>>>>          LDAP
>>>>>
>>>>>      Refactorings/Improvements
>>>>>
>>>>>          FlexibleStringExpander
>>>>>
>>>>>          FlexibleMapExpander
>>>>>
>>>>>          FOP Integration
>>>>>
>>>>>          FreeMarkerWorker
>>>>>
>>>>>          Date-Time Handling
>>>>>
>>>>>          Mini-language
>>>>>
>>>>>          Job Scheduler
>>>>>
>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>
>>>>> So, the contents of this message come from years of experience mucking
>>>>> about in the framework code.
>>>>>
>>>>> Okay, let's get started...
>>>>>
>>>>> Initial Problem Statement
>>>>> -------------------------
>>>>>
>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>
>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>
>>>>> At the time, there was some agreement that a rewrite was necessary, but
>>>>> there was disagreement as to how the rewrite should be incorporated into
>>>>> the project:
>>>>>
>>>>>
>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>
>>>>>
>>>>> There were concerns that a rewrite would break backward compatibility.
>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>> community be more accepting of backward-incompatible changes:
>>>>>
>>>>>
>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>
>>>>>
>>>>> Despite an effort to convince David to proceed with the framework
>>>>> rewrite,
>>>>> he ended up doing it in a separate project:
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>
>>>>>
>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>> it you
>>>>> can extract information on the problems David was trying to solve:
>>>>>
>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>
>>>>> There was an email he sent out on the OFBiz dev list where he listed the
>>>>> problems he saw in the framework, but I can't find it. The rest of this
>>>>> message will include the issues he mentioned (the ones I remember). I
>>>>> was
>>>>> in agreement with him at the time, and I still agree that a framework
>>>>> rewrite is necessary.
>>>>>
>>>>> The Problems
>>>>> ------------
>>>>>
>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>> framework modular. This causes serious problems. The mere fact that
>>>>> components like entityext and securityext EXIST makes it clear that
>>>>> there
>>>>> are problems - those components should not be there. Also, we run
>>>>> into the
>>>>> recurring problem of circular dependencies (component A will not build
>>>>> unless component B is built, and component B will not build unless
>>>>> component A is built).
>>>>>
>>>>> Bad separation of concerns. There are far too many examples of classes
>>>>> that try to be everything to everyone. This makes debugging
>>>>> difficult, and
>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>> consider
>>>>> an automobile design where a spark plug is not separate from a
>>>>> transmission. Instead, the automobile uses a spark-plug-transmission. So
>>>>> when the engine is running rough because the spark plug is bad, you
>>>>> have to
>>>>> replace the spark plug AND the transmission.] A good framework
>>>>> example can
>>>>> be found in my rewrite of the mini-language code. Originally, the models
>>>>> AND the script execution context both contained script behaviors -
>>>>> making
>>>>> debugging/improvements difficult. I changed it so only the models
>>>>> contain
>>>>> script behavior and the script execution context contains only the
>>>>> script
>>>>> execution state.
>>>>>
>>>>> Lack of good OO design. There are many places where a bit of framework
>>>>> functionality is contained in a single method that is hundreds or
>>>>> thousands
>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>> reused.
>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>> in the
>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>
>>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>>> error condition is encountered, but instead of throwing an exception,
>>>>> the
>>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>>> at a
>>>>> solution and then provide an arbitrary default behavior. I've seen many
>>>>> developers struggle with debugging a problem because they didn't look at
>>>>> the logs, or because the error was not logged and there is no way of
>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>> through
>>>>> code until it reaches the error.
>>>>>
>>>>> Out-of-date code. A good example is the use of Javolution. That library
>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>> because
>>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>>> was
>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>> unreliable
>>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>>> replaced, but a lot of it is still there.
>>>>>
>>>>> Portions of the API are overly complicated. Some methods require a
>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>> code
>>>>> complicated and verbose. (David solved that problem with his Execution
>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>> "convenience
>>>>> methods" - making the API harder to learn and memorize. In some
>>>>> places, a
>>>>> domain-specific API is spread across instance methods and static methods
>>>>> and across different classes - making the API hard to understand and
>>>>> use.
>>>>> Yes, there can be good designs that require something like that, but
>>>>> in the
>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>
>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>> thread
>>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>>> current design makes sense from a J2EE perspective, but what if I don't
>>>>> want to run the framework in a J2EE container? Which leads to the next
>>>>> problem...
>>>>>
>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>>> Java community (myself included) who are beginning to question if
>>>>> J2EE is
>>>>> really necessary to run web applications. The folks at Atomikos are a
>>>>> good
>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>>> not
>>>>> make sense. It would be better if the framework was designed to run
>>>>> outside
>>>>> a J2EE container, and then have container integration as an option.
>>>>>
>>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>> configuration settings are in nonsensical places.
>>>>>
>>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>>> coverage, but my gut feeling is coverage is less than 10%. Basically, we
>>>>> all have our fingers crossed - hoping that the framework code works as
>>>>> expected. This was made painfully obvious a while back when I was
>>>>> looking
>>>>> at some entity caching code and thought to myself "this code can't
>>>>> work."
>>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>>> cache
>>>>> had serious problems. Think about that - years passed with no entity
>>>>> cache
>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>
>>>>> Fix Versus Rewrite
>>>>> ------------------
>>>>>
>>>>> Jira issues could be created for these problems and teams of developers
>>>>> could work to fix them.
>>>>>
>>>>> Or, we could create a branch and start over from scratch. This time
>>>>> around, there should be less push-back from people concerned about
>>>>> backwards compatibility. A rewrite offers the advantage of reconsidering
>>>>> everything - like API design, general problem solving, and new features.
>>>>>
>>>>> I created a Wiki page for a framework design:
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>
>>>>>
>>>>> but there hasn't been much interest in it. If the community decides
>>>>> to go
>>>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>>>> guide.
>>>>>
>>>>> Sandglass Foundation
>>>>> --------------------
>>>>>
>>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>>> easier outside the OFBiz community. So, I created my own library called
>>>>> Foundation:
>>>>>
>>>>>
>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>
>>>>>
>>>>> (PDF)
>>>>>
>>>>> and I only mention it here to stress how wonderful it can be to start
>>>>> with
>>>>> a clean slate and design an API that is concise yet powerful. (Please do
>>>>> not discuss Foundation here, contact me privately if you want more
>>>>> information.)
>>>>>
>>>>> Some examples of what can be done with a rewrite:
>>>>>
>>>>>      A single configuration file
>>>>>      Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>>> complicated Java structures
>>>>>      Simultaneous asynchronous queries
>>>>>      Relational integrity across multiple datasources
>>>>>      Multi-table SELECT across multiple datasources
>>>>>      Automatic and transparent row version control
>>>>>      Automatic and transparent multi-language datasource support
>>>>>      Abstract entities (similar to SQL user types)
>>>>>      Service engine throttling (protects against server
>>>>> over-utilization)
>>>>>      Simplified security (authorization) (
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>>
>>>>>      Pure interface-based API - so developers are free to modify
>>>>> framework
>>>>> behavior by using decorators
>>>>>      Thorough unit tests
>>>>>
>>>>> Benefits of a rewrite:
>>>>>
>>>>>      Reduced resource requirements (lower hosting fees)
>>>>>      Reduce application development time - due to a simplified API
>>>>>      Easier framework code maintenance
>>>>>      Better reliability
>>>>>
>>>>> Conclusion
>>>>> ----------
>>>>>
>>>>> Like I said at the start, this is all I will say about the subject. I'm
>>>>> done trying to convince everyone. I hope someone agrees with me and they
>>>>> are able to build support for the idea.
>>>>>
>>>>> --
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>
>>>
>>
>

[byersa]

I was waiting for someone to bring this up. David Jones created Moqui with
the same end in mind that the rewrite is meant to accomplish. Do you think
that you will do a better job than him? Even if you could, would it be so
much better that it warrants the effort that it would take?

Is this a political thing? I don't know that David would give up control of
Moqui Core and I, for one, would not want him to. So many of OFBiz's
problems are the result of ineptitude on the part of committers who did not
know what they were doing (like me.) But I don't know that the Core will
change all that much going forward and there should be places in the Mantle
to contribute and, most certainly, in the Crust.

I know that there were some valid questions about licensing and project
management, but I would think that they could be worked out.

On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <[hidden email]>
wrote:

> Why not skip this step, using moqui which is already up and running and
> then as Adrian states as a next step: applications could be pulled down and
> adapted to it.
>
> Hans
>
>
>
> On 15/10/15 16:51, Jacques Le Roux wrote:
>
>> I'm in the same mood than Paul and Scott. So a sub-project could indeed
>> be a solution.
>>
>> Jacques
>>
>> Le 15/10/2015 03:11, Adrian Crum a écrit :
>>
>>> I agree that a sub-project would be nice to have. Once the new framework
>>> is up and running, applications could be pulled down and adapted to it.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>>
>>>> This seems to be very good advice.
>>>> A completely separate sub-project under OFBiz with its own mailing lists
>>>> would keep the people together yet all allow the new framework the
>>>> flexibility to move forward.
>>>>
>>>> Ron
>>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>>
>>>>> My advice is as follows:
>>>>> 1. If people are interested, then get them together and start working
>>>>> on it.
>>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>>> appropriate
>>>>> because it's completely new development rather than a refactoring.  I
>>>>> don't
>>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>>> (although
>>>>> I don't really see the need either).
>>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try
>>>>> and
>>>>> keep quiet about it in the early stages on the dev/user lists or other
>>>>> marketing channels because it could potentially harm adoption of our
>>>>> existing framework (think AngularJS 2.0).
>>>>>
>>>>> There really isn't any need to get early stage sign-off from the PMC or
>>>>> anyone else in the community.  You only need enough PMC approval to
>>>>> get the
>>>>> required infrastructure sorted, which I don't think would be an issue.
>>>>> >From there, it's really up to the community to decide whether or not
>>>>> the
>>>>> thing will fly.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>>
>>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>>> <[hidden email]
>>>>>
>>>>>> wrote:
>>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>>> action
>>>>>> needs to be taken.
>>>>>>
>>>>>> In this message, I will try to give a detailed explanation of why a
>>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>>> action on
>>>>>> this subject, because I've brought it up before without success, and
>>>>>> I'm
>>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>>> on in
>>>>>> someone's head and they will take action.
>>>>>>
>>>>>> My Background
>>>>>> -------------
>>>>>>
>>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>>> started
>>>>>> making contributions to the project by supplying patches to the issue
>>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>>> on the
>>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>>> Work
>>>>>> Effort). I stayed away from touching the framework code because it was
>>>>>> deep, dark, and scary.
>>>>>>
>>>>>> Eventually, I started to understand how the framework code works and I
>>>>>> made some minor modifications. As my understanding grew, I progressed
>>>>>> to
>>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>>> fault
>>>>>> tolerant, efficient, and easier to use.
>>>>>>
>>>>>> I will list some of my contributions here, so everyone can have a
>>>>>> clear
>>>>>> understanding of my experience with the framework code:
>>>>>>
>>>>>>      New Features
>>>>>>
>>>>>>          User Preferences
>>>>>>
>>>>>>          Visual Themes
>>>>>>
>>>>>>          Custom UI Label XML File Format
>>>>>>
>>>>>>          Temporal Expressions
>>>>>>
>>>>>>          Data Type Conversion Framework
>>>>>>
>>>>>>          Screen Widget Boundary Comments
>>>>>>
>>>>>>          Metrics
>>>>>>
>>>>>>      Integrations
>>>>>>
>>>>>>          UEL
>>>>>>
>>>>>>          iCalendar
>>>>>>
>>>>>>          JSR 223
>>>>>>
>>>>>>          WebDAV
>>>>>>
>>>>>>          LDAP
>>>>>>
>>>>>>      Refactorings/Improvements
>>>>>>
>>>>>>          FlexibleStringExpander
>>>>>>
>>>>>>          FlexibleMapExpander
>>>>>>
>>>>>>          FOP Integration
>>>>>>
>>>>>>          FreeMarkerWorker
>>>>>>
>>>>>>          Date-Time Handling
>>>>>>
>>>>>>          Mini-language
>>>>>>
>>>>>>          Job Scheduler
>>>>>>
>>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>>
>>>>>> So, the contents of this message come from years of experience mucking
>>>>>> about in the framework code.
>>>>>>
>>>>>> Okay, let's get started...
>>>>>>
>>>>>> Initial Problem Statement
>>>>>> -------------------------
>>>>>>
>>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>>
>>>>>>
>>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>>
>>>>>> At the time, there was some agreement that a rewrite was necessary,
>>>>>> but
>>>>>> there was disagreement as to how the rewrite should be incorporated
>>>>>> into
>>>>>> the project:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>>
>>>>>>
>>>>>> There were concerns that a rewrite would break backward compatibility.
>>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>>> community be more accepting of backward-incompatible changes:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>>
>>>>>>
>>>>>> Despite an effort to convince David to proceed with the framework
>>>>>> rewrite,
>>>>>> he ended up doing it in a separate project:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>>
>>>>>>
>>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>>> it you
>>>>>> can extract information on the problems David was trying to solve:
>>>>>>
>>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>>
>>>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>>>> the
>>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>>> this
>>>>>> message will include the issues he mentioned (the ones I remember). I
>>>>>> was
>>>>>> in agreement with him at the time, and I still agree that a framework
>>>>>> rewrite is necessary.
>>>>>>
>>>>>> The Problems
>>>>>> ------------
>>>>>>
>>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>>> framework modular. This causes serious problems. The mere fact that
>>>>>> components like entityext and securityext EXIST makes it clear that
>>>>>> there
>>>>>> are problems - those components should not be there. Also, we run
>>>>>> into the
>>>>>> recurring problem of circular dependencies (component A will not build
>>>>>> unless component B is built, and component B will not build unless
>>>>>> component A is built).
>>>>>>
>>>>>> Bad separation of concerns. There are far too many examples of classes
>>>>>> that try to be everything to everyone. This makes debugging
>>>>>> difficult, and
>>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>>> consider
>>>>>> an automobile design where a spark plug is not separate from a
>>>>>> transmission. Instead, the automobile uses a spark-plug-transmission.
>>>>>> So
>>>>>> when the engine is running rough because the spark plug is bad, you
>>>>>> have to
>>>>>> replace the spark plug AND the transmission.] A good framework
>>>>>> example can
>>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>>> models
>>>>>> AND the script execution context both contained script behaviors -
>>>>>> making
>>>>>> debugging/improvements difficult. I changed it so only the models
>>>>>> contain
>>>>>> script behavior and the script execution context contains only the
>>>>>> script
>>>>>> execution state.
>>>>>>
>>>>>> Lack of good OO design. There are many places where a bit of framework
>>>>>> functionality is contained in a single method that is hundreds or
>>>>>> thousands
>>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>>> reused.
>>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>>> in the
>>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>>
>>>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>>>> error condition is encountered, but instead of throwing an exception,
>>>>>> the
>>>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>>>> at a
>>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>>> many
>>>>>> developers struggle with debugging a problem because they didn't look
>>>>>> at
>>>>>> the logs, or because the error was not logged and there is no way of
>>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>>> through
>>>>>> code until it reaches the error.
>>>>>>
>>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>>> library
>>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>>> because
>>>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>>>> was
>>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>>> unreliable
>>>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>>>> replaced, but a lot of it is still there.
>>>>>>
>>>>>> Portions of the API are overly complicated. Some methods require a
>>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>>> code
>>>>>> complicated and verbose. (David solved that problem with his Execution
>>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>>> "convenience
>>>>>> methods" - making the API harder to learn and memorize. In some
>>>>>> places, a
>>>>>> domain-specific API is spread across instance methods and static
>>>>>> methods
>>>>>> and across different classes - making the API hard to understand and
>>>>>> use.
>>>>>> Yes, there can be good designs that require something like that, but
>>>>>> in the
>>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>>
>>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>>> thread
>>>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>>> don't
>>>>>> want to run the framework in a J2EE container? Which leads to the next
>>>>>> problem...
>>>>>>
>>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>>>> Java community (myself included) who are beginning to question if
>>>>>> J2EE is
>>>>>> really necessary to run web applications. The folks at Atomikos are a
>>>>>> good
>>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>>>> not
>>>>>> make sense. It would be better if the framework was designed to run
>>>>>> outside
>>>>>> a J2EE container, and then have container integration as an option.
>>>>>>
>>>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>>> configuration settings are in nonsensical places.
>>>>>>
>>>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>>>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>>>>>> we
>>>>>> all have our fingers crossed - hoping that the framework code works as
>>>>>> expected. This was made painfully obvious a while back when I was
>>>>>> looking
>>>>>> at some entity caching code and thought to myself "this code can't
>>>>>> work."
>>>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>>>> cache
>>>>>> had serious problems. Think about that - years passed with no entity
>>>>>> cache
>>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>>
>>>>>> Fix Versus Rewrite
>>>>>> ------------------
>>>>>>
>>>>>> Jira issues could be created for these problems and teams of
>>>>>> developers
>>>>>> could work to fix them.
>>>>>>
>>>>>> Or, we could create a branch and start over from scratch. This time
>>>>>> around, there should be less push-back from people concerned about
>>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>>> reconsidering
>>>>>> everything - like API design, general problem solving, and new
>>>>>> features.
>>>>>>
>>>>>> I created a Wiki page for a framework design:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>>
>>>>>>
>>>>>> but there hasn't been much interest in it. If the community decides
>>>>>> to go
>>>>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>>>>> guide.
>>>>>>
>>>>>> Sandglass Foundation
>>>>>> --------------------
>>>>>>
>>>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>>>> easier outside the OFBiz community. So, I created my own library
>>>>>> called
>>>>>> Foundation:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>>
>>>>>>
>>>>>> (PDF)
>>>>>>
>>>>>> and I only mention it here to stress how wonderful it can be to start
>>>>>> with
>>>>>> a clean slate and design an API that is concise yet powerful. (Please
>>>>>> do
>>>>>> not discuss Foundation here, contact me privately if you want more
>>>>>> information.)
>>>>>>
>>>>>> Some examples of what can be done with a rewrite:
>>>>>>
>>>>>>      A single configuration file
>>>>>>      Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>>>> complicated Java structures
>>>>>>      Simultaneous asynchronous queries
>>>>>>      Relational integrity across multiple datasources
>>>>>>      Multi-table SELECT across multiple datasources
>>>>>>      Automatic and transparent row version control
>>>>>>      Automatic and transparent multi-language datasource support
>>>>>>      Abstract entities (similar to SQL user types)
>>>>>>      Service engine throttling (protects against server
>>>>>> over-utilization)
>>>>>>      Simplified security (authorization) (
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>>>
>>>>>>
>>>>>>      Pure interface-based API - so developers are free to modify
>>>>>> framework
>>>>>> behavior by using decorators
>>>>>>      Thorough unit tests
>>>>>>
>>>>>> Benefits of a rewrite:
>>>>>>
>>>>>>      Reduced resource requirements (lower hosting fees)
>>>>>>      Reduce application development time - due to a simplified API
>>>>>>      Easier framework code maintenance
>>>>>>      Better reliability
>>>>>>
>>>>>> Conclusion
>>>>>> ----------
>>>>>>
>>>>>> Like I said at the start, this is all I will say about the subject.
>>>>>> I'm
>>>>>> done trying to convince everyone. I hope someone agrees with me and
>>>>>> they
>>>>>> are able to build support for the idea.
>>>>>>
>>>>>> --
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>

[Adrian Crum-3]

Keep in mind that much of David's code in OFBiz has been rewritten. So
yes, we CAN do a better job than him. Also keep in mind that Moqui
duplicates some of the problems I listed - so by using Moqui, we keep
the same problems instead of fixing them. On the other hand, it is
David's responsibility to fix them, not ours.

If we created a sub-project, then we would have the opportunity to
review committer permissions and perhaps restrict access to the new code.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/15/2015 6:34 AM, Al Byers wrote:

> I was waiting for someone to bring this up. David Jones created Moqui with
> the same end in mind that the rewrite is meant to accomplish. Do you think
> that you will do a better job than him? Even if you could, would it be so
> much better that it warrants the effort that it would take?
>
> Is this a political thing? I don't know that David would give up control of
> Moqui Core and I, for one, would not want him to. So many of OFBiz's
> problems are the result of ineptitude on the part of committers who did not
> know what they were doing (like me.) But I don't know that the Core will
> change all that much going forward and there should be places in the Mantle
> to contribute and, most certainly, in the Crust.
>
> I know that there were some valid questions about licensing and project
> management, but I would think that they could be worked out.
>
> On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <[hidden email]>
> wrote:
>
>> Why not skip this step, using moqui which is already up and running and
>> then as Adrian states as a next step: applications could be pulled down and
>> adapted to it.
>>
>> Hans
>>
>>
>>
>> On 15/10/15 16:51, Jacques Le Roux wrote:
>>
>>> I'm in the same mood than Paul and Scott. So a sub-project could indeed
>>> be a solution.
>>>
>>> Jacques
>>>
>>> Le 15/10/2015 03:11, Adrian Crum a écrit :
>>>
>>>> I agree that a sub-project would be nice to have. Once the new framework
>>>> is up and running, applications could be pulled down and adapted to it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>>>
>>>>> This seems to be very good advice.
>>>>> A completely separate sub-project under OFBiz with its own mailing lists
>>>>> would keep the people together yet all allow the new framework the
>>>>> flexibility to move forward.
>>>>>
>>>>> Ron
>>>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>>>
>>>>>> My advice is as follows:
>>>>>> 1. If people are interested, then get them together and start working
>>>>>> on it.
>>>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>>>> appropriate
>>>>>> because it's completely new development rather than a refactoring.  I
>>>>>> don't
>>>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>>>> (although
>>>>>> I don't really see the need either).
>>>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try
>>>>>> and
>>>>>> keep quiet about it in the early stages on the dev/user lists or other
>>>>>> marketing channels because it could potentially harm adoption of our
>>>>>> existing framework (think AngularJS 2.0).
>>>>>>
>>>>>> There really isn't any need to get early stage sign-off from the PMC or
>>>>>> anyone else in the community.  You only need enough PMC approval to
>>>>>> get the
>>>>>> required infrastructure sorted, which I don't think would be an issue.
>>>>>> >From there, it's really up to the community to decide whether or not
>>>>>> the
>>>>>> thing will fly.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>>>> <[hidden email]
>>>>>>
>>>>>>> wrote:
>>>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>>>> action
>>>>>>> needs to be taken.
>>>>>>>
>>>>>>> In this message, I will try to give a detailed explanation of why a
>>>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>>>> action on
>>>>>>> this subject, because I've brought it up before without success, and
>>>>>>> I'm
>>>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>>>> on in
>>>>>>> someone's head and they will take action.
>>>>>>>
>>>>>>> My Background
>>>>>>> -------------
>>>>>>>
>>>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>>>> started
>>>>>>> making contributions to the project by supplying patches to the issue
>>>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>>>> on the
>>>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>>>> Work
>>>>>>> Effort). I stayed away from touching the framework code because it was
>>>>>>> deep, dark, and scary.
>>>>>>>
>>>>>>> Eventually, I started to understand how the framework code works and I
>>>>>>> made some minor modifications. As my understanding grew, I progressed
>>>>>>> to
>>>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>>>> fault
>>>>>>> tolerant, efficient, and easier to use.
>>>>>>>
>>>>>>> I will list some of my contributions here, so everyone can have a
>>>>>>> clear
>>>>>>> understanding of my experience with the framework code:
>>>>>>>
>>>>>>>       New Features
>>>>>>>
>>>>>>>           User Preferences
>>>>>>>
>>>>>>>           Visual Themes
>>>>>>>
>>>>>>>           Custom UI Label XML File Format
>>>>>>>
>>>>>>>           Temporal Expressions
>>>>>>>
>>>>>>>           Data Type Conversion Framework
>>>>>>>
>>>>>>>           Screen Widget Boundary Comments
>>>>>>>
>>>>>>>           Metrics
>>>>>>>
>>>>>>>       Integrations
>>>>>>>
>>>>>>>           UEL
>>>>>>>
>>>>>>>           iCalendar
>>>>>>>
>>>>>>>           JSR 223
>>>>>>>
>>>>>>>           WebDAV
>>>>>>>
>>>>>>>           LDAP
>>>>>>>
>>>>>>>       Refactorings/Improvements
>>>>>>>
>>>>>>>           FlexibleStringExpander
>>>>>>>
>>>>>>>           FlexibleMapExpander
>>>>>>>
>>>>>>>           FOP Integration
>>>>>>>
>>>>>>>           FreeMarkerWorker
>>>>>>>
>>>>>>>           Date-Time Handling
>>>>>>>
>>>>>>>           Mini-language
>>>>>>>
>>>>>>>           Job Scheduler
>>>>>>>
>>>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>>>
>>>>>>> So, the contents of this message come from years of experience mucking
>>>>>>> about in the framework code.
>>>>>>>
>>>>>>> Okay, let's get started...
>>>>>>>
>>>>>>> Initial Problem Statement
>>>>>>> -------------------------
>>>>>>>
>>>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>>>
>>>>>>>
>>>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>>>
>>>>>>> At the time, there was some agreement that a rewrite was necessary,
>>>>>>> but
>>>>>>> there was disagreement as to how the rewrite should be incorporated
>>>>>>> into
>>>>>>> the project:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>>>
>>>>>>>
>>>>>>> There were concerns that a rewrite would break backward compatibility.
>>>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>>>> community be more accepting of backward-incompatible changes:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>>>
>>>>>>>
>>>>>>> Despite an effort to convince David to proceed with the framework
>>>>>>> rewrite,
>>>>>>> he ended up doing it in a separate project:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>>>
>>>>>>>
>>>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>>>> it you
>>>>>>> can extract information on the problems David was trying to solve:
>>>>>>>
>>>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>>>
>>>>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>>>>> the
>>>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>>>> this
>>>>>>> message will include the issues he mentioned (the ones I remember). I
>>>>>>> was
>>>>>>> in agreement with him at the time, and I still agree that a framework
>>>>>>> rewrite is necessary.
>>>>>>>
>>>>>>> The Problems
>>>>>>> ------------
>>>>>>>
>>>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>>>> framework modular. This causes serious problems. The mere fact that
>>>>>>> components like entityext and securityext EXIST makes it clear that
>>>>>>> there
>>>>>>> are problems - those components should not be there. Also, we run
>>>>>>> into the
>>>>>>> recurring problem of circular dependencies (component A will not build
>>>>>>> unless component B is built, and component B will not build unless
>>>>>>> component A is built).
>>>>>>>
>>>>>>> Bad separation of concerns. There are far too many examples of classes
>>>>>>> that try to be everything to everyone. This makes debugging
>>>>>>> difficult, and
>>>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>>>> consider
>>>>>>> an automobile design where a spark plug is not separate from a
>>>>>>> transmission. Instead, the automobile uses a spark-plug-transmission.
>>>>>>> So
>>>>>>> when the engine is running rough because the spark plug is bad, you
>>>>>>> have to
>>>>>>> replace the spark plug AND the transmission.] A good framework
>>>>>>> example can
>>>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>>>> models
>>>>>>> AND the script execution context both contained script behaviors -
>>>>>>> making
>>>>>>> debugging/improvements difficult. I changed it so only the models
>>>>>>> contain
>>>>>>> script behavior and the script execution context contains only the
>>>>>>> script
>>>>>>> execution state.
>>>>>>>
>>>>>>> Lack of good OO design. There are many places where a bit of framework
>>>>>>> functionality is contained in a single method that is hundreds or
>>>>>>> thousands
>>>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>>>> reused.
>>>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>>>> in the
>>>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>>>
>>>>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>>>>> error condition is encountered, but instead of throwing an exception,
>>>>>>> the
>>>>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>>>>> at a
>>>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>>>> many
>>>>>>> developers struggle with debugging a problem because they didn't look
>>>>>>> at
>>>>>>> the logs, or because the error was not logged and there is no way of
>>>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>>>> through
>>>>>>> code until it reaches the error.
>>>>>>>
>>>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>>>> library
>>>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>>>> because
>>>>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>>>>> was
>>>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>>>> unreliable
>>>>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>>>>> replaced, but a lot of it is still there.
>>>>>>>
>>>>>>> Portions of the API are overly complicated. Some methods require a
>>>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>>>> code
>>>>>>> complicated and verbose. (David solved that problem with his Execution
>>>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>>>> "convenience
>>>>>>> methods" - making the API harder to learn and memorize. In some
>>>>>>> places, a
>>>>>>> domain-specific API is spread across instance methods and static
>>>>>>> methods
>>>>>>> and across different classes - making the API hard to understand and
>>>>>>> use.
>>>>>>> Yes, there can be good designs that require something like that, but
>>>>>>> in the
>>>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>>>
>>>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>>>> thread
>>>>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>>>> don't
>>>>>>> want to run the framework in a J2EE container? Which leads to the next
>>>>>>> problem...
>>>>>>>
>>>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>>>>> Java community (myself included) who are beginning to question if
>>>>>>> J2EE is
>>>>>>> really necessary to run web applications. The folks at Atomikos are a
>>>>>>> good
>>>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>>>>> not
>>>>>>> make sense. It would be better if the framework was designed to run
>>>>>>> outside
>>>>>>> a J2EE container, and then have container integration as an option.
>>>>>>>
>>>>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>>>> configuration settings are in nonsensical places.
>>>>>>>
>>>>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>>>>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>>>>>>> we
>>>>>>> all have our fingers crossed - hoping that the framework code works as
>>>>>>> expected. This was made painfully obvious a while back when I was
>>>>>>> looking
>>>>>>> at some entity caching code and thought to myself "this code can't
>>>>>>> work."
>>>>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>>>>> cache
>>>>>>> had serious problems. Think about that - years passed with no entity
>>>>>>> cache
>>>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>>>
>>>>>>> Fix Versus Rewrite
>>>>>>> ------------------
>>>>>>>
>>>>>>> Jira issues could be created for these problems and teams of
>>>>>>> developers
>>>>>>> could work to fix them.
>>>>>>>
>>>>>>> Or, we could create a branch and start over from scratch. This time
>>>>>>> around, there should be less push-back from people concerned about
>>>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>>>> reconsidering
>>>>>>> everything - like API design, general problem solving, and new
>>>>>>> features.
>>>>>>>
>>>>>>> I created a Wiki page for a framework design:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>>>
>>>>>>>
>>>>>>> but there hasn't been much interest in it. If the community decides
>>>>>>> to go
>>>>>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>>>>>> guide.
>>>>>>>
>>>>>>> Sandglass Foundation
>>>>>>> --------------------
>>>>>>>
>>>>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>>>>> easier outside the OFBiz community. So, I created my own library
>>>>>>> called
>>>>>>> Foundation:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>>>
>>>>>>>
>>>>>>> (PDF)
>>>>>>>
>>>>>>> and I only mention it here to stress how wonderful it can be to start
>>>>>>> with
>>>>>>> a clean slate and design an API that is concise yet powerful. (Please
>>>>>>> do
>>>>>>> not discuss Foundation here, contact me privately if you want more
>>>>>>> information.)
>>>>>>>
>>>>>>> Some examples of what can be done with a rewrite:
>>>>>>>
>>>>>>>       A single configuration file
>>>>>>>       Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>>>>> complicated Java structures
>>>>>>>       Simultaneous asynchronous queries
>>>>>>>       Relational integrity across multiple datasources
>>>>>>>       Multi-table SELECT across multiple datasources
>>>>>>>       Automatic and transparent row version control
>>>>>>>       Automatic and transparent multi-language datasource support
>>>>>>>       Abstract entities (similar to SQL user types)
>>>>>>>       Service engine throttling (protects against server
>>>>>>> over-utilization)
>>>>>>>       Simplified security (authorization) (
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>>>>
>>>>>>>
>>>>>>>       Pure interface-based API - so developers are free to modify
>>>>>>> framework
>>>>>>> behavior by using decorators
>>>>>>>       Thorough unit tests
>>>>>>>
>>>>>>> Benefits of a rewrite:
>>>>>>>
>>>>>>>       Reduced resource requirements (lower hosting fees)
>>>>>>>       Reduce application development time - due to a simplified API
>>>>>>>       Easier framework code maintenance
>>>>>>>       Better reliability
>>>>>>>
>>>>>>> Conclusion
>>>>>>> ----------
>>>>>>>
>>>>>>> Like I said at the start, this is all I will say about the subject.
>>>>>>> I'm
>>>>>>> done trying to convince everyone. I hope someone agrees with me and
>>>>>>> they
>>>>>>> are able to build support for the idea.
>>>>>>>
>>>>>>> --
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>

[byersa]

Fair enough, Adrian, but is this a widely held position on OFBiz that as a
group you could produce a product that is so much better than Moqui that it
would be worth the time and risk (the risk of burning cycles that you will
never get back only to have the venture never succeed.) Have all the people
who would like to do a rewrite done the same gap analysis on Moqui vs what
you would like to see OFBiz be? Does everyone understand and agree that the
deficiencies that you see in Moqui are important? My concern is that the
many people who understandably want a rewrite of OFBiz will be swayed by
your arguments without there being due diligence being done. I think that
there are a lot of veterans of OFBiz who have confidence in David's
development skills, but who are not pressing for a move to Moqui or for a
rewrite because they have so much invested in the current state of OFBiz
and recognized what a long shot a rewrite would be and how much work it
would require of them to move over. But anybody who is open to a rewrite
would be foolish not to consider the work done by the principal architect
of OFBiz; work that was meant to address deficiencies in OFBiz.

On Thu, Oct 15, 2015 at 7:58 AM, Adrian Crum <
[hidden email]> wrote:

> Keep in mind that much of David's code in OFBiz has been rewritten. So
> yes, we CAN do a better job than him. Also keep in mind that Moqui
> duplicates some of the problems I listed - so by using Moqui, we keep the
> same problems instead of fixing them. On the other hand, it is David's
> responsibility to fix them, not ours.
>
> If we created a sub-project, then we would have the opportunity to review
> committer permissions and perhaps restrict access to the new code.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 10/15/2015 6:34 AM, Al Byers wrote:
>
>> I was waiting for someone to bring this up. David Jones created Moqui with
>> the same end in mind that the rewrite is meant to accomplish. Do you think
>> that you will do a better job than him? Even if you could, would it be so
>> much better that it warrants the effort that it would take?
>>
>> Is this a political thing? I don't know that David would give up control
>> of
>> Moqui Core and I, for one, would not want him to. So many of OFBiz's
>> problems are the result of ineptitude on the part of committers who did
>> not
>> know what they were doing (like me.) But I don't know that the Core will
>> change all that much going forward and there should be places in the
>> Mantle
>> to contribute and, most certainly, in the Crust.
>>
>> I know that there were some valid questions about licensing and project
>> management, but I would think that they could be worked out.
>>
>> On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <[hidden email]>
>> wrote:
>>
>> Why not skip this step, using moqui which is already up and running and
>>> then as Adrian states as a next step: applications could be pulled down
>>> and
>>> adapted to it.
>>>
>>> Hans
>>>
>>>
>>>
>>> On 15/10/15 16:51, Jacques Le Roux wrote:
>>>
>>> I'm in the same mood than Paul and Scott. So a sub-project could indeed
>>>> be a solution.
>>>>
>>>> Jacques
>>>>
>>>> Le 15/10/2015 03:11, Adrian Crum a écrit :
>>>>
>>>> I agree that a sub-project would be nice to have. Once the new framework
>>>>> is up and running, applications could be pulled down and adapted to it.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>>>>
>>>>> This seems to be very good advice.
>>>>>> A completely separate sub-project under OFBiz with its own mailing
>>>>>> lists
>>>>>> would keep the people together yet all allow the new framework the
>>>>>> flexibility to move forward.
>>>>>>
>>>>>> Ron
>>>>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>>>>
>>>>>> My advice is as follows:
>>>>>>> 1. If people are interested, then get them together and start working
>>>>>>> on it.
>>>>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>>>>> appropriate
>>>>>>> because it's completely new development rather than a refactoring.  I
>>>>>>> don't
>>>>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>>>>> (although
>>>>>>> I don't really see the need either).
>>>>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try
>>>>>>> and
>>>>>>> keep quiet about it in the early stages on the dev/user lists or
>>>>>>> other
>>>>>>> marketing channels because it could potentially harm adoption of our
>>>>>>> existing framework (think AngularJS 2.0).
>>>>>>>
>>>>>>> There really isn't any need to get early stage sign-off from the PMC
>>>>>>> or
>>>>>>> anyone else in the community.  You only need enough PMC approval to
>>>>>>> get the
>>>>>>> required infrastructure sorted, which I don't think would be an
>>>>>>> issue.
>>>>>>> >From there, it's really up to the community to decide whether or not
>>>>>>> the
>>>>>>> thing will fly.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>>
>>>>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>>>>> <[hidden email]
>>>>>>>
>>>>>>> wrote:
>>>>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>>>>> action
>>>>>>>> needs to be taken.
>>>>>>>>
>>>>>>>> In this message, I will try to give a detailed explanation of why a
>>>>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>>>>> action on
>>>>>>>> this subject, because I've brought it up before without success, and
>>>>>>>> I'm
>>>>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>>>>> on in
>>>>>>>> someone's head and they will take action.
>>>>>>>>
>>>>>>>> My Background
>>>>>>>> -------------
>>>>>>>>
>>>>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>>>>> started
>>>>>>>> making contributions to the project by supplying patches to the
>>>>>>>> issue
>>>>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>>>>> on the
>>>>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>>>>> Work
>>>>>>>> Effort). I stayed away from touching the framework code because it
>>>>>>>> was
>>>>>>>> deep, dark, and scary.
>>>>>>>>
>>>>>>>> Eventually, I started to understand how the framework code works
>>>>>>>> and I
>>>>>>>> made some minor modifications. As my understanding grew, I
>>>>>>>> progressed
>>>>>>>> to
>>>>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>>>>> fault
>>>>>>>> tolerant, efficient, and easier to use.
>>>>>>>>
>>>>>>>> I will list some of my contributions here, so everyone can have a
>>>>>>>> clear
>>>>>>>> understanding of my experience with the framework code:
>>>>>>>>
>>>>>>>>       New Features
>>>>>>>>
>>>>>>>>           User Preferences
>>>>>>>>
>>>>>>>>           Visual Themes
>>>>>>>>
>>>>>>>>           Custom UI Label XML File Format
>>>>>>>>
>>>>>>>>           Temporal Expressions
>>>>>>>>
>>>>>>>>           Data Type Conversion Framework
>>>>>>>>
>>>>>>>>           Screen Widget Boundary Comments
>>>>>>>>
>>>>>>>>           Metrics
>>>>>>>>
>>>>>>>>       Integrations
>>>>>>>>
>>>>>>>>           UEL
>>>>>>>>
>>>>>>>>           iCalendar
>>>>>>>>
>>>>>>>>           JSR 223
>>>>>>>>
>>>>>>>>           WebDAV
>>>>>>>>
>>>>>>>>           LDAP
>>>>>>>>
>>>>>>>>       Refactorings/Improvements
>>>>>>>>
>>>>>>>>           FlexibleStringExpander
>>>>>>>>
>>>>>>>>           FlexibleMapExpander
>>>>>>>>
>>>>>>>>           FOP Integration
>>>>>>>>
>>>>>>>>           FreeMarkerWorker
>>>>>>>>
>>>>>>>>           Date-Time Handling
>>>>>>>>
>>>>>>>>           Mini-language
>>>>>>>>
>>>>>>>>           Job Scheduler
>>>>>>>>
>>>>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>>>>
>>>>>>>> So, the contents of this message come from years of experience
>>>>>>>> mucking
>>>>>>>> about in the framework code.
>>>>>>>>
>>>>>>>> Okay, let's get started...
>>>>>>>>
>>>>>>>> Initial Problem Statement
>>>>>>>> -------------------------
>>>>>>>>
>>>>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>>>>
>>>>>>>> At the time, there was some agreement that a rewrite was necessary,
>>>>>>>> but
>>>>>>>> there was disagreement as to how the rewrite should be incorporated
>>>>>>>> into
>>>>>>>> the project:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>>>>
>>>>>>>>
>>>>>>>> There were concerns that a rewrite would break backward
>>>>>>>> compatibility.
>>>>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>>>>> community be more accepting of backward-incompatible changes:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>>>>
>>>>>>>>
>>>>>>>> Despite an effort to convince David to proceed with the framework
>>>>>>>> rewrite,
>>>>>>>> he ended up doing it in a separate project:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>>>>
>>>>>>>>
>>>>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>>>>> it you
>>>>>>>> can extract information on the problems David was trying to solve:
>>>>>>>>
>>>>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>>>>
>>>>>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>>>>>> the
>>>>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>>>>> this
>>>>>>>> message will include the issues he mentioned (the ones I remember).
>>>>>>>> I
>>>>>>>> was
>>>>>>>> in agreement with him at the time, and I still agree that a
>>>>>>>> framework
>>>>>>>> rewrite is necessary.
>>>>>>>>
>>>>>>>> The Problems
>>>>>>>> ------------
>>>>>>>>
>>>>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>>>>> framework modular. This causes serious problems. The mere fact that
>>>>>>>> components like entityext and securityext EXIST makes it clear that
>>>>>>>> there
>>>>>>>> are problems - those components should not be there. Also, we run
>>>>>>>> into the
>>>>>>>> recurring problem of circular dependencies (component A will not
>>>>>>>> build
>>>>>>>> unless component B is built, and component B will not build unless
>>>>>>>> component A is built).
>>>>>>>>
>>>>>>>> Bad separation of concerns. There are far too many examples of
>>>>>>>> classes
>>>>>>>> that try to be everything to everyone. This makes debugging
>>>>>>>> difficult, and
>>>>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>>>>> consider
>>>>>>>> an automobile design where a spark plug is not separate from a
>>>>>>>> transmission. Instead, the automobile uses a
>>>>>>>> spark-plug-transmission.
>>>>>>>> So
>>>>>>>> when the engine is running rough because the spark plug is bad, you
>>>>>>>> have to
>>>>>>>> replace the spark plug AND the transmission.] A good framework
>>>>>>>> example can
>>>>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>>>>> models
>>>>>>>> AND the script execution context both contained script behaviors -
>>>>>>>> making
>>>>>>>> debugging/improvements difficult. I changed it so only the models
>>>>>>>> contain
>>>>>>>> script behavior and the script execution context contains only the
>>>>>>>> script
>>>>>>>> execution state.
>>>>>>>>
>>>>>>>> Lack of good OO design. There are many places where a bit of
>>>>>>>> framework
>>>>>>>> functionality is contained in a single method that is hundreds or
>>>>>>>> thousands
>>>>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>>>>> reused.
>>>>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>>>>> in the
>>>>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>>>>
>>>>>>>> Fail-slow design. There are a lot of places in low-level code where
>>>>>>>> an
>>>>>>>> error condition is encountered, but instead of throwing an
>>>>>>>> exception,
>>>>>>>> the
>>>>>>>> error is ignored and maybe it is logged, or the code tries to
>>>>>>>> "guess"
>>>>>>>> at a
>>>>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>>>>> many
>>>>>>>> developers struggle with debugging a problem because they didn't
>>>>>>>> look
>>>>>>>> at
>>>>>>>> the logs, or because the error was not logged and there is no way of
>>>>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>>>>> through
>>>>>>>> code until it reaches the error.
>>>>>>>>
>>>>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>>>>> library
>>>>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>>>>> because
>>>>>>>> of improved garbage collection. Another good example is DCL code.
>>>>>>>> DCL
>>>>>>>> was
>>>>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>>>>> unreliable
>>>>>>>> design (I can get it to fail 90% of the time). Some DCL code has
>>>>>>>> been
>>>>>>>> replaced, but a lot of it is still there.
>>>>>>>>
>>>>>>>> Portions of the API are overly complicated. Some methods require a
>>>>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>>>>> code
>>>>>>>> complicated and verbose. (David solved that problem with his
>>>>>>>> Execution
>>>>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>>>>> "convenience
>>>>>>>> methods" - making the API harder to learn and memorize. In some
>>>>>>>> places, a
>>>>>>>> domain-specific API is spread across instance methods and static
>>>>>>>> methods
>>>>>>>> and across different classes - making the API hard to understand and
>>>>>>>> use.
>>>>>>>> Yes, there can be good designs that require something like that, but
>>>>>>>> in the
>>>>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>>>>
>>>>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>>>>> thread
>>>>>>>> per request (and most J2EE libraries depend on that behavior), so
>>>>>>>> the
>>>>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>>>>> don't
>>>>>>>> want to run the framework in a J2EE container? Which leads to the
>>>>>>>> next
>>>>>>>> problem...
>>>>>>>>
>>>>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in
>>>>>>>> the
>>>>>>>> Java community (myself included) who are beginning to question if
>>>>>>>> J2EE is
>>>>>>>> really necessary to run web applications. The folks at Atomikos are
>>>>>>>> a
>>>>>>>> good
>>>>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE
>>>>>>>> does
>>>>>>>> not
>>>>>>>> make sense. It would be better if the framework was designed to run
>>>>>>>> outside
>>>>>>>> a J2EE container, and then have container integration as an option.
>>>>>>>>
>>>>>>>> Configuration files are scattered everywhere. Anyone who has
>>>>>>>> deployed
>>>>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>>>>> configuration settings are in nonsensical places.
>>>>>>>>
>>>>>>>> An abysmal lack of unit testing. I don't have an exact figure for
>>>>>>>> code
>>>>>>>> coverage, but my gut feeling is coverage is less than 10%.
>>>>>>>> Basically,
>>>>>>>> we
>>>>>>>> all have our fingers crossed - hoping that the framework code works
>>>>>>>> as
>>>>>>>> expected. This was made painfully obvious a while back when I was
>>>>>>>> looking
>>>>>>>> at some entity caching code and thought to myself "this code can't
>>>>>>>> work."
>>>>>>>> So I wrote some entity cache unit tests and confirmed that the
>>>>>>>> entity
>>>>>>>> cache
>>>>>>>> had serious problems. Think about that - years passed with no entity
>>>>>>>> cache
>>>>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>>>>
>>>>>>>> Fix Versus Rewrite
>>>>>>>> ------------------
>>>>>>>>
>>>>>>>> Jira issues could be created for these problems and teams of
>>>>>>>> developers
>>>>>>>> could work to fix them.
>>>>>>>>
>>>>>>>> Or, we could create a branch and start over from scratch. This time
>>>>>>>> around, there should be less push-back from people concerned about
>>>>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>>>>> reconsidering
>>>>>>>> everything - like API design, general problem solving, and new
>>>>>>>> features.
>>>>>>>>
>>>>>>>> I created a Wiki page for a framework design:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>>>>
>>>>>>>>
>>>>>>>> but there hasn't been much interest in it. If the community decides
>>>>>>>> to go
>>>>>>>> ahead with a rewrite, then please feel free to use the Wiki pages
>>>>>>>> as a
>>>>>>>> guide.
>>>>>>>>
>>>>>>>> Sandglass Foundation
>>>>>>>> --------------------
>>>>>>>>
>>>>>>>> Like David, I came to the conclusion that a framework rewrite would
>>>>>>>> be
>>>>>>>> easier outside the OFBiz community. So, I created my own library
>>>>>>>> called
>>>>>>>> Foundation:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>>>>
>>>>>>>>
>>>>>>>> (PDF)
>>>>>>>>
>>>>>>>> and I only mention it here to stress how wonderful it can be to
>>>>>>>> start
>>>>>>>> with
>>>>>>>> a clean slate and design an API that is concise yet powerful.
>>>>>>>> (Please
>>>>>>>> do
>>>>>>>> not discuss Foundation here, contact me privately if you want more
>>>>>>>> information.)
>>>>>>>>
>>>>>>>> Some examples of what can be done with a rewrite:
>>>>>>>>
>>>>>>>>       A single configuration file
>>>>>>>>       Use ANSI/ISO SQL SELECT statement strings instead of
>>>>>>>> constructing
>>>>>>>> complicated Java structures
>>>>>>>>       Simultaneous asynchronous queries
>>>>>>>>       Relational integrity across multiple datasources
>>>>>>>>       Multi-table SELECT across multiple datasources
>>>>>>>>       Automatic and transparent row version control
>>>>>>>>       Automatic and transparent multi-language datasource support
>>>>>>>>       Abstract entities (similar to SQL user types)
>>>>>>>>       Service engine throttling (protects against server
>>>>>>>> over-utilization)
>>>>>>>>       Simplified security (authorization) (
>>>>>>>>
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign
>>>>>>>> )
>>>>>>>>
>>>>>>>>
>>>>>>>>       Pure interface-based API - so developers are free to modify
>>>>>>>> framework
>>>>>>>> behavior by using decorators
>>>>>>>>       Thorough unit tests
>>>>>>>>
>>>>>>>> Benefits of a rewrite:
>>>>>>>>
>>>>>>>>       Reduced resource requirements (lower hosting fees)
>>>>>>>>       Reduce application development time - due to a simplified API
>>>>>>>>       Easier framework code maintenance
>>>>>>>>       Better reliability
>>>>>>>>
>>>>>>>> Conclusion
>>>>>>>> ----------
>>>>>>>>
>>>>>>>> Like I said at the start, this is all I will say about the subject.
>>>>>>>> I'm
>>>>>>>> done trying to convince everyone. I hope someone agrees with me and
>>>>>>>> they
>>>>>>>> are able to build support for the idea.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>

[Hans Bakker]

Well said: +1

On 15/10/15 22:13, Al Byers wrote:

> Fair enough, Adrian, but is this a widely held position on OFBiz that as a
> group you could produce a product that is so much better than Moqui that it
> would be worth the time and risk (the risk of burning cycles that you will
> never get back only to have the venture never succeed.) Have all the people
> who would like to do a rewrite done the same gap analysis on Moqui vs what
> you would like to see OFBiz be? Does everyone understand and agree that the
> deficiencies that you see in Moqui are important? My concern is that the
> many people who understandably want a rewrite of OFBiz will be swayed by
> your arguments without there being due diligence being done. I think that
> there are a lot of veterans of OFBiz who have confidence in David's
> development skills, but who are not pressing for a move to Moqui or for a
> rewrite because they have so much invested in the current state of OFBiz
> and recognized what a long shot a rewrite would be and how much work it
> would require of them to move over. But anybody who is open to a rewrite
> would be foolish not to consider the work done by the principal architect
> of OFBiz; work that was meant to address deficiencies in OFBiz.
>
> On Thu, Oct 15, 2015 at 7:58 AM, Adrian Crum <
> [hidden email]> wrote:
>
>> Keep in mind that much of David's code in OFBiz has been rewritten. So
>> yes, we CAN do a better job than him. Also keep in mind that Moqui
>> duplicates some of the problems I listed - so by using Moqui, we keep the
>> same problems instead of fixing them. On the other hand, it is David's
>> responsibility to fix them, not ours.
>>
>> If we created a sub-project, then we would have the opportunity to review
>> committer permissions and perhaps restrict access to the new code.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 10/15/2015 6:34 AM, Al Byers wrote:
>>
>>> I was waiting for someone to bring this up. David Jones created Moqui with
>>> the same end in mind that the rewrite is meant to accomplish. Do you think
>>> that you will do a better job than him? Even if you could, would it be so
>>> much better that it warrants the effort that it would take?
>>>
>>> Is this a political thing? I don't know that David would give up control
>>> of
>>> Moqui Core and I, for one, would not want him to. So many of OFBiz's
>>> problems are the result of ineptitude on the part of committers who did
>>> not
>>> know what they were doing (like me.) But I don't know that the Core will
>>> change all that much going forward and there should be places in the
>>> Mantle
>>> to contribute and, most certainly, in the Crust.
>>>
>>> I know that there were some valid questions about licensing and project
>>> management, but I would think that they could be worked out.
>>>
>>> On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <[hidden email]>
>>> wrote:
>>>
>>> Why not skip this step, using moqui which is already up and running and
>>>> then as Adrian states as a next step: applications could be pulled down
>>>> and
>>>> adapted to it.
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>> On 15/10/15 16:51, Jacques Le Roux wrote:
>>>>
>>>> I'm in the same mood than Paul and Scott. So a sub-project could indeed
>>>>> be a solution.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 15/10/2015 03:11, Adrian Crum a écrit :
>>>>>
>>>>> I agree that a sub-project would be nice to have. Once the new framework
>>>>>> is up and running, applications could be pulled down and adapted to it.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>>>>>
>>>>>> This seems to be very good advice.
>>>>>>> A completely separate sub-project under OFBiz with its own mailing
>>>>>>> lists
>>>>>>> would keep the people together yet all allow the new framework the
>>>>>>> flexibility to move forward.
>>>>>>>
>>>>>>> Ron
>>>>>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>>>>>
>>>>>>> My advice is as follows:
>>>>>>>> 1. If people are interested, then get them together and start working
>>>>>>>> on it.
>>>>>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>>>>>> appropriate
>>>>>>>> because it's completely new development rather than a refactoring.  I
>>>>>>>> don't
>>>>>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>>>>>> (although
>>>>>>>> I don't really see the need either).
>>>>>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try
>>>>>>>> and
>>>>>>>> keep quiet about it in the early stages on the dev/user lists or
>>>>>>>> other
>>>>>>>> marketing channels because it could potentially harm adoption of our
>>>>>>>> existing framework (think AngularJS 2.0).
>>>>>>>>
>>>>>>>> There really isn't any need to get early stage sign-off from the PMC
>>>>>>>> or
>>>>>>>> anyone else in the community.  You only need enough PMC approval to
>>>>>>>> get the
>>>>>>>> required infrastructure sorted, which I don't think would be an
>>>>>>>> issue.
>>>>>>>> >From there, it's really up to the community to decide whether or not
>>>>>>>> the
>>>>>>>> thing will fly.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>>>>>> <[hidden email]
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>>>>>> action
>>>>>>>>> needs to be taken.
>>>>>>>>>
>>>>>>>>> In this message, I will try to give a detailed explanation of why a
>>>>>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>>>>>> action on
>>>>>>>>> this subject, because I've brought it up before without success, and
>>>>>>>>> I'm
>>>>>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>>>>>> on in
>>>>>>>>> someone's head and they will take action.
>>>>>>>>>
>>>>>>>>> My Background
>>>>>>>>> -------------
>>>>>>>>>
>>>>>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>>>>>> started
>>>>>>>>> making contributions to the project by supplying patches to the
>>>>>>>>> issue
>>>>>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>>>>>> on the
>>>>>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>>>>>> Work
>>>>>>>>> Effort). I stayed away from touching the framework code because it
>>>>>>>>> was
>>>>>>>>> deep, dark, and scary.
>>>>>>>>>
>>>>>>>>> Eventually, I started to understand how the framework code works
>>>>>>>>> and I
>>>>>>>>> made some minor modifications. As my understanding grew, I
>>>>>>>>> progressed
>>>>>>>>> to
>>>>>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>>>>>> fault
>>>>>>>>> tolerant, efficient, and easier to use.
>>>>>>>>>
>>>>>>>>> I will list some of my contributions here, so everyone can have a
>>>>>>>>> clear
>>>>>>>>> understanding of my experience with the framework code:
>>>>>>>>>
>>>>>>>>>        New Features
>>>>>>>>>
>>>>>>>>>            User Preferences
>>>>>>>>>
>>>>>>>>>            Visual Themes
>>>>>>>>>
>>>>>>>>>            Custom UI Label XML File Format
>>>>>>>>>
>>>>>>>>>            Temporal Expressions
>>>>>>>>>
>>>>>>>>>            Data Type Conversion Framework
>>>>>>>>>
>>>>>>>>>            Screen Widget Boundary Comments
>>>>>>>>>
>>>>>>>>>            Metrics
>>>>>>>>>
>>>>>>>>>        Integrations
>>>>>>>>>
>>>>>>>>>            UEL
>>>>>>>>>
>>>>>>>>>            iCalendar
>>>>>>>>>
>>>>>>>>>            JSR 223
>>>>>>>>>
>>>>>>>>>            WebDAV
>>>>>>>>>
>>>>>>>>>            LDAP
>>>>>>>>>
>>>>>>>>>        Refactorings/Improvements
>>>>>>>>>
>>>>>>>>>            FlexibleStringExpander
>>>>>>>>>
>>>>>>>>>            FlexibleMapExpander
>>>>>>>>>
>>>>>>>>>            FOP Integration
>>>>>>>>>
>>>>>>>>>            FreeMarkerWorker
>>>>>>>>>
>>>>>>>>>            Date-Time Handling
>>>>>>>>>
>>>>>>>>>            Mini-language
>>>>>>>>>
>>>>>>>>>            Job Scheduler
>>>>>>>>>
>>>>>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>>>>>
>>>>>>>>> So, the contents of this message come from years of experience
>>>>>>>>> mucking
>>>>>>>>> about in the framework code.
>>>>>>>>>
>>>>>>>>> Okay, let's get started...
>>>>>>>>>
>>>>>>>>> Initial Problem Statement
>>>>>>>>> -------------------------
>>>>>>>>>
>>>>>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>>>>>
>>>>>>>>> At the time, there was some agreement that a rewrite was necessary,
>>>>>>>>> but
>>>>>>>>> there was disagreement as to how the rewrite should be incorporated
>>>>>>>>> into
>>>>>>>>> the project:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There were concerns that a rewrite would break backward
>>>>>>>>> compatibility.
>>>>>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>>>>>> community be more accepting of backward-incompatible changes:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Despite an effort to convince David to proceed with the framework
>>>>>>>>> rewrite,
>>>>>>>>> he ended up doing it in a separate project:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>>>>>> it you
>>>>>>>>> can extract information on the problems David was trying to solve:
>>>>>>>>>
>>>>>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>>>>>
>>>>>>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>>>>>>> the
>>>>>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>>>>>> this
>>>>>>>>> message will include the issues he mentioned (the ones I remember).
>>>>>>>>> I
>>>>>>>>> was
>>>>>>>>> in agreement with him at the time, and I still agree that a
>>>>>>>>> framework
>>>>>>>>> rewrite is necessary.
>>>>>>>>>
>>>>>>>>> The Problems
>>>>>>>>> ------------
>>>>>>>>>
>>>>>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>>>>>> framework modular. This causes serious problems. The mere fact that
>>>>>>>>> components like entityext and securityext EXIST makes it clear that
>>>>>>>>> there
>>>>>>>>> are problems - those components should not be there. Also, we run
>>>>>>>>> into the
>>>>>>>>> recurring problem of circular dependencies (component A will not
>>>>>>>>> build
>>>>>>>>> unless component B is built, and component B will not build unless
>>>>>>>>> component A is built).
>>>>>>>>>
>>>>>>>>> Bad separation of concerns. There are far too many examples of
>>>>>>>>> classes
>>>>>>>>> that try to be everything to everyone. This makes debugging
>>>>>>>>> difficult, and
>>>>>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>>>>>> consider
>>>>>>>>> an automobile design where a spark plug is not separate from a
>>>>>>>>> transmission. Instead, the automobile uses a
>>>>>>>>> spark-plug-transmission.
>>>>>>>>> So
>>>>>>>>> when the engine is running rough because the spark plug is bad, you
>>>>>>>>> have to
>>>>>>>>> replace the spark plug AND the transmission.] A good framework
>>>>>>>>> example can
>>>>>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>>>>>> models
>>>>>>>>> AND the script execution context both contained script behaviors -
>>>>>>>>> making
>>>>>>>>> debugging/improvements difficult. I changed it so only the models
>>>>>>>>> contain
>>>>>>>>> script behavior and the script execution context contains only the
>>>>>>>>> script
>>>>>>>>> execution state.
>>>>>>>>>
>>>>>>>>> Lack of good OO design. There are many places where a bit of
>>>>>>>>> framework
>>>>>>>>> functionality is contained in a single method that is hundreds or
>>>>>>>>> thousands
>>>>>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>>>>>> reused.
>>>>>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>>>>>> in the
>>>>>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>>>>>
>>>>>>>>> Fail-slow design. There are a lot of places in low-level code where
>>>>>>>>> an
>>>>>>>>> error condition is encountered, but instead of throwing an
>>>>>>>>> exception,
>>>>>>>>> the
>>>>>>>>> error is ignored and maybe it is logged, or the code tries to
>>>>>>>>> "guess"
>>>>>>>>> at a
>>>>>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>>>>>> many
>>>>>>>>> developers struggle with debugging a problem because they didn't
>>>>>>>>> look
>>>>>>>>> at
>>>>>>>>> the logs, or because the error was not logged and there is no way of
>>>>>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>>>>>> through
>>>>>>>>> code until it reaches the error.
>>>>>>>>>
>>>>>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>>>>>> library
>>>>>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>>>>>> because
>>>>>>>>> of improved garbage collection. Another good example is DCL code.
>>>>>>>>> DCL
>>>>>>>>> was
>>>>>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>>>>>> unreliable
>>>>>>>>> design (I can get it to fail 90% of the time). Some DCL code has
>>>>>>>>> been
>>>>>>>>> replaced, but a lot of it is still there.
>>>>>>>>>
>>>>>>>>> Portions of the API are overly complicated. Some methods require a
>>>>>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>>>>>> code
>>>>>>>>> complicated and verbose. (David solved that problem with his
>>>>>>>>> Execution
>>>>>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>>>>>> "convenience
>>>>>>>>> methods" - making the API harder to learn and memorize. In some
>>>>>>>>> places, a
>>>>>>>>> domain-specific API is spread across instance methods and static
>>>>>>>>> methods
>>>>>>>>> and across different classes - making the API hard to understand and
>>>>>>>>> use.
>>>>>>>>> Yes, there can be good designs that require something like that, but
>>>>>>>>> in the
>>>>>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>>>>>
>>>>>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>>>>>> thread
>>>>>>>>> per request (and most J2EE libraries depend on that behavior), so
>>>>>>>>> the
>>>>>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>>>>>> don't
>>>>>>>>> want to run the framework in a J2EE container? Which leads to the
>>>>>>>>> next
>>>>>>>>> problem...
>>>>>>>>>
>>>>>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in
>>>>>>>>> the
>>>>>>>>> Java community (myself included) who are beginning to question if
>>>>>>>>> J2EE is
>>>>>>>>> really necessary to run web applications. The folks at Atomikos are
>>>>>>>>> a
>>>>>>>>> good
>>>>>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE
>>>>>>>>> does
>>>>>>>>> not
>>>>>>>>> make sense. It would be better if the framework was designed to run
>>>>>>>>> outside
>>>>>>>>> a J2EE container, and then have container integration as an option.
>>>>>>>>>
>>>>>>>>> Configuration files are scattered everywhere. Anyone who has
>>>>>>>>> deployed
>>>>>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>>>>>> configuration settings are in nonsensical places.
>>>>>>>>>
>>>>>>>>> An abysmal lack of unit testing. I don't have an exact figure for
>>>>>>>>> code
>>>>>>>>> coverage, but my gut feeling is coverage is less than 10%.
>>>>>>>>> Basically,
>>>>>>>>> we
>>>>>>>>> all have our fingers crossed - hoping that the framework code works
>>>>>>>>> as
>>>>>>>>> expected. This was made painfully obvious a while back when I was
>>>>>>>>> looking
>>>>>>>>> at some entity caching code and thought to myself "this code can't
>>>>>>>>> work."
>>>>>>>>> So I wrote some entity cache unit tests and confirmed that the
>>>>>>>>> entity
>>>>>>>>> cache
>>>>>>>>> had serious problems. Think about that - years passed with no entity
>>>>>>>>> cache
>>>>>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>>>>>
>>>>>>>>> Fix Versus Rewrite
>>>>>>>>> ------------------
>>>>>>>>>
>>>>>>>>> Jira issues could be created for these problems and teams of
>>>>>>>>> developers
>>>>>>>>> could work to fix them.
>>>>>>>>>
>>>>>>>>> Or, we could create a branch and start over from scratch. This time
>>>>>>>>> around, there should be less push-back from people concerned about
>>>>>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>>>>>> reconsidering
>>>>>>>>> everything - like API design, general problem solving, and new
>>>>>>>>> features.
>>>>>>>>>
>>>>>>>>> I created a Wiki page for a framework design:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> but there hasn't been much interest in it. If the community decides
>>>>>>>>> to go
>>>>>>>>> ahead with a rewrite, then please feel free to use the Wiki pages
>>>>>>>>> as a
>>>>>>>>> guide.
>>>>>>>>>
>>>>>>>>> Sandglass Foundation
>>>>>>>>> --------------------
>>>>>>>>>
>>>>>>>>> Like David, I came to the conclusion that a framework rewrite would
>>>>>>>>> be
>>>>>>>>> easier outside the OFBiz community. So, I created my own library
>>>>>>>>> called
>>>>>>>>> Foundation:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (PDF)
>>>>>>>>>
>>>>>>>>> and I only mention it here to stress how wonderful it can be to
>>>>>>>>> start
>>>>>>>>> with
>>>>>>>>> a clean slate and design an API that is concise yet powerful.
>>>>>>>>> (Please
>>>>>>>>> do
>>>>>>>>> not discuss Foundation here, contact me privately if you want more
>>>>>>>>> information.)
>>>>>>>>>
>>>>>>>>> Some examples of what can be done with a rewrite:
>>>>>>>>>
>>>>>>>>>        A single configuration file
>>>>>>>>>        Use ANSI/ISO SQL SELECT statement strings instead of
>>>>>>>>> constructing
>>>>>>>>> complicated Java structures
>>>>>>>>>        Simultaneous asynchronous queries
>>>>>>>>>        Relational integrity across multiple datasources
>>>>>>>>>        Multi-table SELECT across multiple datasources
>>>>>>>>>        Automatic and transparent row version control
>>>>>>>>>        Automatic and transparent multi-language datasource support
>>>>>>>>>        Abstract entities (similar to SQL user types)
>>>>>>>>>        Service engine throttling (protects against server
>>>>>>>>> over-utilization)
>>>>>>>>>        Simplified security (authorization) (
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>        Pure interface-based API - so developers are free to modify
>>>>>>>>> framework
>>>>>>>>> behavior by using decorators
>>>>>>>>>        Thorough unit tests
>>>>>>>>>
>>>>>>>>> Benefits of a rewrite:
>>>>>>>>>
>>>>>>>>>        Reduced resource requirements (lower hosting fees)
>>>>>>>>>        Reduce application development time - due to a simplified API
>>>>>>>>>        Easier framework code maintenance
>>>>>>>>>        Better reliability
>>>>>>>>>
>>>>>>>>> Conclusion
>>>>>>>>> ----------
>>>>>>>>>
>>>>>>>>> Like I said at the start, this is all I will say about the subject.
>>>>>>>>> I'm
>>>>>>>>> done trying to convince everyone. I hope someone agrees with me and
>>>>>>>>> they
>>>>>>>>> are able to build support for the idea.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Adrian Crum
>>>>>>>>> Sandglass Software
>>>>>>>>> www.sandglass-software.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>

[Shi Jinghai-3]

+1

-----邮件原件-----
发件人: Adrian Crum [mailto:[hidden email]]
发送时间: 2015年10月15日 21:59
收件人: [hidden email]
主题: Re: Why A Framework Rewrite Is Necessary

Keep in mind that much of David's code in OFBiz has been rewritten. So
yes, we CAN do a better job than him. Also keep in mind that Moqui
duplicates some of the problems I listed - so by using Moqui, we keep
the same problems instead of fixing them. On the other hand, it is
David's responsibility to fix them, not ours.

If we created a sub-project, then we would have the opportunity to
review committer permissions and perhaps restrict access to the new code.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/15/2015 6:34 AM, Al Byers wrote:

> I was waiting for someone to bring this up. David Jones created Moqui with
> the same end in mind that the rewrite is meant to accomplish. Do you think
> that you will do a better job than him? Even if you could, would it be so
> much better that it warrants the effort that it would take?
>
> Is this a political thing? I don't know that David would give up control of
> Moqui Core and I, for one, would not want him to. So many of OFBiz's
> problems are the result of ineptitude on the part of committers who did not
> know what they were doing (like me.) But I don't know that the Core will
> change all that much going forward and there should be places in the Mantle
> to contribute and, most certainly, in the Crust.
>
> I know that there were some valid questions about licensing and project
> management, but I would think that they could be worked out.
>
> On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <[hidden email]>
> wrote:
>
>> Why not skip this step, using moqui which is already up and running and
>> then as Adrian states as a next step: applications could be pulled down and
>> adapted to it.
>>
>> Hans
>>
>>
>>
>> On 15/10/15 16:51, Jacques Le Roux wrote:
>>
>>> I'm in the same mood than Paul and Scott. So a sub-project could indeed
>>> be a solution.
>>>
>>> Jacques
>>>
>>> Le 15/10/2015 03:11, Adrian Crum a écrit :
>>>
>>>> I agree that a sub-project would be nice to have. Once the new framework
>>>> is up and running, applications could be pulled down and adapted to it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 10/14/2015 5:53 PM, Ron Wheeler wrote:
>>>>
>>>>> This seems to be very good advice.
>>>>> A completely separate sub-project under OFBiz with its own mailing lists
>>>>> would keep the people together yet all allow the new framework the
>>>>> flexibility to move forward.
>>>>>
>>>>> Ron
>>>>> On 14/10/2015 8:27 PM, Scott Gray wrote:
>>>>>
>>>>>> My advice is as follows:
>>>>>> 1. If people are interested, then get them together and start working
>>>>>> on it.
>>>>>> 2. Find somewhere to do the work.  I don't think a branch is
>>>>>> appropriate
>>>>>> because it's completely new development rather than a refactoring.  I
>>>>>> don't
>>>>>> have any objections to it being done under the ASF OFBiz umbrella
>>>>>> (although
>>>>>> I don't really see the need either).
>>>>>> 3. Set up a separate mailing list for discussion.  Generally I'd try
>>>>>> and
>>>>>> keep quiet about it in the early stages on the dev/user lists or other
>>>>>> marketing channels because it could potentially harm adoption of our
>>>>>> existing framework (think AngularJS 2.0).
>>>>>>
>>>>>> There really isn't any need to get early stage sign-off from the PMC or
>>>>>> anyone else in the community.  You only need enough PMC approval to
>>>>>> get the
>>>>>> required infrastructure sorted, which I don't think would be an issue.
>>>>>> >From there, it's really up to the community to decide whether or not
>>>>>> the
>>>>>> thing will fly.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> On 15 October 2015 at 08:21, Adrian Crum
>>>>>> <[hidden email]
>>>>>>
>>>>>>> wrote:
>>>>>>> I understand that Sharan brought up the framework rewrite subject at
>>>>>>> ApacheCon, and some attendees felt that the framework is fine and no
>>>>>>> action
>>>>>>> needs to be taken.
>>>>>>>
>>>>>>> In this message, I will try to give a detailed explanation of why a
>>>>>>> framework rewrite is necessary. I don't plan to take any further
>>>>>>> action on
>>>>>>> this subject, because I've brought it up before without success, and
>>>>>>> I'm
>>>>>>> tired of discussing it. It is my hope that the light bulb will click
>>>>>>> on in
>>>>>>> someone's head and they will take action.
>>>>>>>
>>>>>>> My Background
>>>>>>> -------------
>>>>>>>
>>>>>>> I became a member of the OFBiz community in 2004. I immediately
>>>>>>> started
>>>>>>> making contributions to the project by supplying patches to the issue
>>>>>>> tracker. In 2007, I became a committer. Most of my initial work was
>>>>>>> on the
>>>>>>> UI and some work in the applications (mainly Asset Maintenance and
>>>>>>> Work
>>>>>>> Effort). I stayed away from touching the framework code because it was
>>>>>>> deep, dark, and scary.
>>>>>>>
>>>>>>> Eventually, I started to understand how the framework code works and I
>>>>>>> made some minor modifications. As my understanding grew, I progressed
>>>>>>> to
>>>>>>> rewriting large swaths of framework code - making it thread-safe,
>>>>>>> fault
>>>>>>> tolerant, efficient, and easier to use.
>>>>>>>
>>>>>>> I will list some of my contributions here, so everyone can have a
>>>>>>> clear
>>>>>>> understanding of my experience with the framework code:
>>>>>>>
>>>>>>>       New Features
>>>>>>>
>>>>>>>           User Preferences
>>>>>>>
>>>>>>>           Visual Themes
>>>>>>>
>>>>>>>           Custom UI Label XML File Format
>>>>>>>
>>>>>>>           Temporal Expressions
>>>>>>>
>>>>>>>           Data Type Conversion Framework
>>>>>>>
>>>>>>>           Screen Widget Boundary Comments
>>>>>>>
>>>>>>>           Metrics
>>>>>>>
>>>>>>>       Integrations
>>>>>>>
>>>>>>>           UEL
>>>>>>>
>>>>>>>           iCalendar
>>>>>>>
>>>>>>>           JSR 223
>>>>>>>
>>>>>>>           WebDAV
>>>>>>>
>>>>>>>           LDAP
>>>>>>>
>>>>>>>       Refactorings/Improvements
>>>>>>>
>>>>>>>           FlexibleStringExpander
>>>>>>>
>>>>>>>           FlexibleMapExpander
>>>>>>>
>>>>>>>           FOP Integration
>>>>>>>
>>>>>>>           FreeMarkerWorker
>>>>>>>
>>>>>>>           Date-Time Handling
>>>>>>>
>>>>>>>           Mini-language
>>>>>>>
>>>>>>>           Job Scheduler
>>>>>>>
>>>>>>> In addition, I have performed innumerable framework bug fixes.
>>>>>>>
>>>>>>> So, the contents of this message come from years of experience mucking
>>>>>>> about in the framework code.
>>>>>>>
>>>>>>> Okay, let's get started...
>>>>>>>
>>>>>>> Initial Problem Statement
>>>>>>> -------------------------
>>>>>>>
>>>>>>> In 2009, David Jones started a framework rewrite in a branch:
>>>>>>>
>>>>>>>
>>>>>>> https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716
>>>>>>>
>>>>>>> At the time, there was some agreement that a rewrite was necessary,
>>>>>>> but
>>>>>>> there was disagreement as to how the rewrite should be incorporated
>>>>>>> into
>>>>>>> the project:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3C455601.62605.qm@...%3E
>>>>>>>
>>>>>>>
>>>>>>> There were concerns that a rewrite would break backward compatibility.
>>>>>>> Work on the rewrite branch stopped. Eventually, Jacopo suggested the
>>>>>>> community be more accepting of backward-incompatible changes:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cD24F129D-4F9F-444E-84AF-ACA46F49990C@...%3e
>>>>>>>
>>>>>>>
>>>>>>> Despite an effort to convince David to proceed with the framework
>>>>>>> rewrite,
>>>>>>> he ended up doing it in a separate project:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3C07565C88-4023-4D24-93A3-A4906E86F939@...%3E
>>>>>>>
>>>>>>>
>>>>>>> This page describes differences between OFBiz and Moqui, and within
>>>>>>> it you
>>>>>>> can extract information on the problems David was trying to solve:
>>>>>>>
>>>>>>> http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/
>>>>>>>
>>>>>>> There was an email he sent out on the OFBiz dev list where he listed
>>>>>>> the
>>>>>>> problems he saw in the framework, but I can't find it. The rest of
>>>>>>> this
>>>>>>> message will include the issues he mentioned (the ones I remember). I
>>>>>>> was
>>>>>>> in agreement with him at the time, and I still agree that a framework
>>>>>>> rewrite is necessary.
>>>>>>>
>>>>>>> The Problems
>>>>>>> ------------
>>>>>>>
>>>>>>> Code is scattered everywhere - due to an initial effort to make the
>>>>>>> framework modular. This causes serious problems. The mere fact that
>>>>>>> components like entityext and securityext EXIST makes it clear that
>>>>>>> there
>>>>>>> are problems - those components should not be there. Also, we run
>>>>>>> into the
>>>>>>> recurring problem of circular dependencies (component A will not build
>>>>>>> unless component B is built, and component B will not build unless
>>>>>>> component A is built).
>>>>>>>
>>>>>>> Bad separation of concerns. There are far too many examples of classes
>>>>>>> that try to be everything to everyone. This makes debugging
>>>>>>> difficult, and
>>>>>>> it makes maintenance/improvements a nightmare. [Using an analogy,
>>>>>>> consider
>>>>>>> an automobile design where a spark plug is not separate from a
>>>>>>> transmission. Instead, the automobile uses a spark-plug-transmission.
>>>>>>> So
>>>>>>> when the engine is running rough because the spark plug is bad, you
>>>>>>> have to
>>>>>>> replace the spark plug AND the transmission.] A good framework
>>>>>>> example can
>>>>>>> be found in my rewrite of the mini-language code. Originally, the
>>>>>>> models
>>>>>>> AND the script execution context both contained script behaviors -
>>>>>>> making
>>>>>>> debugging/improvements difficult. I changed it so only the models
>>>>>>> contain
>>>>>>> script behavior and the script execution context contains only the
>>>>>>> script
>>>>>>> execution state.
>>>>>>>
>>>>>>> Lack of good OO design. There are many places where a bit of framework
>>>>>>> functionality is contained in a single method that is hundreds or
>>>>>>> thousands
>>>>>>> of lines long. There is a term for that: Brittle Code. Code isn't
>>>>>>> reused.
>>>>>>> Instead, it is copy-and-pasted all over - so when a problem is found
>>>>>>> in the
>>>>>>> C&P code, it has to be fixed in many places instead of one.
>>>>>>>
>>>>>>> Fail-slow design. There are a lot of places in low-level code where an
>>>>>>> error condition is encountered, but instead of throwing an exception,
>>>>>>> the
>>>>>>> error is ignored and maybe it is logged, or the code tries to "guess"
>>>>>>> at a
>>>>>>> solution and then provide an arbitrary default behavior. I've seen
>>>>>>> many
>>>>>>> developers struggle with debugging a problem because they didn't look
>>>>>>> at
>>>>>>> the logs, or because the error was not logged and there is no way of
>>>>>>> knowing what caused it. They end up spending hours single-stepping
>>>>>>> through
>>>>>>> code until it reaches the error.
>>>>>>>
>>>>>>> Out-of-date code. A good example is the use of Javolution. That
>>>>>>> library
>>>>>>> was beneficial in the Java 1.4 days, but it is not necessary today
>>>>>>> because
>>>>>>> of improved garbage collection. Another good example is DCL code. DCL
>>>>>>> was
>>>>>>> used extensively in OFBiz, but it is clearly documented to be an
>>>>>>> unreliable
>>>>>>> design (I can get it to fail 90% of the time). Some DCL code has been
>>>>>>> replaced, but a lot of it is still there.
>>>>>>>
>>>>>>> Portions of the API are overly complicated. Some methods require a
>>>>>>> collection of user-specified artifacts/arguments, which makes client
>>>>>>> code
>>>>>>> complicated and verbose. (David solved that problem with his Execution
>>>>>>> Context.) Portions of the API are cluttered with unnecessary
>>>>>>> "convenience
>>>>>>> methods" - making the API harder to learn and memorize. In some
>>>>>>> places, a
>>>>>>> domain-specific API is spread across instance methods and static
>>>>>>> methods
>>>>>>> and across different classes - making the API hard to understand and
>>>>>>> use.
>>>>>>> Yes, there can be good designs that require something like that, but
>>>>>>> in the
>>>>>>> OFBiz framework, it exists because of a bad design, not a good one.
>>>>>>>
>>>>>>> Use of thread-local variables. This makes multi-threaded design
>>>>>>> impossible. The J2EE specification and the Servlet API require one
>>>>>>> thread
>>>>>>> per request (and most J2EE libraries depend on that behavior), so the
>>>>>>> current design makes sense from a J2EE perspective, but what if I
>>>>>>> don't
>>>>>>> want to run the framework in a J2EE container? Which leads to the next
>>>>>>> problem...
>>>>>>>
>>>>>>> Dependence on J2EE designs/APIs/libraries. There are developers in the
>>>>>>> Java community (myself included) who are beginning to question if
>>>>>>> J2EE is
>>>>>>> really necessary to run web applications. The folks at Atomikos are a
>>>>>>> good
>>>>>>> example. OFBiz does not use EJBs, so tying the framework to J2EE does
>>>>>>> not
>>>>>>> make sense. It would be better if the framework was designed to run
>>>>>>> outside
>>>>>>> a J2EE container, and then have container integration as an option.
>>>>>>>
>>>>>>> Configuration files are scattered everywhere. Anyone who has deployed
>>>>>>> OFBiz in a production environment will agree this is a problem. Try
>>>>>>> changing the HTTP/HTTPS and port settings - it is a nightmare. Some
>>>>>>> configuration settings are in nonsensical places.
>>>>>>>
>>>>>>> An abysmal lack of unit testing. I don't have an exact figure for code
>>>>>>> coverage, but my gut feeling is coverage is less than 10%. Basically,
>>>>>>> we
>>>>>>> all have our fingers crossed - hoping that the framework code works as
>>>>>>> expected. This was made painfully obvious a while back when I was
>>>>>>> looking
>>>>>>> at some entity caching code and thought to myself "this code can't
>>>>>>> work."
>>>>>>> So I wrote some entity cache unit tests and confirmed that the entity
>>>>>>> cache
>>>>>>> had serious problems. Think about that - years passed with no entity
>>>>>>> cache
>>>>>>> unit tests and consequently we had no idea it wasn't working.
>>>>>>>
>>>>>>> Fix Versus Rewrite
>>>>>>> ------------------
>>>>>>>
>>>>>>> Jira issues could be created for these problems and teams of
>>>>>>> developers
>>>>>>> could work to fix them.
>>>>>>>
>>>>>>> Or, we could create a branch and start over from scratch. This time
>>>>>>> around, there should be less push-back from people concerned about
>>>>>>> backwards compatibility. A rewrite offers the advantage of
>>>>>>> reconsidering
>>>>>>> everything - like API design, general problem solving, and new
>>>>>>> features.
>>>>>>>
>>>>>>> I created a Wiki page for a framework design:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
>>>>>>>
>>>>>>>
>>>>>>> but there hasn't been much interest in it. If the community decides
>>>>>>> to go
>>>>>>> ahead with a rewrite, then please feel free to use the Wiki pages as a
>>>>>>> guide.
>>>>>>>
>>>>>>> Sandglass Foundation
>>>>>>> --------------------
>>>>>>>
>>>>>>> Like David, I came to the conclusion that a framework rewrite would be
>>>>>>> easier outside the OFBiz community. So, I created my own library
>>>>>>> called
>>>>>>> Foundation:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf
>>>>>>>
>>>>>>>
>>>>>>> (PDF)
>>>>>>>
>>>>>>> and I only mention it here to stress how wonderful it can be to start
>>>>>>> with
>>>>>>> a clean slate and design an API that is concise yet powerful. (Please
>>>>>>> do
>>>>>>> not discuss Foundation here, contact me privately if you want more
>>>>>>> information.)
>>>>>>>
>>>>>>> Some examples of what can be done with a rewrite:
>>>>>>>
>>>>>>>       A single configuration file
>>>>>>>       Use ANSI/ISO SQL SELECT statement strings instead of constructing
>>>>>>> complicated Java structures
>>>>>>>       Simultaneous asynchronous queries
>>>>>>>       Relational integrity across multiple datasources
>>>>>>>       Multi-table SELECT across multiple datasources
>>>>>>>       Automatic and transparent row version control
>>>>>>>       Automatic and transparent multi-language datasource support
>>>>>>>       Abstract entities (similar to SQL user types)
>>>>>>>       Service engine throttling (protects against server
>>>>>>> over-utilization)
>>>>>>>       Simplified security (authorization) (
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
>>>>>>>
>>>>>>>
>>>>>>>       Pure interface-based API - so developers are free to modify
>>>>>>> framework
>>>>>>> behavior by using decorators
>>>>>>>       Thorough unit tests
>>>>>>>
>>>>>>> Benefits of a rewrite:
>>>>>>>
>>>>>>>       Reduced resource requirements (lower hosting fees)
>>>>>>>       Reduce application development time - due to a simplified API
>>>>>>>       Easier framework code maintenance
>>>>>>>       Better reliability
>>>>>>>
>>>>>>> Conclusion
>>>>>>> ----------
>>>>>>>
>>>>>>> Like I said at the start, this is all I will say about the subject.
>>>>>>> I'm
>>>>>>> done trying to convince everyone. I hope someone agrees with me and
>>>>>>> they
>>>>>>> are able to build support for the idea.
>>>>>>>
>>>>>>> --
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>