You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Lars Huttar <la...@sil.org> on 2005/06/22 00:13:36 UTC
deploying to separate environments using different database servers
Dear Cocoon-based webapp developers,
I would be interested to hear how others have handled this issue.
You have Cocoon applications whose source code is stored in a
repository. You want to be able to install them on multiple development
machines (on each developer's desktop), on test servers, and on
production servers.
The environments (dev, test, production) use separate database servers
as well as separate web servers.
But when you checkout the source code from the repository onto various
web servers, they're all pointing to the same database server, because
they all have the same datasources defined in cocoon.xconf.
You could then go in and modify cocoon.xconf separately for each
environment, but that could get to be a lot of time-consuming and
error-prone work. (We currently have 38 datasources defined for all our
applications! Maybe not all of them are still used, but most are, I
believe.)
How do you automate this task?
I'm trying to think of some way to set one global variable that points
to a dev, test, or production database server, so that code only needs
to be changed in one place... and preferably not every time datasources
are added or changed. Maybe it should be done by defining an XML entity?
Thanks for any responses.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: deploying to separate environments using different database servers
Posted by Andrew Franz <af...@optushome.com.au>.
1. In cocoon.xconf, setup an input module like this:
<component-instance name="local-properties"
class="org.apache.cocoon.components.modules.input.PropertiesFileModule">
<file src="C:\env\local.properties"/>
</component-instance>
& setup *both* datasources like this:
<datasources>
<jdbc name="dbdev">
<dburl>jdbc:oracle:thin:@localhost:1521:dbdev</dburl>
...
</jdbc>
<jdbc name="dblive">
<dburl>jdbc:oracle:thin:@localhost:1521:dblive</dburl>
...
</jdbc>
...
2. in c:\env\local.properties
dbc=dbdev
or dbc=dblive (depending on the system)
3. In each sitemap, if you were using the SQLTransformer, for example:
<map:transform type="sql">
<map:parameter name="use-connection"
value="{local-properties:dbc}" />
...
...or XSP
<map:generate src="{1}.xsp" type="serverpages"/>
<map:parameter name="dbc" value="{local-properties:dbc}"/>
and
<esql:pool><xsp:expr>parameters.getParameter("dbc")</xsp:expr></esql:pool>
Kim Toms wrote:
> I was wondering something similiar; I have a system where database
> servers are deployed, and I'd like to pull reports off of them. I
> have a list of database servers in a local database, do I have to
> manually edit the cocoon.xconf file as I deploy each new server?
>
> On 6/21/05, *Lars Huttar* <lars_huttar@sil.org
> <ma...@sil.org> > wrote:
>
> Dear Cocoon-based webapp developers,
>
> I would be interested to hear how others have handled this issue.
>
> You have Cocoon applications whose source code is stored in a
> repository. You want to be able to install them on multiple
> development
> machines (on each developer's desktop), on test servers, and on
> production servers.
> The environments (dev, test, production) use separate database servers
> as well as separate web servers.
> But when you checkout the source code from the repository onto various
> web servers, they're all pointing to the same database server,
> because
> they all have the same datasources defined in cocoon.xconf.
>
> You could then go in and modify cocoon.xconf separately for each
> environment, but that could get to be a lot of time-consuming and
> error-prone work. (We currently have 38 datasources defined for
> all our
> applications! Maybe not all of them are still used, but most are, I
> believe.)
> How do you automate this task?
>
> I'm trying to think of some way to set one global variable that points
> to a dev, test, or production database server, so that code only
> needs
> to be changed in one place... and preferably not every time
> datasources
> are added or changed. Maybe it should be done by defining an XML
> entity?
>
> Thanks for any responses.
>
> Lars
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> <ma...@cocoon.apache.org>
> For additional commands, e-mail: users-help@cocoon.apache.org
> <ma...@cocoon.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: deploying to separate environments using different database servers
Posted by Kim Toms <ki...@gmail.com>.
I was wondering something similiar; I have a system where database servers
are deployed, and I'd like to pull reports off of them. I have a list of
database servers in a local database, do I have to manually edit the
cocoon.xconf file as I deploy each new server?
On 6/21/05, Lars Huttar <la...@sil.org> wrote:
>
> Dear Cocoon-based webapp developers,
>
> I would be interested to hear how others have handled this issue.
>
> You have Cocoon applications whose source code is stored in a
> repository. You want to be able to install them on multiple development
> machines (on each developer's desktop), on test servers, and on
> production servers.
> The environments (dev, test, production) use separate database servers
> as well as separate web servers.
> But when you checkout the source code from the repository onto various
> web servers, they're all pointing to the same database server, because
> they all have the same datasources defined in cocoon.xconf.
>
> You could then go in and modify cocoon.xconf separately for each
> environment, but that could get to be a lot of time-consuming and
> error-prone work. (We currently have 38 datasources defined for all our
> applications! Maybe not all of them are still used, but most are, I
> believe.)
> How do you automate this task?
>
> I'm trying to think of some way to set one global variable that points
> to a dev, test, or production database server, so that code only needs
> to be changed in one place... and preferably not every time datasources
> are added or changed. Maybe it should be done by defining an XML entity?
>
> Thanks for any responses.
>
> Lars
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: deploying to separate environments using different database servers
Posted by Lars Huttar <la...@sil.org>.
Mark Lundquist wrote:
>
> Hi Lars,
>
> On Jun 21, 2005, at 3:13 PM, Lars Huttar wrote:
>
>> Dear Cocoon-based webapp developers,
>>
>> I would be interested to hear how others have handled this issue.
>>
>> You have Cocoon applications whose source code is stored in a
>> repository. You want to be able to install them on multiple
>> development machines (on each developer's desktop), on test servers,
>> and on production servers.
>> The environments (dev, test, production) use separate database
>> servers as well as separate web servers.
>> But when you checkout the source code from the repository onto
>> various web servers, they're all pointing to the same database
>> server, because they all have the same datasources defined in
>> cocoon.xconf.
>>
>> You could then go in and modify cocoon.xconf separately for each
>> environment, but that could get to be a lot of time-consuming and
>> error-prone work. (We currently have 38 datasources defined for all
>> our applications! Maybe not all of them are still used, but most are,
>> I believe.)
>> How do you automate this task?
>
>
> With the xpatch Ant task, included with Cocoon (the cocoon build uses
> it). See http://wiki.apache.org/cocoon/XPatchTaskUsage.
>
Thanks for the suggestion.
It's good to know about xpatch.
Presumably in our situation, we would set up our source control system
to run xpatch whenever certain files are updated from source control.
I'm hesistant to use something like that, for two reasons.
One is that it adds extra steps to our process. Up till now, developers
on our team have not had to know anything about Ant.
The other is that if xpatch modifies a file on update, source control
will flag it as "modified" when there is nothing that needs to be
committed to the repository. This will confuse developers and make it
more difficult for them to tell when a file really does need to be
committed.
Maybe you have some way to deal with that?
I think our solution will be to use parameter entities and external
entities, if I can get it to work.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: deploying to separate environments using different database servers
Posted by Mark Lundquist <ml...@wrinkledog.com>.
Hi Lars,
On Jun 21, 2005, at 3:13 PM, Lars Huttar wrote:
> Dear Cocoon-based webapp developers,
>
> I would be interested to hear how others have handled this issue.
>
> You have Cocoon applications whose source code is stored in a
> repository. You want to be able to install them on multiple
> development machines (on each developer's desktop), on test servers,
> and on production servers.
> The environments (dev, test, production) use separate database servers
> as well as separate web servers.
> But when you checkout the source code from the repository onto various
> web servers, they're all pointing to the same database server, because
> they all have the same datasources defined in cocoon.xconf.
>
> You could then go in and modify cocoon.xconf separately for each
> environment, but that could get to be a lot of time-consuming and
> error-prone work. (We currently have 38 datasources defined for all
> our applications! Maybe not all of them are still used, but most are,
> I believe.)
> How do you automate this task?
With the xpatch Ant task, included with Cocoon (the cocoon build uses
it). See http://wiki.apache.org/cocoon/XPatchTaskUsage.
HTH,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org