Ludovic,
By reusing the File object, it shouldn't matter if the template is in
velocity or xml. For the backend, we could always use something similar to the
broker object with a new item in lokahi.properties that says
'template.engine=velocity / xml / other'. The downside is that this would mean
that all templates must all be in the same format, but this will probably be
the case for users anyway.
An OSGi architecture would likely be the only clean way to add new engines at
runtime, but do you think there will be a need for this? I'm thinking that once
the user has decided upon a template format, they will keep it.
-Jeff
-----Original Message-----
From: Ludovic Maitre [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 2:42 AM
To: [email protected]
Subject: Re: Templating configuration files
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)
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
