On 22/03/14 13:10, Martin Gainty wrote:
Hi Brian
I *think* what youre looking for in JSPWiki Page *Aliases* located here:
Thanks for spending time thinking about my question, Martin.
Unfortunately, Mark snipped out my original description of the problem
and I didn't put it back in my reply. The JSPWiki Page Alias feature is
not relevant to the problem I was trying to solve.
http://www.ecyrd.com/JSPWiki/wiki/PageAlias
That is the OLD JSPWiki web site, which was frozen several months ago
and is now read-only. There was some discussion about taking it
completely offline in case it confused people, but in the end the devs
decided to keep it online as a historical archive because the new web
site does not have the same content.
JSPWiki has now been adopted as an apache project, and its new web site
is here:
https://jspwiki-wiki.apache.org/
The PageAlias page no longer exists on the new wiki. I'm sorry to say I
have no idea whether the feature was lost in conversion to an apache
project - a lot of contributed code simply will not work until it is
changed to use the new project package names.
http://tomcat.apache.org/whichversion.html
Tomcat 7 supports Servlet Spec 3.x
but Tomcat 6 now conforms to Servlet Spec 2.5
...since Servlet-Spec-2.5 is supported by JSPWiki
http://www.ecyrd.com/JSPWiki/wiki/JSPWikiDownload
you *should* be ok implementing JSPWiki with TC 6
I am using tomcat 7.0.52 on ubuntu linux i386 and openjdk7. I was
referring to the servlet 3.0 docs.
The latest download for JSPWiki is at:
http://www.apache.org/dyn/closer.cgi/jspwiki
The latest version is 2.10, but I am working against the latest trunk.
Brian
HTH,
Martin
______________________________________________
> Date: Sat, 22 Mar 2014 12:25:38 +0000
> From: br...@pingtoo.com
> To: users@tomcat.apache.org
> Subject: Re: Configuration of Default Servlet for a single Container?
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
