You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeffrey Janner <Je...@PolyDyne.com> on 2012/02/16 22:12:01 UTC
generic deployment question
Assume latest Tomcat 6.x for current deployment, and 7.x for future deployments.
I host an app for a couple of dozen customers. Naturally, upgrade time can be a bit of a pain, and I'd like to simplify things.
Assuming that all the customer-specific information (DB connection info, logger info, etc.) can be described as resources in the context.xml file, would it be possible to put the actual webapp in a single pre-exploded directory without causing Tomcat fits?
Example directory tree:
Web-app-1.1
Images
META-INF
JSPs
WEB-INF (with generic web.xml for web-app-1.1)
lib
classes
ROOT.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context path=""
docBase="path/to/Web-app-1.1">
<Valve className="org.apache.catalina.authenticator.SSLAuthenticator"
securePagesWithPragma="false" />
<....resources definitions.... />
</Context>
Then when a new release comes out, I can deploy the web-app once and modify the individual customer's contexts to point to the new release path as they choose upgrade (or all at once).
And, yes, I know that disk is cheap and I could just do it by replacing 3-4 dozen war files nearly as easily. And right now, I'm not sure if the future 7.x versioning feature will come in handy as our dev staff haven't started investigating 7.x yet.
Jeff
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: generic deployment question
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 1:59 PM, Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Terence M. Bandoian [mailto:terence@tmbsw.com]
>> Sent: Saturday, February 18, 2012 5:14 PM
>> To: Tomcat Users List
>> Subject: Re: generic deployment question
>>
>> On 1:59 PM, Christopher Schultz wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Jeffrey,
>>>
>>> On 2/17/12 10:45 AM, Jeffrey Janner wrote:
>>>> Thanks. I was under the impression that Tomcat normally explodes
>>>> the war files when you drop them into the webapps folder, though I
>>>> know you can disable that feature.
>>> I was suggesting that you leave the WAR files out of the webapps
>>> directory, but it doesn't really matter.
>>>
>>> Honestly, if you use the manager to deploy your webapps, you can
>>> upload whatever WAR file you want anytime you want to get whatever
>>> version you want.
>>>
>>>> I was under the impression that one should run from the exploded
>>>> directory for performance reasons, i.e. it's faster to pull files
>>>> from the directory than from inside the war file.
>>> IIRC, Tomcat explodes the WAR file into the work directory anyway.
>> You
>>> can easily confirm that.
>>>
>>>> If there really is no performance difference, then that's even more
>>>> reason that I want to get my developers to get this thing down to a
>>>> war file with no files I need to modify.
>>> Don't forget the immense power of scripting: if you have
>>> client-specific files to merge into a webapp, then write a script
>> that
>>> takes the stock WAR file from engineering and a set of client-
>> specific
>>> files and combines them into a client-specific WAR. You can even have
>>> that script push the newly-minted WAR file up to Tomcat using the
>>> manager. Boom: single-script deployment for each client.
>>>
>>> You got 25 clients? Run the same command 25 times. Or script that,
>> too.
>>> - -chris
>> If each user has their own domain, wouldn't it be possible to:
>>
>> 1) Move all of the user-specific configuration information to a
>> database
>>
>> 2) Differentiate users by host name and access their configuration data
>> from the database.
>>
>> This could simplify administration of the application over the long
>> term.
>>
>> Does each domain have a different IP address?
>>
>> -Terence Bandoian
>>
> Yes Terence, that's the direction I'm headed in. Currently, each customer gets their own host/IP/DB. I'm trying to get it so all I have to do to setup a new customer is set up the<host> and context.xml with<resources> for the DB connection and context parameters supplying paths to log4j.properties and anything else that has to be pulled from the file system. If I get there, I don't see the need to have multiple copies of the actual app (be it war file or exploded directory) on the system.
> But as stated, I think I answered my own question when I really thought about it. Thanks for you input anyway.
Hi, Jeffrey-
I might try to go to a little further so that all you have to do to
configure new customers is add them to a common configuration database.
Logging could be problematic.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Terence M. Bandoian [mailto:terence@tmbsw.com]
> Sent: Saturday, February 18, 2012 5:14 PM
> To: Tomcat Users List
> Subject: Re: generic deployment question
>
> On 1:59 PM, Christopher Schultz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jeffrey,
> >
> > On 2/17/12 10:45 AM, Jeffrey Janner wrote:
> >> Thanks. I was under the impression that Tomcat normally explodes
> >> the war files when you drop them into the webapps folder, though I
> >> know you can disable that feature.
> > I was suggesting that you leave the WAR files out of the webapps
> > directory, but it doesn't really matter.
> >
> > Honestly, if you use the manager to deploy your webapps, you can
> > upload whatever WAR file you want anytime you want to get whatever
> > version you want.
> >
> >> I was under the impression that one should run from the exploded
> >> directory for performance reasons, i.e. it's faster to pull files
> >> from the directory than from inside the war file.
> > IIRC, Tomcat explodes the WAR file into the work directory anyway.
> You
> > can easily confirm that.
> >
> >> If there really is no performance difference, then that's even more
> >> reason that I want to get my developers to get this thing down to a
> >> war file with no files I need to modify.
> > Don't forget the immense power of scripting: if you have
> > client-specific files to merge into a webapp, then write a script
> that
> > takes the stock WAR file from engineering and a set of client-
> specific
> > files and combines them into a client-specific WAR. You can even have
> > that script push the newly-minted WAR file up to Tomcat using the
> > manager. Boom: single-script deployment for each client.
> >
> > You got 25 clients? Run the same command 25 times. Or script that,
> too.
> >
> > - -chris
>
> If each user has their own domain, wouldn't it be possible to:
>
> 1) Move all of the user-specific configuration information to a
> database
>
> 2) Differentiate users by host name and access their configuration data
> from the database.
>
> This could simplify administration of the application over the long
> term.
>
> Does each domain have a different IP address?
>
> -Terence Bandoian
>
Yes Terence, that's the direction I'm headed in. Currently, each customer gets their own host/IP/DB. I'm trying to get it so all I have to do to setup a new customer is set up the <host> and context.xml with <resources> for the DB connection and context parameters supplying paths to log4j.properties and anything else that has to be pulled from the file system. If I get there, I don't see the need to have multiple copies of the actual app (be it war file or exploded directory) on the system.
But as stated, I think I answered my own question when I really thought about it. Thanks for you input anyway.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 1:59 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeffrey,
>
> On 2/17/12 10:45 AM, Jeffrey Janner wrote:
>> Thanks. I was under the impression that Tomcat normally explodes
>> the war files when you drop them into the webapps folder, though I
>> know you can disable that feature.
> I was suggesting that you leave the WAR files out of the webapps
> directory, but it doesn't really matter.
>
> Honestly, if you use the manager to deploy your webapps, you can
> upload whatever WAR file you want anytime you want to get whatever
> version you want.
>
>> I was under the impression that one should run from the exploded
>> directory for performance reasons, i.e. it's faster to pull files
>> from the directory than from inside the war file.
> IIRC, Tomcat explodes the WAR file into the work directory anyway. You
> can easily confirm that.
>
>> If there really is no performance difference, then that's even more
>> reason that I want to get my developers to get this thing down to a
>> war file with no files I need to modify.
> Don't forget the immense power of scripting: if you have
> client-specific files to merge into a webapp, then write a script that
> takes the stock WAR file from engineering and a set of client-specific
> files and combines them into a client-specific WAR. You can even have
> that script push the newly-minted WAR file up to Tomcat using the
> manager. Boom: single-script deployment for each client.
>
> You got 25 clients? Run the same command 25 times. Or script that, too.
>
> - -chris
If each user has their own domain, wouldn't it be possible to:
1) Move all of the user-specific configuration information to a database
2) Differentiate users by host name and access their configuration data
from the database.
This could simplify administration of the application over the long term.
Does each domain have a different IP address?
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 2/17/12 10:45 AM, Jeffrey Janner wrote:
> Thanks. I was under the impression that Tomcat normally explodes
> the war files when you drop them into the webapps folder, though I
> know you can disable that feature.
I was suggesting that you leave the WAR files out of the webapps
directory, but it doesn't really matter.
Honestly, if you use the manager to deploy your webapps, you can
upload whatever WAR file you want anytime you want to get whatever
version you want.
> I was under the impression that one should run from the exploded
> directory for performance reasons, i.e. it's faster to pull files
> from the directory than from inside the war file.
IIRC, Tomcat explodes the WAR file into the work directory anyway. You
can easily confirm that.
> If there really is no performance difference, then that's even more
> reason that I want to get my developers to get this thing down to a
> war file with no files I need to modify.
Don't forget the immense power of scripting: if you have
client-specific files to merge into a webapp, then write a script that
takes the stock WAR file from engineering and a set of client-specific
files and combines them into a client-specific WAR. You can even have
that script push the newly-minted WAR file up to Tomcat using the
manager. Boom: single-script deployment for each client.
You got 25 clients? Run the same command 25 times. Or script that, too.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8+eUUACgkQ9CaO5/Lv0PAjCgCgv8HIzzyo07sDXYFy/RrwtTRn
UN8An1/NOK4EyUprYYjzvLojYQ7wXSwa
=x7Xg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, February 17, 2012 9:36 AM
> To: Tomcat Users List
> Subject: Re: generic deployment question
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeffrey,
>
> On 2/16/12 4:12 PM, Jeffrey Janner wrote:
> > I host an app for a couple of dozen customers. Naturally, upgrade
> > time can be a bit of a pain, and I'd like to simplify things.
> > Assuming that all the customer-specific information (DB connection
> > info, logger info, etc.) can be described as resources in the
> > context.xml file, would it be possible to put the actual webapp in
> > a single pre-exploded directory without causing Tomcat fits?
>
> [snip]
>
> > Then when a new release comes out, I can deploy the web-app once
> > and modify the individual customer's contexts to point to the new
> > release path as they choose upgrade (or all at once).
>
> When you say "deploy the web-app once" you aren't really talking about
> deploying it: what you mean is just throwing it up on the server on
> the disk some place. A "deployment" is really when the context gets
> launched and it available to clients.
>
> I don't see any reason why you couldn't do this. I agree with Pid that
> you shouldn't explode the WAR file: there's no reason to do that
> unless you have buggy code that doesn't fetch resources properly. I
> think it would be as easy as this:
>
> 1. Get the WAR file into a new place:
>
> $ cp my-new-version.war \
> /path/to/non-auto-deploy-webapps/
>
> 2. For each webapp you want to upgrade:
> $ echo ",s/my-old-version\.war/my-new-version\.war/g" \
> | ed $CATALINA_BASE/conf/Catalina/[hostname]/webapp.xml
>
> If you have auto-deploy enabled, I believe this will cause Tomcat to
> reload the context. If not, you may have to use the manager to either
> re-load the context or re-deploy.
>
> - -chris
Chris-
Thanks. I was under the impression that Tomcat normally explodes the war files when you drop them into the webapps folder, though I know you can disable that feature. I was under the impression that one should run from the exploded directory for performance reasons, i.e. it's faster to pull files from the directory than from inside the war file. If there really is no performance difference, then that's even more reason that I want to get my developers to get this thing down to a war file with no files I need to modify.
Thanks again.
Jeff
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: [logging processes] Too many or Not too many?
Posted by Pae Choi <pa...@gmail.com>.
On 02/18/2012 05:17 PM, Mark Thomas wrote:
> On 18/02/2012 21:57, Pae Choi wrote:
>> Tomcat v7.0.25
>> CentOS 5.7 32bit
>>
>> Running the tomcat without any webapp deployed, the system shows about
>> 38 processes(i think)
>> related to logging. Why that many and what are they logging about?
>>
>> I see some of logging under the "$CATALINA_HOME/logs" folder and they
>> seemed to be reasonably
>> needed. But what others related to that many logging processes?
> 1. Don't hijack threads.
>
> 2. Be patient.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
My apologies for not being patient as well as hijacking the thread. It's
2nd posting since the
1st posting didn't appeared as fast as used be about a little over a
decade ago. So I just wanted
to test to see if any posting works.
Anyhow, your reply confirmed what I intended for. Thanks.
Pae
Re: [logging processes] Too many or Not too many?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2012 21:57, Pae Choi wrote:
> Tomcat v7.0.25
> CentOS 5.7 32bit
>
> Running the tomcat without any webapp deployed, the system shows about
> 38 processes(i think)
> related to logging. Why that many and what are they logging about?
>
> I see some of logging under the "$CATALINA_HOME/logs" folder and they
> seemed to be reasonably
> needed. But what others related to that many logging processes?
1. Don't hijack threads.
2. Be patient.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
[logging processes] Too many or Not too many?
Posted by Pae Choi <pa...@gmail.com>.
Tomcat v7.0.25
CentOS 5.7 32bit
Running the tomcat without any webapp deployed, the system shows about
38 processes(i think)
related to logging. Why that many and what are they logging about?
I see some of logging under the "$CATALINA_HOME/logs" folder and they
seemed to be reasonably
needed. But what others related to that many logging processes?
Regards,
Pae
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, February 17, 2012 9:42 AM
> To: Tomcat Users List
> Subject: Re: generic deployment question
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeffrey,
>
> On 2/17/12 10:36 AM, Christopher Schultz wrote:
> > Jeffrey,
> >
> > On 2/16/12 4:12 PM, Jeffrey Janner wrote:
> >> I host an app for a couple of dozen customers. Naturally,
> >> upgrade time can be a bit of a pain, and I'd like to simplify
> >> things. Assuming that all the customer-specific information (DB
> >> connection info, logger info, etc.) can be described as resources
> >> in the context.xml file, would it be possible to put the actual
> >> webapp in a single pre-exploded directory without causing Tomcat
> >> fits?
> >
> > [snip]
> >
> >> Then when a new release comes out, I can deploy the web-app once
> >> and modify the individual customer's contexts to point to the
> >> new release path as they choose upgrade (or all at once).
> >
> > When you say "deploy the web-app once" you aren't really talking
> > about deploying it: what you mean is just throwing it up on the
> > server on the disk some place. A "deployment" is really when the
> > context gets launched and it available to clients.
> >
> > I don't see any reason why you couldn't do this. I agree with Pid
> > that you shouldn't explode the WAR file: there's no reason to do
> > that unless you have buggy code that doesn't fetch resources
> > properly. I think it would be as easy as this:
> >
> > 1. Get the WAR file into a new place:
> >
> > $ cp my-new-version.war \ /path/to/non-auto-deploy-webapps/
> >
> > 2. For each webapp you want to upgrade: $ echo
> > ",s/my-old-version\.war/my-new-version\.war/g" \ | ed
> > $CATALINA_BASE/conf/Catalina/[hostname]/webapp.xml
> >
> > If you have auto-deploy enabled, I believe this will cause Tomcat
> > to reload the context. If not, you may have to use the manager to
> > either re-load the context or re-deploy.
>
> http://tomcat.apache.org/tomcat-7.0-doc/manager-
> howto.html#Deploy_A_New_Application_from_a_Local_Path
>
> You can deploy from an existing configuration file like this:
> http://localhost:8080/manager/text/deploy?config=file:/path/context.xml
>
> I'm not sure if "update=true" will work for that command, so you may
> have to perform an undeploy first, then a re-deploy.
>
That's where I'm trying to get the current developer crop to go so I can use "standard" deployment methods. Then maybe, just maybe, I can turn all this over to someone else and "retire". Of course, right now, it's like trying to paddle upstream in a molasses river in a rubber dingy.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: generic deployment question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 2/17/12 10:36 AM, Christopher Schultz wrote:
> Jeffrey,
>
> On 2/16/12 4:12 PM, Jeffrey Janner wrote:
>> I host an app for a couple of dozen customers. Naturally,
>> upgrade time can be a bit of a pain, and I'd like to simplify
>> things. Assuming that all the customer-specific information (DB
>> connection info, logger info, etc.) can be described as resources
>> in the context.xml file, would it be possible to put the actual
>> webapp in a single pre-exploded directory without causing Tomcat
>> fits?
>
> [snip]
>
>> Then when a new release comes out, I can deploy the web-app once
>> and modify the individual customer's contexts to point to the
>> new release path as they choose upgrade (or all at once).
>
> When you say "deploy the web-app once" you aren't really talking
> about deploying it: what you mean is just throwing it up on the
> server on the disk some place. A "deployment" is really when the
> context gets launched and it available to clients.
>
> I don't see any reason why you couldn't do this. I agree with Pid
> that you shouldn't explode the WAR file: there's no reason to do
> that unless you have buggy code that doesn't fetch resources
> properly. I think it would be as easy as this:
>
> 1. Get the WAR file into a new place:
>
> $ cp my-new-version.war \ /path/to/non-auto-deploy-webapps/
>
> 2. For each webapp you want to upgrade: $ echo
> ",s/my-old-version\.war/my-new-version\.war/g" \ | ed
> $CATALINA_BASE/conf/Catalina/[hostname]/webapp.xml
>
> If you have auto-deploy enabled, I believe this will cause Tomcat
> to reload the context. If not, you may have to use the manager to
> either re-load the context or re-deploy.
http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Deploy_A_New_Application_from_a_Local_Path
You can deploy from an existing configuration file like this:
http://localhost:8080/manager/text/deploy?config=file:/path/context.xml
I'm not sure if "update=true" will work for that command, so you may
have to perform an undeploy first, then a re-deploy.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8+dVoACgkQ9CaO5/Lv0PCdCgCfR/YPqJIeorExHoy81ZA/rof1
9UAAoK+xFAjdHQu5P2VF87JGjGIOTD5T
=QVk/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 2/16/12 4:12 PM, Jeffrey Janner wrote:
> I host an app for a couple of dozen customers. Naturally, upgrade
> time can be a bit of a pain, and I'd like to simplify things.
> Assuming that all the customer-specific information (DB connection
> info, logger info, etc.) can be described as resources in the
> context.xml file, would it be possible to put the actual webapp in
> a single pre-exploded directory without causing Tomcat fits?
[snip]
> Then when a new release comes out, I can deploy the web-app once
> and modify the individual customer's contexts to point to the new
> release path as they choose upgrade (or all at once).
When you say "deploy the web-app once" you aren't really talking about
deploying it: what you mean is just throwing it up on the server on
the disk some place. A "deployment" is really when the context gets
launched and it available to clients.
I don't see any reason why you couldn't do this. I agree with Pid that
you shouldn't explode the WAR file: there's no reason to do that
unless you have buggy code that doesn't fetch resources properly. I
think it would be as easy as this:
1. Get the WAR file into a new place:
$ cp my-new-version.war \
/path/to/non-auto-deploy-webapps/
2. For each webapp you want to upgrade:
$ echo ",s/my-old-version\.war/my-new-version\.war/g" \
| ed $CATALINA_BASE/conf/Catalina/[hostname]/webapp.xml
If you have auto-deploy enabled, I believe this will cause Tomcat to
reload the context. If not, you may have to use the manager to either
re-load the context or re-deploy.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8+c/MACgkQ9CaO5/Lv0PAPWgCgn2uSU4Kw+9jVk5i3wsbf2y0d
4GQAniVwmmKlqVbUIXtRBwNvQJk+VvHA
=CO5N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/17 Jeffrey Janner <Je...@polydyne.com>:
> Assume latest Tomcat 6.x for current deployment, and 7.x for future deployments.
>
> I host an app for a couple of dozen customers. Naturally, upgrade time can be a bit of a pain, and I'd like to simplify things.
> Assuming that all the customer-specific information (DB connection info, logger info, etc.) can be described as resources in the context.xml file, would it be possible to put the actual webapp in a single pre-exploded directory without causing Tomcat fits?
>
> Example directory tree:
>
> Web-app-1.1
> Images
> META-INF
> JSPs
> WEB-INF (with generic web.xml for web-app-1.1)
> lib
> classes
>
> ROOT.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <Context path=""
> docBase="path/to/Web-app-1.1">
> <Valve className="org.apache.catalina.authenticator.SSLAuthenticator"
> securePagesWithPragma="false" />
> <....resources definitions.... />
> </Context>
>
>
> Then when a new release comes out, I can deploy the web-app once and modify the individual customer's contexts to point to the new release path as they choose upgrade (or all at once).
>
> And, yes, I know that disk is cheap and I could just do it by replacing 3-4 dozen war files nearly as easily. And right now, I'm not sure if the future 7.x versioning feature will come in handy as our dev staff haven't started investigating 7.x yet.
>
1. It is possible to have several contexts to point to the same
exploded directory or a war file.
People use this a lot with virtual hosts - to deploy the same manager
webapp to different hosts at once.
I use this when running with separate CATALINA_HOME and CATALINA_BASE:
I leave manager webapp in CATALINA_HOME, pointing to it from a context
file. (So that I do not need to do a fresh copy of manager app when I
update Tomcat).
Note that you can use properties substitution in xml files parsed by
Tomcat, e.g. use ${catalina.home}.
2. Regarding different configuration:
- It is possible to add paths to classloader via context.xml - by
using VirtualWebappLoader class.
- It is possible to overwrite resources by using aliases in Context in Tomcat 7.
3. If you need to minimize downtime, in Tomcat 7 you can use versioned contexts.
4. If you frequently use redeployment on a running Tomcat, make sure
that your web application does not have PermGen memory leak. The
manager app can detect them.
5. If you are redeploying on a stopped Tomcat, make sure that you
purge the work directory from old files.
>> I was under the impression that one should run from the exploded
>> directory for performance reasons, i.e. it's faster to pull files
>> from the directory than from inside the war file.
>
> IIRC, Tomcat explodes the WAR file into the work directory anyway. You
> can easily confirm that.
>
Only classes and jars. Resources are not unpacked when running from
unexploded WAR.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 2/17/12 10:39 AM, Jeffrey Janner wrote:
> That's actually the current deployment mechanism that I'm wanting
> to get changed. Unfortunately right now, there are some
> application related config files buried under the WEB-INF directory
> that have to updated for each customer, so I have to use the
> exploded directory structure anyway.
zip -u?
jar u?
Doesn't this mean that you need a separate exploded directory for each
customer, anyway?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8+deAACgkQ9CaO5/Lv0PDWIACeOS9+sv0hGOuZsu/GtPj0G9MS
Y4IAoIZZRVpPSRimGDnTlRbb2mAWYR9h
=B5OC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
> Sent: Friday, February 17, 2012 9:22 AM
> To: Tomcat Users List
> Subject: RE: generic deployment question
>
> > From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> > Subject: RE: generic deployment question
>
> > But, really, I just wanted to know if my original suggestion
> > would cause issues with Tomcat.
>
> As Pid stated, it might work, but it's not a guaranteed deployment
> mechanism.
>
> > Essentially, I don't see why I should zip up an app directory
> > structure into a war file, just so Tomcat can unzip it a couple
> > of dozen times.
>
> No need to zip anything up, just make a copy of the directory for each
> client.
>
> - Chuck
That's actually the current deployment mechanism that I'm wanting to get changed. Unfortunately right now, there are some application related config files buried under the WEB-INF directory that have to updated for each customer, so I have to use the exploded directory structure anyway. Trying to get that changed so the information is retrieved from the database and then the database config info is done the "tomcat normal" way. Same with the location of the log4j properties file. Then there's only one or two other minor per/customer mods that I sometimes do that can be handled differently as well.
I'm trying to limit the number of places I have to make updates on a deployment.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: generic deployment question
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> Subject: RE: generic deployment question
> But, really, I just wanted to know if my original suggestion
> would cause issues with Tomcat.
As Pid stated, it might work, but it's not a guaranteed deployment mechanism.
> Essentially, I don't see why I should zip up an app directory
> structure into a war file, just so Tomcat can unzip it a couple
> of dozen times.
No need to zip anything up, just make a copy of the directory for each client.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Thursday, February 16, 2012 3:32 PM
> To: Tomcat Users List
> Subject: Re: generic deployment question
>
> Jeffrey Janner wrote:
> > Assume latest Tomcat 6.x for current deployment, and 7.x for future
> deployments.
> >
> > I host an app for a couple of dozen customers. Naturally, upgrade
> time can be a bit of a pain,
>
> why ?
>
> and I'd like to simplify things.
> > Assuming that all the customer-specific information (DB connection
> info, logger info, etc.) can be described as resources in the
> context.xml file, would it be possible to put the actual webapp in a
> single pre-exploded directory without causing Tomcat fits?
> >
>
> It seems to me that there is a logical problem : if you have only 1
> webapp, then you also
> only have one context.xml. So how are you going to specify per-
> customer specific
> configurations ?
> And even if you do, how will you distinguish a request from one
> customer from a request
> from another customer, and use this information to select the
> appropriate resource
> definition ?
>
> Personally, I tend to think that you are going to trade an small
> inconvenient (having to
> update 24 war files), against a vast complication of your application
> and setup.
> And lose a lot of flexibility too, like if ever one customer wanted
> this thing just a
> little differently..
>
> I am told that there are tools to automate such a multiple deployment,
> so that you would
> only have to give a command once, and it would deploy the same
> application to 24 locations.
>
> That was just my 0.02€.
Sorry André. Realized after I posted that I'd left some details out.
Each customer is their own <Host>, with their own DB and a few other resources. It's not really one web-app, but a single set of code deployed multiple times.
From the developer's standpoint, they are developing one product, but I need to deploy it as many times as the sales guys sell it. As far as the current deployment method being cumbersome, that's primarily a result of decisions made years ago by a developer who was kept in a bubble in a closet who was provided food through a slot, i.e. really had no idea of real-world deployment issues. As it is, I don't even use war files, as that would require me to build a specific one for each individual customer, because of some of those years-old decisions. I'm trying to get the current team to make adjustment so that war files, or the way above, would be feasible.
Btw: we don't customize things for individual customers in that manner. All custom requests are integrated into product, and if not useful for everyone, we control access via settings outside of code. And I could automate deployment of war files with a Windows bat script that does a couple dozen copy commands and maintain that. Don't wanna.
But, really, I just wanted to know if my original suggestion would cause issues with Tomcat. Essentially, I don't see why I should zip up an app directory structure into a war file, just so Tomcat can unzip it a couple of dozen times.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: generic deployment question
Posted by André Warnier <aw...@ice-sa.com>.
Jeffrey Janner wrote:
> Assume latest Tomcat 6.x for current deployment, and 7.x for future deployments.
>
> I host an app for a couple of dozen customers. Naturally, upgrade time can be a bit of a pain,
why ?
and I'd like to simplify things.
> Assuming that all the customer-specific information (DB connection info, logger info, etc.) can be described as resources in the context.xml file, would it be possible to put the actual webapp in a single pre-exploded directory without causing Tomcat fits?
>
It seems to me that there is a logical problem : if you have only 1 webapp, then you also
only have one context.xml. So how are you going to specify per-customer specific
configurations ?
And even if you do, how will you distinguish a request from one customer from a request
from another customer, and use this information to select the appropriate resource
definition ?
Personally, I tend to think that you are going to trade an small inconvenient (having to
update 24 war files), against a vast complication of your application and setup.
And lose a lot of flexibility too, like if ever one customer wanted this thing just a
little differently..
I am told that there are tools to automate such a multiple deployment, so that you would
only have to give a command once, and it would deploy the same application to 24 locations.
That was just my 0.02€.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: generic deployment question
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Friday, February 17, 2012 2:49 AM
> To: Tomcat Users List
> Subject: Re: generic deployment question
>
> On 16/02/2012 21:12, Jeffrey Janner wrote:
> > Assume latest Tomcat 6.x for current deployment, and 7.x for future
> deployments.
> >
> > I host an app for a couple of dozen customers. Naturally, upgrade
> time can be a bit of a pain, and I'd like to simplify things.
> > Assuming that all the customer-specific information (DB connection
> info, logger info, etc.) can be described as resources in the
> context.xml file, would it be possible to put the actual webapp in a
> single pre-exploded directory without causing Tomcat fits?
> >
> > Example directory tree:
> >
> > Web-app-1.1
> > Images
> > META-INF
> > JSPs
> > WEB-INF (with generic web.xml for web-app-1.1)
> > lib
> > classes
> >
> > ROOT.xml:
> > <?xml version="1.0" encoding="UTF-8"?> <Context path=""
> > docBase="path/to/Web-app-1.1">
>
> The 'path' attribute is not valid here.
>
Thanks. It's a left-over artifact from sometime in the past. I'd seen the admonishment on this list before, but never took it to heart, for some reason. Apparently tomcat 6.x just ignores it, but I understand the reasoning.
> > <Valve
> className="org.apache.catalina.authenticator.SSLAuthenticator"
> > securePagesWithPragma="false" />
> > <....resources definitions.... />
> > </Context>
> >
> >
> > Then when a new release comes out, I can deploy the web-app once and
> modify the individual customer's contexts to point to the new release
> path as they choose upgrade (or all at once).
> >
> > And, yes, I know that disk is cheap and I could just do it by
> replacing 3-4 dozen war files nearly as easily. And right now, I'm not
> sure if the future 7.x versioning feature will come in handy as our dev
> staff haven't started investigating 7.x yet.
>
> Disclaimer: I haven't tested to see if it works, but I would try to
> point the docBase to the .war file and allow each customer to have
> their own exploded copy of the .war. I would not share an exploded
> directory.
>
>
> Having said that, in practice I'd probably just deploy 'n' versions of
> the .war anyway. As you say, disk is cheap & this way there's no
> accidents if the application gets damaged.
>
>
> Note, with Tomcat 7.0 the version feature allows you to specify *any*
> string as the version string.
>
> ROOT##v1.0.1-customer-AAAA.war
>
>
> p
>
>
>
> > Jeff
> >
> ______________________________________________________________________
> > ____
> >
I just realized that I'm not sure why I bothered to ask this question.
Currently, for each host, I add a manager.xml file that points to the standard Tomcat webapp/manager directory. I just copy the same file into each host's directory in conf. I haven't had any problems with this setup in years of running it.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: generic deployment question
Posted by Pid <pi...@pidster.com>.
On 16/02/2012 21:12, Jeffrey Janner wrote:
> Assume latest Tomcat 6.x for current deployment, and 7.x for future deployments.
>
> I host an app for a couple of dozen customers. Naturally, upgrade time can be a bit of a pain, and I'd like to simplify things.
> Assuming that all the customer-specific information (DB connection info, logger info, etc.) can be described as resources in the context.xml file, would it be possible to put the actual webapp in a single pre-exploded directory without causing Tomcat fits?
>
> Example directory tree:
>
> Web-app-1.1
> Images
> META-INF
> JSPs
> WEB-INF (with generic web.xml for web-app-1.1)
> lib
> classes
>
> ROOT.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <Context path=""
> docBase="path/to/Web-app-1.1">
The 'path' attribute is not valid here.
> <Valve className="org.apache.catalina.authenticator.SSLAuthenticator"
> securePagesWithPragma="false" />
> <....resources definitions.... />
> </Context>
>
>
> Then when a new release comes out, I can deploy the web-app once and modify the individual customer's contexts to point to the new release path as they choose upgrade (or all at once).
>
> And, yes, I know that disk is cheap and I could just do it by replacing 3-4 dozen war files nearly as easily. And right now, I'm not sure if the future 7.x versioning feature will come in handy as our dev staff haven't started investigating 7.x yet.
Disclaimer: I haven't tested to see if it works, but I would try to
point the docBase to the .war file and allow each customer to have their
own exploded copy of the .war. I would not share an exploded directory.
Having said that, in practice I'd probably just deploy 'n' versions of
the .war anyway. As you say, disk is cheap & this way there's no
accidents if the application gets damaged.
Note, with Tomcat 7.0 the version feature allows you to specify *any*
string as the version string.
ROOT##v1.0.1-customer-AAAA.war
p
> Jeff
> __________________________________________________________________________
>
> Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
>
> If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
>
--
[key:62590808]