Thoughts after migrating from Rewrite v1 to v2

Splash Forums Rewrite Users Thoughts after migrating from Rewrite v1 to v2

This topic contains 13 replies, has 3 voices, and was last updated by  Lincoln Baxter III 3 years, 2 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
  • #23971


    My app is EE6 using CDI, JSF2.1 and Rewrite, and running on Glassfish. Let me share my thoughts after migrating from Rewrite 1.1.0 to 2.0.1, maybe some other people will find this useful.

    1) com.ocpsoft.rewrite.config.ConfigurationProvider is now org.ocpsoft.rewrite.config.ConfigurationProvider

    2) rewrite servlet dependency had to be changed in pom.xml




    3) THANKS there is no more stupid “hard” dependency on seam-security and its cascade of stupid (yes stupid) behavior-changing transient dependencies such as seam-transaction and seam-persistence. No transient inclusion of Picketlink that I didn’t use either, and no need to include joda-time anymore. Really, thanks, you made Rewrite EASILY useable without side-effects in a serious app.

    4) Rules changed a little, for example: .addRule(Join.path("/news/id/{id}/").to("/public/blogList.jsf").where("id").bindsTo("", LongConverter.class)))) //my backing bean id is a Long...



    5) Within these rules if you previously had mistakenly set a non-matching param (eg


    There was no error, now the filter refuses to instantiate and the stacktrace says what’s wrong. Good, however…

    6) …a Rewrite 2 stacktrace is logged on one line only. Very annoying.

    SEVERE: Error Rendering View[/index.xhtml]java.lang.NullPointerException	at org.ocpsoft.rewrite.servlet.config.Path.evaluateHttp(	at org.ocpsoft.rewrite.servlet.config.HttpCondition.evaluate(	at org.ocpsoft.rewrite.servlet.config.rule.Join.evaluate(	at

    Though the same happens with other glassfish errors (eg hk2 ones) so I’m not sure this is a Rewrite issue here.

    7) Without changing my rules, I now get NullPointerException at org.ocpsoft.rewrite.servlet.config.Path.evaluateHttp( which didn’t hapen before.

    This happens when the page renders an h:outputLink that has params, and the stacktrace doesn’t help you finding out at all.

    OK link params are not supposed to be present with pretty urls, but I had written a specific component replacing h:outputLink where one could specify both a pretty and a non-pretty value and globally choose to render one or the other. I think Rewrite could be more lenient there and ignore unnecessary params as before.

    8) Similarly I got this error I didn’t have before: IllegalStateException: PhaseBinding does not support retrieval. at org.ocpsoft.rewrite.faces.config.PhaseBinding.retrieve(

    This also happens upon OutputLink rendering, but this time with a link in the same page: <h:outputLink value=”#article#{articleId}”>; the intent is to render
    <a href=""#article99"">Article Title</a>
    Workaround: declare the full “pretty” path in the outputlink: <h:outputLink value=”/articles/#article#{}”>. Not sure this is a feature or a bug here.

    9) THANKS one doesn’t have to dig into the sources of SocialPM anymore to find relevant examples!!! There’s a nice examples page now (, but it needs a small refresh (eg Response.setCode() should be replacesd by Response.setStatus())

    Lincoln, Christian, Rewrite is getting better and better, thanks.

    • This topic was modified 3 years, 2 months ago by  fabmars.
    • This topic was modified 3 years, 2 months ago by  fabmars.
    • This topic was modified 3 years, 2 months ago by  Lincoln Baxter III.
    • This topic was modified 3 years, 2 months ago by  Lincoln Baxter III.


    Argh I cannot edit the topic anymore. Addendum:

    8) [..]
    This also happens upon OutputLink rendering, but this time with a link in the same page: <h:outputLink value=”#art#{articleId}”>; the intent is to render a link /context/articles#art99
    Workaround: declare the full “pretty” path in the outputlink: <h:outputLink value=”/articles/#art#{articleId}”>. I suspect there is a bug here.

    10) All the rest works like a charm.



    thank you very much for your feedback. I think this will be very handy for others migrating to Rewrite 2.0.x.

    We should really create some kind of migration guide. And you post could be the first start for this.

    A few notes regarding you post:

    2) I think rewrite-servlet already existed before. Actually this artifact is an aggregation of other artifacts like rewrite-impl-servlet. But including rewrite-servlet is the recommended way.

    6) It is weird that exceptions aren’t logged correctly. By default Rewrite logs to java.util.logging. Perhaps you could try to add one of the logging adapters like the one for SLF4J. After adding the adapter, Rewrite will log to SLF4J instead. Perhaps this will fix the problem:

    7) Could you update to 2.0.2.Final a check if this still happens?

    8) You are using a h:outputLink to render a link that just links to an anchor on the same page. But I’m not sure what this exception is caused by exactly. But you can easily work around this by manually rendering the link, which would also be good for performance reasons because you component tree will be smaller:

    <a href="#article#{articleId}">link</a>



    Hi and thanks for your answer,

    2) maybe, so it means i had misconfigured Rewrite1 before. OK.

    6) I tried, nothing changed. All there was to do was to add this in the pom right ?

    7) I think you meant 2.0.2-SNAPSHOT. By the way, note the snapshots repo written in the Rewrite frontpage has changed, leads nowhere whereas (or seems to be the right ones now, whilst is the one dedicated to releases.

    Anyway, I tried with 2.0.2-SNAPSHOT from June 2nd, and indeed the behavior is different. For:
    <h:outputLink value=”#{facesContext.externalContext.requestContextPath}/news”>
    <f:param name=”id” value=”#{}” />
    <h:outputText value=”#{entry.title}”/>
    I get the output link: http://localhost:8080/context/news?id=123 which is fair enough. Thanks.

    8) You’re totally right. Fact is my app was built at the time of JSF1.x where this wasn’t allowed. I’ll change it.




    11) Ah another change I spotted from v1 to v2:, MyConverter.class));
    had to become:;

    I have a question too: how can I retrieve the “pretty” URL eventually displayed in the navigation bar? I need it for SEO purposes.
    For instance <meta property=”og:url” content=”#{request.requestURL}” /> will write the actual .jsf URL to the meta content.

    • This reply was modified 3 years, 2 months ago by  fabmars.

    Hey Fabmars!

    Thanks so much for your detailed feedback. This is great!

    To answer your question, you can use request.getAttribute("javax.servlet.forward.request_uri") to retrieve the original Request URL.

    Fortunately, this is built into the Servlet container, so there’s no need to go through Rewrite, but it might be something we can make simpler (and should certainly document it.)



    This logging issue is really weird. Could you post what exactly get on the console if there is an exception. My guess is that the container catches an exception thrown by rewrite. In this case the container is responsible for logging it correctly.



    Lincoln: EXcellent, thanks.

    Christian: I suspect you are right as I saw it happen with hk2 too on Glassfish.
    Here it is:
    This is on Glassfish where I upgraded JSF module to 2.1.22 and Weld module to 1.1.13.

    As far as I’m concerned, the Rewrite “upgrade” is successful and I am so thankful for those seam* dependencies that are now gone (that was bound to happen though as Seam is dying).


    The stacktrace looks weird. What is you code doing here:


    So you are updating the JSF and CDI implementations shipped with Glashfish? I think this could cause some problems. Partial updates of container dependencies are always a bit risky. 🙂



    My code is just building the Rewrite config. It’s a quickly hacked copy/update from a bigger project

    package plop;
    import javax.servlet.ServletContext;
    import org.ocpsoft.rewrite.config.Configuration;
    import org.ocpsoft.rewrite.config.ConfigurationBuilder;
    import org.ocpsoft.rewrite.context.EvaluationContext;
    import org.ocpsoft.rewrite.el.El;
    import org.ocpsoft.rewrite.event.Rewrite;
    import org.ocpsoft.rewrite.param.Converter;
    import org.ocpsoft.rewrite.servlet.config.HttpConfigurationProvider;
    import org.ocpsoft.rewrite.servlet.config.rule.Join;
    public class RewriteConfigProvider extends HttpConfigurationProvider {
      public int priority() {
        return 10;
      public Configuration getConfiguration(ServletContext servletContext) {
        try {
          return buildPrettyConfiguration();
        catch (Exception e) { //don't do that at home...
          return null;
       * Builds the Rewrite config
       * @throws SecurityException 
       * @throws NoSuchFieldException 
      private Configuration buildPrettyConfiguration() {
        return ConfigurationBuilder.begin()
            //then real short urls
    class LongConverter implements Converter<Long> {
      public final static LongConverter INSTANCE = new LongConverter();
      public Long convert(final Rewrite event, final EvaluationContext context, final Object value) {
        if (value == null) {
          throw new IllegalArgumentException("Value to convert cannot be null.");
        return Long.valueOf(value.toString());

    Yes I upgrade containers, but scarcely. I know from the JSF guys there’s no problem upgrading javax.faces.jar and I know the Weld guys don’t change the apis on 1.1 anymore (that would require the GF-weld integration bundle to be upgraded too and that’s where problems start). I’d never have sone that at the time of Weld 1.0.x.

    • This reply was modified 3 years, 2 months ago by  fabmars.
    • This reply was modified 3 years, 2 months ago by  fabmars.

    It’s weird that you are getting this:

    SEVERE: java.lang.NoSuchFieldException: id
            at java.lang.Class.getField(
            at plop.RewriteConfigProvider.buildPrettyConfiguration(

    Is it perhaps caused by the fact that you are binding the parameter to #{}?


    Yeah, this looks suspicious to me. I think that the NoSuchFieldException is probably the root of some kind of issue,



    Don’t worry about that: I’ve been playing with which generated some exceptions. When you asked me to show you some exception, I copied the first one I found, but my config (above) had been cleaned up in the meantime. In other words the exception I gave you doesn’t match the config I gave you, sorry for that.

    The point was to show you these “one line exceptions” anyway. Though if you want me to produce another exception with the matching config, I will do.

    • This reply was modified 3 years, 2 months ago by  fabmars.

    No, that’s OK. From what I can tell, this is not an issue with Rewrite, since we don’t do any special exception handling. This is most likely an issue with the way that the GlassFish container does it’s exception handling and error logging.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

Comments are closed.