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
>
>
>




Reply via email to