You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Harry Metske <ha...@gmail.com> on 2009/08/08 16:36:45 UTC
PageViewPlugin
Hi there,
Andre has contributed a PageViewPlugin.
Looks to me a good candidate to takeinto the core distribution, it just
needs some additional JUnit tests.
Any thoughts ?
See http://www.jspwiki.org/wiki/PageViewPlugin
regards,
Harry
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
*grin* Should've skimmed it more accurately then!
/Janne
On 9 Aug 2009, at 12:20, Harry Metske wrote:
> that is also already in the code :-)
>
> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>
>>
>> An improvement would be that it could also listen to the
>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>
>> Is Andre on this list? Would you mind contributing your code to us?
>>
>> /Janne
>>
>>
>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>
>> the plugin spawns a separate thread when it first initializes
>> (using a
>>> static var).The thread saves the in-memory counts to a file each 5
>>> minutes.
>>>
>>> Harry
>>>
>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>
>>> Hi all,
>>>>
>>>> I don't believe either it would be too late to integrate in 2.8,
>>>> since
>>>>> it would be just a new plugin and does not change existing APIs
>>>>> in any
>>>>> way.
>>>>>
>>>>
>>>> ok, fine then! :-) Was thinking of the policy to only integrate
>>>> bugfix
>>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>>
>>>> (Note, however, that there's still a good reason to store page view
>>>>> counts in a separate file: performance. Having a database write
>>>>> (possibly several) for each read would be very heavy. Better to
>>>>> journal it and keep a latest count in memory; then upon startup
>>>>> read
>>>>> the journal back in. JCR does not have the concept of appending
>>>>> to a
>>>>> Property either.)
>>>>>
>>>>
>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>
>>>> regards
>>>> Florian
>>>>
>>>>
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
that is also already in the code :-)
2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>
> An improvement would be that it could also listen to the
> WikiEngineEvent.SHUTDOWN to be on the safe side.
>
> Is Andre on this list? Would you mind contributing your code to us?
>
> /Janne
>
>
> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>
> the plugin spawns a separate thread when it first initializes (using a
>> static var).The thread saves the in-memory counts to a file each 5
>> minutes.
>>
>> Harry
>>
>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>
>> Hi all,
>>>
>>> I don't believe either it would be too late to integrate in 2.8, since
>>>> it would be just a new plugin and does not change existing APIs in any
>>>> way.
>>>>
>>>
>>> ok, fine then! :-) Was thinking of the policy to only integrate bugfix
>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>
>>> (Note, however, that there's still a good reason to store page view
>>>> counts in a separate file: performance. Having a database write
>>>> (possibly several) for each read would be very heavy. Better to
>>>> journal it and keep a latest count in memory; then upon startup read
>>>> the journal back in. JCR does not have the concept of appending to a
>>>> Property either.)
>>>>
>>>
>>> AFAIK this is just the way Andre has implemented it :-)
>>>
>>> regards
>>> Florian
>>>
>>>
>
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
Great, thanks!
/Janne
On 3 Sep 2009, at 20:43, Harry Metske wrote:
> I kind of summarized this discussion in
> https://issues.apache.org/jira/browse/JSPWIKI-592
>
>
> 2009/9/1 Janne Jalkanen <Ja...@ecyrd.com>
>
>> not necessary, we could still use the current (in memory) caching
>>> mechanism.
>>> We should then keep delta values there, and after interval expiry,
>>> read
>>> the
>>> pagecount value from the JCR node for each entry from the im-mem
>>> cache,
>>> add
>>> the delta values and write back to JCR.
>>>
>>
>> That would take a lot of writes still... Perhaps it's better to
>> have a
>> single binary blob.
>>
>> This does assume that we have locking capabilities on the JCR page.
>>> This way we would also support multiple wiki instances.
>>>
>>
>> Most JCR implementations do support locking (aka "mix:lockable").
>> Including
>> Priha.
>>
>> /Janne
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
I kind of summarized this discussion in
https://issues.apache.org/jira/browse/JSPWIKI-592
2009/9/1 Janne Jalkanen <Ja...@ecyrd.com>
> not necessary, we could still use the current (in memory) caching
>> mechanism.
>> We should then keep delta values there, and after interval expiry, read
>> the
>> pagecount value from the JCR node for each entry from the im-mem cache,
>> add
>> the delta values and write back to JCR.
>>
>
> That would take a lot of writes still... Perhaps it's better to have a
> single binary blob.
>
> This does assume that we have locking capabilities on the JCR page.
>> This way we would also support multiple wiki instances.
>>
>
> Most JCR implementations do support locking (aka "mix:lockable"). Including
> Priha.
>
> /Janne
>
Re: PageViewPlugin
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> not necessary, we could still use the current (in memory) caching
> mechanism.
> We should then keep delta values there, and after interval expiry,
> read the
> pagecount value from the JCR node for each entry from the im-mem
> cache, add
> the delta values and write back to JCR.
That would take a lot of writes still... Perhaps it's better to have a
single binary blob.
> This does assume that we have locking capabilities on the JCR page.
> This way we would also support multiple wiki instances.
Most JCR implementations do support locking (aka "mix:lockable").
Including Priha.
/Janne
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
2009/8/31 Janne Jalkanen <ja...@iki.fi>
> > Keeping the data as property of the page would break the performance of
> the plugin.
> > (and would make a sliding behaviour like dividing all counts by 2 every
> time period
> > that much more difficult to implement)
>
> Not really; would be really easy to find them all with an XPath query.
> The bigger problem is that they would probably kill read perf because
> it would result in a DB write for each read.
not necessary, we could still use the current (in memory) caching mechanism.
We should then keep delta values there, and after interval expiry, read the
pagecount value from the JCR node for each entry from the im-mem cache, add
the delta values and write back to JCR.
This does assume that we have locking capabilities on the JCR page.
This way we would also support multiple wiki instances.
/Harry
> > Originally I opted against putting the data in a generated wiki page
> because it will
> > get in the way of people. An attachment to a special page like
> PopularPages also
> > did not seem the way to go - replacement bypassing the versioning of
> pages and attachments
> > breaks the general behaviour.
>
> For JCR this is not a problem, you just put it in a non-versioned
> Node. It would both be invisible to the generic user, and also it
> would not mess up with anything.
>
> I think JSPWiki currently ignores any namespaced Nodes in the main repo.
>
> > With regard to context; one would expect a count per space if spaces are
> separate
> > wikis.
>
> Well, a WikiPath is a combo of spacename and wikiname, so you would
> probably use that.
>
> /Janne
>
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@iki.fi>.
> Keeping the data as property of the page would break the performance of the plugin.
> (and would make a sliding behaviour like dividing all counts by 2 every time period
> that much more difficult to implement)
Not really; would be really easy to find them all with an XPath query.
The bigger problem is that they would probably kill read perf because
it would result in a DB write for each read.
> Originally I opted against putting the data in a generated wiki page because it will
> get in the way of people. An attachment to a special page like PopularPages also
> did not seem the way to go - replacement bypassing the versioning of pages and attachments
> breaks the general behaviour.
For JCR this is not a problem, you just put it in a non-versioned
Node. It would both be invisible to the generic user, and also it
would not mess up with anything.
I think JSPWiki currently ignores any namespaced Nodes in the main repo.
> With regard to context; one would expect a count per space if spaces are separate
> wikis.
Well, a WikiPath is a combo of spacename and wikiname, so you would
probably use that.
/Janne
Re: PageViewPlugin
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
You mean something like mix:referenceable? (aka
Session.getNodeByUUID())? ;-)
/Janne
On Sep 1, 2009, at 01:07 , Murray Altheim wrote:
> Janne Jalkanen wrote:
>> The first determination would be to decide whether this data should
>> be stored as a Property of a WikiPage or as a generic binary blob
>> under some special page...
>> Easiest would be to simply define a special page and then store it
>> as a Binary blob there. This would mirror the current storage in
>> workDir.
>> JSPWiki stores currently the WikiPages as JCR Node /pages/<space
>> name>/<wikiname>. We could store the data under /
>> wiki:PageViewPlugin/, perhaps? But that means that you need to
>> access the JCR store directly (using the JSR-170 API), and it might
>> not be import/exportable. THe other possibility is to define a /
>> pages/<space name>/System:PageViewPlugin or something and store it
>> there, but then it becomes tied to a particular wikispace
>> (=something else than a static var is needed to store the data).
>> Opinions?
>
> Another approach is modularising various functionality via linked web
> services, which we've been doing for about a year now. This might not
> be appropriate for this instance but I thought to mention it.
>
> We've been using REST-style web services for a number of things, where
> the ties between a page and some kind of related metadata is weaker
> than might be for what we normally consider page-level metadata, or
> in instances where we don't want to "corrupt" the page record with
> content not properly part of the page itself (such as user comments).
> We're doing this for a prototype chat service and for a network status
> feature (where our engineers alter status information on a separate
> web service site and it shows up on the wiki using a plugin), but it
> occurs to me there might be other appropriate uses.
>
> This kind of modularity has been valuable and has kept our wiki
> content
> cleaner, with the links always via wiki page name. One of the projects
> in the plans is a persistent identifier (permalink/tinyurl) web
> service,
> where the canonical identifier for a wiki page would be a persistent
> identifier (PID) rather than the wiki page name (which could change).
> This would require the addition of the PID to the wiki page metadata
> and a simple resolver from PID to wiki page URL (which could be done
> via a fielded Lucene search or a hashtable). The PID then becomes the
> common link between web service and wiki page, which makes more sense
> than using a mutable wiki page name. With the move to a Priha/JSR-170
> style backend this might be easier than with the 2.8.2 code base.
>
> Some ideas anyway...
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray09 at altheim dot com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
> = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
Re: PageViewPlugin
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>
> The first determination would be to decide whether this data should be
> stored as a Property of a WikiPage or as a generic binary blob under
> some special page...
>
> Easiest would be to simply define a special page and then store it as a
> Binary blob there. This would mirror the current storage in workDir.
>
> JSPWiki stores currently the WikiPages as JCR Node /pages/<space
> name>/<wikiname>. We could store the data under /wiki:PageViewPlugin/,
> perhaps? But that means that you need to access the JCR store directly
> (using the JSR-170 API), and it might not be import/exportable. THe
> other possibility is to define a /pages/<space
> name>/System:PageViewPlugin or something and store it there, but then it
> becomes tied to a particular wikispace (=something else than a static
> var is needed to store the data).
>
> Opinions?
Another approach is modularising various functionality via linked web
services, which we've been doing for about a year now. This might not
be appropriate for this instance but I thought to mention it.
We've been using REST-style web services for a number of things, where
the ties between a page and some kind of related metadata is weaker
than might be for what we normally consider page-level metadata, or
in instances where we don't want to "corrupt" the page record with
content not properly part of the page itself (such as user comments).
We're doing this for a prototype chat service and for a network status
feature (where our engineers alter status information on a separate
web service site and it shows up on the wiki using a plugin), but it
occurs to me there might be other appropriate uses.
This kind of modularity has been valuable and has kept our wiki content
cleaner, with the links always via wiki page name. One of the projects
in the plans is a persistent identifier (permalink/tinyurl) web service,
where the canonical identifier for a wiki page would be a persistent
identifier (PID) rather than the wiki page name (which could change).
This would require the addition of the PID to the wiki page metadata
and a simple resolver from PID to wiki page URL (which could be done
via a fielded Lucene search or a hashtable). The PID then becomes the
common link between web service and wiki page, which makes more sense
than using a mutable wiki page name. With the move to a Priha/JSR-170
style backend this might be easier than with the 2.8.2 code base.
Some ideas anyway...
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
RE: PageViewPlugin
Posted by "Dalen, Andre van" <an...@siemens.com>.
Keeping the data as property of the page would break the performance of the plugin.
(and would make a sliding behaviour like dividing all counts by 2 every time period
that much more difficult to implement)
Originally I opted against putting the data in a generated wiki page because it will
get in the way of people. An attachment to a special page like PopularPages also
did not seem the way to go - replacement bypassing the versioning of pages and attachments
breaks the general behaviour.
With regard to context; one would expect a count per space if spaces are separate
wikis.
regards, Andre
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalkanen@ecyrd.com]
Sent: zondag 30 augustus 2009 22:41
To: jspwiki-dev@incubator.apache.org
Subject: Re: PageViewPlugin
The first determination would be to decide whether this data should be
stored as a Property of a WikiPage or as a generic binary blob under
some special page...
Easiest would be to simply define a special page and then store it as
a Binary blob there. This would mirror the current storage in workDir.
JSPWiki stores currently the WikiPages as JCR Node /pages/<space name>/
<wikiname>. We could store the data under /wiki:PageViewPlugin/,
perhaps? But that means that you need to access the JCR store directly
(using the JSR-170 API), and it might not be import/exportable. THe
other possibility is to define a /pages/<space name>/
System:PageViewPlugin or something and store it there, but then it
becomes tied to a particular wikispace (=something else than a static
var is needed to store the data).
Opinions?
/Janne
On 30 Aug 2009, at 20:29, Florian Holeczek wrote:
> Hallo Harry,
>
> conceptually, this is metadata of the related page. In JCR speak, it's
> a property of the page node.
>
> regards
> Florian
>
> Ursprüngliche Nachricht vom 30.08.2009 um 19:24:
>> Yes,
>> do you have a few more details on how to implement, should it be
>> stored in a
>> special page, or something else.
>> Maybe some skeleton or sample code could give a jump start.
>
>> regards,
>> Harry
>
>> 2009/8/30 Janne Jalkanen <ja...@ecyrd.com>
>
>>>
>>> For 3.0, it might be nice to store the contents in the repository as
>>> opposed to the work directory. That way you don't lose it
>>> accidentally if
>>> you empty the workdir or move the machine or something. Workdir is
>>> supposed
>>> to be a place for things which can be recovered...
>>>
>>> /Janne
>>>
>>>
>>> On 30 Aug 2009, at 13:11, Harry Metske wrote:
>>>
>>> The Plugin is in the core now for 2.8.
>>>> I'm working on the 3.0 version, but it requires some more
>>>> adjustments
>>>> (like
>>>> replace oro regexp with Java 5 regexp).
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/8/26 Harry Metske <ha...@gmail.com>
>>>>
>>>> Hi,
>>>>> Andre has sent a signed ICLA to ASF's secretary.
>>>>> So I'd like to add this plugin to the core.
>>>>> I will add some testcases and hope to commit it somewhere next
>>>>> week if
>>>>> there aren't any objections.
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2009/8/12 Harry Metske <ha...@gmail.com>
>>>>>
>>>>> I sent Andre a direct email, and got an out-of-office reply, we
>>>>> should
>>>>> wait
>>>>>
>>>>>> a couple of weeks still.
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>>
>>>>>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>>>>>
>>>>>>
>>>>>>> An improvement would be that it could also listen to the
>>>>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>>>>
>>>>>>> Is Andre on this list? Would you mind contributing your code
>>>>>>> to us?
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>>
>>>>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>>>>
>>>>>>> the plugin spawns a separate thread when it first initializes
>>>>>>> (using a
>>>>>>>
>>>>>>>> static var).The thread saves the in-memory counts to a file
>>>>>>>> each 5
>>>>>>>> minutes.
>>>>>>>>
>>>>>>>> Harry
>>>>>>>>
>>>>>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't believe either it would be too late to integrate in
>>>>>>>>> 2.8,
>>>>>>>>> since
>>>>>>>>>
>>>>>>>>>> it would be just a new plugin and does not change existing
>>>>>>>>>> APIs in
>>>>>>>>>> any
>>>>>>>>>> way.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ok, fine then! :-) Was thinking of the policy to only
>>>>>>>>> integrate
>>>>>>>>> bugfix
>>>>>>>>> code into a stable branch, but indeed, it's a non-invasive
>>>>>>>>> change.
>>>>>>>>>
>>>>>>>>> (Note, however, that there's still a good reason to store
>>>>>>>>> page view
>>>>>>>>>
>>>>>>>>>> counts in a separate file: performance. Having a database
>>>>>>>>>> write
>>>>>>>>>> (possibly several) for each read would be very heavy.
>>>>>>>>>> Better to
>>>>>>>>>> journal it and keep a latest count in memory; then upon
>>>>>>>>>> startup read
>>>>>>>>>> the journal back in. JCR does not have the concept of
>>>>>>>>>> appending to
>>>>>>>>>> a
>>>>>>>>>> Property either.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Florian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
The first determination would be to decide whether this data should be
stored as a Property of a WikiPage or as a generic binary blob under
some special page...
Easiest would be to simply define a special page and then store it as
a Binary blob there. This would mirror the current storage in workDir.
JSPWiki stores currently the WikiPages as JCR Node /pages/<space name>/
<wikiname>. We could store the data under /wiki:PageViewPlugin/,
perhaps? But that means that you need to access the JCR store directly
(using the JSR-170 API), and it might not be import/exportable. THe
other possibility is to define a /pages/<space name>/
System:PageViewPlugin or something and store it there, but then it
becomes tied to a particular wikispace (=something else than a static
var is needed to store the data).
Opinions?
/Janne
On 30 Aug 2009, at 20:29, Florian Holeczek wrote:
> Hallo Harry,
>
> conceptually, this is metadata of the related page. In JCR speak, it's
> a property of the page node.
>
> regards
> Florian
>
> Ursprüngliche Nachricht vom 30.08.2009 um 19:24:
>> Yes,
>> do you have a few more details on how to implement, should it be
>> stored in a
>> special page, or something else.
>> Maybe some skeleton or sample code could give a jump start.
>
>> regards,
>> Harry
>
>> 2009/8/30 Janne Jalkanen <ja...@ecyrd.com>
>
>>>
>>> For 3.0, it might be nice to store the contents in the repository as
>>> opposed to the work directory. That way you don't lose it
>>> accidentally if
>>> you empty the workdir or move the machine or something. Workdir is
>>> supposed
>>> to be a place for things which can be recovered...
>>>
>>> /Janne
>>>
>>>
>>> On 30 Aug 2009, at 13:11, Harry Metske wrote:
>>>
>>> The Plugin is in the core now for 2.8.
>>>> I'm working on the 3.0 version, but it requires some more
>>>> adjustments
>>>> (like
>>>> replace oro regexp with Java 5 regexp).
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/8/26 Harry Metske <ha...@gmail.com>
>>>>
>>>> Hi,
>>>>> Andre has sent a signed ICLA to ASF's secretary.
>>>>> So I'd like to add this plugin to the core.
>>>>> I will add some testcases and hope to commit it somewhere next
>>>>> week if
>>>>> there aren't any objections.
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2009/8/12 Harry Metske <ha...@gmail.com>
>>>>>
>>>>> I sent Andre a direct email, and got an out-of-office reply, we
>>>>> should
>>>>> wait
>>>>>
>>>>>> a couple of weeks still.
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>>
>>>>>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>>>>>
>>>>>>
>>>>>>> An improvement would be that it could also listen to the
>>>>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>>>>
>>>>>>> Is Andre on this list? Would you mind contributing your code
>>>>>>> to us?
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>>
>>>>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>>>>
>>>>>>> the plugin spawns a separate thread when it first initializes
>>>>>>> (using a
>>>>>>>
>>>>>>>> static var).The thread saves the in-memory counts to a file
>>>>>>>> each 5
>>>>>>>> minutes.
>>>>>>>>
>>>>>>>> Harry
>>>>>>>>
>>>>>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't believe either it would be too late to integrate in
>>>>>>>>> 2.8,
>>>>>>>>> since
>>>>>>>>>
>>>>>>>>>> it would be just a new plugin and does not change existing
>>>>>>>>>> APIs in
>>>>>>>>>> any
>>>>>>>>>> way.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ok, fine then! :-) Was thinking of the policy to only
>>>>>>>>> integrate
>>>>>>>>> bugfix
>>>>>>>>> code into a stable branch, but indeed, it's a non-invasive
>>>>>>>>> change.
>>>>>>>>>
>>>>>>>>> (Note, however, that there's still a good reason to store
>>>>>>>>> page view
>>>>>>>>>
>>>>>>>>>> counts in a separate file: performance. Having a database
>>>>>>>>>> write
>>>>>>>>>> (possibly several) for each read would be very heavy.
>>>>>>>>>> Better to
>>>>>>>>>> journal it and keep a latest count in memory; then upon
>>>>>>>>>> startup read
>>>>>>>>>> the journal back in. JCR does not have the concept of
>>>>>>>>>> appending to
>>>>>>>>>> a
>>>>>>>>>> Property either.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Florian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
Re: PageViewPlugin
Posted by Florian Holeczek <fl...@holeczek.de>.
Hallo Harry,
conceptually, this is metadata of the related page. In JCR speak, it's
a property of the page node.
regards
Florian
Ursprüngliche Nachricht vom 30.08.2009 um 19:24:
> Yes,
> do you have a few more details on how to implement, should it be stored in a
> special page, or something else.
> Maybe some skeleton or sample code could give a jump start.
> regards,
> Harry
> 2009/8/30 Janne Jalkanen <ja...@ecyrd.com>
>>
>> For 3.0, it might be nice to store the contents in the repository as
>> opposed to the work directory. That way you don't lose it accidentally if
>> you empty the workdir or move the machine or something. Workdir is supposed
>> to be a place for things which can be recovered...
>>
>> /Janne
>>
>>
>> On 30 Aug 2009, at 13:11, Harry Metske wrote:
>>
>> The Plugin is in the core now for 2.8.
>>> I'm working on the 3.0 version, but it requires some more adjustments
>>> (like
>>> replace oro regexp with Java 5 regexp).
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/8/26 Harry Metske <ha...@gmail.com>
>>>
>>> Hi,
>>>> Andre has sent a signed ICLA to ASF's secretary.
>>>> So I'd like to add this plugin to the core.
>>>> I will add some testcases and hope to commit it somewhere next week if
>>>> there aren't any objections.
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/8/12 Harry Metske <ha...@gmail.com>
>>>>
>>>> I sent Andre a direct email, and got an out-of-office reply, we should
>>>> wait
>>>>
>>>>> a couple of weeks still.
>>>>> regards,
>>>>> Harry
>>>>>
>>>>>
>>>>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>>>>
>>>>>
>>>>>> An improvement would be that it could also listen to the
>>>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>>>
>>>>>> Is Andre on this list? Would you mind contributing your code to us?
>>>>>>
>>>>>> /Janne
>>>>>>
>>>>>>
>>>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>>>
>>>>>> the plugin spawns a separate thread when it first initializes (using a
>>>>>>
>>>>>>> static var).The thread saves the in-memory counts to a file each 5
>>>>>>> minutes.
>>>>>>>
>>>>>>> Harry
>>>>>>>
>>>>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>>>
>>>>>>>> I don't believe either it would be too late to integrate in 2.8,
>>>>>>>> since
>>>>>>>>
>>>>>>>>> it would be just a new plugin and does not change existing APIs in
>>>>>>>>> any
>>>>>>>>> way.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ok, fine then! :-) Was thinking of the policy to only integrate
>>>>>>>> bugfix
>>>>>>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>>>>>>
>>>>>>>> (Note, however, that there's still a good reason to store page view
>>>>>>>>
>>>>>>>>> counts in a separate file: performance. Having a database write
>>>>>>>>> (possibly several) for each read would be very heavy. Better to
>>>>>>>>> journal it and keep a latest count in memory; then upon startup read
>>>>>>>>> the journal back in. JCR does not have the concept of appending to
>>>>>>>>> a
>>>>>>>>> Property either.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>>>
>>>>>>>> regards
>>>>>>>> Florian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
Yes,
do you have a few more details on how to implement, should it be stored in a
special page, or something else.
Maybe some skeleton or sample code could give a jump start.
regards,
Harry
2009/8/30 Janne Jalkanen <ja...@ecyrd.com>
>
> For 3.0, it might be nice to store the contents in the repository as
> opposed to the work directory. That way you don't lose it accidentally if
> you empty the workdir or move the machine or something. Workdir is supposed
> to be a place for things which can be recovered...
>
> /Janne
>
>
> On 30 Aug 2009, at 13:11, Harry Metske wrote:
>
> The Plugin is in the core now for 2.8.
>> I'm working on the 3.0 version, but it requires some more adjustments
>> (like
>> replace oro regexp with Java 5 regexp).
>>
>> regards,
>> Harry
>>
>> 2009/8/26 Harry Metske <ha...@gmail.com>
>>
>> Hi,
>>> Andre has sent a signed ICLA to ASF's secretary.
>>> So I'd like to add this plugin to the core.
>>> I will add some testcases and hope to commit it somewhere next week if
>>> there aren't any objections.
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/8/12 Harry Metske <ha...@gmail.com>
>>>
>>> I sent Andre a direct email, and got an out-of-office reply, we should
>>> wait
>>>
>>>> a couple of weeks still.
>>>> regards,
>>>> Harry
>>>>
>>>>
>>>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>>>
>>>>
>>>>> An improvement would be that it could also listen to the
>>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>>
>>>>> Is Andre on this list? Would you mind contributing your code to us?
>>>>>
>>>>> /Janne
>>>>>
>>>>>
>>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>>
>>>>> the plugin spawns a separate thread when it first initializes (using a
>>>>>
>>>>>> static var).The thread saves the in-memory counts to a file each 5
>>>>>> minutes.
>>>>>>
>>>>>> Harry
>>>>>>
>>>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>>>
>>>>>>> I don't believe either it would be too late to integrate in 2.8,
>>>>>>> since
>>>>>>>
>>>>>>>> it would be just a new plugin and does not change existing APIs in
>>>>>>>> any
>>>>>>>> way.
>>>>>>>>
>>>>>>>>
>>>>>>> ok, fine then! :-) Was thinking of the policy to only integrate
>>>>>>> bugfix
>>>>>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>>>>>
>>>>>>> (Note, however, that there's still a good reason to store page view
>>>>>>>
>>>>>>>> counts in a separate file: performance. Having a database write
>>>>>>>> (possibly several) for each read would be very heavy. Better to
>>>>>>>> journal it and keep a latest count in memory; then upon startup read
>>>>>>>> the journal back in. JCR does not have the concept of appending to
>>>>>>>> a
>>>>>>>> Property either.)
>>>>>>>>
>>>>>>>>
>>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>>
>>>>>>> regards
>>>>>>> Florian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
For 3.0, it might be nice to store the contents in the repository as
opposed to the work directory. That way you don't lose it accidentally
if you empty the workdir or move the machine or something. Workdir is
supposed to be a place for things which can be recovered...
/Janne
On 30 Aug 2009, at 13:11, Harry Metske wrote:
> The Plugin is in the core now for 2.8.
> I'm working on the 3.0 version, but it requires some more
> adjustments (like
> replace oro regexp with Java 5 regexp).
>
> regards,
> Harry
>
> 2009/8/26 Harry Metske <ha...@gmail.com>
>
>> Hi,
>> Andre has sent a signed ICLA to ASF's secretary.
>> So I'd like to add this plugin to the core.
>> I will add some testcases and hope to commit it somewhere next week
>> if
>> there aren't any objections.
>>
>> regards,
>> Harry
>>
>> 2009/8/12 Harry Metske <ha...@gmail.com>
>>
>> I sent Andre a direct email, and got an out-of-office reply, we
>> should wait
>>> a couple of weeks still.
>>> regards,
>>> Harry
>>>
>>>
>>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>>
>>>>
>>>> An improvement would be that it could also listen to the
>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>
>>>> Is Andre on this list? Would you mind contributing your code to
>>>> us?
>>>>
>>>> /Janne
>>>>
>>>>
>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>
>>>> the plugin spawns a separate thread when it first initializes
>>>> (using a
>>>>> static var).The thread saves the in-memory counts to a file each 5
>>>>> minutes.
>>>>>
>>>>> Harry
>>>>>
>>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> I don't believe either it would be too late to integrate in
>>>>>> 2.8, since
>>>>>>> it would be just a new plugin and does not change existing
>>>>>>> APIs in any
>>>>>>> way.
>>>>>>>
>>>>>>
>>>>>> ok, fine then! :-) Was thinking of the policy to only integrate
>>>>>> bugfix
>>>>>> code into a stable branch, but indeed, it's a non-invasive
>>>>>> change.
>>>>>>
>>>>>> (Note, however, that there's still a good reason to store page
>>>>>> view
>>>>>>> counts in a separate file: performance. Having a database write
>>>>>>> (possibly several) for each read would be very heavy. Better to
>>>>>>> journal it and keep a latest count in memory; then upon
>>>>>>> startup read
>>>>>>> the journal back in. JCR does not have the concept of
>>>>>>> appending to a
>>>>>>> Property either.)
>>>>>>>
>>>>>>
>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>
>>>>>> regards
>>>>>> Florian
>>>>>>
>>>>>>
>>>>
>>>
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
The Plugin is in the core now for 2.8.
I'm working on the 3.0 version, but it requires some more adjustments (like
replace oro regexp with Java 5 regexp).
regards,
Harry
2009/8/26 Harry Metske <ha...@gmail.com>
> Hi,
> Andre has sent a signed ICLA to ASF's secretary.
> So I'd like to add this plugin to the core.
> I will add some testcases and hope to commit it somewhere next week if
> there aren't any objections.
>
> regards,
> Harry
>
> 2009/8/12 Harry Metske <ha...@gmail.com>
>
> I sent Andre a direct email, and got an out-of-office reply, we should wait
>> a couple of weeks still.
>> regards,
>> Harry
>>
>>
>> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>>
>>>
>>> An improvement would be that it could also listen to the
>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>
>>> Is Andre on this list? Would you mind contributing your code to us?
>>>
>>> /Janne
>>>
>>>
>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>
>>> the plugin spawns a separate thread when it first initializes (using a
>>>> static var).The thread saves the in-memory counts to a file each 5
>>>> minutes.
>>>>
>>>> Harry
>>>>
>>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>>
>>>> Hi all,
>>>>>
>>>>> I don't believe either it would be too late to integrate in 2.8, since
>>>>>> it would be just a new plugin and does not change existing APIs in any
>>>>>> way.
>>>>>>
>>>>>
>>>>> ok, fine then! :-) Was thinking of the policy to only integrate bugfix
>>>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>>>
>>>>> (Note, however, that there's still a good reason to store page view
>>>>>> counts in a separate file: performance. Having a database write
>>>>>> (possibly several) for each read would be very heavy. Better to
>>>>>> journal it and keep a latest count in memory; then upon startup read
>>>>>> the journal back in. JCR does not have the concept of appending to a
>>>>>> Property either.)
>>>>>>
>>>>>
>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>
>>>>> regards
>>>>> Florian
>>>>>
>>>>>
>>>
>>
>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
Hi,
Andre has sent a signed ICLA to ASF's secretary.
So I'd like to add this plugin to the core.
I will add some testcases and hope to commit it somewhere next week if there
aren't any objections.
regards,
Harry
2009/8/12 Harry Metske <ha...@gmail.com>
> I sent Andre a direct email, and got an out-of-office reply, we should wait
> a couple of weeks still.
> regards,
> Harry
>
>
> 2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>
>>
>> An improvement would be that it could also listen to the
>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>
>> Is Andre on this list? Would you mind contributing your code to us?
>>
>> /Janne
>>
>>
>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>
>> the plugin spawns a separate thread when it first initializes (using a
>>> static var).The thread saves the in-memory counts to a file each 5
>>> minutes.
>>>
>>> Harry
>>>
>>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>>
>>> Hi all,
>>>>
>>>> I don't believe either it would be too late to integrate in 2.8, since
>>>>> it would be just a new plugin and does not change existing APIs in any
>>>>> way.
>>>>>
>>>>
>>>> ok, fine then! :-) Was thinking of the policy to only integrate bugfix
>>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>>
>>>> (Note, however, that there's still a good reason to store page view
>>>>> counts in a separate file: performance. Having a database write
>>>>> (possibly several) for each read would be very heavy. Better to
>>>>> journal it and keep a latest count in memory; then upon startup read
>>>>> the journal back in. JCR does not have the concept of appending to a
>>>>> Property either.)
>>>>>
>>>>
>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>
>>>> regards
>>>> Florian
>>>>
>>>>
>>
>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
I sent Andre a direct email, and got an out-of-office reply, we should wait
a couple of weeks still.
regards,
Harry
2009/8/9 Janne Jalkanen <ja...@ecyrd.com>
>
> An improvement would be that it could also listen to the
> WikiEngineEvent.SHUTDOWN to be on the safe side.
>
> Is Andre on this list? Would you mind contributing your code to us?
>
> /Janne
>
>
> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>
> the plugin spawns a separate thread when it first initializes (using a
>> static var).The thread saves the in-memory counts to a file each 5
>> minutes.
>>
>> Harry
>>
>> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>>
>> Hi all,
>>>
>>> I don't believe either it would be too late to integrate in 2.8, since
>>>> it would be just a new plugin and does not change existing APIs in any
>>>> way.
>>>>
>>>
>>> ok, fine then! :-) Was thinking of the policy to only integrate bugfix
>>> code into a stable branch, but indeed, it's a non-invasive change.
>>>
>>> (Note, however, that there's still a good reason to store page view
>>>> counts in a separate file: performance. Having a database write
>>>> (possibly several) for each read would be very heavy. Better to
>>>> journal it and keep a latest count in memory; then upon startup read
>>>> the journal back in. JCR does not have the concept of appending to a
>>>> Property either.)
>>>>
>>>
>>> AFAIK this is just the way Andre has implemented it :-)
>>>
>>> regards
>>> Florian
>>>
>>>
>
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
An improvement would be that it could also listen to the
WikiEngineEvent.SHUTDOWN to be on the safe side.
Is Andre on this list? Would you mind contributing your code to us?
/Janne
On 9 Aug 2009, at 11:59, Harry Metske wrote:
> the plugin spawns a separate thread when it first initializes (using a
> static var).The thread saves the in-memory counts to a file each 5
> minutes.
>
> Harry
>
> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>
>> Hi all,
>>
>>> I don't believe either it would be too late to integrate in 2.8,
>>> since
>>> it would be just a new plugin and does not change existing APIs in
>>> any
>>> way.
>>
>> ok, fine then! :-) Was thinking of the policy to only integrate
>> bugfix
>> code into a stable branch, but indeed, it's a non-invasive change.
>>
>>> (Note, however, that there's still a good reason to store page view
>>> counts in a separate file: performance. Having a database write
>>> (possibly several) for each read would be very heavy. Better to
>>> journal it and keep a latest count in memory; then upon startup read
>>> the journal back in. JCR does not have the concept of appending
>>> to a
>>> Property either.)
>>
>> AFAIK this is just the way Andre has implemented it :-)
>>
>> regards
>> Florian
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
the plugin spawns a separate thread when it first initializes (using a
static var).The thread saves the in-memory counts to a file each 5 minutes.
Harry
2009/8/9 Florian Holeczek <fl...@holeczek.de>
> Hi all,
>
> > I don't believe either it would be too late to integrate in 2.8, since
> > it would be just a new plugin and does not change existing APIs in any
> > way.
>
> ok, fine then! :-) Was thinking of the policy to only integrate bugfix
> code into a stable branch, but indeed, it's a non-invasive change.
>
> > (Note, however, that there's still a good reason to store page view
> > counts in a separate file: performance. Having a database write
> > (possibly several) for each read would be very heavy. Better to
> > journal it and keep a latest count in memory; then upon startup read
> > the journal back in. JCR does not have the concept of appending to a
> > Property either.)
>
> AFAIK this is just the way Andre has implemented it :-)
>
> regards
> Florian
>
Re: PageViewPlugin
Posted by Florian Holeczek <fl...@holeczek.de>.
Hi all,
> I don't believe either it would be too late to integrate in 2.8, since
> it would be just a new plugin and does not change existing APIs in any
> way.
ok, fine then! :-) Was thinking of the policy to only integrate bugfix
code into a stable branch, but indeed, it's a non-invasive change.
> (Note, however, that there's still a good reason to store page view
> counts in a separate file: performance. Having a database write
> (possibly several) for each read would be very heavy. Better to
> journal it and keep a latest count in memory; then upon startup read
> the journal back in. JCR does not have the concept of appending to a
> Property either.)
AFAIK this is just the way Andre has implemented it :-)
regards
Florian
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
I don't believe either it would be too late to integrate in 2.8, since
it would be just a new plugin and does not change existing APIs in any
way. It should also work quite unmodified in 3.0, though it would
make sense to store the data in JCR.
(Note, however, that there's still a good reason to store page view
counts in a separate file: performance. Having a database write
(possibly several) for each read would be very heavy. Better to
journal it and keep a latest count in memory; then upon startup read
the journal back in. JCR does not have the concept of appending to a
Property either.)
/Janne
On 9 Aug 2009, at 11:04, Harry Metske wrote:
> Florian,
> why would it be too late for integration in 2.8 ?
>
> Storing the page counters in a flat file is indeed something to
> reconsider,
> I agree with you about JCR, in 3.0 it should support a clustered
> wiki environment.
>
> regards,
> Harry
>
> 2009/8/9 Florian Holeczek <fl...@holeczek.de>
>
>> Hallo Harry,
>>
>> it seems to be a very nice plugin, indeed.
>> However, for 2.8 it's too late for integrating it, and for 3.x its
>> persistency code should be changed. Now that we're using JCR, a page
>> view count is a typical candidate for another page metadata to be
>> stored directly in the content repository and not in an extra file on
>> disk. But the plugin frontend looks nice to me!
>>
>> best regards
>> Florian
>>
>> Ursprüngliche Nachricht vom 08.08.2009 um 16:36:
>>> Hi there,
>>
>>> Andre has contributed a PageViewPlugin.
>>> Looks to me a good candidate to takeinto the core distribution, it
>>> just
>>> needs some additional JUnit tests.
>>> Any thoughts ?
>>
>>> See http://www.jspwiki.org/wiki/PageViewPlugin
>>> regards,
>>> Harry
>>
Re: PageViewPlugin
Posted by Harry Metske <ha...@gmail.com>.
Florian,
why would it be too late for integration in 2.8 ?
Storing the page counters in a flat file is indeed something to reconsider,
I agree with you about JCR, in 3.0 it should support a clustered
wiki environment.
regards,
Harry
2009/8/9 Florian Holeczek <fl...@holeczek.de>
> Hallo Harry,
>
> it seems to be a very nice plugin, indeed.
> However, for 2.8 it's too late for integrating it, and for 3.x its
> persistency code should be changed. Now that we're using JCR, a page
> view count is a typical candidate for another page metadata to be
> stored directly in the content repository and not in an extra file on
> disk. But the plugin frontend looks nice to me!
>
> best regards
> Florian
>
> Ursprüngliche Nachricht vom 08.08.2009 um 16:36:
> > Hi there,
>
> > Andre has contributed a PageViewPlugin.
> > Looks to me a good candidate to takeinto the core distribution, it just
> > needs some additional JUnit tests.
> > Any thoughts ?
>
> > See http://www.jspwiki.org/wiki/PageViewPlugin
> > regards,
> > Harry
>
Re: PageViewPlugin
Posted by Florian Holeczek <fl...@holeczek.de>.
Hallo Harry,
it seems to be a very nice plugin, indeed.
However, for 2.8 it's too late for integrating it, and for 3.x its
persistency code should be changed. Now that we're using JCR, a page
view count is a typical candidate for another page metadata to be
stored directly in the content repository and not in an extra file on
disk. But the plugin frontend looks nice to me!
best regards
Florian
Ursprüngliche Nachricht vom 08.08.2009 um 16:36:
> Hi there,
> Andre has contributed a PageViewPlugin.
> Looks to me a good candidate to takeinto the core distribution, it just
> needs some additional JUnit tests.
> Any thoughts ?
> See http://www.jspwiki.org/wiki/PageViewPlugin
> regards,
> Harry
Re: PageViewPlugin
Posted by Janne Jalkanen <ja...@ecyrd.com>.
Looks nice; though a couple of issues:
* Code is not formatted according to JSPWiki coding guidelines (e.g.
it uses tabs)
* This is a fairly large contribution, so I think an ICLA or a
Software Grant is required
So no opposition from me, if the above are addressed (including the
unit tests).
/Janne
On 8 Aug 2009, at 15:36, Harry Metske wrote:
> Hi there,
>
> Andre has contributed a PageViewPlugin.
> Looks to me a good candidate to takeinto the core distribution, it
> just
> needs some additional JUnit tests.
> Any thoughts ?
>
> See http://www.jspwiki.org/wiki/PageViewPlugin
> regards,
> Harry