On 2011-10-24, at 8:04 AM, [email protected] wrote: > Thanks Q for the tip. Looks like you are right on the money. > > I asked my buddy "JD" what the heck you are talking about since > WODeployedBundle.relativePathForResource() is undocumented. It in turn calls > _preloadAllResourcesIfNecessary() which is where the fun really starts to > happen. > > Here's what I can gather and conjecture: > > WO loads up all the locations for static resources located in the jar, war, > or woa and caches them. Whenever your app needs them it tries to find a > cached value. If there is a match it then converts it to what is needed in a > split install for Apache to use and just *assumes* it is out there in the > publically viewable web directory.
<smacks forehead> Right. Of course. It won't know the path to nested resources if it does not have a model to look them up in. > If there is no match then it just assumes "NOT_FOUND" and doesn't even > bother to do anything more assuming that it won't be in the split install > location either. > > Thinking further this makes some sense. Think about permissions and access. > Our java app could be run anywhere, even inside a war file. It could be > isolated from the true static content. Imagine all your static resources > being served by Akamai. Or maybe your java app is run with a user that just > doesn't even have read access to the web directory due to some business > policy. Any one of these interesting scenarios being the case why not just > duplicate the static resources into your app bundle? It's a reasonable > assumption that your script will accurately split install a copy where Apache > can serve it up. While this is duplication (which is normally a bad thing) it > is OK from a security standpoint to put static resources in your app bundle. > The converse, putting java logic and jars in your Apache split install would > be bad. The duplication buys you the ability to "confirm" the existence of > resources dynamically at runtime. > > In the end? Yes we have to duplicate our static resources with WO. That's the > way it is. At least the above ideas sheds some light on why this must be so. > While it doesn't make sense for simple deployments it must be this way for > complex ones. > > Yes, once again we find the old WO masters are wise beyond their years. They > anticipated a great deal and afforded us the flexibility to carry on through > infinity and beyond. The other option would be to build a model of the static resources into the application resources at build time. I am thinking of a plist here. The bundle could then consult this to determine if a resource existed and what its path was. That sounds like a lot of effort to save a bit of storage and bandwidth. Chuck > From: Q <[email protected]> > To: Chuck Hill <[email protected]> > Cc: [email protected], [email protected] > Date: 10/22/2011 02:34 AM > Subject: Re: Why are static web resources duplicated in the app > bundle? > > > > > On 22/10/2011, at 5:35 AM, Chuck Hill wrote: > > > > > On 2011-10-21, at 11:28 AM, [email protected] wrote: > > > >> Good thought Chuck, > >> > >> I checked and the app I was testing and it has direct connect disabled. I > >> guess somehow deep in the bowels of WO it just expects the duplication to > >> be there. > > > > It would be interesting to know where that is. > > WODeployedBundle.relativePathForResource(...) > > > > > > > Chuck > > > >> And, as you say, perhaps it is tolerated because you might at some point > >> want to turn on Direct Connect mode to test something. Still seems a bit > >> shaky but maybe that's all there is to it. > >> > >> Thanks for the tip, > >> -- Aaron > >> > >> > >> > >> From: Chuck Hill <[email protected]> > >> To: [email protected] > >> Cc: [email protected] > >> Date: 10/21/2011 01:16 PM > >> Subject: Re: Why are static web resources duplicated in the app > >> bundle? > >> > >> > >> > >> I _thought_ they were only needed on the Java side for development builds > >> and with Direct Connect. I'd guess they are included in the .woa as it is > >> possible to run the app in Direct Connect mode. > >> > >> Chuck > >> > >> > >> On 2011-10-21, at 10:09 AM, [email protected] wrote: > >> > >>> Hi WOrriors, > >>> > >>> Do any of us know why static web resources such as images and javascript > >>> files get duplicated during a split install? Surely they need to be in > >>> the .woa that resides under the Apache root but why are they duplicated > >>> in the other .woa alongside the java logic? > >>> > >>> I've seen this for many years when compiling under both pbx.proj and ant. > >>> Recently I made a comment that this duplication was inane but then my > >>> bluff was called. When we tried to remove it from the java side of the > >>> split we get "NOT_FOUND" resources. It seems like WO requires this > >>> duplication but why? > >>> > >>> Only the files located on the Apache root side of the divide truly have > >>> to be there. Those are the ones served up to the web browser. Why on > >>> earth would the java side of the house need them duplicated? > >>> > >>> -- Aaron _______________________________________________ > >>> Do not post admin requests to the list. They will be ignored. > >>> Webobjects-dev mailing list ([email protected]) > >>> Help/Unsubscribe/Update your Subscription: > >>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > >>> > >>> This email sent to [email protected] > >> > >> -- > >> 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 ([email protected]) > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/webobjects-dev/qdolan%40gmail.com > > > > This email sent to [email protected] > > -- 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 ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
