Monday, June 24, 2013

How to manage Maven third party jars

How to manage Maven third party jars

When you find yourself the need to load third party jars into Maven repository, there are few steps you normally do to test it out. You first install them locally into $HOME/.m2/repository, and then create your project pom that list those dependency. When things look good, then you deploy into your own hosted repository. The following scripts will help you perform these tasks.

If you have lot’s of jars under a group, it’s more conveninent to create an extra pom that list these dependency and install/deploy it into the repository as well. And then your project would only need to include one dependency with <type>pom</type>.
#!/usr/bin/env bash
# Install local jar files into Maven repository. The artifact name would be same
# as the filename minus the extension.
# :Author: Zemian Deng
# :Date: 2013/06/17
# Usage:
#   # Print as maven dependency used in pom file
# mygroup 1.0.0 lib/*.jar
#   # Install jar files into local maven repo
#   RUN_TYPE=install mygroup 1.0.0 lib/*.jar
#   # Deploy jar files into remote maven repo
#   export REPO_URL=http://localhost/nexus/content/repositories/thirdparty
#   RUN_TYPE=deploy mygroup 1.0.0 lib/*.jar

# Capture command arguments and options
if [[ "$GROUP" == "" || "$VERSION" == "" || "$FILES" == "" ]]; then
 printf "ERROR: invalid arguments: GROUP VERSION FILES...\n"
 exit 1

RUN_TYPE=${RUN_TYPE:="print"} # values: print|install|deploy
REPO_ID=${REPO_ID:="nexus-server"} # Id defined in user's settings.xml for authentication

# For each file, perform action based on run type.
for FILE in $FILES; do
 ARTIFACT=`basename $FILE '.jar'`
 if [[ "$RUN_TYPE" == "deploy" ]]; then
  printf "Deploying file=$FILE as artifact=$ARTIFACT to repo=$REPO_URL\n"
  mvn deploy:deploy-file \
   -DrepositoryId=$REPO_ID -Durl=$REPO_URL \
   -DgroupId=$GROUP -DartifactId=$ARTIFACT -Dversion=$VERSION -Dpackaging=jar \
 elif [[ "$RUN_TYPE" == "install" ]]; then
  printf "Installing file=$FILE as artifact=$ARTIFACT\n"
  mvn install:install-file \
   -DgroupId=$GROUP -DartifactId=$ARTIFACT -Dversion=$VERSION -Dpackaging=jar \
 elif [[ "$RUN_TYPE" == "print" ]]; then
  printf "        <dependency>\n"
  printf "            <groupId>$GROUP</groupId>\n"
  printf "            <artifactId>$ARTIFACT</artifactId>\n"
  printf "            <version>$VERSION</version>\n"
  printf "        </dependency>\n"

Tuesday, June 18, 2013

How to zip up a release from a hg repository

How to zip up a release from a hg repository

Did you know hg archive command can quickly zip up your project by given a revision or release name? This is very handy to package up a distribution and share with other who is refusing to use the same client.

I wrote a simple bash script to do this with couple extras. It will create a zip file with a nice basename so it’s easy for unzipping. It also auto generate and append the given revision or tag name into the RELEASE.txt file, so you know what’s been released.

Just add the following file into any root of your hg based project’s bin directory and it’s ready to use.

This script will not tag your repository. It assumed you already have tagged. It simply will package up a release into a nice little zip file.
#!/usr/bin/env bash
# Package a release or snapshot from Hg repository for distribution.
# :Author: Zemian Deng
# :Date: 2013/02/01
# Usage example:
#   # release a specific tag
#   cd /path/to/project
#   bin/ 1.0.1
#   # release a snapshot
#   bin/

# Command line arguments and options
# Assume this script is in bin, which one directory up.
APP_HOME=`cd $(dirname $0)/.. && pwd`
if [[ `command -v realpath` != "" ]]; then
	# resolve symbolic link if possible.
    APP_HOME=`realpath $APP_HOME`
HG_REVISION=`hg id -i`
if [[ "$REL_VERSION" == "" ]]; then

# Generate the zip package
printf "Generating $REL_NAME in directory=`pwd`\n"
mkdir -p $REL_DIR

# Auto append revision id to release file.
if [[ -e $APP_HOME/RELEASE.txt ]]; then
printf "$REL_NAME revsion=$HG_REVISION date=`date`\n" >> $REL_DIR/RELEASE.txt

# Clean up the tmp rel dir.
rm -r $REL_DIR

printf "$REL_ZIPFILE created.\n"

Saturday, June 15, 2013

How to install awestruct on Cygwin

How to install <code>awestruct</code> on Cygwin

How to install awestruct on Cygwin

I tried installing awestruct on Cygwin today, but it failed with following:

gem install awestruct
Building native extensions.  This could take a while...
ERROR:  Error installing awestruct:
        ERROR: Failed to build gem native extension.

        /usr/bin/ruby.exe extconf.rb
checking for libxml/parser.h... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

I am running Windows 7 with Cygwin 1.7.20 and ruby 1.9.3p392

After looking at the log and googling around, I've found that the awestruct depends on nokogiri, and in turns depends on libxslt, libxslt and iconv native lib. I have the last three already installed in Cygwin with default paths, but the problem is they are installed under /usr and not /usr/local. Because of this, I have to install the awestruct with extra parameters like this:

gem install awestruct -- --with-xml2-include=/usr/include/libxml2 \
                        --with-xml2-lib=/usr/lib \
                        --with-xslt-dir=/usr/include/libxslt \
                        --with-iconv-include=/usr/include \

