While the classical Apache Wicket implementation has the SpringBean annotation this does not work the same way for Pax-Wicket. First of all in Pax-Wicket we do not encounter one single ApplicationContext but rather an entire range of (more than one is possible per bundle). In addition Pax-Wicket should support Spring-Bean-Injection as well as Blueprint-Bean-Injection. And if possible without any change of configuration. Finally, compared to the classical Wicket approach in Pax-Wicket one class could be registered in even one Application for multible different points. So a one-to-one copy of the Wicket approach wont work and we had to think about something new.
The Annotation
First of all we've introduced a new annotation: PaxWicketBean which has the following, simple, signature:
Overwrites
Overwrites are a quite important concept in Pax-Wicket. With their help it is possible to define alternative beans to be injected.
For example you have one Tab implementation which you would like to provide multiple times. Each time only the domain object differs, but nothing else. Nevertheless, with the classical approach you can not define multiple bean names for the various instances. Using Pax-Wicket Spring or Blueprint factories you can define bean overwrites at each ContentProvider in a Map<String,String>. For example, you define a PaxWicketBean(name="test") and provide the overwrite "test","abc" Pax-Wicket will lookup the bean "abc" instead of "test".
Please be aware that this only works if you use the name attribute of the PaxWicketBean annotation. Otherwise it is not possible to lookup the correct bean.
Let's see how this will look in code. Assume you've a page with the following code:
Now you want to export this page two time with different provider beans. So export the page like:
InjectorHolder
Sometimes objects are not inherited from Component and therefore the constructor is not called. Therefore the annotated fields are not injected. Similar to Wicket you have the option in Pax-Wicket to use the static InjectorHolder to inject your bean. This could look like the following for an external instance...
... or like the following if you like to inject into the bean executing right now:
Nasty Imports
For pax-wicket we need a way to inject beans within the bundle from the bundles application context. Therefore it is required that we extend the bundles at some parts with CG enhanced classes. This on the other hand has the downside that the bundle itself requires those dependencies. But, since those classes are added at runtime to the bundles, e.g. the maven bundle plugin can not know that those are required. Therefore, the only possible way is to add "org.ops4j.pax.wicket.util.proxy" manually as dependency.

