Home
The Toolkit for Online Communities
16685 Community Members, 1 member online, 2244 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Getting xotcl to worh on RedHat Server Enterprise 6.1 (32bit)

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

Icon of envelope Request notifications

I have the web server up and running - can browse to it locally and content is displayed correctly where xotcl is NOT being used so I assume there is something wrong with the installation of it, but I know that it may be another component causing the issue so I will list all the relevant software. This is running AOLserver40r10.

Here are some details:
-TCL version 8.4.13 installed (appears to be working correctly)
-XOTCL version 1.5.3 initially installed then upgraded to 1.6.6 to see if this would resolve the issue - no joy.
-Libthread version 2.6.5 installed
-nscache installed
-nspostgres version 4.0 installed
-nssha1-0.1 installed
-tDOM 0.8.0 installed
-tcllib 1.10 installed

As far as I can tell all components installed without error and those which were erroneous were resolved.

This is the error which is displayed on the webpage:

invalid command name "::xowiki::Object"
while executing
"::xowiki::Object fetch_object -object ::$folder_id -item_id $item_id"
(procedure "require_folder_object" line 26)
::3551196 ::xowiki::Package->require_folder_object
invoked from within
"my require_folder_object"
(procedure "init" line 5)
::3551196 ::xowiki::Package->init
::xowiki::Package ::xotcl::Class->create
invoked from within
"my create ::$package_id -url $url"
(procedure "require" line 8)
::xowiki::Package ::xo::PackageMgr->require
invoked from within
"my require -url $url $package_id"
(procedure "initialize" line 21)
::xowiki::Package ::xo::PackageMgr->initialize
invoked from within
"::xowiki::Package initialize -ad_doc {

This is the resolver for this package. It turns a request into
an object and executes the object with the ..."
(file "/var/lib/aolserver/nccedudotlrn/packages/xowiki/www/index.vuh" line 2)
invoked from within
"source [ad_conn file]"
(procedure "rp_handle_tcl_request" line 3)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$path""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/$path"
set tcl_url2file([ad_conn url]) [ad_conn file]
set tcl_url2path_info..."

If any other error logs are required please ask.

Any help would be greatly appreciated. Thanks in advance.

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

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

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,

This error has nothing to do with the OS environment. I meant, RedHat is not the cause of the error.

The error is directly related to the content-repository-content-files

The registers associated with xowiki on you database (to be precise on table cr_items) don't match with the tree structure of content-repository-content-files/

The solution is to copy this directory from the same place you got the database dump.

Let us know if your problem is solved.

I copied the directory from the location of the database dump and it didn't fix it. Could it be due to how old the versions like mentioned below?
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.

But the best and right thing to do is to get the latest version.