On 22/03/14 14:05, Mark Thomas wrote:
On 22/03/2014 12:25, Brian Burch wrote:
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?
Correct. Worse still, that API changed completely between Tomcat 7 and
Tomcat 8.
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'm afraid so.
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.
Given the work that is likely to be involved I think you are likely to
be better off writing your own default servlet. That will be container
neutral.
I had not thought of that approach... are you sure it would be helpful?
Surely I couldn't do anything more than is already done by the
DefaultServlet, which I implicitly use to serve up the JPG and PNG files?
I don't immediately see how rolling my own would get me nearer than the
DefaultServlet, i.e. allow me to have access to resources outside the
webapp container in an OS-neutral manner.
Did you mean:
a) derive the absolute path to the image file (I can do that already).
b) create a File to the resource (which is outside the container).
c) read the contents and process the metadata of the file.
d) deal with any security issues not handled by the file system
permissions mechanism.
e) deliver it to the HTTP client.
That doesn't sound like an "easy" option to me!
I'd hope that Servlet 3.2 will include some form of the aliases feature
but it is not certain.
Thanks for working through my question so carefully, Mark. As usual,
your accurate and helpful advice is very valuable and has saved me a lot
of unproductive work.
Regards,
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
