WebSphere Application Server - Binary Scanner

From this: -

The binary scanner…not just for migrations anymore!

With the latest release of the binary scanner, two new enhancements are available that can help application developers and administrators outside the scope of a migration. Have you developed a new application for Liberty or moved one over from another application server and are wondering what features you need to configure in the server.xml file? Or maybe you are supporting a legacy application that has grown over time and you have no idea what is in it and what problems are lurking? Intrigued? Keep reading to see how the binary scanner can help you.

and this: -

Migration Toolkit for Application Binaries

The Migration Toolkit for Application Binaries provides a command line tool that quickly evaluates application binaries for rapid deployment on newer versions of WebSphere Application Server traditional or Liberty.

so I've tried it on some my sample applications: -

java -jar binaryAppScanner.jar ~/Downloads/DefaultApplication/DefaultWebApplication.war 

Scanning files.......................
The report was saved to the following file: /Users/davidhay/Downloads/wamt/DefaultWebApplication.war_TechnologyReport.html

java -jar binaryAppScanner.jar ~/Downloads/ferret-1.2.war 

Scanning files..........................
The report was saved to the following file: /Users/davidhay/Downloads/wamt/ferret-1.2.war_TechnologyReport.html

java -jar binaryAppScanner.jar ~/Desktop/SuperSnoopProj.ear 

Scanning files......
The report was saved to the following file: /Users/davidhay/Downloads/wamt/SuperSnoopProj.ear_TechnologyReport.html

So that's me OK then …

For the record, I've "installed" the Binary Scanner JAR on my Mac, running macOS Sierra, and am using Java 8

java -version

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

WebSphere Liberty Profile - Where's my stuff ?

I saw this: -

[14/02/17 10:50:51:653 GMT] 0000002b com.ibm.ws.webcontainer.webapp                               W SRVE0190E: File not found: /foo.jsp
[14/02/17 10:50:51:744 GMT] 0000002b com.ibm.ws.logging.internal.impl.IncidentImpl                I FFDC1015I: An FFDC Incident has been created: "com.ibm.ws.jsp.webcontainerext.JSPErrorReport: JSPG0036E: Failed to find resource /foo.jsp com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter 144" at ffdc_17.02.14_10.50.51.0.log
[14/02/17 10:53:03:226 GMT] 0000004f com.ibm.ws.webcontainer.extension                            W SRVE0190E: File not found: /login.html

on my local installation of WebSphere Liberty Profile (WLP) on my Mac.

What was strange was that the so-called missing files were definitely there.

Or, to be more precise, they were here: -

 ~/Downloads/wlp/usr/servers/defaultServer/apps/expanded/DefaultWebApplication.war/

HelloHTML.jsp HelloVXML.jsp HelloWML.jsp HitCount.jsp WEB-INF banner.gif index.html loginError.jsp
HelloHTMLError.jsp HelloVXMLError.jsp HelloWMLError.jsp META-INF auth_error.jsp foo.jsp login.html logout.html

I'd checked my server.xml for the specific web application: -

    <webApplication id="DefaultWebApplication"
     location="DefaultWebApplication.war"
     name="DefaultWebApplication" suppressUncoveredHttpMethodWarning="true" contextRoot="DefaultWebApplication">
     <application-bnd>
     <security-role name="All Role" id="admin">
     <special-subject type="ALL_AUTHENTICATED_USERS"></special-subject>
     </security-role>
     </application-bnd>
    </webApplication>

and I'd proven that the context root wasn't the problem, as I *WAS* able to access certain pages, such as this: -

https://localhost:9443/DefaultWebApplication/index.html

So, to summarise my position, I had a web application deployed to Liberty, suitably referenced in server.xml serving SOME but not ALL requested pages ….

So I then dug into the file-system further …..

… and found this: -

 ~/Downloads/wlp/usr/servers/defaultServer/apps/DefaultWebApplication.war.xml 

<?xml version="1.0" encoding="UTF-8"?>
<archive>
    <dir sourceOnDisk="/Users/davidhay/Documents/workspace/DefaultWebApplication/WebContent" targetInArchive="/"/>
    <dir sourceOnDisk="/Users/davidhay/Documents/workspace/DefaultWebApplication/ImportedClasses" targetInArchive="/WEB-INF/classes/"/>
</archive>

And that's the problem ….

This file appears to "override" what's in the server.xml file, meaning that the actual root ( from where the content is served ) is the Eclipse workspace.

I proved this by coping the missing files: -

cp ~/Downloads/wlp/usr/servers/defaultServer/apps/expanded/DefaultWebApplication.war/log* /Users/davidhay/Documents/workspace/DefaultWebApplication/WebContent/

