Forum OpenACS Q&A: Re: Problem with newest xowiki

thanks Gustaf, now xowiki INSTALLS without a problem, sadly I'm getting an error when trying to access an instance of it. This is the error message the server tells me:

(it looks more like an xotcl error, I'm using version 0.51)

required arg: 'package_id' missing
::xotcl::nonposArgs ::xotcl::NonposArgs->required
invoked from within
"::xotcl::nonposArgs required package_id"
invoked from within
"::xotcl::interpretNonpositionalArgs $args"
(procedure "new" line 2)
::xo::db::content_item->new
invoked from within
"::xo::db::content_item new -name $name -parent_id $parent_id -creation_user $creation_user -item_subtype "content_item" -content_type $object_type -..."
("eval" body line 1)
invoked from within
"eval ::xo::db::content_item new [[self class] set content_item__new_args]"
invoked from within
"set item_id [eval ::xo::db::content_item new [[self class] set content_item__new_args]]"
("uplevel" body line 14)
invoked from within
"uplevel 1 $transaction_code "
(procedure "db_transaction" line 1)
invoked from within
"db_transaction {
$__class instvar storage_type object_type
$__class folder_type -folder_id $parent_id register
[self class] lock acs..."
(procedure "save_new" line 28)
invoked from within
"next"
(procedure "save_new" line 3)
::32066 ::Generic::CrCache::Item->save_new
invoked from within
"::$folder_id save_new"
(procedure "require_folder_object" line 34)
::32045 ::xowiki::Package->require_folder_object
invoked from within
"my require_folder_object"
(procedure "init" line 5)
::32045 ::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 "/home/cesar/miviaro/viaro_testing/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..."

do a "fgrep -- --OpenACS openacs-4/log/error.log".
be sure, you use the version of xotcl-core from head as well.

i see: the apm_version_names_compare 5.2.0d9 5.2 returns 1 (meaning older than 5.2), but you have already the 5.2 features like e.g. the package_id. Since versions before 5.2 did not have package-ids, xotcl-core does not pass the package-id to content_item__new, although the datamodel says, it is required.

is it a problem for you to upgrade that machine at least to 5.2? xotcl-core and xowiki have a few tests on the kernel version to behave differently in pre 5.2 versions. You can certainly grep for 5.2 in xotcl-core and xowiki to change this into 5.1.99 or whatever to address this problem.