To help answer an OTN question today regarding the use of the domain/lib directory on WLS 10.3.3, I went to use the CAT utility (as I've become accustomed) and then realized we'd only added it from the WLS 10.3.4 onwards.
As far as I'm aware, we don't make use of any newer APIs in WLS 10.3.4 within CAT, so I simply copied out the wls-cat.war file from a WLS 10.3.4 installation and deployed it to the WLS 10.3.3 domain I was using for the test.
The WLS CAT application deployed successfully and then seemed to work normally, letting me locate exactly where class I was using was being loaded from on WLS 10.3.3.
Of course this is totally unsupported, but if you're in need of WLS CAT on an earlier 10.3.x release and of the adventurous spirit, give it a shot. You can always undeploy it if it doesn't work for you.
2 comments:
It appears that if you backport this from 10.3.4 to 10.3.3, the link for "Classloader Analysis Tool" doesn't appear in the "Testing" tab. In that case, you have to use the manual URL for "wls-cat" described in the "CAT" documentation page.
The other unfortunate problem with using this is that my classloader conflict causes the app to fail to deploy, and CAT only works with applications that successfully deployed. Considering the most likely symptom of a classloader conflict is that the app fails to deploy, It looks to me like CAT is all dressed up with nowhere to go.
(Sigh. I entered this once and Blogger blew it away. Here we go again.)
It appears that when you backport this from 10.3.4 to 10.3.3, the "Classloader Analysis Tool" doesn't appear in the "Testing" tab. However, you can still use the direct URL for it, as described in the CAT doc page.
The bigger problem is that this apparently only works with applications that have successfully deployed. Considering that the most likely symptom of a classloader conflict is that the app fails to deploy, it looks to me like CAT is all dressed up with nowhere to go.
Post a Comment