OfBiz System Configuration Wizard

[David E Jones]

On Dec 14, 2007, at 9:42 PM, Adrian Crum wrote:

> Thank you for the clarification!

Glad it helped... though I'm still left wondering why you're trying so  
hard to argue with every point I make... is my thinking fundamentally  
flawed somewhere? The idea of "making things easier for the user" is  
one I totally agree with, but I don't see how this does that, ie  
looking at the details seems to make the whole thing fall apart...

> I understand your point of view, but the idea that a user could muck  
> up existing data is true for all of OFBiz. How many emails do we see  
> about product catalog configuration problems? In addition, a user  
> could delete admin permissions using the Party Manager component and  
> end up locking themselves out of the system. The scenario you  
> described could be applied equally to many areas of OFBiz.

Logical fallacy: false analogy.

These are different knowledge domains. One way or another a user must  
understand the domain they work with. If someone does understand the  
technical domain they shouldn't have a problem following the  
instructions in the technical production setup guide. On the other  
hand if someone does not understand, and shouldn't be expected to  
understand, the system level settings they might still trying to play  
with things there and would complain of lack of documentation for  
things like JDBC URI strings that I don't think we want to get into  
documenting for end-users. We certainly could, but do we really want  
to make that a priority?

> The system level settings could operate just like any other seed  
> data. It gets loaded during ant run-install and from that point on  
> it is managed from the UI.

Oh yeah, how? Nearly ALL of the system level settings are used before  
it can even talk to the database... including the cache, debug,  
database connection, entity AND service engine settings, etc. One of  
the few exceptions is the app server (HTTP, etc) setup, but those are  
still needed for startup and don't really do anything without  
restarting some or all of OFBiz, and for those and other reasons I  
just don't see how the settings being in the database actually HELP us.

> Maybe we could identify particular areas as "do not touch" and make  
> it clear in the UI that a user shouldn't change those settings.  
> That's one of the advantages I see in the UI configuration wizard  
> (or screen) - instead of a simplistic "key=value" setting in a  
> property file, the UI could explain the setting and the pros and  
> cons of changing it.
>
> If a consultant or systems integrator wanted to prevent a user from  
> altering consultant-supplied settings, then they could disable the  
> configuration screen.

I'm seeing more arguments for disabling it than for having it... I  
still haven't seen a target audience or end-user scenario that points  
to this being useful...

-David

