http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167869.html
Lei concurrent work argument may be something in favor or #2. But IMHO and
> I agree with Andrew Sykes about the current setup: I think it's also
> very important to keep the default setup (with OFBiz that controls the
> container).
>
> Jacopo
>
>
>
> Andrew Sykes wrote:
> > 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>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev