Is it possible to alter Ant properties after they've been initialized?

I was working on an Ant script (yes, I am using maven2 too for other projects, but in this case I just want to use plain vanilla Ant script) and along the way came upon this need to change an Ant property after it has been initialized.


Did a bit of googling and came upon this forum discussion. Not a very bright and encouraging note at the end - essence being "No; property values, once set, cannot be changed. Attempts to do so will fail silently."


Well, guess what? I am not the kind who give up that easily.


Here are the steps (for contribution back to the community) to change an Ant property after it have been initiatlized. Snaplets of code for illustration purpose only.


Before we dive into codes, just some overview of the approach. I am using javascript within the Ant script to accomplish this. So, you will need to download dependency libraries. The one that is really needed is js.jar from from Mozilla and don't forget to grab also the bsf jar too. For more information, you should check the Ant user manual here (scroll to the table containing js.jar and follow the link). For my side, I have both bsf-all-3.1.jar and js-14.jar within the lib directory of ant. I am running Ant version 1.7.1 for this example.


OK, now that we have covered the basics, here goes:



<project name="myProject" default="myTarget">
<property name="message" value="Hello, me!"/>
<target name="myTarget">
    <echo message="${message}"/>
    <script language = "javascript"><![CDATA[
           myProject.setProperty("message", "Hello world!");
     ]]></script>
     <echo message="${message}"/>
</target>
</project>


The portion of code that changed the property value is highlighted. The output should be similar to this:


Buildfile: build.xml


myTarget:
          [echo] Hello, me!
          [echo] Hello world!


BUILD SUCCESSFUL
Total time: 0 seconds


Never give up so easily in life.... that's the lesson. Have fun!

Increasing disk size for virtualbox running Ubuntu

Yes, I am running Ubuntu in a VirtualBox, and have been refusing to upgrade to version 10.10 or even version 11, since I have no compelling reasons to do so (actually, I have good reason not to do so). However, end of last week, I hit to an issue with MySQL - a limitation that I will write in another blog entry.

Anyway, I did run out of disk space on my virtualbox guest. Came across a few web entries that discussed on how to overcome it, but most of them are applicable to Windows guest virtualbox setup.

Here are some of my attempts that didn't work out that well, and possible reasons:

1. Used Clonezilla

Strategy
Use Clonezilla to back up the old VM and restore it into the new expanded disk.

Outcome
Yup, I boot up my old version of Ubuntu using Clonezilla LiveCD and make a clone copy. Then boot up my new empty virtual image using Clonezilla LiveCD and tried to restore the image to the expanded disk image.

Reason
I was able to backup image of old Ubuntu VM, and managed to restore the image to the expanded VM volume, but when I boot up, it was not able to start up. This is due to GRUB loader. During the restoration of image, I briefly saw a message that there could be an issue since they detected GRUB and was not able to change to root to change some settings... I guess.

Result
Failed (you might have better luck than me)

2. Use GPart 

Strategy

Create an empty (larger diskspace disk) virtual disk using VirtualBox Virtual Media Manager. Attached the larger virtual disk to the SATA port 1 (the old smaller virtual disk on SATA port 0). Mount GPart LiveCD  and boot from it. Copy the old disk (/sda1) to the new disk (/sdb). Mark the new disk as bootable. Reboot with the new disk as primary (might also want to unmount the old disk).

Outcome
No problem with the copy and paste using GPart. No problem with the flag "boot" for the new disk. Just didn't boot after when switch to primary boot disk!


Reason
Unknown. Still figuring it out.

---

Here is what worked for me.

Background

I have the following:

1. Oracle VirtualBox 3.2.12 r68302
2. Ubuntu 9.10.2 (8 GB HD)

What I want to do is to add more hard disk space (increase to 16 GB HD).

Steps

1. Create a virtual disk of larger size

•  Through Oracle VirtualBox GUI, select File > Virtual Media Manager > Actions > New
• Fill up the 'Create New Virtual Disk' form

2. Open a command prompt and do:

C:\Documents and Settings\user\.VirtualBox\HardDisks>"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd "MyFirstSmallerDisk.vdi" "MyLargerSecondDisk.vdi" --existing

Oracle VM VirtualBox Command Line Management Interface Version 3.2.12
(C) 2005-2010 Oracle Corporation
All rights reserved.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone hard disk created in format 'VDI'. UUID: 2fe48578-ade7-48fa-873b-2245714074f5


