De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > I'm missing something here. > > The UI-based configurator you're talking about, isn't it run *apart* from > OFBiz? Whether or not > OFBiz is up and running, we should still be able to bring up the > configurator, right? > > I think so. If not, it'll be like building a house with locks and keyholes on > the wrong side of > doors. We'll either be locked in or locked out. Just shooting ourselves in > the foot.
Yes I agree Jacques > Jonathon > > Chris Howe wrote: > > I'm not suggesting an actual change of ports while running, just changing > > the configuration files. There would be an ofbiz reset involved. Just when it comes back up, if it's not changed concurrently, it won't be accessible. > > > > ----- Original Message ---- > > From: David E Jones <[EMAIL PROTECTED]> > > To: dev@ofbiz.apache.org > > Sent: Saturday, December 15, 2007 12:38:42 AM > > Subject: Re: OfBiz System Configuration Wizard > > > > > > > > Wow, I didn't even realize we were considering something to change > > ports on the fly. Has anyone even done a proof of concept to see if > > the various infrastructure pieces we're using even support that? I > > guess in theory they should, but you're getting into a LOT more than > > just reading and writing files or something... you may have to unload > > and reload different objects and everything that depends on them.... > > Beyond a proof of concept that would also have to be tested a lot > > because those tend to be error prone sorts of things, especially when > > the infrastructure was not originally written with that in mind. > > > > -David > > > > > > On Dec 14, 2007, at 10:58 PM, Chris Howe wrote: > > > >> To use the http port setting again. If you're using the UI to > >> change the port and you only change one of the files, you likely > >> will have to go back and change the file by hand after a restart > >> because the UI won't be accessible. Whereas if it were changed in a > > > >> transactional manner it either fails and you're presented with the > >> same UI or it passes and the new settings take effect properly. > >> > >> Also in the case of conflicting changes. Beanshell, email, http, > >> etc all need to be running on different ports. If you happen to > >> have them running on a port that Ofbiz already has in use, you > >> likely won't be able to get back to a UI to correct the mistake. In > > > >> a transactional manner, you're able to run a service to verify such > >> things before committing it back to the file system. > >> > >> ----- Original Message ---- > >> From: David E Jones <[EMAIL PROTECTED]> > >> To: dev@ofbiz.apache.org > >> Sent: Friday, December 14, 2007 11:35:33 PM > >> Subject: Re: OfBiz System Configuration Wizard > >> > >> > >> > >> The transactional nature sounds wonderful, but what problem does it > >> actually solve? > >> > >> -David > >> > >> > >> On Dec 14, 2007, at 10:32 PM, Chris Howe wrote: > >> > >>> d) Load the config files into an XML database (Apache Xindice) > >>> manipulate with a UI/wizzard to your heart's content, verify the > >>> structure against an xsd, flush it to the original filename. The > >>> benefit of using an xml database as opposed to just reading/writing > >>> the original file is that you're able to make the changes in a > >>> transaction manner. For instance changing the http port, you can > >>> change url.properties and ofbiz-containers simultaneously. > >>> > >>> ----- Original Message ---- > >>> From: Jacopo Cappellato <[EMAIL PROTECTED]> > >>> To: dev@ofbiz.apache.org > >>> Sent: Friday, December 14, 2007 11:08:01 PM > >>> Subject: Re: OfBiz System Configuration Wizard > >>> > >>> > >>> I think that system settings should stay in config files, not in the > >>> database; if the goal is to simplify the configuration steps > >> described > >>> in the production setup guide, then there are probably different > > ways > >>> of > >>> addressing this: > >>> > >>> a) deliver a separate set of config files already configured for a > >>> "standard" production (cache enabled, verbose logs disabled etc...); > >>> we > >>> > >>> may also consider to deliver these settings in the release branch, > >> and > >>> maintain the dev settings in the trunk > >>> > >>> b) implement an ant-based wizard (to be run during the installation > >> of > >>> OFBiz) that prompts the user for some common settings (http port, > >>> https > >>> > >>> port, mail server address, db used, db user/password, db url etc...) > >>> and > >>> then modify the OFBiz's files (or, we could prapare *one* simple > > file > >>> where the user can enter all these values, then run the ant script > >>> that > >>> > >>> places then in all the relevant OFBiz files) > >>> > >>> c) clean up the existing config files; for example, the > >>> entityengine,xml > >>> contains the settings for a lot of different databases; we could > > keep > >>> the settings for just one of them and move the others into a > > separate > >>> file, or create one file per database etc... > >>> > >>> Of course, for more complex (real World) setups, you'll have to > >> follow > >>> the steps of the production setup guide... but for simpler ones it > >>> could > >>> work. > >>> > >>> just my 2 cents > >>> > >>> Jacopo > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > >
