Forum OpenACS Development: Re: Getting xotcl to worh on RedHat Server Enterprise 6.1 (32bit)

I think the latter of which you mentioned could be the issue-
I started up the server and looked through the error log as you suggested and found this:

[27/Jul/2011:15:19:21][19913.3079108288][-main-] Error: Error sourcing /var/lib/aolserver/nccedudotlrn/packages/xowiki/tcl/xowiki-procs.tcl:
invalid command name "attribute::exists_p"
while executing
"attribute::exists_p $object_type $attribute_name"
(procedure "create_attributes" line 25)
::xowiki::Page ::Generic::CrClass->create_attributes
invoked from within
"my create_attributes"
("uplevel" body line 2)
invoked from within
"uplevel 1 $transaction_code "
(procedure "db_transaction" line 1)
invoked from within
"db_transaction {
my create_attributes
}"
(procedure "init" line 39)
::xowiki::Page ::Generic::CrClass->init
::Generic::CrClass ::xotcl::Class->create
invoked from within
"::Generic::CrClass create Page -superclass ::Generic::CrItem -pretty_name "XoWiki Page" -pretty_plural "XoWiki Pages" -table_name "xowiki_page" -id_..."
(in namespace eval "::xowiki" script line 5)
invoked from within
"namespace eval ::xowiki {
#
# create classes for different kind of pages
#
::Generic::CrClass create Page -superclass ::Generic::CrItem \
..."
(file "/var/lib/aolserver/nccedudotlrn/packages/xowiki/tcl/xowiki-procs.tcl" line 9)
invoked from within
"source $__file "

I have checked that directory and that file does not exist. What does that suggest? From what I can tell it was installed correctly.

Thanks for the reply.

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:
https://openacs.org/forums/message-view?message_id=1771379
https://openacs.org/forums/message-view?message_id=3636214

-gustaf neumann

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.