Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Embedded Jetty and Angular 6: only rewrite URLs that don`t match any servlet or files

Hi Joakim,

Those are interesting workarounds. I haven't tried the DefaultServlet idea, but I remember you had suggested using the error handler back when i first asked about pushstate in the original thread. I tried several techniques but it didn`t work for me. I actually lost a lot of time trying to find a way to make one that would work. Here's what I had tried:

Note: i used parentheses below to indicate whether or not handlers are set inside the webapp context or chained together at a higher level. The main webapp context has its own error handler built in.

(WebAppContext -> Servlet -> CustomErrorHandler -> ErrorHandlingServlet)
This was your suggestion. I couldn't get it to work because I couldn't figure out how to get the error handling servlet to return the index.html along with the appropriate parameter. Perhaps if you gave us an example as to how to return the index.html file with parameters?   This could work in theory.

Rewrite Handler -> (WebAppContext -> Servlet -> DefaultErrorHandler)
This didn't work because we can't do conditional handling in the rewriter. Images and servlet would all return the contents of index.html.  There is no support for conditional rewriting on Jetty.

(WebAppContext -> Servlet -> DefaultErrorHandler) -> RewriteHandler -> WebAppContext...
While this would fix my earlier problem of not being able to feed the rewritten path in the file server, this didn't work because the error handler would stop the chain.

(WebAppContext -> Servlet -> null error handler) -> RewriteHandler -> WebAppContext...
This didn't work because the Default error handler would still stop the chain. If error handler is null, the code for WebAppContext instantiates a DefaultErrorHandler automatically. 

(WebAppContext -> Servlet ->  CustomPassthroughErrorHandler ) -> RewriteHandler -> WebAppContext...  
In this attempt, i created a custom error handler which would ignore errors and let them trough so the chain can keep going. Jetty has a loop detection thing that prevents feeding the path back into the same context.

(WebAppContext with no welcome page -> Servlet -> CustomPassthroughErrorHandler) -> Rewrite Handler -> CustomAngularContext... 
In this attempt, I was trying to separate Servlet contexts from File contexts so that Jetty would no longer view this as a loop. I think at that point I felt this was becoming ridiculous so I decided to write the conditional rewrite handler. I felt a conditional rewriter was not only simpler but also a better design because it does what it is meant to do.

By the way, in retrospective, I think the fact that the webapp context automatically instantiates a default error handler if the handler is null, that could be a design issue... 


Seems like searches to fix this kind of problems on Java servers is trending. I ran a new search today, and I found this new example example for JBoss Wildfly server which also performs rewriting. Interestingly enough, they too have support for conditional rewriting, see the xml section which checks that the requested resource is neither a real file or servlet path:

On Fri, Nov 30, 2018 at 2:40 PM Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
"rewrite URLs that don`t match any servlet or files"

Why not just have a Error handler on status code 404 instead?
This is the easiest approach.
Make it return whatever you want, rewrite it, etc...

Alternatively, if you don't rely on welcome files, you could map your welcome files to a servlet name.
That way it runs if the incoming path doesn't match a servlet, and not a directly mentioned static file name.
Make your servlet do what you need.

Option 3 is to provide your own DefaultServlet behavior (mapped to `<url-pattern>/</url-pattern>`.
Lets call this MyDefaultServlet.
If you get called, then you'll know that you have matched no Servlets.
Then it's just a matter of returning the static file (if it exists), or rewriting the URL it that doesn't match.
Check out the code for DefaultServlet, you'll essentially want to have a different doGet()

protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
    {
        if(!_resourceService.doGet(request,response))
        {
            // didn't serve a static file, do your special logic here.
            response.sendRedirect("/other/path/that/I/want/to/rewrite/to");
         }
    }




Joakim Erdfelt / joakim@xxxxxxxxxxx


On Fri, Nov 30, 2018 at 12:49 PM PETER CURRIVAN <Peter.Currivan@xxxxxxxxxxxx> wrote:

Nicolas Therrien et al.,

 

Thank you for sharing your custom RewriteHandler for use with Angular 6 routing.  I am having trouble using it, however, because I am using XML configuration (non-embedded Jetty).  My problem is I do not know how to access a reference to the WebAppContext in my jetty-rewrite.xml file.  Whereas you have instantiated the WebAppContext and the Html5PushStateConditionalRewriteHandler in a single Java file, and can simply pass the reference, I am seemingly forced to configure these objects in separate Jetty IoC XML files (jetty-web.xml configures the WebAppContext and jett-rewrite.xml configures the Html5PushStateConditionalRewriteHandler).

 

Do you (or anyone else reading this) know a way I might access a reference to the WebAppContext configured in jetty-web.xml from within jetty-rewrite.xml?  Or perhaps another way to access the “mappedServlet” within the custom RewriteHandler?

 

I tried adding an id to the WebAppContext in jetty-web.xml and using a Ref tag in jetty-rewrite.xml but the reference comes back null.

 

jetty-web.xml:

<Configure id="webAppContext" class="org.eclipse.jetty.webapp.WebAppContext">

 

jetty-rewrite.xml:

<Configure id="Server" class="org.eclipse.jetty.server.Server">

  <Call name="insertHandler">

    <Arg>

      <New class="my.package.Html5PushStateConditionalRewriteHandler">

        <Arg name="webAppContext"><Ref refid="webAppContext"/></Arg>

 

Thanks,

Peter Currivan

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_jetty-2Dusers&d=DwICAg&c=q3cDpHe1hF8lXU5EFjNM_A&r=P3_1pTtMQK06fFymYIWbyyzVU6nc0CcwfuZhLhexammvaiCaU0ieHeI7BWvfbbjE&m=8a8S9CvgexbMN-nlNHHhSLKVeBwDHVUoicIYnYp94o4&s=cvfmhyimKnCzxfDd7CU8RsY9A_ieVbWEgwoqMyTdmcQ&e=

Back to the top