Yes I see your point, using registrey editor I guess. I was speaking about the C:\WINNT\SYSTEM32\CONFIG\system on win2000, you don't have any access to this file in normal mode. Anyway forget it ;o)
Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > 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 > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > > > > > >
