Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.1.3
-
None
-
None
-
Tomcat 5.5 on Linux
Description
According to the documentation here:
http://portals.apache.org/jetspeed-2/guides/guide-profiler.html
The definition of the "name" of a criterion for a profiling rule is:
The unique name (per rule) of this criterion. Upon matches, the name is mapped to the profile locator property name.
However, if you create a rule with multiple hostname criterion and you give one of them the name "hostname-2" so that it is unique, then it doesn't work properly because the paths constructed by the SiteView component contain "_hostname-2" instead of "_hostname".
Here's what happened: a co-worker of mine was working on the example sub-site profiling rule and editing it in the profiler admin.
He noticed that if you have two criterion named the same thing (eg. there are two occurrences of the "hostname" criterion), then when you are in the profiler admin and you click on the criterion to edit it, you can only ever load the first occurrence. (see issue #JS2-1191).
That is clicking on the hostname criterion at position 4 will cause the hostname criterion at position 1 to get loaded.
For this reason, he changed the name of the second hostname criterion to be "hostname-2".
We figured this should be fine since the second navigation criterion was named using this convention (ie. navigation-2). I just figured that a hostname criterion would always use a fixed value of "_hostname" for the path. We didn't think it would use the criterion name.
However, doing this resulted in the list of paths that the SiteView.makeSearchPathList method produces to be:
/__subsite-root/_hostname/my.company.com/_user/guest
/__subsite-root/_hostname/my.company.com
/__subsite-root/_hostname-2/my.company.com/_role/portal-user
/__subsite-root/_hostname-2/my.company.com
/__subsite-root
Since there is no _hostname-2 folder, those paths would get pruned and never shown in the profiler debug log and we were left wondering why the role paths were never considered.
I found this out by adding some debug of my own to the SiteView class.
I found the same behaviour with the role and user criteria types and I would assume it would be the same with group, etc.
My suggestion would be to do one of the following:
1. Update the online documentation to say that the criterion name need not be unique per rule. Further, the "_user", "_role", "_group" and "_hostname" reserved folders are merely convention and in fact, they will end up being whatever the "name" of your criterion is with an underbar in front. In addition, fix #JS2-1191.
2. Change the behaviour of the SiteView and related components so that the reserved folder names (ie. _user, _role, etc) are always used for their respective criterion "type", regardless of the "name" of the criterion.
3. Allow population of a "value" for the user, role, group and hostname criterion. If a "value" is provided, then that is used in calculating the reserved folder name. If there is no value, then it falls back to the "name" of the criterion.
The documentation should be made to line up with which ever way this issue is addressed.