This issue appears to be resolved. And, it appears it has no relationship to the other other issue I'm experiencing. DOGGONIT!! :-)
So, um, set your frameworksBaseURL. Tim Worman UCLA GSE&IS On Aug 22, 2011, at 11:42 AM, Tim Worman wrote: > > On Aug 22, 2011, at 11:26 AM, Chuck Hill wrote: > >> >> On 2011-08-21, at 12:33 PM, Tim Worman wrote: >> >>> On Aug 21, 2011, at 11:49 AM, Chuck Hill wrote: >>> >>>> >>>> On 2011-08-20, at 11:28 AM, Tim Worman wrote: >>>> >>>>> It's taken me a few days to get back to this due to a deployment. >>>>> >>>>> On Aug 10, 2011, at 7:51 AM, Chuck Hill wrote: >>>>> >>>>>> On 2011-08-10, at 7:03 AM, Timothy Worman wrote: >>>>>>> On Aug 9, 2011, at 9:46 AM, Chuck Hill wrote: >>>>>>> >>>>>>>> Hi Tim, >>>>>>>> >>>>>>>> I am not really clear on what you are doing and what the problem is. >>>>>>>> This code should only affect URLs that get sent into your application. >>>>>>>> Which should be none. Why do you have relative URLs to resources? >>>>>>>> Have you looked at the BASE tag, >>>>>>>> http://www.w3schools.com/tags/tag_base.asp? That maybe a better >>>>>>>> solution to your problem. >>>>>>> >>>>>>> I do believe I have relative urls in my css pointing to images used by >>>>>>> the css. I can't look at the moment but I used suggestions I found on >>>>>>> the list to do it. Maybe this causes issues. >>>>>> >>>>>> Wonder uses this (e.g. the Ajax frameworks) so it should work if you >>>>>> have a Wonder app. Check the page source, does the CSS link look like >>>>>> this: >>>>>> >>>>>> <link rel="stylesheet" type="text/css" >>>>>> href="/cgi-bin/WebObjects/AjaxExample.woa/_wr_/wodata=/Users/chuck/Documents/Wonder/Frameworks/Ajax/Ajax/build/Ajax.framework/WebServerResources/modalbox.css"/> >>>>> >>>>> No, in deployment that page resources are linked like: >>>>> >>>>> <link rel="stylesheet" type="text/css" >>>>> href="/WebObjects/Frameworks/GSEISCoreFramework.framework/WebServerResources/core.css"/> >>>>> <script >>>>> src="/WebObjects/Frameworks/Ajax.framework/WebServerResources/prototype.js"></script> >>>>> <link rel="stylesheet" type="text/css" >>>>> href="/WebObjects/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.css"/> >>>> >>>> That is vended through Apache. Those won't reach the app (unless you have >>>> some whacky rewrite rules :-) >>> >>> The only rewrite rules I use are the ones to convert my /cgi-bin/WebObjects >>> bla bla into the app name. >>> >>> But I'm pretty sure I do have a problem here. :-) Because what I'm actually >>> doing is creating symlinks in >>> /Library/WebServer/Documents/WebObjects/Frameworks to the actual embedded >>> framework resources in the split install of the app. I have to because >>> those are the paths where the app tries to discover those resources in >>> deployment. But I'm not really sure when this started to be a problem or >>> why - I've always used the typical project layout and build files. Maybe my >>> build files are behind the times? 'Cause they never really get updated >>> unless you create a new project. >> >> You need this in the build.properties file of the app: >> >> frameworksBaseURL=/WebObjects/Cadre.woa/Frameworks >> >> http://davidleber.net/?p=279 > > Thanks Chuck. > > I did find something about that last night - and I completely remember > reading discussions about it related to WO 543 but I did not make the > connection to any issues I was having since I wasn't seeing any grand > failures in my apps. I'm gonna make sure this is set properly and see if it > has any relationship to the other issue I've been tracking with requests not > completing. > > Tim Worman > UCLA GSE&IS > > >>>>> >>>>> In development they are linked more like: >>>>> >>>>> <link rel="stylesheet" type="text/css" >>>>> href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Users/worman/Source/corewo/GSEISCoreFramework/WebServerResources/core.css"/> >>>>> <script >>>>> src="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/modalbox.js"></script> >>>>> <link rel="stylesheet" type="text/css" >>>>> href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/modalbox.css"/> >>>>> <script >>>>> src="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.js"></script> >>>>> <link rel="stylesheet" type="text/css" >>>>> href="/cgi-bin/WebObjects/eTimesheet.woa/-55555/wr/wodata=/Library/Frameworks/Ajax.framework/WebServerResources/ibox/ibox.css"/> >>>> >>>> The app serves these. >>>> >>>> >>>>> >>>>>>>>>>>> What's been causing this for me are requests for >>>>>>>>>>>> "Ajax/WebServerResources/ibox/images/bg.png" when using AMD. >>>>>>>> >>>>>>>> I don't see why that should be. Are you using a custom CSS file with >>>>>>>> the AMD? Is the relative URL in there? That will only work with >>>>>>>> Wonder, and only if the image path is relative to the location of the >>>>>>>> CSS file in your project. >>>>>>> >>>>>>> I am not using custom css for the AMD. I'm simply using the component >>>>>>> in my app. I didn't know any of this trouble was happening until I >>>>>>> started trying to handle session restoration for ajax requests. Then I >>>>>>> noticed that method was being called all the time and it seemed related >>>>>>> to image files. At that point I started searching the list to figure >>>>>>> out why that would be happening. That's what bought me here to Klaus' >>>>>>> thread on the same topic. >>>>>> >>>>>> It should not be getting called all the time (obviously). Do you have >>>>>> CSS and images that are vended directly from Apache and not through the >>>>>> application? That is the only thing that I can think of. >>>>> >>>>> I think the above links reflect that they are being vended through apache? >>>>> >>>>> I also think this entire issue I've encountered is related to another >>>>> issue I'm having that I brought up in January regarding runaway httpd >>>>> threads. >>>>> >>>>> http://lists.apple.com/archives/webobjects-dev/2011/Jan/msg00224.html >>>>> >>>>> I'm still having that issue but I'm gonna bring that thread back so that >>>>> subject stays on track. >>>> >>>> >>>> OK >>>> >>>> >>>> Chuck >>>> >>>>> >>>>> >>>>>> Chuck >>>>>> >>>>>> >>>>>>>> >>>>>>>> On 2011-08-05, at 12:51 PM, Timothy Worman wrote: >>>>>>>> >>>>>>>>> On Aug 5, 2011, at 12:17 PM, Chuck Hill wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2011-08-05, at 11:45 AM, Tim Worman wrote: >>>>>>>>>> >>>>>>>>>>> I'm seeing this now and it's been driving me exactly bat-sh!t >>>>>>>>>>> crazy. In all the threads I've read on this topic the only thing I >>>>>>>>>>> haven't found is WHY it happens. Why do any of the transactions on >>>>>>>>>>> my pages believe that image files are sessions ids? Anybody……….? >>>>>>>>>>> Bueller………? >>>>>>>>>> >>>>>>>>>> The transactions on your pages _don't_ believe that image files are >>>>>>>>>> sessions ids. From that page: >>>>>>>>>> The request URI looks like this: >>>>>>>>>> /cgi-bin/WebObjects/woapp.woa/wo/images/headerart.jpg. >>>>>>>>>> >>>>>>>>>> The /wo/ indicates that it is a session based, component request so >>>>>>>>>> WO just hands it off to the WOComponentRequestHandler. The >>>>>>>>>> WOComponentRequestHandler needs a session to handle the request, so >>>>>>>>>> it creates one if one does not exist. After that point it hits the >>>>>>>>>> error of the URL being nonsense. >>>>>>>>>> >>>>>>>>>> Chuck >>>>>>>>> >>>>>>>>> Thanks for the explanation Chuck - very much appreciated. After >>>>>>>>> implementing Klaus's code, I'm now returning 404's on most of the >>>>>>>>> images in my app - so they don't show up at least in development. So, >>>>>>>>> this will fubar deployment. I am using Wonder/apache to rewrite urls. >>>>>>>>> Do I have to get the rewriting involved in referencing my images >>>>>>>>> properly now? >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What's been causing this for me are requests for >>>>>>>>>>> "Ajax/WebServerResources/ibox/images/bg.png" when using AMD. >>>>>>>>>>> >>>>>>>>>>> …and maybe others. >>>>>>>>>>> >>>>>>>>>>> Oh, and thanks to Klaus for sharing the code! >>>>>>>>>>> >>>>>>>>>>> Tim Worman >>>>>>>>>>> UCLA GSE&IS >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 4, 2009, at 7:03 PM, Klaus Berkling wrote: >>>>>>>>>>> >>>>>>>>>>>> Sometime back in 2005 Kaj Hejer posted a question about having a >>>>>>>>>>>> relative link to an image, and clicking links on the wo app page >>>>>>>>>>>> resulted in their custom 'session expired' page. >>>>>>>>>>>> >>>>>>>>>>>> The solution was to catch the request for the image in >>>>>>>>>>>> dispatchRequest and return a 404. >>>>>>>>>>>> >>>>>>>>>>>> Well I recently came acros the same type of problem. I though I'd >>>>>>>>>>>> share the code: >>>>>>>>>>>> >>>>>>>>>>>> http://web.mac.com/kib/page1/files/relative_image.html >>>>>>>>>>>> >>>>>>>>>>>> If you have sessions that you can't account for, this may be why. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> kib >>>>>>>>>>>> >>>>>>>>>>>> "The trouble with normal is it always gets worse." >>>>>>>>>>>> Bruce Cockburn >>>>>>>>>>>> >>>>>>>>>>>> Klaus Berkling >>>>>>>>>>>> Systems Administrator >>>>>>>>>>>> DynEd International, Inc. >>>>>>>>>>>> www.dyned.com | www.eskimo.com/~kiberkli >>>>>>>> >>>>>>>> -- >>>>>>>> Chuck Hill Senior Consultant / VP Development >>>>>>>> >>>>>>>> Practical WebObjects - for developers who want to increase their >>>>>>>> overall knowledge of WebObjects or who are trying to solve specific >>>>>>>> problems. >>>>>>>> http://www.global-village.net/products/practical_webobjects >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Chuck Hill Senior Consultant / VP Development >>>>>> >>>>>> Practical WebObjects - for developers who want to increase their overall >>>>>> knowledge of WebObjects or who are trying to solve specific problems. >>>>>> http://www.global-village.net/products/practical_webobjects >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Chuck Hill Senior Consultant / VP Development >>>> >>>> Practical WebObjects - for developers who want to increase their overall >>>> knowledge of WebObjects or who are trying to solve specific problems. >>>> http://www.global-village.net/products/practical_webobjects >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> Chuck Hill Senior Consultant / VP Development >> >> Practical WebObjects - for developers who want to increase their overall >> knowledge of WebObjects or who are trying to solve specific problems. >> http://www.global-village.net/products/practical_webobjects >> >> >> >> >> >> >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com > > This email sent to li...@thetimmy.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
