We’re pleased to announce the availability of DataPower Buddy 3.4.
This release provides support for DataPower firmware upgrades, extensive configuration reporting and diffing, DataPower operational analytics and many other features.
Please see release notes for more information.
Download PBuddy 3.4 from this page and follow our Quick Start Guide.
We’re pleased to announce the availability of DataPower Buddy 3.3.
We’re pleased to announce that DataPower Buddy 3.2.4 is now available. The focus of this release is on improved audit and logging.
DPBuddy now generates an audit log file in JSON format, in addition to the XML format supported in earlier releases. This file can be easily tailed, analyzed with jq and/or uploaded to an enterprise SIEM tool. DPBuddy now uses logback framework for auditing and logging. This provides a lot of flexibility in configuring log file location, rollover policies, appenders and other parameters.
Other new features include:
To upgrade to this release, you can simply download and un-archive the distribution and point your DPBUDDY_HOME environment variable to the new location. If you’re using DPBuddy from Apache Ant, you will also need to add <pathelement location=”${dpbuddy.home}/conf”/> to the DPBuddy library’s “taskdef” in your Ant files, otherwise, you will see verbose logging output in the console.
You can download DPBuddy 3.2.4 from this page.
We're pleased to announce that DPBuddy 3.2-beta is now available. The main feature of this release is the ability to execute any DPBuddy task or command against multiple devices and/or domains. Simply define the URLs of your devices using environment properties and supply a list of environment prefixes to a command or an Ant task:
dpbuddy import -file services.zip -env "dev,test"
DPBuddy will execute the command against all the devices in the list, and, in case of any errors, it would optionally rollback either just the failed domains or all the devices/domains in the list.
You can find more details in the DPBuddy documentation.
Other new features include:
The release also contains several important bug fixes.
The general availability of DPBuddy 3.2 is expected in January 2015. Meanwhile, please let us know if you're interested in becoming part of our beta program.
If you’re using Eclipse for developing IBM WebSphere DataPower artifacts (xslt, schemas, etc.) you can easily configure DPBuddy to automatically copy your artifacts to the appliance and do various other chores. All you need to do is to define an Ant file with DPBuddy tasks and configure the Ant file as a builder for your project.
You can find the detailed steps for configuring Eclipse and DPBuddy here.
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.
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.2.2 is available from this link. This release contains several bug fixes, mostly around “import” Ant task.
MyArch, Inc. offers paid support for dpbuddy, including implementing custom enhancements. If you’re interested, please contact us as info at myarch.com.
PAnt 2.0.1 contains an important bug fix that was preventing using certain Ant tasks from python. Specifically, the bug affected all tasks that utilize “addConfigured”:http://ant.apache.org/manual/develop.html method to handle nested elements. This included the “manifest” task and several others.
You can download PAnt 2.0.1 from the “PAnt project page”:/pant
We’ve just updated PAnt documentation to reflect changes implemented in PAnt 2.0. There are two significat changes:
* Support for Ant targets.
* PAnt is now bundled with Ant Jython tasks that previously were available separately.
You can follow this guide to get started with PAnt.
We’ve just released a new version of PAnt, a tool for developing build scripts in python. The key new feature of PAnt 2.0 is the ability to create Ant targets directly from python. This allows for completely getting rid of Ant XML files and for developing build scripts entirely in Python.
Here is an example:
@target(unless=”prop.name”, depends=ptarget1)
def p_target2():
“””Python project ptarget2″””
ant.echo(“echo ptarget2”)
You can find more details about creating targets from PAnt here.
This is a major update to our popular python Ant wrapper.
Notable changes in this release:
* Support for positional (as opposed to named) arguments, e.g., “pant.echo(‘message’)”.
* Support for lists to express repeating elements.
* Support for “ant_” prefix to avoid conflicts with python keywords.
More information is available from PAnt project page
Please subscribe to our feed or follow us on twitter to continue receiving updates about PAnt – new version is coming shortly.
Ant uses reflection to pass data from XML to the Java class that implement an Ant task. For every attribute in XML, you have to define a setter in the Java task’s class.
This works fine most of the time, however, in some cases there could be a need for a dynamic list of attributes. For example a task can pass attribute values to some external tool that has its own set of parameters that you don’t want to hardcode in Ant. Or you may simply like the flexibility of using dynamic attributes as opposed to predefined setters.
In order to implement dynamic attributes, first you need to override “maybeConfigure” method in your Ant task and have it do nothing:
public void maybeConfigure() throws BuildException {
}
Then in your “execute” method you can access the map of attributes (that represents all attributes set in XML) as follows:
RuntimeConfigurable configurator= getRuntimeConfigurableWrapper();
Map attributes=configurator.getAttributeMap();
String attr1=(String)attributes.get("attr1");
Note that in this case Ant does not do property substitution (for ${}), so you would need to explicitly invoke project.replaceProperties for each attribute value.
In one of the previous posts I “complained”:/was-70-is-still-on-jython-21 that wsadmin tool (which is the main WebSphere Application Server administration tool) still relies on Jython 2.1, which is quite old.
The issue became critical when I realized that jython automatically re-compiles classes compiled with a different jython version. In my case, I was using Jython 2.2 for my Ant scripts and Jython 2.1 for wsadmin scripts. Some of the code was shared. This led to the situation of concurrent builds stepping on each other by dynamically re-compiling classes with different jython versions. The error looked something like that:
File "", line 5, in ?
java.lang.ArrayIndexOutOfBoundsException: -4
at org.python.core.imp.createFromPyClass(Unknown Source)
Bugs like that are always fun to troubleshoot.
Going back to 2.1 was not an option for me since I use closures and “new classes” in quite a few places. So I tried putting jython 2.2.1 on wsadmin classpath and it worked without a hitch with “thin wsadmin client”:/wsadmin-thin-client. All my of wsadmin scripts work without a problem.
Here is a “sample wsadmin.bat file”:/files/wsadmin/wsadmin_thin.bat that I use. This file utilizes thin client jars. Note how in line 85 my jython.jar (which is jython 2.2.1) is added to the classpath so it would override jython packages supplied with WAS.
One possible downside of this approach is running into issues with IBM support in case if you need to open a PMR related to wsadmin scripting.
I’ve updated Ant Jython task with a number of new features:
* Jython path is now handled by a separate JythonPath task.
* Jython interpreter is now scoped to Ant project. This means that you can have multiple Jython calls withing the same project that share common imports and variables.
* Jython task now supports nested text, similar to the “script” task.