Hi,
Great to hear again about this subject. I totally agree that the change
i suggest in issue 4 doesn't solve the problem of the configurations
templatization and templating, but it allow to test several
implementations of the template engine (the calss which produce the
final configuration files). A velocity template system could be fine,
but i'm inclined to use a xml based templating system so i would like we
have a way to plug our own custom template engines, and to develop them
in parallel. I guess we need to be able to load/use various templates at
runtime but that there is no need to load new template engines (legacy,
velocity, xml...). (if it was the case an OSGi underlying architecture
would be my preferred way to achieve it).
Steve Toback a écrit :
The offending method
org.apache.lokahi.httpd.api.worker.ApacheWorkerModel.buildConf(ApacheWorker
aw) (for httpd conf) certainly makes a few assumptions that may not be
true.
>From a Lokahi perspective, the workers.properties should be optional...
On Jan 29, 2008 2:27 PM, Feist, Jeffrey <[EMAIL PROTECTED]> wrote:
Hello. I am looking to making Lokahi's configuration files templated
instead of the current hard coding approach. The goal would be to allow
any of the configuration files (server.xml, httpsd.conf, etc.) to be
created from a template that is defined by a user. This would allow
updates of the templates without requiring updated coding and restarts.
More info can be found here:
https://issues.apache.org/jira/browse/LOKAHI-4
I like Ludovic's approach using a factory, however it looks like it
would still require a restart to load the additional template
implementations into memory. Please correct me if I am wrong.
It's a great start, however it doesn't allow more than one class to
act as a vehicle for building the file at any given point, which makes
the tool expandable, but not to have a built in template.
Another approach to consider is using velocity templates. Here we can
have a variable in the template be populated with a value entered by the
user. Example: In the apache conf file, $serverRoot would be filled in
with the apache.getServerRoot(); Using this approach, additional
templates can be added at run time by users and can be updated if
needed.
Actually there's even less than that needed if we were to use a
velocity template even perhaps stored as a file object in the
database, $serverRoot is always defined as
$apacheworker.getApache().getServerRoot(), I'm guessing we'd need to
allow access to the apache worker, and maybe a collection or two to
put stuff in and get it from. Although assuming we go down the
velocity route we can look at adding in a 'toolbox' for the apache
config or the tomcat config.
Virtualhost blocks (including the default virtualhost) would also need
the ability to be templated. I'm not sure the best way to have a user
select which template they would want to use for their virtualhost. A
single apache conf file may be using several different virtualhost
templates at a time so my guess is that the template would need to be
selected when the virtualhost is created.
Default vhost is created as part of the ApacheWorkerModel.buildConf()
method, so assuming we're completely replacing that, the default vhost
if desired, could be assumed to be included in the template.
What different virtualhost templates did you have in mind? I don't
see a use case where Virtualhost.buildVhostEntry() and
Virtualhost.buildFullEntry() couldn't be replaced by something in the
singular attached to an Apache Server template, assuming they should
be as there's mod_jk stuff in there that really shouldn't be...
Another thought would be trying to find a solution where more than one
file can be generated from the template. For example create the
workers.properties and the httpd configuration file from the same
template. Or the main part of the apache configuration file and each
virtualhost in separate files.
Here's thing - we do this right and it makes it real easy to add
support for other App servers. It might even make the ApacheWorker
and TomcatWorker classes obsolete, if we can reconcile the differences
easily.
Steve
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
