http://ofbiz.116.s1.nabble.com/Dev-OFBiz-Boot-Refactor-tp167866p167878.html
Agreed. Although at the moment we are comfortable with things as they are it seems likely that we
will need to change app servers as we get more traffic so this is something we'd have to deal with
It does have to be said that I always prefer going with existing standards so the option one would
be the ideal for me I think (although that said there is no way I could actually contribute
towards this (beyond testing) as it's way out of my league technically). With that caveat the
solution as described sounds ideal. What sort of projects would a separate project attract?
Would this be sufficiently attractive to develop a larger community around this or are other
Besides App servers is this likely to throw up problems with any of the other external components?
> I second Si's #1 and #3. #1 could increase the popularity of OFBiz
> drastically.
>
> Vinay Agarwal
>
>
> -----Original Message-----
> From:
[hidden email] [mailto:
[hidden email]] On
> Behalf Of Si Chen
> Sent: Wednesday, May 03, 2006 10:41 AM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - OFBiz Boot Refactor -- EVERYBODY READ THIS!!!
>
>
> Hi everybody -
>
>
> Make sure you read this and give your feedback. This is very important,
> so I added that comment to the header..
>
> Andy,
>
>
> Sorry to say that this is outside of my realm of expertise per se, so in
> the end I'll defer to you and David's opinion. My "wishlist" is that we achieve the following
> goals, in order of decreasing importance:
>
> 1. Allow OFBiz to be deployed inside any major J2EE app server more
> easily, including Geronimo, JBoss, WebLogic, Websphere.
>
> 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
> be kept running in place even as bugs are fixed or code is updated.
>
> Looking at your list of options, I agree #1 of re-architecting OFBiz is
> 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. Would #3 be able to fulfill all of the three wishes
> above?
>
> If you do go with #3, I think another project under the Apache aegis to
> draw in greater support for it would be a good idea.
>
> Let me know if there's anything else we here could do to help with this.
>
>
> Si
>
>
> 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>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev>
>
coffee. Discounts are available for regular orders. Contact us for more