This page is currently no longer used. Up to version 2 of this page (see "page history" or "More info") it contained bug fixes up to May 2005. See also BugReports.

I propose that the remainder of the page be wiped clean. - Gregor


2003/05/22 - RSS Feed Attachment Link wrong#

Browser(s) n/a , RDF-Ticker from http://www.rdf-ticker.de

I noted two things about the Wiki RssFeed:

  • Links about changes in attachmens point to the wrong URL, e.g.: http://www.jspwiki.org/Wiki.jsp?page=Pic/update.png instead of the Attachment's URL.
  • Maybe the feed should not include links to attachments anyway. Instead I think the feed should include the page the file is attached to. So instead of containing all the attachments that were uploaded to the Pics page, it should contain the Pics page only once.

-- StefanRiss

Well, the URL is wrong, yes. But attachments should still be included in the RssFeed. So this is a bug.

-- JanneJalkanen

Thanx for fixing.

-- StefanRiss

Fixed in 2.0.42.

FileSystemProvider and searching#

FileSystemProvider.findPages() in v2.0.36 (and 2.1.7) never closes the files it opens, therefore causing a huge number of file handles to be allocated until the next garbage collection. This may be an issue in large Wiki sites (it's certainly a problem here), especially if you're having a very large heap (which means that garbage collection occurs rarely).

-- JanneJalkanen, 10-Apr-2003.

Fixed in 2.0.39.

2003-April-03 - Intermittent FATAL errors logged by WikiTagBase#

  • Java Version: Sun JDK 1.4.1_02
  • JSPWiki v2.0.36
  • Windows XP Professional
  • jakarta-tomcat-4.1.18
  • The used page provider: VersioningFileProvider
  • Used browsers: IE 6.026

Okay, I admit it, I never watched the log until a user complained that he "lost" an edit. I do not think this is related to his lost edit (I think he had a conflict with someone and did not understand what to do). BUT...

I took a peek in the log, I'm running with basically the "stock" logging configuration (INFO and higher, no email notification). I went back in time and looked at old logs and this issue was around back with 2.0.32-beta too.

Intermittently, and on different pages, I see either:

  • FATAL com.ecyrd.jspwiki.tags.WikiTagBase ResearchWiki:RecentChanges - I/O exception
  • FATAL com.ecyrd.jspwiki.tags.WikiTagBase ResearchWiki:JohnV - Including failed
I think the Including failed variant is the same problem, just wrapped in a JspException, as both report "Connection reset by peer: socket write error".

I'll not post the long gory stack traces here unless you want them, they all are basically the same and the only com.ecyrd... entry is IncludeTag.doEndTag(IncludeTag.java:68), which oddly enough is just trying to include a page.

Anyone have any ideas? Is this an "ignore it" sort of issue? If so, it shouldn't be logged as FATAL. To be honest I've not noticed any behavioural problems with the system the only reason I looked as because of the (probably unrelated) user complaint.

I suppose I should mention that I'm not using the default templates, but a slightly modified "mrg" template set. Let me hasten to point out that I do not think this is template related as it's intermittent. Nor do I think it's related to page content as it occurs on a random (changing) set of pages, everything from Main to RecentChanges, to whatevers.

--JohnV

Yes, you are correct, they are actually the same error. The other one is just wrapped.

FATAL in this case means that the processing has been interrupted, and no further things can be done. However, it does not kill JSPWiki as an webapp... Perhaps an ERROR should be sufficient.

Could you please send me the relevant stack traces through email? I would like to take a look, since there might be something similar going on in this site as well.

-- JanneJalkanen

Fixed in 2.1.8

2003-Mar-06: Edit, then preview, then back, and edits are gone (<security-constriant>'s enabled)#

  • Java Version: Sun JDK 1.4.1_02
  • JSPWiki v2.0.32-beta
  • Windows XP Professional
  • jakarta-tomcat-4.1.18
  • The used page provider: VersioningFileProvider
  • Used browsers: IE 6.026

Trying this on this site does 'not' show this problem. On my clean and new setup here at work, I started off by uncommenting the <security-constraint> stuff as we are limiting access to Wiki.jsp and Edit.jsp to select sets of users. To my great surprise I lost an edit when testing out the setup. Edit a page, preview that page, but the back button, and the edit was gone. I commneted back out the <security-constraint> stuff and viola, works just fine and don't lose the edit. Anybody got a clue as to what causes this and how to fix it? This isn't a bug in JSPWiki code itsself but in the interplay of Tomcat and the browser. Help!

--JohnV

Hm. I suspect that IE 6 is the problem here, since it's cache-handling is something that I have never been able to understand.

Take a look at the Edit.jsp, and especially the following lines. Tweaking them might help:

    response.addHeader( "Cache-control", "max-age=0" );
    response.addDateHeader( "Expires", new Date().getTime() );
    response.addDateHeader( "Last-Modified", new Date().getTime() );

On TWiki there is some more discussion about this problem. If anyone more versed with the intricasies of HTTP, IE 6.x and caches could help out here, that would be great :-).

-- JanneJalkanen

Just had a look at it. The problem is that if authorization is turned on, Tomcat automatically adds

 Pragma: No-cache
 Cache-Control: no-cache
 Expires: Thu, 01 Jan 1970 00:00:00 GMT

As Edit.jsp uses addHeader() the response contains Cache-Control and Expires twice. Replacing the add*Header()- calls with their set*Header() counterparts fixes the problem. The remaining Pragma doesn't matter, HTTP/1.1 clients shoudn't interpret it anyway (overwriting it with some nonsense value probably isn't advisable and there is no removeHeader() ).

-- Torsten

Thanks Torsten! That fixes it perfectly! Janne, will this change get made in CVS head? Any reason not to? --JohnV

Nope. That is, no reason not to =). I'll make the change over the weekend - I don't have the time to do it today.

-- JanneJalkanen

Bugfix is in 2.0.35.

Has this bug resurfaced? Because I turned on security for one of my work Wiki's (2.0.50), and it was causing problems much like this one. Some people would see the message "Current state = FLUSHED, new state = CODING_END" when saving.

-- MahlenMorris

Never mind. It's happening because our disk is full. Doh!-- MahlenMorris


HTTP Response headers visible#

May 24, 2002 @ 09:45 GMT+2 -- JukkaKoskelin

Not sure if this is a bug, feature or something that my Mozilla causes, but...

When registering a name in UserPreferences for second time, and from different computer (ie. did the registration yesterday from home and again today from work), the page shown after registering looks weird. It first has the registration page, then something that looks to my eye like HTTP-header:

HTTP/1.1 200 OK Date: Fri, 24 May 2002 06:38:34 GMT Server: Apache/1.3.22 (Unix) mod_jk mod_ssl/2.8.5 OpenSSL/0.9.6c PHP/4.1.1 Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java 1.3.1; Linux 2.2.20 i386; java.vendor=Sun Microsystems Inc.) Keep-Alive: timeout=15, max=90 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 2000

... And then the mainpage.

Got this from this site (so, the newest version of JSPWiki), using Mozilla 0.9.9 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313), running on Debian.

The registration works okay, though.

Yes, for some odd reason Tomcat+Apache+Mozilla -combination causes this. I haven't yet figured out why this is so. This does not occur if we run plain Tomcat, nor does it occur with other browsers. My guess is that we should upgrade Tomcat =). --JanneJalkanen

Check. :) -- JukkaKoskelin

Confirmation: never seen this with Tomcat 4.x. Since I've updated things a bit anyway today, maybe I'll give Tomcat a face lift. --ebu

