java

You are currently browsing the archive for the java category.

Spring has a rather nice scripting framework that I haven’t paid much attention to, more from a lack of need than any real lack of interest.

One thing I recently noticed, is that there are only 3 supported scripting languages: Beanshell, Groovy and JRuby. Now Beanshell (for myself at least) was interesting about 4 or 5 years ago (maybe longer… since I can’t quite recall when it was first released), and I have little interest in Groovy (read “little interest” as “no interest”).

A bit of googling only uncovered a brief discussion about adding Jython support back in 2004 (I haven’t been able to find any code to go with that discussion), and Rhino-in-Spring which, as far as I can tell, is aimed at the web tier. Interesting that 2 of the most popular (IMO) scripting languages are rather conspicious by their absence from the core Spring distribution. Or if not absent, then certainly not very visible.

I’ve been looking for a reason to hack around with Spring extensions for a while, so this seemed like the opportune moment. Following one of the comments in that 2004 discussion, I started with cloning GroovyScriptFactory and a few other classes from the scripting package, and then hacked away the bits I didn’t want or need.

GenericScriptFactory is my abstract base class, and contains most of the code from GroovyScriptFactory. Subclass JythonScriptFactory is the workhorse for Jython scripting, while RhinoScriptFactory is obviously for Javascript code.

The cool part — I’ve implemented a NamespaceHandler for both, so bean configuration looks like this for Jython:

<script:jython id="test1" script-source="test.py"
               bean-name="mytest" return-type="test.TestInterface"
               interpreter="pythonInterpreter">
    <script:property name="test" value="jython prop from spring" />
</script:jython>

and for Javascript (Rhino):

<script:rhino id="test2" script-source="test.js"
              bean-name="mytest" return-type="test.TestInterface"
              scope="jsScope">
    <script:property name="test" value="javascript prop from spring" />
</script:rhino>

You’ll note that in both cases the attributes are passed to the factory, but properties are injected after the bean (in whatever language) has been created. A distinction which is rather useful when you think about it. This is the same as the other scripting languages already built-in to Spring.

You can see the full configuration file here, which includes setting up a PythonInterpreter for Jython, and a global scope for Rhino.

The sweet spot is, of course, this configuration:

<script:jython id="test3" script-source="test.py" bean-name="mytest" return-type="test.TestInterface" interpreter="pythonInterpreter">
    <script:property name="testInterface" ref="test2" />
</script:jython>

test2 is the object created by the Javascript code, and you’ll note that it’s being injected into the object created (in this case) by Jython code. The opposite works as well, meaning you can call Jython code from Javascript and Javascript code from Jython (well, at least through Spring injection). Exactly why you’d want to do this, I don’t know, but it’s a fun feature.

In either case, my classes implement a simple Java interface, meaning the beans created by both scripts are useable from Java as well — as you can see in the Test code:

public static final void main(String[] args) throws Exception {
    ApplicationContext context = new ClassPathXmlApplicationContext(new String[] { "beans.xml" });
    BeanFactory factory = (BeanFactory) context;

    TestInterface ti1 = (TestInterface) factory.getBean("test1");
    System.out.println("jython test: " + ti1.getTest());

    TestInterface ti2 = (TestInterface) factory.getBean("test2");
    System.out.println("rhino test: " + ti2.getTest());
}

Anyone interested can find the whole thing (very much a work in progress) in a Mercurial repository here.

UPDATE: it helps if you check the menu options properly… blushsmiley

I don’t tend to waste my time investigating all the nooks and crannies of an IDE (Integrated Development Environment, for the non-developer-types). I typically just use the basics. Some might say I’m wasting time by not using those features, but it works for me.

So when the Eclipse & IntelliJ users on the team opened a dialog box and jumped straight to a source file by typing the first few letters of the filename, I just shrugged and went back to navigating through the project tree…. that is, until someone pointed out that Netbeans had the exact same feature — “Go To File” (so obviously a little investigation of menu options wouldn’t have gone astray).

