<dependency><groupId>com.cubeia.firebase</groupId><artifactId>guice-support</artifactId><version>1.0-RC.1</version></dependency>

And if you haven’t already got it, you’d need our repository as well:

<repository><id>cubeia-nexus</id><url>http://m2.cubeia.com/nexus/content/groups/public/</url><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots></repository>

Now your all set to go, just extend GuiceGame and return the class of you game processor within the configuration, like so:

public class MyGame extends GuiceGame {public Configuration getConfigurationHelp() {return new ConfigurationAdapter() {public Class getGameProcessorClass() {return MyProcessor.class;}};}}

So what’s the magic then? It is this: The class MyProcessor will be instantiated by Guice and can therefore contain injections. And further, it will be done in a custom scope, per event, thus isolating instances nicely.You can also add your own modules to the injection context, again by overriding a method in GuiceGame:

protected void preInjectorCreation(List list) {list.add(new MyGameModule());}

Which means, you can inject not only stuff from the current table but also, your own classes. So if we continue:

public class MyProcessor implements MyProcessor {/** This is probably configured in the "MyGameModule" configured* in the guice game extension.*/@Injectprivate MyHandler handler;/** This is a speciality, you can inject Firebase services* right into your classes.*/@Serviceprivate ScriptSupport support;/** And another shortcut, if you use Log4j, we have a* a helper annotation for you...*/@Log4jprivate Logger log;public void handle(GameDataAction action, Table table) {// do something here eh?}[...]}

That should give you the idea. You can inject Firebase services as well as a logger (and remember, if you don’t use Log4j, Guice support the Java utility logging package from scratch). There’s a couple of things not shown here, for example, you can inject table members directly into the classes and the state object, so you don’t have to pass those around.Any catch? Well, when you create your own modules you’ll need to keep in mind that the processor will only work in a custom scope, called EventScope. So if you have something which needs to be bound not as a singleton or in the default scope, you’ll probably need to do something like this:

bind(MyHandler.class).to(MyHandlerImpl.class).in(EventScoped.class);

And that’s it! In a few days we’ll release our script support, which is as you might imagine built on top of the Guice support. And so far? I love it!

• Guice and Spring
• Declarative transactions and JTA
• EDA, Pipelines and CEP
• SOA and ESB and NMR
• Column databases and distributed file systems
• Wicket and various related Ajax components
• OSGi in various permutations with the above
• BI, in-memory BI and CEP (again)
• AOP and/or IoC patterns

And now I’m contemplating the fultility of programming.

Introduction
I’m afraid I don’t “get” it either. Religion does that to me, as soon as someone tells me if I would only get it I would understand, I automatically back off, ready to fight. I mean, if I only would let Jesus into my life I would start believe, right? And if I would only start getting Spring I would be a follower too, right?

Yeah, right.

You don’t think it is a religion? Well, try critizising it, and then check what kind of responses you’ll get. (In fact, have you read a critical analyzis of spring at all? Probably not, I know that I haven’t. And that worries me, and apparently Crazy Bob as well, a bit). Or you can read Bobs post and then scan through the comments:

• “I use it and it works for me”
• “If you just get it you would understand”
• “So? Don’t use it then”

And many will testify to the fervor with which Spring advocates jumps at any doubting voice. (Also among the comments, there’s some long sales pitches from Keith from the Spring Web Flow team.)

So why am I sceptical? Well, the religion issue apart, here’s some things about Spring which I question:

• It is not very a light-weight sollution
• Spring does affect you code
• There’s no clear demarcation between code and XML
• Spring XML effectively is another language
• Refactoring and debugging becomes a pain

Let’s take them on, shall we?

Heavy Ball and Chain
Light-weight? Erhm, no, I don’t think so. Light-weight in my book means small, non-intrusive and without any particular runtime impact. Also, I don’t expect light-weight sollutions to have any significant impact on my coding style. And let’s not forget what Bob points out, the public contracts of Spring are very much not light at all (but to their defence, they do have extensive API documentation provided).

Don’t Touch My Code
Contrary to claims, spring does “touch” my code. Just becasuse what injects your dependencies on the right places sits outside your code instead of within it, doesn’t mean it doesn’t exist. I mean, how do you start you application? It is correct that no Java code is visible in your project, but this is not necesserally a good thing. And as Bob puts it:

Spring advocates tout that Spring doesn’t “touch” your code, i.e. you don’t have to implement any Spring-specific interfaces (with the exception of life-cycle interfaces, etc.). News flash: the XML configuration *is my code*, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific. 

Demarcation
Where do you draw the line between Spring and Java? If you do it too coarse-grained you don’t particulary need Spring at all, but as you penetrate deeper the amount of XML will grow rapidly, and that will soon become a problem. I have been in projects with fully grown “XML Hell” problems. It. Is. Not. Funny.

Mixing Langauges?
Please read the Bob-qoute a few paragraphs above: XML is code in a Spring project. A “fully Springified” project will most probably, thanks to the demarcation problem, have a lot of XML files in a 3rd party language. In other words, in order to fully understand, and therefore effectively work in, such a project you need to be fluent in Spring. Light-weight? No. Does it affect my code? Yes.

Do I really want projects written in two separate lagauges? Perhaps it isn’t a problem, but you must understand that when you take the Spring step, you are forever relying on dual-language programmers to work on and support it. And large projects tend to live longer than their programmers. That might be a really big problem for any Spring project in the near future. Seriously. What if you can’t find any good Spring programmers to hire? Legacy code is bad enough. Legacy code in an obscure XML language that no-one really uses any more is even worse.

Hard references and strong types
I like strong types. I like hard references. They make my life as a programmer so much simpler. And both of them are negatively affected by Spring. This problem will shrink a bit when IDE’s becomes better at handling Spring files for you. But right now, they’re not up to schratch.

Conclusion
Does this mean I don’t like dependency injection? Not at all. Good programmers do that all the time without the help of any heavy-weight framework. Does this mean I will never use Spring? Not at all. But I consider the above points very important and unless I’m wrong, which of course may well be the case, I’ll probably try to stay away. And to be very, very clear to any Spring zelaot happening to read this: Don’t bother to answer unless you have answers, they’re specific, and to the point. I’m not interested in your religion, I’m interested in writing damn good code.