(some of the information are scrumbled and replaced, especially those in blue. Replace the name of the vdi files appropriately)

This will clone the smaller virtual disk to the larger one.

3. Create a new VM through the Oracle VirtualBox GUI, select Machine > New

• Enter a new name for this VM (e.g. "MyLargerSecondVM")
• Choose Linux, Ubuntu for OS Type
• Enter the memory size
• Check "Boot Hard Disk" and select "Use existing hard disk" > "MyLargerSecondDisk.vdi"

4. Reboot the new VM ("MyLargerSecondVM") to see that things are still bootable and in order, but do note that the primary partition is still the same and has not been modified. The extra disk space has not been allocated yet.

5. Shutdown the VM after everything looks fine. Back up the VMs.

• I copied all the files under "C:\Documents and Settings\user\.VirtualBox" to another secondary storage.

It is now time to resize the partition to fill up the entire new virtual disk.

6. Ensure that the boot order for the new VM ("MyLargerSecondVM") is (CD/DVD-ROM, Floppy, Hard disk) via Setting > System > Motherboard

7. Ensure that the GPart LiveCD is mounted. Setting > Storage > IDE Controller > CD/DVD Device > [select the gpart iso file, e.g. gparted-live-0.8.0-5.iso]

8. Reboot the VM ("MyLargerSecondVM")

9. Enlarge the primary boot partition. You might need to move the swap partition to the end of the disk before enlarging the primary boot partition. I did the changes in a series of small steps rather than applying all changes at one go. I actually hit to a slight problem initially if I will to consolidate all my steps.

10. Once the swap partition is moved to the end, and primary partition has been enlarged successfully, quit GPart and reboot. Remember to unmount the GPart LiveCD through Setting > Storage > IDE Controller > CD/DVD Device > [Select "Empty"]

11. Reboot "MyLargerSecondVM" and login. You can check that you have more disk space now. e.g.

% cd /

% df -k .

Good luck.

Grails Acegi plugin and Spring Security Core Plugin

As you might have suspected it: I am writing again on technical subject simply because I want to save some hours for you folks out there in the wild.

Yup, I was trying to read the instructions found here in Grails.org for using Acegi plugin.

If you are in a rush, then just read this line: The above tutorial is very outdated and you should probably not waste your life following it anymore.

OK, here is what I did (removed some path information to protect some privacy) :

# grails install-plugin acegi

Welcome to Grails 1.3.5 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: \tools\grails-1.3.5

Base Directory: test3
Resolving dependencies...
Dependencies resolved in 1094ms.
Running script \tools\grails-1.3.5\scripts\InstallPlugin.groovy
Environment set to development
Resolving plugin acegi. Please wait...

:: problems summary ::
:::: WARNINGS
                [NOT FOUND  ] org.grails.plugins#acegi;0.6!acegi.zip (219ms)

        ==== grailsCentral: tried

          http://svn.codehaus.org/grails-plugins/grails-acegi/tags/RELEASE_0_6/g
rails-acegi-0.6.zip

                ::::::::::::::::::::::::::::::::::::::::::::::

                ::              FAILED DOWNLOADS            ::

                :: ^ see resolution messages for details  ^ ::

                ::::::::::::::::::::::::::::::::::::::::::::::

                :: org.grails.plugins#acegi;0.6!acegi.zip

                ::::::::::::::::::::::::::::::::::::::::::::::


Error resolving plugin [name:acegi, group:org.grails.plugins, version:latest.int
egration].
Plugin not found for name [acegi] and version [not specified]

As you can see, I cannot download the plugin. Heh, no problem especially after you have read this article and have some inspiration? We download the latest version from codehause (at this point of writing, I can find the best candidate to be here).

Guess what? Installation was great. But when you try to create-auth-domains, there are no domain classes created. It is all empty!

OK, now the right way. The right way is to move to Spring Security Core Plugin! The reference document can be found here and for those who just want to jump into it, please go straight to here.

I really wished that the article/blogs/whatever authors of acegi would just help the village to update their materials and point to Spring Security Core Plugin as it is already stated in Grails Acegi site that "You're encouraged to use the new Spring Security Core plugin instead which is the official Grails security plugin and will be actively maintained."

Have fun!

Spring + Quartz

I have started to use Quartz within Spring last night after thinking about why I cannot run away from using a scheduler and how I could avoid using one.... in the end, I ran out of options, so I started to design the job and stick out a few lines of configuration.

There were two interesting lessons that I have learnt.

1. The cron expression for the org.springframework.scheduling.quartz.CronTriggerBean is not a standard unix cron expression. It is only "cron-like" definition (as written in the javadoc for CronTrigger).

This one bites me a few hours. Reading the documentation at first glance gave me the impression that the expression used to setup the cron job is the standard unix crontab expression. Oh, how wrong I was!!! In the end, I was battling with a strange error message (a snapshot shown below):

Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.quartz.SchedulerException: method (Ljava/lang/String;Ljava/lang/Throwable;)V not found
Caused by:
java.lang.NoSuchMethodError: org.quartz.SchedulerException: method (Ljava/lang/String;Ljava/lang/Throwable;)V not found
at org.springframework.scheduling.quartz.SchedulerFactoryBean.registerJobsAndTriggers(SchedulerFactoryBean.java:795)
at org.springframework.scheduling.quartz.SchedulerFactoryBean.afterPropertiesSet(SchedulerFactoryBean.java:599)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118)

Of course, when you read this blog you already have the wisdom it is due to the cron expression. But that's hindsight. Looking at the error message gives you a few misleading indicators. It was actually saying something really different. The underlying class have a mismatch method signature or using one that does not exists. So, I try other Quartz library... 1.5.1, 1.5.2 or even 1.6.0 which ships with the Spring that I am using. Nothing works until I changed the cron expression to the one that follows EXACTLY as in the documentation, then my unit tests start to fire up again.

Actually, a hint that there might be something wrong with the crontrigger bean happens when I commented out the portion of loading of triggers to the SchedulerFactoryBean. The error message is no longer showing up, ... and of course, neither was the job firing up.... but it was hinting something to me...

This is when I started to go back to the javadoc for CronTrigger and discover to my horror that the cron expression IS NOT the standard cron expression. Perhaps, Spring could put a liner of warning to the documentation too (not just the javadoc). Not their fault, I should have better known this.

2. Strangely, Quartz 1.6.0 that ships with my Spring 2.0.8 did not work on runtime. It works on compile time.

Well.... there is a strange liner when the Spring's javadoc for SchedulerFactoryBean have this liner:

This version of Spring's SchedulerFactoryBean requires Quartz 1.5 or higher.

So, I resort to Quartz 1.5.2 and it works again.

So, just make sure that all these are out of the way and ... enjoy the fun of firing up your jobs.

There is good and ugly (Maven2)

Well, thought I might just add some thoughts in the debate on Maven that started a couple of days back. Didn't want to add to that blog's long list of comments as it already is a long list and honestly, took me sometime to read all the valuable experiences of others.

I must at least quantify where and what I do: I am a Development Manager. I look at development processes, and toolsuite is part of my constant concern as it impacts how my teams get their work done. There was a kung-fu movie (StormRiders) that has some nice wisdom:

Cloud: Which is better, martial arts or a good sword?

Cloud's father: A good sword can help a novice and make a expert really powerful. But the most important is who is using the sword.

That's the subtitle, yurks! Let me paraphrase it using my Cantonese:

Cloud: Which is more important? Martial Arts or a good sword?

Cloud's father: A good sword can make someone without martial arts mighty, and also can make a master conquer the world. But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.

And that's perhaps my starting point.

There were a few things that drawn my attention to Maven2. And yes, the push factor is the documentation (more of that later). The most important part was a clear definition of a project structure. It is not entirely easy at first I must admit coming from the pure ant environment. Took some time to familarize with it. And I have also similar problem with "moving" or "shifting" artifacts. One way to control this is really to host an internal repository and we control what is really needed (together with fixing the version of the dependencies). This is a fact of life - there are many "untested" or "ill-tested" artifacts. The original developers might not have meant to do a bad job, it is just a reality that we have to live with (even with commercial products!). Rather than whinning and crying, I control this chaos.

Oh, I forgot to mention - why is it important for me to have a clear project directory structure. Of course, to be honest, I could define one and the rest of my teams follow it. But think: Is this what you want your guys to learn? i.e. YOUR structure, and YOUR way of organization? Well, what I want is this: I want to enhance their productivity. If I can follow some open way of structure, and there is wide adoption (i.e. other companies are also adopting - which is of course a dream), then it will be easier for my team to move onto another job or role in another company. Or for other skilled engineer to join my team too - it works both ways. Let's be honest: this is NOT their first company or team, and won't be the last. If I enhance their role and skill, I think I am on a better bet to retain good skilled teams.

Furthermore, I often think when running multiple projects with my teams, it is really best to have a "common" structure, so that when a "new" team member is dropped into the project, productivity will not be affected too adversely - it is a reality of life, at times we do need some help from other teams.

So, there is a plus if we have a proper project directory structure. i.e. where we place our codes, where we place the configuration files, the web stuffs, etc.

Maven provides that. I do not have experience with Ivy (yet). But I think I will take a look at it soon from all those good words that were said, not to forget a few others in the blog mentioned above.

All said, I admit the documentation of Maven was more of a hinderance to me than of a help. In fact, at times I do better without it! Why is it so? well.... blame it on us! I thought it is supposed to be an open source project, isn't it? And one with a good intention. Those who complained about the documentation (like me), are NOT the ones writing the documentation. If we want it to be better, well... roll-up your sleeves and help out by contributing to the quality and detail of the documentation. In fact, there are so many "experts" who have used Maven and complained about the quality of the documentation, yet I don't see them on the list of contributors. Is Howard on the list? Is Jay on the list? Is Jon on the list? Is Gabriel on the list? Carols who is from the maven team commented "documentation could be better way" in the long series of comments. Notice there is no ivory tower talk - he is already contributing to the project. I think his credential blows the rest away (and mine too when I say the documentation is a hinderance because I have not helped in the documentation either, so shame on me). It is because of this, that's why I kept much of my silence. If it is not good (enough), most likely it is because we are not contributing to its success when we see the problem. Just admit it.

