Re: Why are static web resources duplicated in the app bundle?
Re: Why are static web resources duplicated in the app bundle?
- Subject: Re: Why are static web resources duplicated in the app bundle?
- From: Chuck Hill <email@hidden>
- Date: Mon, 24 Oct 2011 10:59:51 -0700
On 2011-10-24, at 8:04 AM, email@hidden 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@hidden>
> To: Chuck Hill <email@hidden>
> Cc: email@hidden, email@hidden
> 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@hidden 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@hidden>
> >> To: email@hidden
> >> Cc: email@hidden
> >> 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@hidden 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@hidden)
> >>> Help/Unsubscribe/Update your Subscription:
> >>>
> >>> This email sent to email@hidden
> >>
> >> --
> >> 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@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
>
>
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden