From the description above, it is not clear, whether xotcl (the tcl extension) is not working, or whether there is a problem with the loading of xotcl-core (the OpenACS package providing an oo infrastructure for OpenACS) or xowiki (wiki package based on xotcl-core). Problems with the tcl extension are very seldom.

Check the following two things:
a) What is the first error in the error.log file after the startup of the server (the error message above just says that ::xowiki::Object is not defined, there was most probably an error that prevents the definition of this class).
b) what is the output of http://YOURHOST/xotcl/version-numbers

There was also an earlier error which is perhaps relevant but I left it out because it wasn't xotcl related:

[27/Jul/2011:15:17:49][19913.3079108288][-main-] Error: pidfile: failed to open pid file '/usr/local/aolserver/log/nspid.nccedudotlrn': 'Permission denied'

This is probably due to access rights but I'm not even sure if it is responsible for the xotcl errors.

Thanks.

Joe, you seem to have an ancient version of xowiki installed, which tries to use the OpenACS function "attribute::exists_p", which does not seem to be available during startup.

I guessed the age of xowiki from the log-output (::Generic::CrClass, which was replaced in 2007), around this time, the usage of "attribute::exists_p" was eliminated in the class definition (the cvs browser from openacs seems to be down).

What version of xowiki, xotcl-core and OpenACS are you using? As mentioned above, the query ../xotcl/version-numbers returns the relevant version numbers, but maybe, your xotcl-core version is so old that it does not provide this query.

see the following two posts:
http://openacs.org/forums/message-view?message_id=1771379
http://openacs.org/forums/message-view?message_id=3636214

-gustaf neumann

Sad to read it didn't work.

Yes please, do it what Gustaff has said.
Attention to the second link, you can invert the order which APIs are loaded on boot.

I also tried here and it worked fine.

I have resolved this, thank you very much guys. I found the solution in one of your links; all I had to do was this:

11: Re: Error sourcing xowiki-procs.tcl: invalid command name "attribute::exists_p" (response to 1)
Posted by Andrew Helsley on 05/27/11 11:57 PM
I encountered the same error. It is caused by an inversion of the loading order of the acs-subsite and xowiki packages at startup. In order to define the ::xowiki::Object command xowiki requires uses attribute::exists_p proc. acs-subsite defines attribute::exists_p. Thus, if xowiki is loaded before acs-subsite, ::xowiki::Object will not be defined and this error occurs.

I don't have the ability to upgrade the server I'm working on, so I just modified packages/acs-tcl/tcl/apm-procs.tcl, changing:


ad_proc -public apm_load_packages {
...
# Load *-procs.tcl files
if { $load_libraries_p } {
apm_load_libraries -force_reload=$force_reload_p -packages $packages -procs
}
to:

ad_proc -public apm_load_packages {
...
# Load *-procs.tcl files
if { $load_libraries_p } {
apm_load_libraries -force_reload=$force_reload_p -packages acs-subsite -procs
apm_load_libraries -force_reload=$force_reload_p -packages $packages -procs
}
This modification forces acs-subsite to be loaded after all other core server initialization but before most other packages, including xowiki.


Once again, thank you.