Links to IBM WebSphere Application Server Documentations

In spite of Google’s power, finding information about WebSphere is still a chore. I can’t really blame Google because IBM WebSphere documentation is huge.

Until search results get better or I figure out how to find things faster on the IBM site directly, I am organizing my bookmarks here so that I can immediately refer to documentations I always use.

  1. WebSphere Application Server, Version 6.1 Information Center – Everything should be under here about WebSphere Application Server.
  2. IBM WebSphere Application Server, Release 6 API Specification – Javadoc to all Websphere APIs. This is under the Infocenter documentation but this will save you the trouble of searching where the Javadocs of the API reside.
  3. WebSphere Application Server Release 6.1 Public MBean Interfaces – Javadoc to WebSphere MBeans.
  4. WebSphere Extended Deployment (XD) Release 6.1 Public JMX MBean Interfaces
  5. Server Configuration Interfaces
  6. WebSphere Configuration Documentation – Documentation to WebSphere’s XML files
  7. WSADMIN Scripting
Advertisements

WebSphere Administrative Objects Not Accessible from Imported Jython Modules

In Websphere Jython (as of WAS6.1), the administrative objects are not automatically accessible from imported modules, unlike when you call them from your main script. It is also not possible to import them either since they are not defined in sys.modules.

“myModule.py”

print AdminConfig.types()

For example, the code above will break if this Jython module is imported from the main script or another module. If this is executed as the main script it would work right off the bat even without importing anything.

To fix this problem, you need to add the administrative objects to the “sys.modules” dictionary in the main script so that they will be visible to all imported modules. Once the administrative objects are available in “sys.modules”, your imported modules can then call the import command for those object to access them.

For example, in your main script, you need to construct the lines shown below before you can import any modules that will require access to the WebSphere administrative objects:

“myMain.py”

    import sys
    sys.modules['AdminConfig'] = AdminConfig
    sys.modules['AdminControl'] = AdminControl
    sys.modules['AdminApp'] = AdminApp
    sys.modules['AdminTask'] = AdminTask
    sys.modules['Help'] = Help

    # now you can import your module
    import myModule

Your imported modules can then call the import command to access these objects. The module below shows import commands for each WebSphere Administrative object.

“myModule.py”

    try:
        import AdminConfig
        import AdminControl
        import AdminApp
        import AdminTask
        import Help
    except:
        pass

    # this works now even if this module is imported
    print AdminConfig.types()

The try-except clause above is used to prevent the module from failing if you tried to run this as your main script. If you tried to run this in your main wsadmin script and the sys.modules were not set, this would simply ignore the exceptions and should be able to proceed to run any administrative commands directly.

I hope someday IBM will fix this problem by simply adding the administrative objects to the sys.modules by default so that we won’t need to do this ourselves.

Websphere’s Implementation of Jython (wsadmin) Broke __name__

Jython in IBM Websphere does not implement the global variable “__name__” the same way CPython or the official Jython does. Instead of setting it to “__main__” (if the module is not imported), it sets it to “main”.

For example, if you have this code to check if the script is being imported or not,

if __name__ == '__main__':
    run_method()

you have to write it differently with WebSphere Jython like this:

if __name__ == 'main':
    run_method()

It’s not a big deal, you’d say. Just check for both values if you are concerned about portability:

if __name__ == '__main__' or __name__ == 'main':
    run_method()

Unfortunately, that is not the only problem. There are libraries out there that use __main__. One example is unittest.main(). This method doesn’t work with Websphere Jython (WASv61). IBM ships this unittest module with Websphere v6.1, however, the unittest.main() method doesn’t work. Actually, the primary culprit is that Websphere’s Jython doesn’t implement the __main__ module.

As a workaround to this problem, don’t use unittest.main(). Instead, use the methods TestSuite() and TextTestRunner(). For example, instead of the usual way of writing your test class like this:

if __name__ == '__main__':
    unittest.main()

write it this way with Websphere Jython:

if __name__ == '__main__' or __name__ == 'main':
    suite = unittest.TestSuite()
    suite.addTest(unittest.makeSuite(TestMyJythonClass))
    unittest.TextTestRunner().run(suite)

Dynamically Including JavaScript and CSS Files

In C/C++, if you want to include code from another file, you use the #include directive. In PHP, you use the require or include command. In Java and Python, you use the import command to import a library. In Perl, you use the require or use command. However in JavaScript, for some reason, it doesn’t have this functionality. :(

What is expected in JavaScript is that you do the includes externally on the HTML page using the script-src tag. But there are many limitations with this option. Wouldn’t it be nice if you can simply perform includes just like you do it in other languages?

Fortunately, there is a workaround!

What you do is dynamically create the script tag element at runtime in the DOM. Below is a JavaScript function where you simply call whenever you need to include a JavaScript src file.

function includeJavascript(src) {
    if (document.createElement && document.getElementsByTagName) {
        var head_tag = document.getElementsByTagName('head')[0];
        var script_tag = document.createElement('script');
        script_tag.setAttribute('type', 'text/javascript');
        script_tag.setAttribute('src', src);
        head_tag.appendChild(script_tag);
    }
}
// Include javascript src file
includeJavascript("http://www.mydomain.com/script/mynewscript.js");

The idea behind this is that a new script-src tag is dynamically constructed in the DOM at runtime. It will be like adding this line to the <head> section of the web page but dynamically:

<script type="text/javascript"
   src="http://www.mydomain.com/script/mynewscript.js">
</script>

The same idea can be applied to CSS files. Below is a function where you can include CSS files programmatically.

function includeCSSfile(href) {
    var head_node = document.getElementsByTagName('head')[0];
    var link_tag = document.createElement('link');
    link_tag.setAttribute('rel', 'stylesheet');
    link_tag.setAttribute('type', 'text/css');
    link_tag.setAttribute('href', href);
    head_node.appendChild(link_tag);
}