[webbeans-dev] Spec Conflicts Between JSR-299, JSR-318

[Carlo de Wolf]

Gavin King wrote:
> On Wed, Mar 18, 2009 at 1:11 AM, Andrew Lee Rubinger <alr at 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