What is the Best Tool to Replace Ant With?

Posted on: March 30, 2013 | Posted in: Ant, gradle

At this day and age there is no reason to continue using Ant. Ant was a great tool for its time but this time has passed.

There are basically three build tools that can replace Ant: Maven, gradle and Buildr.

It is important to be able to continue using existing Ant scripts and custom tasks alongside the new tool. There is a multitude of useful open-source custom Ant tasks and with Ant being a de-facto standard for years, many development shops built vast libraries of Ant scripts and custom tasks.

Out of all three, Gradle has the best integration with Ant. It allows for using existing custom Ant tasks pretty much without any changes. It also allows for importing Ant scripts into Gradle build script. Gradle tasks can even depend on Ant targets (and vice versa). There is also easy access to Ant properties.


Read the rest of this post »

DataPower Virtual Machines are Coming

Posted on: October 21, 2012 | Posted in: DataPower

IBM recently published a statement of directions to release “virtual editions” of IBM WebSphere DataPower XG45 and XI52. These are probably two the most popular DataPower models.
DataPower functionality (“firmware”) will be implemented as a VMWare VM.

This will greatly simplify use of DataPower for development. For example, development and test instances can be implemented as VMs, whereas production could remain hardware appliance-based.

Hopefully, this will also lead to increased popularity of DataPower platform as it makes it easier for potential customers to try it out (will we see a trial version of DataPower?).

Using Auto-complete in Eclipse Ant Editor for DPBuddy Tasks

Posted on: September 22, 2012 | Posted in: Ant, DataPower, DPBuddy

Many developers utilize Eclipse for editing Ant files. Ant editor in Eclipse is fairly powerful, this article provides a good overview of its capabilities.

One of the most useful features is auto-complete for Ant tasks. Just press Ctrl-space and you’ll see all attributes and nested elements supported by the task.

Auto-complete comes very handy when working with DPBuddy Ant tasks (and for developing WebSphere DataPower-related artifacts in general).

Just type ‘

Unfortunately, auto-complete won’t display help for custom tasks. Apparently description of Ant tasks is embedded inside Eclipse and does not seem to be extendable.

DataPower Buddy 2.3.2 Bug Fix Release

Posted on: May 28, 2012 | Posted in: DataPower, DPBuddy

Release 2.3.2 of dpbuddy fixes a single but significant issue preventing copying files (using dp:copy command) to the hard disk array. RAID is mounted under local: filesystem on the device; the name of the mount point can be found under Administration/Storage Devices/Hard Disk Array in WebGUI.

SOMA “CreateDir” action errors out when it is used to re-create the RAID mount directory. In this release of dpbuddy logic was added to ignore the error.

The updated DPBuddy package can be downloaded from dpbuddy download page.

Security Hardening of WebSphere Application Server Installations

Posted on: October 15, 2011 | Posted in: WebSphere, WebSphere Application Server Administration

It is a known fact that an out of the box WAS installation with security enabled is not entirely secure. There is a number of steps that has to be taken in order to “harden” the installation. Most of the steps are documented in the WebSphere hardening guide, which should be closely studied and followed by any WAS administrator or developer. The hardening guide, however, is a little light on the specifics regarding how to secure WAS at the OS level. For example, hardening should normally include changing file and directory permissions to restrict access to sensitive configuration files.

Why bother hardening the installation at the OS level? This helps defend against external threats, i.e., a server hosting the installation is compromised and against internal threats, i.e., an unauthorized access from inside.

Here are some of the things you can do to secure your installation on a Unix/Linux platform:

Read the rest of this post »

WebSphere Application Server Tutorial and FAQ — WAS in 5 Minutes

Posted on: August 14, 2011 | Posted in: Developer productivity, WebSphere, WebSphere Application Server Administration

If you’re developing applications for WAS and you’re new to it, this is what you need to know:

