FAQ

[Tomcat-users] generic deployment question

Jeffrey Janner
Feb 16, 2012 at 9:12 pm
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.
reply

Search Discussions

19 responses

  • André Warnier at Feb 16, 2012 at 9:32 pm

    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
  • Jeffrey Janner at Feb 17, 2012 at 3:07 pm

    -----Original Message-----
    From: André Warnier
    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.
  • Caldarale, Charles R at Feb 17, 2012 at 3:22 pm

    From: Jeffrey Janner
    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.
  • Jeffrey Janner at Feb 17, 2012 at 3:40 pm

    -----Original Message-----
    From: Caldarale, Charles R
    Sent: Friday, February 17, 2012 9:22 AM
    To: Tomcat Users List
    Subject: RE: generic deployment question
    From: Jeffrey Janner
    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.
  • Christopher Schultz at Feb 17, 2012 at 3:45 pm
    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


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at Feb 17, 2012 at 8:49 am

    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]
  • Jeffrey Janner at Feb 17, 2012 at 3:52 pm

    -----Original Message-----
    From: Pid
    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
  • Christopher Schultz at Feb 17, 2012 at 3:36 pm
    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


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Christopher Schultz at Feb 17, 2012 at 3:42 pm
    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


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Jeffrey Janner at Feb 17, 2012 at 3:51 pm

    -----Original Message-----
    From: Christopher Schultz
    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.
  • Jeffrey Janner at Feb 17, 2012 at 3:51 pm

    -----Original Message-----
    From: Christopher Schultz
    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.
  • Christopher Schultz at Feb 17, 2012 at 3:59 pm
    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


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Terence M. Bandoian at Feb 18, 2012 at 11:12 pm

    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
  • Jeffrey Janner at Feb 21, 2012 at 4:01 pm

    -----Original Message-----
    From: Terence M. Bandoian
    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
  • Terence M. Bandoian at Feb 22, 2012 at 5:30 am

    On 1:59 PM, Jeffrey Janner wrote:
    -----Original Message-----
    From: Terence M. Bandoian
    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
  • Pae Choi at Feb 18, 2012 at 9:57 pm
    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
  • Mark Thomas at Feb 18, 2012 at 10:17 pm

    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
  • Pae Choi at Feb 19, 2012 at 8:58 am

    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
  • Konstantin Kolinko at Feb 19, 2012 at 12:06 am

    2012/2/17 Jeffrey Janner <Jeffrey.Janner@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

Related Discussions