%%information
JSPWiki bug reporting system has changed.

Please, __use the [bugs.jspwiki.org|http://bugs.jspwiki.org] to submit bug reports from now on__.  IF YOU REPORT A BUG HERE, IT WILL BE IGNORED UNTIL THE END OF TIME.
%%

And I would really, really appreciate it that if you happen to walk by on this page, you would copy a single bug report from this page to the new bug handling system.   And also, remove the bug from this page as well so that we know which already exist.

-- JanneJalkanen

----

[{TableOfContents }]

----

__back slashes in http string in a file causes file not to load__

|Date            | 2004-01-27
|JSPWiki version | JSPWiki v2.1.86-alpha
|Java version    | 1.4.1
|Operating system| NT
|Web server and servlet container | Tomcat 5.0.18
|Page provider   | FileSystemProvider
|Browser         | Mozilla 

----
!2003/9/25 - page in weird state on attachment abort

|Date            | 2003/9/25        
|JSPWiki version | JSPWiki v2.0.52-cvs 
|Java version    | 1.4.1
|Operating system| w2k
|Web server and servlet container | resin
|Page provider   | FileSystem
|Browser         | IE 5.0

From a user: I had various tid bids stowed away over there - but it somehow vanished. I was in the middle of attaching a file - I tried aborting that - went back to check my page - ony to find all the contents in the page werel blown away. I was left with a blank page :-( 

The funny thing is that when I go to edit the tl1FirstPage it still shows my original text, but when I display my tl1page it has none of my text.

Analysis: The page was indeed in the file system but did not display in view mode, but did in edit mode, even after restarting the system. I renamed the file to a different name and it worked fine.

----
!2003/08/24 - Escaping Brackets 

|Date            | 2003/08/24
|JSPWiki version | 2.0.56
|Java version    | 1.4.1
|Operating system| Win98
|Web server and servlet container | Tomcat 4.1
|Page provider   | FileSystem
|Browser         | IE 5.0

I'm trying to insert a javascript inside the LeftMenu.
{{{<select onchange="document.location=options[selectedIndex].value;">}}}

To have my selectedIndex with brackets around I tried:
{{{options[[]selectedIndex]}}}

But it's always translated as:
{{{options[]selectedIndex]}}} 

Seems a bug to me although it's said to be a FixedBug since 1.9.23
--FrancoisParlant

----
!2003/07/22 - Still no ability to go forward with the [patched Calendar Tag|CalendarTagPrevNextPatch].

|Date            | 2003/07/22
|JSPWiki version | 2.1.53
|Java version    | 1.4.1
|Operating system| Win2k 
|Web server and servlet container | Tomcat 4.1
|Page provider   | FileSystem
|Browser         | IE 6.0

I compiled the latest CVS release which is supposed to have the patched Calendar tag.  I'm still unable to see future months.  There is no useage documentation, so I assume it is automatically there...therefore making this a bug. :-p
\\

Please reach me at: [AArbit@go-integral.com|mailto:AArbit@go-integral.com]
\\
Thank you.

Well, it is a design error, not a bug as such.  But I will add the ability to go forward in the next release. --JanneJalkanen

----
!2003/07/07 - RecentChangesPlugin does not get resolved.

|Date            | 2003/07/07

|JSPWiki version | 2.0.45 / 2.0.39
|Java version    | 1.4.1
|Operating system| Win2000 
|Web server and servlet container | Tomcat 4.1.18
|Page provider   | FileSystem
|Browser(s)      | Mozilla 1.4 / IE 6.0


I have installed JSPWiki (unzip war file into webapps sub dir), made minor mods
to jspwiki to point to page directory.  When I display LeftMenuFooter, 
the plugin is not found.  he prevents me from being able to save pages.  
I get "An unknown exception java.lang.~NullPointerException was caught by 
Error.jsp".  See attached file: wikiError07072003.zip.  It contains the log file chunk for the 2.0.39 version and the properties file.


I can be reached at: jpettens@rochester.rr.com
- J.Pettenski



An update.  It looks like this error causes the other above.

2003-07-07 12:46:25,936 [Thread-10] INFO com.ecyrd.jspwiki.WikiEngine  - Starting cross reference scan of WikiPages
2003-07-07 12:46:26,061 [Thread-10] FATAL com.ecyrd.jspwiki.WikiEngine  - PageProvider is unable to list pages: 
com.ecyrd.jspwiki.providers.ProviderException: Specified attachment directory C:\Data\jspwiki\testWiki\attachments does not exist!

Yes.  You need to create the "C:\Data\jspwiki\testWiki\attachments" directory first.

-- JanneJalkanen

----

!2003/05/15 - No author shown - only ip adress

|Date            | 2003/05/12
|JSPWiki version | 2.0.39 
|Java version    | 1.4.1_2
|Operating system| W2K
|Web server and servlet container | Tomcat
|Page provider   | RCSFileProvider
|Browser(s)      | n/a

Hi,
I thought that if I set the userpreferences cookie to my client that I could find the author who changed a page. But it is not so! Does somebody know why?
I read that I must use versioning but this works only if I have attached a file to the site.
--[RimElrey]
;:''Setting your name in the UserPreferences page doesn't change the information available in other pages.  However, after you set your name, then any page you edit (or any attachment you upload) will have your name (as stored in the cookie) as the author, which is a Good Thing.  I think it is such a Good Thing, that I made the template I contributed (see the [ContributedTemplates] page) require you to set a name in UserPreferences before you can change pages.  (Of course, you can still enter rubbish for the name, but a Wiki is largely about the honor system.)  --MichaelGentry''
Yes, I hoped that it is so! But with my installation it is not!
I set a username first and changed then a page, but the user is "unknown".
Only if upload an attachment that I could see a username.
Why?
--[RimElrey]
;:''I use the same configuration as you (Tomcat version 4.1.12/.18), except I __DO NOT__ use the RCSFileProvider.  I use the VersioningFileProvider and it works fine for me.  Unless you have a specific reason for using the RCSFileProvider, I suggest switching to the VersioningFileProvider.  --MichaelGentry''
Yes, that's it!\\
--[RimElrey]

;:''This is such an FAQ, that since version 2.1.21 FileSystemProvider also saves author information.  Move to JSPWikiFAQ.''

----
!2003/05/12 - Can't link to javascript

|Date            | 2003/05/12
|JSPWiki version | 2.0.39 
|Java version    | n/a
|Operating system| n/a
|Web server and servlet container | n/a
|Page provider   | n/a
|Browser(s)      | n/a

linking to a [javascript function | javascript:alert('yo dude!')] doesn't work.


- YishayMor

NotABug.  We don't allow javascript on this site for security reasons. --JanneJalkanen

----
!2003/05/08 - Error translating embedded HTML

|Date            | 5/08/2003
|JSPWiki version | 2.0.39 
|Java version    | 1.4.1_01
|Operating system| Win2000
|Web server and servlet container | Tomcat 4.1.18
|Page provider   | ~FileSystemProvider
|Browser(s)      | IE 6.0

If {{jspwiki.translatorReader.allowHTML = true}}, if the following code is embedded in a page:
{{{
    <a name="Wikiname">Wikiname</a>

    <a name="WikiName">WikiName</a>

    <a name="Nonwikiname">
    Nonwikiname, split line</a>

    <a name="WikiName">
    WikiName, split line</a>
}}}
It will be rendered as . . .

;:Wikiname

;:~WikiName

;:Nonwikiname, split line

;:WikiName"> WikiName, split line

-- PaulDownes

This isn't at all surprising - if you have CamelCase detection enabled at the same time, one of these is going to break =).  It gets very complicated if you try to determine where in HTML you can or you cannot do CamelCase translation.  NotABug, but should probably be mentioned in JSPWikiFAQ.

--JanneJalkanen

----

!2003/05/08 - A convenience bug : Upload servlet should a JSP

|Date            | 5/08/2003

|JSPWiki version | All
|Java version    | 1.4.1
|Operating system| All
|Web server and servlet container | Tomcat
|Page provider   | ~FileSystemProvider
|Browser(s)      | All


This is more of an annoyance than a bug. The current implementation of upload uses a servlet.
My ISP runs a kind of shared Tomcat where I cannot (not allowed to) register servlet aliases.
I hacked the code base to use the fully qualified name for the upload servlet instead of the alias.
Would not it make sense to use a JSP instaed of a servlet to be true to JSPWiki being a JSP implementation?
That would make the overall homogeneity of the code better(no more servlets), and solve my problem

[PhilippeO]

01/10/2004 - I am running into the same problem with my hosting company.  I cannot register "/attach" but I can register "/servlet/attach".  So it looks like I need to hack the sources and rebuild to make attachments work.  If the upload was a JSP it would not be a problem.  Thanks! [Bryce Denney] 

----

!2003/03/28 - Attachment System does not like any non-JSPWiki files in dir tree 

|Date            | 3/28/2003
|JSPWiki version | 2.0.36 
|Java version    | Sun 1.4.1

|Operating system| Win98
|Web server and servlet container | Tomcat 4.1.18
|Page provider   | ~BasicAttachmentProvider
|Browser(s)      | Not Related

(Sorry if this should not go here, since its not really a bug - PLS move it elsewhere if you think)
When there are any subdirectories within the attachment tree (dirs that were ''NOT'' created by JSPWiki), it leads to many ~NullPointerExceptions. This is a pity, because it prevents to store the wiki content in some CVS repository (this will leave CVS subdirectories all over the place). \\

Ignoring any CVS directories could be one (simple) solution... -- [Bob|BobSchulze]\\
''Ok, I did help myself and added a pluggable [alternative|SimpleAttachmentProvider] AttachmentProvider -[Bob|BobSchulze]''
----
MarcAndreDumont

* Date: 03/09/03
* JSPWiki version: 2.0.32
* Hosted by an ISP on Linux/Apache/Tomcat 4.0.6
* The used page provider: VersioningFileProvider
* Used browsers: Opera7, IE6.0

Everything is working fine exept the attachements. I set the path to the real path (/home/taxony.net/htdocs/wiki/content/) as I did for the pageDir. When I try to uploade an image I get a message An 'unknown error was caught by Error.jsp' but no further log entry.

I also installed the JPSWiki CVS version since the uploads work here (I tested), but the same result. With a PHP-based forum software is it possible to upload attachements thus I doesn't seem to be a restriction of my ISP.

But what else?


JanneJalkanen: Do you have the jspwiki.attachmentProvider set?  If yes, then please do set the log4j.rootCategory to DEBUG, FileLog and see if there are any exceptions in the log defined in log4j.appender.FileLog.File.


MarcAndreDumont: The log says: UploadServlet initialized. Using /usr/local/jakarta/temp for temporary storage. Upload failure: Directory [/usr/local/jakarta/temp] is readonly.

As I run JSPWiki on a server of my ISP, I do not have access to that directory, so is it possible to do uploads without temporary storage?

2003-Mar-09 MarcAndreDumont: I could fix it by replacing "System.getProperty( "java.io.tmpdir" )" in line 74 of AttachementServlet.java with a fix path. I would suggest to add such parameter (e.g. jspwiki.fileSystemProvider.tempDir) in the jspwiki.properties.

No, this is not a good idea - it is not a good idea to mess with java system properties (can you say concurrency issues?).  You can always start Java with the command "-Djava.io.tmpdir=/my/tmp/dir".  


Besides, the temporary directory should ALWAYS be writeable.  Your provider is obviously doing something very wrong if this is not the case.

-- JanneJalkanen
I disagree with this last statement : I have the exact same problem with my ISP. I suggest that JSPWiki not rely on the server provided temp directory, but instead uses its own logic, including a property parameter to point to it, or a subdirectory of the pages storage directory.  The implementation of temp config can be so different from one install to the other, that I think it is bad form to assume anything about the target environment. I have made the hack (ie new property to use an arbitrary temp directory for uploads, and now it works, when it did not before).--PhilippeO

----
! matchEnglishPlurals & ReferringPagesPlugin

* ''configuration probably does not matter beyond: __matchEnglishPlurals==true__''

Create a page named ~ExamplePlural then edit this page to refer to it as ExamplePlurals, then goto ~ExamplePlural and notice that it says it's not referenced by anyone.  My assumption is that the ReferringPagesPlugin need to hook up with the logic of ''matchEnglishPlurals'' as appropriate.   --JohnVolkar  

;:''Known bug.  There are even tests for this in the current distribution.  Will be fixed.''

----


!2003-Mar-09: "FindPage" title hardcoded

* JSPWiki v2.0.32-beta


I currently translate the JSPWiki to german (yes, of course I'll publish that here when I'm through). If I'm right, the title of the page that displays the search results is hardcoded in the Search.jsp instead in the "presentation layer" (in a template or as a wiki page).

-- MarcAndreDumont

Oops.  You're right.  Same with UserPreferences...

-- JanneJalkanen

''Fixed in 2.1.56.  Move to [FixedBugs].''

!2003-Mar-04: Unconfirmed bugginess with XML-RPC and attachments

I'm running JSPWiki v2.0.22-cvs on [http://wiki.cocoondev.org/] for which I created a Python script that mails wiki diffs to a Cocoon mailing list ([http://marc.theaimsgroup.com/?l=xml-cocoon-docs&r=1&b=200303&w=2]). I had two error situations coming up on irregular occasions, and have now come to the suspection that XMLRPC and binary attachments aren't coming along very well. My script itself was breaking on trying to diff attachments (quite obvious), so I fixed that to make it scan for '%2F' in the page name and skip such a 'page'. It would be a Good Thing if I can differentiate between normal pages and attachments using some more formal than '%2F' appearing in the page name, so maybe the XMLRPC interface should be expanded adding an extra property.

;:''Yup.  The XML-RPC interface should not even be returning attachments in the lists, probably.'' --JanneJalkanen

;:''Since 2.0.35, we no longer list attachments.''

Anyway, working my way around the bugs in my own application, I suddenly started thinking that the other problem might have been caused by the combination of binary attachments and XMLRPC. For some reason or another, JSPWiki had periods of very high CPU load on my server (Linux, Sun JDK 1.4), for unapparent reasons (to me). Now, I start to believe that fetching the content of attachments across XMLRPC triggers some error condition in the XMLRPC stuff, and I'm wondering whether my assumption might be correct. I'll check whether not accessing attachments across XMLRPC does resolve the CPU load situation, and if that is the case, my assumption might be correct. Does anyone else has similar experiences with XMLRPC & attachments? -- [Steven Noels|http://wiki.cocoondev.org/Wiki.jsp?page=StevenNoels]

----

!2003-Feb-28: error with Tomcat 4.0 and error loading first page after install

* Java Version: Sun JDK 1.3.1_04
* JSPWiki v2.0.32-beta
* Windows 2000 Professional
* jakarta-tomcat-4.1.18
* The used page provider: {{ FileSystemProvider }}
* Used browsers: IE 6.026

Ok, I've now set up the 32beta on two machines.  I failed on the first machine which was running Tomcat 4.0 for Win, and all attempts to get past a completely blank page failed.  There were errors in the log, but when I changed the settings so that they would avoid an error, it would just create another.

So, I moved to the second machine running Tomcat 4.1.18 and it worked.  However, on the first load of the Main page (I call mine HomePage), I got the following message.
{{{
(class: org/apache/jsp/ViewTemplate_jsp, method: _jspx_meth_wiki_Breadcrumbs_0 signature: 

(Ljavax/servlet/jsp/PageContext;)Z) Incompatible object argument for function call 
}}}
After hitting __refresh__ in the browser, this message when away and all appears to be fine.


I went back to the first machine, with a copy of the wiki from the second machine and it still would not run.  I upgraded Tomcat to 4.1.18 and viola, it ran.   However, the first time I opened the HomePage got the breadcrumb error shown above.

In anycase, most is now as it should be, thanks.  Scott

!Here's the error as seen in the browser:
[BugReports/B32_Scott_Error.jpg]

;:''Um.  Strange.  I really don't have much idea about what is happening here. --JanneJalkanen''

----

!2003-Feb-24: error saving a page 

* Java Version: Sun JRE 1.4.1_01-b01
* JSPWiki v2.0.32-cvs
* Windows 2000 Professional
* jakarta-tomcat-4.1.18
* The used page provider: {{ DatabaseProvider }}
* Used browsers: IE 6.026


Additional information:\\
Using plugin for Tomcat and [Eclipse|http://www.eclipse.org] from\\
Sysdeo Eclipse Tomcat Launcher Plugin\\
(c) Sysdeo SA - 2002 - [http://www.sysdeo.com/eclipse/tomcatPlugin.html]

Submitted by ThierryLach\\
Note: this also occurs with FileSystemProvider and VersioningFileProvider,



The Sysdeo patch enhances the Tomcat classloader so that JSP pages and java code running in tomcat can be debugged using Eclipse.  This causes failures of JSPWiki compiling pages when the default template page is used, since the java code generated by the templates contains



{{{

package org.apache.jsp.templates.default;
}}}

instead of
{{{
package org.apache.jsp;
}}}
This causes the jsp page to fail to compile since default is a reserved word.

Though this is not a JSPWiki bug per se, I still suggest that the directory name for the default templates be changed to some non-reserved word (maybe dflt?) since it is possible that a non-Tomcat jsp engine may encounter the same situation.

{{{
#
#  This sets the default template used by the Wiki engine.  The templates
#  live in templates/<template name>.  JSPWiki will attempt to find two
#  basic templates from that directory: "ViewTemplate" and "EditTemplate".
#
#  By default this is called "dflt".
#
jspwiki.templateDir = dflt
}}}

--[ThierryLach]

No, 'default' is not a reserved word in package names (I checked the Java specification).  However, it seems that the Java compiler for Windows is broken in this respect - someone else has complained about this as well.  Hm.  Perhaps we should rename the default template - but I really hate working around compiler bugs in these kind of situations... :-(.

--[JanneJalkanen]

Btw, I'm also using 1.4.1_01-b01 and tomcat-4.1.18 only on WindowsXP, but never had this problem.
-- [Torsten|TorstenH]

I have this problem as well, running under tomcat-4.1.24 on XP with the Sysdeo
patch applied.

My read of the Java Language Spec (v2) is that 'default' ''is'' a reserved word in package names (6.5 defines ''Packagename'' as a sequence of ''Identifier''s, 3.8 defines ''Identifier'' as not a ''Keyword'', and 3.9 defines 'default' to be a ''Keyword''.)  Did I misinterpret?

See also: [http://www.javaworld.com/javaworld/javaqa/2001-12/02-qa-1221-package.html]

If this is deemed not a bug, perhaps the workaround (rename the default template) should be mentioned in the Windows install page?  This seems to have happened to several people, and for my part, it took a while for me to figure out what was going wrong.

--[FritzMueller]

----

!2003-Feb-24: error saving a page 


* Java Version: JDK 1.3.1_07
* JSPWiki v1.8.2 
* Windows XP
* jakarta-tomcat-4.1.18
* The used page provider: {{ FileSystemProvider }}
* Used browsers: IE 6.026

Submitted by AndrewArnold\\
Don't know whether the problem I've encountered is a bug or results from the fact I'm an inept non-techie trying to do a techie thing.  I tried downloading and installing jspwiki. It loads, but I get an error when I try to save a page after edits. 

If you could help me work this out, I'd really appreciate it. - Thx, andrew\\

The HTTP status 500 error that shows in the browser indicates a null pointer exception because the system thinks the Page directory doesn't exist. However, {{C:\\Data\\jspwiki}} does in fact exist on my file system. Below, I've pasted in the Browser error, log file message, and changes I made to {{jspwiki.properties}}.

Changes to the {{jspwiki.properties}} file:\\
{{{
jspwiki.fileSystemProvider.pageDir = C:\\Data\\jspwiki 
jspwiki.baseURL=http://localhost:8080/MyWiki/
log4j.appender.FileLog.File = C:\\jakarta-tomcat-4.1.18\\webapps\\MyWiki\\tmp\\jspwiki.log
}}}


Relevant section of the log file: 
{{{
2003-02-24 09:46:16,951 [Thread-9] INFO com.ecyrd.jspwiki.WikiEngine  - JSPWiki 1.8.2 starting. Whee!
...
2003-02-24 09:46:16,967 [Thread-9] INFO com.ecyrd.jspwiki.FileSystemProvider  - Wikipages are read from : C:\Data\jspwiki 
...
}}}

Hm.  Strange.  Please make sure that
# You can access the directory
# The directory name is correct (not "JsPWiki" or something)
# You don't have things like an extra space after the directory name in the property file.

-- JanneJalkanen



Just painting Andrew's text with my cursor let's me guess that number 3 is the problem.
Andrew, please edit your ''jspwiki.properties'' and kill that extra space at the end of the ''jspwiki.fileSystemProvider.pageDir'' line. I'm going to check the log message and make sure it has some quotes around it to make noticing this easier...

Done. I hope we're slowly running out of these. This will make life easier in 2.0.32+, but users of older versions will still need to check their spaces. 


--ebu


----

!!PageInfo slow with RCSFileProvider
''This site''.

For some strange reason RCSFileProvider insists on checking out every single version when doing a version history listing.  This causes pages like [Ideas] to have very slow history pages.  This is probably an oversight or a side effect of something being changed somewhere in WikiEngine, as the original version history listing should be quite sufficient for any information.

--JanneJalkanen

OK.  Found the problem: It's the ~PageSize tag, which checks out each version from RCS and then displays the result.  No wonder it's so bloody slow.

The obvious solution would be to amend RCSFileProvider to put the file size in file metadata, but how exactly could we then do graceful migration for old systems?  Or do we even care?

--JanneJalkanen, pondering out loud

Disabled page size for a while on PageInfo pages for pages, which really does speed things up a LOT.  Still wondering what we should do.

--JanneJalkanen


----
!!Problems with "default" template
2003-01-06\\
JSPWiki 2.0.7-beta\\
Java 1.4.1\\
Windows 2000\\
Tomcat 4.1.18\\

This could be considered a documentation/installation issue, but I could not get JSPWiki to work using the "default" template name.  I had to change it to another name (in the properties file and copy the default template on disk) in order to get the JSP to compile.  Here is the error output:

{{{2003-01-06 12:15:47,086 [Thread-4] FATAL com.ecyrd.jspwiki.tags.WikiTagBase FMWiki:Main - Including failed
org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
    [javac] Compiling 1 source file

$TOMCAT_HOME\work\Standalone\localhost\FMWiki\templates\default\ViewTemplate_jsp.java:1: 
<identifier> expected
package org.apache.jsp.templates.default;

                                 ^
1 error}}}

''This is really strange.  As far as I can tell, it seems to be a bug in the JDK for Windows, as it seems that it thinks that the "default" package is actually a keyword.

However, I cannot duplicate this on my Tomcat 4.1.18/JDK 1.4.1_01/Linux combination...  Could you perhaps try some other version of Tomcat and JDK and report the results?

--JanneJalkanen''

Well ... it would be a tad painful on the Windows box, but I could try it out on my OS X box at some point (which still has Java 1.3.1  on it -- until Apple takes 1.4.1 out of beta -- and Tomcat 4.something).  The easist thing to do might be to rename the "default" template, though (perhaps "standard"?) to avoid an issue with it.  I've been modifying the supplied templates, anyway, so it hasn't been much of an issue for me, but it definitely defeated the drag and drop installation of the WAR file.  If I get ambitious at some point, I'll upload the new templates as an example (it uses a more horizontal approach -- I wanted wide code listings and graphic diagrams to be easier to view -- and removes the left sidebar).

--MichaelGentry

Hmm... Did you just drop the WAR-file in place or did you extract it?



Anyway, new templates would be really cool.  Why don't we make a page called [ContributedTemplates] and let people attach stuff there?

--JanneJalkanen


I dropped the WAR into the Tomcat "webapps" directory.  Tomcat saw the new WAR and unpacked it.  I then went and edited the configuration and restarted Tomcat.  When I tried to access the main page, though, is when I'd have the "default" errors (as it tried to compile the JSP).

I'll try to add my templates there Real Soon Now.  I do have a few other changes I want to make locally first, plus there are some plugin changes I'd like to make, but I can't grab the CVS tree from work due to our firewall (port 2401 is not allowed out) -- that doesn't effect the templates for now, though.

--MichaelGentry

Please try an alternative approach: Unzip the WAR file yourself before you start Tomcat.  There must be some sort of a strange bug aloof here, and I'd rather understand the bug and fix it than treating the symptoms :-).


--JanneJalkanen

----

!!Websphere Adv 4.0 Install
Feb 11, 2003 -- den
Java 1.2, Servlet 2.2, Windows 2000 Server, IBM Websphere Adv 4.0


I have installed JSPWiki v2.0.27-cvs on IBM Websphere Adv 4.0 Server. Everything seems to be fine except the Page Contents is displayed on the top of each page before the <HTML> tag not withing the body like it is suppose to be. Does anyone know why this is happening? The include-directives are in the right place in the ~ViewTemplate.jsp file. This happens on both IE and Netscape browsers so the browser it not the problem. I receive no errors in the Web App logs.

----

!! Upload fails "An unknown error was caught by Error.jsp" with Tomcat 5.0.19


|Date            | 2004-03-23
|JSPWiki version | 2.0.52
|Browser         | any browser
|Java version    | 1.4.1_02-b06 
|Operating system| Win2K
|Web server and servlet container | Apache Tomcat 5.0.19 \\ versus \\ JWSDP1.3 (should be Tomcat 5.x))
|Page provider   | FileSystemProvider
|Attachment provider   | BasicAttachmentProvider



JWSDP 1.3 (Sun download, probably any Tomcat 5.x) was replaced with Tomcat 5.0.19. The wiki installation ist unchanged as all user files are in a directory of their own

When JWSDP 1.3 is active everything works fine. With Tomcat 5.0.19 the upload functionality fails like shown above "unknown error". The rest of the wiki however seems to work. At least haven't seen anything changed. 

Not shure if this is a jspwiki problem or a Windows Tomcat beta version issue?

-Michael

\\
ah! found something in log4j.log 
{{{
2004-03-23 21:28:58,134 [http8080-Processor23] WARN com.ecyrd.jspwiki.attachment.AttachmentServlet  
  - Upload failure: Directory [..\temp] is invalid. (attachment: (unknown))
java.io.IOException: Directory [..\temp] is invalid.

	at http.utils.multipartrequest.MultipartRequest.initParser(MultipartRequest.java:590)
}}}
 
a temp dir is missing. Which one?

-Michael

I let this Tomcat print out 
{{{
<%= System.getProperty ("java.io.tmpdir") %>
}}}

and it actually hat changed this property to "..\temp". But I don*t know where this relative path points to...  after this I created in catalina.policiy the explicit entry
{{{
permission java.util.PropertyPermission "java.io.tmpdir", "read";
}}}

but it still changes java.io.tmpdir to  "..\temp". 
grr...


-Michael