On 04/28/2015 03:39 AM, David E. Jones wrote:
+1 - with the clarification that to me "begin replacing" implies a PoC effort
in a branch.
I just saw this thread and need a little time to think over the best approach,
but off the top of my head it would look something like:
- add the moqui-framework-<version>.jar file and all dependent jars to a
component directory under ofbiz/framework (these could go in the base or common
components, but might be best separate for clarity); if needed update jars currently
used in OFBiz where an older version is used (don't know if this is the case for any,
mention for the sake of completeness)
There are 2 separate items in this bullet point. I'll talk about the
second, updating jar versions.
HAHAHAHAHAHAHA!
I have discovered that ofbiz is using hc.apache.org(HttpClient), and
commons-httpclient. The former is the newer, rewritten, rearchitected,
replacement for the latter.
The rest of the versioned jars are just as bad.
- add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui
uses this for various things); this would contain the Moqui tools components
(with the Tools and System apps) so we have a UI to look at Moqui internals,
OFBiz data, etc
Do each of the separate moqui sub-tools need their own runtime folder?
How difficult would it be to have $OFBIZ_HOME/runtime/$tool1,
runtime/$tool2, etc?
- either in the Moqui runtime directory or as an OFBiz component add a
"webroot" webapp; Moqui is designed to run in a single webapp, and I'd
recommend this be separate from the existing OFBiz webapps for now; when this webapp
loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy
it
Wait. The webapp initializes the context factory? There isn't a
separate way to do this? Does that mean Moqui is tied to a webapp? What
kind of webapp? I hope it isn't servlets.
You mention it as weboot. Does that mean it runs at the root of the
webserver? This might be a noob question.
- because initializing Moqui when the webroot webapp starts may not be
adequate, make sure the Moqui static init stuff is in place and working (in the
Moqui.java class)
Ah. So that means that means that moqui-component needs a container
definition. Ignore the above then.
I have never liked that ofbiz startup delays initialization of certain
components until they are magically called from some random bit of java
code, aka, the web container starting up.
- run my little templates to transform current OFBiz data model XML files into
Moqui ones and put those in a Moqui component in the Moqui runtime directory
Sorry for the noob question, but does that mean that both ofbiz
entityengine and moqui could talk to the same database backend(s), at
the same time?
This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the
real PoC of either a "thunk" layer as Adrian proposed, probably accessing the
statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes
are statically initialized, or using the more dynamic initialization through the Moqui
webroot webapp.
Actually, a bit simpler, would be to just see if moqui can be added to
the classpath, and loaded, before translating any datamodels. Once that
is done, then have a method that translates the model definitions
dynamically at load time, so that they are always kept in sync.
Once this has proven, then that dynamic translation can be removed, and
the output of it can become the new static definition of the model.
The reason I suggest this way, is so that hot-deploy components(or other
file modifications) that alter the entity definitions
dynamically(extends-entity, whole new entity definitions) can also work
transparently.
For those who want a brief introduction to some of the differences between OFBiz
Framework and Moqui Framework, see the "OFBiz: How does it compare to Moqui?"
section at:
http://www.moqui.org/framework/index.html
That is an older document and isn't meant to be any sort of exhaustive list of
the features of Moqui versus the features of OFBiz Framework, but gives a
general idea about how some of the similar tools are different.
For those who want to dive a bit deeper the Tutorial may be helpful:
http://www.moqui.org/framework/docs/Tutorial.html
For those who want to dive in neck deep the "Making Apps with Moqui" book is
the more exhaustive reference to Moqui (though about 8 months old now and there are many
new features, summarized in the ReleaseNotes.txt file for those curious):
http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt
I would be happy to participate in this effort... if nothing else should be an
interesting technical diversion.
-David
