You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Peter Schart <pe...@goodinassociates.com> on 2009/03/09 22:06:58 UTC
Re: Preferences not being saved
Hi all,
(New here, so go easy on me!)
My problem is pretty simple to describe but it's driving me batty.
I'm running 2 wikis under Jetty (I have a bit of a strange set up but
for the most part it's similar to the "step by step" guide to having
multiple wikis).
On my test machine everything works as intended but for some reason on
my live server preferences are not being saved to the cookie. It has
prev. search and asserted name but never updates if I, say, try to
enable section editing or change the skin. This is true (both that it
works on my test machine and doesn't on the live server) in all
browsers I've tested. It doesn't give any errors or indication that
anything failed, it simply doesn't save them and redirects to Main.
Going immediately back in to the prefs shows the defaults.
Additionally, none of widgets on the plain editor (Bold, underline,
insert table, etc...) do anything.
I've looked everywhere I could think of for error messages or some
indication of why it isn't working and I can't find anything at all.
I could go into more detail if anyone thinks it will help, but I
thought (hope) there might be something obvious or oft-encountered
that I am just missing...
Advice? Suggestions?
Thanks,
peter schart
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
This is most definitely not the case. There is no evidence whatsoever
on the resultant page of the addResourceRequest()'ed scripts.
Curiously, I turned the log level up to debug and I DO get the message:
Request to add a resource: <script type='text/javascript' src='scripts/
jspwiki-prefs.js'></script>
Yet even then the script is not included (on my live server; works
fine in testing environment, grr! ;)
pete
On Mar 10, 2009, at 2:53 PM, Dirk Frederickx wrote:
> If you do a "View source" in your browser, you should get the
>
> <script type='text/javascript' src='.../scripts/jspwiki-edit.js'></
> script>
>
> <script type='text/javascript' src='.../scripts/posteditor.js'></
> script>
>
> lines. Is this the case ?
>
> This is currently broken in 3.0, but should be ok on a 2.8.
>
> dirk
>
>
> On Tue, Mar 10, 2009 at 7:25 PM, Peter Schart <pete@goodinassociates.com
> >wrote:
>
>> No, I'm on 2.8. There is definitely something preventing the
>> javascript
>> files from being attached by the addResourceRequest() method. For
>> instance,
>> templates/<my template>/editors/plain.jsp has the following lines:
>>
>> <%
>> WikiContext context = WikiContext.findContext( pageContext );
>> WikiEngine engine = context.getEngine();
>>
>> String contextPath = request.getContextPath();
>>
>> TemplateManager.addResourceRequest( context, "script",
>> contextPath +
>> "/scripts/jspwiki-edit.js" );
>> TemplateManager.addResourceRequest( context, "script",
>> contextPath +
>> "/scripts/posteditor.js" );
>> String usertext = EditorManager.getEditedText( pageContext );
>> %>
>>
>> Some simple debugging lets me see that 'context' is a valid object
>> and
>> 'contextPath' is "/gal-wiki". Further, manually navigating to
>> "http://<myserver>/gal-wiki/scripts/jspwiki-edit.js"
>> shows the file as would be expected, but there is no indication on
>> the
>> resultant page that it even attempted to load those two scripts -
>> they just
>> aren't in the response at all, nor is there any indication of an
>> error...
>> Same thing for jspwiki-prefs.js on the preferences page.
>>
>> pete
>>
>>
>>
>>
>> On Mar 10, 2009, at 12:24 PM, Andrew Jaquith wrote:
>>
>> Are you using 3.0? If so, be aware that lots of things are broken
>> at the
>>> moment.
>>>
>>> On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com>
>>> wrote:
>>>
>>> Replying to my own post... Anyway, it seems as though the cause
>>> of most
>>>> of my problems is javascript files not getting added to the page.
>>>> Apparently, "TemplateManager.addResourceRequest()" calls are not
>>>> happening
>>>> correctly. The prefs page does not have "jspwiki-prefs.js"
>>>> included and the
>>>> edit page does not have "jspwiki-edit.js" or "posteditor.js"
>>>> included.
>>>>
>>>> Any ideas as to why addResourceRequest() calls would be failing?
>>>>
>>>> thanks again,
>>>> pete
>>>>
>>>>
>>>> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>>>>
>>>> Thanks for the suggestion, David. Unfortunately, I don't think
>>>> this is
>>>>> the problem either. As far as I can tell, the permissions are
>>>>> correct.
>>>>>
>>>>> The deeper I dig trying to fix this the more I am starting think
>>>>> that
>>>>> something is just totally screwed (quite possibly the server
>>>>> itself and
>>>>> nothing to do with JSPWiki).
>>>>>
>>>>> I just keep finding more and more "weirdness" - like when I go
>>>>> to the
>>>>> Attach tab on a page I get the "You don't have access to <page
>>>>> name>"
>>>>> message (even though I'm logged in as a member of group Admin
>>>>> which has
>>>>> AllPermission in my policy) and yet it happily lets me upload... ?
>>>>>
>>>>> If I could recreate the problem on my test box I could probably
>>>>> figure
>>>>> this out but everything works exactly as I expect it to on my
>>>>> test box with
>>>>> the exact same setup, .policy and .property files... I'm truly
>>>>> stumped.
>>>>>
>>>>> Back to digging...
>>>>>
>>>>> pete
>>>>>
>>>>> P.S. I may have found a culprit for the prefs not saving thing.
>>>>> When I
>>>>> load the prefs page I get a javascript error about "WikiGroup"
>>>>> not being
>>>>> defined (it's a line that spits out the group members to the
>>>>> group tab of
>>>>> the preference page). The line is, for example:
>>>>> "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created
>>>>> on ....");" I'm
>>>>> guessing that the js error might be preventing the cookie-
>>>>> writing from
>>>>> executing. But again, I don't get this error on my test box so
>>>>> it's
>>>>> probably going to be difficult to track down the cause.
>>>>>
>>>>>
>>>>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I have similar experience before. My case is that I cannot change
>>>>>> password no matter how I tried. NB. my JSPWiki is running on
>>>>>> CentOS linux.
>>>>>> And finally I found that the ACL for one of jar files in WEB-
>>>>>> INF/lib folder
>>>>>> is not corrected set. Tomcat simply has no right to access that
>>>>>> file.
>>>>>>
>>>>>> Everything works fine after I chmod the jar file to the correct
>>>>>> ownership. Hope this helps.
>>>>>>
>>>>>> Thanks for the quick response, Janne. I thought of the baseURL
>>>>>> thing,
>>>>>>> but I just double checked and -- as far as I can tell -- they
>>>>>>> are correct.
>>>>>>> As I mentioned, I have two wikis running -- each with a separate
>>>>>>> *.properties file -- one has a baseURL of "
>>>>>>> http://www.goodinassociates.com/gal-wiki/" and the other is
>>>>>>> the same
>>>>>>> except the last path element is "/client-wiki/".
>>>>>>>
>>>>>>> The same type of configuration works on my test machine with "
>>>>>>> http://localhost/gal-wiki/" and "http://localhost/client-wiki"
>>>>>>> so I'm
>>>>>>> thinking it must be something else.
>>>>>>>
>>>>>>> Again, maybe I'm just missing something...
>>>>>>>
>>>>>>> thanks again,
>>>>>>> pete
>>>>>>>
>>>>>>>
>>>>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi ho!
>>>>>>>>
>>>>>>>> The probable reason is that your server has the wrong
>>>>>>>> baseURL. This
>>>>>>>> causes cookies to be written for the wrong domain name, and
>>>>>>>> your browser
>>>>>>>> won't send them back to the server (because cookies can only
>>>>>>>> be sent to the
>>>>>>>> same server which set them in the first place). There's no
>>>>>>>> way JSPWiki can
>>>>>>>> really detect this (since it's not actually an error case as
>>>>>>>> such), so you
>>>>>>>> wouldn't be seeing anything in the logs :-)
>>>>>>>>
>>>>>>>> Hope this helps!
>>>>>>>>
>>>>>>>> /Janne
>>>>>>>>
>>>>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>> (New here, so go easy on me!)
>>>>>>>>> My problem is pretty simple to describe but it's driving me
>>>>>>>>> batty.
>>>>>>>>> I'm running 2 wikis under Jetty (I have a bit of a strange
>>>>>>>>> set up but for
>>>>>>>>> the most part it's similar to the "step by step" guide to
>>>>>>>>> having multiple
>>>>>>>>> wikis).
>>>>>>>>>
>>>>>>>>> On my test machine everything works as intended but for some
>>>>>>>>> reason
>>>>>>>>> on my live server preferences are not being saved to the
>>>>>>>>> cookie. It has
>>>>>>>>> prev. search and asserted name but never updates if I, say,
>>>>>>>>> try to enable
>>>>>>>>> section editing or change the skin. This is true (both that
>>>>>>>>> it works on my
>>>>>>>>> test machine and doesn't on the live server) in all browsers
>>>>>>>>> I've tested.
>>>>>>>>> It doesn't give any errors or indication that anything
>>>>>>>>> failed, it simply
>>>>>>>>> doesn't save them and redirects to Main. Going immediately
>>>>>>>>> back in to the
>>>>>>>>> prefs shows the defaults.
>>>>>>>>>
>>>>>>>>> Additionally, none of widgets on the plain editor (Bold,
>>>>>>>>> underline,
>>>>>>>>> insert table, etc...) do anything.
>>>>>>>>>
>>>>>>>>> I've looked everywhere I could think of for error messages
>>>>>>>>> or some
>>>>>>>>> indication of why it isn't working and I can't find anything
>>>>>>>>> at all.
>>>>>>>>>
>>>>>>>>> I could go into more detail if anyone thinks it will help,
>>>>>>>>> but I
>>>>>>>>> thought (hope) there might be something obvious or oft-
>>>>>>>>> encountered that I am
>>>>>>>>> just missing...
>>>>>>>>>
>>>>>>>>> Advice? Suggestions?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> peter schart
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> David Gao (davidgjm@gmail.com)
>>>>>>
>>>>>
>>>>>
>>>>
>>
Re: Preferences not being saved
Posted by Dirk Frederickx <di...@gmail.com>.
If you do a "View source" in your browser, you should get the
<script type='text/javascript' src='.../scripts/jspwiki-edit.js'></script>
<script type='text/javascript' src='.../scripts/posteditor.js'></script>
lines. Is this the case ?
This is currently broken in 3.0, but should be ok on a 2.8.
dirk
On Tue, Mar 10, 2009 at 7:25 PM, Peter Schart <pe...@goodinassociates.com>wrote:
> No, I'm on 2.8. There is definitely something preventing the javascript
> files from being attached by the addResourceRequest() method. For instance,
> templates/<my template>/editors/plain.jsp has the following lines:
>
> <%
> WikiContext context = WikiContext.findContext( pageContext );
> WikiEngine engine = context.getEngine();
>
> String contextPath = request.getContextPath();
>
> TemplateManager.addResourceRequest( context, "script", contextPath +
> "/scripts/jspwiki-edit.js" );
> TemplateManager.addResourceRequest( context, "script", contextPath +
> "/scripts/posteditor.js" );
> String usertext = EditorManager.getEditedText( pageContext );
> %>
>
> Some simple debugging lets me see that 'context' is a valid object and
> 'contextPath' is "/gal-wiki". Further, manually navigating to "http://<myserver>/gal-wiki/scripts/jspwiki-edit.js"
> shows the file as would be expected, but there is no indication on the
> resultant page that it even attempted to load those two scripts - they just
> aren't in the response at all, nor is there any indication of an error...
> Same thing for jspwiki-prefs.js on the preferences page.
>
> pete
>
>
>
>
> On Mar 10, 2009, at 12:24 PM, Andrew Jaquith wrote:
>
> Are you using 3.0? If so, be aware that lots of things are broken at the
>> moment.
>>
>> On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com> wrote:
>>
>> Replying to my own post... Anyway, it seems as though the cause of most
>>> of my problems is javascript files not getting added to the page.
>>> Apparently, "TemplateManager.addResourceRequest()" calls are not happening
>>> correctly. The prefs page does not have "jspwiki-prefs.js" included and the
>>> edit page does not have "jspwiki-edit.js" or "posteditor.js" included.
>>>
>>> Any ideas as to why addResourceRequest() calls would be failing?
>>>
>>> thanks again,
>>> pete
>>>
>>>
>>> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>>>
>>> Thanks for the suggestion, David. Unfortunately, I don't think this is
>>>> the problem either. As far as I can tell, the permissions are correct.
>>>>
>>>> The deeper I dig trying to fix this the more I am starting think that
>>>> something is just totally screwed (quite possibly the server itself and
>>>> nothing to do with JSPWiki).
>>>>
>>>> I just keep finding more and more "weirdness" - like when I go to the
>>>> Attach tab on a page I get the "You don't have access to <page name>"
>>>> message (even though I'm logged in as a member of group Admin which has
>>>> AllPermission in my policy) and yet it happily lets me upload... ?
>>>>
>>>> If I could recreate the problem on my test box I could probably figure
>>>> this out but everything works exactly as I expect it to on my test box with
>>>> the exact same setup, .policy and .property files... I'm truly stumped.
>>>>
>>>> Back to digging...
>>>>
>>>> pete
>>>>
>>>> P.S. I may have found a culprit for the prefs not saving thing. When I
>>>> load the prefs page I get a javascript error about "WikiGroup" not being
>>>> defined (it's a line that spits out the group members to the group tab of
>>>> the preference page). The line is, for example:
>>>> "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created on ....");" I'm
>>>> guessing that the js error might be preventing the cookie-writing from
>>>> executing. But again, I don't get this error on my test box so it's
>>>> probably going to be difficult to track down the cause.
>>>>
>>>>
>>>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> I have similar experience before. My case is that I cannot change
>>>>> password no matter how I tried. NB. my JSPWiki is running on CentOS linux.
>>>>> And finally I found that the ACL for one of jar files in WEB-INF/lib folder
>>>>> is not corrected set. Tomcat simply has no right to access that file.
>>>>>
>>>>> Everything works fine after I chmod the jar file to the correct
>>>>> ownership. Hope this helps.
>>>>>
>>>>> Thanks for the quick response, Janne. I thought of the baseURL thing,
>>>>>> but I just double checked and -- as far as I can tell -- they are correct.
>>>>>> As I mentioned, I have two wikis running -- each with a separate
>>>>>> *.properties file -- one has a baseURL of "
>>>>>> http://www.goodinassociates.com/gal-wiki/" and the other is the same
>>>>>> except the last path element is "/client-wiki/".
>>>>>>
>>>>>> The same type of configuration works on my test machine with "
>>>>>> http://localhost/gal-wiki/" and "http://localhost/client-wiki" so I'm
>>>>>> thinking it must be something else.
>>>>>>
>>>>>> Again, maybe I'm just missing something...
>>>>>>
>>>>>> thanks again,
>>>>>> pete
>>>>>>
>>>>>>
>>>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>>>
>>>>>>
>>>>>>> Hi ho!
>>>>>>>
>>>>>>> The probable reason is that your server has the wrong baseURL. This
>>>>>>> causes cookies to be written for the wrong domain name, and your browser
>>>>>>> won't send them back to the server (because cookies can only be sent to the
>>>>>>> same server which set them in the first place). There's no way JSPWiki can
>>>>>>> really detect this (since it's not actually an error case as such), so you
>>>>>>> wouldn't be seeing anything in the logs :-)
>>>>>>>
>>>>>>> Hope this helps!
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>> (New here, so go easy on me!)
>>>>>>>> My problem is pretty simple to describe but it's driving me batty.
>>>>>>>> I'm running 2 wikis under Jetty (I have a bit of a strange set up but for
>>>>>>>> the most part it's similar to the "step by step" guide to having multiple
>>>>>>>> wikis).
>>>>>>>>
>>>>>>>> On my test machine everything works as intended but for some reason
>>>>>>>> on my live server preferences are not being saved to the cookie. It has
>>>>>>>> prev. search and asserted name but never updates if I, say, try to enable
>>>>>>>> section editing or change the skin. This is true (both that it works on my
>>>>>>>> test machine and doesn't on the live server) in all browsers I've tested.
>>>>>>>> It doesn't give any errors or indication that anything failed, it simply
>>>>>>>> doesn't save them and redirects to Main. Going immediately back in to the
>>>>>>>> prefs shows the defaults.
>>>>>>>>
>>>>>>>> Additionally, none of widgets on the plain editor (Bold, underline,
>>>>>>>> insert table, etc...) do anything.
>>>>>>>>
>>>>>>>> I've looked everywhere I could think of for error messages or some
>>>>>>>> indication of why it isn't working and I can't find anything at all.
>>>>>>>>
>>>>>>>> I could go into more detail if anyone thinks it will help, but I
>>>>>>>> thought (hope) there might be something obvious or oft-encountered that I am
>>>>>>>> just missing...
>>>>>>>>
>>>>>>>> Advice? Suggestions?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> peter schart
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> David Gao (davidgjm@gmail.com)
>>>>>
>>>>
>>>>
>>>
>
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
Now, we might be getting closer here. Inspecting the web.xml entries
for WikiJSPFilter revealed a <servlet-mapping> tag for the following
URL pattern:
/wiki/*
Is that correct? This is a "stock" entry as far as I know, and not
part of my baseURLs (which are our domain name + "/gal-wiki" and + "/
client-wiki"). There is also an entry for "*.jsp" so I'm not even
sure what the "/wiki/*" one is referring to. However, a. this same
setup works fine on one machine but not the other; and b. I tried
changing the "/wiki/*" entry to "/gal-wiki/*" and it did not improve
the situation.
this is driving me mad because our setup on the live server makes it
quite difficult to test/debug... I can't tell you all how much I
appreciate your trying to help me.
pete
On Mar 10, 2009, at 1:32 PM, Andrew Jaquith wrote:
> The most obvious cause of this would be if WikiJSPFilter
> (com.ecyrd.jspwiki.ui.WikiJSPFilter) wasn't mapped and active in
> web.xml. This is the filter that does the resource includes. You might
> want to check your web.xml and see if it's filtering the request as
> expected -- if you are handing with debuggers, you could do this by
> attaching a JDPA watchpoint to WikiJSPFilter to make sure it is
> firing.
>
> Andrew
>
> On Tue, Mar 10, 2009 at 2:25 PM, Peter Schart <pete@goodinassociates.com
> > wrote:
>> No, I'm on 2.8. There is definitely something preventing the
>> javascript
>> files from being attached by the addResourceRequest() method. For
>> instance,
>> templates/<my template>/editors/plain.jsp has the following lines:
>>
>> <%
>> WikiContext context = WikiContext.findContext( pageContext );
>> WikiEngine engine = context.getEngine();
>>
>> String contextPath = request.getContextPath();
>>
>> TemplateManager.addResourceRequest( context, "script",
>> contextPath +
>> "/scripts/jspwiki-edit.js" );
>> TemplateManager.addResourceRequest( context, "script",
>> contextPath +
>> "/scripts/posteditor.js" );
>> String usertext = EditorManager.getEditedText( pageContext );
>> %>
>>
>> Some simple debugging lets me see that 'context' is a valid object
>> and
>> 'contextPath' is "/gal-wiki". Further, manually navigating to
>> "http://<myserver>/gal-wiki/scripts/jspwiki-edit.js" shows the file
>> as would
>> be expected, but there is no indication on the resultant page that
>> it even
>> attempted to load those two scripts - they just aren't in the
>> response at
>> all, nor is there any indication of an error... Same thing for
>> jspwiki-prefs.js on the preferences page.
>>
>> pete
>>
>>
>>
>> On Mar 10, 2009, at 12:24 PM, Andrew Jaquith wrote:
>>
>>> Are you using 3.0? If so, be aware that lots of things are broken
>>> at the
>>> moment.
>>>
>>> On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com>
>>> wrote:
>>>
>>>> Replying to my own post... Anyway, it seems as though the cause
>>>> of most
>>>> of my problems is javascript files not getting added to the page.
>>>> Apparently, "TemplateManager.addResourceRequest()" calls are not
>>>> happening
>>>> correctly. The prefs page does not have "jspwiki-prefs.js"
>>>> included and the
>>>> edit page does not have "jspwiki-edit.js" or "posteditor.js"
>>>> included.
>>>>
>>>> Any ideas as to why addResourceRequest() calls would be failing?
>>>>
>>>> thanks again,
>>>> pete
>>>>
>>>>
>>>> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>>>>
>>>>> Thanks for the suggestion, David. Unfortunately, I don't think
>>>>> this is
>>>>> the problem either. As far as I can tell, the permissions are
>>>>> correct.
>>>>>
>>>>> The deeper I dig trying to fix this the more I am starting think
>>>>> that
>>>>> something is just totally screwed (quite possibly the server
>>>>> itself and
>>>>> nothing to do with JSPWiki).
>>>>>
>>>>> I just keep finding more and more "weirdness" - like when I go
>>>>> to the
>>>>> Attach tab on a page I get the "You don't have access to <page
>>>>> name>"
>>>>> message (even though I'm logged in as a member of group Admin
>>>>> which has
>>>>> AllPermission in my policy) and yet it happily lets me upload... ?
>>>>>
>>>>> If I could recreate the problem on my test box I could probably
>>>>> figure
>>>>> this out but everything works exactly as I expect it to on my
>>>>> test box with
>>>>> the exact same setup, .policy and .property files... I'm truly
>>>>> stumped.
>>>>>
>>>>> Back to digging...
>>>>>
>>>>> pete
>>>>>
>>>>> P.S. I may have found a culprit for the prefs not saving thing.
>>>>> When I
>>>>> load the prefs page I get a javascript error about "WikiGroup"
>>>>> not being
>>>>> defined (it's a line that spits out the group members to the
>>>>> group tab of
>>>>> the preference page). The line is, for example:
>>>>> "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created
>>>>> on ....");" I'm
>>>>> guessing that the js error might be preventing the cookie-
>>>>> writing from
>>>>> executing. But again, I don't get this error on my test box so
>>>>> it's
>>>>> probably going to be difficult to track down the cause.
>>>>>
>>>>>
>>>>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have similar experience before. My case is that I cannot change
>>>>>> password no matter how I tried. NB. my JSPWiki is running on
>>>>>> CentOS linux.
>>>>>> And finally I found that the ACL for one of jar files in WEB-
>>>>>> INF/lib folder
>>>>>> is not corrected set. Tomcat simply has no right to access that
>>>>>> file.
>>>>>>
>>>>>> Everything works fine after I chmod the jar file to the correct
>>>>>> ownership. Hope this helps.
>>>>>>
>>>>>>> Thanks for the quick response, Janne. I thought of the baseURL
>>>>>>> thing,
>>>>>>> but I just double checked and -- as far as I can tell -- they
>>>>>>> are correct.
>>>>>>> As I mentioned, I have two wikis running -- each with a
>>>>>>> separate
>>>>>>> *.properties file -- one has a baseURL of
>>>>>>> "http://www.goodinassociates.com/gal-wiki/" and the other is
>>>>>>> the same except
>>>>>>> the last path element is "/client-wiki/".
>>>>>>>
>>>>>>> The same type of configuration works on my test machine with
>>>>>>> "http://localhost/gal-wiki/" and "http://localhost/client-
>>>>>>> wiki" so I'm
>>>>>>> thinking it must be something else.
>>>>>>>
>>>>>>> Again, maybe I'm just missing something...
>>>>>>>
>>>>>>> thanks again,
>>>>>>> pete
>>>>>>>
>>>>>>>
>>>>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hi ho!
>>>>>>>>
>>>>>>>> The probable reason is that your server has the wrong
>>>>>>>> baseURL. This
>>>>>>>> causes cookies to be written for the wrong domain name, and
>>>>>>>> your browser
>>>>>>>> won't send them back to the server (because cookies can only
>>>>>>>> be sent to the
>>>>>>>> same server which set them in the first place). There's no
>>>>>>>> way JSPWiki can
>>>>>>>> really detect this (since it's not actually an error case as
>>>>>>>> such), so you
>>>>>>>> wouldn't be seeing anything in the logs :-)
>>>>>>>>
>>>>>>>> Hope this helps!
>>>>>>>>
>>>>>>>> /Janne
>>>>>>>>
>>>>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>> (New here, so go easy on me!)
>>>>>>>>> My problem is pretty simple to describe but it's driving me
>>>>>>>>> batty.
>>>>>>>>> I'm running 2 wikis under Jetty (I have a bit of a strange
>>>>>>>>> set up but for
>>>>>>>>> the most part it's similar to the "step by step" guide to
>>>>>>>>> having multiple
>>>>>>>>> wikis).
>>>>>>>>>
>>>>>>>>> On my test machine everything works as intended but for some
>>>>>>>>> reason
>>>>>>>>> on my live server preferences are not being saved to the
>>>>>>>>> cookie. It has
>>>>>>>>> prev. search and asserted name but never updates if I, say,
>>>>>>>>> try to enable
>>>>>>>>> section editing or change the skin. This is true (both that
>>>>>>>>> it works on my
>>>>>>>>> test machine and doesn't on the live server) in all browsers
>>>>>>>>> I've tested.
>>>>>>>>> It doesn't give any errors or indication that anything
>>>>>>>>> failed, it simply
>>>>>>>>> doesn't save them and redirects to Main. Going immediately
>>>>>>>>> back in to the
>>>>>>>>> prefs shows the defaults.
>>>>>>>>>
>>>>>>>>> Additionally, none of widgets on the plain editor (Bold,
>>>>>>>>> underline,
>>>>>>>>> insert table, etc...) do anything.
>>>>>>>>>
>>>>>>>>> I've looked everywhere I could think of for error messages
>>>>>>>>> or some
>>>>>>>>> indication of why it isn't working and I can't find anything
>>>>>>>>> at all.
>>>>>>>>>
>>>>>>>>> I could go into more detail if anyone thinks it will help,
>>>>>>>>> but I
>>>>>>>>> thought (hope) there might be something obvious or oft-
>>>>>>>>> encountered that I am
>>>>>>>>> just missing...
>>>>>>>>>
>>>>>>>>> Advice? Suggestions?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> peter schart
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> David Gao (davidgjm@gmail.com)
>>>>>
>>>>
>>
>>
Re: Preferences not being saved
Posted by Andrew Jaquith <an...@gmail.com>.
The most obvious cause of this would be if WikiJSPFilter
(com.ecyrd.jspwiki.ui.WikiJSPFilter) wasn't mapped and active in
web.xml. This is the filter that does the resource includes. You might
want to check your web.xml and see if it's filtering the request as
expected -- if you are handing with debuggers, you could do this by
attaching a JDPA watchpoint to WikiJSPFilter to make sure it is
firing.
Andrew
On Tue, Mar 10, 2009 at 2:25 PM, Peter Schart <pe...@goodinassociates.com> wrote:
> No, I'm on 2.8. There is definitely something preventing the javascript
> files from being attached by the addResourceRequest() method. For instance,
> templates/<my template>/editors/plain.jsp has the following lines:
>
> <%
> WikiContext context = WikiContext.findContext( pageContext );
> WikiEngine engine = context.getEngine();
>
> String contextPath = request.getContextPath();
>
> TemplateManager.addResourceRequest( context, "script", contextPath +
> "/scripts/jspwiki-edit.js" );
> TemplateManager.addResourceRequest( context, "script", contextPath +
> "/scripts/posteditor.js" );
> String usertext = EditorManager.getEditedText( pageContext );
> %>
>
> Some simple debugging lets me see that 'context' is a valid object and
> 'contextPath' is "/gal-wiki". Further, manually navigating to
> "http://<myserver>/gal-wiki/scripts/jspwiki-edit.js" shows the file as would
> be expected, but there is no indication on the resultant page that it even
> attempted to load those two scripts - they just aren't in the response at
> all, nor is there any indication of an error... Same thing for
> jspwiki-prefs.js on the preferences page.
>
> pete
>
>
>
> On Mar 10, 2009, at 12:24 PM, Andrew Jaquith wrote:
>
>> Are you using 3.0? If so, be aware that lots of things are broken at the
>> moment.
>>
>> On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com> wrote:
>>
>>> Replying to my own post... Anyway, it seems as though the cause of most
>>> of my problems is javascript files not getting added to the page.
>>> Apparently, "TemplateManager.addResourceRequest()" calls are not happening
>>> correctly. The prefs page does not have "jspwiki-prefs.js" included and the
>>> edit page does not have "jspwiki-edit.js" or "posteditor.js" included.
>>>
>>> Any ideas as to why addResourceRequest() calls would be failing?
>>>
>>> thanks again,
>>> pete
>>>
>>>
>>> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>>>
>>>> Thanks for the suggestion, David. Unfortunately, I don't think this is
>>>> the problem either. As far as I can tell, the permissions are correct.
>>>>
>>>> The deeper I dig trying to fix this the more I am starting think that
>>>> something is just totally screwed (quite possibly the server itself and
>>>> nothing to do with JSPWiki).
>>>>
>>>> I just keep finding more and more "weirdness" - like when I go to the
>>>> Attach tab on a page I get the "You don't have access to <page name>"
>>>> message (even though I'm logged in as a member of group Admin which has
>>>> AllPermission in my policy) and yet it happily lets me upload... ?
>>>>
>>>> If I could recreate the problem on my test box I could probably figure
>>>> this out but everything works exactly as I expect it to on my test box with
>>>> the exact same setup, .policy and .property files... I'm truly stumped.
>>>>
>>>> Back to digging...
>>>>
>>>> pete
>>>>
>>>> P.S. I may have found a culprit for the prefs not saving thing. When I
>>>> load the prefs page I get a javascript error about "WikiGroup" not being
>>>> defined (it's a line that spits out the group members to the group tab of
>>>> the preference page). The line is, for example:
>>>> "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created on ....");" I'm
>>>> guessing that the js error might be preventing the cookie-writing from
>>>> executing. But again, I don't get this error on my test box so it's
>>>> probably going to be difficult to track down the cause.
>>>>
>>>>
>>>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have similar experience before. My case is that I cannot change
>>>>> password no matter how I tried. NB. my JSPWiki is running on CentOS linux.
>>>>> And finally I found that the ACL for one of jar files in WEB-INF/lib folder
>>>>> is not corrected set. Tomcat simply has no right to access that file.
>>>>>
>>>>> Everything works fine after I chmod the jar file to the correct
>>>>> ownership. Hope this helps.
>>>>>
>>>>>> Thanks for the quick response, Janne. I thought of the baseURL thing,
>>>>>> but I just double checked and -- as far as I can tell -- they are correct.
>>>>>> As I mentioned, I have two wikis running -- each with a separate
>>>>>> *.properties file -- one has a baseURL of
>>>>>> "http://www.goodinassociates.com/gal-wiki/" and the other is the same except
>>>>>> the last path element is "/client-wiki/".
>>>>>>
>>>>>> The same type of configuration works on my test machine with
>>>>>> "http://localhost/gal-wiki/" and "http://localhost/client-wiki" so I'm
>>>>>> thinking it must be something else.
>>>>>>
>>>>>> Again, maybe I'm just missing something...
>>>>>>
>>>>>> thanks again,
>>>>>> pete
>>>>>>
>>>>>>
>>>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi ho!
>>>>>>>
>>>>>>> The probable reason is that your server has the wrong baseURL. This
>>>>>>> causes cookies to be written for the wrong domain name, and your browser
>>>>>>> won't send them back to the server (because cookies can only be sent to the
>>>>>>> same server which set them in the first place). There's no way JSPWiki can
>>>>>>> really detect this (since it's not actually an error case as such), so you
>>>>>>> wouldn't be seeing anything in the logs :-)
>>>>>>>
>>>>>>> Hope this helps!
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> (New here, so go easy on me!)
>>>>>>>> My problem is pretty simple to describe but it's driving me batty.
>>>>>>>> I'm running 2 wikis under Jetty (I have a bit of a strange set up but for
>>>>>>>> the most part it's similar to the "step by step" guide to having multiple
>>>>>>>> wikis).
>>>>>>>>
>>>>>>>> On my test machine everything works as intended but for some reason
>>>>>>>> on my live server preferences are not being saved to the cookie. It has
>>>>>>>> prev. search and asserted name but never updates if I, say, try to enable
>>>>>>>> section editing or change the skin. This is true (both that it works on my
>>>>>>>> test machine and doesn't on the live server) in all browsers I've tested.
>>>>>>>> It doesn't give any errors or indication that anything failed, it simply
>>>>>>>> doesn't save them and redirects to Main. Going immediately back in to the
>>>>>>>> prefs shows the defaults.
>>>>>>>>
>>>>>>>> Additionally, none of widgets on the plain editor (Bold, underline,
>>>>>>>> insert table, etc...) do anything.
>>>>>>>>
>>>>>>>> I've looked everywhere I could think of for error messages or some
>>>>>>>> indication of why it isn't working and I can't find anything at all.
>>>>>>>>
>>>>>>>> I could go into more detail if anyone thinks it will help, but I
>>>>>>>> thought (hope) there might be something obvious or oft-encountered that I am
>>>>>>>> just missing...
>>>>>>>>
>>>>>>>> Advice? Suggestions?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> peter schart
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> David Gao (davidgjm@gmail.com)
>>>>
>>>
>
>
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
No, I'm on 2.8. There is definitely something preventing the
javascript files from being attached by the addResourceRequest()
method. For instance, templates/<my template>/editors/plain.jsp has
the following lines:
<%
WikiContext context = WikiContext.findContext( pageContext );
WikiEngine engine = context.getEngine();
String contextPath = request.getContextPath();
TemplateManager.addResourceRequest( context, "script",
contextPath + "/scripts/jspwiki-edit.js" );
TemplateManager.addResourceRequest( context, "script",
contextPath + "/scripts/posteditor.js" );
String usertext = EditorManager.getEditedText( pageContext );
%>
Some simple debugging lets me see that 'context' is a valid object and
'contextPath' is "/gal-wiki". Further, manually navigating to "http://
<myserver>/gal-wiki/scripts/jspwiki-edit.js" shows the file as would
be expected, but there is no indication on the resultant page that it
even attempted to load those two scripts - they just aren't in the
response at all, nor is there any indication of an error... Same
thing for jspwiki-prefs.js on the preferences page.
pete
On Mar 10, 2009, at 12:24 PM, Andrew Jaquith wrote:
> Are you using 3.0? If so, be aware that lots of things are broken at
> the moment.
>
> On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com>
> wrote:
>
>> Replying to my own post... Anyway, it seems as though the cause of
>> most of my problems is javascript files not getting added to the
>> page. Apparently, "TemplateManager.addResourceRequest()" calls are
>> not happening correctly. The prefs page does not have "jspwiki-
>> prefs.js" included and the edit page does not have "jspwiki-
>> edit.js" or "posteditor.js" included.
>>
>> Any ideas as to why addResourceRequest() calls would be failing?
>>
>> thanks again,
>> pete
>>
>>
>> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>>
>>> Thanks for the suggestion, David. Unfortunately, I don't think
>>> this is the problem either. As far as I can tell, the permissions
>>> are correct.
>>>
>>> The deeper I dig trying to fix this the more I am starting think
>>> that something is just totally screwed (quite possibly the server
>>> itself and nothing to do with JSPWiki).
>>>
>>> I just keep finding more and more "weirdness" - like when I go to
>>> the Attach tab on a page I get the "You don't have access to <page
>>> name>" message (even though I'm logged in as a member of group
>>> Admin which has AllPermission in my policy) and yet it happily
>>> lets me upload... ?
>>>
>>> If I could recreate the problem on my test box I could probably
>>> figure this out but everything works exactly as I expect it to on
>>> my test box with the exact same setup, .policy and .property
>>> files... I'm truly stumped.
>>>
>>> Back to digging...
>>>
>>> pete
>>>
>>> P.S. I may have found a culprit for the prefs not saving thing.
>>> When I load the prefs page I get a javascript error about
>>> "WikiGroup" not being defined (it's a line that spits out the
>>> group members to the group tab of the preference page). The line
>>> is, for example: "WikiGroup.putGroup("Admin", "<user>\n<user2>\n",
>>> "created on ....");" I'm guessing that the js error might be
>>> preventing the cookie-writing from executing. But again, I don't
>>> get this error on my test box so it's probably going to be
>>> difficult to track down the cause.
>>>
>>>
>>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>>
>>>> Hi,
>>>>
>>>> I have similar experience before. My case is that I cannot change
>>>> password no matter how I tried. NB. my JSPWiki is running on
>>>> CentOS linux. And finally I found that the ACL for one of jar
>>>> files in WEB-INF/lib folder is not corrected set. Tomcat simply
>>>> has no right to access that file.
>>>>
>>>> Everything works fine after I chmod the jar file to the correct
>>>> ownership. Hope this helps.
>>>>
>>>>> Thanks for the quick response, Janne. I thought of the baseURL
>>>>> thing, but I just double checked and -- as far as I can tell --
>>>>> they are correct. As I mentioned, I have two wikis running --
>>>>> each with a separate *.properties file -- one has a baseURL of "http://www.goodinassociates.com/gal-wiki/
>>>>> " and the other is the same except the last path element is "/
>>>>> client-wiki/".
>>>>>
>>>>> The same type of configuration works on my test machine with "http://localhost/gal-wiki/
>>>>> " and "http://localhost/client-wiki" so I'm thinking it must be
>>>>> something else.
>>>>>
>>>>> Again, maybe I'm just missing something...
>>>>>
>>>>> thanks again,
>>>>> pete
>>>>>
>>>>>
>>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>>
>>>>>>
>>>>>> Hi ho!
>>>>>>
>>>>>> The probable reason is that your server has the wrong baseURL.
>>>>>> This causes cookies to be written for the wrong domain name,
>>>>>> and your browser won't send them back to the server (because
>>>>>> cookies can only be sent to the same server which set them in
>>>>>> the first place). There's no way JSPWiki can really detect
>>>>>> this (since it's not actually an error case as such), so you
>>>>>> wouldn't be seeing anything in the logs :-)
>>>>>>
>>>>>> Hope this helps!
>>>>>>
>>>>>> /Janne
>>>>>>
>>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>> (New here, so go easy on me!)
>>>>>>> My problem is pretty simple to describe but it's driving me
>>>>>>> batty. I'm running 2 wikis under Jetty (I have a bit of a
>>>>>>> strange set up but for the most part it's similar to the "step
>>>>>>> by step" guide to having multiple wikis).
>>>>>>>
>>>>>>> On my test machine everything works as intended but for some
>>>>>>> reason on my live server preferences are not being saved to
>>>>>>> the cookie. It has prev. search and asserted name but never
>>>>>>> updates if I, say, try to enable section editing or change the
>>>>>>> skin. This is true (both that it works on my test machine and
>>>>>>> doesn't on the live server) in all browsers I've tested. It
>>>>>>> doesn't give any errors or indication that anything failed, it
>>>>>>> simply doesn't save them and redirects to Main. Going
>>>>>>> immediately back in to the prefs shows the defaults.
>>>>>>>
>>>>>>> Additionally, none of widgets on the plain editor (Bold,
>>>>>>> underline, insert table, etc...) do anything.
>>>>>>>
>>>>>>> I've looked everywhere I could think of for error messages or
>>>>>>> some indication of why it isn't working and I can't find
>>>>>>> anything at all.
>>>>>>>
>>>>>>> I could go into more detail if anyone thinks it will help, but
>>>>>>> I thought (hope) there might be something obvious or oft-
>>>>>>> encountered that I am just missing...
>>>>>>>
>>>>>>> Advice? Suggestions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> peter schart
>>>>>
>>>>>
>>>>
>>>> --
>>>> David Gao (davidgjm@gmail.com)
>>>
>>
Re: Preferences not being saved
Posted by Andrew Jaquith <an...@gmail.com>.
Are you using 3.0? If so, be aware that lots of things are broken at
the moment.
On Mar 10, 2009, at 9:33, Peter Schart <pe...@goodinassociates.com>
wrote:
> Replying to my own post... Anyway, it seems as though the cause of
> most of my problems is javascript files not getting added to the
> page. Apparently, "TemplateManager.addResourceRequest()" calls are
> not happening correctly. The prefs page does not have "jspwiki-
> prefs.js" included and the edit page does not have "jspwiki-edit.js"
> or "posteditor.js" included.
>
> Any ideas as to why addResourceRequest() calls would be failing?
>
> thanks again,
> pete
>
>
> On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
>
>> Thanks for the suggestion, David. Unfortunately, I don't think
>> this is the problem either. As far as I can tell, the permissions
>> are correct.
>>
>> The deeper I dig trying to fix this the more I am starting think
>> that something is just totally screwed (quite possibly the server
>> itself and nothing to do with JSPWiki).
>>
>> I just keep finding more and more "weirdness" - like when I go to
>> the Attach tab on a page I get the "You don't have access to <page
>> name>" message (even though I'm logged in as a member of group
>> Admin which has AllPermission in my policy) and yet it happily lets
>> me upload... ?
>>
>> If I could recreate the problem on my test box I could probably
>> figure this out but everything works exactly as I expect it to on
>> my test box with the exact same setup, .policy and .property
>> files... I'm truly stumped.
>>
>> Back to digging...
>>
>> pete
>>
>> P.S. I may have found a culprit for the prefs not saving thing.
>> When I load the prefs page I get a javascript error about
>> "WikiGroup" not being defined (it's a line that spits out the group
>> members to the group tab of the preference page). The line is, for
>> example: "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created
>> on ....");" I'm guessing that the js error might be preventing the
>> cookie-writing from executing. But again, I don't get this error
>> on my test box so it's probably going to be difficult to track down
>> the cause.
>>
>>
>> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>>
>>> Hi,
>>>
>>> I have similar experience before. My case is that I cannot change
>>> password no matter how I tried. NB. my JSPWiki is running on
>>> CentOS linux. And finally I found that the ACL for one of jar
>>> files in WEB-INF/lib folder is not corrected set. Tomcat simply
>>> has no right to access that file.
>>>
>>> Everything works fine after I chmod the jar file to the correct
>>> ownership. Hope this helps.
>>>
>>>> Thanks for the quick response, Janne. I thought of the baseURL
>>>> thing, but I just double checked and -- as far as I can tell --
>>>> they are correct. As I mentioned, I have two wikis running --
>>>> each with a separate *.properties file -- one has a baseURL of "http://www.goodinassociates.com/gal-wiki/
>>>> " and the other is the same except the last path element is "/
>>>> client-wiki/".
>>>>
>>>> The same type of configuration works on my test machine with "http://localhost/gal-wiki/
>>>> " and "http://localhost/client-wiki" so I'm thinking it must be
>>>> something else.
>>>>
>>>> Again, maybe I'm just missing something...
>>>>
>>>> thanks again,
>>>> pete
>>>>
>>>>
>>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>>
>>>>>
>>>>> Hi ho!
>>>>>
>>>>> The probable reason is that your server has the wrong baseURL.
>>>>> This causes cookies to be written for the wrong domain name, and
>>>>> your browser won't send them back to the server (because cookies
>>>>> can only be sent to the same server which set them in the first
>>>>> place). There's no way JSPWiki can really detect this (since
>>>>> it's not actually an error case as such), so you wouldn't be
>>>>> seeing anything in the logs :-)
>>>>>
>>>>> Hope this helps!
>>>>>
>>>>> /Janne
>>>>>
>>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>>
>>>>>> Hi all,
>>>>>> (New here, so go easy on me!)
>>>>>> My problem is pretty simple to describe but it's driving me
>>>>>> batty. I'm running 2 wikis under Jetty (I have a bit of a
>>>>>> strange set up but for the most part it's similar to the "step
>>>>>> by step" guide to having multiple wikis).
>>>>>>
>>>>>> On my test machine everything works as intended but for some
>>>>>> reason on my live server preferences are not being saved to the
>>>>>> cookie. It has prev. search and asserted name but never
>>>>>> updates if I, say, try to enable section editing or change the
>>>>>> skin. This is true (both that it works on my test machine and
>>>>>> doesn't on the live server) in all browsers I've tested. It
>>>>>> doesn't give any errors or indication that anything failed, it
>>>>>> simply doesn't save them and redirects to Main. Going
>>>>>> immediately back in to the prefs shows the defaults.
>>>>>>
>>>>>> Additionally, none of widgets on the plain editor (Bold,
>>>>>> underline, insert table, etc...) do anything.
>>>>>>
>>>>>> I've looked everywhere I could think of for error messages or
>>>>>> some indication of why it isn't working and I can't find
>>>>>> anything at all.
>>>>>>
>>>>>> I could go into more detail if anyone thinks it will help, but
>>>>>> I thought (hope) there might be something obvious or oft-
>>>>>> encountered that I am just missing...
>>>>>>
>>>>>> Advice? Suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>> peter schart
>>>>
>>>>
>>>
>>> --
>>> David Gao (davidgjm@gmail.com)
>>
>
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
Replying to my own post... Anyway, it seems as though the cause of
most of my problems is javascript files not getting added to the
page. Apparently, "TemplateManager.addResourceRequest()" calls are
not happening correctly. The prefs page does not have "jspwiki-
prefs.js" included and the edit page does not have "jspwiki-edit.js"
or "posteditor.js" included.
Any ideas as to why addResourceRequest() calls would be failing?
thanks again,
pete
On Mar 10, 2009, at 11:15 AM, Peter Schart wrote:
> Thanks for the suggestion, David. Unfortunately, I don't think this
> is the problem either. As far as I can tell, the permissions are
> correct.
>
> The deeper I dig trying to fix this the more I am starting think
> that something is just totally screwed (quite possibly the server
> itself and nothing to do with JSPWiki).
>
> I just keep finding more and more "weirdness" - like when I go to
> the Attach tab on a page I get the "You don't have access to <page
> name>" message (even though I'm logged in as a member of group Admin
> which has AllPermission in my policy) and yet it happily lets me
> upload... ?
>
> If I could recreate the problem on my test box I could probably
> figure this out but everything works exactly as I expect it to on my
> test box with the exact same setup, .policy and .property files...
> I'm truly stumped.
>
> Back to digging...
>
> pete
>
> P.S. I may have found a culprit for the prefs not saving thing.
> When I load the prefs page I get a javascript error about
> "WikiGroup" not being defined (it's a line that spits out the group
> members to the group tab of the preference page). The line is, for
> example: "WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created
> on ....");" I'm guessing that the js error might be preventing the
> cookie-writing from executing. But again, I don't get this error on
> my test box so it's probably going to be difficult to track down the
> cause.
>
>
> On Mar 9, 2009, at 8:24 PM, David Gao wrote:
>
>> Hi,
>>
>> I have similar experience before. My case is that I cannot change
>> password no matter how I tried. NB. my JSPWiki is running on CentOS
>> linux. And finally I found that the ACL for one of jar files in WEB-
>> INF/lib folder is not corrected set. Tomcat simply has no right to
>> access that file.
>>
>> Everything works fine after I chmod the jar file to the correct
>> ownership. Hope this helps.
>>
>>> Thanks for the quick response, Janne. I thought of the baseURL
>>> thing, but I just double checked and -- as far as I can tell --
>>> they are correct. As I mentioned, I have two wikis running --
>>> each with a separate *.properties file -- one has a baseURL of "http://www.goodinassociates.com/gal-wiki/
>>> " and the other is the same except the last path element is "/
>>> client-wiki/".
>>>
>>> The same type of configuration works on my test machine with "http://localhost/gal-wiki/
>>> " and "http://localhost/client-wiki" so I'm thinking it must be
>>> something else.
>>>
>>> Again, maybe I'm just missing something...
>>>
>>> thanks again,
>>> pete
>>>
>>>
>>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>>
>>>>
>>>> Hi ho!
>>>>
>>>> The probable reason is that your server has the wrong baseURL.
>>>> This causes cookies to be written for the wrong domain name, and
>>>> your browser won't send them back to the server (because cookies
>>>> can only be sent to the same server which set them in the first
>>>> place). There's no way JSPWiki can really detect this (since
>>>> it's not actually an error case as such), so you wouldn't be
>>>> seeing anything in the logs :-)
>>>>
>>>> Hope this helps!
>>>>
>>>> /Janne
>>>>
>>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>>
>>>>> Hi all,
>>>>> (New here, so go easy on me!)
>>>>> My problem is pretty simple to describe but it's driving me
>>>>> batty. I'm running 2 wikis under Jetty (I have a bit of a
>>>>> strange set up but for the most part it's similar to the "step
>>>>> by step" guide to having multiple wikis).
>>>>>
>>>>> On my test machine everything works as intended but for some
>>>>> reason on my live server preferences are not being saved to the
>>>>> cookie. It has prev. search and asserted name but never updates
>>>>> if I, say, try to enable section editing or change the skin.
>>>>> This is true (both that it works on my test machine and doesn't
>>>>> on the live server) in all browsers I've tested. It doesn't
>>>>> give any errors or indication that anything failed, it simply
>>>>> doesn't save them and redirects to Main. Going immediately back
>>>>> in to the prefs shows the defaults.
>>>>>
>>>>> Additionally, none of widgets on the plain editor (Bold,
>>>>> underline, insert table, etc...) do anything.
>>>>>
>>>>> I've looked everywhere I could think of for error messages or
>>>>> some indication of why it isn't working and I can't find
>>>>> anything at all.
>>>>>
>>>>> I could go into more detail if anyone thinks it will help, but I
>>>>> thought (hope) there might be something obvious or oft-
>>>>> encountered that I am just missing...
>>>>>
>>>>> Advice? Suggestions?
>>>>>
>>>>> Thanks,
>>>>> peter schart
>>>
>>>
>>
>> --
>> David Gao (davidgjm@gmail.com)
>
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
Thanks for the suggestion, David. Unfortunately, I don't think this
is the problem either. As far as I can tell, the permissions are
correct.
The deeper I dig trying to fix this the more I am starting think that
something is just totally screwed (quite possibly the server itself
and nothing to do with JSPWiki).
I just keep finding more and more "weirdness" - like when I go to the
Attach tab on a page I get the "You don't have access to <page name>"
message (even though I'm logged in as a member of group Admin which
has AllPermission in my policy) and yet it happily lets me upload... ?
If I could recreate the problem on my test box I could probably figure
this out but everything works exactly as I expect it to on my test box
with the exact same setup, .policy and .property files... I'm truly
stumped.
Back to digging...
pete
P.S. I may have found a culprit for the prefs not saving thing. When
I load the prefs page I get a javascript error about "WikiGroup" not
being defined (it's a line that spits out the group members to the
group tab of the preference page). The line is, for example:
"WikiGroup.putGroup("Admin", "<user>\n<user2>\n", "created
on ....");" I'm guessing that the js error might be preventing the
cookie-writing from executing. But again, I don't get this error on
my test box so it's probably going to be difficult to track down the
cause.
On Mar 9, 2009, at 8:24 PM, David Gao wrote:
> Hi,
>
> I have similar experience before. My case is that I cannot change
> password no matter how I tried. NB. my JSPWiki is running on CentOS
> linux. And finally I found that the ACL for one of jar files in WEB-
> INF/lib folder is not corrected set. Tomcat simply has no right to
> access that file.
>
> Everything works fine after I chmod the jar file to the correct
> ownership. Hope this helps.
>
>> Thanks for the quick response, Janne. I thought of the baseURL
>> thing, but I just double checked and -- as far as I can tell --
>> they are correct. As I mentioned, I have two wikis running -- each
>> with a separate *.properties file -- one has a baseURL of "http://www.goodinassociates.com/gal-wiki/
>> " and the other is the same except the last path element is "/
>> client-wiki/".
>>
>> The same type of configuration works on my test machine with "http://localhost/gal-wiki/
>> " and "http://localhost/client-wiki" so I'm thinking it must be
>> something else.
>>
>> Again, maybe I'm just missing something...
>>
>> thanks again,
>> pete
>>
>>
>> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>>
>>>
>>> Hi ho!
>>>
>>> The probable reason is that your server has the wrong baseURL.
>>> This causes cookies to be written for the wrong domain name, and
>>> your browser won't send them back to the server (because cookies
>>> can only be sent to the same server which set them in the first
>>> place). There's no way JSPWiki can really detect this (since it's
>>> not actually an error case as such), so you wouldn't be seeing
>>> anything in the logs :-)
>>>
>>> Hope this helps!
>>>
>>> /Janne
>>>
>>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>>
>>>> Hi all,
>>>> (New here, so go easy on me!)
>>>> My problem is pretty simple to describe but it's driving me
>>>> batty. I'm running 2 wikis under Jetty (I have a bit of a
>>>> strange set up but for the most part it's similar to the "step by
>>>> step" guide to having multiple wikis).
>>>>
>>>> On my test machine everything works as intended but for some
>>>> reason on my live server preferences are not being saved to the
>>>> cookie. It has prev. search and asserted name but never updates
>>>> if I, say, try to enable section editing or change the skin.
>>>> This is true (both that it works on my test machine and doesn't
>>>> on the live server) in all browsers I've tested. It doesn't give
>>>> any errors or indication that anything failed, it simply doesn't
>>>> save them and redirects to Main. Going immediately back in to
>>>> the prefs shows the defaults.
>>>>
>>>> Additionally, none of widgets on the plain editor (Bold,
>>>> underline, insert table, etc...) do anything.
>>>>
>>>> I've looked everywhere I could think of for error messages or
>>>> some indication of why it isn't working and I can't find anything
>>>> at all.
>>>>
>>>> I could go into more detail if anyone thinks it will help, but I
>>>> thought (hope) there might be something obvious or oft-
>>>> encountered that I am just missing...
>>>>
>>>> Advice? Suggestions?
>>>>
>>>> Thanks,
>>>> peter schart
>>
>>
>
> --
> David Gao (davidgjm@gmail.com)
Re: Preferences not being saved
Posted by David Gao <da...@gmail.com>.
Hi,
I have similar experience before. My case is that I cannot change
password no matter how I tried. NB. my JSPWiki is running on CentOS
linux. And finally I found that the ACL for one of jar files in
WEB-INF/lib folder is not corrected set. Tomcat simply has no right to
access that file.
Everything works fine after I chmod the jar file to the correct
ownership. Hope this helps.
> Thanks for the quick response, Janne. I thought of the baseURL thing,
> but I just double checked and -- as far as I can tell -- they are
> correct. As I mentioned, I have two wikis running -- each with a
> separate *.properties file -- one has a baseURL of
> "http://www.goodinassociates.com/gal-wiki/" and the other is the same
> except the last path element is "/client-wiki/".
>
> The same type of configuration works on my test machine with
> "http://localhost/gal-wiki/" and "http://localhost/client-wiki" so I'm
> thinking it must be something else.
>
> Again, maybe I'm just missing something...
>
> thanks again,
> pete
>
>
> On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>
>>
>> Hi ho!
>>
>> The probable reason is that your server has the wrong baseURL. This
>> causes cookies to be written for the wrong domain name, and your
>> browser won't send them back to the server (because cookies can only
>> be sent to the same server which set them in the first place).
>> There's no way JSPWiki can really detect this (since it's not
>> actually an error case as such), so you wouldn't be seeing anything
>> in the logs :-)
>>
>> Hope this helps!
>>
>> /Janne
>>
>> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>>
>>> Hi all,
>>> (New here, so go easy on me!)
>>> My problem is pretty simple to describe but it's driving me batty.
>>> I'm running 2 wikis under Jetty (I have a bit of a strange set up
>>> but for the most part it's similar to the "step by step" guide to
>>> having multiple wikis).
>>>
>>> On my test machine everything works as intended but for some reason
>>> on my live server preferences are not being saved to the cookie. It
>>> has prev. search and asserted name but never updates if I, say, try
>>> to enable section editing or change the skin. This is true (both
>>> that it works on my test machine and doesn't on the live server) in
>>> all browsers I've tested. It doesn't give any errors or indication
>>> that anything failed, it simply doesn't save them and redirects to
>>> Main. Going immediately back in to the prefs shows the defaults.
>>>
>>> Additionally, none of widgets on the plain editor (Bold, underline,
>>> insert table, etc...) do anything.
>>>
>>> I've looked everywhere I could think of for error messages or some
>>> indication of why it isn't working and I can't find anything at all.
>>>
>>> I could go into more detail if anyone thinks it will help, but I
>>> thought (hope) there might be something obvious or oft-encountered
>>> that I am just missing...
>>>
>>> Advice? Suggestions?
>>>
>>> Thanks,
>>> peter schart
>
>
--
David Gao (davidgjm@gmail.com)
Re: Preferences not being saved
Posted by Peter Schart <pe...@goodinassociates.com>.
Thanks for the quick response, Janne. I thought of the baseURL thing,
but I just double checked and -- as far as I can tell -- they are
correct. As I mentioned, I have two wikis running -- each with a
separate *.properties file -- one has a baseURL of "http://www.goodinassociates.com/gal-wiki/
" and the other is the same except the last path element is "/client-
wiki/".
The same type of configuration works on my test machine with "http://localhost/gal-wiki/
" and "http://localhost/client-wiki" so I'm thinking it must be
something else.
Again, maybe I'm just missing something...
thanks again,
pete
On Mar 9, 2009, at 4:27 PM, Janne Jalkanen wrote:
>
> Hi ho!
>
> The probable reason is that your server has the wrong baseURL. This
> causes cookies to be written for the wrong domain name, and your
> browser won't send them back to the server (because cookies can only
> be sent to the same server which set them in the first place).
> There's no way JSPWiki can really detect this (since it's not
> actually an error case as such), so you wouldn't be seeing anything
> in the logs :-)
>
> Hope this helps!
>
> /Janne
>
> On 9 Mar 2009, at 23:06, Peter Schart wrote:
>
>> Hi all,
>> (New here, so go easy on me!)
>> My problem is pretty simple to describe but it's driving me batty.
>> I'm running 2 wikis under Jetty (I have a bit of a strange set up
>> but for the most part it's similar to the "step by step" guide to
>> having multiple wikis).
>>
>> On my test machine everything works as intended but for some reason
>> on my live server preferences are not being saved to the cookie.
>> It has prev. search and asserted name but never updates if I, say,
>> try to enable section editing or change the skin. This is true
>> (both that it works on my test machine and doesn't on the live
>> server) in all browsers I've tested. It doesn't give any errors or
>> indication that anything failed, it simply doesn't save them and
>> redirects to Main. Going immediately back in to the prefs shows
>> the defaults.
>>
>> Additionally, none of widgets on the plain editor (Bold, underline,
>> insert table, etc...) do anything.
>>
>> I've looked everywhere I could think of for error messages or some
>> indication of why it isn't working and I can't find anything at all.
>>
>> I could go into more detail if anyone thinks it will help, but I
>> thought (hope) there might be something obvious or oft-encountered
>> that I am just missing...
>>
>> Advice? Suggestions?
>>
>> Thanks,
>> peter schart
Re: Preferences not being saved
Posted by Janne Jalkanen <ja...@ecyrd.com>.
Hi ho!
The probable reason is that your server has the wrong baseURL. This
causes cookies to be written for the wrong domain name, and your
browser won't send them back to the server (because cookies can only
be sent to the same server which set them in the first place).
There's no way JSPWiki can really detect this (since it's not actually
an error case as such), so you wouldn't be seeing anything in the
logs :-)
Hope this helps!
/Janne
On 9 Mar 2009, at 23:06, Peter Schart wrote:
> Hi all,
> (New here, so go easy on me!)
> My problem is pretty simple to describe but it's driving me batty.
> I'm running 2 wikis under Jetty (I have a bit of a strange set up
> but for the most part it's similar to the "step by step" guide to
> having multiple wikis).
>
> On my test machine everything works as intended but for some reason
> on my live server preferences are not being saved to the cookie. It
> has prev. search and asserted name but never updates if I, say, try
> to enable section editing or change the skin. This is true (both
> that it works on my test machine and doesn't on the live server) in
> all browsers I've tested. It doesn't give any errors or indication
> that anything failed, it simply doesn't save them and redirects to
> Main. Going immediately back in to the prefs shows the defaults.
>
> Additionally, none of widgets on the plain editor (Bold, underline,
> insert table, etc...) do anything.
>
> I've looked everywhere I could think of for error messages or some
> indication of why it isn't working and I can't find anything at all.
>
> I could go into more detail if anyone thinks it will help, but I
> thought (hope) there might be something obvious or oft-encountered
> that I am just missing...
>
> Advice? Suggestions?
>
> Thanks,
> peter schart