On 31/01/14 13:27, Brian Burch wrote:
On 31/01/14 12:48, Mark Thomas wrote:
On 31/01/2014 12:42, Brian Burch wrote:
Have I overlooked a configuration trick that would allow me to use the
webapp without a symlink, but still have the Default Servlet access
external static content as if it were internal?
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes
aliases?
Thanks very much, as always, for your rapid response. I will follow that
link with interest.
If you switch to Tomcat 8, you get a cleaner implementation and much
more control with the new resources implementation.
I'll get back to you if I don't understand, but otherwise, thanks very
much,
This task finally arrived near the top of my list. I started by looking
at org.apache.catalina.core.TestStandardContextAliases, which was very
helpful. So was the javadoc for
org.apache.catalina.core.StandardContext.setAliases(String).
I then thought about extending my existing logic to support both the
existing "internal" and the new "external" directory trees. I thought I
had a viable approach, but have hit an implementation issue that does
not seem to have an elegant, lightweight solution.
JSPWiki is not intended to be dependent on tomcat, so it should only use
services defined in the sevlet api. My existing plugin currently follows
this constraint, and I would like to do the same with my enhancement.
Unfortunately, the setAliases method is not inherited from
javax.servlet.ServletContext and I couldn't find any reference to
aliases in the Servlet 3.0 api docs. Am I correct in concluding it is a
tomcat-only feature?
If it is tomcat-only, then my enhancement would not be available under
any other flavour of webapp container. Worse still, I can't simply cast
the execution Context to a StandardContext. I'll have to write
introspection code to avoid a ClassNotFoundException when the plugin is
loaded during deployment of the JSPWiki war...
Does that sound about right, Mark?
I am prepared to go ahead implementing a tomcat-only feature, but I
would like to be sure it is the only or best solution before doing a lot
of work.
Thanks...
Brian
Brian
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
