30 October 2013

CRIMA5096821AE during WebSphere 8 update/fixpack or other Installation Manager operations

You might happen to be updating your WAS 8 installation with a fixpack, and more, you may want to do it with iclm tool, instead of IM GUI.

First of all, you need to be sure which package you are choosing from the repo, and to be sure you need to read the content of the repository with:

./imcl listAvailablePackages -repositories source_repository1,source_repository2

also, you need to be sure what is the exact signature of the packages you have installed:

 ./imcl listInstalledPackages -features -long

After you make sure you pick the ones you have and need, you do this (exemplary packages):

./imcl install com.ibm.websphere.ND.v80_8.0.7.20130725_2248 -installationDirectory /opt/IBM/WebSphere8/AppServer -repositories /opt/was8inst –acceptLicense

And, you might run into that error (exact paths vary from your system):

CRIMA5096821AE ERROR: Error updating.

CRIMA5096821AE ERROR: Error getting file for installation: 'jar file com.ibm.was.backup.nsf_8.0.4.20120410_0000' not found in /var/tmp/IBM/IMShared..

CRIMA5096821AE 'jar file com.ibm.was.backup.nsf_8.0.4.20120410_0000' not found in /var/tmp/IBM/IMShared.

In that case, you might start to worry, because most probably somebody deleted IMShared directory from your filesystem. And this is very bad thing, since Installation Manager needs this to operate on already installed packages. It stores vital data for IM operation, such as sychronization repos, libraries etc.
DO NOT REMOVE IT or you won't be able to use your IM with existing installation (to be precise: particular software packages for which this particular IMShared directory was chosen, as this may vary between packages, using the same always is a default).

There's nothing but one thing you can do about it - if you happen to work in multiple machine environment, you might have different machine with identical software set installed (like prod/dev/test systems). In that case, you might try to copy IMShared directory from other machine with identical set and in MIGHT work. Not guaranteed, but sometimes it's a last resort.

Good luck!

Couple of links on the topic:
http://www-01.ibm.com/support/docview.wss?uid=swg21444138
http://pic.dhe.ibm.com/infocenter/install/v1r2/index.jsp?topic=/com.ibm.cic.agent.ui.doc/topics/c_install_location.html

02 October 2013

WAS 8.5 Trace missing - SLF4J: Class path contains multiple SLF4J bindings

It's been quite long since I posted here. Yet I have one new tip for you today:

The problem was that WebSphere 8.5 server did not recognize components to trace after application deployment, and after finally appearing in the traceable components tree did not log all expected output to trace log. As a result we wasn't able to troubleshoot the installation, not to mention that some of the log output was required by defined use cases of the designed solution.


After some search, asking here and there, a colleague of mine (thanks, Agnieszka!) noticed the following entries in the SystemOut.log file of the server when the troublesome application was deployed:


10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Class path contains multiple SLF4J bindings.
[10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [bundleresource://243.fwk-1319487885:1/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-jdk14-1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:332 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:332 CEST] 00000042 SystemErr     R   SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
[10/2/13 13:42:10:357 CEST] 00000042 SystemErr     R   SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]

and apparently this was causing the server to make wrong class pickup the logging (and hence missing output as that class missed appropriate configuration).

I came up with the idea of removing one of the conflicting classes from ear with console option "Remove file" and selecting whole jar (lib/slf4j-log4j12-1.7.2.jar). After application restart logging started to work as expected!


Good luck!


Env: WebSphere 8.5.0.2 ND, Linux rhel 6 64bit, application build with Maven (some predefined class includes defined).