Use EATJ. It has much better JSP support.
This is a discussion page regarding hosting JSPWiki on GoDaddy.
Other JSP hosting solutions may be found on JSPWikiFriendlyWebHosting.
I am having a fair bit of problems getting JSPWiki working on GoDaddy. Some things that I have picked up along the way:
- GoDaddy does not allow its shared tomcat user to write to any path other than /tmp. This obviously rules out the standard providers and forces you to use the MySQL providers. I also think that this is going to cause problems with the user.xml file. This isn't too much of a problem for me because the user list for my wiki is going to be pretty static.
- The above limitation also applies to the writing the log4j log file. I am not aware if you can view the logs in /tmp (at the moment I can't write to them) so I have also moved my logs to MySQL as well.
In short I am having truckloads of problems getting it working on GoDaddy, has anyone successfully done it?
The initialisation process is a bit of a hassle as well because it only initialises once on startup, given that the ~Godaddy host only restarts the tomcat instance once per day that means that I have been working on this for weeks. Add to this is that the jars are signed which means I can't change the initialisation without breaking the security stuff. In short I have hit a brick wall in getting JSPWiki to work on GoDaddy.
The problem I am having with now relates to the temporary directory that JSPWiki attempts to write to on startup. I am getting an exception as follows:
Unable to find or create the working directory: /web/tomcat/temp/JSPWiki-12136508
java.security.AccessControlException: access denied (java.io.FilePermission /web/tomcat/temp/JSPWiki-12136508 read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:700) at java.io.File.mkdirs(File.java:1145) at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:482) at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:429) at com.ecyrd.jspwiki.WikiEngine.getInstance(WikiEngine.java:328) at com.ecyrd.jspwiki.ui.WikiServletFilter.init(WikiServletFilter.java:74) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:225) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:308) at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:79) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3698) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4349) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3043) at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4651) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608) at java.lang.Thread.run(Thread.java:595)Any suggestions much appreciated.
--Michael Ransley, 21-Jul-2006
Try setting the jspwiki.workDir property to point to a file in /tmp/. For example:
Unfortunately, if /tmp/ is cleaned often, you will lose some of the advantages (as e.g. the Lucene files will be located there, so deleting the directory will cause a rescan at start.)
Hi Micheal How you moved your logs to SQL - I am having extreme problems in configuring log4 J on shared linux hosting of GoDaddy.
so I have also moved my logs to MySQL as well. In short I am having truckloads of problems getting it working on GoDaddy, has anyone successfully done it?
I've had lots of problems doing *anything* Java-related with ~Godaddy. Most of the problems stem from the fact that they have tight Java security policy settings but their support people don't understand how it works. Anything that involves writing to the filesystem (even /tmp) or opening network sockets is a huge hassle. As mentioned earlier, the fact that they'll only restart the container once a day means that it can take weeks to get a simple issue resolved. Can't recommend.
GoDaddy uses Tomcat 5.0.27 running on JDK 1.5. This unfortunately means no JAX-WS deployment (such as producing a web service in Netbeans).
Service is sometimes sluggish, especially at first as if it's loading Tomcat from scratch or something. Many pages are simply *BLANK* with no explanation.
You can pay $6.95 a month for the cheapest JSP/servlet support around, period. To get around the once-per-day war file deployment problem, best you can do is develop and test locally, and deploy for the next day for it to get picked up.
It throws a security excepcion, don't you know?
JSPWiki 2.6.1 - GoDaddy Patch v.0.1
- Some hacks to get JSPWiki working on goDaddy.
- JAAS not working, it must be replace.
- Some others configurations.
JSPWiki 2.6.1 - GoDaddy Patch v.0.2
- Authetication works, JAAS was replace to Database authetication, -80% progress
web.xml does not work in godaddy, neither do spring framework. Weekly server failure due to out of memory is a norm there.
My web page is working for about 8 months in godaddy, web.xml is working and doesn't have out of memmory exception using jspwiki 2.6.1 patched.