* What is the default URL of the admin console: https://$hostname:9043/ibm/console.
* What are the default ports: HTTP: 9080, HTTPS: 9443.
* How to locate the logs: Logs can be found under $install_root/profiles/$profile_name/logs/$server_name. The default profile name is AppSrv01 and the default server name is server1. Example:/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1. SystemOut.log is the file containing everything that was logged to standard out. Logs can also be viewed from the admin console by navigating to Troubleshooting/Logging and Tracing/server_name/Runtime.
* How to start/stop a server: If you’re dealing with a “Network Deployment” type of installation (multiple application servers running under the control of the “deployment manager”), your can start/stop a server from the console (Server/Server Types/WebSphere application servers). Otherwise you have to do it from command line. Go to install_root/bin and run ./startServer.sh server_name, e.g., ./startServer.sh server1 (this assumes that your installation has only one profile defined, otherwise you may need to “cd” to the profile_name/bin directory). Make sure that you run all commands using the appropriate system account. To stop the server, run ./stopServer.sh server_name -username user_name -password password. user_name and password is the credentials of an admin account, typically the same one you use to login to the console.
* How to deploy an application: In admin console, navigate to Applications/Application Types/WebSphere enterprise applications, click on “Install new application”, select “Fast path”, accept all the defaults except that on “step 2” make sure that you targeted correct servers (if you have multiple servers/clusters in your environment). Note that you can deploy a WAR file directly, you don’t have to build an EAR. In this case, make sure that you set a context root on “step 4” screen of the wizard.
* How to change context root of a Web application: Go to Applications/Application Types/WebSphere enterprise applications/application_name/Context Root For Web Modules in the console. Re-start the application after the change.
* How to change the order of classloaders: If you’re getting a ClassNotFoundException when you’re starting the app, changing the order of classloaders is the first thing you may want to try. Go to Applications/Application Types/WebSphere enterprise applications/application_name/Manage Modules/module_name and make the appropriate selection in the “Class loader order” drop-down (this assumes you’re doing it for a WAR module).
* How to enable dynamic class reloading: If you need to frequently update your deployed application (e.g., you use a local WAS installation for development), enabling dynamic reloading could be a huge time saver. Go to your application in the console, “Class loading and update detection”, set “Override class reloading settings …” and set polling interval to 2 seconds. See this post for more details on how to configure your development environment to support class reloading.
* How to find a host name and a port of the server: Go to Server/Server Types/WebSphere application servers. You’ll find the host name in the Host Name column. To find a port, click on your server, and expand Ports. WC_defaulthost is the HTTP port and WC_defaulthost_secure is the HTTPS port.
* How to kill a JVM: If the normal “stop” routine failed to stop the server in a reasonable amount of time, you may need to kill it. In a “Network Deployment” environment, simply navigate to the list of servers, select the server and click “Terminate”. A node agent will kill the JVM for you. To achieve the same from command line (the only option if you’re running standalone), cd to install_root/profiles/profile_name/logs/server_name, and kill the process ID contained in the file server_name.pid. On Unix, you can simply do kill -9 `cat server1.pid` (assuming server1 is your server name). Use task manager or taskkill /PID on Windows.
* How to browse JMS messages: Go to Buses/Your bus name/Destinations/Your destination/Queue points/Your queue point/Runtime/Messages.
* Where to find configuration files: WAS has many configuration files, most of them are in XML/XMI format. The files are located under $install_root/profiles/$profile_name/config/cells/$cell_name.

This post is part of the series on WebSphere Application Server administration. Please subscribe to our blog if you’d like to receive updates.

We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.

Keeping Multiple DataPower Devices in Sync

Posted on: August 9, 2011 | Posted in: DataPower, DPBuddy

Most DataPower installations in production contain two DataPower devices with identical or similar configuration.
It is actually quite easy to keep the two devices in sync using Apache Ant and DPBuddy administration tool.
DPBuddy supports a notion of an environment prefix. The prefix groups together connectivity properties for each device:

dp.username=dpbuddy
dp.password=123 
dp.domain=deployTest
prod1.dp.xmlmgm.url=https://dp1.prod
prod2.dp.xmlmgm.url=https://dp2.prod


The above property list defines dp.username, dp.password and dp.domain properties that are common to all environments and two XML management URLs for our DataPower cluster.

Then the Ant target for importing configuration into both devices could look like this:


Note that for speed we chose to execute both imports in parallel; it is perfectly save to do it with dpbuddy as all of its tasks are thread-safe.

If your “dp:import” tasks is more complex (e.g. because of use of deployment policies), you may want to create an Ant macro for each task to avoid duplicating parameters.

MyArch, Inc. offers paid support for dpbuddy, including implementing custom enhancements. If you’re interested, please contact us as info at myarch.com.

Message Acknowledgement or Transacted Session?

Posted on: May 30, 2011 | Posted in: Java EE, JMS

JMS is one of the oldest Java EE specifications (JMS 1.0 specification is dated 11/1999), however, questions about the difference between message acknowledgement and transacted session still come up. The difference is especially subtle when programmatic client acknowledgement (Session.CLIENT_ACKNOWLEDGE) is used since Message.acknowledge() and Session.recover() are similar to Session.commit() and Session.rollback(). So how are these APIs different?

The bottom line is that there is no difference if you deal only with a single resource (Queue or Topic) within a session. If all you do is consuming messages from a single queue, it does not matter whether you use acknowledgements or transacted sessions (although in my opinion it is more intuitive to use Session.commit/rollback). Session.commit() invokes Message.acknowledge() under the covers and Session.rollback() invokes recover().

