Forum OpenACS Q&A: adp code not being parsed properly

Posted by Rajneesh Khugsal on 09/06/02 07:56 AM

I am having a lot of trouble with the adp pages.
Most of the times <if></if><else></else> clause is not working.
Sometimes it seems to work and after a few clicks it stops
working giving an error no such variable.
I would be glad incase someone tells me where i can get the
latest patch to the adp parser, its been annoying.
I am using Oracle 8.1.6, AOLServer 3.0 and ACS 4.2.
Any sort of help will be most welcome.

2: Response to adp code not being parsed properly (response to 1)

Posted by Michael A. Cleverly on 09/06/02 08:25 AM

Does this occur consistantly? If you restart AOLserver does the problem again manifest itself? We run ACS 4.2 on Oracle 8.1.6 and AOLserver 3.3+ad13 and I can remember something like this happening once or twice in the past year, though it's been long enough I don't remember what the details were exactly...

I expect that the reason it "works" on some requests but not on others would be because different requests end up hitting different threads, and each thread has it's own Tcl interpreter, and in one (or more, but not all) of them the internal state of the templating engine has gotten corrupted/messed up.

Does the .adp/.tcl pair rely on database queries? Do you have a staging server you can test it on? If so, does the same .adp exhibit the same behavior? Can you reduce/simplify the template down to some minimal example? If you don't have another system to test it on, and you want to email the .tcl & .adp code to me, I'd be happy to give it a try on our system.

Also, if you are running AOLserver 3.0, you really ought to upgrade to either 3.3+ad13 or 3.4. Prior versions have security vulnerabilities.

3: adp code not being parsed properly under multiple clause (response to 1)

Posted by Rajneesh Khugsal on 09/09/02 07:04 AM

I can not load AOL Server 3.3 now, since management won't allow me
to play with whatever is already running.

I figured out that the problems start arising whenever i try to
refer a variable inside the multiple tag in adp file. The variable
can be easily used before the multiple tag. Yes the .adp and .tcl pair
rely on the database.

It will be great if you can advice me on how come even the plain
and simple statement like

<if @some_variable@ defined>

placed after multiple tag inside the adp file lead to variable not
being found. If I am right this should have been translated to the
tcl command

if { info exists ${some_variable} }

and the action would have proceeded even if the variable was not
found.

Since I am new to both TCL and this entire templating system, and
my background being in C and C++, i am getting altogether more
confused. Any sort of information is welcome. Even if you can tell
me some links to go and read, i would be more than happy doing that,
I just want to make this work.

Thanks Michael Sir for your reply but I am stuck here.

4: Response to adp code not being parsed properly (response to 1)

Posted by C. R. Oldham on 09/09/02 07:29 AM

Rajneesh,

I think someone will correct me if I am wrong, but I'm pretty sure there are bugs in the fancy adp parser in AOLserver versions prior to 3.3, so the templating system won't work very well with those versions.

You know you can run the server on a separate port and it will not interfere with anything else. That's one really big reason why I jumped on the OpenACS bandwagon--it was possible to setup different test scenarios and keep them from stepping on each other. That's really hard with Apache.

--cro

5: adp parser problems (most) solved. (response to 1)

Posted by Rajneesh Khugsal on 09/09/02 01:20 PM

Thanks Mr. OldHam,
It was the problem with the AOL Server. All the problems of
improper parsing of adp tags has now been resolved without even
touching a single line of code. All the things are working off
the shelf. I had worked for about a couple of weeks on this but
only part of the code used to work but now, I can not stop laughing.

So the outcome is ACS version 4.2 with AOLServer3.0 and Oracle
8.1.6 has problems with the ADP fancy parser. The solution out is to
replace AOLServer3.0 with version 3.3 and most of the problems
associated with the <if></if> inside <multiple> tag disappear.

Thanks again. 😊

6: Apache hard to run on different ports? (response to 1)

Posted by Andrew Piskorski on 09/09/02 03:03 PM

C.R., I've never had reason to run Apache, but I talk to people who do, so I'm curious about what you said, that, "it was possible to setup different test scenarios and keep them from stepping on each other. That's really hard with Apache." Why is it that, exactly? It's hard to run Apache on a seprate port (why?), or?

7: Response to adp code not being parsed properly (response to 1)

Posted by C. R. Oldham on 09/09/02 04:33 PM

cro wrote: it was possible to setup different test scenarios and keep them from stepping on each other. That's really hard with Apache.

Andrew wrote?" Why is it that, exactly? It's hard to run Apache on a seprate port (why?), or?

I guess our troubles stemmed from 2 things: 1) Apache in its default packaging (configure; make; make install) sort of assumes it is the only copy of itself on a given machine. Even the Debian packages assume there is only one copy. Apache needs lots of shared libraries nowadays, and you have to go through some gyrations to get it to look elsewhere. With AOLserver, all that can be changed in the config file. And we used to use mod_perl, which could break in unexpected ways if you upgraded your Perl the "wrong" way and forgot to recompile and rebuild Apache.

The second problem we had dealt more with the Mason package than Apache itself, but Mason (which we used to use before switching to ACS) also wouldn't allow you to run more than one version at a time or have more than one component root per Apache, so we could not develop with a later version or have more than one developer on the same machine do stuff without potentially breaking stuff for the other developers.

My goal was to be able to have our sites completely in CVS, config files and all, so we could check out to production or have developers check out copies and work on them "live" (e.g. with a full server behind them hooked to the database and all), and AOLserver made that possible. Also AOLserver generally has very few external dependencies--pretty much everything you need ends up in the AOLserver install directory (except for things like the shared libraries for nsxml and nsopenssl), and that seems to be a good thing. Apache is just so *big*, tracking down everything you need to duplicate an install on another box is troublesome...

So, Andrew, I'm not sure if I answered your question. Yes, you can run Apache on another port fairly easily, but running/testing different versions of Apache, or different versions of components inside of Apache (like mod_perl or Mason or things that need shared libraries), or supporting multiple developers on one machine is hard. Not impossible, I don't think, just hard.