Rob Gordon is a seasoned Java developer and a big fan of open source. Oddjob is his own open source project to make job scheduling and task automation in Java much much easier. Rob is based in London. Rob is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Why I Wrote Yet Another Java Bean Framework

02.08.2012
| 5709 views |
  • submit to reddit
With so many Java Bean XML and dependency injection frameworks out there – did I really need to write another? Am I suffering from some terrible ‘Not Invented Here’ syndrome? In this post I’m hoping to persuade myself that I’m not, and hopefully I can persuade you that it might be worth a look too.

It all came down to Drag and Drop. I wrote my own framework because I couldn’t find another that allowed beans to be Cut, Pasted and Configured in place – while running – no restart required!

Here it is working between two server processes, scroll quickly for that Flip Book animation effect!

Oddjob Drag and Drop 1

Oddjob Drag and Drop 2

Oddjob Drag and Drop 3

What’s going on? – I’m dragging the XML configuration for a bean from one server process to another. Here are those server processes:

Oddjob Drag and Drop Servers

Now I’m going to drag that job straight into this post…

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<echo id="echo-job"><![CDATA[Hello from ${server.name}]]></echo>

 …and no I didn’t cheat!

Here is that server drag and drop again, except in code:

public class CutAndPaste {
 
    public static void main(String... args) throws Exception {
 
        Oddjob oddjob = new Oddjob();
        oddjob.setConfiguration(new XMLConfiguration(new File("client.xml")));
 
        oddjob.run();
 
        OddjobLookup lookup = new OddjobLookup(oddjob);
 
        DragPoint drag1 = lookup.lookup("client1/server-jobs", ConfigurationOwner.class
                ).provideConfigurationSession().dragPointFor(
                        lookup.lookup("client1/server-jobs/echo-job"));
 
        String copy = drag1.copy();
        drag1.cut();
 
        DragPoint drag2 = lookup.lookup("client2/server-jobs", ConfigurationOwner.class
                ).provideConfigurationSession().dragPointFor(
                        lookup.lookup("client2/server-jobs/job-folder"));
 
        drag2.paste(0, copy);
 
        Runnable job = lookup.lookup("client2/server-jobs/echo-job", Runnable.class);
 
        job.run();
 
        oddjob.destroy();
    }
}

I also run the job in its new location – just for good measure.

Now many of you will be saying ‘Why would I want anyone dragging around my applications configuration!’, and yes, in production this is quite dangerous and most of the time you probably do want all your beans and their dependencies locked down.

But sometimes it might be really useful to have a bit of flexibility with your remote components configuration, and for those sometimes I wrote a cut and paste Java Bean XML based dependency injection framework.

Now I’m expecting lots of feedback telling me that XYZ framework will do this already, and I’m looking forward to it, and I don’t mind – because there is another reason I wrote the framework, the main reason… I loved every minute of it!

 

Source: http://rgordon.co.uk/blog/2012/02/03/why-i-wrote-yet-another-java-bean-framework/

Published at DZone with permission of Rob Gordon, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andreas Haufler replied on Thu, 2012/02/09 - 3:05am

Your approach looks quite interesting. As far as I'm concerned, I fully understand why it's sometimes better to write your own framework instaed of using a *already-there* 1000+ classes monster.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.