Long time Ant committer, Stefan Bodewig, has a blog. Stefan is one of the nicest, most helpful and most knowledgeable people I have had the fortune to work with as part of open-source development. I look forward to his blog.
The first beta for Ant 1.6 is out and it has a lot of changes, both bug fixes and new functionality. I think it warrants a reasonably long beta period. The main thing now is to get people to try it out.
This release establishes a few building blocks which will be used and expanded upon in the following releases. I’m hopeful this can simplify the management of classpaths for the optional jars which has often caused problems.
One new component is the new launch code which moves the initial classpath creation into Java code. Ant is now launched with a very minimal classpath and then picks up the main Ant jars. The jars can now come from any arbitrary directory – not just ANT_HOME/lib using the new -lib option. This should better support standard installations without the need to stick jars into the Ant install.
Another component is the new antlib concept. I’m hopeful that in future releases we won’t deploy tasks in the base classloader for which the required support classes are not available. These tasks could then be deployed on demand with a build file specified classpath picking up the required libraries. Currently in Ant, and this remains true in Ant 1.6, the jars which support optional tasks need to be known when Ant starts up. In Ant 1.6, they can, however, live outside the Ant installation.
Anyway, that is just a taste of the new stuff in this release and what it bodes for the future. There’s lots more. Obviously such a large number of changes has the potential to cause some hiccups for existing setups. We’ve worked to minimize problems but we want to know about any during the beta period. So, go check it out – try your existing builds.
The Sobig worm continues to fill up my spam box and I can barely comprehend the number of people whose systems are compromised. I have rarely understood the real size of the internet.
For most of my systems SoBig is not a major problem. I don’t use Outlook and I have enough mail rules and Bayesian filtering going on webtrafficgeeks that both the worm and the useless bounces it triggers are spirited away.
One system has been affected, however. A friend and I share a domain name with a small website and a few email accounts hosted by an Australian hosting service that works exactly like ipage hosting. One of those accounts is mine and I think it appears in a few Tomcat files and mail archives. Not many but a few. When SoBig.F went off this email address received an incredible number of emails. The provider claims something like 8000 mails in two days and about 6 Gig of email traffic to my email account.
Personally, given SoBig’s 100k payload, I don’t think the numbers add up but the result is that the provider suspended our account and will not reinstate it unless we upgrade to a more expensive plan (10 times more). So this is affecting not just my email account, which I don’t really use anymore, but also my friend’s email accounts and our site. More than likely we’ll move to a US provider where traffic is less of an issue but what about the next SoBig? I understand the provider’s point of view but it also feels unfair that I, and expecially my friend are affected.
Having contributed to projects like Ant and the associated mailing lists, my email address is on a lot of websites, mail archives and even a lot of people’s systems. I feel a little like Typhoid Mary.
I think email, as it is currently implemented, cannot go on for much longer. Some people call email the internet killer-app, but it’s becoming the internet-killer app. I don’t know how to change it and whether it can be done quickly enough but change it must.
At the very least, I’d like to see some validation of the sending address to stop the spoofing. I don’t know details but say something where if you send from a particular domain, that domain would provide a lookup service to specify what IP ranges a particular email address can be sourced from.
While these current worms are enabled by Microsoft products, I don’t think other systems are inherently more secure, probably just less pervasive. I’d say the real problem is in the underlying email infrastructure and its lack of security. I hope the email providers step up to the plate here. Our provider will lose our business and they are probably happy to see us go, but we won’t be the last unless the infrastructure changes.
I haven’t blogged for ages for a few reasons. Mainly I have been working on some new developments at Cortex and not a lot of time to spare for other things.
This project is a J2EE project and surprisingly it is actually a long while since I really had a lot to do with a J2EE system. I’ve been doing lots of other systems around J2EE systems. Anyway, this is an EJB based system. I don’t really mind EJBs. They do have lots of issues but I understand those and overall they work OK for me. One thing for sure is that the advent of usable CMP and xdoclet cut down the amount of boring boilerplate code you need to produce.
I modified a few of the xdoclet templates in the area of value objects to suit my preferences. I can now mark some properties as readonly so they still appear in the value object but are not rewritten when the value object is set. Also, rather than aggregating related value objects, I can choose to just aggregate their primary keys. I find that often that is all I need.
Modifying xdoclet templates is a bit hairy but not impossible. The XML templating is a little cumbersome but the results are effective. I shouldn’t complain, xdoclet is writing more code than I am.
For the webapp famework, I am using a few OpenSymphony technologies. WebWork2/XWork is working out well. I’ve found a few bugs most of which I have worked around. OSUser provides a nice and simple method of defining users and groups. Finally we are using Sitemesh to add a lot of common UI stuff to the pages. I have to say that Sitemesh really rocks. It means that I can ignore most of the HTML fiddling on most of my pages.
I’m having fun getting back into J2EE development. It really has come a long way since we started at Cortex with Weblogic 4.5.1
A while ago Duncan published a Blog entry quoting somebody saying that in Ant we’d forgotten some old Unix lessons such as the stringing together of simple filter operations in pipes. I can’t find the entry now since Duncan has rebuilt his blog on a new server. At the time I had a quick think about it and was not sure how we could provide the concept of a pipe in Ant. I didn’t get very far and let it go. Nevertheless, that thought has been jangling around in my head since then.
I recently saw a bug report in Ant about sorting the output of <echoproperties>. The normal approach would be to bung in a new attribute to control sorting of the output and just do that. But that does not make the functionality available to other Ant tasks. The idea of a pipe appealed
So, I wonder if a pipe could be created, something like this
<pipe> <echoproperties/> <sort/> </pipe>
The pipe would route the log output of one task to an input method on the subsequent task for additional processing. Anyway, I’m at something of a low ebb right now and not in the mood to code so I thought I’d throw these thoughts out there for some feedback.