> David E Jones <[hidden email]> wrote:It doesn't really have  
> anything to do with concurrency, my concerns is
> with redundancy and inconsistency. If we put configuration (system or
> business level) in the database, which is what this discussion was
> originally about, then the initial data will come from XML data files.
> If that data is changed in the database but not in the XML files then
> they are out of sync, and if anyone changes one without the other and
> the XML files are used for a new system or to update an existing
> system then strange things may happen (which generally needs to be
> done periodically since we are not omniscient are rarely create or
> deploy systems that don't change).
>
> Right now system level settings such as http, database, cache, debug,
> etc settings are in files and are read from those files; if any of
> these are changed through a UI then the changes are in memory only.
> Would we really want a setup wizard for these things? We certainly
> could, but what is the target audience and intended use process?
>
> Business level settings are done a little differently, and this is
> where the biggest inconsistency lies. Some of these are in properties
> files and others are in the database. In order to have different
> industry-specific or business type specific data sets these that can
> be loaded initially when setting up a system these really should be
> all in the database and configurable through UIs rather than sitting
> in properties files.
>
> I really think the more important things to allow users to configure
> are the business level things. The system level things might be nice,
> but most of those settings should stay the same for really small
> installations where they are using it OOTB. If we did make a config UI
> for system level settings in order to make it easier for non-technical
> users to change things they just might use it... and that could be
> bad! Most of the system level settings require an understanding that
> non-technical users wouldn't have, and we shouldn't make it easy for
> them to hork their entire system and require someone more technical to
> come in and try to figure out what they did, undo any damage (if
> possible!) and then tell them NOT to use the fancy UI we built  
> anyway...
>
> -David
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo!  
> Search.

[Jacopo Cappellato]

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


Adrian Crum wrote:

> David,
>
> Thank you for the clarification!
>
> I understand your point of view, but the idea that a user could muck up existing data is true for all of OFBiz. How many emails do we see about product catalog configuration problems? In addition, a user could delete admin permissions using the Party Manager component and end up locking themselves out of the system. The scenario you described could be applied equally to many areas of OFBiz.
>
> The system level settings could operate just like any other seed data. It gets loaded during ant run-install and from that point on it is managed from the UI.
>
> Maybe we could identify particular areas as "do not touch" and make it clear in the UI that a user shouldn't change those settings. That's one of the advantages I see in the UI configuration wizard (or screen) - instead of a simplistic "key=value" setting in a property file, the UI could explain the setting and the pros and cons of changing it.
>
> If a consultant or systems integrator wanted to prevent a user from altering consultant-supplied settings, then they could disable the configuration screen.
>
> -Adrian
>
> David E Jones <[hidden email]> wrote:It doesn't really have anything to do with concurrency, my concerns is  
> with redundancy and inconsistency. If we put configuration (system or  
> business level) in the database, which is what this discussion was  
> originally about, then the initial data will come from XML data files.  
> If that data is changed in the database but not in the XML files then  
> they are out of sync, and if anyone changes one without the other and  
> the XML files are used for a new system or to update an existing  
> system then strange things may happen (which generally needs to be  
> done periodically since we are not omniscient are rarely create or  
> deploy systems that don't change).
>
> Right now system level settings such as http, database, cache, debug,  
> etc settings are in files and are read from those files; if any of  
> these are changed through a UI then the changes are in memory only.  
> Would we really want a setup wizard for these things? We certainly  
> could, but what is the target audience and intended use process?
>
> Business level settings are done a little differently, and this is  
> where the biggest inconsistency lies. Some of these are in properties  
> files and others are in the database. In order to have different  
> industry-specific or business type specific data sets these that can  
> be loaded initially when setting up a system these really should be  
> all in the database and configurable through UIs rather than sitting  
> in properties files.
>
> I really think the more important things to allow users to configure  
> are the business level things. The system level things might be nice,  
> but most of those settings should stay the same for really small  
> installations where they are using it OOTB. If we did make a config UI  
> for system level settings in order to make it easier for non-technical  
> users to change things they just might use it... and that could be  
> bad! Most of the system level settings require an understanding that  
> non-technical users wouldn't have, and we shouldn't make it easy for  
> them to hork their entire system and require someone more technical to  
> come in and try to figure out what they did, undo any damage (if  
> possible!) and then tell them NOT to use the fancy UI we built anyway...
>
> -David
>
>
>
>        
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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

[David E Jones]

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 <[hidden email]>
> To: [hidden email]
> 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
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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
>
>
>

[David E Jones]

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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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
>>
>>
>>
>
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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
>>
>>
>>
>
>
>
>

[jonwimp]

Solves nothing in context of system-level settings. Hard to imagine more than 1 person designated
as the deployment manager at any one single time. Even if we are dealing with change sets that
contain more than a few change locations, it's just a simple matter of programming the UI to do
all that in a single step.

But the Xindice thing sounds great. Especially when dealing with huge config files that contain
enormous XML content.

I did mine with just a simple hack. No Xindice, nothing. Purpose: make it easier for me to deploy
hundreds of varied OFBiz instances per month.

Jonathon

David E Jones wrote:

>
> 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 <[hidden email]>
>> To: [hidden email]
>> 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
>>
>>
>>
>

[jonwimp]

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.

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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>

[Jacques Le Roux]

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" <[hidden email]>
> 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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >> To: [hidden email]
> >> 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
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
>

[Jacques Le Roux]

De : "Jonathon -- Improov" <[hidden email]>
> 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> >> To: [hidden email]
> >> 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 <[hidden email]>
> >>> To: [hidden email]
> >>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>

[Jacques Le Roux]

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" <[hidden email]>
>
> 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" <[hidden email]>
> > 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> > > To: [hidden email]
> > > 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 <[hidden email]>
> > >> To: [hidden email]
> > >> 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
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]; Jacques Le Roux <[hidden email]>
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" <[hidden email]>
>
> 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" <[hidden email]>
> > 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 <[hidden email]>
> > To: [hidden email]
> > 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 <[hidden email]>
> > > To: [hidden email]
> > > 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 <[hidden email]>
> > >> To: [hidden email]
> > >> 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
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>

[cjhowe]

No doubt it is.  All tools that are used to configure an application are.  RTFM is a much simpler response to accomplish the same thing. ;-)  The point isn't necessarily making a tool that makes life easier on the 20 or so people that post to the dev list regularly, but to lower the barrier of entry into OFBiz for the 30 or so people that only post one or two messages on the user list that we never hear from again.  If Xindice is decided as the way to go, commit OFBIZ-851 into specialpurpose and I can toss a couple examples at it over the next few days for anyone wanting to help out and then I'd be able to contribute more time to it after the first of the year.

