The problem I’ve always had with DI frameworks, be it Spring or Guice, is they create this nasty dependency tree. If you don’t want to use GlobalApplicationContext.getBean() or Injector.getInstance() then you’ll need to inject all your dependencies at the root. It annoys the crap out of me, but I suppose there’s just no way around it…
Except if the language had a mechanism to realize interfaces and abstract classes at runtime, either built-in or through some extension.
[...]The fundamental problem with all dependency injection tools is they are trying to do what language should be doing (instantiating objects that implement some interface[!]).

These toughts might be correct if you reduce dependency injection to “instanciate a class that implement this or that inferface”. But I understand dependency injection as a tool for inversion of control and decoupling of implementations. Dependency injection shall enable the developer to reconfigure the application without compilation of the compontents that depend on eachother.

Yes, at some point you will have to decide which implementation of a certain interface shall be used, and one can argue where this “wiring information” should be placed: Spring uses an XML file, PicoContainers can be composed hierachically, guice can use annotations. But if you have only one implementation of the interface you can do without a dependency injection framework at all.

Updates

• Fixed typos
• As pointed out by Paul Hammant PicoContainer of course can be configured with XML as well as with Groovy, Python, Beanshell and Ruby. I’m sure one can add Yaml and Json easily as well. Furthermore I think this is possible to some extend for Spring and Guice as well and the Qi4J developers would be able to add something to this, too. What I wanted to make clear is that one can argue about when, where and how to wire the components; the different ways the mentioned frameworks offer emphasize this.

Although this seems cryptic its rather straight forward: match on either “” or “1” (first part until “|“) or match on a substring of 2 or more “1” with repeatedly fits the whole. For the string “111111” the substring “11” fits in 3 times.

Over all its a very high level description of a primality test. I never considered regular expressions as a mathematical domain language.

More details on Avinash Meetoo’s Blog.

Basically the nice glass like look of the combobox will disappear and the old flat look will be restored. This comes due to Nimbus using a custom CellRenderer:

javax.swing.plaf.synth.SynthComboBoxUI$SynthComboBoxRenderer

Fortunately this renderer is based on JLabel, too. This is why you can simply wrap the renderer and add some blinkenlights when needed:

The implementation is straight forward:

Use it as follows:


jComboBox.setRenderer(new InstanceWithIconCellRendererWrapper(jComboBox.getRenderer()));


ApplicationContext ctxt = ApplicationContext.getInstance();
ResourceManager mgr = ctxt.getResourceManager();
resource = mgr.getResourceMap(HelloWorld.class);
String helloText = (String) resource.getObject("helloLabel", String.class);

But… what is this ApplicationContext.getInstance() static method call? Where is dependency injection? Look into the API documentation of ApplicationContext: it’s a global service locator. That means it provides a fixed bunch of services which are accessible by a singleton instance. You can of course use aggregation, sub-classing and delegation to extend it’s abilities but dependency injection is the train everyone jumps onto, ain’t it?

There is another issue that puzzles me: where are the interfaces? A framework whithout any interface? It’s even worse, ApplicationContext returns instances of concrete classes, not even abstract classes. So you’ll always get an instance of class RessourceManager. I you like to provide your own, you can only sub-class it, at least, RessourceManager is not final.

Can I have some dependeny injection, please? Picocontainer, Guice or Spring, perhaps? Yes, I can but it would be more nice, if RessourceManager, ActionManager and all other services provided by the framework would be interfaces and I could use any implemention I wish.

By the way, there is some dependency injection in the framework: you can inject property values into any awt component with RessourceManager.injectComponent. I hope the method name is not final yet, because I expected an component to be injected into some other instance, not something to be injected into a component.

<target name="appxml" depends="resolve">
<property name="meta.dir" value="${basedir}/src/main/resources/META-INF/"/>
<property name="appxml.filename" value="application.xml"/>
<property name="appxml.file" value="${build.dir}/${appxml.filename}"/>
<ivy:report todir="${build.dir}"
outputpattern="ivy.xml"
xml="true"/>
<xslt in="${build.dir}/ivy.xml" style="ivy2appxml.xslt" out="${appxml.file}"/>
</target>

The stylsheet I use currently is simple but does it job. No support for web archvies and connectors yet, or any configuration but it’s doing it’s job:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/javaee/application_5.xsd">
<xsl:template match="ivy-report">
<application>
<display-name>
<xsl:value-of select="info/module"/>
</display-name>
<xsl:apply-templates/>
</application>
</xsl:template>
<xsl:template match="dependencies">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="artifact[@type='jar']">
<module>
<java>
<xsl:value-of select="concat(@name, ‘.’, @ext)"/>
</java>
</module>
</xsl:template>
<xsl:template match="artifact[@type='ejb']">
<module>
<ejb>
<xsl:value-of select="concat(@name, ‘.’, @ext)"/>
</ejb>
</module>
</xsl:template>
<xsl:template match="artifact[@type='sar']">
<module>
<java>
<xsl:value-of select="concat(@name, ‘.’, @ext)"/>
</java>
</module>
</xsl:template>
</xsl:stylesheet>

Minor update: added @AssociationOverride from Java EE 5 API documentation. Thanks to Jonathan O’Connor for catching this one.

Just download it from here as pdf or OpenOffice Document.

Updates to the EJB 3.0 Annotations Cheat Sheet.

Changes

• Title changed to EJB 2.1 and Ealier Client View
• Update @RemoteHome and @LocalHome according to the latest spec.
• Fixed spelling and typos (NamesQueries / SINGLE_TABLE)

Thanks to Jonathan O’Connor for pointing out this errors.

Just download it from here as pdf or OpenOffice Document.