which did the trick.

Next step is to see whether I actually need the DefaultWebApplication.war.xml file, as it's been helpfully provided by the WebSphere Developer Tools in Eclipse, with which I've been managing the WLP instance.

Fun fun fun

Improve IBM BPM performance with an Oracle database

This was published last week: -

Improve IBM BPM performance with an Oracle database

IBM® Business Process Manager (BPM) is a platform for processing and orchestrating enterprise business tasks. With proper planning, you can prevent performance issues before the end users of your process applications report them. This article focuses on what you can learn from the BPMDB database in IBM BPM to prevent problems and to troubleshoot issues when they occur.

This is part of a 3-part series: -

Improve IBM BPM performance with an IBM DB2 database

Solve IBM BPM performance issues with IBM DB2 examples

java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=com/ibm/rules/res/xu/spi/internal/XUResourceAdapter

Not sure why I've not seen this before, but that's a problem for another day.

During a build of an IBM Operational Decision Manager (ODM) 8.8.1 environment, I saw this: -

...

  [wsadmin] GBRPT0017I: Install resource adapter on the node: Node1 
  [wsadmin] WASX7017E: Exception received while running file "/opt/ibm/WebSphereProfiles/Dmgr01/bin/rules/configureDSRulesNetworkDeployer.py"; exception information: com.ibm.websphere.management.exception.ConfigServiceException
  [wsadmin] javax.management.MBeanException
  [wsadmin] com.ibm.websphere.management.exception.AdminException
  [wsadmin] java.lang.UnsupportedClassVersionError: java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=com/ibm/rules/res/xu/spi/internal/XUResourceAdapter, offset=6

  [wsadmin] Java Result: 105

BUILD SUCCESSFUL
Total time: 2 minutes 14 seconds
...

during the build of the Rule Execution Server (RES) cluster.

This is what I had installed: -

/opt/ibm/InstallationManager/eclipse/tools/imcl listAvailablePackages -repositories /mnt/disk1/WAS,/mnt/disk1/WASJDK7,/mnt/disk2/DecisionServerRules,/mnt/disk2/ProfileTemplateRules

com.ibm.websphere.ND.v85_8.5.5009.20160225_0435
com.ibm.websphere.IBMJAVA.v70_7.0.9030.20160224_1826
com.ibm.websphere.odm.ds.rules.v88_8.8.1000.20160527_0819
com.ibm.websphere.odm.pt.rules.v88_8.8.1000.20160527_0949

and this is how I was creating the cluster: -

export ODM_HOME=/opt/ibm/ODM881/
/opt/ibm/WebSphereProfiles/Dmgr01/bin/configureDSCluster.sh -dmgrAdminUsername wasadmin -dmgrAdminPassword passw0rd -clusterPropertiesFile ~/configureDSCluster.properties -targetNodeName Node1 -dmgrHostName `hostname` -dmgrPort 8879

Thankfully, the internet had the solution: -

Fail to create ODM 8.8 Decision Server Rules with profile template

which said, in part: -

<snip>

The problem occured because profiles are created by default with Java 6 and ODM 8.8 components require Java 7.

To make sure that WAS profiles are created by default with a given version use the managesdk command.

To check the default WAS profile Java version execute:

WAS_HOME/bin/managesdk -getNewProfileDefault

To set the default Java version to 1.7_4 execute:

WAS_HOME/bin/managesdk -setNewProfileDefault -sdkName 1.7_64
</snip>

Once I realised this, I added the following steps to my build: -

Check Default SDK

/opt/ibm/WebSphere/AppServer/bin/managesdk.sh -getNewProfileDefault

CWSDK1007I: New profile creation SDK name: 1.6_64
CWSDK1001I: Successfully performed the requested managesdk task.

Set SDK to 1.7

/opt/ibm/WebSphere/AppServer/bin/managesdk.sh -setNewProfileDefault -sdkName 1.7_64

CWSDK1022I: New profile creation will now use SDK name 1.7_64.
CWSDK1001I: Successfully performed the requested managesdk task.

Check Default SDK

/opt/ibm/WebSphere/AppServer/bin/managesdk.sh -getNewProfileDefault

CWSDK1007I: New profile creation SDK name: 1.7_64
CWSDK1001I: Successfully performed the requested managesdk task.

Once done, my cluster magically created : -

...

  [wsadmin] GBRPT0019I: Start application jrules-ssp on server Node1-DSServer ...
  [wsadmin] GBRPT0019I: Start application jrules-res-management on server RulesMgrSrv ...
  [wsadmin] GBRPC0005I: Invoking synchronization for node Node1 ...
  [wsadmin] GBRPC0013I: Synchronization done.
  [wsadmin] GBRPC0028I: The cluster is up and running!

