Folks, With or without the domain.ini file (or with it blank), the :80 is not recognized as the same domain... so I give up.
My fix is to use a custom scoped var. If someone has a better idea (I'd prefer to use domain vars, because I've already started writing my tafs to use them), please consult me offlist. Jim Kass Web Developer -- Forestweb: The Source for Industry Intelligence Best Content -- Most Relevant -- Best Delivery http://www.forestweb.com (310) 553 - 0008 -----Original Message----- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 2:53 PM To: [EMAIL PROTECTED] Subject: RE: Witango-Talk: STARTUPURL configuration var. Hi Jim, See, two different domains - as far as Witango is concerned. Just so you know, you don't have to configure the domain.ini file to make use of Domain Scope variables. Unless you're using domain.ini for something specific, maybe remove the domain entries and see what happens. The domain.ini file in it's default state still supports multiple domains. It's only when you need to make unique Configuration Variable settings for a particular domain that you need to edit that file. Hope this helps. Cheers..... Scott Cadillac, Witango.org - http://witango.org 403-281-6090 - [EMAIL PROTECTED] -- Information for the Witango Developer Community --------------------- XML-Extranet - http://xmlx.ca 403-281-6090 - [EMAIL PROTECTED] -- Well-formed Development (for hire) --------------------- -----Original Message----- From: "Jim Kass" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Thu, 6 Nov 2003 14:33:32 -0800 Subject: RE: Witango-Talk: STARTUPURL configuration var. > Robert, > > EXCELLENT TEST! I determined that the STARTUPURL version is showing > www.mydomain.com:80 and the browser version is showing www.mydomain.com > > Also.. I'm noticing that the :80 version is runs serveral times after > the > server gets started (the variableTimeoutTrigger is also set to the same > URL, > so maybe the domain var is timing out right away in some cases). > > My domains.ini file looks like: > > [Domains] > www.mydomain.com > www.mydomain.com:80 > > but that doesn't seem to change anything... I'm ALMOST THERE! Please > help > me get this resolved. > > Jim Kass > Web Developer > > -- > Forestweb: The Source for Industry Intelligence > Best Content -- Most Relevant -- Best Delivery > http://www.forestweb.com > (310) 553 - 0008 > > -----Original Message----- > From: Robert Shubert [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 1:59 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: STARTUPURL configuration var. > > > It still sounds like either the startupurl is not firing on the proper > domain. Add to your startupurl TAF to email you <@DOMAIN> and see what > it responds from both executions (statup and browser) > > Robert > > > -----Original Message----- > From: Jim Kass [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 2:51 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: STARTUPURL configuration var. > > > Here is the problem exactly: > > I use a taf to purge all domain variables, then restart the server. I > can > see in the log file that my domain variable IS BEING SET(and thus the > URL is > being hit), but then when I try to use a taf that reads the domain > vars, > it > shows that they are still purged. If I go to the startupurl file with > my > browser, the log file shows exactly the same result as before, but now > going > back to my domain var reader taf, the domain vars are set. > > I hope that helps to explain it better. > > TIA > > Jim Kass > Web Developer > > -- > Forestweb: The Source for Industry Intelligence > Best Content -- Most Relevant -- Best Delivery > http://www.forestweb.com > (310) 553 - 0008 > > -----Original Message----- > From: Scott Cadillac [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 11:41 AM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: STARTUPURL configuration var. > > > Hi Jim, > > I admit I haven't read every post on this thread, but I can confirm > that > the > method you just > described does work. > > There must be some other problem getting in the way for you. > > Although you can likely reach 'http://www.website.com/' from the > browser > on > your > workstation, it does not necessarily mean the Server can find itself > as 'http://www.website.com/'. > > In order for STARTUPURL to work, the Server Witango is running on must > be > able to reach this > address and the problem with the STARTUPURL process is that there is > nothing > "visual" to > indicate the process completed successfully. > > Have you tried pinging the address from the Server itself? Or opened a > browser on the Server > and surfed to 'http://www.website.com/'? > > Can you reach it? If not, try modifying the HOSTS file on the Server or > correct the local > DNS configuration - then start over and test it again. > > Hope this helps. Cheers..... > > Scott Cadillac, > Witango.org - http://witango.org > 403-281-6090 - [EMAIL PROTECTED] > -- > Information for the Witango Developer Community > --------------------- > > XML-Extranet - http://xmlx.ca > 403-281-6090 - [EMAIL PROTECTED] > -- > Well-formed Development (for hire) > --------------------- > > > -----Original Message----- > From: "Jim Kass" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Date: Thu, 6 Nov 2003 11:22:55 -0800 > Subject: RE: Witango-Talk: STARTUPURL configuration var. > > > > > > > So, then by that reational - if I test and use the startupurl with > > 'http://www.website.com/startup.taf' domain... then any domain var > > assignments there should be able to impact domain vars on > > http://www.website.com/index.taf. > > > > The problem is... they don't! > > > > With the exception of writing code that sits at the head of EVERY > > SINGLE taf > > (we have 100s right now), is there no other way that Tango can > > essentially > > "preload" certain variables that are used globally in every taf on > the > > server??! > > > > I guess my big question is can you set global/domain variables using > a > > STARTUPURL (has anyone a proven method of doing this before), and > > if not, then is there another solution that someone has in mind. > > > > TIA > > > > Jim Kass > > Web Developer > > > > -- > > Forestweb: The Source for Industry Intelligence > > Best Content -- Most Relevant -- Best Delivery > > http://www.forestweb.com > > (310) 553 - 0008 > > > > -----Original Message----- > > From: Robert Shubert [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 05, 2003 7:19 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Witango-Talk: STARTUPURL configuration var. > > > > > > A few things to note: > > > > It's generally good practice to set an additional domain variable > > something like: <@ASSIGN domain$vars_ok 1> Then at the top of each > TAF, > > place an IF statement checking for @@domain$vars_ok != 1. If so, > branch > > to your domain variable rebuild TAF. In your setup, it sounds like > your > > domain variable set is an all-or-nothing issue. This will ensure that > > your variables are present before any execution occurs. > > > > The second thing to note is that domain variables are dependant on > the > > domain which is the entire URL, including the host, thus > "website.com" > > and "www.website.com" are two separate domains. If you're testing at > > one, and running your startupurl at another, you'll have the outcome > > you > > describe (and rather unpredictable results). You can use domains.ini > to > > combine URL variations like that into one 'tango' domain, or simply > use > > @URL to call your domain setup TAF at all possible domain variations. > > > > Robert Shubert > > Tronics > > > > -----Original Message----- > > From: Jim Kass [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 05, 2003 9:32 PM > > To: [EMAIL PROTECTED] Com > > Subject: Witango-Talk: STARTUPURL configuration var. > > > > I'm using dynamic DataSources... specified with domain scoped > > variable(s). > > Whent the server restarts I'm noticing strange behavior... > > in some cases, the domain vars die, but in most cases they are still > > alive. > > > > I used a taf to clear domain vars manually, and restarted the server. > > The STARTUPURL that I set in t4server.ini which creates the domain > vars > > I > > need shows it is setting them in the log, but then when I try to use > a > > file > > that requires it, it fails... another taf used to view vars shows > that > > the > > domain vars are as blank as when I cleared them before the restart. > > > > If I run the taf that the STARTUPURL points to manually... it sets > all > > the > > vars I want and they are accessible, and after the server is > restarted, > > they > > are still alive. > > > > I'm awfully confused. The default timeout is set to 120. I'm > setting > > a > > variableTimeoutTrigger to the same taf as STARTUPURL. My big concern > > here > > is that sometimes these domain vars are dying and because they are > > being > > used to indicate a database connection - pretty important things will > > break > > in the middle of the night after a server restart without my > knowing... > > a > > serious problem as far as I'm concerned. > > > > I'd think that setting the variableTimeoutTrigger to the STARTUPURL > taf > > would ensure that even if they die that they still get rebuilt, but > > considering that the variable assignments dont seemt to be happening > > anyway > > other than in the logs... I'm at a loss for how to ensure 100% uptime > > of > > these vars. (Maybe the ultra-unelegant solution of putting the > > STARTUPURL > > taf on a cron... hoping that it behaves differently than when the > > server > > restarts). > > > > > > > > Any ideas? > > > > > > Jim Kass > > Web Developer > > > > -- > > Forestweb: The Source for Industry Intelligence > > Best Content -- Most Relevant -- Best Delivery > > http://www.forestweb.com > > (310) 553 - 0008 > > > > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
