sorry to hijack the thread. you can so a period export of the registry, by the way there are two one for the system and one for the user. The exported registry is text and can be re-imported without security concerns. great when changing machines and want to not install all the stuff again.
Jacques Le Roux sent the following on 12/15/2007 10:23 AM: > I was just thinking at webmin as an example, like Windows registry is another > bad one. It's bad because if the file (yes it's all in > one file !!!) is corrupted you just have to pray that its backup is not (and > be able to understand what it takes to recreate it). > Else you can reinstall Windows. I was always able to use the backup, but it's > really frightening. Actually Windows is something > behind game consoles and real systems :o) > > Jacques > > > De : "Chris Howe" <[EMAIL PROTECTED]> >> Almost nine months ago: >> http://www.nabble.com/Xindice-td9662303.html#a9662303 ;-) >> My major issue reason for abandoning looking into webmin as a solution was >> that you need to know additional scripting languages to > accomplish it. This is a barrier to entry for me, but more importantly, it > would be a barrier of entry to someone wanting to > customize the configurator in OFbiz. >> ----- Original Message ---- >> From: Jacques Le Roux <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org; Jacques Le Roux <[EMAIL PROTECTED]> >> Sent: Saturday, December 15, 2007 8:30:16 AM >> Subject: Re: OfBiz System Configuration Wizard >> >> >> Mmmm... : >> >> http://www.nabble.com/What-does--22OOTB-front-end-accessibility-22-mean-to-you--to8138284.html#a8155140 >> >> Almost one year ago... >> >> Jacques >> >> De : "Jacques Le Roux" <[EMAIL PROTECTED]> >>> Sorry for misinterpretation David. Actually I was thinking about >> Chris's idea and at this time it was not even clear in my mind >> that >>> we spoke only about system parameters as Adrian repeated. >>> >>> For me it's clear that business level parameters should all be/stay >> in DB and should only be accessed through the UI of their (and >>> only their) respective components (to keep components independent). >> There should be as less as possible exceptions to this rule. I >>> have already expressed my opininon about that in the past (I did not >> then understand that there was not only accouting periods set >>> in Webtools/Custom time periods) >>> >>> I like the idea to have an UI to set system parameters. I was >> thinking about something like Webmin http://www.webmin.com/. Of >> course >>> this parameters could stay in properties files. >>> But if I can try an analogy we are currently using some sort of >> Windows 3.1 ini files (webmin too). Remember(?), Windows 95 has >>> introduced the concept of registry to replace those cluttered files. >>> This is what I think Chris is really talking about, a centralised >> place where all parameters are "easily" accessible and safe. For >>> the framework it's not a problem to centralise since it is monolithic >> (you need every pieces to make it works) >>> Both these approach have pro and cons (properties files are easy to >> manipulate, but as Chris insisted you can't ensure >> consistency). >>> Having an UI to, for instance, set ports concurently sounds like >> promising, isn'it ? >>> We have already enough things to think about (most of the time I >> forget the url.properties file, ok it's not a big deal as I know >> it >>> exists, and in such a case a newbie should read the setup doc) >>> >>> Maybe it's sledge hammer to kill a fly, tough ? Is anybody really >> ready to do the work ? Chris ? >>> Jacques >>> >>> >>> De : "Chris Howe" <[EMAIL PROTECTED]> >>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >> > > > >
