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

[Pete Muir]

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 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
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete