Great news. Glad it works for you. On Dec 8, 2009, at 9:30, "Schenk, Andre" <Andre.Schenk@FIZ- Karlsruhe.DE> wrote: Hi developers, > > just a short message from me, that supplying the WikiEngine to a > custom login module now works with JSPWiki 2.8.3. Many thanks for > that!!! > > Best regards, > > André > -------------------------- > André Schenk > ePublishing & eScience > Development & Applied Research > Phone +49 7247 808-215 > Fax +49 7247 808-133 > Andre.Schenk@fiz-karlsruhe.de > > > FIZ Karlsruhe > Hermann-von-Helmholtz-Platz 1 > 76344 Eggenstein-Leopoldshafen, Germany > > www.fiz-karlsruhe.de > --------------------------------------- > > >> -----Original Message----- >> From: Andrew Jaquith [mailto:andrew.r.jaquith@gmail.com] >> Sent: Thursday, March 26, 2009 4:39 AM >> To: jspwiki-dev@incubator.apache.org; Schenk, Andre >> Subject: Re: OpenID support in JSPWiki? >> >> Hi Tilman -- >> >> Your analysis is correct. You would need to get obtain the >> HttpRequest >> from WikiCallbackHandler, which at the moment it does not know how to >> supply. We have had some other questions about this recently, notably >> Andre Schenk's desire to be able to obtain a reference to the >> WikiEngine from inside his custom LoginModule. >> >> In both cases, the common thread is that we need to supply additional >> callbacks to WikiCallbackHandler. I'm inclined to fix this in 2.8.2, >> by simply adding in support for the HttpRequestCallback. That should >> meet your needs, no? >> >> It should also meet Andre's, indirectly, in the sense that if you >> have >> an HttpRequest you can fairly easily retrieve the WikiEngine also (by >> passing getSession().getServletContext() to WikiEngine.getInstance >> ()). >> >> Andrew >> >> On Wed, Mar 25, 2009 at 7:27 AM, Tilman Bender >> <tbender@stud.hs-heilbronn.de> wrote: >>> Hi Andrew, >>> >>> Thanks for your help! >>> >>> Let's see if I got it right: >>> >>> - My OpenidAssertionLoginModule need the data from the HttpPRequest >>> - The way to obtain this data is via HttpReuqestCallback >>> >>> From what I can see so far, the HttpReuqest in HttpRequestCallBack >>> is >> only >>> set in WebContainerCallbackHandler, which is used by: >>> >>> -WebContainerLoginModule >>> -CookieAssertionLoginModule >>> - AnonymousLoginModule >>> >>> So as I get it, I would have to either use this CallBackHandler, >> instead of >>> WikiCallBackHandler >>> or to find a way to set the HttpRequest in HttpRequestCallBack from >> within >>> WikiCallBackHandler. >>> >>> Question is: How can I access the request from within, >> WikiCallBackHandler? >>> >>> I agree on the attribute exchange on login, allthough I would see >> that as a >>> further improvement to the basic OpenID >>> functionality. >>> >>> For the UI side, I attached some mocks. This is what my UI currenlty >> looks >>> like, but it is far from complete. Comments >>> welcome :-) >>> >>> >>> >>> >>> >>> >>> >>> >>> kind regards >>> >>> Tilman Bender >>> Student des Software Engineering >>> Hochschule Heilbronn >>> tbender@stud.hs-heilbronn.de >>> >>> >>> >>> Am 20.03.2009 um 14:43 schrieb Andrew Jaquith: >>> >>>> Tilman-- >>>> >>>> Thanks for your e-mail, and for your good work. >>>> >>>> Your thought-process on this seems sound. Agreed, the first phase >>>> of >> login >>>> (OP discovery + redirect) should be handled by a custom JSP. The >> second >>>> phase (validation) should be handled by JAAS. >>>> >>>> To do this, you will need to get the HttpRequest object. JSPWiki >> does have >>>> an HttpRequestCallback that can supply this, at least in the custom >>>> authentication case. You will need to check to see if >> WikiCallbackHandler >>>> passes that callback. If not, it is trivial to patch the code to do >> this. >>>> >>>> So, I think this is basically in line with what you proposed. >>>> >>>> Some other thoughts: >>>> >>>> At login time, it would be highly desirable to use SREG or OpenID >>>> attribute exchange to pull the user's name and e-mail address and >> use the >>>> returned values to update their profile, which would ensure that >> their >>>> information is always current. The login ID used to look up the >> profile >>>> should be the user's OpenID URL... I think. >>>> >>>> On the UI side, we will need a special OpenID login page (JSP). The >>>> regular login page could include this if desired. >>>> >>>> Andrew >>>> >>>> On Mar 18, 2009, at 7:02, Tilman Bender <tbender@stud.hs- >> heilbronn.de> >>>> wrote: >>>> >>>>> Hey guys, >>>>> >>>>> I am currently plaing with the 2.8.1 code and openid4java. >>>>> >>>>> But I am having a hard time trying to fiugre out where exactly to >> hook in >>>>> the OpenID stuff. >>>>> The problem is (as also described in #JSPWIKI-94), that: >>>>> >>>>> 1. To me it seems you cannot do the whole thing in JAAS: >>>>> OpenID as I understand it has two phases : >>>>> >>>>> Phase I: >>>>> - The user just submitted his openid identifier to our >> login/registration >>>>> from. >>>>> - We do discovery on the identifier to find the Endpoint of his >> OpenID >>>>> Provider (and check if the provider is in our whitelist) >>>>> - We redirect the user to his OpenID provider >>>>> >>>>> So in this phase it makes no sense to me to use a JAAS-Module >>>>> since >> we >>>>> wouldn't be able to complete the login mehtod >>>>> as we do not know enough about the user yet (we do not know if his >>>>> identity is asserted by the OpenID Provider). >>>>> So I currently do this via JSP and Scriptlets (no custom tag >>>>> yet). >>>>> >>>>> Phase II: >>>>> - The user is redirected back to us by his OpenID Provider >>>>> - We connect to the OpenID Provider to verify the assertion that >> was >>>>> passed along the request (be it a positive or negative assertion) >>>>> - Now we know enough about the user to log them in. >>>>> >>>>> I currently try to use UserManager.setUserProfile in this >> situation. Now >>>>> here comes my Problem: >>>>> >>>>> I would like to do all the assertion verifiaction in a JAAS- >>>>> Module, >> but >>>>> for that I need all the request >>>>> data, which I do not have in the setUserProfile-Method. >>>>> >>>>> So currently I am stuck. Before I start to wildly mess the API: Am >> I >>>>> taking the right direction? >>>>> >>>>> >>>>> Tilman Bender >>>>> Student des Software Engineering >>>>> Hochschule Heilbronn >>>>> tbender@stud.hs-heilbronn.de >>>>> >>>>> >>>>> >>>>> Am 03.12.2008 um 21:50 schrieb Janne Jalkanen: >>>>> >>>>>> Hi! >>>>>> >>>>>> Thanks for the effort - sounds like a worthy project! >>>>>> >>>>>> I think you will save yourself a lot of grief if you work on the >> 2.8.1 >>>>>> branch, since the trunk is now the subject of a lot of changes - >> but note >>>>>> that we *will* be making some rather major changes for 3.0, so >>>>>> you >> may face >>>>>> a small porting effort towards the end. We certainly wouldn't >> like to land >>>>>> a major feature in 2.8 branch anymore, since it's rather stable. >>>>>> >>>>>> I think the first thing you could do is to outline your plan as >>>>>> to >> how >>>>>> exactly are you planning to hook into our structures - a good >> place to start >>>>>> is probably the Security documentation at >>>>>> http://doc.jspwiki.org/2.8/wiki/Security, and then asking a lot >>>>>> of >> questions >>>>>> on this mailing list. >>>>>> >>>>>> Also, since we are talking about a fairly large project here, you >> might >>>>>> want to sign a contributor license agreement (CLA), and depending >> on the >>>>>> German copyright legislation, get also Heilbronn to sign a >> corporate CLA. >>>>>> That, or Heilbronn (or you) need to, at the end of the project, >> give a >>>>>> software grant (SGA) to Apache Software Foundation. But these >>>>>> are >> not >>>>>> biggies and can be tackled if/when we start merging ;-) >>>>>> >>>>>> /Janne >>>>>> >>>>>> On Dec 3, 2008, at 21:25 , Tilman Bender wrote: >>>>>> >>>>>>> Hi JSPWiki Devs, >>>>>>> >>>>>>> I am a student at Heilbronn University in Germany (Some of you >> might >>>>>>> know Christoph Sauer, who worked there.) >>>>>>> As pre-thesis for my diploma I want to enhance JSPWiki with >> OpenID. >>>>>>> >>>>>>> I am still pretty new to JSPWIki, OpenID and JAAS. >>>>>>> I have worked my way through the official OpenID 2.0 >> Authentication >>>>>>> standard >>>>>>> and will do as well for Attributes Exchange. >>>>>>> >>>>>>> I would like to base my work on the 2.8.1 tag and >>>>>>> see to get it integrate into the trunk later. Is that the >>>>>>> correct >> way >>>>>>> to do it? >>>>>>> >>>>>>> As I see Andrew already spent quite some time on OpenID and did >> some >>>>>>> preparations. >>>>>>> Since I plan to get my diploma somday soon (say in 2009 ;-)), I >> have a >>>>>>> high personal interest >>>>>>> in getting OpenID into JSPWiki. >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> * I have time >>>>>>> * I have motivation >>>>>>> * I need some help to get started ;-) >>>>>>> >>>>>>> Any suggestions where to begin? I guess registration/profile >> creation >>>>>>> would be first. >>>>>>> >>>>>>> kind regards >>>>>>> >>>>>>> >>>>>>> Tilman Bender >>>>>>> Student des Software Engineering >>>>>>> Hochschule Heilbronn >>>>>>> tbender@stud.hs-heilbronn.de >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>> > > > ------------------------------------------------------- > > Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich > -technische Information mbH. > Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht > Mannheim HRB 101892. > Geschäftsführerin: Sabine Brünger-Weilandt. > Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. > >
Hi developers, just a short message from me, that supplying the WikiEngine to a custom login module now works with JSPWiki 2.8.3. Many thanks for that!!! Best regards, André -------------------------- André Schenk ePublishing & eScience Development & Applied Research Phone +49 7247 808-215 Fax +49 7247 808-133 Andre.Schenk@fiz-karlsruhe.de FIZ Karlsruhe Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen, Germany www.fiz-karlsruhe.de --------------------------------------- > -----Original Message----- > From: Andrew Jaquith [mailto:andrew.r.jaquith@gmail.com] > Sent: Thursday, March 26, 2009 4:39 AM > To: jspwiki-dev@incubator.apache.org; Schenk, Andre > Subject: Re: OpenID support in JSPWiki? > > Hi Tilman -- > > Your analysis is correct. You would need to get obtain the HttpRequest > from WikiCallbackHandler, which at the moment it does not know how to > supply. We have had some other questions about this recently, notably > Andre Schenk's desire to be able to obtain a reference to the > WikiEngine from inside his custom LoginModule. > > In both cases, the common thread is that we need to supply additional > callbacks to WikiCallbackHandler. I'm inclined to fix this in 2.8.2, > by simply adding in support for the HttpRequestCallback. That should > meet your needs, no? > > It should also meet Andre's, indirectly, in the sense that if you have > an HttpRequest you can fairly easily retrieve the WikiEngine also (by > passing getSession().getServletContext() to WikiEngine.getInstance()). > > Andrew > > On Wed, Mar 25, 2009 at 7:27 AM, Tilman Bender > <tbender@stud.hs-heilbronn.de> wrote: > > Hi Andrew, > > > > Thanks for your help! > > > > Let's see if I got it right: > > > > - My OpenidAssertionLoginModule need the data from the HttpPRequest > > - The way to obtain this data is via HttpReuqestCallback > > > > From what I can see so far, the HttpReuqest in HttpRequestCallBack is > only > > set in WebContainerCallbackHandler, which is used by: > > > > -WebContainerLoginModule > > -CookieAssertionLoginModule > > - AnonymousLoginModule > > > > So as I get it, I would have to either use this CallBackHandler, > instead of > > WikiCallBackHandler > > or to find a way to set the HttpRequest in HttpRequestCallBack from > within > > WikiCallBackHandler. > > > > Question is: How can I access the request from within, > WikiCallBackHandler? > > > > I agree on the attribute exchange on login, allthough I would see > that as a > > further improvement to the basic OpenID > > functionality. > > > > For the UI side, I attached some mocks. This is what my UI currenlty > looks > > like, but it is far from complete. Comments > > welcome :-) > > > > > > > > > > > > > > > > > > kind regards > > > > Tilman Bender > > Student des Software Engineering > > Hochschule Heilbronn > > tbender@stud.hs-heilbronn.de > > > > > > > > Am 20.03.2009 um 14:43 schrieb Andrew Jaquith: > > > >> Tilman-- > >> > >> Thanks for your e-mail, and for your good work. > >> > >> Your thought-process on this seems sound. Agreed, the first phase of > login > >> (OP discovery + redirect) should be handled by a custom JSP. The > second > >> phase (validation) should be handled by JAAS. > >> > >> To do this, you will need to get the HttpRequest object. JSPWiki > does have > >> an HttpRequestCallback that can supply this, at least in the custom > >> authentication case. You will need to check to see if > WikiCallbackHandler > >> passes that callback. If not, it is trivial to patch the code to do > this. > >> > >> So, I think this is basically in line with what you proposed. > >> > >> Some other thoughts: > >> > >> At login time, it would be highly desirable to use SREG or OpenID > >> attribute exchange to pull the user's name and e-mail address and > use the > >> returned values to update their profile, which would ensure that > their > >> information is always current. The login ID used to look up the > profile > >> should be the user's OpenID URL... I think. > >> > >> On the UI side, we will need a special OpenID login page (JSP). The > >> regular login page could include this if desired. > >> > >> Andrew > >> > >> On Mar 18, 2009, at 7:02, Tilman Bender <tbender@stud.hs- > heilbronn.de> > >> wrote: > >> > >>> Hey guys, > >>> > >>> I am currently plaing with the 2.8.1 code and openid4java. > >>> > >>> But I am having a hard time trying to fiugre out where exactly to > hook in > >>> the OpenID stuff. > >>> The problem is (as also described in #JSPWIKI-94), that: > >>> > >>> 1. To me it seems you cannot do the whole thing in JAAS: > >>> OpenID as I understand it has two phases : > >>> > >>> Phase I: > >>> - The user just submitted his openid identifier to our > login/registration > >>> from. > >>> - We do discovery on the identifier to find the Endpoint of his > OpenID > >>> Provider (and check if the provider is in our whitelist) > >>> - We redirect the user to his OpenID provider > >>> > >>> So in this phase it makes no sense to me to use a JAAS-Module since > we > >>> wouldn't be able to complete the login mehtod > >>> as we do not know enough about the user yet (we do not know if his > >>> identity is asserted by the OpenID Provider). > >>> So I currently do this via JSP and Scriptlets (no custom tag yet). > >>> > >>> Phase II: > >>> - The user is redirected back to us by his OpenID Provider > >>> - We connect to the OpenID Provider to verify the assertion that > was > >>> passed along the request (be it a positive or negative assertion) > >>> - Now we know enough about the user to log them in. > >>> > >>> I currently try to use UserManager.setUserProfile in this > situation. Now > >>> here comes my Problem: > >>> > >>> I would like to do all the assertion verifiaction in a JAAS-Module, > but > >>> for that I need all the request > >>> data, which I do not have in the setUserProfile-Method. > >>> > >>> So currently I am stuck. Before I start to wildly mess the API: Am > I > >>> taking the right direction? > >>> > >>> > >>> Tilman Bender > >>> Student des Software Engineering > >>> Hochschule Heilbronn > >>> tbender@stud.hs-heilbronn.de > >>> > >>> > >>> > >>> Am 03.12.2008 um 21:50 schrieb Janne Jalkanen: > >>> > >>>> Hi! > >>>> > >>>> Thanks for the effort - sounds like a worthy project! > >>>> > >>>> I think you will save yourself a lot of grief if you work on the > 2.8.1 > >>>> branch, since the trunk is now the subject of a lot of changes - > but note > >>>> that we *will* be making some rather major changes for 3.0, so you > may face > >>>> a small porting effort towards the end. We certainly wouldn't > like to land > >>>> a major feature in 2.8 branch anymore, since it's rather stable. > >>>> > >>>> I think the first thing you could do is to outline your plan as to > how > >>>> exactly are you planning to hook into our structures - a good > place to start > >>>> is probably the Security documentation at > >>>> http://doc.jspwiki.org/2.8/wiki/Security, and then asking a lot of > questions > >>>> on this mailing list. > >>>> > >>>> Also, since we are talking about a fairly large project here, you > might > >>>> want to sign a contributor license agreement (CLA), and depending > on the > >>>> German copyright legislation, get also Heilbronn to sign a > corporate CLA. > >>>> That, or Heilbronn (or you) need to, at the end of the project, > give a > >>>> software grant (SGA) to Apache Software Foundation. But these are > not > >>>> biggies and can be tackled if/when we start merging ;-) > >>>> > >>>> /Janne > >>>> > >>>> On Dec 3, 2008, at 21:25 , Tilman Bender wrote: > >>>> > >>>>> Hi JSPWiki Devs, > >>>>> > >>>>> I am a student at Heilbronn University in Germany (Some of you > might > >>>>> know Christoph Sauer, who worked there.) > >>>>> As pre-thesis for my diploma I want to enhance JSPWiki with > OpenID. > >>>>> > >>>>> I am still pretty new to JSPWIki, OpenID and JAAS. > >>>>> I have worked my way through the official OpenID 2.0 > Authentication > >>>>> standard > >>>>> and will do as well for Attributes Exchange. > >>>>> > >>>>> I would like to base my work on the 2.8.1 tag and > >>>>> see to get it integrate into the trunk later. Is that the correct > way > >>>>> to do it? > >>>>> > >>>>> As I see Andrew already spent quite some time on OpenID and did > some > >>>>> preparations. > >>>>> Since I plan to get my diploma somday soon (say in 2009 ;-)), I > have a > >>>>> high personal interest > >>>>> in getting OpenID into JSPWiki. > >>>>> > >>>>> Summary: > >>>>> > >>>>> * I have time > >>>>> * I have motivation > >>>>> * I need some help to get started ;-) > >>>>> > >>>>> Any suggestions where to begin? I guess registration/profile > creation > >>>>> would be first. > >>>>> > >>>>> kind regards > >>>>> > >>>>> > >>>>> Tilman Bender > >>>>> Student des Software Engineering > >>>>> Hochschule Heilbronn > >>>>> tbender@stud.hs-heilbronn.de > >>>>> > >>>>> > >>>> > >>> > > > > > > ------------------------------------------------------- Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische Information mbH. Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892. Geschäftsführerin: Sabine Brünger-Weilandt. Vorsitzender des Aufsichtsrats: MinR Hermann Riehl.
This might work counterproductive: Once users find out this can be overruled,
the maximum setting will have lost its enforcing power and they will try to find
to get out of the limit themselves. (Possible by harrasing the admin until she
uploads the offending attachments.)
-----Original Message-----
From: Jürgen Weber (JIRA) [mailto:jira@apache.org]
Sent: dinsdag 8 december 2009 14:55
To: jspwiki-dev@incubator.apache.org
Subject: [jira] Created: (JSPWIKI-618) Allow Administrators to override attachment.maxsize
Allow Administrators to override attachment.maxsize
---------------------------------------------------
Key: JSPWIKI-618
URL: https://issues.apache.org/jira/browse/JSPWIKI-618
Project: JSPWiki
Issue Type: Improvement
Components: Core & storage
Reporter: Jürgen Weber
I think limiting attachment sizes is a good thing.
But Administrators should be able to override it, i.e. be able to upload bigger attachments
than attachment.maxsize.
Workaround: temporarily remove attachment.maxsize
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Allow Administrators to override attachment.maxsize
---------------------------------------------------
Key: JSPWIKI-618
URL: https://issues.apache.org/jira/browse/JSPWIKI-618
Project: JSPWiki
Issue Type: Improvement
Components: Core & storage
Reporter: Jürgen Weber
I think limiting attachment sizes is a good thing.
But Administrators should be able to override it, i.e. be able to upload bigger attachments
than attachment.maxsize.
Workaround: temporarily remove attachment.maxsize
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harry Metske resolved JSPWIKI-617.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.8.4
Assignee: Harry Metske
Fixed in 2.8.4-svn-4
> Attachments unsearchable after renaming a page
> -----------------------------------------------
>
> Key: JSPWIKI-617
> URL: https://issues.apache.org/jira/browse/JSPWIKI-617
> Project: JSPWiki
> Issue Type: Bug
> Environment: Apache Tomcat 5.5.28 Server
> JSPWiki 2.8.3
> Reporter: Benedict Xu
> Assignee: Harry Metske
> Fix For: 2.8.4
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> After renaming a page, all its attachments become unsearchable, but newly uploaded attachment
is searchable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Attachments unsearchable after renaming a page
-----------------------------------------------
Key: JSPWIKI-617
URL: https://issues.apache.org/jira/browse/JSPWIKI-617
Project: JSPWiki
Issue Type: Bug
Environment: Apache Tomcat 5.5.28 Server
JSPWiki 2.8.3
Reporter: Benedict Xu
After renaming a page, all its attachments become unsearchable, but newly uploaded attachment
is searchable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janne Jalkanen resolved JSPWIKI-616.
------------------------------------
Resolution: Fixed
Fix Version/s: 3.0
Fixed in 3.0.0-svn-189
> WikiPageEvent should use WikiPath instead of String
> ---------------------------------------------------
>
> Key: JSPWIKI-616
> URL: https://issues.apache.org/jira/browse/JSPWIKI-616
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core & storage
> Affects Versions: 3.0
> Reporter: Janne Jalkanen
> Assignee: Janne Jalkanen
> Fix For: 3.0
>
>
> To allow for wikispace events to occur, WikiPageEvent should utilize WikiPath as the
page identifier instead of String. That, or an UUID, but I think WikiPath is nicer from the
debug point of view. UUIDs should be used for long-term storage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
No need, it's solved in the current trunk :) /Janne On Nov 29, 2009, at 18:53 , Craig L Russell wrote: > Or file a JIRA. > > Craig > > On Nov 29, 2009, at 2:37 AM, Harry Metske wrote: > >> I like to see it too, please email, or maybe stick it somewhere on >> www.jspwiki.org >> >> regards, >> Harry >> >> 2009/11/29 Janne Jalkanen <Janne.Jalkanen@ecyrd.com> >> >>> >>> Sent it to you directly - others, let me know if you want to see it. >>> >>> Well, we've got JSPWikiTestBase class, which extends TestCase. So >>> we could >>> use that as well and just start extending our tests from it >>> instead directly >>> from TestCase. >>> >>> /Janne >>> >>> >>> On Nov 29, 2009, at 00:52 , Andrew Jaquith wrote: >>> >>> Janne, I think your attachment got stripped out. Can you re-send >>>> (maybe directly?) >>>> >>>> I agree that we ought to figure out some way of using some sort of >>>> singleton (or singleton-per-wikiengine) object to stash the >>>> results of >>>> findImplementations(). Not sure how this would work with JUnit, >>>> though >>>> -- I should do some research. What we'd need is the ability to >>>> create >>>> test fixture objects that persist across the entire run... >>>> >>>> Andrew >>>> >>>> On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen >>>> <Janne.Jalkanen@ecyrd.com> wrote: >>>> >>>>> Folks, here's a screenshot from JProfiler. This should explain >>>>> why our >>>>> tests are fairly slow... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Simply put; we're not using EhCache, and also we're calling >>>>> Stripes >>>>> ResolverUtil.findImplementations twice per WikiEngine startup. >>>>> So it >>>>> might >>>>> make sense to move findImplementations() calls into a singleton or >>>>> something. But I'm not too sure whether it makes sense >>>>> considering >>>>> restarts >>>>> - or perhaps restarts should clean away the singleton cache? >>>>> >>>>> (This is after about 700 tests were run; I didn't want to wait >>>>> until they >>>>> had all finished, since it had already taken about two hours with >>>>> profiling >>>>> on...) >>>>> >>>>> Priha can be seen taking quite a lot of time as well, but that's >>>>> because >>>>> it >>>>> needs to hit the disk all the time. More optimization for >>>>> FileProvider >>>>> is >>>>> needed, but partly it's also because we're not caching anything. >>>>> >>>>> /Janne >>>>> >>>>> >>> > > Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:Craig.Russell@sun.com > P.S. A good JDO? O, Gasp! >
[ https://issues.apache.org/jira/browse/JSPWIKI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek resolved JSPWIKI-614.
---------------------------
Resolution: Not A Problem
Thanks that work's a treat. Have marked this a resolved.
> Create a Piwik plugin
> ----------------------
>
> Key: JSPWIKI-614
> URL: https://issues.apache.org/jira/browse/JSPWIKI-614
> Project: JSPWiki
> Issue Type: New Feature
> Components: Plugins
> Reporter: Derek
> Priority: Minor
>
> Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of
users through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784993#action_12784993
]
Harry Metske commented on JSPWIKI-614:
--------------------------------------
localheader.jsp is a dummy jsp that is intended for this purpose, as mentioned in the comment
of it :
{noformat}
<%-- This is a local JSP header file, which you can override in your own template
if you want to put something in the head-section of the page. This page is
included after the commonheader.jsp.
The JSPWiki default template and distribution will never have anything here
except this comment. Therefore it's safe to override without accidentally
removing any functionality.
Some things which you might want to put here would e.g. be your site tracker
Javascript (like Google Analytics, or Sitemeter, or whatever).
The safest trick would be to create your own template (say "sitetemplate") directory,
and just put a new localheader.jsp in it. JSPWiki will always use the
files in the "default" template, if it cannot locate an equivalent file in
your defined template directory.
--%>
{noformat}
As an admin you can stick in the right piwik standard js in here with the required parameters.
> Create a Piwik plugin
> ----------------------
>
> Key: JSPWIKI-614
> URL: https://issues.apache.org/jira/browse/JSPWIKI-614
> Project: JSPWiki
> Issue Type: New Feature
> Components: Plugins
> Reporter: Derek
> Priority: Minor
>
> Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of
users through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784710#action_12784710
]
Derek commented on JSPWIKI-614:
-------------------------------
Your assumption is correct. I'm looking for something that allows me to define a site id,
Piwik server and port and have that included in the localheader.jsp. Either that or a means,
via an admin screen, to allow the admin to include the Piwik provided javascript that would
be included in each page.
Example of the standard js is as follows:
<!-- Piwik -->
<script type="text/javascript">
var pkBaseURL = (("https:" == document.location.protocol) ? "https://{$PIWIK_URL}" : "http://{$PIWIK_URL}");
document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
</script><script type="text/javascript">
try {
var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", {$IDSITE});
piwikTracker.trackPageView();
piwikTracker.enableLinkTracking();
} catch( err ) {}
</script>
<!-- End Piwik Tag -->
> Create a Piwik plugin
> ----------------------
>
> Key: JSPWIKI-614
> URL: https://issues.apache.org/jira/browse/JSPWIKI-614
> Project: JSPWiki
> Issue Type: New Feature
> Components: Plugins
> Reporter: Derek
> Priority: Minor
>
> Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of
users through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The fix is in the trunk now. Not everything is working yet; I'm seeing oddities with page content (e.g. WikiengineTest.deleteVersion()), but I think those are fairly easy to figure out now. /Janne On Dec 1, 2009, at 23:51 , Janne Jalkanen wrote: > > Got it. JCRWikiPage.getJCRNode() creates the page if it does not > exist. This has the unfortunate side effect that *any* calls to > WikiPage after it has been deleted do not result in exceptions, but > they do result in a new Node being created, which in turn screws up > quite a lot of stuff... > > The fun thing is, the commit was marked as "now all unit tests > run" ;-) > > /Janne > > On Dec 1, 2009, at 19:59 , Andrew Jaquith wrote: > >> The easy way to test this hypothesis, which is an interesting one, >> would be to unhook the ReferenceManager event listener and see if it >> makes a difference. The RefMgr tests will fail, but perhaps some of >> the other failing tests will succeed. >> >> Generally, though, we should definitely do one of two things: either >> create a separate "updater" JCR session for the ReferenceManager >> event >> listener, and have it do its own saves, OR remove all save()s from >> ReferenceManager entirely. Right now it does saves in the context of >> the caller's JCR session, which doesn't feel right. >> >> Andrew >> >> On Tue, Dec 1, 2009 at 11:25 AM, Janne Jalkanen >> <Janne.Jalkanen@ecyrd.com> wrote: >>> >>> The test seems correct. There seems to be something fairly odd >>> going on >>> with respect to versioning; for example, >>> ContentManagerTest.deleteAllPages() >>> fails because it deletes all pages ok, but at the last instant it >>> recreates >>> the pages as empty. >>> >>> My guess is that it was a bug in ContentManager that priha 0.6.x >>> revealed; >>> and I also have a nagging suspicion it has something to do with >>> ReferenceManager, as it seems to me that the pages are recreated >>> by the >>> event handlers as a side effect. This could happen if the page is >>> first >>> deleted, then save()d, then a event handler adds a property to it >>> and >>> recreates the Node as a sanity check or something. Haven't yet had >>> time to >>> peek into it very deeply. >>> >>> /Janne >>> >>> On Dec 1, 2009, at 15:44 , Andrew Jaquith wrote: >>> >>>> Janne, can I get a quick sanity check on something? >>>> >>>> // Save two versions of the test page >>>> m_engine.saveText( "Test", "This is the first version" ); >>>> m_engine.saveText( "Test", "This is the second version" ); >>>> >>>> // Make sure they both saved ok >>>> WikiPage v1 = m_engine.getPage( "Test", 1 ); >>>> WikiPage v2 = m_engine.getPage( "Test", 2 ); >>>> assertNotNull( "Did not save page Test, v1!", v1 ); >>>> assertNotNull( "Did not save page Test, v2!", v2 ); >>>> assertEquals( "This is the first version", >>>> m_engine.getPureText( v1 ).trim() ); >>>> >>>> The last assertion is failing. When WikiEngine.getPureText(v1) is >>>> called, it is returning "This is the second version", which seems >>>> wrong . It should return the first version, right? >>>> >>>> Back when the trunk tests all ran clean (aka "the good old days"), >>>> this test worked also. So it seems to me that some recent changes >>>> caused the results to change. So was the test wrong all along, or >>>> is >>>> there a bug somewhere? >>>> >>>> Andrew >>> >>>
Got it. JCRWikiPage.getJCRNode() creates the page if it does not exist. This has the unfortunate side effect that *any* calls to WikiPage after it has been deleted do not result in exceptions, but they do result in a new Node being created, which in turn screws up quite a lot of stuff... The fun thing is, the commit was marked as "now all unit tests run" ;-) /Janne On Dec 1, 2009, at 19:59 , Andrew Jaquith wrote: > The easy way to test this hypothesis, which is an interesting one, > would be to unhook the ReferenceManager event listener and see if it > makes a difference. The RefMgr tests will fail, but perhaps some of > the other failing tests will succeed. > > Generally, though, we should definitely do one of two things: either > create a separate "updater" JCR session for the ReferenceManager event > listener, and have it do its own saves, OR remove all save()s from > ReferenceManager entirely. Right now it does saves in the context of > the caller's JCR session, which doesn't feel right. > > Andrew > > On Tue, Dec 1, 2009 at 11:25 AM, Janne Jalkanen > <Janne.Jalkanen@ecyrd.com> wrote: >> >> The test seems correct. There seems to be something fairly odd >> going on >> with respect to versioning; for example, >> ContentManagerTest.deleteAllPages() >> fails because it deletes all pages ok, but at the last instant it >> recreates >> the pages as empty. >> >> My guess is that it was a bug in ContentManager that priha 0.6.x >> revealed; >> and I also have a nagging suspicion it has something to do with >> ReferenceManager, as it seems to me that the pages are recreated by >> the >> event handlers as a side effect. This could happen if the page is >> first >> deleted, then save()d, then a event handler adds a property to it and >> recreates the Node as a sanity check or something. Haven't yet had >> time to >> peek into it very deeply. >> >> /Janne >> >> On Dec 1, 2009, at 15:44 , Andrew Jaquith wrote: >> >>> Janne, can I get a quick sanity check on something? >>> >>> // Save two versions of the test page >>> m_engine.saveText( "Test", "This is the first version" ); >>> m_engine.saveText( "Test", "This is the second version" ); >>> >>> // Make sure they both saved ok >>> WikiPage v1 = m_engine.getPage( "Test", 1 ); >>> WikiPage v2 = m_engine.getPage( "Test", 2 ); >>> assertNotNull( "Did not save page Test, v1!", v1 ); >>> assertNotNull( "Did not save page Test, v2!", v2 ); >>> assertEquals( "This is the first version", >>> m_engine.getPureText( v1 ).trim() ); >>> >>> The last assertion is failing. When WikiEngine.getPureText(v1) is >>> called, it is returning "This is the second version", which seems >>> wrong . It should return the first version, right? >>> >>> Back when the trunk tests all ran clean (aka "the good old days"), >>> this test worked also. So it seems to me that some recent changes >>> caused the results to change. So was the test wrong all along, or is >>> there a bug somewhere? >>> >>> Andrew >> >>
[ https://issues.apache.org/jira/browse/JSPWIKI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784315#action_12784315
]
Harry Metske commented on JSPWIKI-614:
--------------------------------------
We first need to make clear what a "plugin" is:
- piwik has different types of plugins, plugins that generate the piwik javascript tag, and
plugins on the piwik server for all kinds of functionality like for instance a translator
plugin
- a JSPWiki plugin is a piece of code that gets executed whenever you include it's name in
a page [{MyWonderFullPlugin}]
My assumption is that you need something in JSPWiki that generated the piwik javascript tag
in all html generated by JSPWiki, in that case a jspwiki plugin is not appropriate (you don;t
want to stick plugin tags on every page)
I think we already have something like that for Google Analytics, it is a modification on
localheader.jsp I think, for piwik you could do the same.
Is this my correct understanding ?
> Create a Piwik plugin
> ----------------------
>
> Key: JSPWIKI-614
> URL: https://issues.apache.org/jira/browse/JSPWIKI-614
> Project: JSPWiki
> Issue Type: New Feature
> Components: Plugins
> Reporter: Derek
> Priority: Minor
>
> Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of
users through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The easy way to test this hypothesis, which is an interesting one, would be to unhook the ReferenceManager event listener and see if it makes a difference. The RefMgr tests will fail, but perhaps some of the other failing tests will succeed. Generally, though, we should definitely do one of two things: either create a separate "updater" JCR session for the ReferenceManager event listener, and have it do its own saves, OR remove all save()s from ReferenceManager entirely. Right now it does saves in the context of the caller's JCR session, which doesn't feel right. Andrew On Tue, Dec 1, 2009 at 11:25 AM, Janne Jalkanen <Janne.Jalkanen@ecyrd.com> wrote: > > The test seems correct. There seems to be something fairly odd going on > with respect to versioning; for example, ContentManagerTest.deleteAllPages() > fails because it deletes all pages ok, but at the last instant it recreates > the pages as empty. > > My guess is that it was a bug in ContentManager that priha 0.6.x revealed; > and I also have a nagging suspicion it has something to do with > ReferenceManager, as it seems to me that the pages are recreated by the > event handlers as a side effect. This could happen if the page is first > deleted, then save()d, then a event handler adds a property to it and > recreates the Node as a sanity check or something. Haven't yet had time to > peek into it very deeply. > > /Janne > > On Dec 1, 2009, at 15:44 , Andrew Jaquith wrote: > >> Janne, can I get a quick sanity check on something? >> >> // Save two versions of the test page >> m_engine.saveText( "Test", "This is the first version" ); >> m_engine.saveText( "Test", "This is the second version" ); >> >> // Make sure they both saved ok >> WikiPage v1 = m_engine.getPage( "Test", 1 ); >> WikiPage v2 = m_engine.getPage( "Test", 2 ); >> assertNotNull( "Did not save page Test, v1!", v1 ); >> assertNotNull( "Did not save page Test, v2!", v2 ); >> assertEquals( "This is the first version", >> m_engine.getPureText( v1 ).trim() ); >> >> The last assertion is failing. When WikiEngine.getPureText(v1) is >> called, it is returning "This is the second version", which seems >> wrong . It should return the first version, right? >> >> Back when the trunk tests all ran clean (aka "the good old days"), >> this test worked also. So it seems to me that some recent changes >> caused the results to change. So was the test wrong all along, or is >> there a bug somewhere? >> >> Andrew > >
The test seems correct. There seems to be something fairly odd going on with respect to versioning; for example, ContentManagerTest.deleteAllPages() fails because it deletes all pages ok, but at the last instant it recreates the pages as empty. My guess is that it was a bug in ContentManager that priha 0.6.x revealed; and I also have a nagging suspicion it has something to do with ReferenceManager, as it seems to me that the pages are recreated by the event handlers as a side effect. This could happen if the page is first deleted, then save()d, then a event handler adds a property to it and recreates the Node as a sanity check or something. Haven't yet had time to peek into it very deeply. /Janne On Dec 1, 2009, at 15:44 , Andrew Jaquith wrote: > Janne, can I get a quick sanity check on something? > > // Save two versions of the test page > m_engine.saveText( "Test", "This is the first version" ); > m_engine.saveText( "Test", "This is the second version" ); > > // Make sure they both saved ok > WikiPage v1 = m_engine.getPage( "Test", 1 ); > WikiPage v2 = m_engine.getPage( "Test", 2 ); > assertNotNull( "Did not save page Test, v1!", v1 ); > assertNotNull( "Did not save page Test, v2!", v2 ); > assertEquals( "This is the first version", > m_engine.getPureText( v1 ).trim() ); > > The last assertion is failing. When WikiEngine.getPureText(v1) is > called, it is returning "This is the second version", which seems > wrong . It should return the first version, right? > > Back when the trunk tests all ran clean (aka "the good old days"), > this test worked also. So it seems to me that some recent changes > caused the results to change. So was the test wrong all along, or is > there a bug somewhere? > > Andrew
Janne, can I get a quick sanity check on something?
// Save two versions of the test page
m_engine.saveText( "Test", "This is the first version" );
m_engine.saveText( "Test", "This is the second version" );
// Make sure they both saved ok
WikiPage v1 = m_engine.getPage( "Test", 1 );
WikiPage v2 = m_engine.getPage( "Test", 2 );
assertNotNull( "Did not save page Test, v1!", v1 );
assertNotNull( "Did not save page Test, v2!", v2 );
assertEquals( "This is the first version",
m_engine.getPureText( v1 ).trim() );
The last assertion is failing. When WikiEngine.getPureText(v1) is
called, it is returning "This is the second version", which seems
wrong . It should return the first version, right?
Back when the trunk tests all ran clean (aka "the good old days"),
this test worked also. So it seems to me that some recent changes
caused the results to change. So was the test wrong all along, or is
there a bug somewhere?
Andrew
WikiPageEvent should use WikiPath instead of String
---------------------------------------------------
Key: JSPWIKI-616
URL: https://issues.apache.org/jira/browse/JSPWIKI-616
Project: JSPWiki
Issue Type: Improvement
Components: Core & storage
Affects Versions: 3.0
Reporter: Janne Jalkanen
To allow for wikispace events to occur, WikiPageEvent should utilize WikiPath as the page
identifier instead of String. That, or an UUID, but I think WikiPath is nicer from the debug
point of view. UUIDs should be used for long-term storage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The event documentation needs to document parameters too
--------------------------------------------------------
Key: JSPWIKI-615
URL: https://issues.apache.org/jira/browse/JSPWIKI-615
Project: JSPWiki
Issue Type: Improvement
Components: Documentation & website
Affects Versions: 3.0
Reporter: Janne Jalkanen
Priority: Trivial
The event classes in org.apache.wiki.event don't describe what parameters each event expects
or uses, therefore making using them pretty much guesswork at RTFS level.
A simple task to improve, but let's make a note here lest we forget.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Or file a JIRA. Craig On Nov 29, 2009, at 2:37 AM, Harry Metske wrote: > I like to see it too, please email, or maybe stick it somewhere on > www.jspwiki.org > > regards, > Harry > > 2009/11/29 Janne Jalkanen <Janne.Jalkanen@ecyrd.com> > >> >> Sent it to you directly - others, let me know if you want to see it. >> >> Well, we've got JSPWikiTestBase class, which extends TestCase. So >> we could >> use that as well and just start extending our tests from it instead >> directly >> from TestCase. >> >> /Janne >> >> >> On Nov 29, 2009, at 00:52 , Andrew Jaquith wrote: >> >> Janne, I think your attachment got stripped out. Can you re-send >>> (maybe directly?) >>> >>> I agree that we ought to figure out some way of using some sort of >>> singleton (or singleton-per-wikiengine) object to stash the >>> results of >>> findImplementations(). Not sure how this would work with JUnit, >>> though >>> -- I should do some research. What we'd need is the ability to >>> create >>> test fixture objects that persist across the entire run... >>> >>> Andrew >>> >>> On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen >>> <Janne.Jalkanen@ecyrd.com> wrote: >>> >>>> Folks, here's a screenshot from JProfiler. This should explain >>>> why our >>>> tests are fairly slow... >>>> >>>> >>>> >>>> >>>> >>>> Simply put; we're not using EhCache, and also we're calling Stripes >>>> ResolverUtil.findImplementations twice per WikiEngine startup. >>>> So it >>>> might >>>> make sense to move findImplementations() calls into a singleton or >>>> something. But I'm not too sure whether it makes sense considering >>>> restarts >>>> - or perhaps restarts should clean away the singleton cache? >>>> >>>> (This is after about 700 tests were run; I didn't want to wait >>>> until they >>>> had all finished, since it had already taken about two hours with >>>> profiling >>>> on...) >>>> >>>> Priha can be seen taking quite a lot of time as well, but that's >>>> because >>>> it >>>> needs to hit the disk all the time. More optimization for >>>> FileProvider >>>> is >>>> needed, but partly it's also because we're not caching anything. >>>> >>>> /Janne >>>> >>>> >> Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
I like to see it too, please email, or maybe stick it somewhere on www.jspwiki.org regards, Harry 2009/11/29 Janne Jalkanen <Janne.Jalkanen@ecyrd.com> > > Sent it to you directly - others, let me know if you want to see it. > > Well, we've got JSPWikiTestBase class, which extends TestCase. So we could > use that as well and just start extending our tests from it instead directly > from TestCase. > > /Janne > > > On Nov 29, 2009, at 00:52 , Andrew Jaquith wrote: > > Janne, I think your attachment got stripped out. Can you re-send >> (maybe directly?) >> >> I agree that we ought to figure out some way of using some sort of >> singleton (or singleton-per-wikiengine) object to stash the results of >> findImplementations(). Not sure how this would work with JUnit, though >> -- I should do some research. What we'd need is the ability to create >> test fixture objects that persist across the entire run... >> >> Andrew >> >> On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen >> <Janne.Jalkanen@ecyrd.com> wrote: >> >>> Folks, here's a screenshot from JProfiler. This should explain why our >>> tests are fairly slow... >>> >>> >>> >>> >>> >>> Simply put; we're not using EhCache, and also we're calling Stripes >>> ResolverUtil.findImplementations twice per WikiEngine startup. So it >>> might >>> make sense to move findImplementations() calls into a singleton or >>> something. But I'm not too sure whether it makes sense considering >>> restarts >>> - or perhaps restarts should clean away the singleton cache? >>> >>> (This is after about 700 tests were run; I didn't want to wait until they >>> had all finished, since it had already taken about two hours with >>> profiling >>> on...) >>> >>> Priha can be seen taking quite a lot of time as well, but that's because >>> it >>> needs to hit the disk all the time. More optimization for FileProvider >>> is >>> needed, but partly it's also because we're not caching anything. >>> >>> /Janne >>> >>> >
I've been thinking about moving to JUnit4, but so far there hasn't really been a compelling reason. This could be it... One possible way could of course to be to override the Stripes default implementation for tests. That would make it fairly fast. /Janne On Nov 29, 2009, at 01:22 , Andrew Jaquith wrote: > Looks like if we used JUnit 4, we could use methods annotated with > @BeforeClass to set up fixtures that would persist between tests in a > single test class. We'd get a lot of savings in classes like > JSPWikiMarkupParserTest that have 200 tests, for example. > > Also, I've investigated (a little) methods for reducing the need to > run ResolverUtil. We would probably still need to run it at least > twice: once for all of JSPWiki's needs, and once for Stripes itself. > But we'd need some way of registering "interest" in particular classes > to discover, so that it could all be done in one pass. I wrote the > class org.apache.wiki.ui.stripes.IsOneOf exactly for this purpose > (match against multiple target classes), but it's not optimized for > speed yet. > > Andrew > > On Sat, Nov 28, 2009 at 5:52 PM, Andrew Jaquith > <andrew.r.jaquith@gmail.com> wrote: >> Janne, I think your attachment got stripped out. Can you re-send >> (maybe directly?) >> >> I agree that we ought to figure out some way of using some sort of >> singleton (or singleton-per-wikiengine) object to stash the results >> of >> findImplementations(). Not sure how this would work with JUnit, >> though >> -- I should do some research. What we'd need is the ability to create >> test fixture objects that persist across the entire run... >> >> Andrew >> >> On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen >> <Janne.Jalkanen@ecyrd.com> wrote: >>> Folks, here's a screenshot from JProfiler. This should explain >>> why our >>> tests are fairly slow... >>> >>> >>> >>> >>> >>> Simply put; we're not using EhCache, and also we're calling Stripes >>> ResolverUtil.findImplementations twice per WikiEngine startup. So >>> it might >>> make sense to move findImplementations() calls into a singleton or >>> something. But I'm not too sure whether it makes sense >>> considering restarts >>> - or perhaps restarts should clean away the singleton cache? >>> >>> (This is after about 700 tests were run; I didn't want to wait >>> until they >>> had all finished, since it had already taken about two hours with >>> profiling >>> on...) >>> >>> Priha can be seen taking quite a lot of time as well, but that's >>> because it >>> needs to hit the disk all the time. More optimization for >>> FileProvider is >>> needed, but partly it's also because we're not caching anything. >>> >>> /Janne >>> >>
Sent it to you directly - others, let me know if you want to see it. Well, we've got JSPWikiTestBase class, which extends TestCase. So we could use that as well and just start extending our tests from it instead directly from TestCase. /Janne On Nov 29, 2009, at 00:52 , Andrew Jaquith wrote: > Janne, I think your attachment got stripped out. Can you re-send > (maybe directly?) > > I agree that we ought to figure out some way of using some sort of > singleton (or singleton-per-wikiengine) object to stash the results of > findImplementations(). Not sure how this would work with JUnit, though > -- I should do some research. What we'd need is the ability to create > test fixture objects that persist across the entire run... > > Andrew > > On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen > <Janne.Jalkanen@ecyrd.com> wrote: >> Folks, here's a screenshot from JProfiler. This should explain why >> our >> tests are fairly slow... >> >> >> >> >> >> Simply put; we're not using EhCache, and also we're calling Stripes >> ResolverUtil.findImplementations twice per WikiEngine startup. So >> it might >> make sense to move findImplementations() calls into a singleton or >> something. But I'm not too sure whether it makes sense considering >> restarts >> - or perhaps restarts should clean away the singleton cache? >> >> (This is after about 700 tests were run; I didn't want to wait >> until they >> had all finished, since it had already taken about two hours with >> profiling >> on...) >> >> Priha can be seen taking quite a lot of time as well, but that's >> because it >> needs to hit the disk all the time. More optimization for >> FileProvider is >> needed, but partly it's also because we're not caching anything. >> >> /Janne >>
Looks like if we used JUnit 4, we could use methods annotated with @BeforeClass to set up fixtures that would persist between tests in a single test class. We'd get a lot of savings in classes like JSPWikiMarkupParserTest that have 200 tests, for example. Also, I've investigated (a little) methods for reducing the need to run ResolverUtil. We would probably still need to run it at least twice: once for all of JSPWiki's needs, and once for Stripes itself. But we'd need some way of registering "interest" in particular classes to discover, so that it could all be done in one pass. I wrote the class org.apache.wiki.ui.stripes.IsOneOf exactly for this purpose (match against multiple target classes), but it's not optimized for speed yet. Andrew On Sat, Nov 28, 2009 at 5:52 PM, Andrew Jaquith <andrew.r.jaquith@gmail.com> wrote: > Janne, I think your attachment got stripped out. Can you re-send > (maybe directly?) > > I agree that we ought to figure out some way of using some sort of > singleton (or singleton-per-wikiengine) object to stash the results of > findImplementations(). Not sure how this would work with JUnit, though > -- I should do some research. What we'd need is the ability to create > test fixture objects that persist across the entire run... > > Andrew > > On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen > <Janne.Jalkanen@ecyrd.com> wrote: >> Folks, here's a screenshot from JProfiler. This should explain why our >> tests are fairly slow... >> >> >> >> >> >> Simply put; we're not using EhCache, and also we're calling Stripes >> ResolverUtil.findImplementations twice per WikiEngine startup. So it might >> make sense to move findImplementations() calls into a singleton or >> something. But I'm not too sure whether it makes sense considering restarts >> - or perhaps restarts should clean away the singleton cache? >> >> (This is after about 700 tests were run; I didn't want to wait until they >> had all finished, since it had already taken about two hours with profiling >> on...) >> >> Priha can be seen taking quite a lot of time as well, but that's because it >> needs to hit the disk all the time. More optimization for FileProvider is >> needed, but partly it's also because we're not caching anything. >> >> /Janne >> >
Janne, I think your attachment got stripped out. Can you re-send (maybe directly?) I agree that we ought to figure out some way of using some sort of singleton (or singleton-per-wikiengine) object to stash the results of findImplementations(). Not sure how this would work with JUnit, though -- I should do some research. What we'd need is the ability to create test fixture objects that persist across the entire run... Andrew On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen <Janne.Jalkanen@ecyrd.com> wrote: > Folks, here's a screenshot from JProfiler. This should explain why our > tests are fairly slow... > > > > > > Simply put; we're not using EhCache, and also we're calling Stripes > ResolverUtil.findImplementations twice per WikiEngine startup. So it might > make sense to move findImplementations() calls into a singleton or > something. But I'm not too sure whether it makes sense considering restarts > - or perhaps restarts should clean away the singleton cache? > > (This is after about 700 tests were run; I didn't want to wait until they > had all finished, since it had already taken about two hours with profiling > on...) > > Priha can be seen taking quite a lot of time as well, but that's because it > needs to hit the disk all the time. More optimization for FileProvider is > needed, but partly it's also because we're not caching anything. > > /Janne >
Folks, here's a screenshot from JProfiler. This should explain why our tests are fairly slow...
Folks, there seems to be a bigger issue with the trunk right now. I patched some things, but it's somehow related to the way we do repository delete - i.e. when we call TestEngine.emptyRepository() it looks like some pages exist which should be there. I would normally blame Priha, but in this case it's odd because Priha's own unit tests are running nicely. And not all JSPWiki tests are failing either. More testing would be good to isolate the problem... /Janne
Thanks Dirk! (BTW it does affect the current trunk) On Nov 25, 2009, at 13:24, Dirk Frederickx <dirk.frederickx@gmail.com> wrote: > Andrew, > > I'll try to look into it over the weekend. Latest v3.x version ? > > dirk > > On Wed, Nov 25, 2009 at 12:52 PM, Andrew Jaquith <andrew.r.jaquith@gmail.com >> wrote: > >> Well, sort of. >> >> It has something to do with JavaScript. If I turn off JavaScript, >> when >> I edit a page (create a second version), the text is replaced with >> what's in the textarea. If JS is on, the previous and new text are >> concatenated. >> >> Weird! Dirk, any hints? >> >> Andrew >>
yep, the current trunk still has the problem. (good catch BTW Andrew) regards, Harry 2009/11/25 Dirk Frederickx <dirk.frederickx@gmail.com> > Andrew, > > I'll try to look into it over the weekend. Latest v3.x version ? > > dirk > > On Wed, Nov 25, 2009 at 12:52 PM, Andrew Jaquith < > andrew.r.jaquith@gmail.com > > wrote: > > > Well, sort of. > > > > It has something to do with JavaScript. If I turn off JavaScript, when > > I edit a page (create a second version), the text is replaced with > > what's in the textarea. If JS is on, the previous and new text are > > concatenated. > > > > Weird! Dirk, any hints? > > > > Andrew > > >
Andrew, I'll try to look into it over the weekend. Latest v3.x version ? dirk On Wed, Nov 25, 2009 at 12:52 PM, Andrew Jaquith <andrew.r.jaquith@gmail.com > wrote: > Well, sort of. > > It has something to do with JavaScript. If I turn off JavaScript, when > I edit a page (create a second version), the text is replaced with > what's in the textarea. If JS is on, the previous and new text are > concatenated. > > Weird! Dirk, any hints? > > Andrew >
Well, sort of. It has something to do with JavaScript. If I turn off JavaScript, when I edit a page (create a second version), the text is replaced with what's in the textarea. If JS is on, the previous and new text are concatenated. Weird! Dirk, any hints? Andrew
[ https://issues.apache.org/jira/browse/JSPWIKI-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782166#action_12782166
]
Dirk Frederickx commented on JSPWIKI-613:
-----------------------------------------
Well, the [Edit] link is indeed generated client-side through some javascript.
It could be made a bit smarter and use the encoded page-name in the section header anchors.
But there is a little problem...
Format of a section header :
{noformat} #section-pagename-headertitle {noformat}
However, it the page is called Test-Test:
{noformat} #section-Test-Test-headertitle {noformat}
We will need to use a special separator between the encoded page-name and the remaining header
title.
That will allow to jump to the inserted page instead.
Alternatively, we could put the page-name of the included page in another attribute of the
anchor (rel='...' ?)
dirk
dirk
> InsertPage plugin and the feature of section editing do not fit together
> ------------------------------------------------------------------------
>
> Key: JSPWIKI-613
> URL: https://issues.apache.org/jira/browse/JSPWIKI-613
> Project: JSPWiki
> Issue Type: Bug
> Components: Plugins
> Affects Versions: 2.8.3
> Environment: Current versions of Windows XP and Firefox running in a virtual
machine of VMWare Fusion on a Mac Server
> Reporter: Mario Lotz
> Priority: Minor
>
> I often used the *InsertPage plugin* to separate structure of my presentation from the
content. Normaly I include pages into tabbed sections to give my users a single point of entry
to the same kind of information.
> If the *section editing feature* is enabled the rendered *edit links* are pointing to
the {color:red}_including_{color} page instead of the {color:red}_included_{color} ones.
> I assume, that the links are added to the page after the includes are done. To fix the
wrong links, the edit links have to be inserted for each included page independent of the
parent and with a separate heading counter.
> This is my first bug report for your great JSPWiki and I hope to give you enough information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Holeczek updated JSPWIKI-612:
-------------------------------------
Fix Version/s: 3.0
> There is a small bug in the ...\JSPWiki\templates\default\admin\UserManagement.jsp
> ----------------------------------------------------------------------------------
>
> Key: JSPWIKI-612
> URL: https://issues.apache.org/jira/browse/JSPWIKI-612
> Project: JSPWiki
> Issue Type: Bug
> Components: Default template
> Affects Versions: 2.8.3
> Environment: windows XP,IE6,IE7
> Reporter: 高法æ£
> Fix For: 2.8.4, 3.0
>
>
> In the UserManagement.jsp page,there is a select box like that:
>
> <select name="userid" id="userid" size="16" onchange="javascript:refreshUserInfo()">
> <c:forEach var="user" items="${engine.userManager.userDatabase.wikiNames}">
> <option><c:out value="${user.name}" escapeXml="true"/></option>
> </c:forEach>
> </select>
> and the is a javascript function, it want to get the value of the select box. The function
like that:
> function refreshUserInfo()
> {
> var userid = $('userid').getValue();
>
> if( userid == '--New--' ) return;
>
> Wiki.jsonrpc("users.getUserInfo", [userid], function(userprofile){
> $('loginname').value = userprofile.loginName;
> $('loginid').value = userprofile.loginName;
> $('fullname').value = userprofile.fullname;
> $('email').value = userprofile.email;
> $('lastmodified').setHTML(constructdate(userprofile.lastModified));
> $('creationdate').setHTML(constructdate(userprofile.created));
> });
> }
> In the option tag of the select box,there is not "value" attribute,so the code "$('userid').getValue()"
get a empty String,
> then it will occur a js bug.
> But in the firefox3.5,the bug will not happen.
> Chage the select box like that:
> <select name="userid" id="userid" size="16" onchange="javascript:refreshUserInfo()">
> <c:forEach var="user" items="${engine.userManager.userDatabase.wikiNames}">
> <option value="${user.name}"><c:out value="${user.name}" escapeXml="true"/></option>
> </c:forEach>
> </select>
> the bug gone.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Holeczek updated JSPWIKI-612:
-------------------------------------
Fix Version/s: (was: 2.8.3)
(was: 3.0)
2.8.4
adjusted fix version.
> There is a small bug in the ...\JSPWiki\templates\default\admin\UserManagement.jsp
> ----------------------------------------------------------------------------------
>
> Key: JSPWIKI-612
> URL: https://issues.apache.org/jira/browse/JSPWIKI-612
> Project: JSPWiki
> Issue Type: Bug
> Components: Default template
> Affects Versions: 2.8.3
> Environment: windows XP,IE6,IE7
> Reporter: 高法æ£
> Fix For: 2.8.4
>
>
> In the UserManagement.jsp page,there is a select box like that:
>
> <select name="userid" id="userid" size="16" onchange="javascript:refreshUserInfo()">
> <c:forEach var="user" items="${engine.userManager.userDatabase.wikiNames}">
> <option><c:out value="${user.name}" escapeXml="true"/></option>
> </c:forEach>
> </select>
> and the is a javascript function, it want to get the value of the select box. The function
like that:
> function refreshUserInfo()
> {
> var userid = $('userid').getValue();
>
> if( userid == '--New--' ) return;
>
> Wiki.jsonrpc("users.getUserInfo", [userid], function(userprofile){
> $('loginname').value = userprofile.loginName;
> $('loginid').value = userprofile.loginName;
> $('fullname').value = userprofile.fullname;
> $('email').value = userprofile.email;
> $('lastmodified').setHTML(constructdate(userprofile.lastModified));
> $('creationdate').setHTML(constructdate(userprofile.created));
> });
> }
> In the option tag of the select box,there is not "value" attribute,so the code "$('userid').getValue()"
get a empty String,
> then it will occur a js bug.
> But in the firefox3.5,the bug will not happen.
> Chage the select box like that:
> <select name="userid" id="userid" size="16" onchange="javascript:refreshUserInfo()">
> <c:forEach var="user" items="${engine.userManager.userDatabase.wikiNames}">
> <option value="${user.name}"><c:out value="${user.name}" escapeXml="true"/></option>
> </c:forEach>
> </select>
> the bug gone.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Holeczek updated JSPWIKI-585:
-------------------------------------
Fix Version/s: (was: 2.8.3)
2.8.4
> overflow:auto breaks FullRecentChanges
> --------------------------------------
>
> Key: JSPWIKI-585
> URL: https://issues.apache.org/jira/browse/JSPWIKI-585
> Project: JSPWiki
> Issue Type: Bug
> Components: Default template
> Affects Versions: 2.8.2
> Environment: JSPWIki 2.8.2, Firefox 3.5.1
> Reporter: Stefan Bohn
> Assignee: Dirk Frederickx
> Priority: Trivial
> Fix For: 2.8.4, 3.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, screenshot-4.png
>
>
> html > body #previewcontent, html > body #info, html > body #pagecontent, html
> body #attach, html > body #findcontent
> {
> overflow:auto
> }
> breaks FullRecentChanges.
> The whole table is generated, but only the first part is displayed correctly.
> The page is as long as the whole table, but after the first shown part, all table rows
are not visible, so the page is white.
> Testing with Firebug and disabling the mentioned css shows the full table. But may break
other styles...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Holeczek updated JSPWIKI-454:
-------------------------------------
Fix Version/s: (was: 2.8.3)
2.8.4
> Export tool
> -----------
>
> Key: JSPWIKI-454
> URL: https://issues.apache.org/jira/browse/JSPWIKI-454
> Project: JSPWiki
> Issue Type: New Feature
> Components: Core & storage
> Reporter: Janne Jalkanen
> Fix For: 2.8.4
>
>
> In order to facilitate the move to a different backend in 3.0, and also allowing people
the choice of the 3.0 backend provider, we should have an export tool which can export the
old format repository to the JCR XML export format (System View). This will also be useful
in 3.0 for people who want to have an implementation-independent database dump.
> A couple of requirements:
> * Must run with existing 2.8.x
> * Must have an export functionality in the Admin UI
> * Should have also a simple GUI
> * Should have also a command-line interface
> * Should also export version histories (though there is no standard representation defined
in JCR, we may have to invent our own.)
> * May have built-in compression (the XML files are bound to be large)
> (For 3.0 it then obviously becomes: add a tool which allows *importing* of such XML document.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Holeczek updated JSPWIKI-614:
-------------------------------------
Priority: Minor (was: Major)
Affects Version/s: (was: 2.8.2)
Fix Version/s: (was: 2.8.3)
Good idea!
Adjusted entry settings.
> Create a Piwik plugin
> ----------------------
>
> Key: JSPWIKI-614
> URL: https://issues.apache.org/jira/browse/JSPWIKI-614
> Project: JSPWiki
> Issue Type: New Feature
> Components: Plugins
> Reporter: Derek
> Priority: Minor
>
> Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of
users through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Create a Piwik plugin
----------------------
Key: JSPWIKI-614
URL: https://issues.apache.org/jira/browse/JSPWIKI-614
Project: JSPWiki
Issue Type: New Feature
Components: Plugins
Affects Versions: 2.8.2
Reporter: Derek
Fix For: 2.8.3
Would be greate if there was a Piwik (www.piwik.org) plugin to allow the tracking of users
through the Wiki and to help determine usage and page hits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JSPWIKI-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781325#action_12781325
]
Janne Jalkanen commented on JSPWIKI-613:
----------------------------------------
Thanks for the report and welcome :-)
You're right, the section editing should point at the included page and not the host page.
However, the way that section editing is currently done is that it's completely done on the
client side. The problem is that the page is included on the server side...
Dirk, any ideas on how this should be handled? The only thing I can think of is that the heading
anchor tags do reveal which page was included, but that may not be reliable (the anchor generation
method loses information). One possibility would be to disable the section edit links for
included pages - this should be possible to deduce from the anchor names.
> InsertPage plugin and the feature of section editing do not fit together
> ------------------------------------------------------------------------
>
> Key: JSPWIKI-613
> URL: https://issues.apache.org/jira/browse/JSPWIKI-613
> Project: JSPWiki
> Issue Type: Bug
> Components: Plugins
> Affects Versions: 2.8.3
> Environment: Current versions of Windows XP and Firefox running in a virtual
machine of VMWare Fusion on a Mac Server
> Reporter: Mario Lotz
> Priority: Minor
>
> I often used the *InsertPage plugin* to separate structure of my presentation from the
content. Normaly I include pages into tabbed sections to give my users a single point of entry
to the same kind of information.
> If the *section editing feature* is enabled the rendered *edit links* are pointing to
the {color:red}_including_{color} page instead of the {color:red}_included_{color} ones.
> I assume, that the links are added to the page after the includes are done. To fix the
wrong links, the edit links have to be inserted for each included page independent of the
parent and with a separate heading counter.
> This is my first bug report for your great JSPWiki and I hope to give you enough information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
InsertPage plugin and the feature of section editing do not fit together
------------------------------------------------------------------------
Key: JSPWIKI-613
URL: https://issues.apache.org/jira/browse/JSPWIKI-613
Project: JSPWiki
Issue Type: Bug
Components: Plugins
Affects Versions: 2.8.3
Environment: Current versions of Windows XP and Firefox running in a virtual machine
of VMWare Fusion on a Mac Server
Reporter: Mario Lotz
Priority: Minor
I often used the *InsertPage plugin* to separate structure of my presentation from the content.
Normaly I include pages into tabbed sections to give my users a single point of entry to the
same kind of information.
If the *section editing feature* is enabled the rendered *edit links* are pointing to the
{color:red}_including_{color} page instead of the {color:red}_included_{color} ones.
I assume, that the links are added to the page after the includes are done. To fix the wrong
links, the edit links have to be inserted for each included page independent of the parent
and with a separate heading counter.
This is my first bug report for your great JSPWiki and I hope to give you enough information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.