This also happens on IE 6.0 -- NiiloNeuvo

OK, we upgraded to Tomcat 4.1.18. Please let us know, if you see this phenomenon again. If this does not happen, this should probably be moved to JSPWikiFAQ. --JanneJalkanen

CheckLock not working for mode not locked#

April 02, 2003 --RajeshRaheja Windows2000, OC4J (Oracle) 2.0.36

am trying to stop users from editing page if someone has locked it.

<wiki:CheckLock mode="locked" id="lock">
	<P CLASS="locknote">User <%=lock.getLocker()%> is editing 
        this page since <%=lock.getAcquisitionTime()%>.
	Please try again later - the lock expires in <%=lock.getTimeLeft()%> 
        minutes in case it is not saved.
    Press the <Back> button of your browser to return to <wiki:PageName/> or 
    <a href="<wiki:LinkTo format="url" />" class="nav2">click here</a>.
</P>
</wiki:CheckLock>

<wiki:CheckLock mode="unlocked" id="lock">
...do editing here
</wiki:CheckLock>

problem is that if the page is NOT locked, then I see no content for the editing. the first CheckLock works, but the second does not - at least not for mode="unlocked" or any other as the documentation suggests.

Hm. Worrying. Quick visual inspection does not suggest this problem. I'll take a closer look at this asap. --JanneJalkanen

Well, duh. Of course the page was locked when someone would start editing it, including the user himself. Since 2.0.39 you can check it through using "owned" instead of "unlocked".

2003-02-22: Attachment upload not working#

  • this site

When trying to upload an attachment I get the following error:

...
root cause

java.lang.NoSuchMethodError: 

Is there an old version of MultiPartRequest still somewhere in the class-path?

-- Torsten

Oops. Of course there was... :-)

Should be fixed now.

-- JanneJalkanen



2003-Mar-16: breadCrumbTrail some times does not function in a load balanced Resin 2.15#


"some time" is when it try to sync session with other machine

  • JSPWiki v2.0.32-beta

