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]
