Just to keep abreast of what I'm doing, I"m preparing a second proposal that involves reusing CDI (aka JSR299) annotations. CDI is really neat and quite similar to what we've been doing in lots of respect. It also has a lot of improvements. I need to research a bit more, especially in the area of dynamic registration of beans with CDI. I've asked a question there: http://seamframework.org/Community/DynamicRegistrationOfBeans I'm starting to get a grasp on the relationships between CDI/Weld/Jigsaw/OSGi. I'll send a summary email when I know enough. If some of you are experts in this area please let me know. Thanks -Vincent On Apr 8, 2010, at 2:21 PM, Vincent Massol wrote:
Hi devs,
Since the JSR330 is now accepted as final and thus as a standard, I'd like to propose that we modify our component annotations to use it.
Rationale ========
The advantages of using it are: * Be standard, ie: ** Our components will be able to be re-used by injectors other than ours (Guice for example) ** Since IDEs will support JSR330 they'll be able to offer features for our code (auto complete, graph, etc), for ex http://blogs.jetbrains.com/idea/tag/dependency-injection/
Proposed Changes ===============
Note: JSR330 doesn't specify how components should be bound, hence the need to keep xwiki-specific metadata for the bindings.
* @Component and @ComponentRole stay unchanged * Deprecate @Requirement, replaced by @Inject * Use @Named or application-specific annotations (based on @Qualifier) instead of hints specified in the @Requirement annotation * Add new @Role(Class) to specify a dependency role in the case of collections (since generics are not available using reflection in Java) * Deprecate @InstantiationStrategy, replaced by @Singleton. We don't need to introduce any other scope annotations for now. * Note that the default scope in the JSR330 spec is "per lookup". Since our default is singleton, we'll need to add @Singleton annotations everywhere we used to not have anything.
Example before:
@Component("html") public class HTMLMacro extends AbstractMacro<HTMLMacroParameters> { ... @Requirement private HTMLCleaner htmlCleaner; ... @Requirement("xhtmlmacro/1.0") private PrintRendererFactory xhtmlRendererFactory; ...
Same example after the change:
@Component("html") public class HTMLMacro extends AbstractMacro<HTMLMacroParameters> { ... @Inject private HTMLCleaner htmlCleaner; ... @Inject @Named("xhtmlmacro/1.0") private PrintRendererFactory xhtmlRendererFactory; ...
WDYT?
Thanks -Vincent