Forum OpenACS Q&A: Speaking of package breakage...
Following just hours after my vicious, unfounded, and wholly inappropriate attacks on package breakage in OpenACS, Dave Bauer heroically announced a security fix for the acs-templating package. Hooray, Dave!
But, lo, what happens to my poor hapless server upon upgrading to this new and improved (and more secure) templating package? Oh, there was much gnashing of teeth. The bug-tracker has gone to meet her maker(s). Since one of those makers was Lars, who's now a heathen Rubyist, things don't look good for our damsel in distress.
In short, I thought I'd take this opportunity to learn a thing or two about OpenACS, the templating package, and maybe I could pierce the veil of obscurity that is the bug-tracker codebase as well.
So, after filing a bug ( http://openacs.org/bugtracker/openacs/bug?bug%5fnumber=2758 ), I've spent the past couple of hours trying to track down what has changed that could lead to this problem, and let me tell you...I'm feeling pretty lost. There's quite a lot of abstraction in the bug-tracker, and so it took me a good while to find my way down the traceback to where the offending call is maybe coming from (bug_list), and then many more layers had to be dug through to get to the template functions. And I'm seemingly no wiser than when I started. I simply don't see what's going wrong.
Torben gave me lots of good advice in previous threads, and one piece of advice was to ask questions when I'm confused. I'm confused, so I'm asking questions.
Just so we're on the same page (and so we all know I've done my homework), here's what I've tried:
- diff. The patch between my original acs-templating/tcl directory and the new security fixed version is a whopping 2455 lines! I'm not even sure where to start to figure this one out. diff is usually my best friend when I have code that worked before and doesn't work now...but 2455 lines of code is a lot of diff lines to read. I fear I've given myself a headache from staring at a slew of plus/minus prepended lines of code I don't quite understand. I'm beginning to suspect that this security update contains maybe a little bit more than security-related changes.
- API docs. I see how the call to the relevant paginator function is supposed to be made, but I don't see how I can figure out what is actually being sent or where things are going wrong. Or, for that matter, even whether the function is behaving as documented after the upgrade. I know how to fire up tclsh, but I don't know how to have a "live" OACS environment in the shell for debugging purposes (or whatever equivalent debugging tools might exist).
- Logging. I've added a few logging calls sprinkled about in bug-tracker, but I'm not getting any information that seems particularly revealing. Again, the extreme abstraction of bug-tracker has me a bit stumped. I don't think I'm clever enough to grasp this code, as it seems to all happen magically (workflow package does the thinking, and I've tried on numerous occasions to make it do something differently, and it never listens to me--it's like I'm talking to brick wall about roles and actions).
- Backtrace. I've read the backtrace several times, and I've following the execution path through the source, having a look at each function from the bug-tracker on down through the paginator functions and template functions. I just don't understand things well enough to spot what is wrong.
What's next? I'm perfectly willing to do my own leg-work. I just don't know where to go from here. Obviously, I'd like to stay on top of security updates. But I'd also like to keep things kinda sorta working most of the time.
Anyone have a clue or two they can beat me about the head and shoulders with?
In the past I used the old ticket module (OpenACS 3) wich I consider more flexible and functionally complete than bug-tracker, but never found the time of porting it to a newest release.
Regarding the package breakage in general I understand that it is disappointing and I agree that this should be clearly stated, even if I, as a developer, find them very useful anyway.
What are you clicking on to get that error, or when is it happening?
I commented on your bug. I don't think its related to the templating security fix at all. That just changes how variables are substituted within translation message keys. Its a pretty obscure issue.
Basically the statement_name passed into template::paginator::create is an empty string and we need to track down why that is.
If possible more interactive debugging assistance is available almost 24 hours a day from #openacs on irc.freenode.net.
I've installed developer-support. Very cool! I'm still stumped, but it's cool, nonetheless.
What has me stumped is I'm trying use the shell to just run a database query as it appears in the bug-tracker call to template::list::create (which is where things appear to go south), but I get an upvar error when I do, and I guess this is because the state is clean when I start the shell and we're already up as far as there is to go. So, how do I pull in the relevant modules to get state that I can use? i.e. is it possible to simulate an application interaction and then query variables or function results directly?
Specifically, here's what I get:
Input tcl script:
bug_tracker::bug::get_query -query_name bugs_pagination
can't upvar from variable to itself
"upvar #[template::adp_level] orderby orderby "
(procedure "bug_tracker::bug::get_query" line 4)
invoked from within
"bug_tracker::bug::get_query -query_name bugs_pagination"
("uplevel" body line 1)
invoked from within
"uplevel 1 $script"
Anyway, I'm back to being stumped after following up on David's bug-tracker response. I've reverted to the old, insecure, acs-templating on my production site, until I can get this figured out.
Sorry, apparently other things changed in templating besides that one fix.
You can apply this patch for the security update.