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 <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:38:42 AM
Subject: Re: OfBiz System Configuration Wizard



Wow, I didn't even realize we were considering something to change ports on the fly. Has anyone even done a proof of concept to see if the various infrastructure pieces we're using even support that? I guess in theory they should, but you're getting into a LOT more than just reading and writing files or something... you may have to unload and reload different objects and everything that depends on them.... Beyond a proof of concept that would also have to be tested a lot because those tend to be error prone sorts of things, especially when the infrastructure was not originally written with that in mind.

-David


On Dec 14, 2007, at 10:58 PM, Chris Howe wrote:

To use the http port setting again. If you're using the UI to change the port and you only change one of the files, you likely will have to go back and change the file by hand after a restart because the UI won't be accessible. Whereas if it were changed in a
transactional manner it either fails and you're presented with the same UI or it passes and the new settings take effect properly.

Also in the case of conflicting changes. Beanshell, email, http, etc all need to be running on different ports. If you happen to have them running on a port that Ofbiz already has in use, you likely won't be able to get back to a UI to correct the mistake. In
a transactional manner, you're able to run a service to verify such things before committing it back to the file system.

----- Original Message ----
From: David E Jones <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Friday, December 14, 2007 11:35:33 PM
Subject: Re: OfBiz System Configuration Wizard



The transactional nature sounds wonderful, but what problem does it
actually solve?

-David


On Dec 14, 2007, at 10:32 PM, Chris Howe wrote:

d) Load the config files into an XML database (Apache Xindice)
manipulate with a UI/wizzard to your heart's content, verify the
structure against an xsd, flush it to the original filename.  The
benefit of using an xml database as opposed to just reading/writing
the original file is that you're able to make the changes in a
transaction manner.  For instance changing the http port, you can
change url.properties and ofbiz-containers simultaneously.

----- Original Message ----
From: Jacopo Cappellato <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Friday, December 14, 2007 11:08:01 PM
Subject: Re: OfBiz System Configuration Wizard


I think that system settings should stay in config files, not in the
database; if the goal is to simplify the configuration steps
described
in the production setup guide, then there are probably different
 ways
of
addressing this:

a) deliver a separate set of config files already configured for a
"standard" production (cache enabled, verbose logs disabled etc...);
we

may also consider to deliver these settings in the release branch,
and
maintain the dev settings in the trunk

b) implement an ant-based wizard (to be run during the installation
of
OFBiz) that prompts the user for some common settings (http port,
https

port, mail server address, db used, db user/password, db url etc...)
and
then modify the OFBiz's files (or, we could prapare *one* simple
 file
where the user can enter all these values, then run the ant script
that

places then in all the relevant OFBiz files)

c) clean up the existing config files; for example, the
entityengine,xml
contains the settings for a lot of different databases; we could
 keep
the settings for just one of them and move the others into a
 separate
file, or create one file per database etc...

Of course, for more complex (real World) setups, you'll have to
follow
the steps of the production setup guide... but for simpler ones it
could
work.

just my 2 cents

Jacopo












Reply via email to