http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167868.html
> Andy,
>
> Firstly, I think I should qualify by saying that the current setup does
> us just fine, so this is a very theoretical response. Although I
> understand the motivation.
>
> #1 Sounds like it would mean learning a lot of new stuff, so for
> financial reasons I'm not keen, also like you say, "standards change".
>
> #2 This sounds a bit like the bad old days (OFBiz 2.0) when running the
> server involved copying loads of jars from one place to another. This
> made starting up a more HD intensive operation than it needed to be, not
> to mention the fact that you ended up with 2 copies of the same jar
> (this caused a few head-scratching sessions on my part!).
>
> #3 Sounds like quite a progressive proposal, the JMX integration would
> presumably allow some enterprising type to create a bespoke OFBiz
> management console?
>
>
> On Wed, 2006-05-03 at 13:28 -0400, A. Zeneski wrote:
>> A few months ago, I spent a good two weeks trying to get OFBiz
>> working inside Geronimo; with the hopes to make it generic enough to
>> go with any application server. Due to the way ofbiz boots up, this
>> ended up being a huge task, which was impossible to implement the way
>> things are today.
>>
>> I would like to redesign this quickly so that we can take advantage
>> of using other containers.
>>
>> The first problem is the way our 'components' hold libraries. Using a
>> J2EE application server we lose the ability to dynamically load
>> libraries. As far as I know, there is no spec which defined how this
>> should be handled, so each application server does it differently.
>> Geronimo for example uses Maven and keeps all libraries in a 'Maven
>> Repository' which get loaded upon boot.
>>
>> If we decide we want to JUST support Geronimo, we can change this to
>> follow their pattern. Otherwise, by changing this we will have the
>> same problem in the future when trying to work with a different
>> application server.
>>
>> I think having OFBiz control the container is nice under certain
>> conditions. But it becomes a royal pain when it comes time to move to
>> something more robust.
>>
>> Currently I can think of a few options we have:
>>
>> 1) Redesign the organization of OFBiz to conform to J2EE standards.
>> This would be a lot of work, and since standards are changing all the
>> time will require quite a bit to maintain. Not my favorite option.
>>
>> 2) Develop an OFBiz deployment tool. This would be application server
>> specific and would end up re-packing and deploying OFBiz components
>> in a way which makes the application server happy.
>>
>> 3) Refactor the OFBiz startup code. Develop a very slim java runtime
>> wrapper. A highly configurable tool which will setup an environment
>> and then deploy a java application. This would replace the way an
>> application server boots. First it would configure the environment
>> based on a configuration, set up an initial class loader then boot
>> the application as if it was called from the command line. This would
>> only work with application servers which are 100% pure java already
>> since it be almost impossible to do a generic JNI based tool.
>>
>> #3 is very much like creating a dynamic script to start any java
>> application; except it is written also in java. I will even consider
>> the idea of developing this outside of OFBiz under its own project to
>> make sure it remains generic and supported by a broader community.
>>
>> An initial prototype of this would only take a couple of days to
>> develop. As I expect to base it on what is in base/start today. It
>> will be slimmer and more configurable. I have thought about making it
>> JMX based, but maybe that would add too much overhead. It would
>> however allow it to be managed by standard JMX tools.
>>
>> If it was JMX based it would run off of MX4j (an Apache licensed
>> project). It would first create a very private class loader to start
>> the JMX server and then run a few beans. The primary bean would be
>> the environment setup and application loader. It would create a new
>> class loader so that the JMX instance running would not conflict with
>> any JMX servers running from the application. This would however add
>> more overhead which I am not sure is worth it for what we get in return.
>>
>> #2 and #3 would both include a JSR 88 standard J2EE application
>> deployment tool. This would be used to mount the web applications to
>> the application server. I have this partially written already from
>> when I was toying with Geronimo.
>>
>> Before I commit to begin working on any options, I wanted to get
>> feedback from people to see what they think the better solution is.
>> My vote currently is for #3. I am open to other suggestions. So,
>> let's get the ball rolling. Please feel free to comment, ask
>> questions, etc.
>>
>> Andy
>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev