5:50 p.m.
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.)
* 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?
WDYT?
6 p.m.
On May 09, 2008, at 17:50 , Pete Muir wrote:
If we use the MC we get ootb:
* flexible deployment system
This, for me, is one of the deciding factors. The current Seam 2.x
deployment system is crude and has to be rewritten anyway in the next
major release to support
a) Seam usage/deployment outside of a web container (Swing apps, etc.)
b) Customized deployment for highly dynamic applications (I'm
currently struggling with a hot-redeployable plugin.jar system on top
of Seam).
Although we made some of the Seam 2 deployment architecture more
extensible in 2.1 with DeploymentStrategy, any user who wants a) or b)
still has to roll their own deployment system starting with the
Initialization class (and lots of hacking).
So, even if we only use that single feature of JBoss MC, we'd already
avoid duplication and the "what if JBoss AS uses a different version"
problem because the only alternative would be to invent our own
deployment system from scratch anyway.
6:12 p.m.
On 9 May 2008, at 17:00, Christian Bauer wrote:
On May 09, 2008, at 17:50 , Pete Muir wrote:
> If we use the MC we get ootb:
>
> * flexible deployment system
This, for me, is one of the deciding factors. The current Seam 2.x
deployment system is crude and has to be rewritten anyway in the
next major release to support
a) Seam usage/deployment outside of a web container (Swing apps, etc.)
b) Customized deployment for highly dynamic applications (I'm
currently struggling with a hot-redeployable plugin.jar system on
top of Seam).
Although we made some of the Seam 2 deployment architecture more
extensible in 2.1 with DeploymentStrategy, any user who wants a) or
b) still has to roll their own deployment system starting with the
Initialization class (and lots of hacking).
Yes, the entire Seam bootstrap and deployment system is very cobbled
together for a specific environment, and isn't very extensible (aka a
mess). I certainly don't want to reuse it for WBRI (but we could take
the lessons learnt). But it is a big thing to implement nicely. As we
are going to use WBRI for the Seam 3 core it is important to get this
right.
6:11 p.m.
I am seriously considering using it for HEM, HAN in Core v4 and for
the Bean Validation RI. Hibernate Commons Annotations duplicates a lot
of what they have done.
But we will have to make MC and all the dependencies ASL. We need to
be sure we are OK with that.
On May 9, 2008, at 08:50, Pete Muir 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.)
* 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?
WDYT?
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
1:26 p.m.
Ok, it looks like we can't use the MC as it is LGPL licensed and the
RI must be ASL licensed.
But we should still consider to provide hooks to plug in the MC as the
core engine if it is present...
On 9 May 2008, at 17:11, Emmanuel Bernard wrote:
I am seriously considering using it for HEM, HAN in Core v4 and for
the Bean Validation RI. Hibernate Commons Annotations duplicates a
lot of what they have done.
But we will have to make MC and all the dependencies ASL. We need to
be sure we are OK with that.
On May 9, 2008, at 08:50, Pete Muir 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.)
> * 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?
>
> WDYT?
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
6:42 p.m.
In fact, Ales has already done some prototyping
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
On 9 May 2008, at 16:50, Pete Muir 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.)
* 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?
WDYT?
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
6:49 p.m.
It's a wip, but just to get the feeling that anything is possible in MC. ;-)
Like Emmanuel learned yesterday at our deployers discussion. :-)
Pete Muir wrote:
In fact, Ales has already done some prototyping
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
7:01 p.m.
right, you just have to implement an interface. The hard part is to
find which one.
On May 9, 2008, at 09:49, Ales Justin wrote:
It's a wip, but just to get the feeling that anything is possible
in
MC. ;-)
Like Emmanuel learned yesterday at our deployers discussion. :-)
Pete Muir wrote:
> In fact, Ales has already done some prototyping
>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
>
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern...
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
7:26 p.m.
On Fri, May 9, 2008 at 11:50 AM, Pete Muir <pmuir(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
5811
days inactive
5831
days old
8 comments
6 participants
participants (6)
-
Ales Justin -
Christian Bauer -
Emmanuel Bernard -
Jay Balunas -
Pete Muir -
Pete Muir