New Installation

[Migrated From Jforum.net]

I got the following stack trace from an error during installation using the wizard. It looks like a permission problem, but I thought I had the folders set up.

I unpacked and ftp'd the whole jforum folder up to my hosting site into a folder I named /forum.
In the /forum folder, I checked the following folders with write permissions (drwxr-xr-x):
/forum/upload
/forum/tmp
/forum/images
/forum/WEB-INF/config
/forum/WEB-INF/jforumLuceneIndex

Also, I set up a mySql database.

The wizard started just fine, but when I submitted the first page on the wizard, I got the stack trace below.
Thanks in advance for any ideas!
Stu

STACK TRACE
<!-- BEGIN ERROR STACK TRACE <br /> net.jforum.exceptions.ForumException: java.lang.reflect.InvocationTargetException <br /> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) <br /> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) <br /> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) <br /> at java.lang.reflect.Method.invoke(Method.java:585) <br /> at net.jforum.Command.process(Command.java:114) <br /> at net.jforum.view.install.InstallAction.process(InstallAction.java:915) <br /> at net.jforum.InstallServlet.service(InstallServlet.java:141) <br /> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) <br /> at sun.reflect.GeneratedMethodAccessor141.invoke(Unknown Source) <br /> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) <br /> at java.lang.reflect.Method.invoke(Method.java:585) <br /> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:239) <br /> at java.security.AccessController.doPrivileged(Native Method) <br /> at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) <br /> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:266) <br /> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:157) <br /> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) <br /> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:50) <br /> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:140) <br /> at java.security.AccessController.doPrivileged(Native Method) <br /> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:136) <br /> at net.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59) <br /> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) <br /> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) <br /> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) <br /> at java.lang.reflect.Method.invoke(Method.java:585) <br /> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:239) <br /> at java.security.AccessController.doPrivileged(Native Method) <br /> at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) <br /> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:266) <br /> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:213) <br /> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:183) <br /> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:50) <br /> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:140) <br /> at java.security.AccessController.doPrivileged(Native Method) <br /> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:136) <br /> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) <br /> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) <br /> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) <br /> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) <br /> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) <br /> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) <br /> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) <br /> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) <br /> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:417) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) <br /> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) <br /> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) <br /> at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) <br /> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) <br /> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) <br /> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) <br /> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) <br /> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) <br /> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) <br /> at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) <br /> at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) <br /> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) <br /> at java.lang.Thread.run(Thread.java:595) <br /> Caused by: java.lang.reflect.InvocationTargetException <br /> ... 64 more <br /> Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /var/chroot/home/content/a/g/s/agsllc/html/forum/WEB-INF/config/modulesMapping.properties write) <br /> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) <br /> at java.security.AccessController.checkPermission(AccessController.java:427) <br /> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) <br /> at java.lang.SecurityManager.checkWrite(SecurityManager.java:962) <br /> at java.io.File.canWrite(File.java:680) <br /> at net.jforum.view.install.InstallAction.canWriteToWebInf(InstallAction.java:526) <br /> at net.jforum.view.install.InstallAction.checkInformation(InstallAction.java:772) <br /> [originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

 Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /var/chroot/home/content/a/g/s/agsllc/html/forum/WEB-INF/config/modulesMapping.properties write) 

Add write permissions to the config dir .. (or the individual properties files)

[originally posted on jforum.net by GatorBait3]

[Migrated From Jforum.net]

The directory, WEB-INF/config has permissions -rw-r--r--
The file modulesMapping.properties has permissions -rw-r--r--

The user permissions are the ones that matter, yes?

Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

I have discussed the matter with my hosting tech support.
The installation servlets should be running with user permissions. I have double checked the permissions and they are all set.

I guess I will give the manual installation a try.

Thanks
Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

To be honest, the recommendation should be to try manual installation if possible. This still works like a charm in most cases.

In the prior version there was for instance issues with the missing file which gave weird error messages in the end .. ^^
[originally posted on jforum.net by Sid]

[Migrated From Jforum.net]

sturodgers wrote:I have discussed the matter with my hosting tech support.
The installation servlets should be running with user permissions. I have double checked the permissions and they are all set.

I guess I will give the manual installation a try.

Thanks
Stu

This is not usually the case! The servlets are usually running as the app engine user, not the user using the app.



[originally posted on jforum.net by GatorBait3]

[Migrated From Jforum.net]

I completed the manual installation of jForum. Below is the stack trace that occurs when trying to start the forum.
All of the files and folders have user write permissions.
I am stumped....but I haven't given up!
Thanks
Stu


description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Servlet.init() for servlet jforum threw exception
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:417)
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300)
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374)
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
java.lang.Thread.run(Thread.java:595)


root cause

