XWiki Components Design Choices

Copyright (c) Vincent Massol - 2011

XWikiXWiki’s component architecture

September 2011

Wednesday, September 21, 11


Agenda

• Needs

• Discarded solutions

• Chosen solution

• Lessons learnt

• Future



XWiki Platform

... for developing (collaborative) web applications



Needs (1/2)

• XWiki is a runtime development platform

• Need solution for code reuse

• Need solution to change behaviors

• Ability to install extensions transitively at runtime

• As standard as possible



Needs (2/2)

• Ability to change implementation without changing existing components



Discarded Solutions

• Warning: Choice done 2 years ago

• OSGi: too complex

• Resin Pomegranate: not standard enough

• Guice: static binding only

• CDI 1.0: static binding only



Chosen Solution (1/2)

• XWiki’s own interfaces

• Implemented using Plexus initially

• Custom implementation after Plexus was EOLed

• Using JSR330’s annotations

• First focus: have components for everything



Chosen Solution (2/2)@ComponentRolepublic interface Macro{ List<Block> execute();}

@Component@Named("message")@Singletonpublic class MessageMacro implements Macro{ @Inject private Execution execution;

@Inject @Named("box") private Macro boxMacro;

public List<Block> execute() { ... }}

org.xwiki.rendering.internal.macro.message.MessageMacro

META-INF/components.txt



Lessons Learnt

• XWiki’s own interfaces have served us well

• Allowed us to switch from Plexus to our own implementation

• But... ready to use a standard as soon as one emerges!

• Would love to have CDI with OSGi classloading separation ;)



Future

• Several possibilities

• Use CDI 1.1 when it’s out

• If it’s possible to perform dynamic bean registration/unregistration

• Use JDK’s proposed solution (JavaSE 8?)

• We have time...


Technology

XWiki Components Design Choices