Wicket
  1. Wicket
  2. WICKET-4829

ComponentResolvers created in app init ignore markup's namespace

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.2.0
    • Fix Version/s: 6.3.0
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Windows, Java 6.x

      Description

      Initially this problem was occurring in a page with an enclosure and so I thought it was specific to enclosures but on minimalizing the quickstart it is apparent that it happens on any page where a non default namespace is specified AND a href has a relative path.

      The attached quickstart has a single page with no components at all. In 6.x the page fails if a non default namespace is specified in the <html> tag. This works fine in 1.4.x and 1.5.x

      <html xmls:foobar>

      causes:

      Last cause: Unable to find component with id 'foobar_relative_path_prefix_' in [HtmlHeaderContainer [Component id = _header_0]]
      Expected: 'header_0.foobar_relative_path_prefix'.
      Found with similar names: ''

      If we remove the non standard namespace declaration from the html element then the page works fine.

      Also, if we remove the line:

      <link rel="stylesheet" href="style.css" type="text/css" media="screen" title="Stylesheet"/>

      from the HomePage.html then the problem doesn't occur.

      Problem could possibly be related to how RelativePathPrefixHanlder deals with a non default namespace.

        Issue Links

          Activity

          Hide
          Chris Colman added a comment -

          Quickstart with a single page and no components demonstrating the problem.

          Show
          Chris Colman added a comment - Quickstart with a single page and no components demonstrating the problem.
          Hide
          Chris Colman added a comment -

          Edit title to reflect new discovery: for the problem to occur you need the link element to have href with a relative path. Remove the link to style.css or make the href an absolute ref and the problem goes away.

          Problem in RelativePathPrefixHanlder?

          Show
          Chris Colman added a comment - Edit title to reflect new discovery: for the problem to occur you need the link element to have href with a relative path. Remove the link to style.css or make the href an absolute ref and the problem goes away. Problem in RelativePathPrefixHanlder?
          Hide
          Chris Colman added a comment -

          I have found the cause of the problem but not sure of the best fix.

          The cause:

          In ComponentResolvers#resolve in both standard and non standard namespace scenarios the resolve process falls back to the resolveByApplication option.

          resolveByApplication uses the application's component resolver collection that was established at application init - obviously none of these have a reference to the current markupStream (which indirectly stores the namespace for the stream) and that is indeed the case for the RelativePathPrefixHandler stored in the application component resolver collection as it is created in "resolver" mode (markupStream == null).

          RelativePathPrefixHander#resolve calls RelativePathPrefixHander#getWicketRelativePathPrefix() which calls the base class' getWicketNamespace() method which, having markupStream == null will always return "wicket" and not the namespace declared for the current markupStream. This is why the component can not be resolved.

          Possibly solution:

          Perhaps RelativePathPrefixHander#getWicketRelativePathPrefix() could take a MarkupStream as a parameter and, if not null return, the namespace associated with that markupStream.

          Show
          Chris Colman added a comment - I have found the cause of the problem but not sure of the best fix. The cause: In ComponentResolvers#resolve in both standard and non standard namespace scenarios the resolve process falls back to the resolveByApplication option. resolveByApplication uses the application's component resolver collection that was established at application init - obviously none of these have a reference to the current markupStream (which indirectly stores the namespace for the stream) and that is indeed the case for the RelativePathPrefixHandler stored in the application component resolver collection as it is created in "resolver" mode (markupStream == null). RelativePathPrefixHander#resolve calls RelativePathPrefixHander#getWicketRelativePathPrefix() which calls the base class' getWicketNamespace() method which, having markupStream == null will always return "wicket" and not the namespace declared for the current markupStream. This is why the component can not be resolved. Possibly solution: Perhaps RelativePathPrefixHander#getWicketRelativePathPrefix() could take a MarkupStream as a parameter and, if not null return, the namespace associated with that markupStream.
          Hide
          Chris Colman added a comment -

          In addition to
          .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\RelativePathPrefixHandler.java

          it looks like the following also call their base class' AbstractMarkupFilter method getWicketNamespace():

          .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\WicketMessageTagHandler.java
          .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\InlineEnclosureHandler.java

          Therefore these will likely suffer from the same problem as they also can be used in "resolver" mode (markupStream == null).

          Given that they all derive from AbstractMarkupFilter it might be best to provide a AbstractMarkupFilter.getWicketNamespace(MarkupStream markupStream) method and make them use that within the context of a resolve operation.

          Show
          Chris Colman added a comment - In addition to .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\RelativePathPrefixHandler.java it looks like the following also call their base class' AbstractMarkupFilter method getWicketNamespace(): .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\WicketMessageTagHandler.java .\wicket-core\src\main\java\org\apache\wicket\markup\parser\filter\InlineEnclosureHandler.java Therefore these will likely suffer from the same problem as they also can be used in "resolver" mode (markupStream == null). Given that they all derive from AbstractMarkupFilter it might be best to provide a AbstractMarkupFilter.getWicketNamespace(MarkupStream markupStream) method and make them use that within the context of a resolve operation.
          Hide
          Chris Colman added a comment - - edited

          I have implemented a fix that works well and is hopefully follows any wicket design guidelines.

          To summarize: some of the markup filters that double as IComponentResolvers make calls to getWicketNamespace. As these application wide IComponentResolvers are essentially "global" they can't store a reference to an individual markup source and so currently have no markup context to use when returning the wicket namespace.

          To remedy this we simply add a new getWicketNamespace method in AbstractMarkupFilter that takes a MarkupStream parameter. The resolve method of these three IComponentResolverS then simply passes in the MarkupStream to getWicketNamespace and the problem is fixed.

          diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java
          index 27779c5..ed4802b 100644
          — a/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java
          +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java
          @@ -23,6 +23,7 @@ import org.apache.wicket.markup.HtmlSpecialTag;
          import org.apache.wicket.markup.Markup;
          import org.apache.wicket.markup.MarkupElement;
          import org.apache.wicket.markup.MarkupParser;
          +import org.apache.wicket.markup.MarkupStream;
          import org.apache.wicket.markup.MarkupResourceStream;
          import org.slf4j.Logger;
          import org.slf4j.LoggerFactory;
          @@ -176,4 +177,21 @@ public abstract class AbstractMarkupFilter implements IMarkupFilter
          }
          return wicketNamespace;
          }
          +
          + /**
          + * @return the namespace of the given markup or loaded markup
          + */
          + protected String getWicketNamespace(MarkupStream markupStream)
          + {
          + String wicketNamespace;
          + if (markupStream != null)
          +

          { + wicketNamespace = markupStream.getWicketNamespace(); + }

          + else
          +

          { + wicketNamespace = getWicketNamespace(); + }

          + return wicketNamespace;
          + }
          }
          diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java
          index f812f76..84a959e 100644
          — a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java
          +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java
          @@ -178,7 +178,7 @@ public final class InlineEnclosureHandler extends AbstractMarkupFilter
          if (Strings.isEmpty(inlineEnclosureChildId) == false)
          {
          String id = tag.getId();

          • if (id.startsWith(getWicketNamespace()))
            + if (id.startsWith(getWicketNamespace(markupStream))) { id = id + container.getPage().getAutoIndex(); }

            diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java
            index 420a881..4f1c593 100644

              • a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java
                +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java
                @@ -141,7 +141,7 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter
                {
                if (tag.getId() == null) { - tag.setId(getWicketRelativePathPrefix()); + tag.setId(getWicketRelativePathPrefix(null)); tag.setAutoComponentTag(true); }

                tag.addBehavior(RELATIVE_PATH_BEHAVIOR);
                @@ -157,7 +157,7 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter
                public Component resolve(final MarkupContainer container, final MarkupStream markupStream,
                final ComponentTag tag)
                {

          • if ((tag != null) && (tag.getId().equals(getWicketRelativePathPrefix())))
            + if ((tag != null) && (tag.getId().equals(getWicketRelativePathPrefix(markupStream)))) { String id = tag.getId() + container.getPage().getAutoIndex(); @@ -169,8 +169,8 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter return null; }
          • private String getWicketRelativePathPrefix()
            + private String getWicketRelativePathPrefix(MarkupStream markupStream) { - return getWicketNamespace() + WICKET_RELATIVE_PATH_PREFIX_CONTAINER_ID; + return getWicketNamespace(markupStream) + WICKET_RELATIVE_PATH_PREFIX_CONTAINER_ID; }

            }
            diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java
            index 65aa1d1..204b21e 100644

              • a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java
                +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java
                @@ -91,7 +91,7 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter
                // if this is a raw tag we need to set the id to something so
                // that wicket will not merge this as raw markup and instead
                // pass it on to a resolver
          • tag.setId(getWicketMessageIdPrefix());
            + tag.setId(getWicketMessageIdPrefix(null));
            tag.setAutoComponentTag(true);
            tag.setModified(true);
            }
            @@ -163,11 +163,11 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter
            public Component resolve(MarkupContainer container, MarkupStream markupStream, ComponentTag tag)
            {
            // localize any raw markup that has wicket:message attrs
          • if ((tag != null) && (tag.getId().startsWith(getWicketMessageIdPrefix())))
            + if ((tag != null) && (tag.getId().startsWith(getWicketMessageIdPrefix(markupStream))))
            {
            Component wc;
            int autoIndex = container.getPage().getAutoIndex();
          • String id = getWicketMessageIdPrefix() + autoIndex;
            + String id = getWicketMessageIdPrefix(markupStream) + autoIndex;

          if (tag.isOpenClose())

          { @@ -189,8 +189,8 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter return wicketNamespace + ':' + "message"; }
          • private String getWicketMessageIdPrefix()
            + private String getWicketMessageIdPrefix(MarkupStream markupStream) { - return getWicketNamespace() + WICKET_MESSAGE_CONTAINER_ID; + return getWicketNamespace(markupStream) + WICKET_MESSAGE_CONTAINER_ID; }

            }

          Show
          Chris Colman added a comment - - edited I have implemented a fix that works well and is hopefully follows any wicket design guidelines. To summarize: some of the markup filters that double as IComponentResolvers make calls to getWicketNamespace. As these application wide IComponentResolvers are essentially "global" they can't store a reference to an individual markup source and so currently have no markup context to use when returning the wicket namespace. To remedy this we simply add a new getWicketNamespace method in AbstractMarkupFilter that takes a MarkupStream parameter. The resolve method of these three IComponentResolverS then simply passes in the MarkupStream to getWicketNamespace and the problem is fixed. diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java index 27779c5..ed4802b 100644 — a/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/AbstractMarkupFilter.java @@ -23,6 +23,7 @@ import org.apache.wicket.markup.HtmlSpecialTag; import org.apache.wicket.markup.Markup; import org.apache.wicket.markup.MarkupElement; import org.apache.wicket.markup.MarkupParser; +import org.apache.wicket.markup.MarkupStream; import org.apache.wicket.markup.MarkupResourceStream; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @@ -176,4 +177,21 @@ public abstract class AbstractMarkupFilter implements IMarkupFilter } return wicketNamespace; } + + /** + * @return the namespace of the given markup or loaded markup + */ + protected String getWicketNamespace(MarkupStream markupStream) + { + String wicketNamespace; + if (markupStream != null) + { + wicketNamespace = markupStream.getWicketNamespace(); + } + else + { + wicketNamespace = getWicketNamespace(); + } + return wicketNamespace; + } } diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java index f812f76..84a959e 100644 — a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/InlineEnclosureHandler.java @@ -178,7 +178,7 @@ public final class InlineEnclosureHandler extends AbstractMarkupFilter if (Strings.isEmpty(inlineEnclosureChildId) == false) { String id = tag.getId(); if (id.startsWith(getWicketNamespace())) + if (id.startsWith(getWicketNamespace(markupStream))) { id = id + container.getPage().getAutoIndex(); } diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java index 420a881..4f1c593 100644 a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/RelativePathPrefixHandler.java @@ -141,7 +141,7 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter { if (tag.getId() == null) { - tag.setId(getWicketRelativePathPrefix()); + tag.setId(getWicketRelativePathPrefix(null)); tag.setAutoComponentTag(true); } tag.addBehavior(RELATIVE_PATH_BEHAVIOR); @@ -157,7 +157,7 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter public Component resolve(final MarkupContainer container, final MarkupStream markupStream, final ComponentTag tag) { if ((tag != null) && (tag.getId().equals(getWicketRelativePathPrefix()))) + if ((tag != null) && (tag.getId().equals(getWicketRelativePathPrefix(markupStream)))) { String id = tag.getId() + container.getPage().getAutoIndex(); @@ -169,8 +169,8 @@ public final class RelativePathPrefixHandler extends AbstractMarkupFilter return null; } private String getWicketRelativePathPrefix() + private String getWicketRelativePathPrefix(MarkupStream markupStream) { - return getWicketNamespace() + WICKET_RELATIVE_PATH_PREFIX_CONTAINER_ID; + return getWicketNamespace(markupStream) + WICKET_RELATIVE_PATH_PREFIX_CONTAINER_ID; } } diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java index 65aa1d1..204b21e 100644 a/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java +++ b/wicket-core/src/main/java/org/apache/wicket/markup/parser/filter/WicketMessageTagHandler.java @@ -91,7 +91,7 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter // if this is a raw tag we need to set the id to something so // that wicket will not merge this as raw markup and instead // pass it on to a resolver tag.setId(getWicketMessageIdPrefix()); + tag.setId(getWicketMessageIdPrefix(null)); tag.setAutoComponentTag(true); tag.setModified(true); } @@ -163,11 +163,11 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter public Component resolve(MarkupContainer container, MarkupStream markupStream, ComponentTag tag) { // localize any raw markup that has wicket:message attrs if ((tag != null) && (tag.getId().startsWith(getWicketMessageIdPrefix()))) + if ((tag != null) && (tag.getId().startsWith(getWicketMessageIdPrefix(markupStream)))) { Component wc; int autoIndex = container.getPage().getAutoIndex(); String id = getWicketMessageIdPrefix() + autoIndex; + String id = getWicketMessageIdPrefix(markupStream) + autoIndex; if (tag.isOpenClose()) { @@ -189,8 +189,8 @@ public final class WicketMessageTagHandler extends AbstractMarkupFilter return wicketNamespace + ':' + "message"; } private String getWicketMessageIdPrefix() + private String getWicketMessageIdPrefix(MarkupStream markupStream) { - return getWicketNamespace() + WICKET_MESSAGE_CONTAINER_ID; + return getWicketNamespace(markupStream) + WICKET_MESSAGE_CONTAINER_ID; } }
          Hide
          Chris Colman added a comment -

          This is an update which adds a tests inline exclosures. HomePage.html is provided with two <html> blocks -one for default namespace and one for non default namespace for easy testing.
          This test works with the patch/diff I have provided.

          Show
          Chris Colman added a comment - This is an update which adds a tests inline exclosures. HomePage.html is provided with two <html> blocks -one for default namespace and one for non default namespace for easy testing. This test works with the patch/diff I have provided.
          Hide
          Sven Meier added a comment -

          Although I wasn't able to apply your patch directly, your changes seems to solve this issue.

          But before we just fix the code, perhaps we improve the whole situation:
          It's unfortunate that AbstractMarkupFilter#markupResourceStream is sometimes set and on other times it's null.
          And InlineEnclosureHandler still has "wicket:" prefix in INLINE_ENCLOSURE_ATTRIBUTE_NAME.

          I wonder why RelativePathPrefixHandler#getWicketRelativePathPrefix() and others even bother to prefix the id with the namespace? The namespace is the same for the whole markup anyway. Wouldn't it be easier just to skip the prefixing?

          Show
          Sven Meier added a comment - Although I wasn't able to apply your patch directly, your changes seems to solve this issue. But before we just fix the code, perhaps we improve the whole situation: It's unfortunate that AbstractMarkupFilter#markupResourceStream is sometimes set and on other times it's null. And InlineEnclosureHandler still has "wicket:" prefix in INLINE_ENCLOSURE_ATTRIBUTE_NAME. I wonder why RelativePathPrefixHandler#getWicketRelativePathPrefix() and others even bother to prefix the id with the namespace? The namespace is the same for the whole markup anyway. Wouldn't it be easier just to skip the prefixing?
          Hide
          Chris Colman added a comment -

          The handlers/filters deriving from AbstractMarkupFilter have dual personalities and they are constructed in one or the other personality. On one hand the filters are actually filters but on the other hand they act as component resolvers. When acting as component resolvers they are used as "globals" by the app and so can't keep a reference to any particular markup as they are reused in the rendering of many different markups - this explains why markupResourceStream must be null when constructed in "ComponentResolver" mode. I don't think we can avoid that while ever rendering requires the use of the application wide, and therefore shared, collection of IComponentResolvers.

          I think the reason the namespace is used in the id is because even though the namespace is the same for any one markup, markup inheritance (extend/child) means that you can be performing a render across multiple markups which could have different namespaces. I'm not sure if that would be a problem in this case where the component resolution is all bound to within the rendering of a single markup. I don't know but there may be complex markup inheritance usage where not having the namespace could be a problem.

          Show
          Chris Colman added a comment - The handlers/filters deriving from AbstractMarkupFilter have dual personalities and they are constructed in one or the other personality. On one hand the filters are actually filters but on the other hand they act as component resolvers. When acting as component resolvers they are used as "globals" by the app and so can't keep a reference to any particular markup as they are reused in the rendering of many different markups - this explains why markupResourceStream must be null when constructed in "ComponentResolver" mode. I don't think we can avoid that while ever rendering requires the use of the application wide, and therefore shared, collection of IComponentResolvers. I think the reason the namespace is used in the id is because even though the namespace is the same for any one markup, markup inheritance (extend/child) means that you can be performing a render across multiple markups which could have different namespaces. I'm not sure if that would be a problem in this case where the component resolution is all bound to within the rendering of a single markup. I don't know but there may be complex markup inheritance usage where not having the namespace could be a problem.
          Hide
          Sven Meier added a comment -

          Yeah, this dual personalities thing I find unfortunate: depending on the personality the member variable is null.

          Regarding the namespace prefix:
          I don't think it makes any difference from what namespace the componentTag was identified from. All <wicket:message>, <foo:message> and <bar:message> tags from different markups are handled by the same WicketMessageTagHandler and resolved by a single WicketMessageTagHandler. The prefix shouldn't matter.

          Show
          Sven Meier added a comment - Yeah, this dual personalities thing I find unfortunate: depending on the personality the member variable is null. Regarding the namespace prefix: I don't think it makes any difference from what namespace the componentTag was identified from. All <wicket:message>, <foo:message> and <bar:message> tags from different markups are handled by the same WicketMessageTagHandler and resolved by a single WicketMessageTagHandler. The prefix shouldn't matter.
          Hide
          Chris Colman added a comment -

          WicketMessageTagHandler may not need the prefix but some of the other filters/resolvers might be used in scenarios that cross markups. Not sure exactly but maybe an <:extend> tag inside an <:enclosure> or perhaps an 'a' tag using a relative path inside a markup that is 'overridden' in a child (derived) markup.

          I'm not sure if these scenarios are plausible but to verify that all scenarios work without the namespace inside the id would require very exhaustive, extensive testing.

          For now it might be easier to make the small fix that does not alter the composition of the id because it is a lot less risky than changing the composition of the id. Perhaps the change of id composition could be raised as a separate "improvement" issue in JIRA.

          Show
          Chris Colman added a comment - WicketMessageTagHandler may not need the prefix but some of the other filters/resolvers might be used in scenarios that cross markups. Not sure exactly but maybe an <:extend> tag inside an <:enclosure> or perhaps an 'a' tag using a relative path inside a markup that is 'overridden' in a child (derived) markup. I'm not sure if these scenarios are plausible but to verify that all scenarios work without the namespace inside the id would require very exhaustive, extensive testing. For now it might be easier to make the small fix that does not alter the composition of the id because it is a lot less risky than changing the composition of the id. Perhaps the change of id composition could be raised as a separate "improvement" issue in JIRA.
          Hide
          Chris Colman added a comment - - edited

          Do you think it would be possible to go ahead with the simple bug fix now and look at the other idea as an improvement? If you could apply these small, safe patches into the master then I can switch back to the master branch again and then maybe we can look at the riskier move of changing the id composition later.

          At the moment we want our app to go live soon with a 6.2 snapshot but without the patches in the master we'd have to make a release based on our own branch with the fix which isn't ideal.

          Show
          Chris Colman added a comment - - edited Do you think it would be possible to go ahead with the simple bug fix now and look at the other idea as an improvement? If you could apply these small, safe patches into the master then I can switch back to the master branch again and then maybe we can look at the riskier move of changing the id composition later. At the moment we want our app to go live soon with a 6.2 snapshot but without the patches in the master we'd have to make a release based on our own branch with the fix which isn't ideal.
          Hide
          Sven Meier added a comment -

          Before adding more methods, I'd like to hear Martin's opinion on this, since he worked on WICKET-4520 and WICKET-4521.

          Show
          Sven Meier added a comment - Before adding more methods, I'd like to hear Martin's opinion on this, since he worked on WICKET-4520 and WICKET-4521 .
          Hide
          Chris Colman added a comment -

          I couldn't find any reference to this fix in GitHub. Does something need to be pulled before it ends up in the master branch?

          Show
          Chris Colman added a comment - I couldn't find any reference to this fix in GitHub. Does something need to be pulled before it ends up in the master branch?

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              Chris Colman
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development