I came across the JSR330 annotations from the javax.injection package which were introduced in the JEE world. JSR330 Annotations are recognized by several Dependency Injection frameworks like Guice, Springframework, my homegrown dinistiq, and obviously the JEE Containers.
Step 1: Get rid of Spring
This is were I started to make Tangram less depending on the Springframework directly or provide interfaces to be implemented in a spring and a non-spring way. For the dependency injection part it was mostly as easy as to migrate from@Autowired
private ClassRepository classRepository;
to
@Inject
private ClassRepository classRepository;
I lost the required = false option at that time but was able to live with that given the advantages of portability.
Step 2: Find Alternatives
The spring parts of the application where re-implemented using a plain servlet based solution, and springsecurity was replaced by Apache Shiro for those scenarios.After having migrated to the new annotations most of my Components where portable across containers. So I don't have to sell my soul to a special DI framework for very many cases, which helps choosing the right infrastructure for every project. But there are several details which still remain problematic, most notably the missing required = false option and the missing collection of instances to be able to automatically let the whole set of instances be injected.
Step 3: Annoying Details
The annoying collection problem looks like this:@Autowired(required = false)
private Collection<ControllerHook> controllerHooks = new HashSet<ControllerHook>();
Later I migrated this to the JSR-330 Annotations - which also works with spring.
@Inject
private Collection<ControllerHook> controllerHooks = new HashSet<ControllerHook>();
I made this work with dinistiq as well.
With Guice I learned, that it didn't like to collect the instances for me and provide me with the collection out of the box.
I'm expecting here, that any instance implementing ControllerHook from the application context gets added to a collection which then is injected into the consuming component. Spring does it, dinistiq does it, Guice can be convinced to do it by the additional Multibinder:
Multibinder<ControllerHook> multibinder =
Multibinder.newSetBinder(binder(), ControllerHook.class);
multibinder.addBinding().to(UniqueUrlHook.class);
multibinder.addBinding().to(ProtectionHook.class);
Step 4: Show Stopper
Inspired by the CapeDwarf project, promising to be able to deploy applications developed for the Google App Engines and their APIs on a JEE infrastructure, I tried to deploy GAE based Application to such an Infrastructure based on a JBoss AS7 or Wildfly 8 Server using CapeDwarf Versions 1 or 2 respectively.This approach doesn't work for Tangram since the used DI solution within the application - be it dinistiq or the Springframework - interferes with the JEE Container's CDI implementation. The Application Server starts to interpret the annotations intended for the other DI framework. This would instantiate the application components twice and right at the moment it also fails on some of those components.
Step 5: JEE Wordiness
So quite naturally I now went over to directly migrate Tangram to the JEE world. But also JEE has the same problem as plain Guice has.@Inject
private Collection<ControllerHook> controllerHooks = new HashSet<ControllerHook>();
This time the solution really is ugly. It seems I have to implement a different consuming component and thus instead of the two lines, a separate ControllerHookProvider is needed
public interface ControllerHookProvider {
Collection<ControllerHook> getControllerHooks();
} // ControllerHookProvider
Of course the generic implementation looks like the good old two lines which did the whole job for me so far.
public class GenericControllerHookProvider implements ControllerHookProvider {
@Inject
private Collection<ControllerHook> controllerHooks;
public Collection<ControllerHook> getControllerHooks() {
return controllerHooks;
} // getControllerHooks()
} // GenericControllerHookProvider
For JEE an alternative implementation has to be chosen, which made the interface necessary in the first place, and it is surprisingly wordy for that common and simple scenario.
@Named("controllerHooksProvider")
@Singleton
public class JeeControllerHooksProvider implements ControllerHookProvider {
private Collection<ControllerHook> controllerHooks = new HashSet<>();
@Inject
public void setControllerHooks(@Any Instance<ControllerHook> hooks) {
for (ControllerHook hook : hooks) {
controllerHooks.add(hook);
} // for
} // setControllerHooks()
public Collection<ControllerHook> getControllerHooks() {
return controllerHooks;
} // getControllerHooks()
} // JeeControllerHooksProvider
This really didn't invite me to go deep into JEE again. Additionally it is missing any of the configuration file based bean definitions avoiding much of the interfacing of classes where in fact just two injected values make the difference. With the Springframework configuration files and auto scanning of beans go hand in hand. JEE intentionally left out this part.
