16 Apr
2010
16 Apr
'10
12:17 p.m.
On Apr 16, 2010, at 10:55 AM, Caleb James DeLisle wrote:
You mean "why not"?
The reason is that Guice doesn't implement JSR299. It only implements JSR330. IMO if
CDI becomes adopted for JavaSE then Guice in the current form is dead. They'll need to
implement CDI at that time. I'd be curious to know Bob's opinion nowadays (since
he wrote that piece in 2009:
www.mail-archive.com/google-guice@googlegroups.com/msg01243.html ;)).
CDI is a spec. You need an implementation. And one that goes beyond the spec in order to
support dynamic bean registration and dependency isolation and versioning for ex. Weld is
good candidate to provide this and they're interested in doing so.
Thanks
-Vincent
Vincent Massol wrote:
Indeed, Guice's code in trunk already supports JSR330 and that's the direction
anyway.
Hi devs,
I've been researching what it would take to be able to support the Extension Manager
use case regarding components isolation and dependency versioning. I won't go over
the details of all I've researched (you can ask questions for that). I'm just
proposing a series of steps and a vision of the future for our component model.
If you're interested in the topic I would recommend that you read the Weld tutorial
on CDI:
docs.jboss.org/weld/reference/1.0.0/en-US/html_single/
Here are the steps I'm willing to work on and implement.
Step 1: timeframe from now: 1 month
* Use JSR330 annotations
+1 this looks like it is necessary since these
annotations are apparently used by JSR299 and JSR330 and
are almost exactly the same as Guice's API. Step 2:
timeframe from now: 1 month
* Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module).
- No versioning management yet.
- Need to use a maven osgi plugin to generate Manifest files from the POMs
* Revise further steps based on result from Step 2.
Step 3: timeframe from now: 2 months
* If step 2 is successful add what's needed to the XWiki Component API to perform
generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties
registered with the component. It would contain the role hint and the version for example.
Also add annotations for specifying dependency version ranges.
Note: After step 3 we have the prereqs for the Extension Manager done. The other steps
below are improvements and steps to put us in the standards direction.
Step 4: timeframe from now: 6 months-2 years
* When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it
becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the
spec right now:
Why JSR299 over Guice API? - support for
dynamic bean registration
- ability to implement CDI over OSGi
Why CDI over OSGi? One package can't do
all that is needed?
> * Work with the Weld dev team to add support for those 2 items above. They're
interested to implement it if we help them and if these 2 items get done relatively
quickly we could migrate to CDI earlier than the timeframe above
> * In the meantime we can monitor it carefully to see its progress and we could start
migrating to it slowly. Some ideas:
> - use the CDI annotations instead of the xwiki-specific ones for the binding part
> - introduce new concepts that comes from CDI: decorators, interceptors, producers
> - refactor our observation module to use the CDI event model
>
> Step 5: timeframe for now: 2-4 years
> * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to
be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI
over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we
won't need to change much in our code to do that.
>
> WDYT?
>
> Thanks
> -Vincent
>
> Links:
> - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/
> - Jigsaw: openjdk.java.net/projects/jigsaw/
> - JSR330:
atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html
> - JSR294: See description on openjdk.java.net/projects/jigsaw/