http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167867.html
us just fine, so this is a very theoretical response. Although I
server involved copying loads of jars from one place to another. This
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