You are viewing a plain text version of this content. The canonical link for it is here.
Posted to lokahi-dev@incubator.apache.org by "Feist, Jeffrey" <je...@merck.com> on 2008/01/29 19:27:36 UTC
Templating configuration files
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.
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.
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.
Are there any thoughts on the best way to implement templating?
-Jeff
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
>On Jan 30, 2008 11:17 AM, Feist, Jeffrey <je...@merck.com>
wrote:
>> I think we are talking about the same thing, but I want to clarify my
>> thoughts to make sure. I imagined a velocity template file stored in
the
>> database that has variables such as $serverRoot in it. These files
would
>> be created and updated within the GUI by a user (similar to the way
>> files are maintained now). When a new worker is created, the server,
>> apache and template(s) would be selected. When the worker's config
files
>> are deployed, it would build them from the template(s) selected and
>> deploy them.
>>
>> By 'toolbox' are you referring to a location in Location where all of
>> these templates are maintained? I was thinking within the
Administration
>> under something like 'Manage Templates'.
>
>Velocity has a 'toolbox' capability - ie the toollbox.xml under conf
>is the config for the velocity servlet.
>
>Would you even need to put these templates in visually different
>location in the gui?
No.
>
>The only reason we currently have the current File object is for
>apache head matter. Those pages and objects could just be reused,
>no?
Yes, we could reuse those objects but the pages would likely need a
rename. Simply switching 'File' to 'Template' is a minor task and can be
an afterthought.
>
>> I had in mind breaking this default virtualhost out of the apache
head
>> matter (everything above the virtualhosts). This way, we share the
same
>> configurations in the file while allow different default
virtualhosts.
>> Something like the user would choose a head matter for their apache
>> instance and then choose the default virtualhost to go with it. This
>> would need to be done at the worker level. It reduces the need to
>> maintain several of the same head matters when the only difference in
>> the default virtualhost. This would make it easy to make a change in
one
>> place and propagate the changes to all servers that use it.
>
>We have Pool -> worker -> server
>
>Why would you put the configuration for the 'head template' at the
>worker level, when we currently do it at the server level. Not that I
>am against it, but what's the pros of putting it there in your mind?
>
I would still want to keep the config for the head matter at the server
level, but would want to move the default virtualhost settings to the
worker level. Currently there is no place to define the directives in
the default virtualhost. If the default virtualhost was included in the
main template, a new template would be needed for every default
virtualhost that has different directives. Correct?
If so, there could be several templates with all of the same head matter
but different default virtualhosts. If something in the head matter
would need to be changed (a new module for example), it would need to be
changed in every one of these templates. If every worker was using the
same head matter with a different default vhost, the change would only
need to be made in one place.
>> >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...
>>
>> I figured different virtualhosts may have different rewrite rules or
>> location blocks. These vitrualhosts could vary even though they stay
in
>> the same conf file. When a virtualhost is created, this template
would
>> need to be selected. Do you have thoughts on how to handle different
>> virtualhost blocks within a single conf file?
>
>A virtualhost 'template' is currently in Lokahi defined as:
>
><Virtualhost <$IP>:80>
>$Vhostcontents
><ifmod mod_jk>
>$contexts
></ifmod>
></virtualhost>
>
>what are you intending to define that to?
>
I see that being one template. Instead of having the user type the same
location blocks and rewrite rules, they could provide their own
additional templates. (See bottom of email for example)
>
>> >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.
>>
>> That would be nice, but if this functionality were to be added, I
think
>> it would be good to allow the user to choose which templates to use
for
>> the full deployment. It sounds similar to a Hosting Pool where a
>> "hosting template" would be made up of one or more templates to
deploy.
>> Eg: "Server 1 Template" would deploy "worker.properties_1" and
>> "httpd.conf_3". (see below)
>>
>> >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.
>>
>> I like the idea of removing the ApacheWorker and TomcatWorker
classes.
>> The true only difference between the two is the file that is
deployed.
>> Perhaps replace them with a Worker class that has the functions build
>> and deploy configs. The contents of the file would be read from the
>> template.
>
>and graceful which apache has and tomcat does not - but that could be
>accounted for somehow.
True. Maybe as a first approach move the build and deploy method from
the workers to a generic template class and then work on the specific
actions (restart, graceful, configtest, etc.) later.
>
>> It's starting to sounds like some sort of template builder would be
>> beneficial to have. First start by building the template of a file
that
>> should be deployed and then add all of the files that should be
deployed
>> to the main template. I made a quick example of how I think it would
be
>> done below. 'Server 1 Template' would be deployed which would build
and
>> deploy the rest of the files it contains.
>>
>> Server 1 Template
>> - worker.properties_1
>> - httpd.conf_3
>> - head matter 2
>> - default virtualhost 1
>> - virtualhost a
>> - vhost template 1
>> - virtualhost b
>> - vhost template 5
>> - virtualhost c
>> - vhost template 1
>>
>
>What's the difference between template 1 and 5. I'm failing to see
>what benefit you'd gain from not having it all in one template file,
>or a reason to have more than one vhost template.
>
If there are some common directives that are always used, wouldn't it
make sense to have these stored? For example, this could be vhost
template 1 (aka 'default')
<Virtualhost <$IP>:80>
$Vhostcontents
<ifmod mod_jk>
$contexts
</ifmod>
</virtualhost>
Vhost template 2 could then be:
<Virtualhost <$IP>:80>
<location /test>
SetHandler test-handler
</location>
$Vhostcontents
<ifmod mod_jk>
$contexts
</ifmod>
</virtualhost>
This gives the user the ability to choose a vhost template that fits
their needs without having to write the additional information. I agree
that the 'standard' template would still work but it would require the
user to provide the same information for every vhost. Maybe this could
be a phase 2 task for templating?
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
Re: Templating configuration files
Posted by Steve Toback <to...@apache.org>.
On Jan 30, 2008 11:17 AM, Feist, Jeffrey <je...@merck.com> wrote:
> I think we are talking about the same thing, but I want to clarify my
> thoughts to make sure. I imagined a velocity template file stored in the
> database that has variables such as $serverRoot in it. These files would
> be created and updated within the GUI by a user (similar to the way
> files are maintained now). When a new worker is created, the server,
> apache and template(s) would be selected. When the worker's config files
> are deployed, it would build them from the template(s) selected and
> deploy them.
>
> By 'toolbox' are you referring to a location in Location where all of
> these templates are maintained? I was thinking within the Administration
> under something like 'Manage Templates'.
Velocity has a 'toolbox' capability - ie the toollbox.xml under conf
is the config for the velocity servlet.
Would you even need to put these templates in visually different
location in the gui?
The only reason we currently have the current File object is for
apache head matter. Those pages and objects could just be reused,
no?
> I had in mind breaking this default virtualhost out of the apache head
> matter (everything above the virtualhosts). This way, we share the same
> configurations in the file while allow different default virtualhosts.
> Something like the user would choose a head matter for their apache
> instance and then choose the default virtualhost to go with it. This
> would need to be done at the worker level. It reduces the need to
> maintain several of the same head matters when the only difference in
> the default virtualhost. This would make it easy to make a change in one
> place and propagate the changes to all servers that use it.
We have Pool -> worker -> server
Why would you put the configuration for the 'head template' at the
worker level, when we currently do it at the server level. Not that I
am against it, but what's the pros of putting it there in your mind?
> >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...
>
> I figured different virtualhosts may have different rewrite rules or
> location blocks. These vitrualhosts could vary even though they stay in
> the same conf file. When a virtualhost is created, this template would
> need to be selected. Do you have thoughts on how to handle different
> virtualhost blocks within a single conf file?
A virtualhost 'template' is currently in Lokahi defined as:
<Virtualhost <$IP>:80>
$Vhostcontents
<ifmod mod_jk>
$contexts
</ifmod>
</virtualhost>
what are you intending to define that to?
> >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.
>
> That would be nice, but if this functionality were to be added, I think
> it would be good to allow the user to choose which templates to use for
> the full deployment. It sounds similar to a Hosting Pool where a
> "hosting template" would be made up of one or more templates to deploy.
> Eg: "Server 1 Template" would deploy "worker.properties_1" and
> "httpd.conf_3". (see below)
>
> >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.
>
> I like the idea of removing the ApacheWorker and TomcatWorker classes.
> The true only difference between the two is the file that is deployed.
> Perhaps replace them with a Worker class that has the functions build
> and deploy configs. The contents of the file would be read from the
> template.
and graceful which apache has and tomcat does not - but that could be
accounted for somehow.
> It's starting to sounds like some sort of template builder would be
> beneficial to have. First start by building the template of a file that
> should be deployed and then add all of the files that should be deployed
> to the main template. I made a quick example of how I think it would be
> done below. 'Server 1 Template' would be deployed which would build and
> deploy the rest of the files it contains.
>
> Server 1 Template
> - worker.properties_1
> - httpd.conf_3
> - head matter 2
> - default virtualhost 1
> - virtualhost a
> - vhost template 1
> - virtualhost b
> - vhost template 5
> - virtualhost c
> - vhost template 1
>
What's the difference between template 1 and 5. I'm failing to see
what benefit you'd gain from not having it all in one template file,
or a reason to have more than one vhost template.
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
>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.
I think we are talking about the same thing, but I want to clarify my
thoughts to make sure. I imagined a velocity template file stored in the
database that has variables such as $serverRoot in it. These files would
be created and updated within the GUI by a user (similar to the way
files are maintained now). When a new worker is created, the server,
apache and template(s) would be selected. When the worker's config files
are deployed, it would build them from the template(s) selected and
deploy them.
By 'toolbox' are you referring to a location in Location where all of
these templates are maintained? I was thinking within the Administration
under something like 'Manage Templates'.
>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.
I had in mind breaking this default virtualhost out of the apache head
matter (everything above the virtualhosts). This way, we share the same
configurations in the file while allow different default virtualhosts.
Something like the user would choose a head matter for their apache
instance and then choose the default virtualhost to go with it. This
would need to be done at the worker level. It reduces the need to
maintain several of the same head matters when the only difference in
the default virtualhost. This would make it easy to make a change in one
place and propagate the changes to all servers that use it.
>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...
I figured different virtualhosts may have different rewrite rules or
location blocks. These vitrualhosts could vary even though they stay in
the same conf file. When a virtualhost is created, this template would
need to be selected. Do you have thoughts on how to handle different
virtualhost blocks within a single conf file?
>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.
That would be nice, but if this functionality were to be added, I think
it would be good to allow the user to choose which templates to use for
the full deployment. It sounds similar to a Hosting Pool where a
"hosting template" would be made up of one or more templates to deploy.
Eg: "Server 1 Template" would deploy "worker.properties_1" and
"httpd.conf_3". (see below)
>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.
I like the idea of removing the ApacheWorker and TomcatWorker classes.
The true only difference between the two is the file that is deployed.
Perhaps replace them with a Worker class that has the functions build
and deploy configs. The contents of the file would be read from the
template.
It's starting to sounds like some sort of template builder would be
beneficial to have. First start by building the template of a file that
should be deployed and then add all of the files that should be deployed
to the main template. I made a quick example of how I think it would be
done below. 'Server 1 Template' would be deployed which would build and
deploy the rest of the files it contains.
Server 1 Template
- worker.properties_1
- httpd.conf_3
- head matter 2
- default virtualhost 1
- virtualhost a
- vhost template 1
- virtualhost b
- vhost template 5
- virtualhost c
- vhost template 1
-Jeff
-----Original Message-----
From: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of Steve
Toback
Sent: Tuesday, January 29, 2008 8:15 PM
To: lokahi-dev@incubator.apache.org
Subject: Re: Templating configuration files
The offending method
org.apache.lokahi.httpd.api.worker.ApacheWorkerModel.buildConf(ApacheWor
ker
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 <je...@merck.com> 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
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
Glad to hear there is a lot of interest in templating. Below are what I
believe the changes that need to be made for the first pass. I will get
started on these changes and attach them to the Jira ticket when they
are complete. Please let me know if you have any comments or
suggestions.
GUI
----
Update "Manage Files" to say "Manage Templates"
For files/templates:
Name: display name
Path: path to this file on the server (is this needed anymore?)
Descriptor: name of file (httpd.conf / httpsd.conf /
workers.properties)
*Put examples next to field names*
Update Apache:
- Update "Apache Main" to say "Apache Template"
- Add workers.properties template (with none as a choice)
Update Tomcat:
- Add Server.xml Template drop down
Backend
-----------
add "lokahi.template.engine=X" in lokahi.properties
Create a new class called something like ConfTemplateBuilder
Workers will call: public String ConfTemplateBuilder.buildConf(Server
worker) {
- calls PropertiesFile.getConstantValue("templateEngine") ->
returns org.apache.lokahi....VelocityTemplateEngine
- calls VelocityTemplateEngine.buildConf(Server) {}
The engine classes would be:
Public abstract class TemplateEngine()
VelocityTemplateEngine extends TemplateEngine( )
String VelocityTemplateEngine.buildConf(Server worker) {}
- would have the mapping from $apacheServer -> (ApacheWorker)
Server.getApache().getServerRoot();
- if Server instanceof ApacheWorker {}
- else if Server instanceof TomcatWorker {}
When other Engines would be added, they would need to extend class
TemplateEngine() and have a buildConf function that returns a string
representation of the config file.
-Jeff
-----Original Message-----
From: Steve Lihn [mailto:stevelihn@gmail.com]
Sent: Wednesday, February 06, 2008 9:57 AM
To: lokahi-dev@incubator.apache.org
Subject: Re: Templating configuration files
Severn,
I am also interested in Lokahi supporting JBOSS/Apache environment.
Maybe there could be a /common/ J2EE module added to Lokahi.
What is your requirement to manage Geronimo?
What I am looking for in JBOSS is simple: To start/stop a JBOSS server
(JVM). Of course, this is in addition to all the nice features of
managing Apache config, JVM config, and mod_jk.
If there is momentum in this direction, more features can be added,
such as managing JBOSS config files, getting into the JMX console
business, etc.
Steve
On 2/5/08, STsui@symcor.com <ST...@symcor.com> wrote:
> We\'re planning on using Lokahi to manage our application hosting
> infrastructure, however we\'re primarily a Geronimo/Apache shop
instead of
> Tomcat, so we have an interest in some sort of more generic
configuration
> templating.
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
The src/www/Core/Template/* files were created as part of the template
work. Src/www/Core/File/* was moved into this location.
-Jeff
-----Original Message-----
From: STsui@symcor.com [mailto:STsui@symcor.com]
Sent: Tuesday, February 19, 2008 2:01 PM
To: lokahi-dev@incubator.apache.org
Subject: RE: Templating configuration files
Looking at the patch, I'm not sure which version of Lokahi
vms-pactch.txt
is against. I've checked current svn, rev 619464, and M01 and all of
them
seem to be missing the src/www/Core/Template/* files the patch is
supposed
to be patching.
Can you diff it against svn?
-Severn
"Toback, Steve" <st...@merck.com>
02/12/2008 11:43 AM
Please respond to
lokahi-dev@incubator.apache.org
To
lokahi-dev@incubator.apache.org
cc
Subject
RE: Templating configuration files
Without looking at the patch - we should probably start a page on the
wiki for this documentation :)
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Tuesday, February 12, 2008 11:36 AM
>To: lokahi-dev@incubator.apache.org
>Subject: RE: Templating configuration files
>
>I just committed the patches for the templating engine.
>Currently, it included a VelocityTemplatingEngine but I
>included instructions on how to add your own on the Jira issue
>page: https://issues.apache.org/jira/browse/LOKAHI-4. This
>page also includes all of the changes that were made for the
>templating engine code.
>
>-Jeff
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Monday, February 11, 2008 5:09 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>With the templating code being updated, I figured it would
>also be beneficial to include a generic config template
>deployer. This simply takes a worker, builds the config files
>based on its templates and deploys them to the location on the
>server provided when it is created.
>
>This should also reduce some of the dependencies on Apache and Tomcat.
>
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Friday, February 08, 2008 4:26 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>I have started working on this and found something else that
>looked to be beneficial. Instead of Apache and Tomcat only
>being allowed to have one file, I updated them to have a
>Collection of Templates. This allows any Application
>(currently only Apache and Tomcat) to have any number of
>configuration files. This lets the user choose a template for
>their worker.properties file along with the apache main file.
>This required 2 database tables be updated but I will be
>including a patch to update existing tables.
>
>-Jeff
>
>>-----Original Message-----
>>From: Feist, Jeffrey
>>Sent: Thursday, February 07, 2008 9:38 AM
>>To: 'lokahi-dev@incubator.apache.org'
>>Subject: RE: Templating configuration files
>>
>>Glad to hear there is a lot of interest in templating. Below
>are what I believe the changes that need to be made for the
>first pass. I will get started on these changes and attach
>them to the Jira ticket when they are complete. Please let me
>know if you have any comments or suggestions.
>>
>>GUI
>>----
>>Update "Manage Files" to say "Manage Templates"
>>
>>For files/templates:
>> Name: display name
>> Path: path to this file on the server (is this needed
anymore?)
>> Descriptor: name of file (httpd.conf / httpsd.conf /
>workers.properties)
>>*Put examples next to field names*
>>
>>Update Apache:
>> - Update "Apache Main" to say "Apache Template"
>> - Add workers.properties template (with none as a
choice)
>>
>>Update Tomcat:
>> - Add Server.xml Template drop down
>>
>>Backend
>>-----------
>>add "lokahi.template.engine=X" in lokahi.properties
>>
>>Create a new class called something like ConfTemplateBuilder
>>
>>Workers will call: public String
>ConfTemplateBuilder.buildConf(Server worker) {
>> - calls
>PropertiesFile.getConstantValue("templateEngine") -> returns
>org.apache.lokahi....VelocityTemplateEngine
>> - calls VelocityTemplateEngine.buildConf(Server) {}
>>
>>The engine classes would be:
>>Public abstract class TemplateEngine()
>>VelocityTemplateEngine extends TemplateEngine( )
>>
>>String VelocityTemplateEngine.buildConf(Server worker) {}
>> - would have the mapping from $apacheServer ->
>(ApacheWorker) Server.getApache().getServerRoot();
>> - if Server instanceof ApacheWorker {}
>> - else if Server instanceof TomcatWorker {}
>>
>>
>>
>>When other Engines would be added, they would need to extend
>class TemplateEngine() and have a buildConf function that
>returns a string representation of the config file.
>>
>>-Jeff
>
>
>
------------------------------------------------------------------------
------
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.
------------------------------------------------------------------------
------
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
I just uploaded another patch to the Jira issue. Below is the list that
the patch addresses.
Added patch (templateEngine.patch) for the following issues /
enhancements:
- Updated HostingPoolModel to use the new TemplateDeployer
- Added logging code to VelocityTemplateEngine. By default, velocity
will use its own logger and write to the current working directory. The
updated code used the currently running lokahi log4j logger.
- Added MathTool to the VelocityTemplateEngine
- Added a buildString() method to the Templating engines so we can now
process individual strings with the engine. This comes in handy if you
would want to template the location of a deployed file. Eg:
/etc/$worker.getPath()/conf/
-Jeff
-----Original Message-----
From: Toback, Steve
Sent: Tuesday, February 12, 2008 11:43 AM
To: 'lokahi-dev@incubator.apache.org'
Subject: RE: Templating configuration files
Without looking at the patch - we should probably start a page on the
wiki for this documentation :)
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Tuesday, February 12, 2008 11:36 AM
>To: lokahi-dev@incubator.apache.org
>Subject: RE: Templating configuration files
>
>I just committed the patches for the templating engine.
>Currently, it included a VelocityTemplatingEngine but I
>included instructions on how to add your own on the Jira issue
>page: https://issues.apache.org/jira/browse/LOKAHI-4. This
>page also includes all of the changes that were made for the
>templating engine code.
>
>-Jeff
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Monday, February 11, 2008 5:09 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>With the templating code being updated, I figured it would
>also be beneficial to include a generic config template
>deployer. This simply takes a worker, builds the config files
>based on its templates and deploys them to the location on the
>server provided when it is created.
>
>This should also reduce some of the dependencies on Apache and Tomcat.
>
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Friday, February 08, 2008 4:26 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>I have started working on this and found something else that
>looked to be beneficial. Instead of Apache and Tomcat only
>being allowed to have one file, I updated them to have a
>Collection of Templates. This allows any Application
>(currently only Apache and Tomcat) to have any number of
>configuration files. This lets the user choose a template for
>their worker.properties file along with the apache main file.
>This required 2 database tables be updated but I will be
>including a patch to update existing tables.
>
>-Jeff
>
>>-----Original Message-----
>>From: Feist, Jeffrey
>>Sent: Thursday, February 07, 2008 9:38 AM
>>To: 'lokahi-dev@incubator.apache.org'
>>Subject: RE: Templating configuration files
>>
>>Glad to hear there is a lot of interest in templating. Below
>are what I believe the changes that need to be made for the
>first pass. I will get started on these changes and attach
>them to the Jira ticket when they are complete. Please let me
>know if you have any comments or suggestions.
>>
>>GUI
>>----
>>Update "Manage Files" to say "Manage Templates"
>>
>>For files/templates:
>> Name: display name
>> Path: path to this file on the server (is this needed anymore?)
>> Descriptor: name of file (httpd.conf / httpsd.conf /
>workers.properties)
>>*Put examples next to field names*
>>
>>Update Apache:
>> - Update "Apache Main" to say "Apache Template"
>> - Add workers.properties template (with none as a choice)
>>
>>Update Tomcat:
>> - Add Server.xml Template drop down
>>
>>Backend
>>-----------
>>add "lokahi.template.engine=X" in lokahi.properties
>>
>>Create a new class called something like ConfTemplateBuilder
>>
>>Workers will call: public String
>ConfTemplateBuilder.buildConf(Server worker) {
>> - calls
>PropertiesFile.getConstantValue("templateEngine") -> returns
>org.apache.lokahi....VelocityTemplateEngine
>> - calls VelocityTemplateEngine.buildConf(Server) {}
>>
>>The engine classes would be:
>>Public abstract class TemplateEngine()
>>VelocityTemplateEngine extends TemplateEngine( )
>>
>>String VelocityTemplateEngine.buildConf(Server worker) {}
>> - would have the mapping from $apacheServer ->
>(ApacheWorker) Server.getApache().getServerRoot();
>> - if Server instanceof ApacheWorker {}
>> - else if Server instanceof TomcatWorker {}
>>
>>
>>
>>When other Engines would be added, they would need to extend
>class TemplateEngine() and have a buildConf function that
>returns a string representation of the config file.
>>
>>-Jeff
>
>
>
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by ST...@symcor.com.
Looking at the patch, I'm not sure which version of Lokahi vms-pactch.txt
is against. I've checked current svn, rev 619464, and M01 and all of them
seem to be missing the src/www/Core/Template/* files the patch is supposed
to be patching.
Can you diff it against svn?
-Severn
"Toback, Steve" <st...@merck.com>
02/12/2008 11:43 AM
Please respond to
lokahi-dev@incubator.apache.org
To
lokahi-dev@incubator.apache.org
cc
Subject
RE: Templating configuration files
Without looking at the patch - we should probably start a page on the
wiki for this documentation :)
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Tuesday, February 12, 2008 11:36 AM
>To: lokahi-dev@incubator.apache.org
>Subject: RE: Templating configuration files
>
>I just committed the patches for the templating engine.
>Currently, it included a VelocityTemplatingEngine but I
>included instructions on how to add your own on the Jira issue
>page: https://issues.apache.org/jira/browse/LOKAHI-4. This
>page also includes all of the changes that were made for the
>templating engine code.
>
>-Jeff
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Monday, February 11, 2008 5:09 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>With the templating code being updated, I figured it would
>also be beneficial to include a generic config template
>deployer. This simply takes a worker, builds the config files
>based on its templates and deploys them to the location on the
>server provided when it is created.
>
>This should also reduce some of the dependencies on Apache and Tomcat.
>
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Friday, February 08, 2008 4:26 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>I have started working on this and found something else that
>looked to be beneficial. Instead of Apache and Tomcat only
>being allowed to have one file, I updated them to have a
>Collection of Templates. This allows any Application
>(currently only Apache and Tomcat) to have any number of
>configuration files. This lets the user choose a template for
>their worker.properties file along with the apache main file.
>This required 2 database tables be updated but I will be
>including a patch to update existing tables.
>
>-Jeff
>
>>-----Original Message-----
>>From: Feist, Jeffrey
>>Sent: Thursday, February 07, 2008 9:38 AM
>>To: 'lokahi-dev@incubator.apache.org'
>>Subject: RE: Templating configuration files
>>
>>Glad to hear there is a lot of interest in templating. Below
>are what I believe the changes that need to be made for the
>first pass. I will get started on these changes and attach
>them to the Jira ticket when they are complete. Please let me
>know if you have any comments or suggestions.
>>
>>GUI
>>----
>>Update "Manage Files" to say "Manage Templates"
>>
>>For files/templates:
>> Name: display name
>> Path: path to this file on the server (is this needed
anymore?)
>> Descriptor: name of file (httpd.conf / httpsd.conf /
>workers.properties)
>>*Put examples next to field names*
>>
>>Update Apache:
>> - Update "Apache Main" to say "Apache Template"
>> - Add workers.properties template (with none as a choice)
>>
>>Update Tomcat:
>> - Add Server.xml Template drop down
>>
>>Backend
>>-----------
>>add "lokahi.template.engine=X" in lokahi.properties
>>
>>Create a new class called something like ConfTemplateBuilder
>>
>>Workers will call: public String
>ConfTemplateBuilder.buildConf(Server worker) {
>> - calls
>PropertiesFile.getConstantValue("templateEngine") -> returns
>org.apache.lokahi....VelocityTemplateEngine
>> - calls VelocityTemplateEngine.buildConf(Server) {}
>>
>>The engine classes would be:
>>Public abstract class TemplateEngine()
>>VelocityTemplateEngine extends TemplateEngine( )
>>
>>String VelocityTemplateEngine.buildConf(Server worker) {}
>> - would have the mapping from $apacheServer ->
>(ApacheWorker) Server.getApache().getServerRoot();
>> - if Server instanceof ApacheWorker {}
>> - else if Server instanceof TomcatWorker {}
>>
>>
>>
>>When other Engines would be added, they would need to extend
>class TemplateEngine() and have a buildConf function that
>returns a string representation of the config file.
>>
>>-Jeff
>
>
>
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Toback, Steve" <st...@merck.com>.
Without looking at the patch - we should probably start a page on the
wiki for this documentation :)
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Tuesday, February 12, 2008 11:36 AM
>To: lokahi-dev@incubator.apache.org
>Subject: RE: Templating configuration files
>
>I just committed the patches for the templating engine.
>Currently, it included a VelocityTemplatingEngine but I
>included instructions on how to add your own on the Jira issue
>page: https://issues.apache.org/jira/browse/LOKAHI-4. This
>page also includes all of the changes that were made for the
>templating engine code.
>
>-Jeff
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Monday, February 11, 2008 5:09 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>With the templating code being updated, I figured it would
>also be beneficial to include a generic config template
>deployer. This simply takes a worker, builds the config files
>based on its templates and deploys them to the location on the
>server provided when it is created.
>
>This should also reduce some of the dependencies on Apache and Tomcat.
>
>
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Friday, February 08, 2008 4:26 PM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>I have started working on this and found something else that
>looked to be beneficial. Instead of Apache and Tomcat only
>being allowed to have one file, I updated them to have a
>Collection of Templates. This allows any Application
>(currently only Apache and Tomcat) to have any number of
>configuration files. This lets the user choose a template for
>their worker.properties file along with the apache main file.
>This required 2 database tables be updated but I will be
>including a patch to update existing tables.
>
>-Jeff
>
>>-----Original Message-----
>>From: Feist, Jeffrey
>>Sent: Thursday, February 07, 2008 9:38 AM
>>To: 'lokahi-dev@incubator.apache.org'
>>Subject: RE: Templating configuration files
>>
>>Glad to hear there is a lot of interest in templating. Below
>are what I believe the changes that need to be made for the
>first pass. I will get started on these changes and attach
>them to the Jira ticket when they are complete. Please let me
>know if you have any comments or suggestions.
>>
>>GUI
>>----
>>Update "Manage Files" to say "Manage Templates"
>>
>>For files/templates:
>> Name: display name
>> Path: path to this file on the server (is this needed anymore?)
>> Descriptor: name of file (httpd.conf / httpsd.conf /
>workers.properties)
>>*Put examples next to field names*
>>
>>Update Apache:
>> - Update "Apache Main" to say "Apache Template"
>> - Add workers.properties template (with none as a choice)
>>
>>Update Tomcat:
>> - Add Server.xml Template drop down
>>
>>Backend
>>-----------
>>add "lokahi.template.engine=X" in lokahi.properties
>>
>>Create a new class called something like ConfTemplateBuilder
>>
>>Workers will call: public String
>ConfTemplateBuilder.buildConf(Server worker) {
>> - calls
>PropertiesFile.getConstantValue("templateEngine") -> returns
>org.apache.lokahi....VelocityTemplateEngine
>> - calls VelocityTemplateEngine.buildConf(Server) {}
>>
>>The engine classes would be:
>>Public abstract class TemplateEngine()
>>VelocityTemplateEngine extends TemplateEngine( )
>>
>>String VelocityTemplateEngine.buildConf(Server worker) {}
>> - would have the mapping from $apacheServer ->
>(ApacheWorker) Server.getApache().getServerRoot();
>> - if Server instanceof ApacheWorker {}
>> - else if Server instanceof TomcatWorker {}
>>
>>
>>
>>When other Engines would be added, they would need to extend
>class TemplateEngine() and have a buildConf function that
>returns a string representation of the config file.
>>
>>-Jeff
>
>
>
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
I just committed the patches for the templating engine. Currently, it
included a VelocityTemplatingEngine but I included instructions on how
to add your own on the Jira issue page:
https://issues.apache.org/jira/browse/LOKAHI-4. This page also includes
all of the changes that were made for the templating engine code.
-Jeff
-----Original Message-----
From: Feist, Jeffrey
Sent: Monday, February 11, 2008 5:09 PM
To: 'lokahi-dev@incubator.apache.org'
Subject: RE: Templating configuration files
With the templating code being updated, I figured it would also be
beneficial to include a generic config template deployer. This simply
takes a worker, builds the config files based on its templates and
deploys them to the location on the server provided when it is created.
This should also reduce some of the dependencies on Apache and Tomcat.
-----Original Message-----
From: Feist, Jeffrey
Sent: Friday, February 08, 2008 4:26 PM
To: 'lokahi-dev@incubator.apache.org'
Subject: RE: Templating configuration files
I have started working on this and found something else that looked to
be beneficial. Instead of Apache and Tomcat only being allowed to have
one file, I updated them to have a Collection of Templates. This allows
any Application (currently only Apache and Tomcat) to have any number of
configuration files. This lets the user choose a template for their
worker.properties file along with the apache main file. This required 2
database tables be updated but I will be including a patch to update
existing tables.
-Jeff
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Thursday, February 07, 2008 9:38 AM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>Glad to hear there is a lot of interest in templating. Below are what I
believe the changes that need to be made for the first pass. I will get
started on these changes and attach them to the Jira ticket when they
are complete. Please let me know if you have any comments or
suggestions.
>
>GUI
>----
>Update "Manage Files" to say "Manage Templates"
>
>For files/templates:
> Name: display name
> Path: path to this file on the server (is this needed anymore?)
> Descriptor: name of file (httpd.conf / httpsd.conf /
workers.properties)
>*Put examples next to field names*
>
>Update Apache:
> - Update "Apache Main" to say "Apache Template"
> - Add workers.properties template (with none as a choice)
>
>Update Tomcat:
> - Add Server.xml Template drop down
>
>Backend
>-----------
>add "lokahi.template.engine=X" in lokahi.properties
>
>Create a new class called something like ConfTemplateBuilder
>
>Workers will call: public String ConfTemplateBuilder.buildConf(Server
worker) {
> - calls PropertiesFile.getConstantValue("templateEngine") ->
returns org.apache.lokahi....VelocityTemplateEngine
> - calls VelocityTemplateEngine.buildConf(Server) {}
>
>The engine classes would be:
>Public abstract class TemplateEngine()
>VelocityTemplateEngine extends TemplateEngine( )
>
>String VelocityTemplateEngine.buildConf(Server worker) {}
> - would have the mapping from $apacheServer -> (ApacheWorker)
Server.getApache().getServerRoot();
> - if Server instanceof ApacheWorker {}
> - else if Server instanceof TomcatWorker {}
>
>
>
>When other Engines would be added, they would need to extend class
TemplateEngine() and have a buildConf function that returns a string
representation of the config file.
>
>-Jeff
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
With the templating code being updated, I figured it would also be
beneficial to include a generic config template deployer. This simply
takes a worker, builds the config files based on its templates and
deploys them to the location on the server provided when it is created.
This should also reduce some of the dependencies on Apache and Tomcat.
-----Original Message-----
From: Feist, Jeffrey
Sent: Friday, February 08, 2008 4:26 PM
To: 'lokahi-dev@incubator.apache.org'
Subject: RE: Templating configuration files
I have started working on this and found something else that looked to
be beneficial. Instead of Apache and Tomcat only being allowed to have
one file, I updated them to have a Collection of Templates. This allows
any Application (currently only Apache and Tomcat) to have any number of
configuration files. This lets the user choose a template for their
worker.properties file along with the apache main file. This required 2
database tables be updated but I will be including a patch to update
existing tables.
-Jeff
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Thursday, February 07, 2008 9:38 AM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>Glad to hear there is a lot of interest in templating. Below are what I
believe the changes that need to be made for the first pass. I will get
started on these changes and attach them to the Jira ticket when they
are complete. Please let me know if you have any comments or
suggestions.
>
>GUI
>----
>Update "Manage Files" to say "Manage Templates"
>
>For files/templates:
> Name: display name
> Path: path to this file on the server (is this needed anymore?)
> Descriptor: name of file (httpd.conf / httpsd.conf /
workers.properties)
>*Put examples next to field names*
>
>Update Apache:
> - Update "Apache Main" to say "Apache Template"
> - Add workers.properties template (with none as a choice)
>
>Update Tomcat:
> - Add Server.xml Template drop down
>
>Backend
>-----------
>add "lokahi.template.engine=X" in lokahi.properties
>
>Create a new class called something like ConfTemplateBuilder
>
>Workers will call: public String ConfTemplateBuilder.buildConf(Server
worker) {
> - calls PropertiesFile.getConstantValue("templateEngine") ->
returns org.apache.lokahi....VelocityTemplateEngine
> - calls VelocityTemplateEngine.buildConf(Server) {}
>
>The engine classes would be:
>Public abstract class TemplateEngine()
>VelocityTemplateEngine extends TemplateEngine( )
>
>String VelocityTemplateEngine.buildConf(Server worker) {}
> - would have the mapping from $apacheServer -> (ApacheWorker)
Server.getApache().getServerRoot();
> - if Server instanceof ApacheWorker {}
> - else if Server instanceof TomcatWorker {}
>
>
>
>When other Engines would be added, they would need to extend class
TemplateEngine() and have a buildConf function that returns a string
representation of the config file.
>
>-Jeff
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
I have started working on this and found something else that looked to
be beneficial. Instead of Apache and Tomcat only being allowed to have
one file, I updated them to have a Collection of Templates. This allows
any Application (currently only Apache and Tomcat) to have any number of
configuration files. This lets the user choose a template for their
worker.properties file along with the apache main file. This required 2
database tables be updated but I will be including a patch to update
existing tables.
-Jeff
>-----Original Message-----
>From: Feist, Jeffrey
>Sent: Thursday, February 07, 2008 9:38 AM
>To: 'lokahi-dev@incubator.apache.org'
>Subject: RE: Templating configuration files
>
>Glad to hear there is a lot of interest in templating. Below are what I
believe the changes that need to be made for the first pass. I will get
started on these changes and attach them to the Jira ticket when they
are complete. Please let me know if you have any comments or
suggestions.
>
>GUI
>----
>Update "Manage Files" to say "Manage Templates"
>
>For files/templates:
> Name: display name
> Path: path to this file on the server (is this needed anymore?)
> Descriptor: name of file (httpd.conf / httpsd.conf /
workers.properties)
>*Put examples next to field names*
>
>Update Apache:
> - Update "Apache Main" to say "Apache Template"
> - Add workers.properties template (with none as a choice)
>
>Update Tomcat:
> - Add Server.xml Template drop down
>
>Backend
>-----------
>add "lokahi.template.engine=X" in lokahi.properties
>
>Create a new class called something like ConfTemplateBuilder
>
>Workers will call: public String ConfTemplateBuilder.buildConf(Server
worker) {
> - calls PropertiesFile.getConstantValue("templateEngine") ->
returns org.apache.lokahi....VelocityTemplateEngine
> - calls VelocityTemplateEngine.buildConf(Server) {}
>
>The engine classes would be:
>Public abstract class TemplateEngine()
>VelocityTemplateEngine extends TemplateEngine( )
>
>String VelocityTemplateEngine.buildConf(Server worker) {}
> - would have the mapping from $apacheServer -> (ApacheWorker)
Server.getApache().getServerRoot();
> - if Server instanceof ApacheWorker {}
> - else if Server instanceof TomcatWorker {}
>
>
>
>When other Engines would be added, they would need to extend class
TemplateEngine() and have a buildConf function that returns a string
representation of the config file.
>
>-Jeff
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
Re: Templating configuration files
Posted by Steve Lihn <st...@gmail.com>.
Severn,
I am also interested in Lokahi supporting JBOSS/Apache environment.
Maybe there could be a /common/ J2EE module added to Lokahi.
What is your requirement to manage Geronimo?
What I am looking for in JBOSS is simple: To start/stop a JBOSS server
(JVM). Of course, this is in addition to all the nice features of
managing Apache config, JVM config, and mod_jk.
If there is momentum in this direction, more features can be added,
such as managing JBOSS config files, getting into the JMX console
business, etc.
Steve
On 2/5/08, STsui@symcor.com <ST...@symcor.com> wrote:
> We\'re planning on using Lokahi to manage our application hosting
> infrastructure, however we\'re primarily a Geronimo/Apache shop instead of
> Tomcat, so we have an interest in some sort of more generic configuration
> templating.
RE: Templating configuration files
Posted by ST...@symcor.com.
Hello,
We're planning on using Lokahi to manage our application hosting
infrastructure, however we're primarily a Geronimo/Apache shop instead of
Tomcat, so we have an interest in some sort of more generic configuration
templating.
I can't say I'm too familiar with OSGi... but I do agree that once a user
has decided on one format, they'll probably keep it. Even if they did want
to change formats, changing it at runtime seems kind of messy. However, if
there are features that one template engine has and another doesn't,
someone might want to run one engine say... Apache and another engine for
others?
I've been looking into Velocity as well, it looks like "the way to go",
but if while we're at we can make the system pluggable, that probably
would be even better.
-Severn
"Feist, Jeffrey" <je...@merck.com>
02/01/2008 10:37 AM
Please respond to
lokahi-dev@incubator.apache.org
To
lokahi-dev@incubator.apache.org, ludovic.maitre@free.fr
cc
Subject
RE: Templating configuration files
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:ludovic.maitre@free.fr]
Sent: Thursday, January 31, 2008 2:42 AM
To: lokahi-dev@incubator.apache.org
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 <je...@merck.com> 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.
------------------------------------------------------------------------------
RE: Templating configuration files
Posted by "Feist, Jeffrey" <je...@merck.com>.
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:ludovic.maitre@free.fr]
Sent: Thursday, January 31, 2008 2:42 AM
To: lokahi-dev@incubator.apache.org
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 <je...@merck.com> 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.
------------------------------------------------------------------------------
Re: Templating configuration files
Posted by Ludovic Maitre <lu...@free.fr>.
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 <je...@merck.com> 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)
Re: Templating configuration files
Posted by Steve Toback <to...@apache.org>.
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 <je...@merck.com> 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