No InterWiki reference defined in properties for Wiki called "2003/03/16 11"! Failed storing persistent session attribute `breadCrumbTrail'. Persistent session values must extend java.io.Serializable.

Well, this is a bug in Resin. Or something wrong with your setup: according to the specification the value stored in the HttpSession by BreadcrumbsTag does not have to extend Serializable.

However, luckily this can be worked around in the JSPWiki code. I'll make the session attribute Serializable for 2.0.36.

-- JanneJalkanen


Trail not working#

  • this site
  • 2003-04-07

"Your trail" doesn't show anything (probably due to transition to jspwiki.org).

-- Torsten

Yeah. I took a peek and it seems to be a relatively complicated thing: the path given to the cookie by Tomcat is /JSPWiki, whereas the path that the browser sees is /. This means that the browser does not give access to the session cookie, and thus we loose session tracking completely.

We need to teach Tomcat somehow to understand about VirtualHosts.

-- JanneJalkanen

Fixed (very early in the morning of) today. Let me know if any other problems occur.

-- JanneJalkanen


OutOfMemoryError error with unclosed plugins#

There is also another bug: an unclosed plugin causes an OutOfMemoryError (TranslatorReader.handleOpenbracket()).

-- Torsten

Strange. I can't duplicate it... --JanneJalkanen

Just tested on this site. Add something like [{Test section for [RobD] to a page. -- Torsten

Um. Still can't duplicate it. And I'm not seeing any errors in the logs either. --JanneJalkanen

I must be hallucinating then. ;) Just did it again. Short howto:

  1. goto SandBox
  2. near the end there is the text Test section for RobD
  3. add [{ in front of it
  4. press save and see error.jsp appear :)

To argue with the code (handleOpenbracket()), relevant loop is:

...

testPluginNoEnd() is not failing because a curly brace at last position is the only case where it is not looping forever.

btw, while( true ) considered harmful. :-)

-- Torsten

OK, I see it now. But I can't duplicate it in isolation - there must be some complicated interplay here.

-- JanneJalkanen

Not at all, just a logic error. As I said, just delete the curly brace at the very last position of the test string in TranslatorReaderTest.~testPluginNoEnd().

To fix it you could either change the loop to

        ch = nextToken();
        while( ch!=-1 )
        {
            if( ch == ']' && (!isPlugin || sb.charAt( sb.length()-1 ) == '}') )
                break;

            sb.append( (char) ch );
            ch = nextToken();
        }

or apply TranslatorReader.diff, which is IMO a more legible fix.

-- Torsten

I see it now. Fixed in 2.0.28. Thanks!

Attachment names restricted to ISO-8859-1#

Encoding of form parameters in UploadTemplate.jsp is since 2.0.25 fixed to ISO-8859-1. With

the new version of multipartrequest it is now easy to properly read UTF-8 encoded parameters/filenames, only line 221 of AttachmentServlet has to be changed to

    MultipartRequest multi = new MultipartRequest(
                                    null, // no debugging
                                    req.getContentType(), 
                                    req.getContentLength(), 
                                    req.getInputStream(), 
                                    m_tmpDir, 
                                    Integer.MAX_VALUE,
                                    m_engine.getContentEncoding() );

If Konqueror always uses 8859-1 even if the page containing a form is UTF-8, then this is a bug in Konqueror.

-- Torsten

Fixed in 2.0.32.

Feb 12, 2003: Order of page history versus attachment history, and more#

I'm trying out 2.0.14 (on Windows) and 2.0.27 (on Mac OS X). At least in the 2.0.27 the order of entries in the history overview are different: "page history"has latest at the top (quite handy), "attachment history" has oldest entry at the top.

Fixed in 2.0.28.

16 Feb, 2003: Improved out.png#

I've attached a copy of out.png that has a transparent background. The old one (v2.0.14) had a white background which is visible if your page background is not white. --GeorgeFairbanks

Cool, thanks. --JanneJalkanen
Included in 2.0.32.

16 Feb, 2003: PageHeader.jsp unused#

In version 2.0.14b, the PageHeader.jsp is in the default template but unused by pages, like ViewTemplate.jsp. Even if this file is empty by default, it would be nice to have it included in all the pages so that people like me can just edit one file to change the page header everywhere. --GeorgeFairbanks

Well, there are only two pages that you need to modify, ViewTemplate and EditTemplate. And the other one has the header "Edit <pagename>", so I don't think you can really use a single page header.

-- JanneJalkanen

Removed in 2.0.32.

20 Feb, 2003: Problem in Breadcrumbs and trivial fix#

The breadcrumbs tag generated an extra </a>.
Fixed in 2.0.32.

Feb 7, 2003: Bug in ListLocksPlugin
#

JSPWiki Version: 2.0.26-cvs

I updated to the latest JSPWiki Version and when I added the ListLocksPlugin to the information page, I noticed my page formatting got messed up. It appears that an open-table tag (<table>) is being generated instead of a close-table tag (</table>) at the end of the table. Look at the source for this page for the following:

PageLocked byAcquiredExpires
No locks exist currently.

Thanks,

--MichaelGentry

Confirmed and fixed in 2.0.27.

Jan 31, 2003: File Upload kaput on this site (2.0.21)#

java.lang.IllegalArgumentException: Prefix string too short

Multipartrequest library is broken - the file you want to upload must have at least four characters in its name before the file extension.

--JanneJalkanen

I suggest evaluating Jakarta-commons-fileupload for a good library. --KenLiu

Did that. Unfortunately it pulled in too many auxiliary code to be of any use - it depends on over 200kB of other libraries... :-(. Until that is fixed, we'll stay with the httpmultipartrequest library. --JanneJalkanen

Just found out Jason uploaded a changed version of multipartrequest today. Seems to contain all necessary changes. -- Torsten

Included now in the CVS version. Seems to be working okay. --JanneJalkanen

Jan 22, 2003: Plugin problems#

Plugins seem like the ideal way to handle specific data types that you want to display. I'm writing one now that pretty-prints C code under 2.0.14b. However, the plugin regexp (line 147 of PluginManager.java) bails if there's a "]" or a "}" anywhere in the body. Obviously this is an issue for C code.

Suggestions?

(A neat idea would be the ability to associate simple markups with plugins, such that one could write "<<hello>>" rather than "{INSERT a.b.c.d.e etc... hello}".)

--William Morgan

The current CVS version fixes this problem. You can get it from JSPWikiDownload.

--Janne Jalkanen

I installed the nightly build and things are getting better (']'s can be included now) but it is still dying on '}'. For example, the following:

[{net.masanjin.wmorgan.jspwiki.CodeFormatter style='c'

#include <stdio.h>

/* a simple hello world program */

int main(int argc, char* argv[]) {
  printf("hello a + b\n");

  return 0;
 }

}]

is not interpreted as a plugin call until I remove the tailing '}'.

Thanks...

---WilliamMorgan

Confirmed. You're right, it's the regexp... Will fix. (If someone is good with regexps, they can save me the trouble and post a good one here :-). I don't have the time to tackle this problem probably until next Wednesday at best. I did upload two new unit tests that check for this problem in the CVS version.

--JanneJalkanen

Independent from this bug you can shorten the initial plugin line if you add net.masanjin.wmorgan.jspwiki to the plugin search path in jspwiki.properties (jspwiki.plugin.searchPath) and create a specialized sub-class of your CodeFormatter with style fixed to c. The initial line could then just be something like

[{cCode

-- Torsten

A working regexp is "\\{?(INSERT)?\\s*([\\w\\._]+)[ \\t]*(WHERE)?[ \\t]*" when you also change the first parameter in commandline.substring() (line 478 of PluginManager) to res.endOffset(0).

Fixed in 2.0.25.

Jan 21, 2003: attachment migration fails#

Updated from 2.0.1x to 2.0.22. The attachment migration seems to fail. An old dir Main-att existed, and this exception was thrown.

--ebu

Known problem, and unavoidable, I'm afraid. Please read the ChangeLog for more information.

To migrate, you must rename all attachments of the form "test.txt" to "test.txt-dir", and URLEncode all filenames.

--JanneJalkanen

Is it really unavoidable? Please have a look at the attached diff. It is much more compatible, only attachments with names containing non US-ASCII names will have to be converted manually (which are only possible to create when using Latin1 as the page encoding anyway).

And btw: If using UTF-8: It is not possible to upload an attachment to a page with a name that contains Non-ASCII characters (AttachmentServlet should use safeGetParameter()). Even if you create such an attachment manually it is not possible to get it again, there is an unmangeName() missing in listAttachments() (see diff).

-- Torsten

UTF-8 is a problem anyway: It seems that the HttpMultipartRequest library does not parse the parameters properly, or Mozilla does not encode them correctly. Konqueror seems to work, though. Using safeGetParameter() does not help, since the incoming data is multipart-encoded...

Grr.

--JanneJalkanen

Yeah, that's the upload, as also partly mentioned below[1]. But even if you manage to create an attachment for such a page you are not able to retrieve it again unless AttachmentServlet.doGet uses safeGetParameter().

It suprises me a bit that Konqueror works. This can only mean it always uses Latin1 and no UTF-8 to encode the parameters.

Interesting is also the Response-Header with the filename as there currently doesn't seem to be a standardized way to handle different charsets. Currently we send the filename in whatever encoding is switched on (and that works, of course), but strictly speaking this is invalid HTTP, as the header is restricted to US-ASCII. I also experimented with URL-encoding there but Mozilla doesn't recognize it (though IE does).

-- Torsten

Parts of the problem have been fixed in 2.0.25; ISO-8859-1 filenames seem to be working satisfactorily.

Endless loop in attachment upload#

2003-01-05
JSPWiki since it understands attachments
WinXP

There is a potential endless loop in multipartrequest.jar (more precisely TempFile.createTempFile()) when entering URLs containing parameters (like "http://ahost/foo.jsp?page=bar") in the attachment upload window. This causes it to try and create a temporary file like "foo123.jsp?page=bar" which fails, as this is an invalid filename, at least on Windows. This is causing an endless loop.

I'd suggest we (or Janne to be precise :) should add the sources of multirequest.jar to the distribution if it's open source to be able to fix that.

Torsten

I don´t agree with including library sources; they are available at Jason Pell's code repository. I imagine he would be happier to receive bug fix suggestions directly. --ebu
Thanks for the link. I'll send my changes also to him. The thing just is that I also made other (though minor) changes necessary to implement "Ability to upload files directly from an URL" that might not be very interesting for the general distribution. And it's only 2 files that are needed (out of 4), which could even easily be reduced to just 1 file. -- Torsten
The Sourceforge project page seems very quiet. Let us know if you don't get an answer or Jason is not interested in continuing the support for the library, since it may mean that we have to start including a patched version of the multipartrequest.jar with JSPWiki. --JanneJalkanen
I got an answer from Jason saying that he tries to find the time to make a 1.3 release including the things that piled up during the last 6 months.
I don't quite understand what speaks against including it though, at least until there is the final 1.3 release. We would gain (independent of an external schedule):
    • fix for this bug
    • [#1] proper fix for mangled attachment names if they contain non-US-ASCII characters and UTF-8 is used. This could of course also be fixed temporarily using the current static setEncoding-method as the number of JSPWiki-installations with multiple instances on the same server running different encodings probably isn't very large.
    • beeing able to implement direct upload from a URL
Merging back should be very easy, once it is released. -- Torsten
New httpmultipartrequest library v1.30b3 is now a part of JSPWiki --JanneJalkanen

Text Formating options don't match between EditPageHelp & TextFormattingRules#

2003/1/8 JSPWiki 2.0.11-beta Sun Java 1.3.0 Linux - Redhat 6.2 Tomcat 3.3.2

The text formatting rules indicated in EditPageHelp & TextFormattingRules do not match in the sample pages that come in the distribution. For instance: The information about footnotes is missing from the EditPageHelp.

-- RobertMcGovern

Missing information is okay and deliberate: I did not want the EditPageHelp page to grow too big. There should probably be a note that a complete list is in TextFormattingRules, though.


Windows and Attachments#

  • JSPWiki 2.0.16, Windows 2k. (From TorstenH, noted by JanneJalkanen so that he does not forget these, as he often does when people just send email.)

Files that have no extension fail when uploaded. This is because the BasicAttachmentProvider writes files of the form "0." and "1.", which are not legal names under Windows, I think.

--JanneJalkanen

If you have a look at 'urlUpload.zip' I sent you on Jan 7. it should be very easy to fix that if you add escaping of a dot at the end of a filename in the methods encodeFileName() and decodeFileName() in BasicAttachmentProvider. Btw., this patch also makes filenames with non-USASCII characters work (see end of this page).

-- Torsten

Yeah, I know... I just had to put it here so that I wouldn't forget it :-). The original reason why we use the dot-format is that if you want to open the archived file using a standard file browser on the server (like Konqueror or Windows Explorer), you could just double-click it. That is why we didn't do any escaping. (But I forgot about the ASCII issues.)

-- JanneJalkanen

Adding the extension to the version is a very good idea and my changes don't break anything there. It just uses URL-encoding to encode the directory name (and preserves all dots btw). Only escaping a dot at the very last position with %2E should work. The actual content file can remain as it is (despite the cutpoint-issue).

-- Torsten

Fixed in 2.0.25.


Jan 25, 2003: WikiSecurityException#

Latest cvs tree 25/1/2003

Was looking at the source WikiSecurityException, at present it won't build.

In the class filespace it is currently located in com/ecyrd/jspwiki/auth but its package name is com.ecyrd.jspwiki

Also WikiSecurityException extends WikiException which is in the com.ecyrd.jspwiki but that package is not imported.

Oops, no wonder it caused problems here. Ebu, this is your fault =).
Fixed in 2.0.23.

Feb 1, 2003: Weblog calendar module sorts wrong#

February entries show up after Jan on the blog page. Will commit a fix, if I manage to get my day-night rhythm normalized this weekend.. --ebu

Fixed in 2.0.24.

Jan 15, 2003: Skipping Reserved Chars within Plugin Calls#

This is a subsection of the macro/script idea below; I'm making a separate entry since this is also a smaller modification in code, and to emphasize its usefulness. (Others have also expressed a fervent desire for skipping parsing within plugin calls, but they're wary of irritating Janne.;)

I suspect this is not such an involved matter if we'll settle for a kludgish solution. Implement?

--ebu

You all, of course, understand that if our one and only reserved character ']' is skipped during plugin parsing, the parsing will never end? :-)

Other than the closing bracket, everything else is passed verbatim to the plugin, ever since the TranslatorReader was changed a couple of months ago.

The only possible idea I can think of is to change the parsing code so that if a hyperlink starts with [{ it should also end with }] before parsing ends.

-- JanneJalkanen

Hm. Either that, or we'd had to keep track of bracket context. Need to think about this some more.

--ebu

That you can't do unless you understand the language itself. Which would mean that you would need to

  • Have TranslatorReader somehow understand the scripting language,
  • have plugins that would grab in the whole page and do all parsing themselves, or
  • have plugins that are capable of doing stream translation and tell when the script ends.

Neither of them sounds very robust or easy to implement to me.

-- JanneJalkanen

I can't see much of a problem here. Inside a link you only have to recognize '|' and '}]'. In the rare case someone has to use }] as plugin input he has to write }]. Same for '|'. Only problem I can see with that is that some languages could require the '|' rather often. To avoid lots of escaping we could add another environment that doesn't has to recognize '|' only for plugins ([[{ ... }]] for examle).

-- Torsten

We recognized '|' inside plugins? That's news to me... :-)

The current structure as pseudocode is as follows:

If the current character is [, then
read text until the next ]
if the text starts with [{, then it is a plugin, and handled in handlePlugin()
else the text must be a hyperlink, and we must find a '|'.
etc...

The }] recognition should work, tho'.

-- JanneJalkanen

Oops, you're right, forget the '|'. Confused that with ordinary links. Recognizing [{ and }] not with the link code and using the escape scheme from above should work though.

-- Torsten

And this treatment of ] is quite problematic for me as I am trying to put a regexp into a plugin parameter. I am more than willing to fix this for good in the parser as soon as we are able to run a 2.0 based wiki (ebu has some issues with the authentication code).

If the current character is a [ and the next one is a { assume we are doing a plugin.
Otherwise it must be a hyperlink.  And plugins then end in }].

-- NiiloNeuvo

Fixed. Plugins are stopped only when }] is encountered since 2.0.17. --JanneJalkanen

Search faulty#

  • Jan 10, 2003
  • JSPWiki v2.0.12-cvs
  • Java 1.3.1_04
  • Win 2k Prof
  • Tomcat 4.1.12
  • IE 5.x

I just installed the jspWiki. Then I searched for jspwiki in the Search. i got 16 hits. If I click refresh button on the browser, the list of matches changes to 4 or so. Hitting Refresh again gives an error as follows in the page:

An unknown exception javax.servlet.jsp.JspException was caught by Error.jsp. This the entry in the log file:

<snipped>

Fixed in 2.0.14. This occurs in Tomcat 4 because it pools tags, and there was a field in SearchResultsIteratorTag that was not cleared properly.

May 3, 2002 -- MattMower#

I would like to be able to put a graphical logo into the heading above the "LeftMenu" to replace the name presented there. Whilst I could just edit my Wiki.jsp (or whatever file it's in) I wondered if there was a better & more general way to go about this?

JanneJalkanen: Nope, sorry. You'll have to deal with manual editing. Having said that, I'm currently considering a fully-fledged skin system, based on CascadingStyleSheets.

Wouter: If you're considering changing the way the user interface is built, may I propose the use of Tag Libraries to "package" the JSPWiki functions? That would solve my problems as well, when I update JSPWiki engine that we use for our intranetsite (with its own look and feel, currently implemented by laborious editing of the original JSP files...).

JanneJalkanen: Yes, I realize this is a problem. This is exactly why we'll need to change the way the JSP pages are handled now - otherwise updating the engine is far too laborious.

The only problem is, that I am not too keen on using JSP tags. Some of the reasons are detailed here... I've thought up a template-based solution, but I am seriously considering JakartaVelocity as a more viable solution to JSP.

Wouter: It is absolutely true that JSPs that intermingle markup and code are a very bad idea. However, I'm not convinced that adding an extra layer (like Velocity) is the best answer. Have you had a look at the Java Standard Tag Library, that was published not too long ago? Having an easy way to display your template in a browser does not really strike me as essential (there are other ways to document your templates, especially when they are made in XML)...

JanneJalkanen: Well, JakartaVelocity would replace the JSP pages, so it would not be an extra layer as such. I took a quick peek at the JSR052, but I am not yet too convinced that it would make the job of the template maker any easier. I though more or less about doing something similar to RadioUserland templates (but with JSP), which are quite easy to understand.

I guess the point is that in order to make your own template, you would only need to know HTML and Java (or JavaScript), without having to learn any auxiliary language (such as the JSR052). If I can keep it that simple, then I will; if it turns out to be impossible, then I'll start looking into tag libraries or JakartaVelocity.

JanneJalkanen: Oh yes, BTW. I put a short sample on how I was thinking about doing the new templates: check out this link and let me know what you think - easier than the current one, yes? NB: This is obsolete now.

Wouter (2002-07-16): Your latest attempt does seem easier, indeed - but it still does not protect me from having to know all the details of the Java code in the JSPWiki engine. Actually, if you could add a way to access whatever we need through the WikiContext, then you're very close to what Tag Libraries would do; only the syntax would be different. I'm not fond of scripting in an HTML file - I suppose that is my main problem with the current situation (a syntax-coloring text editor like SCITE can easily handle XML, but not scripting in HTML or JSP). An alternative would be to "package" all these service calls in a JavaBean, that would contain the one and only public interface to the Wiki Engine. You could use a similar mechanism for the plugins...

JanneJalkanen: Perhaps. I haven't made up my mind yet. I don't want to put too much stuff inside Java classes, because that means that if you want to change the functionality (instead of just the layout), you would need to recompile. You might say that the we're currently doing a MVC model, with the View and Controller in the same file (Java code first, then the HTML layout). This is my main gripe about the situation. However, there are some cases when you really want to tinker with the Java code as well, so providing a place for them in the JSP pages makes sense to me.

As for JavaBeans, I am not seeing a clear advantage in using them. They share some of the problems of tags.

And yeah, my problem with tags is the syntax (and the fact that they add a non-obvious layer to the whole thing - see JakartaVelocity website for details. Functionally, these methods are equivalent, I agree. Embedding scriptlets is one way, tags are the other, but both have their problems as well.

Wouter (2002-08-06): I have been doing some research, and I have noticed that there is such a thing as the Velocity JSP Tag Library. I haven't tried it, but it seems to me that this allows you to use Velocity in the Wiki page content - just like the JSPWiki plugins. I'll be investigating this further; there seems to be a lot of potential in Velocity (and Turbine)... But I still think there is too much Java code in the current JSP's. I remain convinced that Tag Libraries are the way to go to solve that problem: they clearly separate the Model (the base functions of JSPWIki) from the Controller (the taglib), thereby stopping the View (JSP) from having to know all the details of the Model (but I don't have to convince you of the advantages of MVC development, I suppose).

JanneJalkanen: Anyway, this discussion is pretty much moot know, since we're really moving towards JSP tags. Check out the current version of JSPWiki 2 from JSPWikiDownload - beware, not all works though. Nearly everything is now tagified, and we'd need to discuss a couple of other things, like unifying plugins and tags, as well as variables on pages.


May 29th, 2002 -- NiiloNeuvo#

Simpler plugins#

I am writing a couple of plugins that our end users will be using a lot. The current plugin format is a bit complex (and long). I suggest some method of being able to use plugins as <plugin arg1=42>.

The method you suggest exists: it is called Tag Libraries... Actually, you would have to write <XX:plugin arg1="42">, XX being the namespace for your tag library. (Wouter, 2002-07-15)

Wouter, plugins are inserted after the JSP page has been compiled. I believe that you could route around this using JakartaTurbine, but that seems to be overkill for something that does not seem to be a really serious problem. Especially since it would mean that you would recompile the page at every GET. --JanneJalkanen

Janne, I suppose you mean: "the content generated by the plugins is inserted after the JSP page has been compiled"? If so, the same goes for TagLibs... But you're right, of course: you can't use TagLibs while editing the Wiki pages (I'm working so hard on the JSP's that I forget to use - and think about - the plugins). --Wouter, 2002-07-26

It also wouldn't be a bad idea to give a search path for plugins, so that you don't need to prepend "com.basen.foo.project.plugins" to everywhere.

Also the SQL syntax is bad karma ;-)

Actually, since 1.7.9 you can now just say [{INSERT CurrentTimePlugin WHERE yadda}]. It also allows quoted parameters, which the older versions did not allow. You can't yet use your own search path, though, but it could be easily added. I'll do it in the next version. --JanneJalkanen.

Excellent. ++NiiloNeuvo

NB: JSPWiki 1.7.10 now contains a "jspwiki.plugin.searchPath" property. --JanneJalkanen

Since 1.9.30, it is now possible to omit the INSERT for a very simple plugin model.

Page specific plugin 'sessions' #

Sept 13, 2002 NiiloNeuvo

As background information: I have somehow started using JSPWiki as a replacement for .jsp, .vm or .php. For this purpose this system seems to work very nicely. There is no way I could accidentally add code of any sorts to my pages (as seemed to happen with even .vm). Editing of the pages is also quite simple.

What seems to be needed in this model is an ability to distinguish that an instantiated plugin resides on a same page impression as another instantiated plugin, as I seem to have a need of setting things up in one plugin and using that information on other plugins on the same page.

What I need is a Object that can be set/get from a plugin that is saved through the whole page for subsequent plugins on the same page. After the page has been displayed it can discard the Object.

The wiki-page could look like the following (I am not planning to do the following):

[{INSERT Set var1='100' var2='200'}]
[{INSERT If val1='$var1' expr='<' val2='200' result='var1 is less than 200'}]

And the actual plugin would do something on the lines (do not use this as an example, I do not know how params behaves from one invocation to another):

public class Set implements WikiPlugin {
  public String execute(WikiContext context, Map params) {
    context.setPageData(params);
  }

public class If implements WikiPlugin {
  public String execute(WikiContext context, Map params) {
    Map storedMap=(Map)context.setPageData(map);
....
  }
}

I hereby name this new programming language Wikish.

--NiiloNeuvo

Argh, a plugin-based language ;D. Sounds doable, and useful in the context Niilo and I are using wiki for. Think more of complex plugins that need previous information than Niilo's example above. But is it KISS? Janne, opinions? I can code the patches for both branches if we settle on something.

--ebu

I think that getting the JSP PageContext available to the plugins should be quite sufficient, yes? Mmh. On second thoughts, this might be a bit difficult, and sort of odd, since we already use the PageContext to store the WikiContext.

Oops. No, pageContext is not available in all cases, such as when someone makes an XML-RPC request for the page HTML.

However, since pageContext sort of already gives everything that you need, it might be desirable to create a pageContext on-the-fly. I don't know whether this is possible.

--JanneJalkanen

OK. Since 1.9.30 this feature is available through WikiContext.getVariable()/setVariable(). --JanneJalkanen

Plugin issues #

Sept 23, 2002 NiiloNeuvo

I have found some features in the plugin management problematic:

1. Reference manager on boot loads every single plugin in. This is extremely slow and totally unnecessary.

JanneJalkanen: Only if you use plugins extensively :-). Anyway, this is quite fixable, and requires only minor modifications.
ebu: How about an expandPlugins flag in the WikiEngine, which the ReferenceManager can turn off? RM definitely shouldn't parse their output, that's true. (Hm.. what's this semicolon-colon thing?)
JanneJalkanen: Anyway, this was fixed in 1.9.3something.

2. All plugin output is wiki-parsed. It is quite difficult to safeguard against this as the wiki language doesn't have easy ways of escaping things. It is much easier to write plugins that do HTML-output.

JanneJalkanen: On current trunk, it is not. However, plugin input is wiki-parsed, because the translator does not know when you're inside plugin definitions and when not. This may be quite difficult to fix.

++ NiiloNeuvo: Oh, that might be the case. In general the whole parsing thing needs rewriting. ebu promised to do that once he has time (probably not very soon ;-))

JanneJalkanen: Be warned that it is not trivial. I have a gut feeling that many things will break down...

Also a non-issue now, since the new TranslatorReader has landed in the current development branch. --JanneJalkanen

Attachment inlining plugin#

November 2, 2002

No, attachments are not there yet, but I'll jump the gun a bit. =) I've found the ability to store an image as an attachment and to inline it at any suitable place within a wikipage very convenient.

Volunteer.

--ebu

Attachments code handle this properly.


Page titles look funny#

v2.0.0

New beautification code is not working as expected: Certain page titles are chopped off in the wrong places (such as JSPWikiFAQ. Grr.

--JanneJalkanen, 09-Dec-2002.

Fixed in 2.0.7.


Restoring previous versions not working?#

Phoenix 0.5, JSPWiki 2.0.3.

Attempting to restore a previous version of a page results in a Conflict message, even though nobody else is editing the page.

--JanneJalkanen

Fixed in 2.0.4.


NPE while uploading file from url: http://..#.

AlainRavet - 12 Dec 2002
version 2.0.0 (happened in this very page)

When attaching a file, if you put a valid web url in the input field, and press /upload/, you will

  • get an error message (see below), and
  • an empty attachment (0 bytes) will be associated/attached to the page

I tested it on this site => check at the bottom of this page.

url: http://cruisecontrol.sourceforge.net/banner.gif

java.lang.NullPointerException
	

Upload.jsp is notoriously sensitive to the data you input. You can't put in an empty value, nor you can put in an URL (which you shouldn't be able to do anyway, BTW :-). Will fix.

--JanneJalkanen

> which you shouldn't be able to do anyway
Why? It would be a nice shortcut. It saves the "download temporarily to local", and "delete temp. from local" steps.
When creating a page about a product with a site, I like illustrating it with a logo, from their site. This is why I tried the url thing.

--AlainRavet

You shouldn't be able to do it because there is no code for it in the current JSPWiki base :-). As for whether the code should be written... Well, I am not certain. It sort of feels like a good idea, but it would make inadvertent copyright violations possible - not everyone realizes the difference between linking and copying. The other thing is that writing the code for that might be a bit hairy - I don't know how much you would need to get into the HTTP spec to be able to do that properly.

--JanneJalkanen

NPE fixed in 2.0.4.


Attachment Bug#

Using v 2.0.0-alpha on this site; IE 5.0

  1. Select Attach file...
  2. Leave input field blank
  3. Click on Upload

-- PaulDownes, 12/11/2002

See above for the NPE while uploading... Same thing. --JanneJalkanen

Fixed in 2.0.4.



version 1.9.48

Ex : JSPWiki:RecentChanges

AlainRavet

Um, yes. I just noticed it myself. It needs a bit of work, since you can actually refer to this wiki with an InterWiki link... Like this Edit:BugReports. Needs a bit of poking around, nothing serious, move along, nothing to see :-).

-- JanneJalkanen

Fixed in 2.0.1. Any InterWiki link that leads outside the wiki is now tagged with the link icon.


CamelCase not ignored inside code block.#

v2.0.1

In this block, CamelCase should be ignored.  However, it is not.

Fixed in v2.0.2.


Unknown parsing bug#

2002-12-12#

When this page is placed into the wiki storage dir, V2.0.0 and V2.0.1 run out of memory when parsing. Suspect an error in TranslatorReader, will write a test case soon(tm).

--ebu

Test case in, and I managed to pin it down to a very simple test case. However, I have no idea whatsoever what the problem is at the moment. If you want to help, please get the latest code and try and fix TranslatorReaderTest.testBrokenPageShort().

--JanneJalkanen

Fixed in v2.0.2. Note to self: always test for EOF. Always test for EOF. ALWAYS test for EOF.


JasperException after upgrading from 1.9.35 to 1.9.48
#

2002-12-08
JSPWiki - 1.9.48
java 1.4.1_01, Windows XP, Tomcat 4.1.12
AlainRavet
002-12-08 16:26:55 Application 8310136 requests WikiEngine.
2002-12-08 16:26:55  Assigning new log to 8310136
2002-12-08 16:26:58 JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: null
...

This looks like what I encountered. (jspwiki.log may have a better report.) This was a matter of missing properties for the new attachment code. Fixed in CVS by added null checks. For a quick fix, add something like this to your jspwiki.properties:

jspwiki.attachmentProvider = BasicAttachmentProvider
jspwiki.basicAttachmentProvider.storageDir = /p/web/www-data/jspwiki/

--ebu

It did the trick. Thanks. --AlainRavet


Cannot rely on ServletContext.getRealPath(...)#

2002-11-19
The JSPWiki JSPWiki - 1.9.37
java version is "1.3.1_01"
Operating system is Windows 2000 Pro
Deployed on JBoss 3.0 / Tomcat 4.1.x

When deployed through JBoss the method call ServletContext.getRealPath("/") returns null.as documented in the javadoc for getRealPath :

public java.lang.String getRealPath(java.lang.String path)

Returns a String containing the real path for a given virtual path.


...

Returns:
a String specifying the real path, or null if the translation cannot be performed }

Which in turn leads to a nullpointerException when looking up the WikiEngine isntance.

Line 162 of WikiEngine.java ( com.ecyrd.jspwiki.WikiEngine )


        ServletContext context = config.getServletContext();        
        String appid = context.getRealPath("/");
        ...
        WikiEngine engine = (WikiEngine) c_engines.get( appid );

--ØyvindLøkling

Ah, bugger. Thanks for this information. Does JBoss always give a null for getRealPath()? What would be a good way to figure out an unique servlet id in this case?

--JanneJalkanen

This is not really a JBoss problem. If you deploy war files without unzipping them in a directory yourself, then the server isn't required to return a real path, since there isn't really a real path. I have a similar problem myself using Jakarta Tomcat 4.1. If you want a per servlet you might consider simply getClass().getName(). (Hmmmm. I now see that would require you to pass a reference to the servlet itself. Maybe not such a good idea after all.) Or use the ServletConfig object itself to index. I don't like that option, but then again, to be quite honnest I don't understand the idea of a per servlet WikiEngine at all.

--WilfredSpringer

OK. A preliminary fix is now in CVS, in version 1.9.40. Please check if this helps.

--JanneJalkanen, 24-Nov-2002.

I tested the cvs version as of 1 Dec today, and there are still errors in connected to the deployment in a war. For example in the constructor of WikiEngine that also uses RealPath, fixed that by using getResourceAsStream to get the properties file. At the moment I get errors in the getPage method, m_pagemanager seems to be null. I will look into this when I have the free time and see if I can come up with a patch in the next few weeks.

--ØyvindLøkling , 4-Dec-2002

I now have JSPWiki working under JBoss :-) The errors in getPage mentioned in my last post was due to wellknow facts about WindowsInstall. I also added a configuration option to disable log4j configuration as this is already set in a JBoss deployment enviornment. This is the fix:

<snip>

--ØyvindLøkling

Thanks, but isn't it just enough to remove all log4j statements in the property file? Or should we just make a check for the existence of log4j.rootCategory or any log4j.* properties instead of making a new property?

--JanneJalkanen

Yes, agree. The main purpose of the fix was to patch the reading of the properties file, the log4j changes was something I added rather quick to see the debug statements in the jboss log :-) Please do whatever you find best regarding the log4j functionality.

--ØyvindLøkling

Fixed now in 1.9.45.

-- Janne Jalkanen, 06-Dec-2002.

BTW, I've got a few email questions about the JBoss and log4j compatibility thingy. Note to self, move this explanation to JSPWikiFAQ.

Plain HTML in Wiki-Markup#

2002-12-05
JSPWiki - 1.9.42

Is it intentional that html-Markup inside a Code-Block is sent verbatim to the browser (see end of MakingAnUploadServlet)? I consider this quite dangerous.

-- TorstenH

No. In fact it was fixed in 1.9.44. :-)

-- Janne Jalkanen.


<TD> tags not closed#

  • August 14th, 2002
  • JSPWiki 1.8.2
  • Java version 1.4.x
  • Windows 98 Second Edition (German)
  • gefionsoftware LiteWebServer, Tomcat 3.2.2
  • Opera 5.12 [de] (but problem is browser independent)

AndreasRozek: Oops - within the HTML output, table data cells (starting with <td>) don't seem to be closed with </td> - is that observation correct? How can I fix this?

JanneJalkanen: This is true and known. JSPWiki does not unfortunately close many tags, including lists. You'd need to rewrite TranslatorReader to do that. Is this a serious problem?

Serious or not, the new TranslatorReader allowed us to fix this for 1.9.36.

Footnotes dying unexpectedly on Preview#

Sep-30, 2002. 1.9.26.

Creating a new page with a footnote on it throws a NullPointerException during Preview.

--JanneJalkanen

Seems to be fixed in 1.9.36, though I can't remember fixing this.


2002-11-07 ebu

This may well be more of a POST or java issue, but: if you enter HTML character entities, such as

τεστ (& tau ; & epsilon ; & sigma ; & tau ;)

they are converted to the real characters at some point along the line. Edit this page to confirm.

Not sure whether to consider this a feature or a bug... (This observed with 1.9.30-cvs, JDK1.3.1, tomcat-3.2.3.)

It is a good question what should be done in this case. I don't really know, which would be preferable. --JanneJalkanen

Entities are now correctly preserved in 1.9.36.

2002-11-07 ebu, any version up to 1.9.30-cvs, any jdk/os/server/page provider/browser

Minor bug/feature: code block text can't be written on one line. It would be convenient to be able to do e.g. numbered lists with escapes for weird file names for system configurators.

Example:

__this is bold despite being in a code block__
__this is not bold, thanks to code block tags on their own lines__

Fixed already in 1.9.32, thanks to a new TranslatorReader. --JanneJalkanen


No way to write vertical bars in table cells#

Example here (please read the source):

trying "double-quote" escapingcell'
trying "double-underline" escapingcell_
trying "double-curved-brace" escapingcell}
trying "triple-curved-brace" escapingce|ll

You're right - there is no escaping. Except you could of course use the "|" character code, which is #124.

(Darn. We seem to kill entities. That's a real bug...)

--JanneJalkanen

Bar escaping with tilde (~) now works in 1.9.36.

Bracket escaping not working#

JanneJalkanen, 07-Aug-02
JSPWiki 1.9.22.

Escaping brackets:

 
[[]  --> [], but no hyperlink.

does not seem to be working properly.

Fixed in 1.9.23.

Copying files by hand does not work#

JSPWiki 1.9.23.

This is really strange: copying new Wiki files by hand into the storage directory does not work. Even when you restart tomcat. Even when you kill all java processes, you still get the previous versions of the files. Funny. Suspicion: this has something to do with RCSFileProvider. (This also explains some of the sluggishness - for each page you get three RCS processes: one for page, one for LeftMenu, and one for LeftMenuFooter. Oops. --JanneJalkanen

Should be fixed in 1.9.25.

baseURL is now mandatory.#

JSPWiki 1.9.22

Not a bug, but a change of behaviour : if you don't define jspwiki.baseURL, you'll only get a blank page as a result.

It's a bug. For now, define baseURL as a workaround. --JanneJalkanen
Fixed in 1.9.23.

Plugin instantiation failure error#

Sep 11, 1.8.1, 1.4.1, Win2K, Tomcat, local hack, IE6.0

My plugin threw a class cast exception due to my bad programming. Wiki thought this meant that my class wasn't a WikiPlugin and complained something on the lines 'Not a wiki plugin'.

You should try to instantiate the class first and then cast it to be able to differentiate the actual errors.

--NiiloNeuvo

Well, Wiki plugins are not supposed to throw exceptions in the constructor, hence the plugin must not have been a wiki plugin. Q.E.D. ;-)

But you're right. It should catch the exceptions separately. However, due to possible pooling in the future, putting extensive initialization inside the constructor is not recommended.

--JanneJalkanen

Fixed in 1.9.24.


August 7th, 2002#

  • after upgrading from version 1.8.2 to 1.9.12 :
  • Java version 1.3.1 and 1.2.2
  • NT and Solaris
  • Tomcat 4.0

There appears to be a problem when adding a new page. The problem appears to be that the WikiPage object used in Edit.jsp is null when the page doesn't exist on disk (probably down to the FileSystemProvider returning a null WikiPage when the file doesn't exist on disk).

Update: It also happens with Wiki.jsp if you attempt to access a page that doesn't exist (page=NoneExistantPage)

Fixed in 1.9.17.


July 19th, 2002 Killer#

"mod_jk breaks UserPreferences"#

If the mod_jk is used with 1.8.1 it becomes impossible to change the UserPreferences. The error that is thrown to the JSPWiki.log is:

2002-07-19 09:42:04,085 [Ajp13Processor[8009][3]] WARN com.ecyrd.jspwiki.UserProfile JSPWiki:Main - 
Missing or broken token in user profile: 'username%3DKalleKivimaa'

A quick and dirty fix to this is to change com.ecyrd.jspwiki.UserProfile.java as follows:

import java.io.UnsupportedEncodingException;


    public void parseStringRepresentation( String res ) 
    { 
        try 
        { 
            if( res != null ) 
            { 
                res = TextUtil.urlDecode(res.getBytes()); 
                StringTokenizer tok = new StringTokenizer( res, " ,=" ); 
 
                while( tok.hasMoreTokens() ) 
                { 
                    String param = tok.nextToken(); 
                    String value = tok.nextToken(); 
                     
                    if( param.equals("username") ) 
                    { 
                        m_userName = TextUtil.urlDecodeUTF8(value); 
                    } 
                } 
            } 
        }
        catch( NoSuchElementException e ) 
        { 
            log.warn("Missing or broken token in user profile: '"+res+"'"); 
        } 
        catch( UnsupportedEncodingException e ) 
        { 
            log.warn("Invalid encoding for: '"+res+"'"); 
        } 
    } 

JanneJalkanen: Interesting. We use mod_jk at ecyrd.com, and this seems to be running quite okay. Can you detail the browser, JSP container, Apache version, etc?

JanneJalkanen (15 seconds later): Hey! Is that space in the UserName intentional ("Ki vimaa") or is it just a cut-n-paste error? Having a space in the name would probably kill the parser, yes.

Killer Cut'n'paste error, fixed it. Tomcat is 4.0.3, Apache is 1.3.26. Browsers used were Konqueror and Mozilla. Ecyrd.com works fine with the same Konqueror which had problems with my site. It seems that UserProfile.java trusts that the container decodes cookies but at least my Tomcat/Apache combo with mod_jk does not do this (ProxyPass worked fine, though).

JanneJalkanen: You're probably right. We do run the parameters through WikiEngine.safeGetParameter() which does the same trick as you're suggesting here, so it might be a good idea to do the same thing to cookies as well.

Killer I think that would be the best way to do it. The performance loss is negligible and even if the behaviour I'm experiencing is against Servlet specifications (I don't know and am too lazy to check :) it would be a trivial change to JSPWiki and would help people using possibly broken containers. BTW, even though I ran into this within hours of starting to use JSPWiki, thanks for clear code and error messages, it took me 10 minutes to figure out what was wrong and how to fix it.

JanneJalkanen: Fixed in 1.8.2.


July 13th, 2002 NiiloNeuvo#

"No difference"#

I read this wiki by looking at the Recent Changes to see what has changed. Most of the pages are rather long so I just read the diffs.

The problem is the first link that asks for diffs between current version and current version (which obviously gives out "No difference").

JanneJalkanen: Yes. In fact, this also happens with diffs new pages as well (due to the WikiPageProvider API). Will be fixed, but in the meanwhile here's what I do: I go to the PageInfo display, then click on the date of the last version I remember seeing. This will give you a diff between that version and the current version.

JanneJalkanen: Fixed in 1.8.2.


July 11, 2002 StevenSchulman#

Can't install version 8.0#

PLEASE HELP!!

I installed version 7.0 on a WebSphere server, but need some of the features of 8.0. I wiped out 7.0 and did a fresh, clean install of the 8.0 war file. The result is:

A recursive error was detected.
The server cannot use specified error page. Please check the application error-path.


Original Error: 
Error Message: Server caught unhandled exception from servlet [file]: 
Server caught unhandled exception from servlet [jsp11]: 
java.lang.StringBuffer: method append(Ljava/lang/StringBuffer;)Ljava/lang/StringBuffer; 
not found
Error Code: 500
Target Servlet: file
Error Stack: 

--------------------------------------------------------------------------------
Root Error-1: java.lang.StringBuffer: method append(Ljava/lang/StringBuffer;)Ljava/lang/StringBuffer; 
not found
<other stuff snipped away>

The problem seems to be that StringBuffer.append(StringBuffer) doesn't exist. According to the JavaDocs, it DOES NOT EXIST. When I look at the source code, at a minimum it is used in TranslatorReader.java for the cleanLink(String), where there is clean.append(component), where both "clean" and "component" are StringBuffer.

I'm obviously overlooking something obvious. Can you PLEASE help?

Thanks

Steven Schulman steven.schulman@ssa.gov

MahlenMorris: By 8.0 do you mean 1.8.0? Try installing 1.8.1 instead. 1.8.0 was accidentally compiled under Java 1.4. This caused much gnashing of teeth all around.

And don't worry about StringBuffer.append(StringBuffer) not existing. It's using StringBuffer.append(Object).

Hope that helps.

JanneJalkanen: Yupyup. This smells exactly like the 1.8.0 compile problem... StringBuffer.append(StringBuffer) didn't exist until 1.4... Perhaps I should change it to use StringBuffer.toString() first. Sigh. Upgrading to 1.8.1 should solve all problems.

StevenSchulman: THANKYOU!!!!! Works great!


July 11th, 2002 NiiloNeuvo#

Plugin output being parsed#

I have a plugin that produces JavaScript. The problem is that plugin produced content goes through the wiki element parser. Some way of returning content that should not be parsed would be nice.

The sample below is possibly slightly difficult to read:

 return "<script language=\"JavaScript\"><!--\nfoo='';\n--></script>\n";

And what I get is (note the start of italics after foo=):
<script language="JavaScript"><!--
foo=<I>;
--></script>

JanneJalkanen: Hm. Difficult this is. The problem is that if you have a construct like this:

Hello, what a [{INSERT WeatherReport}] ''day'',

it is very difficult to let the translator know which parts of the line have already been translated and which have not. The only possible solution that comes to my mind is to move the plugin detection as the absolutely last item on the translator priority list. A quick try suggests that it does not break anything.

JanneJalkanen: A fix is in 1.9.5 (currently in CVS). None of the UnitTests broke, so we may stil l have hope. It's possible now that certain kinds of URLs are no longer valid, though.

ebu - We still want to have some plugins produce WikiText, don't we? (Isn't the Referenced by menu on the left an example of that?) How do you select between non-translated and translated plugins?

JanneJalkanen: I don't. ReferringPagesPlugin does the HTML translation by itself.

JanneJalkanen (19-Jul-2002): Did the 1.9.5 fix work as you expected?


June 21, 2002 -- PaulThomas#

I get the same problem as ldodds (next post down), but I am performing a clean JspWiki 1.8.0 install on Windows 2000, Tomcat 3.3.1, no version control, IE 5.5.

When I try to go to the home page, I get:

java.lang.NoSuchMethodError
	at com.ecyrd.jspwiki.TranslatorReader.cleanLink(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.setHyperLinks(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.fillBuffer(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.read(Unknown Source)...

I installed by extracting the files to a directory in my webapps directory, then editted the properties file to point to my repository directory.

Any suggestions?

MahlenMorris: Hmmph. I'm puzzled now. For one, cleanLink() doesn't have any calls to the WikiEngine in it. Secondly, it hasn't changed that i can tell y casual inspection from 1.6.0. It's vaguely possible this is a JVM version issue, although all the methods called appear to be present in Java 1.2.2. What versions of the JVM are you using? Janne, any ideas?

PaulThomas: I am using JDK 1.3.1. BTW: I don't mean to insult anyone, but I believe that this is a relatively new distribution file (posted yesterday). Is it possible that it has something to do with the distribution?

MahlenMorris: I was wondering this as well, but that's Janne's department. I've installed 1.7.10 successfully here at my work. Try that and see if it works better.

JanneJalkanen: Yeah, I think I screwed up. Sorry. MidsummerFestival. And huge thanks to MahlenMorris for copying my hastily scribbled note to the correct places. Thanks, it was well caught! (I did not dare to do it myself, since EudoraWeb on Palm destroys the page you're editing, so in effect you can only create new pages. I need a better browser - suggestions? :-)

ldodds: JSPWiki 1.8.1 fixed this problem for me. Everything seems to be working fine now.

PaulThomas: me, too. thanks for the quick fix. you guys are great.


June 21, 2002 -- ldodds#

JSPWiki 1.8.0, Solaris/Red Hat Linux, Tomcat 4.0.1, FileSystemProvider, Netscape 6

I'm currently upgrading from 1.6.0, and decided to do a 'parallel' install to try out the new features before replacing my current installation. I manually installed JSPWiki in a separate web application (i.e. unzipped the WAR file, etc), but get a ServletException when accessing the home page. The root cause is the following:

java.lang.NoSuchMethodError
	at com.ecyrd.jspwiki.TranslatorReader.cleanLink(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.setHyperLinks(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.fillBuffer(Unknown Source)
	at com.ecyrd.jspwiki.TranslatorReader.read(Unknown Source)
	at com.ecyrd.jspwiki.FileUtil.copyContents(Unknown Source)
	at com.ecyrd.jspwiki.FileUtil.readContents(Unknown Source)
	at com.ecyrd.jspwiki.WikiEngine.textToHTML(Unknown Source)
	at com.ecyrd.jspwiki.WikiEngine.textToHTML(Unknown Source)
	at org.apache.jsp.Wiki$jsp._jspService(Wiki$jsp.java:304)
        ...

Under a separate Tomcat install I just dropped the WAR file into the webapps directory and restarted Tomcat so it would deploy the application itself. Again, I got the same error.

Am I doing something wrong?

MahlenMorris: I recently encountered a similar problem. The exception likely indicates that a new JSP is trying to call methods in the JSPWiki code that didn't exist in 1.6.0, or that an old JSP is trying to call methods that don't exist now.

The activities i would suggest trying are:

  1. Making sure that no older copies of jspwiki.jar are anywhere on you machine.
  2. Wiping out the compiled versions of the JSP's that Tomcat has created. They likely live in tomcat/work/DEFAULT/Wiki, or something similar.

JanneJalkanen: Please try 1.8.1. It's possible that this version solves that problem - I've often had problems running 1.4 compiled code on JRE 1.3.

ldodds: Thanks Janne, this fixed the problem for me.


May 28, 2002 -- NiiloNeuvo#

When creating a new wiki and not creating the directory for the content you get an ugly null pointer exception. Shouldn't this give a sensible error message?

Yes. Will fix, thanks! --JanneJalkanen

30-May-2002: Hm. I suppose you mean that it's a ServletException? Otherwise, I can't duplicate this bug... Anyway, the whole initialization system needs an overhaul anyway; currently all we can do is to output notes in the log. --JanneJalkanen

May 31st, 2002 -- NiiloNeuvo

I have set the data directory to be C:\nDemo\data. I only created a directory C:\nDemo. The wiki seems to work normally complaining that the main page does not exist. So I edit the page and when I try to save it:

java.lang.NullPointerException
	at com.ecyrd.jspwiki.WikiEngine.saveText(WikiEngine.java:847)
	at org.apache.jsp.Edit$jsp._jspService(Edit$jsp.java:178)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
	...

Hah, this kpnqwest line still works.

Of course it works, stupid of me. www.ecyrd.com is in the same room as I am right now ;-)

Fixed in 1.7.10 --JanneJalkanen

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
jpg
svn_process.jpg 155.0 kB 1 01-Oct-2009 12:51 202.147.44.83
« This page (revision-7) was last changed on 10-Jun-2012 10:43 by Janne Jalkanen