Skip to main content

[webtier] Re: Problem wen using "Default Web Module" & docroot

1 reply [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jan Luehe

Hi Ralph,

On 01/12/09 11:00, wrote:
> Hi Jan,
> we played around with alternate-docroots today but we did not succeed.
> What we have done was to add an alternatedocroot to our virtual server configuration as followed:
> alternatedocroot_1 from=/tiny_mce/* dir=/docroot/tiny_mce
> But this is not working. Is the configuration wrong?
> With "/docroot" we try addressing the default docroot of our glassfish where tiny_mce is still located.
> Should we change the value to something like:
> from=/tiny_mce/* dir=${com.sun.aas.instanceRoot}/docroot
> or should we give a full filepath like /usr/glassfish/domain/domain1/docroot ?
> tiny_mce is currently located in the default docroot of our glassfish domain1
> In this Thread:
> you explain that a default-web-module of a virtual server shadows the alternate-doc-roots.
> has this changed in the currend V2 release?
> Thanks for help
> Ralph

If I understood your original request correctly, you wanted to be able
to have multiple webapps share resources located in the virtual
server's docroot.

However, as soon as you declared one of the webapps to be the virtual
server's default web module, those resources were no longer
accessible, and I explained that this was the expected behaviour,
since a default web module "hides" the docroot of its virtual server.

In order to make it possible for multiple webapps to share resources
even in the case where one of them has been "promoted" to a default
web module, I suggested that you consider using alternate docroots,
but you would have to configure them at the webapp level (for each of
your webapps), because a virtual server's docroot and alternate
docroots will be ignored as soon as you have configured a default web
module (as you found out).

Alternate docroots for webapps may be configured inside sun-web.xml,
but you expressed some concern about hard-coding them inside a
deployment descriptor. Unfortunately, I don't see any way around this
at the moment. One possible enhancement we might consider is to
provide a default-sun-web.xml at the domain level (much like we do for
default-web.xml), whose configuration (including alternate docroots)
would be shared across all deployed webapps.



> [Message sent by forum member 'rsoika' (rsoika)]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail: