9:27 p.m.
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules for
/jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but it
is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:14 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-4190) RewriteFilter is Non-deterministic
[
https://jira.jboss.org/jira/browse/JBSEAM-4190?page=com.atlassian.jira.pl...
]
Nicko Cadell commented on JBSEAM-4190:
--------------------------------------
I'm having the same problem:
1) Does not work for me as I have a /{foo}/{bar} pattern, this must come last!
2) Changing to a TreeMap will sort the page's by the viewID (TreeMap uses the natural
order of the keys by default). This would mean that I would have to sort my views into
alphabetical order based on the order I wanted the rewrite rules to work. It would be
better if rewrite filter could get the view ids in the order they are defined in the
pages.xml file.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest is odd as the method already returns a List, which supports ordering. I'm
assuming that this is supposed to entail some sorting of the patterns. This would be the
best solution if the patterns could be ordered from most specific to least specific. Given
that each view can have multiple patterns it is not sufficient to order the patterns only
by their view. I think that the Grails url mapping engine does this type of pattern
sorting.
A quick fix could be implemented by getting the view ids in the order they are defined in
the pages.xml. This is what I have currently done.
A complete fix would be to find a way of ordering the patterns so that the rules do not
need to be specified in a specific order, and multiple rewrite rules from a single view
are ordered correctly.
Also it would be nice if the rewrite filter didn't have to build the list of patterns
for each request.
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules
for /jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but
it is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:42 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-4190) RewriteFilter is Non-deterministic
[
https://jira.jboss.org/jira/browse/JBSEAM-4190?page=com.atlassian.jira.pl...
]
Norman Richards reassigned JBSEAM-4190:
---------------------------------------
Assignee: Norman Richards
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
Assignee: Norman Richards
Fix For: 2.2.0.CR1
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules
for /jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but
it is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:42 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-4190) RewriteFilter is Non-deterministic
[
https://jira.jboss.org/jira/browse/JBSEAM-4190?page=com.atlassian.jira.pl...
]
Norman Richards updated JBSEAM-4190:
------------------------------------
Fix Version/s: 2.2.0.CR1
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
Assignee: Norman Richards
Fix For: 2.2.0.CR1
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules
for /jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but
it is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:31 p.m.
New subject: [JBoss JIRA] Updated: (JBSEAM-4190) RewriteFilter is Non-deterministic
[
https://jira.jboss.org/jira/browse/JBSEAM-4190?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-4190:
------------------------------
Fix Version/s: The future
(was: 2.2.1.CR1)
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
Assignee: Norman Richards
Fix For: The future
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules
for /jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but
it is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:26 p.m.
New subject: [JBoss JIRA] Updated: (JBSEAM-4190) RewriteFilter is Non-deterministic
[
https://jira.jboss.org/jira/browse/JBSEAM-4190?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-4190:
------------------------------
Assignee: (was: Norman Richards)
RewriteFilter is Non-deterministic
----------------------------------
Key: JBSEAM-4190
URL: https://jira.jboss.org/jira/browse/JBSEAM-4190
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.1.GA
Reporter: John Gilbert
Fix For: The future
The RewriteFilter is non-deterministic in some cases. An example serves best.
Here are the rewrite rules I would like:
/Customer/edit/{id} -> /jsf/Customer/Edit.xhtml
/Customer/create -> /jsf/Customer/Edit.xhtml
/Customer/{id} -> /jsf/Customer/View.xhtml
When debugging the value of RewriteFilter.getAllPatterns(), the order of the two rules
for /jsf/Customer/Edit.xhtml are always preserved.
However, because Pages.getKnownViewIds() returns a HashSet there is no guarantee that the
rules for /jsf/Customer/View.xhtml will come after the rules for /jsf/Customer/Edit.xhtml.
As a result, /Customer/create sometimes translates to /jsf/Customer/View.xhtml when
/jsf/Customer/View.xhtml is returned first in the set.
There are several possible solutions:
1) Change /Customer/{id} to /Customer/view/{id}. However, this is not the best url for a
View.
2) Change Pages.pagesByViewId to a TreeMap. This is the patch I am currently using, but
it is only guaranteed for my patterns.
3) Change RewriteFilter.getAllPatterns() to returns a TreeSet sorted from longest to
shortest. This is similar to the way Pages.wildcardViewIds works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5256
days inactive
5514
days old
5 comments
4 participants
participants (4)
-
John Gilbert (JIRA) -
Nicko Cadell (JIRA)
-
Norman Richards (JIRA)
-
Pete Muir (JIRA)