> On 28 Apr 2015, at 07:42, Adam Heath <doo...@brainfood.com> wrote: > > > 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.
Sounds like a small project of its own... >> - 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? The Moqui runtime folder is similar to the one in OFBiz with component directories, and framework specific directories for classes, conf, db, elasticsearch, lib, log, template, and txlog. The Derby DB files go under the db directory (similar to in OFBiz) and the same is true for the Elasticsearch files (if you are running an embedded ES node with local storage). Some of these Moqui needs as separate folders, some can be combined with OFBiz ones, like the Derby and log dirs. >> - 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. Moqui is designed to facilitate deployment as a single WAR file. The Screen definitions in Moqui live in an hierarchy and you can add the root screen of each of your apps under the /apps screen, or under the root screen if you don’t want the /apps screen decorations. There are other ways to deploy it, like the static init approach mentioned below, but for most use this is by far the easiest. There is even support to add the runtime directory to the WAR file which gets picked up automatically when present, making it possible to throw the whole thing into one big WAR file and drop it into Tomcat or upload it to AWS ElasticBeanstalk or the myriad of similar hosting options. >> - 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. Even though Moqui has a real init/destroy lifecycle, many things are lazy-loaded and cached just like in OFBiz. This provides a lot of flexibility in both development and for production maintenance/etc. Moqui does have some cache warming code for entities, services, and screens that is on by default in production mode. >> - 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? Yes. Initially this would be the easiest way to run them together. An early priority would be to use the Moqui transaction management (based on Bitronix or Atomikos, Bitronix being WAY faster and with the latest update far more reliable too) so that OFBiz Entity Engine and Moqui Entity Facade operations would share TX contexts. >> 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. Simpler at run time for sure, would take some work to build. > 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. As you mentioned this would be a stop-gap effort until the Entity Engine is running through Moqui. If someone needs or wants to populate Moqui entity defs from OFBiz ones at runtime badly enough it can certainly be done, but not sure it HAS to be done. Moqui has the same concepts of entity extension, override, etc. -David
