Aaron,
Good. I am glad it worked for you in the end. Please go ahead and file
JIRA bugs for the UI and docs issues.
Randy
Aaron Evans wrote:
Randy,
We've got it working now so I guess this isn't a bug after all
although there is UI bug in the profiler admin.
Here's what happened: a co-worker of mine was working on the 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.
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/_role-first/portal-user
/__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.
I found the paths above by adding some debug of my own to the SiteView class.
So back to our original problem, adding a 3rd navigation back to "/"
and then adding another user criterion does the trick.
But again, we we initially tried this, we gave our second user
criterion the name "user-2" and this caused the generated path to
contain "_user-2". So now that we are just using the name "user", it
works great.
I can open JIRA issues for the UI bug but I thought perhaps it is
fixed in newer versions of jetspeed?
Also, the fact that the names of the criterion can't be something
custom for hostname, user, role, group etc should probably be spelled
out in the documentation.
Thanks for the help!
-aaron
On Tue, Apr 27, 2010 at 12:15 PM, Aaron Evans <[email protected]> wrote:
Ok, great, we have the debug logging going on so now we can see what's
happening.
Anyhow, I believe that there is a bug with this stuff. It seems as
though once you do a second "navigate", it won't consider the user's
username or role anymore.
Consider the example seed data.
I have the following folder structure:
/default-page.psml
/_user/guest/default-page.psml
/__subsite-root/_hostname/my.company.com/home-page.psml
/__subsite-root/_hostname/my.company.com/_user/guest/default-page.psml
/__subsite-root/_hostname/my.company.com/_role/portal-user/
If I request /portal/jetspeed/ as the anonymous ("guest") user who has
the "portal-user" role, then I get the following ot:
Updated user/locators context: user=guest,
profileLocators=(page=/:navigation:subsite-root:hostname:my.company.com:user:guest:navigation-2:subsite-root:hostname-2:my.company.com:role:portal-user:path:default-page,menu=/:navigation:subsite-root:hostname:my.company.com:user:guest:navigation-2:subsite-root:hostname-2:my.company.com:role:portal-user:path:default-page)
Created site view: search
paths=/__subsite-root/_hostname/my.company.com/_user/guest,/__subsite-root/_hostname/my.company.com,/__subsite-root
Request page: request path=/
Selected folder default page:
path=/__subsite-root/_hostname/my.company.com/_user/guest/default-page.psml
Note that the path
/__subsite-root/_hostname/my.company.com/_role/portal-user is *not*
included in the site view.
If I then *swap* the order of the user criteria and the role criteria
so that role comes first, then I get:
Updated user/locators context: user=guest,
profileLocators=(page=/:navigation:subsite-root:hostname:my.company.com:role:portal-user:navigation-2:subsite-root:hostname-2:my.company.com:user:guest:path:default-page,menu=/:navigation:subsite-root:hostname:my.company.com:role:portal-user:navigation-2:subsite-root:hostname-2:my.company.com:user:guest:path:default-page)
Created site view: search
paths=/__subsite-root/_hostname/my.company.com/_role/portal-user,/__subsite-root/_hostname/my.company.com,/__subsite-root
Request page: request path=/
Selected folder default page:
path=/__subsite-root/_hostname/my.company.com/home-page.psml
So now, the
/__subsite-root/_hostname/my.company.com/_user/guest/default-page.psml
path is not included in the site view.
Is this expected behviour or a bug?
On Tue, Apr 27, 2010 at 10:58 AM, Randy Watler <[email protected]> wrote:
Aaron,
Sounds like you're on the right track. Look for the file named
'Log4j.properties' in the installed jetspeed webapp. Add the following
lines:
log4j.category.org.apache.jetspeed.portalsite = DEBUG, jetspeed
log4j.additivity.org.apache.jetspeed.portalsite = false
The logged output should appear in the logs/jetspeed.log file in the
installed jetspeed webapp.
HTH,
Randy
Aaron Evans wrote:
Hey Randy,
I swear I thought we tried something like that but that does seem to
help somewhat.
However, we're still having a problem for the anonymous case. In the
event that the hostname is not found, we want the user to end up
getting the content in:
pages/_user/guest
I tried inserting another "user" criterion (named user-final) after
the new "/" navigation and before the final path criterion but that
didn't seem to work.
Please excuse my ignorance, but where exactly would I set the DEBUG
level for the Portal Site component?
I think if we could see the output of this it would help us immensely.
I appreciate your assistance in this matter...
-aaron
On Mon, Apr 26, 2010 at 8:29 PM, Randy Watler <[email protected]>
wrote:
Aaron,
Evidently I was mistaken. However, it is simple enough to add another
default path to your profiling rule. Insert this immediately before the
"path" criterion:
<Criterion name="navigation-3">
<type value="navigation"/>
<value value="/"/>
<fallBackOrder value="6"/>
<fallBackType value="2"/>
</Criterion>
And then modify the "path" criterion by bumping the fallback order:
<Criterion name="path">
<type value="path"/>
<value value="home"/>
<fallBackOrder value="7"/>
<fallBackType value="2"/>
</Criterion>
You can verify the resulting page search paths by enabling DEBUG logging
for
the Portal Site component, (org.apache.jetspeed.portalsite), and looking
for
search path messages.
Randy
Aaron Evans wrote:
Hi Randy,
We're using jetspeed 2.1.3 against LDAP.
Basically, we're using the subsite rule pretty much as it is defined
in the example in the documentation. I've pasted the XML below.
It works fine in the case that the request is made using a hostname
for which a directory exists in subsite-root/_hostname.
However, if you use a hostname that is *not* in there, then you end up
getting a "NodeNotFoundException":
ERROR org.apache.jetspeed.profiler.impl.ProfilerValveImpl - No page
matched / request in site view.
org.apache.jetspeed.page.document.NodeNotFoundException: No page
matched / request in site view.
at
org.apache.jetspeed.portalsite.impl.PortalSiteSessionContextImpl.selectRequestPage(PortalSiteSessionContextImpl.java:645)
at
org.apache.jetspeed.portalsite.impl.PortalSiteSessionContextImpl.selectRequestPage(PortalSiteSessionContextImpl.java:228)
at
org.apache.jetspeed.portalsite.impl.PortalSiteRequestContextImpl.getPage(PortalSiteRequestContextImpl.java:213)
at
org.apache.jetspeed.portalsite.impl.PortalSiteRequestContextImpl.getManagedPage(PortalSiteRequestContextImpl.java:196)
at
org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:241)
Subsite Profiling Rule Definition:
<ProfilingRule id="subsite-by-hostname-live" standardRule="false">
<description value="A rule based on role fallback
algorithm with
specified subsite and home page"/>
<Criteria>
<Criterion name="navigation">
<type value="navigation"/>
<value value="subsite-root"/>
<fallBackOrder value="0"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="hostname">
<type value="hostname"/>
<fallBackOrder value="1"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="user">
<type value="user"/>
<fallBackOrder value="2"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="navigation-2">
<type value="navigation"/>
<value value="subsite-root"/>
<fallBackOrder value="3"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="hostname-2">
<type value="hostname"/>
<fallBackOrder value="4"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="role">
<type value="role"/>
<fallBackOrder value="5"/>
<fallBackType value="2"/>
</Criterion>
<Criterion name="path">
<type value="path"/>
<value value="home"/>
<fallBackOrder value="6"/>
<fallBackType value="2"/>
</Criterion>
</Criteria>
</ProfilingRule>
On Mon, Apr 26, 2010 at 2:12 PM, Randy Watler <[email protected]>
wrote:
Aaron,
The subsite rules should fallback to the root folder if they do not
exist.
Let me know if that is not working for you and which rules you are
using,
Randy
Aaron Evans wrote:
We're trying to use the subsite profiling features. We've setup our
profiling rule like in the example here:
http://portals.apache.org/jetspeed-2/guides/guide-subsites.html
Here's the trick though: we'd like it so that if there is no match on
the hostname (ie. there is no directory with the given hostname found
in __subsite-root/_hostname), then we'd like it to return to the pages
root.
Is this possible?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
