http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167874.html
Make sure you read this and give your feedback. This is very important,
the end I'll defer to you and David's opinion. My "wishlist" is that we
1. Allow OFBiz to be deployed inside any major J2EE app server more
2. Allow multiple instances of OFBiz to be deployed inside one app
server.
3. Allow dynamic reloading of .jars during runtime, so the server could
not great. #2 or #3 would sound fine to me. Unfortunately I'm not
experienced enough to know which would suit my three wishes better.
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>
>
>