glassfish_at_javadesktop.org wrote:
>First, the goal. The goal is to have a EAR, and within that EAR to have root WAR who's docroot is outside of the deployment.
>
>This will allow me to redeploy the EAR easily without risking obliterating the content stored in the docroot.
>
>So, simply, I want to have an EAR where the root content is served in some specified, chosen installation location, that is seperate from where the EAR is normally deployed.
>
>Certainly, any other WARs in the EAR will be mapped to their respective context roots, but those are standalone wars.
>
>I tried this is a simple WAR:
>
> <property name="alternatedocroot_1" value="from=/* dir=/tmp/vstest">
> <description>/tmp/vstest</description>
> </property>
>
>But, the "/*" path is obviously relative to the context root, not the server root.
>
>So, I next changed to <context-root>/</context-root> in the WAR.
>
>This works, it serves up a x.jsp from /tmp/vstest.
>
>However, when I create the file WEB-INF/tags/mytag.tag in /tmp/vstest, and add a call to mytag in the JSP, it dies with an NPE from the JSP compiler. I don't know if this is a bug or not (but I filed one anyway -- 3210)
>
>Now, there is the virtual sever docroot that exists. (Taken from a default install)
>
>[code]
> <virtual-server hosts="${com.sun.aas.hostName}"
> http-listeners="http-listener-1,http-listener-2" id="server"
> log-file="${com.sun.aas.instanceRoot}/logs/server.log"
> state="on">
> <property name="docroot" value="${com.sun.aas.instanceRoot}/docroot"/>
> <property name="accesslog" value="${com.sun.aas.instanceRoot}/logs/access"/>
> <property name="sso-enabled" value="false"/>
> </virtual-server>
>[/code]
>
>I use that in another instance for simple static content, and it works fine.
>
>I also tried my Tag file experiment, and it worked fine as well.
>
>My question is this:
>
>Is the VS docroot just simply a webapp? An exploded WAR?
>
>What hierarchy is it loaded under? I'm assuming that if I deploy an EAR with some EJBs, then the docroot WAR (for lack of a better term) can not see any local EJBs deployed in that EAR? That it can only see Remote EJBs?
>
>But, in theory, I can mark my EJBs somehow to "pass by reference" (something like that) so that same JVM remote calls are effectively local calls, just using a different interface (BeanRemote vs BeanLocal).
>
>That seems to me like a nice panacea, simply leveraging the docroot of the VS. It would be nice if I can have an embedded WAR in my EAR, but this is a decent enough workaround.
>
>So, will this work? More specifically, is it DESIGNED to work like this? Can I treat the VS docroot as a "free" WAR, where I can put things in the proper places (WEB-INF/classes, WEB-INF/web.xml, etc.) Can I rely on this behaviour (so it won't blow up and vanish when y'all hit b53 or whatever and finally get around to "fixing" something).
>
>
I still need to look into the issue you filed, but here's an initial
reply in the meantime:
Internally, we represent a virtual server's docroot and the resources
stored in it as a "dummy" web module, which inherits the configuration
(including the declarations of the DefaultServlet and JspServlet) from
the domain's default-web.xml, but no other servlet mappings are
supported for this "dummy" web module. In other words, even if you
provided a WEB-INF/web.xml resource inside the virtual server's
docroot, it would be ignored.
Jan
>[Message sent by forum member 'whartung' (whartung)]
>
>http://forums.java.net/jive/thread.jspa?messageID=222624
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>