On 22/03/2014 16:36, Brian Burch wrote: > 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!
Actually, you may be right as the default servlet taps into Tomcat's internals. You'd need to recreate that. My thinking was start with the default servlet code and extend it to look in external locations as well. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
