I'm not sure I understood your question, but I'm going to answer anyway
What we do is have different web-app-deploy paths, like this:
<host id="" root-directory=".">
<web-app id="/" document-directory="app1/app1"/>
"Host" can be a child of "cluster" so changing things in the app1
webapps directory should not affect any other cluster (or host?)
The above assumes an "app1.war" file in the app1 directory, BTW.
Daniel Lopez wrote:
> Interesting. One question though, if I edit the config file and modify one
> of the cluster blocks, to add a new app for example, is Resin smart enough
> to just restart that specific cluster or will it restart all the instances
> due to the new timestamp of the config file? I guess it is the latter, as
> detecting changes in the config file, checking if they affect one or more
> instances etc... might be an overkill.
> In that case, we would still need different config files as we specify the
> context mappings explicitely, instead of using webapps default mapping, and
> restarting 7-8 instances due to a change in one of the mappings would not
> work for us. But I understand we are kind of a strange usecase, with ~25
> different webapps on 6-7 instances with no clustering.
> Scott Ferguson wrote:
>>> And as Jose said, you don't need two copies of the whole Resin
>>> just two config files so you don't have to worry about
>>> maintaing/upgrading two full instances.
>> FYI, in Resin 3.1 you could just use one config file and have two
>> separate <cluster> blocks. The -server foo will select which
>> <cluster> will be active for that JVM.
>> -- Scott
> resin-interest mailing list
resin-interest mailing list