The point is simple: This is an open source project. Complains will go that far. The better thing to do is to help out when you see the problem. Of course, as end users of a product, we can fly to another product which gives us better stuff (that's seems to be a prevalent behavior when you read those comments)... but honestly, I think that is a ... not so good attitude to life in general. When we take something, it is always good to give back something too.

So, what is said in the StormRiders quotes above is true: But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.

A good read for software development folks

I chanced upon a good article How to Rate a Software Developer, and there is also another separate article entitled The One Minute Software Development Manager too. Both are fairly good read. But remember: Reading does only the cognitive part, and cognitive stimulus must move into reality before the benefits can be realized.

So, don't just read, but do it!

Application profiling (Comparing 4 tools in my bag)

I have not been writing technical blog for very long. On the other hand, James have been writing quite a few technical blogs recently, and some of them are really interesting.

For today, I will probably write on my recent toys which I have been playinig around - profiling tools. The application that I am profiling is a J2EE application, multi-tier, blah blah blah.

Before we proceed, let me state my intention for this tool: I want to identify the performance hotspots within my application and thereby giving me the starting point to do refactoring work, or recoding of modules entirely.

So, I hope this is a simple enough objective for me... or is it?

Needless to say, even though I have previous experience on some commercial tools, this time round I try to stay away from some of my familiar ones - JProbe, OptimizeIt and even the free one which I like - Netbeans Profiler.

The "problem" with Netbeans Profiler in my present context is that my application runs on BEA's JRockit JVM and on JDK 1.4.2. To be fair, NB profiler have a specially instrumented JVM for JDK 1.4, but hack... I am not using Netbeans here in my team. I am using Eclipse.

So, the "natural" choice was to go for TPTP. There is also another option that I have: Mission Control from BEA. The Mission Control 2.0 ships with the JRockit VM.

---

Here are some of my experiences on Eclipse TPTP:

The good

1. It snaps into the IDE which my team is using which is Eclipse
2. I think it will continue to mature
3. We can profile a JRockit VM

The bad

1. The installation process is not that straight forward (besides downloading all the relevant and dependent plug-ins), at one point foiled my Eclipse installation. It was wise of me to do a backup of my hard-disk and I recovered everything to the original state. I hate to furge around trying to figure out what's wrong with the installation, when my original intention is to profile my application which I think is the problem - I don't need another problem
2. There is a separate agent controller and guess what? yes, it does not work on some old JRockit JVM. I have to figure that out and after banging my heads for a few days, I stumbled upon the possibility that perhaps it is due to a VM bug... so I went ahead to download the latest JRockit JVM and viola! it works

The ugly

1. This whole idea of having a agent controller is ridiculous. There are so many tools that don't need it and I have additional setup to do
2. Ridiculously intrusive - it drags my application to its knees in some use cases

Conclusion: I still find it a reasonable tool to use if you are doing a JPetstore. Not suitable if you are working on a large application. I think the tool needs more time to mature. And I think it will improve over time. I am not throwing in the towel for this one.

---

Now about Mission Control 2.0

The good

1. Almost brainless in the installation. There is only the standard profiling agent to be configured at the VM's runtime options - no big deal.
2. Light enough - as compared to TPTP. It didn't drag my application to its knees

The bad

1. Even though I can discover two of my agents running on a single box, only one of them could be profiled properly. The background is that I am running both the web and application tier on the same box. I think the agent must have gotten themselves confused...

The ugly

1. Absolutely ridiculous in the filtering of classes to be profiled and viewed for analysis. I cannot imagine a tool coming from such a reputable company and requires me to enter the full package and classname to be profiled (imagine, I have to type in java.util.Vector... and there are so many other classes I want to profile - all entered manually!!!) The fact is that when I do a profiling of my application, I want to identify the hotspots of my codes - if I supply the full resolved package and classname, that will mean I already know where the problem is! I was defeated by such a ridiculous design.

Conclusion: Not very useful to me (might be to other folks).

Now, I tried something commercial tool which I know might not be fair to compare with the previous highlighted tools. But I was determined to find something that I can use in the development (i.e. free or at least provide a development license).... BTW, I did try YourKit Java Profiler - it is not easy in installation and didn't work well for my application, so bye bye.

---

The next tool that I want to bring into the scene is JXInsight.

The good

1. A more complicated installation process compared to Mission Control, but close to what I should expect even out of JProbe or OptimizeIt, overall still manageable.
2. It supports so many platform (both OS and application container) and VM... unlike Netbeans Profiler...
   

The bad

1. Ghee, the documentation is really not well organized. Folks from JINSPIRED should really sit up on this one - you have a good tool, the problem is that you have people who want to use your tool. Your objective is to make the road easier. In many aspects, you have done so, but not from the Installation guide and User manual. It is frustrating to read it, not well index, the PDF files (included in the installation) does not have clickable indexes or content page. It can be seen that these folks are engineers.
2. The manuals (which is really the help files too), do not really shows step by step on how to use the different views and perspective. Newbies to these tool can get discouraged if they cannot use all the information presented to them - it is thrown to them.

The ugly

1. The user manual writer should really put in BOLD that the user requires to not only start the VM with all the required options and configuration setup but actually runs a transaction through the application BEFORE you can see anything on the console. Most of the other tools usually get snap into the agent and display heap graphs and things like that. This one doesn't - it polls and reports that it cannot find anything within the network.... until you hit your first transaction through the system and viola! all the lights are blinking.

Conclusion: I am using the developer edition now in my development environment, it has a time limit of 45 mins for profiling. Good enough for most purposes, and the most important thing - it works on my application and did not drag it to its knees. It takes a while before you can interpret what you see on those views and as I said, the documents did help that much. Overall, I am quite happy with this tool and it will certainly not be lying on the floor of my toolbox when I do profiling.

---

For those cool profiling tools maker out there, may I give some inputs to what a user wants:

1. Easy setup
2. Light (i.e. don't drag my application down anymore than it is now!!!) The reason why I am using your tool is to investigate the concerns of my application - not your tool
3. Please write the documentation well. People read them. If you want wide usage, it has to be easy to use and easy to understand the vast amount of data presented. Not everybody is a D.E (Distinguished Engineer) who can get productivity at the snap of the fingers. Tools should be written for people - people with a mission and task and it does not help to burden them further.
4. Yes, provide a developer's license is a great way. I am very willing to buy the commercial production license -and yes, I am the technical decision maker.
5. Support a wide range of OS, VM and application container. We don't just work on one project for the rest of our lives. We want to build on the knowledge of the tool, so, if the tool can also support another OS, and VM and container which my next project is working on... wow... I will embrace it almost like a religion (which translates to loyalty to the tool).
   

So, have fun profiling away.