You both could consider using Ant, which would enable you to write a
script to deploy an application and execute whichever renaming scheme
you wish to, as you do so.
Tomcat/bin contains 'catalina-tasks.xml', which defines some JMX task
definitions which provide the necessary functions.
p
[EMAIL PROTECTED] wrote:
> Hi,
>
> I posted a similar problem with subject "Context deletion on redeploy", but
> got no answer.
>
> I also have to deploy the same war many times without modification with
> different settings. I can't use JNDI because the app's context.xml gets
> deleted from conf/Catalina/localhost at every redeployment. So I lose the app
> specific JNDI settings done by the administrator.
>
> I think I do something wrong, because using JNDI has no sense with that
> behaviour.
>
> Thanks for any help,
> Balázs
>
> On 2007-09-11 Tuesday 23:42, Arnone, Anthony wrote:
>> What I'm trying to do is a slightly strange. Let me see if I can explain it
>> a different way.
>>
>> I'd like to be able to use Tomcat's auto deploy feature of the manager to
>> simply copy the war into the webapps directory, and have the context come
>> up correctly with its solr home set appropriate to its deploy-time name.
>> Something like this:
>>
>> $ cp solr-master.war ${CATALINA_HOME}/webapps/solr-001.war
>> $ cp solr-master.war ${CATALINA_HOME}/webapps/solr-002.war
>>
>> and then have access to
>>
>> http://localhost:8080/solr-001/
>> http://localhost:8080/solr-002/
>>
>> Essentially, I might not have access to ant at deploy time, nor have the
>> ability to change the master war itself. This means that I won't be able to
>> change the context.xml or the web.xml files, since they will already be
>> packaged inside the war archive. So, is there some way to generic-ify the
>> context fragment?
>>
>> Anthony
>>
>>
>>
>> -----Original Message-----
>> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, September 11, 2007 3:30 PM
>> To: Tomcat Users List
>> Subject: Re: context-relative path in JNDI variables
>>
>> Anthony,
>>
>> Arnone, Anthony wrote:
>>> I’m trying to set a system where I can deploy a single .war under
>>> multiple context names (using the ant deploy extensions).
>> Ooh! I love these things.
>>
>>> ant -Ddeploy-path=/app-01 deploy
>>>
>>> ant -Ddeploy-path=/app-02 deploy
>> How about:
>>
>> ant -Dcontext-name=app-01 deploy
>> ant -Dcontext-name=app-02 deploy
>>
>>> <Context>
>>>
>>> <Environment name="solr/home" type="java.lang.String"
>>> value="webapps/${context.name}/app-01/solr/" override="true" />
>>>
>>> </Context>
>> Then you can just use:
>>
>> <Environment
>> name="solr/home"
>> type="java.lang.String"
>> value="webapps/${context-name}/solr/"
>> override="true" />
>>
>> Make sure that you turn on the appropriate filter when copying (or
>> generating) your context.xml file so that ${context-name} gets expanded.
>>
>>> <env-entry>
>>>
>>> <env-entry-name>solr/home</env-entry-name>
>>>
>>> <env-entry-type>java.lang.String</env-entry-type>
>>>
>>> <env-entry-value>
>>> webapps/${context.name}/app-01/solr/</env-entry-value>
>>>
>>> </env-entry>
>> Using web.xml might be a little bit more platform-neutral. The strategy
>> would be the same.
>>
>>> This allows for a much simpler deployment, where
>>> no context.xml needs to be generated and packaged into the war at
>>> deploy time.
>> Really? How do you deploy a WAR file without a context.xml file? Or, do
>> you not need Tomcat to provide anything specific like a JNDI data source?
>>
>>> Unfortunately, as far as I know, a variable like this
>>> does not exist. So my question is this, is there a way to specify a
>>> variable like this relative to the context root?
>> No, but you can just change the way you think about the variable and
>> alter your scripts accordingly.
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
