​Hello,
Hopefully I'm putting this in the correct forum...

We've done some tidy-up of snapshots in our BAW Process Center but now when we deploy to our System Test server the deploys are failing due to a 'duplicate' snapshot for one of the Toolkits.

I have run the REST call to get the list of the snapshots on the Process Server and I can see it in there but it is still showing as Active (even though it is no longer in use).  I want to use the wsadmin scripting tool to disable it so I can remove it with the Delete Snapshot API, however when starting up the wsadmin tool it just pauses for a moment and then terminates.

I've manually stepped through what the wsadmin.bat file is doing and it is failing when it tries to executing this line:

"C:\IBM\WebSphere\APPserver\java_1.8_64\bin\java" -Djava.endorsed.dirs="C:\IBM\WebSphere\APPserver\endorsed_apis;C:\IBM\WebSphere\APPserver\java_1.8_64\jre\lib\endorsed" -Dcmd.properties.file="C:\IBM\WebSphere\APPserver\profiles\Node1\temp\wsadmin.30014\wsadmin.properties" -Xms256m -Xmx256m -Xquickstart -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true   "-Dcom.ibm.SOAP.ConfigURL=file:C:\IBM\WebSphere\APPserver\profiles\Node1/properties/soap.client.props" "-Djava.security.auth.login.config=C:\IBM\WebSphere\APPserver\profiles\Node1/properties/wsjaas_client.conf" "-Dcom.ibm.CORBA.ConfigURL=file:C:\IBM\WebSphere\APPserver\profiles\Node1/properties/sas.client.props" "-Dcom.ibm.SSL.ConfigURL=file:C:\IBM\WebSphere\APPserver\profiles\Node1/properties/ssl.client.props"   "-Duser.install.root=C:\IBM\WebSphere\APPserver\profiles\Node1" "-Dwas.install.root=C:\IBM\WebSphere\APPserver"  com.ibm.wsspi.bootstrap.WSPreLauncher -nosplash -application com.ibm.ws.bootstrap.WSLauncher com.ibm.ws.admin.services.WsAdmin

If I try and run this line in isolation from a Command Prompt (from the \APPServer\bin folder) I get this error:

Cound not find or load main class com.ibm.wsspi.bootstrap.WSPreLauncher

and it returns code 15.

Could we be missing some class files from our WAS installation?  I've no idea where to look to see if they are missing or where to find them if they are.

Any help would be greatly appreciated.

EDIT:  We are running BAW 19.0.0.1, if that helps or makes a difference.  I have searched through countless .jar files and can find com.ibm.ws.bootstrap.WSLauncher, but no sign of the PreLauncher anywhere.

Many thanks


------------------------------
Grant Pozzana
------------------------------
​

The problem you describe sounds like a "toolkit spiral".  This will only block you in IBM BPM Advanced.  In "Standard" the check doesn't happen, but a spiral is still a latent bug waiting to happen.

A toolkit "spiral" can happen when 2 toolkits either directly or indirectly depend on one another.  Let's assume that my Process App has 2 toolkits - TKA and TKB.  These Toolkits each have snapshots, that for simplicity are simply numbered, with a higher number being a more recent snapshot.  When we first start out our PA and each toolkit point to snapshot "1" of both toolkits.  So PA points to TKA.1 and TKB.1.  Since TKA and TKB each use things in the other's toolkit we also have TKA.1 pointing to TKB.1 and TKB.1 pointing to TKA.1.

Right now everyone is happy and we can deploy.

Later on we need to make a fix in TKA.  This creates TKA.2 snapshot.  We upgrade the PA to point to this.  So now, PA points to TKA.2 and TKB.1.  Also TKA.2 points to TKB.1.  But remember TKB.1 points to TKA.1.  This is a spiral.  We cannot deploy this application in an Advanced server because Advanced will not allow us to have 2 different snapshots of the same TK in a single execution tree.  Since there are 2 snapshots of TKA in the export the deploy will fail.

Note - These problems are not only just spirals.  You could have in the above a TKC that TKA and TKB depend on.  They both start out pointing at TKC.1.  And we can deploy like before.  But when TKA created snapshot 2, one of the dev's noticed that TKC.2 now existed and upgraded the dependency (assuming this was the right thing to do).  Since TKB was not touched, it still points to TKC.1.  So now both snapshots are in the export and the deploy will fail.

If you want to figure out if you have this problem, BP3's static code analysis tool for IBM BPM will show you the problem visually for free.  You can create an account by the site.  If you upload your TWX file and click on the name of the Process app (not the score) it will take to you a screen that shows if there are toolkit conflicts in the export.

The screen looks like this -


------------------------------
Andrew Paier
------------------------------

Hi Andrew,

Many thanks for the response - yes that is ​exactly what had happened!  I went through all our Toolkits from the bottom up and re-versioned them with new unique snapshot names and we are now able to deploy the Process App that was previously failing.

I am still unable to get the wsadmin scripting tool started up though (still giving the same error with the missing com.ibm.wsspi.bootstrap.WSPreLauncher class), which means we have a large number of Toolkit snapshots in our System Test environment that are not in use but can't be deleted as they are still showing as 'Active'.

Is there something that needs adding/installing in WebSphere to allow us to use this?  All the documentation I can find on it just says to run the relevant batch file and the scripting console will fire up, but it's not doing anything.

Many thanks,​

------------------------------
Grant Pozzana
------------------------------

Original Message:
Sent: Mon January 06, 2020 05:18 PM
From: Andrew Paier
Subject: Unable to start wsadmin scripting tool

The problem you describe sounds like a "toolkit spiral".  This will only block you in IBM BPM Advanced.  In "Standard" the check doesn't happen, but a spiral is still a latent bug waiting to happen.

A toolkit "spiral" can happen when 2 toolkits either directly or indirectly depend on one another.  Let's assume that my Process App has 2 toolkits - TKA and TKB.  These Toolkits each have snapshots, that for simplicity are simply numbered, with a higher number being a more recent snapshot.  When we first start out our PA and each toolkit point to snapshot "1" of both toolkits.  So PA points to TKA.1 and TKB.1.  Since TKA and TKB each use things in the other's toolkit we also have TKA.1 pointing to TKB.1 and TKB.1 pointing to TKA.1.

Right now everyone is happy and we can deploy.

Later on we need to make a fix in TKA.  This creates TKA.2 snapshot.  We upgrade the PA to point to this.  So now, PA points to TKA.2 and TKB.1.  Also TKA.2 points to TKB.1.  But remember TKB.1 points to TKA.1.  This is a spiral.  We cannot deploy this application in an Advanced server because Advanced will not allow us to have 2 different snapshots of the same TK in a single execution tree.  Since there are 2 snapshots of TKA in the export the deploy will fail.

Note - These problems are not only just spirals.  You could have in the above a TKC that TKA and TKB depend on.  They both start out pointing at TKC.1.  And we can deploy like before.  But when TKA created snapshot 2, one of the dev's noticed that TKC.2 now existed and upgraded the dependency (assuming this was the right thing to do).  Since TKB was not touched, it still points to TKC.1.  So now both snapshots are in the export and the deploy will fail.

If you want to figure out if you have this problem, BP3's static code analysis tool for IBM BPM will show you the problem visually for free.  You can create an account by the site.  If you upload your TWX file and click on the name of the Process app (not the score) it will take to you a screen that shows if there are toolkit conflicts in the export.

The screen looks like this -

And the toolkit list will have red lines linking conflicting toolkit versions in the tree if they exist.

------------------------------
Andrew Paier
------------------------------