Dynamic bookmars and portal's BookmarkAction

[Sylvain Wallez <sy...@apache.org>]

Hi all,

We had an interesting bug today: we use the portal's BookmarkAction with 
a "cocoon:" source, as bookmarks are the aggregation of a constant 
bookmark file and a project-specific one (this is a reuseable portal 
infrastructure + per-project customization).

The "cocoon:" source maps to a pipeline in a child sitemap of the one 
where the action is declared, and the result is that we enter an 
infinite loop, because the "cocoon:" is loaded within the action's 
parameterize() method when the sitemap is being built, and that again 
triggers the loading of the sitemap (a new instance since the previous 
one isn't yet active), which creates an instance of the action, calls 
its parameterize() method, etc, etc.

Now the funny thing is that it *used to work* in 2.1.5.1 release, but no 
more in a recent update of the 2.1.x branch. And although I understand 
what happens now, I have hard times understanding why it did work before.

Any hint on this?


A way to solve this could be to defer loading of the bookmark source 
until the first call to act(), but we potentially then hit the problem 
of relative sources whose resolving dependends on the current sitemap, 
and not the place where the action is declared.

So the workaround I finally found is to add a "lazy-load" boolean 
parameter to the bookmark action which, if true, defers loading until 
the first call to act(). That way, the moment where loading occurs is 
under the developper's responsibility. Seems hacky but that's the only 
solution I found so far.

Any idea on a better solution?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Dynamic bookmars and portal's BookmarkAction

[Ralph Goers <Ra...@dslextreme.com>]

Sylvain Wallez wrote:

> Hi all,
>
> We had an interesting bug today: we use the portal's BookmarkAction 
> with a "cocoon:" source, as bookmarks are the aggregation of a 
> constant bookmark file and a project-specific one (this is a reuseable 
> portal infrastructure + per-project customization).
>
> The "cocoon:" source maps to a pipeline in a child sitemap of the one 
> where the action is declared, and the result is that we enter an 
> infinite loop, because the "cocoon:" is loaded within the action's 
> parameterize() method when the sitemap is being built, and that again 
> triggers the loading of the sitemap (a new instance since the previous 
> one isn't yet active), which creates an instance of the action, calls 
> its parameterize() method, etc, etc.
>
> Now the funny thing is that it *used to work* in 2.1.5.1 release, but 
> no more in a recent update of the 2.1.x branch. And although I 
> understand what happens now, I have hard times understanding why it 
> did work before.
>
> Any hint on this?
>
>
> A way to solve this could be to defer loading of the bookmark source 
> until the first call to act(), but we potentially then hit the problem 
> of relative sources whose resolving dependends on the current sitemap, 
> and not the place where the action is declared.
>
> So the workaround I finally found is to add a "lazy-load" boolean 
> parameter to the bookmark action which, if true, defers loading until 
> the first call to act(). That way, the moment where loading occurs is 
> under the developper's responsibility. Seems hacky but that's the only 
> solution I found so far.
>
> Any idea on a better solution?
>
> Sylvain
>
I don't know if it will solve your problem, but you might look at the 
PageLabel stuff I added as an alternative to bookmarks.

Ralph

RE: Dynamic bookmars and portal's BookmarkAction

[Carsten Ziegeler <cz...@apache.org>]

Sylvain Wallez  wrote:
> 
> We had an interesting bug today: we use the portal's 
> BookmarkAction with a "cocoon:" source, as bookmarks are the 
> aggregation of a constant bookmark file and a 
> project-specific one (this is a reuseable portal 
> infrastructure + per-project customization).
> 
> The "cocoon:" source maps to a pipeline in a child sitemap of 
> the one where the action is declared, and the result is that 
> we enter an infinite loop, because the "cocoon:" is loaded 
> within the action's
> parameterize() method when the sitemap is being built, and 
> that again triggers the loading of the sitemap (a new 
> instance since the previous one isn't yet active), which 
> creates an instance of the action, calls its parameterize() 
> method, etc, etc.
> 
> Now the funny thing is that it *used to work* in 2.1.5.1 
> release, but no more in a recent update of the 2.1.x branch. 
> And although I understand what happens now, I have hard times 
> understanding why it did work before.
> 
> Any hint on this?
> 
Hmm, is it related to this?

   <action dev="SW" type="fix" fixes-bug="27249">
     Refactor TreeProcessor to avoid constant reloading of sitemap if its
     modification date is in the future and occasional ECM-related
exceptions
     when a sitemap is reloaded.
   </action>

I'm really wondering myself why it worked before. Strange..

Carsten