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 >> >>> 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