BUILD SUCCESSFUL
Total time: 5 minutes 24 seconds
...

Pango-WARNING **: failed to choose a font, expect ugly output

I saw this: -

(IBM Installation Manager:105744): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common'

when starting IBM Installation Manager 1.8.6 in GUI mode: -

/opt/ibm/InstallationManager/eclipse/IBMIM 

on a Red Hat Enterprise Linux 7.3 box.

It was easily fixed: -

yum install gtk2 libXtst xorg-x11-fonts-Type1 psmisc

Loaded plugins: langpacks, product-id, rhnplugin, search-disabled-repos, subscription-manager
This system is receiving updates from RHN Classic or Red Hat Satellite.
Package gtk2-2.24.28-8.el7.x86_64 already installed and latest version
Package libXtst-1.2.2-2.1.el7.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package psmisc.x86_64 0:22.20-9.el7 will be updated
---> Package psmisc.x86_64 0:22.20-11.el7 will be an update
---> Package xorg-x11-fonts-Type1.noarch 0:7.5-9.el7 will be installed
--> Processing Dependency: ttmkfdir for package: xorg-x11-fonts-Type1-7.5-9.el7.noarch
--> Processing Dependency: ttmkfdir for package: xorg-x11-fonts-Type1-7.5-9.el7.noarch
--> Processing Dependency: mkfontdir for package: xorg-x11-fonts-Type1-7.5-9.el7.noarch
--> Processing Dependency: mkfontdir for package: xorg-x11-fonts-Type1-7.5-9.el7.noarch
--> Running transaction check
---> Package ttmkfdir.x86_64 0:3.0.9-42.el7 will be installed
---> Package xorg-x11-font-utils.x86_64 1:7.5-20.el7 will be installed
--> Processing Dependency: libXfont.so.1()(64bit) for package: 1:xorg-x11-font-utils-7.5-20.el7.x86_64
--> Running transaction check
---> Package libXfont.x86_64 0:1.5.1-2.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================================================
 Package                                               Arch                                    Version                                          Repository                                             Size
============================================================================================================================================================================================================
Installing:
 xorg-x11-fonts-Type1                                  noarch                                  7.5-9.el7                                        rhel-x86_64-server-7                                  521 k
Updating:
 psmisc                                                x86_64                                  22.20-11.el7                                     rhel-x86_64-server-7                                  141 k
Installing for dependencies:
 libXfont                                              x86_64                                  1.5.1-2.el7                                      rhel-x86_64-server-7                                  150 k
 ttmkfdir                                              x86_64                                  3.0.9-42.el7                                     rhel-x86_64-server-7                                   48 k
 xorg-x11-font-utils                                   x86_64                                  1:7.5-20.el7                                     rhel-x86_64-server-7                                   87 k

Transaction Summary
============================================================================================================================================================================================================
Install  1 Package (+3 Dependent packages)
Upgrade  1 Package

Total download size: 947 k
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for rhel-x86_64-server-7
(1/5): libXfont-1.5.1-2.el7.x86_64.rpm                                                                                                                                               | 150 kB  00:00:00     
(2/5): psmisc-22.20-11.el7.x86_64.rpm                                                                                                                                                | 141 kB  00:00:00     
(3/5): ttmkfdir-3.0.9-42.el7.x86_64.rpm                                                                                                                                              |  48 kB  00:00:00     
(4/5): xorg-x11-font-utils-7.5-20.el7.x86_64.rpm                                                                                                                                     |  87 kB  00:00:00     
(5/5): xorg-x11-fonts-Type1-7.5-9.el7.noarch.rpm                                                                                                                                     | 521 kB  00:00:01     
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                       131 kB/s | 947 kB  00:00:07     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : ttmkfdir-3.0.9-42.el7.x86_64                                                                                                                                                             1/6 
  Installing : libXfont-1.5.1-2.el7.x86_64                                                                                                                                                              2/6 
  Installing : 1:xorg-x11-font-utils-7.5-20.el7.x86_64                                                                                                                                                  3/6 
  Installing : xorg-x11-fonts-Type1-7.5-9.el7.noarch                                                                                                                                                    4/6 
  Updating   : psmisc-22.20-11.el7.x86_64                                                                                                                                                               5/6 
  Cleanup    : psmisc-22.20-9.el7.x86_64                                                                                                                                                                6/6 
  Verifying  : xorg-x11-fonts-Type1-7.5-9.el7.noarch                                                                                                                                                    1/6 
  Verifying  : psmisc-22.20-11.el7.x86_64                                                                                                                                                               2/6 
  Verifying  : libXfont-1.5.1-2.el7.x86_64                                                                                                                                                              3/6 
  Verifying  : ttmkfdir-3.0.9-42.el7.x86_64                                                                                                                                                             4/6 
  Verifying  : 1:xorg-x11-font-utils-7.5-20.el7.x86_64                                                                                                                                                  5/6 
  Verifying  : psmisc-22.20-9.el7.x86_64                                                                                                                                                                6/6 