However, if you’re dealing with multiple JMS resources withing the same session (or multiple consumers/producers), the transacted session mechanism is what you want to use. For example, you may consume messages from one queue and then put messages on a different queue using the same JMS session. The transacted session will treat all consumed and produced messages as part of a single transaction and will commit or rollback all messages at once. Message acknowledgement on a non-transacted session will “commit” consumed messages independently of the produced ones.

Transacted sessions are limited to JMS resources; container-managed transactions and JTA is required to managed JMS and non-JMS resources (e.g., getting a message from a queue and updating a database).

As a summary, the different mechanisms discussed here differ in terms of the types of resources managed as part of transactions:

* Message acknowledgement: messages consumed from a single destination.
* Transacted session: multiple JMS resources within the same JMS session.
* Container-managed transactions: multiple JMS and non-JMS resources.

For a more in-depth discussion of different transaction mechanisms, refer to this article.

Note: We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.

Tips for Developing JMS Client for WebSphere Application Server

Posted on: May 22, 2011 | Posted in: Java EE, WebSphere, WebSphere Application Server Administration

Following are some tips for developing a JMS client for WAS.

* First, we need to put the right jar files on the client’s classpath. Following jars are required: com.ibm.ws.sib.client.thin.jms_<WAS version>.jar, com.ibm.ws.ejb.thinclient_<WAS version>.jar. If you’re using Oracle/Sun JDK, you’ll also need com.ibm.ws.orb_<WAS version>.jar as IBM libraries rely on IBM ORB implementation. IBM JDK has it built-in but Oracle’s obviously does not. These jars are available from the “runtimes” directory of your WAS installation. It is a good idea to make sure that the version of your client jars matches the version of your target WAS installation, including the fixpack level. You may want to update your client jars every time a new fixpack is installed.

* If you’re not using DNS, you’ll need to add the host name of the WAS server to the host file on your client machine, otherwise you’re bound to get a cryptic ORB error message. You can find WAS host name by going to Server/Server types/ WebSphere Application Servers in admin console.
By the way, most ORB error messages are cryptic; it is very rare to see the root cause of the problem in the message. The way to deal with it is to enable ORB tracing. Add -Dcom.ibm.CORBA.Debug=true to your JDK parameters; other debug/tracing parameters are explained here.

* Another frequent source of errors is a missing bootstrap property in the connection factory configuration. It is specified in the “provider endpoint” field and has a form of <host>:<SIB_Port>:BootstrapBasicMessaging. If this is not provided, WAS will attempt to bootstrap the messaging engine using localhost.

* Most JMS examples use JNDI lookup in order to get a queue object. It is more efficient to use session.crerateQueue() method. Note that in this case you need to provide the name of the JMS destination as opposed to the queue JNDI name. This is the “Queue name” parameter on the queue configuration screen in WAS admin console.

* Finally, not all developers are aware that WAS admin console has a built-in JMS queue/topic browser. It takes a few steps to get to it from the console: Buses/Your bus name/Destinations/Your destination/Queue points/Your queue point/Runtime/Messages.

Note: We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.

DPBuddy — Tool For DataPower Administrators and Developers

Posted on: August 28, 2010 | Posted in: Building software, DataPower, DPBuddy, IT operations, XML Appliances

We’re pleased to announce the release of our new product, DataPower Buddy (dpbuddy). “dpbuddy” a free command-line tool for automating administration, management and deployment of IBM WebSphere DataPower appliances. The tool supports export/import, file transfer, backups and many other functions.

dpbuddy is implemented as a set of custom tasks for the popular build tool, Apache Ant.

Here is a quick example of dpbuddy in action:

This Ant task will remove remote directories if they exist, reproduce the local directory tree (all folders under “services”) on the device and upload the necessary files based on the “includes” pattern.

dpbuddy is completely free; it can be downloaded from the dpbuddy product page

dpbuddy provides many cool features, including:

* Response from the device is presented in a human-readable form as opposed to raw SOAP/XML messages. dpbuddy makes it easy to understand error and status messages.

* Powerful remote “copy” command that automatically reproduces local directory tree on the device.

* Tight integration with Ant. Ant variables can be used inside deployment policies and configuration files.

* Easy-to-use alternative to deployment policies based on XPath.

* Ability to remotely “tail” device logs. It is even possible to automatically get new log messages similarly to Unix “tail -f” command. “tail” task can also check for error patterns.

* “Export” based on naming patterns. You don’t need to know types (“classes”) of DataPower objects; simply specify a regexp pattern and dpbuddy will export all objects matching this pattern.

* Support for self-signed certificates. No need to add DataPower certificates to the JDK store.

* Support for arbitrary SOMA requests. You can use Ant variables inside a request.

* Parsing of all commands on the client. In case of XML errors, DataPower returns cryptic “internal error” message. The actual error then has to be extracted from the device logs. dpbuddy on the other hand validates management XML commands on the client and displays error messages right away.

Go to dpbuddy product page to learn more.