portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Evans (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Created: (JS2-1192) Profiler: Issue using unique name for multiple user, role or hostname criterion in the same locator rule
Date Tue, 27 Apr 2010 21:18:31 GMT
Profiler: Issue using unique name for multiple user, role or hostname criterion in the same
locator rule
--------------------------------------------------------------------------------------------------------

                 Key: JS2-1192
                 URL: https://issues.apache.org/jira/browse/JS2-1192
             Project: Jetspeed 2
          Issue Type: Bug
          Components: Profiler, Profiling/Portal Navigation
    Affects Versions: 2.1.3
         Environment: Tomcat 5.5 on Linux
            Reporter: Aaron Evans
            Priority: Minor


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.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message