On Fri, May 9, 2008 at 11:50 AM, Pete Muir <pmuir@bleepbleep.org.uk> wrote:
A number of people have suggested basing the RI on the JBoss MC.

As I see it, the core services we need in WB:

* Defining scoped components, backed by EJBs if needed
* Defining bindings
* Defining (custom) scopes
* Managing lifecycle of components through contexts
* Integration with EL
* Resolution of components
* Support for interceptors
* Observer/observable
* Deployment of Web Beans jars

If we use the MC we get ootb:

* flexible deployment system
* Defining components
* DI (inc into constructors)
* Support for building custom XML deployment descriptors
* Support for applying AOP

which will get us going pretty quick

But

* it introduces quite a lot of dependencies which we don't directly control (JBoss MC, JBoss XB etc.)
We should see how small the dependency footprint can be.  I'm sure that this is one of the goals of the MC as well.  I know that this is an issue with Seam we have many dependencies and users ask how can I slim it down.
* it still seems to be under pretty heavy development (docs are very incomplete)
* what happens if WB RI uses one version of MC and the AS uses another?
What about conflicts with other containers caused by the MC.  I know that one of the goals of the MC is to be container agnostic, but I'm sure there will be initial conflicts.  WBs needs to work in any container to be viable - if we get out of the gate quickly using the MC - great!  But initial impressions are important, and if we have conflicts with other containers it might be seen a bit like Seam - as a JBoss specific project - at least at first :)

I'm not saying it is blocker to using the MC, but we should look into container deployment issues. 


WDYT?
_______________________________________________
webbeans-dev mailing list
webbeans-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev