Ken, thanks for responding.
I am trying to understand why the resources that I have included locally within my web module does show up as:
where as the js files served/included by richfaces (which is also part of the same web module, even though as jars) be encoded.
I was trying this as a possible workaround to fix an issue we are facing as I have posted here: http://stackoverflow.com/questions/8219311/websphere-portal-jboss-portlet-bridge-jsf-richfaces-facelets-http-500-ok-m
From the information provided in the stackoverflow post, I suspect it's a problem with the web server proxying for Websphere, through either missing config or another problem. I don't have any knowledge of IHS so wouldn't be much help on that front.
Also, you mention that the js files are returned with HTTP 500 OK messages, 500 is not an OK message. It signifies a server error, which further leads me to a problem with IHS.
Yeah, we were thinking on the same lines too. One other thing we see is that in the http logs, we see a file not found error.
It kind of makes sense as the file being server by richfaces is physically not there in the location specified, but not sure why it happens only with the portal, because when I see my other jsf app deployed directly on WAS going through the same http server does not have a problem with it.
That is the reason I was thinking if there was something that could be done on the portal side.
Thanks for the responses.
I got my issue resolved and the portlet bridge's behavior was just fine.
There is a plugin between Websphere and IHS and there is something called Edge side caching. This was enabled and after talking to IBM, they advised to disable this and that fixed our issue. So, the application works directly on portal server as well as from a web server.