SOLVED: WebServerResources under servlet deploy - WOAppMode=Deployment
SOLVED: WebServerResources under servlet deploy - WOAppMode=Deployment
- Subject: SOLVED: WebServerResources under servlet deploy - WOAppMode=Deployment
- From: Jon Nolan <email@hidden>
- Date: Thu, 21 May 2009 20:43:55 -0600
- Organization: Loch Garman
Jon Nolan wrote:
>>> The ERXStyleSheet is assuming that the file is in the location it
would be if you were having the Web Server serve the static files.
>>>
>>> This path maps to:
/Library/WebServer/Documents/WebObjects/Frameworks/WDExtensions.framework/WebServerResources/css/default-styles.css
>>>
>>> But because you are serving static files through Tomcat instead of
the Web Server and Tomcat has no way of parsing that URL to you're app's.
>>>
>>> I'm not sure how to get ERXStyleSheet to generate a different URL
that would get it to load from the app.
Thanks again Dave.
Making ERXStyleSheet and ERXJavascript work under these conditions
doesn't seem possible without *serious* patching. I'm afraid to go
near that. I can live without using ERXStyleSheet and ERXJavascript
in my apps/frameworks if I have to but the subclasses of AjaxComponent
load the Prototype javascript via addScriptResourceInHead which gives
me a problem I can't see my way around.
Does anyone know if there's a simple way of having
AjaxComponent/AjaxUtils/ERXResponseWriter in some way point to a
webserver based URL? Or perhaps allow me some control over applying a
substitute for "/WebObjects/Frameworks" in the static resource URLs
which the ERXResourceManager creates for me? I've been crawling the
source all afternoon and I'm not seeing it.
Is there anyone else using Wonder Ajax under deployment WOAppMode in a
servlet environment? If so, how did you solve this problem?
OK, I'm not 100% sure I've gone about this the right way... or if I have
done so why exactly it is right... but here goes. Please poke holes in
my solution and/or if you see a better way let me know. I struggled
this for quite a while and am posting this in the hope it helps someone
down the road.
Deploying a servlet based Wonder app presents significant problems when
it comes to static resources. ERXStyleSheet and ERXJavascript just
don't support a solution as far as I can tell. Fortunately,
ERXResponseRewriter and its Delegate inner class do. But first things
first. Using Dave's suggestion with slight mods I copied all of the
WebServerResources to the app root (level with WEB-INFO) by adding the
following to my build.xml.
<!-- copy the WebServerResources to the
WEBINFROOT/WebServerResources directory -->
<mkdir dir="${dest.dir}/${build.app.name}/WebServerResources" />
<copy todir="${dest.dir}/${build.app.name}/WebServerResources"
verbose="true">
<fileset dir="${dest.dir}/${build.app.name}.woa/Contents">
<include
name="Frameworks/*.framework/WebServerResources/**"/>
</fileset>
<fileset dir="${dest.dir}/${build.app.name}.woa">
<include name="Contents/WebServerResources/**"/>
</fileset>
</copy>
This gives me the files at a location where tomcat can legally serve
them via its http connector port. Now to make the application itself
point those static resource URLs in the right direction. The biggest
problem we have with a default deployment install is that there's not
really a way to remove responsibility for those URLs from the servlet
class. By including /WebObjects in the URL we're always bypassing
tomcat and going straight to the servlet.
So the second step is establishing a ERXResponseRewriter.Delegate and
giving it the opportunity to rewrite the static resource URLs. Here's
my implementation. It's fairly self explanatory and you'll see that it
doesn't readily handle all possibilities (i.e. WebServerResources in
the application rather than frameworks) but it covers my immediate needs
and should be easy to extend for future needs.
public class WDResponseRewriterDelegate implements
ERXResponseRewriter.Delegate {
public static void setDelegate() {
String responseRewriteFormat =
ERXProperties.stringForKey("com.lochgarman.wd.extensions.responserewriteformat");
if (responseRewriteFormat != null)
ERXResponseRewriter.setDelegate(new
WDResponseRewriterDelegate(responseRewriteFormat));
}
private String responseRewriteFormat;
public WDResponseRewriterDelegate(String value) {
responseRewriteFormat = value;
}
public boolean responseRewriterShouldAddResource(String
framework, String fileName) {
return true;
}
public Resource responseRewriterWillAddResource(String
framework, String fileName) {
String result = responseRewriteFormat;
if (framework != null)
result =
ERXStringUtilities.replaceStringByStringInString("${framework}",
framework, result);
if (fileName != null)
result =
ERXStringUtilities.replaceStringByStringInString("${fileName}",
fileName, result);
return new Resource(null, result);
}
}
You'll need to set up a property looking like this somewhere. There are
some shortcomings in this which I'll need to address. First thing comes
to mind is handling more than one app. Refactoring the property name
will take care of that.
com.lochgarman.wd.extensions.responserewriteformat=/AppName/WebServerResources/Frameworks/${framework}.framework/WebServerResources/${fileName}
This gets us most of the way there. Unfortunately, the delegate is only
used by ERXResponseRewriter.addResourceInHead() and
ERXStyleSheet/ERXJavascript bypass that method and go straight to
insertInResponseBeforeHead(). I'm pretty leery of trying to modify
those two classes to use the former method as there's a lot going on
there I don't completely understand. So I bailed on those two classes
and switched to ERXResponseRewriter.addStylesheetResourceInHead() and
ERXResponseRewriter.addScriptResourceInHead() within the component I use
to support my <head> tag. It works quite well. If I leave the property
out such as is standard in eclipse/dev I get the ?wrdata style URLs and
if the property is there I get URLs of the form
http://dev.box.com/AppName/WebServerResources/Frameworks/WDExtensions.framework/WebServerResources/css/default-styles.css.
Any suggestions for improvement are appreciated.
Slán,
Jon
_______________________________________________
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