net.jforum.exceptions.ForumStartupException: Error while starting JForum
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
java.security.AccessController.checkPermission(AccessController.java:427)
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
java.lang.SecurityManager.checkWrite(SecurityManager.java:962)
java.io.File.createNewFile(File.java:849)
org.apache.lucene.store.SimpleFSLock.obtain(SimpleFSLockFactory.java:122)
org.apache.lucene.store.Lock.obtain(Lock.java:61)
org.apache.lucene.index.IndexWriter.init(IndexWriter.java:598)
org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:410)
net.jforum.search.LuceneSettings.createIndexDirectory(LuceneSettings.java:90)
net.jforum.search.LuceneSettings.useFSDirectory(LuceneSettings.java:81)
net.jforum.search.LuceneManager.init(LuceneManager.java:77)
net.jforum.search.SearchFacade.init(SearchFacade.java:84)
net.jforum.ConfigLoader.startSearchIndexer(ConfigLoader.java:265)
net.jforum.JForumBaseServlet.startApplication(JForumBaseServlet.java:92)
net.jforum.JForum.init(JForum.java:92)


[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

Since the user permissions appear to be correct, maybe jForum is looking in the wrong location for files or directories?

The only configuration I can think of is the forum.link in SystemGlobal.properties. Is there another setting that I need to make to ensure jForum knows where to find all the needed folders?

Thanks
Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

sturodgers wrote:Since the user permissions appear to be correct, maybe jForum is looking in the wrong location for files or directories?

The only configuration I can think of is the forum.link in SystemGlobal.properties. Is there another setting that I need to make to ensure jForum knows where to find all the needed folders?

Thanks
Stu

What user are you giving write permissions to, your hosted account user? What app server is being used (i.e. Tomcat)?

The user that the app server runs under (i.e. tomcat or apache) is the one that would need permissions on your folders. Often times, hosting companies that say they support Java apps really don't in reality (but applets will work fine).

From the path you have listed, it appears you have a "shared" jvm instance for your java apps .. and that usually is part of the problem. The app server user doesn't have permissions into your hosted directory area, so you can get permission errors like you are seeing. Since you have a "shared" java instance, the app server is NOT running as your hosted user account (otherwise the other people sharing the java app server instance wouldn't work either). And, I'd be willing to bet that you do not have permissions to stop and start the app server either.

Your hosting service isn't GoDaddy by any chance is it? I tried unsuccessfully to get an instance of JForum running on GoDaddy and could never get it to work properly .. and even their tech support admitted to not fully supporting Java apps in their non-dedicated server hosting plans.

And this type of problem is not JForum specific ...
[originally posted on jforum.net by GatorBait3]

[Migrated From Jforum.net]

Yes, I am hosted at GoDaddy with a shared hosting account.

I have chatted with the tech support bubbas and they are "working on it" for me. Hopefully, they can set it up to run correctly.
If not, I will probably get a dedicated server account.
I will be running other java servlets and applications, so I can't have partial support for java.

Thanks
Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

sturodgers wrote:Yes, I am hosted at GoDaddy with a shared hosting account.

I have chatted with the tech support bubbas and they are "working on it" for me. Hopefully, they can set it up to run correctly.
If not, I will probably get a dedicated server account.
I will be running other java servlets and applications, so I can't have partial support for java.

Thanks
Stu

I doubt they will be able to help get it going for you, but good luck.

I would just save the time and headaches and just start looking for a real Java hosting environment - a standard GoDaddy hosting account is NOT the way to go for any Java applications.
[originally posted on jforum.net by GatorBait3]

[Migrated From Jforum.net]

Thank you for the advice.

I will post what results from my discussions with GoDaddy's tech support.
-Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

Please do!

As I mentioned, I tried to get an instance of JForum running on a standard GoDaddy Linux hosting account for about a week ... and was unsuccessful! The tech support folks finally admitted they didn't think it was possible.

And remember, the Tomcat restarts are only done in the evenings / early mornings, and you cannot get GoDaddy to restart it for you (and of course, you cannot restart it yourself either). So any new "updates" get to wait until the scheduled Tomcat restart.


[originally posted on jforum.net by GatorBait3]

[Migrated From Jforum.net]

Results from GoDaddy's customer support.
They say that the jForum application is trying to modify a file that I don't have access to on a shared hosting account.
I asked which file or directory it was, but he said he couldn't tell.
I also asked for the Tomcat log which might have additional information to help me figure it out. He said that it was not possible to send me the log.

So, I am left with a few unfortunate options.
1. I can either dig through all the the jForum source code, figure out which classes need to write to areas that can't be written to in a shared hosting account, and redesign them to work in my environment. OR
2. My hosting account costs about $6 a month at GoDaddy. I can shell out the additional $40 every month for a virtual dedicated server which will give me my own private instances of Apache and Tomcat that I will fully control. Then I should be able to install jForum.
3. I can go to www.simplemachines.org, download their php & mySQL powered forum (SimpleMachinesForum) and install it on my current hosting account.

Ultimately, I decided to go with option 3. The SimpleMachinesForum was easy to install and uses php and style sheets that can be fully customized to integrate into my existing site.
I would have preferred to use a java based solution, since I prefer java as a development environment.
But $40 is $40.
I am not especially happy with GoDaddy's answer, but it is only costing me $6 and sometimes you get what you pay for.

Thanks,
-Stu
[originally posted on jforum.net by sturodgers]

[Migrated From Jforum.net]

That pretty much mirrors my experience with GoDaddy and Java hosting.

phpBB3 is a pretty nice forum app too - that's what I ended up installing on GoDaddy. But like you, I prefer a java based solution.

[originally posted on jforum.net by GatorBait3]