Wednesday 8 February 2017

Just because we can doesn't mean we should - Serving Static Content from WebSphere Application Server's Web Container

This ties up with something about which I've been talking with one of my colleagues.

Using my BPM 8.5.7 VM, I created an HTML file: -

Hello.html

<html>
<body>
<head>
<h1>
Hello World!
</h1>
</head>
</body>
</html>

here: -

/opt/ibm/WebSphereProfiles/AppSrv01/installedApps/PCCell1/IBM_BPM_Portal_AppCluster.ear/process-portal.war

This location hosts the Heritage Process Portal, which has two URIs: -

 
The first URI - /portal - actually references a different WAR file ( process-portal-support.war ) whereas the second URI - /HeritagePortal - references this WAR ( process-portal.war ).

Therefore, with my HTML file in this location: -

/opt/ibm/WebSphereProfiles/AppSrv01/installedApps/PCCell1/IBM_BPM_Portal_AppCluster.ear/process-portal.war

I can hit the following URL: -


and see my page: -

 

Bottom line, this turns WAS into a rather expensive HTTP server, but we can put static content within a WAR, purely in the interests of research and development :-)

2 comments:

Kenio Carvalho said...

Last week, on a customer site, his Websphere Portal was serving tons of static js files and css files (all files as wcm components).
The number of hits was very high for this files because of an inconrrect cache setting.
I move all files to IHS Servers and wrote some redirect rules and cache settings.
After that the number of hits and cpu usage drops 30%. :-)

Dave Hay said...

Hi Kenio

Yes, I completely agree, hence the title of the post :-)

Whilst this is a useful way to test, or PoC, an idea, I'd definitely suggest that static content be offloaded to a web server.

Thanks again, Dave

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...