Installed:
  xorg-x11-fonts-Type1.noarch 0:7.5-9.el7                                                                                                                                                                   

Dependency Installed:
  libXfont.x86_64 0:1.5.1-2.el7                                   ttmkfdir.x86_64 0:3.0.9-42.el7                                   xorg-x11-font-utils.x86_64 1:7.5-20.el7                                  

Updated:
  psmisc.x86_64 0:22.20-11.el7                                                                                                                                                                              

Complete!

thanks to this: -

Preparing Red Hat Enterprise Linux 7 for installation

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: -

https://bpm857.uk.ibm.com:9444/HeritagePortal/Hello.html

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 :-)

Red Hat Enterprise Linux 7 - Driving Network Manager via Command-Line

This is definitely a WIP, and results from my experiences with Red Hat Enterprise Linux 7.3, which does networking subtly differently to older versions of RHEL.

Having restored a VM from an OVA export ( using VMware Fusion on macOS ), I realised that I no longer had any network connectivity, even though the VM configuration hadn't changed.

I saw this from the VM console, whilst logged in as a root.

Firstly I checked the IP stack with ifconfig : -

ifconfig -a

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:50:56:38:a3:ca  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0  KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 4  bytes 340 (340.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 340 (340.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

So I've got an Ethernet interface - ens33 - which has no IP address.

Using Network Manager CLI, I checked the connection: -

nmcli connection

NAME         UUID                                  TYPE            DEVICE 
eno16777736  13756690-ac77-b776-4fc1-f5535cee6f16  802-3-ethernet  

which showed that the internal connection ( eno16777736 ) wasn't mapped to the ens33 interface.

This is easily resolved: -

nmcli connection modify eno16777736 connection.interface-name ens33

where I join the connection to the interface.

Now ifconfig shows a pukka IP address: -

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.153.130  netmask 255.255.255.0  broadcast 192.168.153.255
        inet6 fe80::20c:29ff:fefe:a16a  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:fe:a1:6a  txqueuelen 1000  (Ethernet)
        RX packets 127  bytes 15722 (15.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 11401 (11.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 4  bytes 340 (340.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 340 (340.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The actual IP configuration is, as before, handled via a script: -

/etc/sysconfig/network-scripts/ifcfg-eno16777736

TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="eno16777736"
UUID="28ca0f72-3f90-41d1-a2f7-5ec6ea5fffbc"
DEVICE=ens33
ONBOOT="yes"
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

which shows that the connection is using DHCP.

If I wanted to allocate a static IP address, I'd change the file as follows: -

TYPE="Ethernet"
BOOTPROTO="static"
IPADDR=192.168.153.133
NETMASK=255.255.255.0
GATEWAY=192.168.153.2
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="eno16777736"
UUID="28ca0f72-3f90-41d1-a2f7-5ec6ea5fffbc"
DEVICE=ens33
ONBOOT="yes"
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

and restart the network service: -

service network restart

Restarting network (via systemctl):                        [  OK  ]

we now have this: -

ifconfig ens33

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.153.133  netmask 255.255.255.0  broadcast 192.168.153.255
        inet6 fe80::20c:29ff:fefe:a16a  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:fe:a1:6a  txqueuelen 1000  (Ethernet)
        RX packets 961  bytes 88811 (86.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 539  bytes 75366 (73.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

So, to conclude, we have an interface - ens33 - and a Network Manager connection - eno16777736 - and NMCLI can show the join: -

nmcli connection

NAME         UUID                                  TYPE            DEVICE 
eno16777736  28ca0f72-3f90-41d1-a2f7-5ec6ea5fffbc  802-3-ethernet  ens33  

Thanks to this: -

Interface name changes after update to RHEL 7.3 and network does not start

and this: -

⁠2.3. Using the NetworkManager Command Line Tool, nmcli

for inspiration.

For the record, at some point, I also had to do this: -

Map physical connection to interface

nmcli connection add type ethernet con-name ens33 ifname eth0

but I can't recall precisely how/why I got there, so we'll bank that for now :-)