Jacques wrote:---------------------------------
Maybe it's sledge hammer to kill a fly, tough ? Is anybody really ready
 to do the work ? Chris ?

Jacques

[Jacques Le Roux]

OK Chris,

I will have a look

Jacques

De : "Chris Howe" <[hidden email]>
> No doubt it is.  All tools that are used to configure an application are.  RTFM is a much simpler response to accomplish the same
thing. ;-)  The point isn't necessarily making a tool that makes life easier on the 20 or so people that post to the dev list
regularly, but to lower the barrier of entry into OFBiz for the 30 or so people that only post one or two messages on the user list
that we never hear from again.  If Xindice is decided as the way to go, commit OFBIZ-851 into specialpurpose and I can toss a couple
examples at it over the next few days for anyone wanting to help out and then I'd be able to contribute more time to it after the
first of the year.
>
> Jacques wrote:---------------------------------
> Maybe it's sledge hammer to kill a fly, tough ? Is anybody really ready
>  to do the work ? Chris ?
>
> Jacques

[Jacques Le Roux]

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" <[hidden email]>
> 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 <[hidden email]>
> To: [hidden email]; Jacques Le Roux <[hidden email]>
> 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" <[hidden email]>
> >
> > 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" <[hidden email]>
> > > 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 <[hidden email]>
> > > To: [hidden email]
> > > 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 <[hidden email]>
> > > > To: [hidden email]
> > > > 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 <[hidden email]>
> > > >> To: [hidden email]
> > > >> 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
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>
>

[BJ Freeman]

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" <[hidden email]>
>> 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 <[hidden email]>
>> To: [hidden email]; Jacques Le Roux <[hidden email]>
>> 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" <[hidden email]>
>>> 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" <[hidden email]>
>>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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" <[hidden email]>
> >> 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 <[hidden email]>
> >> To: [hidden email]; Jacques Le Roux <[hidden email]>
> >> 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" <[hidden email]>
> >>> 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" <[hidden email]>
> >>>> 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 <[hidden email]>
> >>>> To: [hidden email]
> >>>> 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 <[hidden email]>
> >>>>> To: [hidden email]
> >>>>> 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 <[hidden email]>
> >>>>>> To: [hidden email]
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >
> >
> >
> >
>

[Adrian Crum]

David E Jones wrote:

> On Dec 14, 2007, at 9:42 PM, Adrian Crum wrote:
>
>> Thank you for the clarification!
>
>
> Glad it helped... though I'm still left wondering why you're trying so  
> hard to argue with every point I make... is my thinking fundamentally  
> flawed somewhere? The idea of "making things easier for the user" is  
> one I totally agree with, but I don't see how this does that, ie  
> looking at the details seems to make the whole thing fall apart...

I'm not really trying to argue with every point you make. As you can tell from the response to this
thread (and previous threads on the same subject), there is a desire in the developer community to
implement some type of UI for system configuration. Other developers have responded with suggestions
on how to make it work. You have expressed your doubts. I'm trying to find a way to address your
concerns while still considering the possibility of having a system configuration UI.

Please don't take my efforts to effect a compromise as some kind of attack on your comments. I'm
agreeing with your concerns, but at the same time I'm trying to come up with ideas for making this work.

>> The system level settings could operate just like any other seed  
>> data. It gets loaded during ant run-install and from that point on  it
>> is managed from the UI.
>
>
> Oh yeah, how? Nearly ALL of the system level settings are used before  
> it can even talk to the database... including the cache, debug,  
> database connection, entity AND service engine settings, etc. One of  
> the few exceptions is the app server (HTTP, etc) setup, but those are  
> still needed for startup and don't really do anything without  
> restarting some or all of OFBiz, and for those and other reasons I  just
> don't see how the settings being in the database actually HELP us.

You're right - I hadn't thought of that! Then the settings should remain in properties files.

>> Maybe we could identify particular areas as "do not touch" and make  
>> it clear in the UI that a user shouldn't change those settings.  
>> That's one of the advantages I see in the UI configuration wizard  (or
>> screen) - instead of a simplistic "key=value" setting in a  property
>> file, the UI could explain the setting and the pros and  cons of
>> changing it.
>>
>> If a consultant or systems integrator wanted to prevent a user from  
>> altering consultant-supplied settings, then they could disable the  
>> configuration screen.
>
>
> I'm seeing more arguments for disabling it than for having it... I  
> still haven't seen a target audience or end-user scenario that points  
> to this being useful...

There have been scenarios presented already. It seems you have overlooked them.

-Adrian