[
https://issues.apache.org/jira/browse/WICKET-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483025#comment-13483025
]
Chris Colman commented on WICKET-4829:
--------------------------------------
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.
> ComponentResolvers created in app init ignore markup's namespace
> ----------------------------------------------------------------
>
> Key: WICKET-4829
> URL: https://issues.apache.org/jira/browse/WICKET-4829
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.2.0
> Environment: Windows, Java 6.x
> Reporter: Chris Colman
> Attachments: nonStdNamespaceBugW6.2.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