Now I am awestruct!

Wednesday, June 12, 2013

Taming the JMX on WebLogic Server

Taming the JMX on WebLogic Server

Let assume couple things first:

1) I assume you have heard of Java’s JMX features and familiar what it does (expose and manage your service remotely). You ought to know that default JVM will have a Platform MBeanServer instance that you can register MBean. And you may view them using the jconsole command from the JDK.

2) As of today, I think by far the easiest way you can expose any services in your application to a JMX MBeanServer is using Spring’s exporter. You will do something like this:

    <bean class="org.springframework.jmx.export.MBeanExporter">
        <property name="assembler">
              <bean class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
                <property name="managedInterfaces">
                        <!-- Expose any java interface you like to see under JMX as MBean -->
        <property name="beans">
            <entry key="" value-ref="myCoolService"/>
    <!-- This service must implements the interface used above -->
    <bean id="myCoolService" class="">

Above should get you standalone application with JMX enabled.

Now if you want to do similar on WebLogic Server, then I have few goodies and notes that might help you. Read on…

WebLogic Server’s (WLS) MBeanServer

The JConsole trick

The WLS, like many other EE server will have it’s own MBeanServer. However, to see the MBean’s you would need to do little extra with jconsole. Assume you have a default config WLS started on localhost, then you can connect to it like this.

jconsole -J-Djava.class.path="$JAVA_HOME/lib/jconsole.jar:$MW_HOME/wlserver/server/lib/wljmxclient.jar"

Then when prompted to login, enter the following:

Remote Process: service:jmx:iiop://localhost:7001/jndi/
User: <same userid you used setup WLS to their console app.>
Password: <same password you used setup WLS to their console app.>

Now you should see all the MBeans that WLS already exposed to you as a EE server. You may add your own service there.

Programming with JMX connection

You may connect to the WLS MBeanServer remotely inside your standalone application. Here is a typical connection code you would need

        String serviceName = "com.bea:Name=DomainRuntimeService,";
        try {
            ObjectName service = new ObjectName(serviceName);
        } catch (MalformedObjectNameException e) {
            throw new RuntimeException("Not able to create JMX ObjectName: " + serviceName);

        String protocol = "t3";
        String jndiroot = "/jndi/";
        String mserver = "";
        try {
            JMXServiceURL serviceURL = new JMXServiceURL(protocol, "localhost", 7001, jndiroot + mserver);

            Hashtable h = new Hashtable();
            h.put(Context.SECURITY_PRINCIPAL, username);
            h.put(Context.SECURITY_CREDENTIALS, password);
            h.put("jmx.remote.x.request.waiting.timeout", new Long(10000));
            JMXConnector connector = JMXConnectorFactory.connect(serviceURL, h);
            MBeanServerConnection remoteMBeanServer = connector.getMBeanServerConnection();

            // TODO: Do what you need with remoteMBeanServer here.
        } catch (Exception e) {
            throw new RuntimeException("Not able to initiate MBeanServer protocol= " + protocol +
                    ", jndiroot= " + jndiroot + ", mserver= " + mserver);

That’s a mouthful of boiler code just to get a remote MBeanServer connection! Fortunately there is another easier way though. Read on…

The JNDI trick

The WLS MBeanServer service is also available through JNDI lookup. Again Spring can help you with their JNDI lookup and you simply need to inject it to other services that need it. For example:

    <bean id="jmxServerRuntime" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiName" value="java:comp/env/jmx/runtime"/>
    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
        <property name="beans">
                <entry key="" value-ref="myCoolService"/>
        <property name="server" ref="jmxServerRuntime"/>

Notice that we have injetcted the "server" property with one we looked up from WLS JNDI service. If you use that in your WAR application and deploy it onto a WLS instance, and whola, you got yourself exposed service onto WLS JMX!

above will only works if your Spring xml config is part of the WAR/JAR/EAR that’s deployed in same server where JNDI lives! If you are not, you need to use this JNDI name without the "env" part instead, like "java:comp/env/jmx/runtime".

For more details on how to work with JMX and WLS, see their docs here:

Saturday, June 8, 2013

MySchedule FINAL is released

Hi folks,

I have tagged the release of the MySchedule project today. This is the first stable release of the version 3 branch line of the project. In this release we bring you the latest Vaadin UI experience. You may expect all the good stuff from old release, plus few new features added.

  • You may now save your own Templates in scheduler configurations, scripting text or even XML for job loader.
  • You may interrupt a running job.
  • More Scheduler runtime information are displayed.
  • New table display of all plugins used.
  • Added an embedded web server for quick self running UI server.
  • Single convenient package download.
  • New release format: 3.2.x.y is used for MySchedule3 using Quartz 2.x library.
  • New online demo setup on OpenShift platform

Get it and try it out here

Wednesday, June 5, 2013

Another myschedule-3.0.0_q21-SNAPSHOT.4

I have uploaded yet another snapshot of latest MySchedule 3. This should be the last snapshot before FINAL tag. All the features are complete! Please try it out and let me know.

Saturday, June 1, 2013

Second snapshot of the latest MySchedule 3 is out

Second snapshot of the latest MySchedule 3 is out.

  • The SchedulerScreen now has tab sheet view
  • Added JobWithoutTrigger view
  • Added Current Job Execution view
  • Added Scheduler Status view
  • Added Save Template into File

Get the download and try it out: