Where in the world is com.ibm.ws.scripting.adminCommand.AdminTask?

Question

Frustrated with the damn awful API provided by WebSphere Admin Server, I'm writing my own Java DSL wrapper. My jython files now simply read:

from my.package import MyDSL
config = MyDSL(AdminConfig, AdminTask)
config.goGoGadgetSkates() # or something like that

The essential part is that I send through the (#%$$!@#) god objects AdminConfig and AdminTask so that the DSL can use them to perform operations in WAS.

In order to compile the DSL I need to include the class files for this two objects. I find them by first setting the constructor as:

public MyDSL(Object a, Object b) {
    System.out.println(a.getClass());
    System.out.println(b.getClass());
}

The output showed that the AdminConfig object is an instance of com.ibm.ws.scripting.AdminConfigClient. I easily located the jar that contains this class and all is well.

But AdminTask is an instance of com.ibm.ws.scripting.adminCommand.AdminTask. Despite being present at runtime, this class does not exist anywhere in my classpath or indeed anywhere on my computer's hard drive.

I can only assume com.ibm.ws.scripting.adminCommand.AdminTask is constructed magically by WSAdmin in the jython layer. Perhaps it is defined as a python class?

Before I resort to reflection, can someone please explain where com.ibm.ws.scripting.adminCommand.AdminTask might live and how I might extract a copy of the class file?

Homicide

Very interesting. I can confirm that with a test JSP to locate classes on the WAS runtime classpath, the former is found but the latter is not. (ibm.com/developerworks/mydeveloperworks/blogs/Dougclectica/… ) – Pedo

This may help you search: I am not sure that the WAS classpath and that WASadmin's classpath are identical or that they should be. Anyway, when you have a brand new WebSphere profile, and you start the wsadmin.sh (or .bat) you can see a list of jars it uses. They maybe able to help you. – Bullpen

google told me, it's not of our world. – Americaamerican

Answer 1

The AdminConfigClient class is not API/SPI, so you are creating a fragile infrastructure by relying on that class. The API/SPI entry point is ConfigServiceFactory.

The AdminTask object is backed by the data in CommandMgr. It should be possible to use CommandMgr to do anything you can do with AdminTask.

Einhorn