Re: Dev - OFBiz Boot Refactor

Posted by Si Chen-2 on May 05, 2006; 1:26am
URL: http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167873.html

Andy,

I'm starting to think that #2, creating an OFBiz into another app server by script, might be better, if only so that then OFBiz can play with all the other Java stuff that's deployed into that server.  Is it just a matter of developing and periodically updating a separate script for each major appserver?  Do the files in the appservers/ directory at least give us a starting point?

If anybody knows a lot about this or that app server, please chime in and help! 

Si

Lei Gao wrote:

Hi Andy,

Why #2 dose not work?

I think it might involve less work of #3. We just need to pacakge OFBiz into one  or multiple EAR files and programmatically change the configuration of target server. This might be a several steps task, and for particular servers, there will be some kind dirty works to be done, but I guess it still will involve less work than we need to do for #3, as we need implement JSR88  for both of them anyway.

Another thing is the development pattern, with #3, I think only one person can work on it for different servers, but with #2, like developing drivers, different person can work on different driver code for different servers.

This tool can be either a GUI based tool, or a command line based tool. I personally like a GUI based tool, when a new server support is out, we just plug it in.

I am not sure if I understand this problem really well at this moment though.

Lei

On 5/3/06, A. Zeneski <[hidden email]> 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

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev