glassfish_at_javadesktop.org wrote:
>I have some questions about the GF2 Virtual Server, specifically the alternate docroots functionality.
>
>To be blunt, here's what I want to do.
>
>I want to be able to deploy a WAR file to the server, just like any other WAR file, but I also want to be able to have the user add content to the system.
>
>When a WAR is deployed, the file is exploded in to a working directory, and the content is served from there.
>
>A crude mechanism to do what I want to do would be for the client custom content (static htmls, images, pdfs, perhaps even JSPs) to be copied in to the newly exploded directory.
>
>But, when you redeploy the WAR (via Netbeans, or through the console), POOF, there goes all of the clients content. Unhappy client.
>
>Another technique is to specify the deployment directory within the domain.xml, and simply explode the WAR by hand in to the directory, mixing WAR content with Client content.
>
>But now you can't (I don't believe) use NB or the console to do the deploy. Plus, one missed click in the admin console (say, undeploying the web app), and BOOM, there goes the app and the custom content. Unhappy client, unhappy developer.
>
>What I'm doing now, is I have the custom content in a seperate directory away from the web app, and then I have a filter for every request. If the URL maps to the custom client, I copy the file from the storage "master" area into the deployed web app directory, and then forward to the URL letting the server serve the file up to the client.
>
>This isn't SO bad, save that all of the content is duplicated (disk space, but big deal). Plus, I need a filter anyway for security purposes.
>
>BUT, it IS code that I have to write. And, genuflecting in Larry Walls direction, programmers are lazy.
>
>So, it SEEMS that with the new alternate docroot capability, Glassfish will do this FOR me.
>
>
>Is that true?
>
Yes.
>Can I have in my WAR, bound to the root context, the files /a.html, /b.html, /c.html and then mount an alternate docroot, also on "/", containing /d.html and /e.html, and when the request comes in, the server will look in my WAR first, and then the alternate second?
>
>So, these would all be valid urls:
>
>http://host/a.html
>http://host/b.html
>http://host/d.html
>http://host/e.html
>
>
Once a request has been mapped to the url-pattern of an alternate
docroot, it will be served from the alternate docroot only, and the
regular docroot will not be considered for this request.
Therefore, if your webapp contains resources a.html, b.html, c.html,
d.html, and e.html, and you want a.html, b.html, and c.html to be
looked up in the normal docroot, and d.html and e.html to be served
from an alternate docroot, you need to specify alternate docroot properties
for d.html and e.html in your sun-web.xml, as follows:
<sun-web-app>
<property name="alternatedocroot_1" value="from=/d.html
dir=<alternate-docroot-1>"/>
<property name="alternatedocroot_2" value="from=/e.html
dir=<alternate-docroot-2>"/>
</sun-web-app>
where <alternate-docroot-1> and <alternate-docroot-2>, which may be
identical, are replaced
with the alternate docroot's physical location.
>Will this work for JSPs? Can I add a JSP in to the alternate docroot, and the container will automagically compile and serve them up as if they were part of my web app (including accessing jars deployed in my web app)?
>
>
Yes.
>Finally, will it work for JSP 2.0 tag files?
>
>i.e. can I have the following files:
>
>$wardeploydir/WEB-INF/tags/tag1.jsp
>$alternateroot/WEB-INF/tags/tag2.jsp
>$alternateroot/test.jsp <-- has a <%_at_taglib prefix="t" tagdir="/WEB-INF/tags"%> header and uses both tag1 and tag2
>
>
It should work in principle (since the JSP compiler uses
ServletContext.getResource(), which considers
alternate docroots, to load a requested JSP page or tag file), but I
have not tested it.
>And will all of the urls, regardless of whether they're sourced from the WAR or from the alternate docroot, go through the standard filtering mechanism?
>
>
Yes.
Jan
>I know this hasn't anything to do with the JEE or Servlet spec, and rather it's value add of the GF container. But that's fine in my book, it's good that GF is getting solid on the spec and now going for value add to distinguish itself from other containers.
>
>I am already using the virtual server capability. Using it to serve up a generic static HTML web site alongside my web apps, and that works peachy (though I'm curious whether I can CGI enable it, like a generic apache site). It's nice that we're able to use GF and a standalone web and app server.
>
>But now I'd like to leverage this part, and I was hoping that it will work for me. Otherwise, it's back to my filter.
>[Message sent by forum member 'whartung' (whartung)]
>
>http://forums.java.net/jive/thread.jspa?messageID=219598
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>