Then, lo and behold, I discovered shortly after, that Netbeans’ “Go To File” function actually did more than Eclipse (and was at least equivalent to Intelli). You could type the capital letters of the class and it would list the matching classes. For two glorious months (or so), I had a feature that was at least as good as my colleagues. The months of enduring taunts, because of my obscure choice in IDEs, faded from memory as I jumped from file to file with a flick of a few (less) fingers… at least, until the latest version of Eclipse arrived with that feature.

Now Netbeans 6 beta 1 has been released. I’ve been burnt in the past by NB early releases — but this is a brand-spanking-new beta. Spit-polished with the glean of months of development effort, since then. Gosling is talking about it. The general consensus elsewhere appears to be that it’s good.

And, after upgrading, it does look good. Not a huge amount of visible difference from NB5. A few burrs here and there have been filed off the sharp edges. There are some things I don’t find attractive, but it’s bearable. Integration with source control doesn’t seem to thrash the CPU, which is a major improvement.

But then… Alt+Shift+O

My most-used feature.

The only thing I could (until recently) hold above the Eclipse users on the team, and say confidently (and maturely), “Nyah nyah nyah nyah nyah”.

One thousand curses on the perpetrator, for violating the perfection of the Alt+Shift+O! Yes, they’ve indeed extended it to search all filenames instead of just classes, but at the same time they’ve rendered it unuseable. Not only is it slower, it is s…l……o………w……………e……………………r.

It is grindingly slow.

If the phrase that immediately pops to mind to describe the fastest thing you’ve ever seen is “blazingly fast”, then a snail would be described as “blazingly fast” by this feature. A tortoise would have the opportunity to perform a full circuit around my desk, and execute a perfect pirouette, before this abysmal piece of code decided that it should return some results.

Slowness I could’ve forgiven if they hadn’t removed the only thing that (until recently — and yes, I know I keep saying that) made me better than the Eclipsers. The feature-in-the-feature that made me as good as the Intellis. Searching, via the capital letters of a class.

MCGF would find MyCrazyGeneratorFactory.java and MyCrazyGeneratorFactoryImpl.java. WDMCHSLN would find WhyDoMyClassesHaveSuchLongNames.java. As it is, I now have to type My (then wait an inordinately long amount of time) to find all files starting with “My”. Carry on typing if I want to narrow the results. With a bit more waiting…

Netbeans 6.

The upgrade that is actually a downgrade.

Now I have to endure the snickers of both the IntelliJ AND the Eclipse users.

Sigh.

Footnote: Welcome back NB5.5.1!

…or at least I hope it’s a hiccup.

I downloaded the lastest daily of Netbeans 6, after a couple of exceptions in the m9 release I had been using began to get annoying. Not only is it extremely buggy compared to prior version (unusual for a Netbeans daily, in my experience), but it appears they have replaced the quite functional file dialog with an absolutely abysmal, in my honest opinion completely unuseable, dual mode dialog box.

Whatever possessed the development team to allow that abomination into the main trunk, let’s hope it is a temporary aberration and by the time NB6 goes final, saner minds have prevailed.

A few things I’m finding a minor annoyance in Netbeans at the moment…

1. Netbeans is not an island.

I’m the only one using Netbeans on our project. I’m the small deformed child, in the corner of the class, that none of the other kids wants to play with.
Our projects are all driven off ant build scripts, so the logical way to use NB (when everyone else is using Eclipse or Intelli) is a free-form project (i.e. “Java Project with Existing Ant Script”). Okay, that works fine, but when you want to compile a single file from within the IDE, the ant script ide-file-targets.xml is created — that’s still okay, I can hack so that the internal classpath in that file points at the classpath in our main build script. But what about code completion, and the other IDE tools that rely on knowing the classpath?
First, right-click on the Project, select Properties, then Java Sources Classpath, then reproduce the classpath you’ve already created in the build script….?

Hmmm. That’s a word that starts with A and rhymes with “pass”.

A related note: I hate the ant icon on freeform projects in NB6. Go back to the old one.

 

2. A Project is not an island.

