Application Development Software

I am working on optimization of portal performance by moving static files (gif, css, js) to my front web server (apache) for WLP 10 portal application. I end up with moving whole "framework" folder of the portal WebContent to file system served by apache web server (the one which hosts WLS plugin pointing to my WLP cluster). I use <LocationMatch> directives for that:

Alias /portalapp/framework "/somewhere/servedbyapache/docs/framework"
<Directory "/somewhere/servedbyapache/docs/framework">
<FilesMatch "\.(jsp|jspx|layout|shell|theme|xml)$">
Order allow,deny
Deny from all
</FilesMatch>
</Directory>
<LocationMatch "/partalapp(?!/framework)">
SetHandler weblogic-handler
WLCookieName MYPORTAL
</LocationMatch>

So, now browser gets all static files from apache insted of the app server. However, there are several files from bighorn L&F, which are located in the WLP shared lib: skins/bighorn/ window.css, wsrp.css, menu.css, general.css, colors.css; skins/bighorn/borderless/window.css; skeletons/bighorn/js/ util.js, buttons.js; skeleton/bighorn/css/layout.css

I have to merge these files into the project and physically move them into apache served file system to make mentioned above apache configuration works.

However, this approach makes me exposed bunch of framework resources, which I do not to intend to change and they should not be change (only custom.css is the place to make custom changes to the bighorn skin). Which is obviously not very elegant solution. The other approach would be intend to create more elaborate expression for LocationMatch (I am not sure it's entirely possible giving location of these shared resources). More radical move - stop using bighorn and create totally custom L&F (skin, skeleton) - which is quire a lot of work (plus - bighorn is working just fine for us).

I am wondering what is the "Best Practice Approach" approach recommended by Oracle/BEA - giving the fact that I want to serve all static files from my front end apache server instead fo WLS app server.

Thanks,

Oleg.