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. Tim > > >> 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 > > > > > > > _______________________________________________ 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
