Hi,
I've added context.xml support for GlassFish. You can define your
context.xml as follows.
1. Global context.xml <ex. glassfish/domains/domain1/config/context.xml>
which will be loaded by all webapps.
2. Virtual server context.xml specified by virtual-server property
"contextXmlDefault" in domain.xml will be loaded by all webapps of this
virtual server.
<virtual-server id="server" ... >
<property name="contextXmlDefault" value="config/context.xml.default"/>
</virtual-server>
3. Webapp context.xml </META-INF/context.xml> will be loaded by this
webapp only.
Cheers,
Amy
roger.keays wrote:
> Hi Jan,
>
>
> Jan Luehe wrote:
>
>>>>+ "Configure same webapp differently". Hum...how do you do that in
>
> Tomcat?
>
>>>>
>>>>
>>>
>>>In tomcat I can create and configure contexts with individual context.xml
>>>files for each virtual host or in conf/server.xml like this:
>>>
>>>(host1)
>>> <Context path=""
>>>docBase="${catalina.home}/server/webapps/figbird-2.0.x">
>>> <Environment name="configFile" value="/tmp/host1.properties"
>>> type="java.lang.String" override="false"/>
>>> </Context>
>>>
>>>(host2)
>>> <Context path=""
>>>docBase="${catalina.home}/server/webapps/figbird-2.0.x">
>>> <Environment name="configFile" value="tmp/host2.properties"
>>> type="java.lang.String" override="false"/>
>>> </Context>
>>>
>>>
>>
>>How important do you consider this feature?
>>
>>I would have expected that in most cases, ISPs will host different (as
>>opposed to differently configured) webapps on different virtual
>>servers.
>>
>>Would you agree? If so, can we reduce the priority (currently P1) of
>>this feature?
>>
>
> Well, that's just my use case I suppose, although I don't think it is
> entirely uncommon. For example, an ISP would probably want to make a manager
> application available to all virtual hosts. Tomcat's manager doesn't need to
> be configured for each host, but this might still be useful.
>
> P1 does sound a bit high for this feature, but that really depends on what
> other jobs are on the task list.
>
> Having this feature would definitely take me one step closer to replacing
> tomcat with glassfish, but it still needs to be manageable in a shared
> environment which is something I haven't studied thoroughly. I'd be
> interested in experimenting with this though: e.g. Is there a market for
> shared Java EE hosting? Can a complete virtual server service be provided
> with EJBs *and* servlets? Can the manager app be secured and shared? What
> CPU and memory resources would be required? etc etc
>
> I'm currently selling shared Tomcat hosting through Gecko Hosting
> (http://www.geckohosting.com.au).
>
> Roger