jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schart <p...@goodinassociates.com>
Subject Re: Preferences not being saved
Date Tue, 10 Mar 2009 19:58:09 GMT
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 <pete@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)
>>>>>
>>>>
>>
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message