> On 20 Apr 2015, at 13:21, Adrian Crum <adrian.c...@sandglass-software.com> > wrote: > > On 4/20/2015 7:39 PM, David E. Jones wrote: >> This is where I question whether it is a good idea to just replace the >> framework and leave all else as-is in OFBiz. I know very well that bringing >> this up is likely to stall the discussion and reduce the chances of OFBiz >> ever using Moqui, and the great thing for Moqui and OFBiz that it could be. >> Still, the effort required to do that migration is significant and IMO it >> would be far less effort to start with Moqui and Mantle and basically >> rewrite OFBiz to be a comprehensive business automation application suite, >> just as it is now, but cleaned up and streamlined for both developers and >> end-users in ways that are only dreamed of for OFBiz right now. > > The discussions so far have been around just replacing the OFBiz framework > with Moqui. There is a separate discussion going on about reorganizing higher > level artifacts differently. > > I was thinking we could create a thunk component to ease the transition to > Moqui. The thunk component would map existing Java packages to the Moqui API, > and then we can make changes to client code as time allows.
My first thought in this is it would be messy. :) Moqui objects have a lifecycle with init/destroy methods, especially the ExecutionContext which is created for each general operation such as processing an HTTP request (for web page, web service call, whatever) or running a background service job. There is a static method to get the main ExecutionContextFactory, but then you can only ever have one of those (usually not a big deal), and from there get the current ExecutionContext or create one. When you're done with the ExecutionContext it needs to be destroyed though. The Moqui features that aren't in the OFBiz framework anywhere could be accessed directly, so that shouldn't be an issue. There could be issues in the other direction, parts of the OFBiz framework that are left out of Moqui in favor of other tools (these could be wrapped as well... though unwrapping them is much cleaner... I guess there are already a dozen or more classes in the OFBiz framework that are just thin veneers around other tools!) or that just don't exist because they didn't seem useful and no need for them has come up. Anyway, it a good thought, might be interesting to try... -David
