Your SlideShare is downloading. ×
0
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
XWiki Components Design Choices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

XWiki Components Design Choices

749

Published on

A short presentation about XWiki's choices for its component model

A short presentation about XWiki's choices for its component model

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
749
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. XWiki XWiki’s component architecture Copyright (c) Vincent Massol - 2011 September 2011Wednesday, September 21, 11
  • 2. Agenda • Needs • Discarded solutions • Chosen solution • Lessons learnt • Future Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 3. XWiki Platform ... for developing (collaborative) web applications Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 4. 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 Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 5. Needs (2/2) • Ability to change implementation without changing existing components Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 6. 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 Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 7. 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 Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 8. Chosen Solution (2/2) @ComponentRole public interface Macro {     List<Block> execute(); } @Component @Named("message") @Singleton public class MessageMacro implements Macro {    @Inject    private Execution execution;    @Inject    @Named("box")    private Macro boxMacro;    public List<Block> execute()    {       ...    } } META-INF/components.txt org.xwiki.rendering.internal.macro.message.MessageMacro Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 9. 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 ;) Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11
  • 10. 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... Copyright (c) Vincent Massol - 2011Wednesday, September 21, 11

×