11:50 p.m.
Hi,
Is there any reason seam-bridge-api and seam-webbeans-bridge shouldn't move to
webbeans-extensions? I have this jira issue:
https://jira.jboss.org/jira/browse/WBX-34
to allow the webbeans wicket support to work with any jsr-299 impl,
and part of making that work is providing a way for the wicket
extension to grab the current manager instance. It seems like this
functionality
is useful independent of seam.
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
8:21 p.m.
On Fri, May 22, 2009 at 5:50 PM, Clint Popetz <cpopetz(a)gmail.com> wrote:
Hi,
Is there any reason seam-bridge-api and seam-webbeans-bridge shouldn't move
to
webbeans-extensions? I have this jira issue:
https://jira.jboss.org/jira/browse/WBX-34
to allow the webbeans wicket support to work with any jsr-299 impl,
and part of making that work is providing a way for the wicket
extension to grab the current manager instance. It seems like this
functionality
is useful independent of seam.
I think we are engaging in a struggle over ownership of features and
defining boundaries between Seam and WB.
In my definition, Seam is the universal middleware stack at Red Hat which is
most definitely independent of JSR-299 implementation. Therefore, it's my
position that anything that "extends" 299 towards "rich web" should be
a
module of Seam. Extensions which don't go in that direction, such as the
Java SE support, are a better fit as a webbeans extension. Furthermore, I
don't think you should feel like you "have to depend on Seam" because it
isn't going to be like Seam 2 where it is all or nothing. Modules are
starkely independent and can be seen as a lose collection of extensions.
Perhaps others will disagree with my definition, or think it too liberal,
but if we don't define where Seam begins, then you could easily rationalize
all modules of Seam be extensions of Web Beans...I will admit though that
the bridge is a gray area in that it could go either way.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
8:34 p.m.
On Sun, May 24, 2009 at 1:21 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Fri, May 22, 2009 at 5:50 PM, Clint Popetz
<cpopetz(a)gmail.com> wrote:
> Hi,
>
> Is there any reason seam-bridge-api and seam-webbeans-bridge shouldn't
> move to
> webbeans-extensions? I have this jira issue:
>
> https://jira.jboss.org/jira/browse/WBX-34
>
> to allow the webbeans wicket support to work with any jsr-299 impl,
> and part of making that work is providing a way for the wicket
> extension to grab the current manager instance. It seems like this
> functionality
> is useful independent of seam.
I think we are engaging in a struggle over ownership of features and
defining boundaries between Seam and WB.
True, it seems like an arbitrary boundary.
In my definition, Seam is the universal middleware stack at Red Hat which
is most definitely independent of JSR-299 implementation. Therefore, it's my
position that anything that "extends" 299 towards "rich web" should
be a
module of Seam. Extensions which don't go in that direction, such as the
Java SE support, are a better fit as a webbeans extension. Furthermore, I
don't think you should feel like you "have to depend on Seam" because it
isn't going to be like Seam 2 where it is all or nothing. Modules are
starkely independent and can be seen as a lose collection of extensions.
Perhaps others will disagree with my definition, or think it too liberal,
but if we don't define where Seam begins, then you could easily rationalize
all modules of Seam be extensions of Web Beans...I will admit though that
the bridge is a gray area in that it could go either way.
This issue has actually gone away for my own use-case, because the things
wicket-webbeans needs are now part of the new SPI.
-Clint
11:51 a.m.
New subject: [seam-dev] Re: [webbeans-dev] Seam-bridge-api and seam-webbeans-bridge question
Following on from discussions last week, this bridge thing is going
away entirely, so I think the discussion is moot :-)
On 24 May 2009, at 19:34, Clint Popetz wrote:
On Sun, May 24, 2009 at 1:21 PM, Dan Allen
<dan.j.allen(a)gmail.com>
wrote:
On Fri, May 22, 2009 at 5:50 PM, Clint Popetz <cpopetz(a)gmail.com>
wrote:
Hi,
Is there any reason seam-bridge-api and seam-webbeans-bridge
shouldn't move to
webbeans-extensions? I have this jira issue:
https://jira.jboss.org/jira/browse/WBX-34
to allow the webbeans wicket support to work with any jsr-299 impl,
and part of making that work is providing a way for the wicket
extension to grab the current manager instance. It seems like this
functionality
is useful independent of seam.
I think we are engaging in a struggle over ownership of features and
defining boundaries between Seam and WB.
True, it seems like an arbitrary boundary.
In my definition, Seam is the universal middleware stack at Red Hat
which is most definitely independent of JSR-299 implementation.
Therefore, it's my position that anything that "extends" 299 towards
"rich web" should be a module of Seam. Extensions which don't go in
that direction, such as the Java SE support, are a better fit as a
webbeans extension. Furthermore, I don't think you should feel like
you "have to depend on Seam" because it isn't going to be like Seam
2 where it is all or nothing. Modules are starkely independent and
can be seen as a lose collection of extensions.
Perhaps others will disagree with my definition, or think it too
liberal, but if we don't define where Seam begins, then you could
easily rationalize all modules of Seam be extensions of Web
Beans...I will admit though that the bridge is a gray area in that
it could go either way.
This issue has actually gone away for my own use-case, because the
things wicket-webbeans needs are now part of the new SPI.
-Clint
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
5441
days inactive
5445
days old
3 comments
3 participants
participants (3)
-
Clint Popetz -
Dan Allen -
Pete Muir