If NetBeans is not an island, neither are the projects in it. If you hit Ctrl and move your mouse pointer over a class name you can jump to the implementation… but not if that class is defined in another project. There might be a way to do this — but it ain’t obvious.

 

3. Why can’t I turn off Editor Hints?

I don’t like them. I don’t need them. And if I do, I’ll ask. But the problem is, there’s no obvious option that says “Use Editor Hints” to turn them off, and I’ve been through the advanced options — a number of times.

Besides, checkstyle covers all the stuff we actually want to check for.

 

4. “Help” is rubbish.

Stick it in a proper browser, so I can at least hit CTRL+F and find something in the current page. Oh yeah, and my up and down arrows don’t work in the help window either. Might be a Linux issue. But maybe not.

 

5. Where’s “Jump to Resource”?

Alt+Shift+O opens a dialog to jump to a “type” (class/interface/etc), which is nice. But Eclipse will open any resource: Python scripts, build scripts, whatever. Gimme that instead.

 

6. Fix Imports doesn’t remember what I chose last time.

Chances are if I select commons LogFactory one time, I’m going to want to select it the next time. I do not want to select it from a drop-down menu every time.

 

7 Minimal installation wanted.

I want to specify a minimal installation. All non-essential modules switched off. Everything that doesn’t stop the IDE from falling over in a steaming heap. Code completion yes — built-in Tomcat, app server integration, HTTP monitor, J2EE blueprints, integration, etc, etc, etc… absolutely not. I’ll switch on the bits I want, thanks all the same. In fact, don’t even bother including them in the distribution. Download on demand.

 

8. Reformat

If you say reformat xml, surely it means fully reformat? Not just reformat a bit. Either that, or relabel the menu option to “Half-assed Reformat Code”.

 

Okay, so that’s only eight. But Top Ten rolls off the tongue better than Top Eight… :-D

We’ve had an app running on SQL Server and MySQL under Hibernate for over a year now — but I failed (rather miserably) getting Postgres running well with the same mapping files.

The main problem was that our mapping files use a native generator:

    <generator class="native" />

In SQL Server and MySQL this maps to an auto incrementing column, but in Postgres (I think) you end up with an int or bigint (depending upon your domain object data type), and a separate sequence (named hibernate_sequence), used to populate it.

Thus if you’re applying raw SQL statements outside of Hibernate’s control, you can’t use the same SQL across all 3 databases. In other words, assuming a table:



    
        
            
        


    


The following sql statement…

    insert into mytable (col1, col2) values ('a', 'b')

…will work on SQL Server and MySQL (in these cases, the column “id” is created as an identity or auto_increment), but not on Postgres (the column is created as a basic int).

However, I’ve just found a workaround — not sure if it’s the recommended approach (I’ve seen a couple of other references describing other ways to accomplish the same result, but these involve changing the mapping files), but this way works for me.

The answer is to define your own Hibernate dialect, subclassing the default Postgres dialect:

import java.sql.Types;
import org.hibernate.Hibernate;
import org.hibernate.dialect.PostgreSQLDialect;
import org.hibernate.dialect.function.SQLFunctionTemplate;
import org.hibernate.id.IdentityGenerator;

public class CustomPostgresqlDialect extends PostgreSQLDialect {

    public CustomPostgresqlDialect() {
        super();

        // register some functions and column types in here
        ...
    }

    public Class getNativeIdentifierGeneratorClass() {
        return IdentityGenerator.class;
    }
}

This dialect returns an identity generator instead of a sequence generator, which means we don’t need to change our mappings across all 3 databases.

Result!

This is an excellent example of a developer getting carried away by his/her own cleverness:

When generating Java code from an XML Schema, in certain modes JAXB automagically converts words to plural where there may be more than one element. For example, the word Datum is automatically converted to Data, the word Item converted to Items.

This is an exceptionally bad idea for 2 reasons (off the top of my head):

1. Surely it makes more sense for the code to closely match the schema? Not arbitrarily deciding to fix your grammar for you.

