However, it is important, I feel, that we acknowledge the intent of this was never to harm indigenous people. It was to enforce child-protection laws, which mandated that no child, regardless of racial background, should be forced to live in substandard conditions. These conditions were rife in indigenous communities at the time, and they still are - witness the case of the teenage girl gang-raped at the age of 7; the only reason this even made the news is because the prosecutor decided to let the perpetrators go.
If non-indigenous children were treated in such fashion, the parents would certainly lose their children. It happens all the time - that's why we have organisations such as the Department of Child Safety. For us to tolerate in indigenous communities what we would not tolerate in mainstream society is not "respect for their culture" - it's a revolting acknowledgement that indigenous Australians are not ready to partake in mainstream society.
It is wrong that our governments had to take the children away. It is vastly more wrong that we permitted, and continue to permit, these conditions. Rampant abuse of children has created and perpetuates a cycle of dependence in indigenous communities, and this cycle must be broken somehow. It is our failure to do this, or even to accept a need to do this, that we should apologise for. It is the failure of indigenous Australians to break out of this cycle by themselves that makes the apology somewhat pointless.
(All that said, I'm not in favour of the so-called intervention policies of the last days of the Howard government. We do not need to create special laws to deal with the situation; we need to enforce the ones we have, along with creative programs to achieve results by building communities up instead of tearing them apart)
]]>
Story: transfer from savings to checking account
As a savings account holder
I want to transfer money from my savings account to my checking account
So that I can get cash easily from an ATM
Scenario: savings account has sufficient funds
Given my savings account balance is $100
And my checking account balance is $10
When I transfer $20 from savings to checking
Then my savings account balance should be $80
And my checking account balance should be $30
Scenario: savings account has insufficient funds
Given my savings account balance is $50
And my checking account balance is $10
When I transfer $60 from savings to checking
Then my savings account balance should be $50
And my checking account balance should be $10Yes - that's the test, not the story. You can take that and run it through the RSpec tool, and it will tell you if it passes or fails. And I think even a BA can understand the test.
Okay, there's a lot of magic going on here. I'll do my best to walk you through it, but please remember that I'm not a Ruby person - my total experience in Ruby before starting this was about 12 hours (it's now about 20); don't pick on my Ruby skills (but do feel free to offer suggestions for improvements).
The end goal of this is to test Java code. That means my RSpec tests, which are backed by Ruby, need to be able to call my Java code. JRuby to the rescue! JRuby, in case you didn't know, is a Ruby interpreter for the JVM, which allows for pretty decent integration between Java code and Ruby. Here's a very simple Ruby script that invokes Java code:
require 'java'
include_class 'java.lang.System'
System.out.println "Hello World"You can save that as a script and invoke it with jruby - jruby hello.rb - or enter it interactively via jirb. Note that if you do this, the require 'java' step returns false now - there's a lot of slightly-dated examples on the net which says it should return true, but that apparently changed a little while back.
JRuby seems to come with RSpec, but it's a slightly old version - 1.1.0, while the current release is 1.1.3. So the first order of business is to update. Ruby uses a packaging tool called 'gem' - you can use gem to download new packages, or update packages, over the web.
$JRUBY_HOME/bin/gem install rspecMake sure you're running the 'gem' command inside JRuby's bin - if you've got ruby on your system already, you don't want to get mixed up. (Alternatively, you can make Ruby and JRuby share their gems, if you want).
This will put the RSpec library at $JRUBY_HOME/lib/ruby/gems/1.8/gems/rspec-1.1.3; pay attention to that path, because amongst other things, there are examples there!
Okay, I told a slight lie - if we put the test above in a file called 'account', we're going to want to create a file called 'account.rb'. The example above isn't valid Ruby, and we need something that is. However, it's not very big (and it's going to get smaller):
require 'rubygems'
gem 'rspec'
load 'spec/story.rb'
# don't worry - we'll define accounts later
with_steps_for :accounts do
# Ruby code for "run the file named like this one, but without the .rb extension"
run File.expand_path(__FILE__).gsub(".rb","")
end(RSpec people out there - I just want to point out that it took me about 3 hours to figure out the first 3 lines - couldn't find any examples of using RSpec as a gem that wasn't build up with a Rails app. Okay, someone who knew Ruby would figure it out, but it took me a while to work out why I couldn't run my examples except from within the RSPec examples dir).
You then run the test like so - jruby account.rb - and you should get output like this one (and this is the only example I'm showing in full!):
Arcadia:jrspec robertdw$ ruby account.rb
Running 2 scenarios
Story: transfer from savings to checking account
As a savings account holder
I want to transfer money from my savings account to my checking account
So that I can get cash easily from an ATM
Scenario: savings account has sufficient funds
Given my savings account balance is $100 (PENDING)
And my checking account balance is $10 (PENDING)
When I transfer $20 from savings to checking (PENDING)
Then my savings account balance should be $80 (PENDING)
And my checking account balance should be $30 (PENDING)
Scenario: savings account has insufficient funds
Given my savings account balance is $50 (PENDING)
And my checking account balance is $10 (PENDING)
When I transfer $60 from savings to checking (PENDING)
Then my savings account balance should be $50 (PENDING)
And my checking account balance should be $10 (PENDING)
2 scenarios: 0 succeeded, 0 failed, 2 pending
Pending Steps:
1) transfer from savings to checking account (savings account has sufficient funds): my savings account balance is $100
2) transfer from savings to checking account (savings account has sufficient funds): my checking account balance is $10
3) transfer from savings to checking account (savings account has sufficient funds): I transfer $20 from savings to checking
4) transfer from savings to checking account (savings account has sufficient funds): my savings account balance should be $80
5) transfer from savings to checking account (savings account has sufficient funds): my checking account balance should be $30
6) transfer from savings to checking account (savings account has insufficient funds): my savings account balance is $100
7) transfer from savings to checking account (savings account has insufficient funds): my checking account balance is $10
8) transfer from savings to checking account (savings account has insufficient funds): I transfer $20 from savings to checking
9) transfer from savings to checking account (savings account has insufficient funds): my savings account balance should be $80
10) transfer from savings to checking account (savings account has insufficient funds): my checking account balance should be $30phew Okay, we can see that it's run the test, but hasn't exactly done very much. Mostly, it's said that the test steps were "PENDING". Pending is RSpec's way of saying "I don't know what you mean". So now we have to tell it.
You tell RSpec what the test means by providing "steps". These steps are usually provided in separate files, but I'm going to put them all in one step file. First, though, I have to update my test script. It now looks like this:
require 'rubygems'
gem 'rspec'
load 'spec/story.rb'
# This ruby code loads all the scripts inside of the 'steps' directory.
Dir[File.join(File.dirname(__FILE__), "steps/*.rb")].each do |file|
require file
end
with_steps_for :accounts do
run File.expand_path(__FILE__).gsub(".rb","")
endThe bit in the middle, of course, is the important bit. So we now create an 'accounts_steps.rb' file, inside a steps directory. And it's going to look like this:
require 'rubygems'
gem 'rspec'
load 'spec/story.rb'
# This creates steps for :accounts
steps_for(:accounts) do
Given("my $account_type account balance is $amount") do |account_type, amount|
end
When("I transfer $amount from $source_account to $target_account") do |amount, source_account, target_account|
end
Then("my $account_type account balance should be $amount") do |account_type, amount|
end
endHow do I know what to fill in? The RSpec output from earlier was kind of telling me; essentially, I just create a template. If I run the test again, I get a very simple output back indicating no errors (at least, I do if I've done it right...).
This test, however, doesn't test squat. There's no actual work done in any of the tests! Just as a place holder, I went back and put the word pending inside each block, like so:
Given("my $account_type account balance is $amount") do |account_type, amount|
pending
endWhen I run the test again, I get the big (PENDING) warnings again - but at least now I know that RSpec is understanding my test.
At this point, it's time to start putting some code to test in. Here's the Java class that I'm going to test:
package net.twasink.jrspec;
public class Account {
private final String name;
private double balance = 0.0; // NEVER use double for monetary values in the real world.
public Account(String name) {
this(name, 0.0);
}
public Account(String name, double openingBalance) {
this.name = name;
this.balance = openingBalance;
}
public String getName() { return name; }
public double getBalance() { return balance; }
public void transfer(Account destination, double amount) {
if (amount <= 0.0) { throw new IllegalArgumentException("amount must be positive"); }
if (balance < amount) { throw new IllegalStateException("Insufficent balance"); }
this.balance -= amount;
destination.balance += amount;
}
}I compile that, and I put the results on my classpath. It's now available for JRuby to use. (Actually, I've got a shell script to do this for me; it's all in the archive at the end). So now I can start making Java calls. And what I end up with is this:
require 'rubygems'
gem 'rspec'
load 'spec/story.rb'
require 'java'
include_class 'net.twasink.jrspec.Account'
# This creates steps for :accounts
steps_for(:accounts) do
Given("my $account_type account balance is $amount") do |account_type, amount|
create_account(account_type, amount[1..-1].to_f)
end
When("I transfer $amount from $source_account to $target_account") do |amount, source_account, target_account|
begin
get_account(source_account).transfer(get_account(target_account), amount[1..-1].to_f)
rescue
end
end
Then("my $account_type account balance should be $amount") do |account_type, amount|
get_account(account_type).balance.should == (amount[1..-1].to_f)
end
end
def create_account(account_type, amount)
account = Account.new(account_type, amount)
@accounts_hash ||= {}
@accounts_hash[account_type] = account
end
def get_account(account_type)
return @accounts_hash[account_type]
endRun the test again, and everything passes. Just to confirm, I edited some of the values to give me test failures, and sure enough, they were reported as failures.
So there you have it! Real live running RSpec code, testing Java classes.
There's a little more house-keeping to do, which you'll see in the archive. First, I created a "helper" file, that would provide support for several stories together. Then, I moved the accounts stories, its steps folder, and the helper, into a sub-folder, to create a "story group", and added an "all.rb" script that would run all the story groups (as well as a stories.rb script to run all the stories in a group). Finally, I bundled this all up into two Java projects (built via Maven), along with a shell script to run RSpec/JRuby with the right classpath. All in all, not bad for a day and half's effort. And you can grab a copy of it all if you so desire.
This isn't perfect by any means. I've got a few itches to scratch with this yet:
Lots of fun to be had. Hope you've enjoyed reading this, and can take something away. Please bear in mind that I'm not a Ruby expert, so if you need help troubleshooting this stuff, I suggest you go to the appropriate user communities. OTH, if you've got suggestions or improvements on my technique, or comments about the approach, I'd love to hear from you; the comments box is just below.
]]>
List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger")
.setEntity("blogger", blogger)
.setMaxResults(15)
.setCacheable(true)
.setCacheRegion("frontpages")
.list();(The example code has been lifted from the Hibernate on-line manual).
On the surface, this sounds like it would cache the results of the query until the (separately configured) cache expires the results. And if you never change any data, that's what happens. The catch, however, is that any change to any of the criteria fields results in the cache being invalidated.
Let's go for a realistic example. Customers have Orders. You create a page where customers can browse their order history. This doesn't have to be up-to-the-minute, so you put a query cache in, with a suitable expiry policy. The query would look similar to the above: from Order order where order.customer = :customer. So far so good. In testing, you verify that, yes, the query cache works and the database is not repeatedly called with queries.
However, when this goes live, the database starts getting swamped with these queries. It's almost like the query cache isn't getting used at all. Why? Because every time a customer (any customer) places an order, all the cached query results get removed - even if they were for a different customer.
This explains a little throw-away line in the Hibernate manual:
"Most queries do not benefit from caching, so by default queries are not cached."
Why do most queries not benefit from caching? Because, in order to get cache hits, you need to essentially be querying for static or nearly-static data.
BTW, the same goes for collections. If your Customer class has a collection of Orders, you can define that collection to be cacheable; it's a separate cache from the Customer object, but it's cacheable. However, as soon as any order is made - or even merely modified - the cache will be invalidated.
This can make one-to-many relationships insanely expensive, particularly non-lazy ones; every time the entity goes into a session, the collection will be populated - even if the entity was already in the second level cache. If that collection cache is invalidated, as it probably is, then a database query will be run to populate the collection. If these objects also have a collection cache (think Customer -> Order -> Order LineItem), you will get N queries run. Go 4 levels (SalesPerson.getRecentCustomers()?), and you get n*m queries. Ouch.
Hibernate has very flexible caching policies for entities, but no flexibility around the relationships between the entities. This is a shame, particularly for the query caches - it means that for a number of types of applications, you need to build a separate caching layer above Hibernate, simply because the query caches get wiped far too often. At the very least, the Hibernate documentation could explain this better, elaborating on exactly why "most queries do not benefit from caching".
]]>Here's a short list, before I define what I mean by "suck":
and I'm sure that there's more that will come to me. Today, I'm doing Maven - the rest will come later.
]]> What do I mean by "suck"?Mostly, I mean "it doesn't do what I want it to do". Most of these things actually have a lot of positive aspects to them, but there are features about them that just piss me off.
We shifted to using Maven2 at work about this time last year. What a can of worms that was. I'm going to stress here that it was certainly a net-positive move, but it was a very bumpy ride. (I'm just going to call it Maven from here on)
The basic idea of Maven is great, and there are two sweet spots that Maven hits very well - building JARs, and building single webapps. If you're doing one of these, particularly if you're doing an open-source one, then Maven will have a lot of positive things for you. But if you're building more complex things, then Maven will almost certainly throw a few roadblocks in the way.
First, it's buggy, and the bugs don't get fixed fast. Great example - the Surefire plugin (the JUnit testrunner) 2.2 was released in April 2006. It was the version used by default in Maven 2.0.4 (also released in April 2006), and in Maven 2.0.5 (released January 2007). It had a bug - a pretty nasty one. When you ran several tests at once, the XML log files for a given test contained all of the tests run previously as well. Our Cruise builds were reporting our builds had nearly half a million tests, instead of the couple of thousand they should have. You can imagine the size of the log files, too. And, of course, if one of the early tests failed, then you had a couple of thousand test failures reported.
The bug was reported 22 May 2006. It was reported again on 17 July, 05 August, 10 August, 11 October and 24 March 2007. 3 of those were marked as Major, while 2 were marked as "Cannot Reproduce". A precise fix for the problem was mentioned on 9 August, with a 6-line patch provided (by the same person) on 28 August. This fix - for a Major bug identified 5 times that essentially broke the plugin for use in a CI environment - wasn't applied to the codebase until 27 November 2006. They didn't get a 2.3 release out until 23 February - too late for the Maven 2.0.5 release in January. (You could select it explicitly if you wanted to, but you had to know to do so) So it didn't get into the mainstream until 1 April 2007 (and who releases software on April Fool's Day?) - over 10 months after the original buggy release, on a project that brags about how it can be used to quickly push bug fixes out.
On average, our builds have just stopped dead due to a bug from a Maven plugin every 2 months or so. The fun ones are for the bugs in plugins that "auto-update" (i.e. don't have pinned versions). Case in point - over Christmas, the Maven Invoker plugin 1.1 was released. Somehow, this broke the Antrunner plugin so that if it was invoked in a multi-module reactor build, the working directory was changed. This broke one of our modules - but only if you invoked the module as part of a multi-module build. If you built the module by itself, it worked fine. Makes it easy to debug when the problem goes away when you try to reproduce it!
Combining multi-module builds causes fun interactions. The best one I've got is that the classpath for a plugin can only be set once. So, as a purely hypothetical example, if you had, oh, one module that wanted to run SQL against, say, an Oracle database, using the SQL plugin, and another module that wanted to run SQL against, say, a MySQL database, you have to give both modules both sets of JDBC drivers. (Why do it for both? Because Maven isn't deterministic between versions/JDKs for modules that don't have any dependencies - i.e., you can build them in any order).
Then there's the quality of the POMs. Commons Logging is a great example - here's a tool designed to isolate you from the exact logging library you use, and it brings in 3 logging libraries into your "compile" scope, one of which is Log4J which commons-logging "greedily" looks for. It also brings in the servlet API for some reason - again, at "compile" scope. Now, sure, you could use the commons-logging-api module instead. Except nobody else does. So if you're not using commons-logging explicitly (and unless you're building an open-source JAR to be used by someone else, why would you?) you have to deal with these stupid dependencies that should never have been forced on you.
Now, it's not hard to fix this. Create a <dependencyManagement> section (preferably in the parent POM for your multi-module project) and define the exclusions for commons-logging. Except that, sometime between Maven 2.0.4 and Maven 2.0.6, this stopped working for transitive dependencies (esp. if the dependency was third-or-more hand). So you use, say, commons-beanutils, and it brings in Log4j. WTF??? Furthermore, the exact place that this occurs in the transitive hierarchy seems to shift between Maven versions. The short version of this is that I have had to alter POMs with 3 of the 4 Maven releases since I started using Maven just to cope with build breakages caused by upgrading Maven.
I mentioned earlier that Maven has a sweet spot with building webapps. The sour spot is building EAR files - especially if you've got multiple webapps. Why? Because Maven will try to shove all the libraries into the WEB-INF of the webapps - great for building standalone webapps, bad for EARs where you want to put the libraries in the EAR instead (to share with any EJBs, or just to reduce duplication between webapps). Now, the WAR plugin for maven does realised this, so they give a simple switch to turn off the "bundle in the WEB-INF" behaviour. So far so good.
Except that many web-frameworks (notably Struts and WebWork (aka Struts2)) use static variables for configuration (the "static-as-singleton" antipattern). So if you put two Webwork-based webapps in the same EAR, you need to bundle the Webwork libraries in the WEB-INF/lib dir of each webapp. Except the only way to do this with Maven is to go through and explicitly make all the other dependencies "provided" scope and THEN go into the EAR's pom and make them all "compile" scope so that they get bundled in the EAR. Aaarggh!
You also absolutely have to set up your own internal Maven repository, and pin down all the versions of both dependencies and the plugins. Without this, you don't get repeatable builds - ie, you can't go back, say, six months in your source control and do a build (even if you use the same version of Maven you did then). The plugins would have changed, and they change in incompatible ways. Some of those ways are just designed to make your life a pain - case in point with the Surefire plugin is that they changed what the default values of some options were. However, there are no good and easy ways to do an internal Maven repository (though there are some getting better).
Multi-module builds and versioning are a pain. You can define a parent POM for your POM - you can even specify a relative path to the parent POM. However, you have to specify the version number of the parent POM - it can't just look it up from the relative path. So if you have, say, a dozen modules in your project, you've repeated the version of the parent POM 12 times. WTF??
Some petty gripes to wind up on:
<dependency groupId="foo" artifactId="bar" version="1.2.3" scope="compile">? BTW, this repetition tosses away any size benefits of Maven vs Ant - when I migrated from Ant to Maven, the total byte size of the build files went up by about 10% (the line count went up by about a third). Today, I'm averaging about 25 lines of Java code for every line in our POMs.To finish, I'll just quickly pre-empt most of the comments I'm likely to get:
FWIW, I don't think the current state of Maven, and the Maven community in particular, is going to last. Either the tool and the community will mature (and get less defensive), or it's going to fall over in a flaming heap and be replaced by something better. If I had to bet, my money would be on the latter - probably around the end of the year, or early-to-mid next year. The Java community wants a tool like Maven, needs a tool like Maven - that's the only reason why a tool as shitty as Maven has developed such a large following. What it needs is a better Maven.
]]>At the end of all this, turning the integration with Tourico on was somewhat of an anti-climax - we pushed the button marked "On", and it just worked.
Now maybe I can get my life back for a bit. :)
]]>Secondly, let's talk about what the TIOBE index actually is. It's a measure of how many hits you get back from a search engine when you enter in "<language> programming". That's it. In my highly unscientific search on google just then, I found that java programming got back about 176,000,000 hits, while ruby programming got 55,000,000 hits. Yahoo got 48,500,000 and 16,800,000, while MSN got 18,507,589 and 1,634,857. So Google and Yahoo think that Java's about 3 times more popular than Ruby, while TIOBE and MSN think it's about 8ish.
(Curiously, all of the search engines said Ruby was more popular than C# - 35,000,000, 15,200,000 and a mere 354,986 hits on the respective search engines. But C# has a higer TIOBE rating than Ruby - 3.656% vs 2.632% for Ruby)
Furthermore, this doesn't even look at the popularity of certain related keywords. For example, on Google, j2ee programming gets 17,300,000 hits while rails programming gets 24,200,00 hits. So Rails programming is almost 50% more popular than J2EE programming!
Internet search hits aren't the only measure, anyway. What about book sales, for example, where Ruby enjoyed a 68% growth in sales in Q1 '07 (compared with Q1 '06) in a shrinking market? Personally, I'd pay more attention to interest expressed in dollars spent than I would to internet hits.
For the record, I'm not a Ruby developer - I'm a J2EE specialist with about 8 years of solid Java experience (plus a few years of other stuff) behind me. Ruby looks nice, but I've never taken enough time to play with it, let alone seriously work with it. But people who push news like this out of context and celebrate the "death" of a programming language (especially prematurely!) disgust me. Get a life, guys, and learn how to read the stats, not read your own opinion into them.
]]>I've worked at three startups now (though never at the really early stages). When they lose this feel, the change was always dramatic and noticeable - it's not a question you ask, but a realisation that hits you like a punch to the stomach. If you have to ask the question, you're probably still a startup. :)
The most noticeable sign you're no longer a startup - when you get concerned about defending marketshare rather than how to grow it. The change to a defensive, risk-adverse mindset kills the startup mentality (risk-adverse startups don't even get off the ground). I'd also say that becoming a publicly listed company kills the startup mindset as well.
Wotif lost the startup feel about 18 months ago, I think. Don't get me wrong - it's still a great place to work, with great people - but it's not a startup anymore, and to be honest the change wasn't positive. It's a comparable size to Atlassain in most ways - similar employee & revenue size (126 employees, AU$45.5million in revenue for FY2006), but it's not a startup anymore. Congratulations on keeping the startup feel, Mike, and keep those world-class products coming.
]]>With apologies to Mastercard.
]]>Update: It looks like the Interface21 guys have had similar ideas - check out Project Pitchfork
]]>Well, back in the days of EJB 2, you would make a reference to an EJB using the following incantation:
<bean id="myEjb" class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
<property name="jndiName" value="java:comp/env/ejb/MyEjb" />
<property name="businessInterface" value="net.twasink.ejb.MyEjb" />
</bean>Simple enough; the LocalStatelessSessionProxyFactoryBean knows how to create a Stateless Session Bean, via the Home interface, which is what the JNDI entry points out. There's a couple of different proxy factories, for the various types of EJBs.
In EJB3, you don't need Home interfaces any more. As a result, you don't need to use a LocalStatelessSessionProxyFactoryBean either. Instead, you use the standard JndiObjectFactoryBean:
<bean id="myEjb" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/ejb/MyEjb" />
<property name="expectedType" value="net.twasink.ejb.MyEjb" />
</bean>So this is pretty simple: look the EJB up in the JNDI, register it as a Spring Bean, and then wire it into other Spring Beans as normal. So far so good.
Or is it? Well, this has got a major problem: you need to specify the EJBs. One of the big selling points of EJB 3 is that you don't have to manage any XML files, and here comes Spring making you do it all over again! How annoying!
Fortunately, there's a solution: BeanPostProcessors. BeanPostProcessors lets you do things to a bean after its created. Things like looking for setter methods with an @EJB annotation on them, for example.
Here's the code:
/** Look for EJB3-style annotations, and provide the corresponding values from the container. */
public class EjbBeanPostProcessor implements BeanPostProcessor {
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
// do nothing; the EJBs are configured before initialization.
return bean;
}
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
Class beanClazz = bean.getClass();
for (Method method : beanClazz.getMethods()) {
if (method.isAnnotationPresent(EJB.class)) {
setEjbRef(bean, method);
}
}
return bean;
}
private <T> void setEjbRef(T bean, Method setter) {
Class ejbClass = determineBeanClass(setter);
Object ejbBean = lookupBean(ejbClass, determineJndiName(ejbClass, setter), bean);
invoke(bean, setter, ejbBean);
}
/**
* Determine the JNDI name for the EJB. By default, we assume that it is the simple class
* name, but we allow the setter method to override this, using the 'mappedName' attribute.
*/
private String determineJndiName(Class ejbClass, Method setter) {
EJB ejbAnnotation = setter.getAnnotation(EJB.class);
if (ejbAnnotation.mappedName().equals("")) {
return ejbClass.getSimpleName();
}
return ejbAnnotation.mappedName();
}
private Object lookupBean(Class ejbClass, String beanName, Object bean) throws BeansException {
try {
return new InitialContext().lookup("java:comp/env/ejb/" + beanName);
} catch (NamingException e) {
throw new EjbBeansException(bean, "Could not resolve EJB " + beanName, e);
}
}
/**
* Determine the type of the EJB. This is used to determine the JNDI name to look up. This
* would normally be the type of the argument to the setter, but the EJB spec allows this
* to be overriden (presumably to a subclass)
*/
private Class determineBeanClass(Method setter) {
EJB ejbRefAnnotation = setter.getAnnotation(EJB.class);
if (ejbRefAnnotation.beanInterface() != null &&
Object.class.equals(ejbRefAnnotation.beanInterface()) == false) {
return ejbRefAnnotation.beanInterface();
}
Class otherBeanClass = setter.getParameterTypes()[0];
return otherBeanClass;
}
private <T> void invoke(T bean, Method method, Object ... args) {
try {
method.invoke(bean, args);
} catch (IllegalArgumentException e) {
throw new EjbBeansException(bean, "Could not set EJB", e);
} catch (IllegalAccessException e) {
throw new EjbBeansException(bean, "Could not set EJB", e);
} catch (InvocationTargetException e) {
throw new EjbBeansException(bean, "error setting EJB reference", e.getCause());
}
}
/** Simple exception detailing the type of problem that occured. */
private static class EjbBeansException extends BeansException {
public EjbBeansException(Object bean, String message, Throwable cause) {
super(message + " [bean class: " + bean.getClass().getName() + "]", cause);
}
}
}Having created this lovely BeanPostProcessor, you enable it in your Spring context file with a simple one-line statement, defining the post-processor:
<bean class="net.twasink.EjbBeanPostProcessor" />Now, you simply need to add @EJB references to your Spring beans, and they will magically be set. No need to list the EJBs in your Spring context files or anything - it just works. It also works with anything else using Spring; we have all our WebWork actions configured this way now.
The only caveat to this is that you need to have the JNDI context set up. In a web application, for example, this means you need to have the ejb-ref entries in your web.xml file.
I hope you find this useful; I know I have.
]]>But how do you get a Spring-managed bean from an EJB? The answer: dependency injection, of course. That is, with the aid of a EJB Interceptor:
public class SpringBeanInterceptor {
private BeanFactory beanFactory;
@PostConstruct public void configureSpringBeans(InvocationContext context) throws Exception {
for (Method method : context.getTarget().getClass().getMethods()) {
if (method.isAnnotationPresent(SpringBean.class)) {
Class springClass = method.getParameterTypes()[0];
String springName = determineSpringBeanName(method, springClass);
Object springBean = beanFactory().getBean(springName);
try {
method.invoke(context.getTarget(), springBean);
} catch (IllegalArgumentException e) {
throw new RuntimeException(e);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
} catch (InvocationTargetException e) {
throw new RuntimeException(e.getCause());
}
}
}
context.proceed();
}
private String determineSpringBeanName(Method method, Class springClass) {
String springName = method.getAnnotation(SpringBean.class).value();
if (springName.length() > 0) {
springName = toCamelCase(springClass.getSimpleName());
}
return springName;
}
private String toCamelCase(String string) {
return Character.toLowerCase(string.charAt(0)) + string.substring(1, string.length());
}
private BeanFactory beanFactory() {
if (beanFactory == null) {
BeanFactoryLocator locator = ContextSingletonBeanFactoryLocator.getInstance("classpath*:beanRefContext.xml");
BeanFactoryReference ref = locator.useBeanFactory("applicationContext-service");
beanFactory = ref.getFactory();
}
return beanFactory;
}
}
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface SpringBean {
String value() default "";
}That's it. This Interceptor will look over an EJB, after it's created, and provides the Spring beans. This version looks for 'setter-methods' with an @SpringBean annotation (you could also change it to look for fields), and looks up a corresponding bean from the Spring context (the ContextSingletonBeanFactoryLocator makes this possible).
Here's how you would use it:
@Stateless
@Interceptors(SpringBeanInterceptor.class)
public class MyServiceBean implements MyService {
private MySpringBean bean;
...
@SpringBean public void setMySpringBean(MySpringBean bean) {
this.bean = bean;
}
}With this (and one other trick I'll discuss soon), you can (nearly) seamless integrate EJB3 and Spring.
The one big limitation of this: with Stateless Session Beans, you can only inject stateless dependencies, and you can only inject them when the EJB is initialised.
]]>As of EJB 3, however, it's no longer necessary. instead, it is fairly trivial to mock out the container entirely (and safely!)
]]> I'm not talking about classic unit-tests, where everything is mocked out. You could already do that with EJB2 without too much hassle. No, I'm talking about tests that basically wire everything up the way it is when deployed, including such things as:How do you do it? Simple: you write a factory that creates your EJB instance and wires it up for you. This can be done through the power of reflection - by looking at the annotations.
(In theory, you could have done this with EJB2, as well, but the external deployment descriptor made it painful).
Enough talk. Here's some code that demonstrates this:
public class EjbFactory {
public interface EjbMocker {
<T> void provideMocks(T bean);
}
private Map beans = new HashMap();
private final EjbMocker mocker;
public EjbFactory() {
this(new NoMocks());
}
public EjbFactory(EjbMocker mocker) {
this.mocker = mocker;
}
public <T> T createEjb(Class<T> service) {
T bean = createBean(service);
T decoratedBean = decorate(bean);
registerEjb(service, decoratedBean);
addEjbRefs(bean);
runCustomInterceptors(bean);
postConstruct(bean);
mocker.provideMocks(bean);
return decoratedBean;
}
private <T> void runCustomInterceptors(T bean) {
if (bean.getClass().isAnnotationPresent(Interceptors.class)) {
// TODO: This really should be built up as a chain, not a loop.
Class[] interceptors = bean.getClass().getAnnotation(Interceptors.class).value();
InvocationContext context = new MockInvocationContext(bean);
for (Class interceptorClazz : interceptors) {
postConstruct(newInstance(interceptorClazz), context);
}
}
}
private <T> T newInstance(Class<T> clazz) {
try {
return clazz.newInstance();
} catch (InstantiationException e) {
throw new RuntimeException(e);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
}
private <T> T createBean(Class<T> service) {
try {
if (service.isAnnotationPresent(Stateless.class)) {
return newInstance(service);
}
if (service.isInterface() == false) {
throw new RuntimeException("Trying to mock a non-service: " + service.getName());
}
Class serviceClass = Class.forName(service.getName() + "Bean");
return (T) newInstance(serviceClass);
} catch (ClassNotFoundException e) {
throw new RuntimeException("Could not find bean class for " + service.getName());
}
}
private <T> Object registerEjb(Class<T> service, T bean) {
return beans.put(service, bean);
}
private <T> T decorate(T bean) {
return bean;
}
private <T> void addEjbRefs(T bean) {
Class beanClazz = bean.getClass();
for (Method method : beanClazz.getMethods()) {
if (method.isAnnotationPresent(EJB.class) && ejbIsIgnored(method) == false) {
setEjbRef(bean, method);
}
}
}
private boolean ejbIsIgnored(Method method) {
List<Class> ignoredBeans = getIgnoredBeans();
return ignoredBeans.contains(determineBeanClass(method));
}
private List<Class> getIgnoredBeans() {
if (mocker.getClass().isAnnotationPresent(IgnoredEjbs.class) false) {
return Collections.emptyList();
}
Class[] ignoredEjbs = mocker.getClass().getAnnotation(IgnoredEjbs.class).value();
return Arrays.asList(ignoredEjbs);
}
private void setEjbRef(T bean, Method setter) {
Class otherBeanClass = determineBeanClass(setter);
Object otherBean = lookupBean(otherBeanClass);
invoke(bean, setter, otherBean);
}
private Class determineBeanClass(Method setter) {
EJB ejbRefAnnotation = setter.getAnnotation(EJB.class);
if (ejbRefAnnotation.beanInterface() != null &&
Object.class.equals(ejbRefAnnotation.beanInterface()) false) {
return ejbRefAnnotation.beanInterface();
}
Class otherBeanClass = setter.getParameterTypes()[0];
return otherBeanClass;
}
private <T> void invoke(T bean, Method method, Object ... args) {
try {
method.invoke(bean, args);
} catch (IllegalArgumentException e) {
throw new RuntimeException(e);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
} catch (InvocationTargetException e) {
throw new RuntimeException(e.getCause());
}
}
private Object lookupBean(Class otherBeanClass) {
if (beans.containsKey(otherBeanClass)) {
return beans.get(otherBeanClass);
}
return createEjb(otherBeanClass);
}
private <T> void postConstruct(T bean) {
Class beanClazz = bean.getClass();
for (Method method : beanClazz.getMethods()) {
if (method.isAnnotationPresent(PostConstruct.class)) {
invoke(bean, method);
}
}
}
private void postConstruct(Object bean, InvocationContext context) {
Class beanClazz = bean.getClass();
for (Method method : beanClazz.getMethods()) {
if (method.isAnnotationPresent(PostConstruct.class)) {
invoke(bean, method, context);
}
}
}
private static class NoMocks implements EjbMocker {
public <T> void provideMocks(T bean) {
// do squat.
}
}
private static class MockInvocationContext implements InvocationContext {
private final Object bean;
public MockInvocationContext(Object bean) { this.bean = bean; }
public Object getTarget() { return bean; }
public Object proceed() throws Exception {
return null;
}
}
// ... more mock methods here.
}
}
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface IgnoredEjbs {
Class[] value() default { };
} Let me just run you through this...
You create a stubbed-out EJB like this: new EjbFactory.create(MyService.class). The createBean() method does the following things:
This example code isn't complete - it's based on an early version of what we built at Wotif. For example, there isn't any support in this for injecting resources (such as database connections - or persistence contexts). Nor is the transactional or security support demonstrated. However, it's very functional.
A couple of other features worth noticing:
We used this to convert a number of our EJB tests from calling against the deployed server to testing without deploying. As you can imagine, this makes the test-code cycle a lot faster.
While "strong" unit testing is still my preferred option, these more complete tests have their place - especially for testing persistence logic. This makes it a lot easier to test out of container, and reduces (not elimiate!) your need to test against a deployed app.
]]>One of the things I noticed was that EJB3 gives you a lot of choices for how to implement and configure EJBs and their associated interfaces. There's a lot of "standards" on how to do it, many of them conflicting, but very little explanation of why. This is the set of standards I came up with (and was largely successful in getting implemented), and why I chose them.
]]> Don't annotate interfacesThis one is simple enough: the @Local and @Remote annotations don't go on the interfaces. They will instead be placed on the actual EJB.
Why do this? It's because I'm a fan of two concepts: domain-driven design, and implementation independence. I strongly believe in putting as much logic into my domain classes as possible. Things like EJBs provide services from the environment, not logic. This implies that domain classes can call out to services.
But I don't want to build a dependency on a given technology, such as EJBs, into my domain classes1. There's no certainty that any given service is going to be an EJB, anyway. For this reason, I don't want the EJB3 service annotations on my service interfaces.
(It's probably worth pointing out here that we compile the domain classes separately from the services; these dependency rules are enforced at compile-time)
As a rule, any given EJB should be intended to be a local EJB or a remote EJB. Yes, it is possible for an EJB to implement both a local and remote interface, but there are lots of reasons that this is a bad idea.
Because an EJB should only be remote or local, the corresponding service interface should be conveniently named - e.g. MyService, not MyServiceLocal or MyServiceRemote.
Why do this? First, you have to think about why you'd use a remote interface in the first place. Ignoring reasons such as testing, the only real reason to go for a remote interface is that you want to put the client to the EJB on a different box than the service.
If you do this, there's a good chance that you will be upgrading the server and the client at separate times - maybe just a few minutes apart, but still separate. This means you need to think about the evolution of your classes, and how to deal with that upgrade problem. This, in turn, means that it's not just sufficient to make the types used in the remote interfaces serializable - they have to be externalizable as well.
At Wotif, we run every important piece of software across multiple servers for redundancy. Currently, we follow Fowler's First Law of Distributed Object Design, and run parallel instances rather than having distributed objects. This means, for example, that upgrades are done by taking one node out at a time, upgrading it, and putting it back in. If we used remote interfaces, we would either have to bind clients to their servers (creating two single-points-of-failure), or take out the entire cluster when we do an upgrade, OR spend effort designing robust interfaces that tolerate upgrades. Frankly, it's just easier to deal with local interfaces as a rule.
That said, most of our EJBs have both local and remote interfaces - the remote interface is present for the older-style tests that test the EJB against a deployed server. But these remote interfaces are not intended to be used by the application itself.
(Remote interfaces, at least under Glassfish, are also more annoying to manage - most of our remaining deployment descriptors deal with security settings for the remote interfaces)
Well, as much as possible, anyway. We still have an ejb-jar.xml file, as well as a sun-ejb-jar.xml file, but there isn't much in them. All that's in the ejb-jar.xml file is some environment variables that are configured at build time.
This was more a legacy of our old design - we didn't use EJB 2 entity beans, relying instead on Hibernate for our persistence needs. Because we didn't use them before, we aren't using them now.
We will be investigating EJB 3 Entity Beans on future projects, but to be honest, I think that using Hibernate directly is still a better idea.
For a similar reason, we don't use Stateful Session Beans or Timer Beans (though Timer Beans will also be investigated as an alternative to Quartz).
The single biggest change for the better in EJB 3 is the introduction of dependency injection, via the @EJB and @Resource annotations. We make extensive use of them. Dependency injection rocks, and enables the next rule.
There's lots of good reasons to use dependency injection, and I won't bother re-iterating them here. The one thing to point out is that you can only inject threadsafe dependencies; with stateless session beans (and MDBs) you can only inject dependencies as part of the EJB initialisation steps.
That is, write unit tests that instantiate the EJB implementation, configure it with suitable mocks, and test.
Solid unit testing, without deploying, is an essential part of building EJBs quickly and reliably. EJB3 finally makes this possible.
We also have a lot of EJB tests that are the primary place our database logic gets tested. We still need these tests, so to make it easier I wrote a test harness to automatically configure an EJB instance with their dependencies - ie, wiring up other EJB references and database connections. I converted a bunch of our previous "against-the-container" tests to using this new style, simply by changing how they obtained the EJB reference - no other change to the test required.
That's all the rules. By way of finishing this up, here's an example of what an EJB looks like:
public interface HelloService {
String sayHello();
}
@Stateless
@Local(HelloService.class)
@Remote(HelloServiceRemote.class)
public class HelloServiceBean implements HelloService {
public String sayHello() { return "Hello world"; }
}
public interface HelloServiceRemote {
String sayHello();
} And that's about it.
----
1 There are exceptions, the biggest one being persistence - I'm happy, for example, to use EJB3 and Hibernate-style persistence annotations on my domain classes. However, even in this case, I like to limit the dependency to the smallest amount possible. The idea is to trade the "purity" of implementation independence for some degree of convenience.
]]>Response Headers - http://www.wotif.com/
X-Powered-By: Servlet/2.5, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1, JSP/2.1
Set-Cookie: PersistCountryCode=1; Domain=.wotif.com; Expires=Wed, 23-Sep-2037 22:11:45 GMT; Path=/
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Content-Length: 11520
Date: Wed, 24 Jan 2007 22:11:45 GMT
Server: Sun Java System Application Server Platform Edition 9.0_01
Connection: close
200 OKPhew. Now maybe I can get those backlogged EJB3-based articles out.
]]>However, I expect to start posting again soon - expect the regular stream of quality1 articles that I used to produce.
1 Remember - everything has quality. Sometimes, you can even put a nice adjective in front.
]]>