6:11 a.m.
Hi guys.
In discussing WebBeans/EJB integration with Pete this week we came
across a few issues I'd like to hash out.
*Guiding Principles*
The points below are based on my view of the following bullets; please
correct if they're inaccurate.
* JSR-299 implementations are treated the same as any client of EJB;
they use/consume EJB as one of the target component models.
* A mechanism EJB makes available to JSR-299 should be available to
everyone.
----
1) EJB does not define an endpoint for SFSB removal outside
business/component method @Remove/remove() and timeout
JSR-299 PR2 6.5 - "When the destroy() method is called, the container
removes the stateful session bean. The @PreDestroy callback must be
invoked by the container."
JSR-318 PFD2 4.6 - "When the client calls a business method of the bean
that has been designated as a Remove method, or a remove method on the
home or component interface, the container invokes PreDestroy lifecycle
callback interceptor method(s) (if any) for the bean instance after the
Remove method completes."
JSR-299 is declaring that "destroy" on a contextual object will invoke a
removeal path not defined by EJB.
----
2) JSR-299 defines activity in the middle of EJB Lifecycle
JSR-299 PR2 6.11 - "When the EJB container creates a new instance of an
EJB, the container must perform the following steps after Java EE
injection has been performed and before the @PostConstruct callback
occurs..."
EJB defines no callback mechanism for a hypothetical @PostInstanciated
before @PostConstruct. Thus there's no hook defined for WB to do its magic.
----
I'd like to open up discussion on either adding these points to EJB 3.1
(a bit late in the game) or revising the JSR-299 spec such that it
doesn't impose upon EJB.
Either way, as I've committed to Pete, I'll be taking on the EJB/WB
integration bits. But I do want to ensure the lines are properly drawn.
If properly scoped, we should have to alter no code under the EJB3
components to support WB.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
6:19 a.m.
Andrew Lee Rubinger wrote:
EJB defines no callback mechanism for a hypothetical
@PostInstanciated
before @PostConstruct. Thus there's no hook defined for WB to do its
magic.
I should note that the current WB impl gets around this by way of the
SessionBeanInterceptor, which is a nice solution for JBoss - but I
wonder what other vendors are going to be able to do.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
1:50 p.m.
I spoke to andrew about this, and my understanding of his underlying
concern is around reciprocity - that the ejb spec should mention that
an impl should allow for jsr299 style injection at this post
instantiation point and also that the spec should say that and impl
may be expected to remove session objects for jsr299. An analagous
case is ejb etc injection into servlet - the servlet spec says it
should happen, but doesn't provide a spec'd callback for it.
And there is the question of plyggability (spec defined api for these
things, but that is out of scope for ee6 afaik).
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 18 Mar 2009, at 05:19, Andrew Lee Rubinger <alr(a)jboss.org> wrote:
Andrew Lee Rubinger wrote:
> EJB defines no callback mechanism for a hypothetical
> @PostInstanciated before @PostConstruct. Thus there's no hook
> defined for WB to do its magic.
I should note that the current WB impl gets around this by way of
the SessionBeanInterceptor, which is a nice solution for JBoss -
but I wonder what other vendors are going to be able to do.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
1:58 p.m.
On Mar 18, 2009, at 8:50 AM, pmuir(a)redhat.com wrote:
I spoke to andrew about this, and my understanding of his underlying
concern is around reciprocity - that the ejb spec should mention
that an impl should allow for jsr299 style injection at this post
instantiation point and also that the spec should say that and impl
may be expected to remove session objects for jsr299. An analagous
case is ejb etc injection into servlet - the servlet spec says it
should happen, but doesn't provide a spec'd callback for it.
And there is the question of plyggability (spec defined api for
these things, but that is out of scope for ee6 afaik).
Yes, if we do all this right we'll be ahead of the game in defining
real pluggability contracts for EE 7. For now, I don't see a need to
expose any additional EJB spec-level contracts for Web Beans.
Attempting that at this point wouldn't do much good given the larger
issue that the EJB spec itself has never attempted to define
pluggability. Even if we did, Web Beans integration would be the
least of the issues we'd need to address.
--ken
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 18 Mar 2009, at 05:19, Andrew Lee Rubinger <alr(a)jboss.org> wrote:
> Andrew Lee Rubinger wrote:
>> EJB defines no callback mechanism for a hypothetical
>> @PostInstanciated before @PostConstruct. Thus there's no hook
>> defined for WB to do its magic.
>
> I should note that the current WB impl gets around this by way of
> the SessionBeanInterceptor, which is a nice solution for JBoss -
> but I wonder what other vendors are going to be able to do.
>
> S,
> ALR
>
> --
> Andrew Lee Rubinger
> Sr. Software Engineer
> JBoss, a division of Red Hat, Inc.
> http://exitcondition.alrubinger.com
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
1:42 p.m.
I talked to andrew about this, and my understanding of his argument is
around
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 18 Mar 2009, at 05:11, Andrew Lee Rubinger <alr(a)jboss.org> wrote:
Hi guys.
In discussing WebBeans/EJB integration with Pete this week we came
across a few issues I'd like to hash out.
*Guiding Principles*
The points below are based on my view of the following bullets; please
correct if they're inaccurate.
* JSR-299 implementations are treated the same as any client of EJB;
they use/consume EJB as one of the target component models.
* A mechanism EJB makes available to JSR-299 should be available to
everyone.
----
1) EJB does not define an endpoint for SFSB removal outside
business/component method @Remove/remove() and timeout
JSR-299 PR2 6.5 - "When the destroy() method is called, the container
removes the stateful session bean. The @PreDestroy callback must be
invoked by the container."
JSR-318 PFD2 4.6 - "When the client calls a business method of the
bean that has been designated as a Remove method, or a remove method
on the home or component interface, the container invokes PreDestroy
lifecycle callback interceptor method(s) (if any) for the bean
instance after the
Remove method completes."
JSR-299 is declaring that "destroy" on a contextual object will
invoke a removeal path not defined by EJB.
----
2) JSR-299 defines activity in the middle of EJB Lifecycle
JSR-299 PR2 6.11 - "When the EJB container creates a new instance of
an EJB, the container must perform the following steps after Java EE
injection has been performed and before the @PostConstruct callback
occurs..."
EJB defines no callback mechanism for a hypothetical
@PostInstanciated before @PostConstruct. Thus there's no hook
defined for WB to do its magic.
----
I'd like to open up discussion on either adding these points to EJB
3.1 (a bit late in the game) or revising the JSR-299 spec such that
it doesn't impose upon EJB.
Either way, as I've committed to Pete, I'll be taking on the EJB/WB
integration bits. But I do want to ensure the lines are properly
drawn. If properly scoped, we should have to alter no code under
the EJB3 components to support WB.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
3:31 a.m.
On Wed, Mar 18, 2009 at 1:11 AM, Andrew Lee Rubinger <alr(a)jboss.org> wrote:
* JSR-299 implementations are treated the same as any client of EJB;
they use/consume EJB as one of the target component models.
That is no longer true, since the pluggability contracts have been removed.
EJB and 299 are just aspects of the EE container.
* A mechanism EJB makes available to JSR-299 should be available to
everyone.
I don't see why this should necessarily by the case. 299 is a piece of
the container.
1) EJB does not define an endpoint for SFSB removal outside
business/component method @Remove/remove() and timeout
But 299 does. What's the problem?
2) JSR-299 defines activity in the middle of EJB Lifecycle
JSR-299 PR2 6.11 - "When the EJB container creates a new instance of an EJB,
the container must perform the following steps after Java EE injection has
been performed and before the @PostConstruct callback occurs..."
EJB defines no callback mechanism for a hypothetical @PostInstanciated
before @PostConstruct. Thus there's no hook defined for WB to do its magic.
299 is now part of the container. It doesn't need a hook.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
8:21 a.m.
Gavin King wrote:
On Wed, Mar 18, 2009 at 1:11 AM, Andrew Lee Rubinger
<alr(a)jboss.org> wrote:
> * JSR-299 implementations are treated the same as any client of EJB;
> they use/consume EJB as one of the target component models.
>
That is no longer true, since the pluggability contracts have been removed.
EJB and 299 are just aspects of the EE container.
There is no definition of the EE container yet. There is an EJB (JSR
318) container on top of which we want WB.
In a perfect world we would have a definition of the EE container and
how we can plug EJB and WB into it.
So in effect WB needs a pluggability contract on EJB, whether it's spec
defined or vendor specific.
> * A mechanism EJB makes available to JSR-299 should be available to
> everyone.
>
I don't see why this should necessarily by the case. 299 is a piece of
the container.
The question becomes who's going to build *the* container. I think we
should build it by composition on top of the EJB container which brings
you back into the extension hooks you would need.
> 1) EJB does not define an endpoint for SFSB removal outside
> business/component method @Remove/remove() and timeout
>
But 299 does. What's the problem?
Herein lies no real problem. Personally I find it a bummer that from a
POJO perspective I see another destroy transition outside the bean
definition.
Anyway it just means we just need to go back to some EJB 2 constructs
like EJBHome & EJBObject to make it happen.
So you get SessionObjectHome and SessionObjectReference. Which gives me
an itch.
> 2) JSR-299 defines activity in the middle of EJB Lifecycle
>
> JSR-299 PR2 6.11 - "When the EJB container creates a new instance of an EJB,
> the container must perform the following steps after Java EE injection has
> been performed and before the @PostConstruct callback occurs..."
>
> EJB defines no callback mechanism for a hypothetical @PostInstanciated
> before @PostConstruct. Thus there's no hook defined for WB to do its magic.
>
299 is now part of the container. It doesn't need a hook.
This is exactly the wrong way around and leads into the spec conflict.
Basically once I'm JSR 318 compliant I'm done and you're stuck. We
should need a change request on JSR-318 and possibly define a minimal EE
container.
To make sure we can move forward let's not yet go to JSR-318 yet and
just continue our own internal change request. Still I think JSR-318
could benefit highly from this.
Carlo
2:41 p.m.
My opinion is, given that pluggability is too large to address in the
EE6 timeframe for both EJB 3.1 and JSR299, we are better off
prototyping the pluggability contract between these two specs as
implementation specific hooks which allow us greater flexibility to
get things just right and can be rolled into the next iteration of
these specs (if the demand is there).
On 20 Mar 2009, at 07:21, Carlo de Wolf wrote:
Gavin King wrote:
> On Wed, Mar 18, 2009 at 1:11 AM, Andrew Lee Rubinger
> <alr(a)jboss.org> wrote:
>
>
>> * JSR-299 implementations are treated the same as any client of EJB;
>> they use/consume EJB as one of the target component models.
>>
>
> That is no longer true, since the pluggability contracts have been
> removed.
>
> EJB and 299 are just aspects of the EE container.
>
There is no definition of the EE container yet. There is an EJB (JSR
318) container on top of which we want WB.
In a perfect world we would have a definition of the EE container
and how we can plug EJB and WB into it.
So in effect WB needs a pluggability contract on EJB, whether it's
spec defined or vendor specific.
>
>> * A mechanism EJB makes available to JSR-299 should be available to
>> everyone.
>>
>
> I don't see why this should necessarily by the case. 299 is a piece
> of
> the container.
>
The question becomes who's going to build *the* container. I think
we should build it by composition on top of the EJB container which
brings you back into the extension hooks you would need.
>
>
>> 1) EJB does not define an endpoint for SFSB removal outside
>> business/component method @Remove/remove() and timeout
>>
>
> But 299 does. What's the problem?
>
Herein lies no real problem. Personally I find it a bummer that from
a POJO perspective I see another destroy transition outside the bean
definition.
Anyway it just means we just need to go back to some EJB 2
constructs like EJBHome & EJBObject to make it happen.
So you get SessionObjectHome and SessionObjectReference. Which gives
me an itch.
>
>
>> 2) JSR-299 defines activity in the middle of EJB Lifecycle
>>
>> JSR-299 PR2 6.11 - "When the EJB container creates a new instance
>> of an EJB,
>> the container must perform the following steps after Java EE
>> injection has
>> been performed and before the @PostConstruct callback occurs..."
>>
>> EJB defines no callback mechanism for a hypothetical
>> @PostInstanciated
>> before @PostConstruct. Thus there's no hook defined for WB to do
>> its magic.
>>
>
> 299 is now part of the container. It doesn't need a hook.
>
This is exactly the wrong way around and leads into the spec
conflict. Basically once I'm JSR 318 compliant I'm done and you're
stuck. We should need a change request on JSR-318 and possibly
define a minimal EE container.
To make sure we can move forward let's not yet go to JSR-318 yet and
just continue our own internal change request. Still I think JSR-318
could benefit highly from this.
Carlo
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
6:01 p.m.
On Fri, Mar 20, 2009 at 3:21 AM, Carlo de Wolf <cdewolf(a)redhat.com> wrote:
This is exactly the wrong way around and leads into the spec
conflict.
Basically once I'm JSR 318 compliant I'm done and you're stuck. We should
need a change request on JSR-318 and possibly define a minimal EE container.
This is not even remotely true. Our job as an EE vendor is to
implement all the specs which are required parts of EE6. You can't
assume that you are "done" because you have implemented something that
supports one of the component specs.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5522
days inactive
5524
days old
8 comments
6 participants
participants (6)
-
Andrew Lee Rubinger -
Carlo de Wolf -
Gavin King -
Kenneth Saks -
Pete Muir -
pmuir＠redhat.com