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]