2. It’s badly implemented. For example, if I have an abbreviated word ending with “f” it incorrectly converts to plural — “Itemref” becomes “Itemreves”. Garbage. What’s worse, is that I have an xsd:choice contain Items and Itemrefs, so the JAXB1 generated code contained the method “getItemOrItemRef” — JAXB2 in extensions mode creates the wonderful “getItemsAndItemreves” method.

What 1st university student on 6 months work experience came up with that brilliant plan?

But wait, it gets even worse. The jaxb documentation at dev.java.net is full of badly written (often unintelligible) ramblings, missing links, less-than-useless links to blog entries and unwritten faq entries (why bother writing the heading if you don’t have time to write the content, I ask you?).

It is, to put it politely, an absolute mess.

This is one of the more useful hacks I’ve thrown together lately. It’s a simple console application for accessing a hibernate domain (i.e. you can execute queries such as “from Blah where x = 1″), so you don’t have to deploy your application to test minor changes to hql statements.

It is, by no means, an endorsement of hibernate; rather a reflection on the fact that I can’t find any tools to access the domain which don’t require the use of Eclipse (<sarcasm-alert>because, of course, everyone uses eclipse</sarcasm-alert>).

In any case, the script needs to be executed with a classpath referencing the hibernate jars, jython jars, your domain classes, and anything else hibernate & jython might need to access — I run it from within ant, but it could quite easily be executed from a shellscript.

If you’re using, or have used JSF, you’ll be aware that Javascript is generally a necessity. However, some JSF components do function with Javascript disabled… and so you’d kind-of hope that the basic HTML components will work fine with javascript switched off.

You’d be wrong.

Radio buttons don’t work in all cases, inside tables being the obvious example (solution: write your own radio component. Sigh), and my new personal favourite… feature… command links (rendering as hrefs) will work, but not if they’re inside a form.
We figure the evaluation processing gets to the form component, checks if the form has been submitted, and does not evaluate any of the child elements if it hasn’t been submitted. With javascript enabled, a click on a command link (href) effectively submits the form — with javascript disabled, the command link is a plain href, so the form is not submitted, hence the action on the link is no longer evaluated.

Which is another wonderful example of why spotty faced geeks barely past puberty shouldn’t be allowed to design & develop frameworks… [disclaimer: I have no idea whether the people behind JSF are spotty-faced, geeks, or barely past puberty, but it suits my view of the technology, so I'll persist with my stereotypical assumptions]. Let’s just ignore the last 10 or so years of web development and standardisation, shall we?

One thing I dislike about Netbeans is the ant integration for single file compilation. Pain in the [insert-euphemism-for-nether-regions-here]! Okay, there’s an automatic creation of the ide-file-targets.xml — but it has required a degree of modification for most (read as ‘all’) projects I’ve worked on. Case in point — if you separate your source files from your unit tests (src & test directories for example), the default creation of this file doesn’t work (or at least it doesn’t for me). The fixed classpath in the default target exacerbates the problem, forcing one to edit the file as soon as you add jars to the project (unless you set up a dynamic classpath from the get-go).

Handling this file is, I believe, something that neither I, nor any developer, should have to deal with. It feels uncomfortably like having to hack the IDE for something that should be built in by default. Integration with ant is all very well, but I don’t think editing those project-generated ant scripts should need manual intervention except for the most unusual of circumstances. And certainly not to add single-file-compilation for code in another source directory.


By the way, in order to add another source directory (such as a ‘test’ dir) for single-file-compilation, add a new action to project.xml as follows:

<action name="compile.single">
  <script>nbproject/ide-file-targets.xml</script>
 <target>compile-selected-files-in-test</target>
 <context>
  <property>files</property>
  <folder>test</folder>
  <pattern>\.java$</pattern>
  <format>relative-path</format>
  <arity>
   <separated-files>,</separated-files>
  </arity>
 </context>
</action>

(This is just a copy of the action created automatically when you first pressed F9 to compile a file in the main source tree — with a new target and folder).

Then add the new target to ide-file-targets.xml:

<target name="compile-selected-files-in-test">
 <fail unless="files">Must set property 'files'</fail>

 <mkdir dir="${build.classes.dir}"/>
 <javac destdir="${build.classes.dir}" includes="${files}" source="1.5" srcdir="test" debug="on">
  <classpath refid="classpath" />
 </javac>
</target>

Note that I’m using a dynamic classpath in the above target (with a refid to the actual classpath) — whereas the default usually has a list of jar files.

My latest article has just been published in O’Reilly’s ONJava:

“Playing Together Nicely: Getting REST and SOAP to Share Each Other’s Toys”.

It’s running earlier than expected — for some reason I thought it was scheduled for next Wednesday, rather than this week.

One correction that may (or may not) get reflected in the article — from the paragraph on page 4:

Although the rather pedantic nature of validating WSDLs (missing, anyone?) means slight changes can have significant impacts on validation, and I’m only guessing (because I have yet to fully test this final feature) as to its ultimate usability.

The first bracketed section should read:

(missing “/” anyone)

Alluding to the fact that leaving a slash out of url in wsdl can sometimes have far more effect than you might think.

Relief ensues, as the font smoothness in Netbeans, on my small laptop screen, is still apparent on the large LCD. There are neither the groaning slowdowns nor massive spikes in CPU usage that I was getting in Eclipse with the same projects loaded, so the experience is positive all round.
Not to forget that I’ve been using Netbeans for years, so despite the novelty of using an alternative IDE, I somehow feel more productive in Netbeans (though perhaps mainly through familiarity).

So, it would appear that my own “inexorable march to Eclipse” has turned into an all out retreat back into the fold. How does it feel? In the words of Wesley Snipes (in US Marshals, I think): Righteous. Very righteous.

SIDE NOTE: Looking forward to Mustang (Java6) since the fonts in the Linux GTK look-and-feel look even better…

Initially I didn’t like the concept of a workspace in Eclipse, but now I do. Going back to Netbeans, I suddenly miss the facility. I have a bunch of projects I need to use at work, and then another group of projects for various development efforts I’m running at home. I don’t want the work projects visible at home, and I don’t want the home projects visible at work (either way it’s distracting) — but there doesn’t appear to be an obvious way to accomplish this in Netbeans. I can think of a couple of hacks, but none are particularly nice.

Another stunning omission is lack of support for syntax highlighting other languages. Python/Jython highlighting is available with the Coyote project. Not sure what other languages are available, but it seems as if PHP, at least, is not. It’s a bit of a joke that JEdit has had support for C/C++, PHP, shellscripts, etc (basically you name the language and support is probably there) for an age, but Netbeans is up to a 5 release with support for bugger-all other than Java. Yes it’s an IDE and therefore has a different set of objectives to an editor like JEdit, but if you’re a developer working in more than just Java, the omission is glaring. Anyway, doesn’t the “I” in IDE stand for “integrated”?

Speaking of JEdit, the anti-aliased BitStream mono font, also looks acceptable there, so I think I’ll be moving back to JEdit, for my Python projects at least.

I am the mexican jumping bean of IDE usage.

Eclipse performance (Java dev, not python) has suddenly groaned to a halt. 98%+ CPU usage doing even simple operations. Some operations can take a minute or more before the CPU recovers. Performance was okay, before I started attempting to get some legacy code running outside of its framework — so lots of errors per file, and massively bad performance. Increasing memory allocation, fiddling with GC settings, and so on, makes no difference — and turning off auto-compilation makes a modicum of difference, but (IMO) renders the IDE otherwise unusable (personally I don’t think eclipse is designed well-enough to function outside of it’s default mode of operation).

So back to Netbeans to see if it’s any better (my suspicion is, it will be). Gah! There’s that ugly font again. However, this time, a quick google search recommends turning on anti-aliasing, along with choosing a better font than monospace. I was aware the anti-aliasing option was there, but didn’t bother trying it, since last time I tried the results were less than optimal. Now that I think about it, the last time I tried was probably an early beta of Netbeans 4 (or perhaps even back in pre 3.6 days) — and I imagine I only tried with monospace (yuck). To my surprise (and that will teach me for not researching properly to start with) BitStream Vera Sans 12 (with anti-aliasing), looks exceptionally good. Not sure if it’s up to the standard of Eclipse, but actually it might be.

The big question is whether it will still look good tomorrow morning on the 19″ LCD running at 1280×1024, as it does on my laptop (12″ widescreen 1280×800)….

From Simon Phipp’s weblog, an article on redherring about Eclipse:

…companies like Borland and Oracle are seeing their JBuilder and JDeveloper products lose relevance… …Borland has said its 2006 product will be based on the open-source competition. Oracle announced in June that it would lead an Eclipse tooling project and made JDeveloper free.

Personal opinion time, but I think JDeveloper’s loss in market share has a lot more to do with the fact that it was (perhaps still is?) a pile (feel free to guess what I think it’s a pile of). Admittedly I haven’t touched it in a year or so, but I had a colleague who was a fan and whenever I had to help him with something, I always found it too quirky… and not in a good way.

JBuilder, I haven’t used in years. For quite a while, it was my IDE of choice, but after Forte (later to become NetBeans) was available for free — and despite the fact it was an absolute pain in the proverbial at the time, I still moved onto NetBeans as soon as I had the opportunity. But for sentimental reasons, I’m sorry to hear Borland’s market share is dwindling in the Java space, since I’ve used their products since (I think) Borland C++ in the MS-DOS days. But that doesn’t mean I’d want to go back to JBuilder.

More recently, I’ve needed to use an older version of eclipse, in the form of WebSphere Application Developer (WSAD) and very briefly Rational Application Developer (RAD). After initially being impressed with a (small) selection of the tools and wizards built into WSAD, I’ve lapsed back to a state of extreme indifference. I still prefer NetBeans — even though that IDE still doesn’t exactly fit my personal development style either. Fonts are nicer in WSAD, but NetBeans feels more responsive (at least in Fedora, it does); NetBeans doesn’t seem to get in my way as much, but WSAD has tools that are, occasionally, really useful (xml schema validation, springs immediately to mind). The plugins for NetBeans are… well… generally lame, while the plugins for WSAD/Eclipse are as varied as the community itself — but on the other hand WSAD and RAD are, in my opinion, bloated memory hogs. RAD ultimately died a death on my laptop, despite having 1GB of RAM — which is just craziness. I’ve no experience (yet) to indicate whether this is a problem on the Eclipse platform as a whole (on linux), or just a WSAD/RAD specific issue.

To be quite honest, if I could have JEdit, with the slickness of a Netbeans 4 (or even Eclipse 3) look-and-feel, I’d dump both Netbeans and Eclipse in a second. Of course, when I last checked, JEdit’s code-completion plugin was still buggy and, for me at least, pretty unusable — so that rules it out for a lot of developers — but I still use it for Python/Jython development, and the occasional quick java hack. At home, at least, the inexorable march, has taken a side road (that said, I may join the general throng heading towards Eclipse-town, if my experience with pydev proves a success).

portals…

I’m with Rick, there are some things I like about WebSphere Portal… but unfortunately the list of things that annoy me grows ever longer. Some aren’t necessarily IBM’s fault — the whole portlet framework is flawed; entirely too intrusive, somewhat obscure (some things are as obvious as a polar bear in a snowstorm), and at times, downright painful:

  • support for other templating mechanisms is seriously limited (read: non-existent). I’m using Velocity, but it wasn’t without significant effort (think of those taglibs you use in JSP, then imagine portlet life without them — and the taglibs use functionality that’s not covered in the javadocs). Yes, I probably should have used JSPs (and next time, will), but I prefer Velocity — particularly for complex pages.
  • features that you might think would be easy to control, are either impossible, or at the very least excessively difficult: How do you get the name of the page that a portlet is running inside? Why is changing the mode of the portlet so difficult? etc
  • the user interface…. shudder
  • portlet reusability is a pain - the process of copying and reusing an individual portlet should have minimal cost associated with it (and not involve copying the entire web application)
  • pages layouts are nowhere near flexible enough
  • the html page header should be (at least semi) accessible; for including javascript files, stylesheets and so on, without having to embed them in the page
  • from the WTF files: vaults, segments, credentials, etc (API design-by-monkey)

Those are just off the top of the head, and without mentioning the horrific memory usage, the fact that the html generated by Portal is horrible, the lack of an independent test environment, the fact that the test environment won’t install on my Fedora laptop without having a few million terabytes… of RAM, and the server tends to crash on occasion if you’re doing lots of webapp updates (which, of course, you do during development).

Okay, so I did mention them.

Gah!

I take it all back.

Currently rolling back to Websphere Application Developer 5.1.2 (from the nicer looking RAD6). I originally made the move to RAD because it seems that the Portal Test Environment doesn’t work with WAD5.1.2 on Linux, and rumour has it that the TE does work on Linux with RAD6…

However, after spending 5 hours on an install, one takes the time to read some docs & forum messages, and discovers that the minimum system requirements for installing the portal test environment is 2GB of RAM!?!@!#? (obvious rejoinder: why the hell didn’t I check first? answer: who expects an install to require 2GB?)

A couple of thoughts jump immediately to mind — both unprintable.

In any case, not only is the installation an impossibly long task on my development system, the RAD6 environment doesn’t make a huge amount of sense compared with WAD5. Websphere Server settings in particular don’t appear to be where I expect — and it’s difficult to justify taking the time to figure it all out at the moment, when I already know how to debug in ver.5.

So, back to WAD for the moment. Which won’t make life easy to test portlets, and doesn’t have anywhere near as attractive an interface, and acronym. Sigh.

I’ve recently moved to using Rational Application Developer [edit: now RAD, not WAD]. Not out of choice. I’ve played with Eclipse a few times in the past, but never been particularly impressed - which makes me one of few, it seems, considering the mindshare that eclipse has garnered.

There are a number of things which I find annoying, among them the intrusiveness of the IDE, an inability to customise directories and path structures in a way which I am familiar with, and so on. Worst of all, there’s a sense of deja vu harking back to the days when I (briefly) used VisualAge (shudder), and even though Eclipse/WAD/RAD aren’t close to being that horrific, there’s still guilt by visual association.

However, I do like the integrated test environments — which came as a surprise, since with NetBeans I have generally gone into the options, turned off pretty much every module, and then scripted the bejeezus out of the command line to do everything I want (outside of the IDE). I’ve always found the scripted approach (either using Python or Jython or plain old bash) more powerful — but admittedly the RAD style is growing on me…

…probably like a fungus.

Up until now, I have used Log4j in most of my development efforts — be they personal, open-source or corporate (there’s an argument I should have been using a logging bridge of some kind, to insulate any 3rd party users of my code from having to use my logging system of choice — but most of the work I’ve been doing hasn’t had a huge number of 3rd party users, so it hasn’t been that much of an issue). However, I recently came across Graham Lea’s simple-log; the basic premise of which appeals to my drive to simplify things as much as possible. So, bye bye, Log4J, it’s been great!

I’m currently running a couple of java applications which rely on the commons-logging bridge, alongside of which I use velocity (which itself uses Avalon LogKit or Log4J by default). In order to integrate simple-log and drop log4j out of my lib path, I need to provide a logging implementation for commons-logging, and also change the default velocity runtime logsystem.

SimpleLogger.java (stick your own package in front of it), does both. To use it, make sure you set the runtime property for commons, e.g.:

-Dorg.apache.commons.logging.Log=yourpackagehere.SimpleLogger

and then set the logsystem for velocity (where ve is the VelocityEngine), using the same property:

ve.setProperty(VelocityEngine.RUNTIME_LOG_LOGSYSTEM_CLASS,     System.getProperty('org.apache.commons.logging.Log'))

Read the rest of this entry »