Forum OpenACS Development: Re: Error sourcing xowiki-procs.tcl: invalid command name "attribute::exists_p"

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.

I assume, you are using the head version of openacs, which is using the package_dependencies for computing the loading order. My guess is that you might have a package installed, that requires xowiki, causing an early load of xowiki. i don't see another reason how xowiki could be loaded before acs-subsite.

Although acs-subsite is part of acs-core, it seems that an an explicit dependency is needed to force the loading order. i have updated the dependencies in CVS head; please check, if this solves your problem.

if you run the following snipped in the developer shell, you see the loading order...

Hope this helps! -gustaf

set packages [apm_enabled_packages]
set packages_to_load [list]
set _ ""
foreach package_key $packages {
  ds_comment "$package_key - [apm_package_load_libraries_order $package_key]"
  foreach package_to_load [apm_package_load_libraries_order $package_key] {
     if { [lsearch -exact $packages_to_load $package_to_load] == -1 } {
       lappend packages_to_load $package_to_load
     }
  }
}
append _ [join $packages_to_load \n]
I am not using the head version and I'm not allowed to upgrade this instance of OpenACS at the moment. I'm very happy to hear that explicit dependency-based load ordering is implemented in later versions OpenACS. Thanks for the info.