Dev - OFBiz Boot Refactor
Locked
 
|
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 |
|
|
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 |
Re: Dev - OFBiz Boot Refactor -- EVERYBODY READ THIS!!!
|
|
Si's #3 has been on my wishlist since I first got involved with OFBiz.
Si Chen wrote: > 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 |
Re: Dev - OFBiz Boot Refactor -- EVERYBODY READ THIS!!!
|
|
In reply to this post by Si Chen-2
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 |
Re: Dev - OFBiz Boot Refactor -- EVERYBODY READ THIS!!!
|
|
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 in due course. 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 projects somehow keeping up with the evolving J2EE standards? Besides App servers is this likely to throw up problems with any of the other external components? Best wishes Ian On Wed, May 3, 2006 18:58, Vinay Agarwal wrote: > 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 > > -- Ian Gilbert www.ethicalshopper.net Fair trade: the alternative choice for your everyday shopping 0845 456 2429 WHAT DO YOU DRINK AT WORK? We can supply your organisation with high quality fair trade tea and coffee. Discounts are available for regular orders. Contact us for more details. _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - OFBiz Boot Refactor
|
|
In reply to this post by Andrew Zeneski
I'd like to comment on option #3...
Are you considering an inversion of control container like Spring for this task? Then the spring config could then be tweaked to either wire the container supplied resources such as (JMX, JDBC, JMS, JTA) - or instance and load supplied services/servers for such functionality. Essentially it would involve boiling a lot of stuff down to common interfaces - but as most of the major APIs in the Java world are centered around interfaces... and a lot of the OfBiz framework is interface oriented... this would seem to be an ideal mechanism to boot strap the OfBiz framework into an application server. The question(s) that then arise are: Is the goal to be able to have multiple deployments of OfBiz per app server? If so - is it necessary for each deployment to have a "full copy" of all OfBiz code? Or, is it better to factor out the "shared" portions of OfBiz so that they can live as "singletons" or shared resources to multiple deployed OfBiz applications? One possible outcome is a process that pulls the framework out - so that it can be injected into a container. Thus something like the entity engine (or engines) would be loaded and configured by the container - becoming a "named" resource. And then individual OfBiz applications could be started inside the container and get a handle to the appropriate framework components by requesting them from the container. So then you almost have a two part deployment. 1> Deploy the framework. a> Activates an application server/container with the OfBiz framework b> Ideally only one version of the framework active at a time? c> Core components configured using JNDI as provided by container. 2> Deploy OfBiz aware application. a> Configure using JNDI. b> Requests known service providers from container. c> Requires an "OfBiz Activated Application Server" This probably just creates more questions, and only really underscores my lack of understanding on how we all might like to use OfBiz with respects to a J2EE container, etc. - Porter Woodward A. Zeneski wrote: > 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 |
pwoodward.vcf (301 bytes)
Re: Dev - OFBiz Boot Refactor -- EVERYBODY READ THIS!!!
|
|
In reply to this post by Si Chen-2
#2 on my list would prevent this from ever being possible. The deployment tool would deploy the compiled libraries into the application server's specific locations. If the app server supports auto updates this may work, however it would still require a re-deployment. No more edit an ftp and test (well that may not be true, since webapps would be deployed differently). So, after typing all this, maybe it would still be possible assuming the app server supports this as part of their "library repository'.Â
On May 3, 2006, at 1:41 PM, Si Chen wrote:
_______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
In reply to this post by Andrew Zeneski
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 Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - OFBiz Boot Refactor
|
|
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 |
|
|
In reply to this post by Andrew Zeneski
I agree: if we go with the app server then it'd be a matter of whether they support it or not. Si A. Zeneski wrote: #2 on my list would prevent this from ever being possible. The deployment tool would deploy the compiled libraries into the application server's specific locations. If the app server supports auto updates this may work, however it would still require a re-deployment. No more edit an ftp and test (well that may not be true, since webapps would be deployed differently). So, after typing all this, maybe it would still be possible assuming the app server supports this as part of their "library repository'. _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
In reply to this post by Andrew Zeneski
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 _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
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, _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - OFBiz Boot Refactor
Administrator
|
In reply to this post by Jacopo Cappellato
It seems that #1 interests nobody except Ian.
Lei concurrent work argument may be something in favor or #2. But IMHO and without new information, Si's question and Andy's answer do not tend to favor this point (may depend upon server, so not general enough) Finally at this stage, mostly reading from Andrew experience on #1&2 and as far as I can understand, #3 has also my preference. Last but not least : I completly agree with Jacopo and Andrew about the current setup (Tomcat embeded). Jacques From: "Jacopo Cappellato" > 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 _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Jacques,
On #2, It's worth re-reading David's comments... "Some app servers, like Weblogic, do have proprietary extensions to add to the shared classpath inside an EAR. For others you can add to the global classpath to get that effect. To really annoying ones, like Geronimo 1.0 and Tomcat, you have to copy the jar files and other classpath resources into their directories... Say good-bye to in-place deployment ladies and gents and welcome to the hellish world of wondering why your changes don't seem to be doing anything..." This really can be VERY painful, especially in Windows where for some reason known only to the OS a lock would be maintained on a random jar file, so even though you think you've overwritten it, still nothing happens! OFBiz2.0 used ant tasks to copy the jars into Tomcat, it really was horrible! 2.1 embedded Mortbay's Jetty, and suddenly life was a whole lot easier! As well as that, it adds quite a bit of time onto the build script if it's shifting files around, which gets quite frustrating after 100 restarts!!! -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - OFBiz Boot Refactor
|
Administrator
|
Thanks for comments Andrew.
Jacques ----- Original Message ----- From: "Andrew Sykes" <[hidden email]> To: "OFBiz Project Development Discussion" <[hidden email]> Sent: Sunday, May 07, 2006 5:45 PM Subject: Re: [OFBiz] Dev - OFBiz Boot Refactor > Jacques, > > On #2, It's worth re-reading David's comments... > > "Some app servers, like Weblogic, do have proprietary extensions to add > to the shared classpath inside an EAR. For others you can add to the > global classpath to get that effect. To really annoying ones, like > Geronimo 1.0 and Tomcat, you have to copy the jar files and other > classpath resources into their directories... Say good-bye to in-place > deployment ladies and gents and welcome to the hellish world of > wondering why your changes don't seem to be doing anything..." > > This really can be VERY painful, especially in Windows where for some > reason known only to the OS a lock would be maintained on a random jar > file, so even though you think you've overwritten it, still nothing > happens! > > OFBiz2.0 used ant tasks to copy the jars into Tomcat, it really was > horrible! > > 2.1 embedded Mortbay's Jetty, and suddenly life was a whole lot easier! > > As well as that, it adds quite a bit of time onto the build script if > it's shifting files around, which gets quite frustrating after 100 > restarts!!! > -- > Kind Regards > Andrew Sykes <[hidden email]> > Sykes Development Ltd > http://www.sykesdevelopment.com > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |