On Mar 17, 2009, at 2:28 PM, Pete Muir wrote: > All, > > Based on coversations today with ALR and Ken, I've produced a > slightly updated SPI which is better aligned with the EJB > lifecycle. You can read the contracts here: > > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... > - resolveEJB(EjbDescriptor<?> descriptor, NamingContext context); > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... Hi Pete, What's the purpose of the NamingContext parameter on the resolveEJB() method? The EjbDescriptor object is provided by the ejb container so I would expect that to already encapsulate everything needed by the ejb container to resolve the EJB.

> > I'm still not convinced I have the terminology right here, so > please suggest changes to signatures as needed :-) > > Note that at the moment there is still a discussion about how the > SLSB and singleton lifecycle interacts with JSR299, so I've > concentrated on the SFSB case here - we'll go into more depth on > the SLSB/singleton case once we've clarified our understanding of > how JSR299 should behave. > > We also discussed in some detail the contract imposed by A2. > Session Bean Interceptor http://docs.jboss.org/webbeans/reference/snapshot/en-US/html/ri-spi.html > > ALR said that he would prefer us to register for lifecycle > callbacks from the EJB container programatically, rather than use > an EJB interceptor. > > I'll think about the API for this later today, but in essence we > would pass an extra object as part of the resolveEJB call above, > which would implement some callback interface in the Web Beans SPI > that allowed us to listen for at least postConstruct, > preInvokeBusinessMethod and preDestroy. The JBoss-Web Beans > integration project would then have to decorate this with an > interface JBoss EJB knows about, and somehow pass it to JBoss EJB3 > for registration. > > ALR, do you think we need to do this for the 1.0 of Web Beans, or > can address it for 1.1? I certainly agree that programmatic > registration of an interceptor is less brittle than the current > ThreadLocal approach, but if we can get away with the ThreadLocal > for now, it gives us more time work on a good SPI. > > BTW I think a good SPI would be to pass an EJB interceptor through > the resolveEJB method (which is a well known SPI). If we were to add explicit registration of the interceptor in the SPI it would be more appropriate to configure it at the bean-level at container initialization time rather than as part of the client's acquisition of a component reference at runtime. Doing it during resolveEJB might work in the contextual stateful session bean case but it doesn't work with non-contextual stateful session beans or stateless / singleton / message-driven beans.

--ken > Then e.g. Glassfish could register this as a system interceptor, > whilst JBoss EJB3 could adapt this to be lifecycle callbacks... > > Best, > > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete >

Pete Muir wrote: > We also discussed in some detail the contract imposed by A2. > Session Bean Interceptor http://docs.jboss.org/webbeans/reference/snapshot/en-US/html/ri-spi.html > ALR said that he would prefer us to register for lifecycle > callbacks from the EJB container programatically, rather than use > an EJB interceptor. I raised this point to address a portable mechanism for JSR-299 to integrate with EJB Implementations, where 299 is an add-on (consumer/ client) atop EJB3. If that's left out of scope as Ken suggests, any vendor-specific way to get the job done should suffice. Especially in the case of JBoss WebBeans, which is solving the problem without touching the EJB3 codebase (==good).

> I'll think about the API for this later today, but in essence we > would pass an extra object as part of the resolveEJB call above, > which would implement some callback interface in the Web Beans SPI > that allowed us to listen for at least postConstruct, > preInvokeBusinessMethod and preDestroy. The JBoss-Web Beans > integration project would then have to decorate this with an > interface JBoss EJB knows about, and somehow pass it to JBoss EJB3 > for registration. > ALR, do you think we need to do this for the 1.0 of Web Beans, or > can address it for 1.1? I certainly agree that programmatic > registration of an interceptor is less brittle than the current > ThreadLocal approach, but if we can get away with the ThreadLocal > for now, it gives us more time work on a good SPI. The current mechanism should be good for the time being. My concern is in imposing upon other vendors a specific implementation approach.

To that end, there are a few impositions the 299 spec defines that are outside of the EJB spec, and I'll raise those points in a more appropriate forum (the public webbeans-dev-list) * SFSB remove() bypassing business method @Remove * 299 injection inbetween backing object instance creation and @PostConstruct (violating the client view)

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

I still haven't seen a design that can actually work in AS. It all boils down the the MicroContainer integration. You can't resolve an EJB at any point in time, you can only resolve it using EjbServices interface after the EJBs are actually started. So first you must resolve your metadata to come up with a dependency item for the WB. This *must* be addressed.

On another note I would name the SessionObjectReference.getReference method getBusinessObject (in the likes of SessionContext.getBusinessObject).

And both should throw an NoSuchEJBException if the EJB is already removed.

(Note: keep the IllegalStateException for invalid businessInterface.)

I like the notion of a class interceptor (SessionBeanInterceptor) though, because it's a well defined interface which covers all needs. Except we need another notion than class interceptor to make sure it is registered in at the right time. So in effect we need to expose an interface that allows WB to bind an EJB interceptor in place. Hmm, this can be done in VDF with a SeamBeanInterceptorDeployer to modify the EJB metadata coming past.

I am wondering about other EJB interceptors though, can't they participate in WB? E.g. can I have bijection on EJB interceptors? To me an EJB is a bean and interceptor instances.

Carlo Pete Muir wrote: > All, > > Based on coversations today with ALR and Ken, I've produced a > slightly updated SPI which is better aligned with the EJB > lifecycle. You can read the contracts here: > > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... > - resolveEJB(EjbDescriptor<?> descriptor, NamingContext context); > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... > > I'm still not convinced I have the terminology right here, so > please suggest changes to signatures as needed :-) > > Note that at the moment there is still a discussion about how the > SLSB and singleton lifecycle interacts with JSR299, so I've > concentrated on the SFSB case here - we'll go into more depth on > the SLSB/singleton case once we've clarified our understanding of > how JSR299 should behave. > > We also discussed in some detail the contract imposed by A2. > Session Bean Interceptor http://docs.jboss.org/webbeans/reference/snapshot/en-US/html/ri-spi.html > > ALR said that he would prefer us to register for lifecycle > callbacks from the EJB container programatically, rather than use > an EJB interceptor. > > I'll think about the API for this later today, but in essence we > would pass an extra object as part of the resolveEJB call above, > which would implement some callback interface in the Web Beans SPI > that allowed us to listen for at least postConstruct, > preInvokeBusinessMethod and preDestroy. The JBoss-Web Beans > integration project would then have to decorate this with an > interface JBoss EJB knows about, and somehow pass it to JBoss EJB3 > for registration. > > ALR, do you think we need to do this for the 1.0 of Web Beans, or > can address it for 1.1? I certainly agree that programmatic > registration of an interceptor is less brittle than the current > ThreadLocal approach, but if we can get away with the ThreadLocal > for now, it gives us more time work on a good SPI. > > BTW I think a good SPI would be to pass an EJB interceptor through > the resolveEJB method (which is a well known SPI). Then e.g. > Glassfish could register this as a system interceptor, whilst JBoss > EJB3 could adapt this to be lifecycle callbacks... > > Best, > > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete >

Pete Muir wrote: > > On 17 Mar 2009, at 22:29, Carlo de Wolf wrote: > > ... > >> On another note I would name the >> SessionObjectReference.getReference method getBusinessObject (in >> the likes of SessionContext.getBusinessObject). > > Done > >> And both should throw an NoSuchEJBException if the EJB is already >> removed. > > Done > >> (Note: keep the IllegalStateException for invalid >> businessInterface.) > > Not IllegalArgumentException? I went for IllegalArguementException > > I also did the changes Ken suggested whilst there... Well actually I hate both exceptions in this case. I went for IllegalStateException, because that's how SessionContext.getBusinessObject works, IllegalArgumentException would have been the obvious.

I don't entirely agree with Bloch's guidelines for exception handling (#1). To me the guideline should be: a checked exception whenever an user error is encountered. A precondition on an argument is an user error. So NoSuchBusinessInterfaceException would have been better. Then again this leads to ugly coding (#2), so it might even be better to add boolean SessionContext.isBusinessInterface(Class<?> businessInterface); Then it becomes a programming error again. Ken, does this argument make sense to you? If so, I'll raise it in EJB-EG. > ... > Carlo #1: Effective Java Item 40: Use checked exception for recoverable conditions and run-time exceptions for programming errors #2: EJ Item 41: Avoid unnecessary use of checked exceptions

>> I still haven't seen a design that can actually work in AS. >> It all boils down the the MicroContainer integration. You can't >> resolve an EJB at any point in time, you can only resolve it using >> EjbServices interface after the EJBs are actually started. So >> first you must resolve your metadata to come up with a dependency >> item for the WB. This *must* be addressed. > Yes, I agree - I have this JIRA issue for it - https://jira.jboss.org/jira/browse/WBINT-3 > - this is also a general issue for any container that wishes to > integrate WB I think. > I'll talk to Ales tomorrow and see how he thinks we should best > expose this info from WB (which is not MC based). I guess we need to add proper dependencies on the WB bootstrap bean, making sure EJBs are started before bootstrap is installed. Carlo or ALR, how do I get the EJB's names from DeploymentUnit? JBossMetaData or something even smaller? Afaik WB can ref EJBs from other deployments. How does this issue work for those EJBs? Since we probably only know which EJB is refed by examining WB bean? e.g. examine each WB bean --> add external EJB-start dependency?

Apart from EJBs, any other WB components that would need this too?

On 18 Mar 2009, at 09:42, Ales Justin wrote: >>> I still haven't seen a design that can actually work in AS. >>> It all boils down the the MicroContainer integration. You can't >>> resolve an EJB at any point in time, you can only resolve it using >>> EjbServices interface after the EJBs are actually started. So first >>> you must resolve your metadata to come up with a dependency item >>> for the WB. This *must* be addressed. >> Yes, I agree - I have this JIRA issue for it - >> https://jira.jboss.org/jira/browse/WBINT-3 - this is also a general >> issue for any container that wishes to integrate WB I think. >> I'll talk to Ales tomorrow and see how he thinks we should best >> expose this info from WB (which is not MC based). > > I guess we need to add proper dependencies on the WB bootstrap bean, > making sure EJBs are started before bootstrap is installed. > > Carlo or ALR, how do I get the EJB's names from DeploymentUnit? > JBossMetaData or something even smaller?

> > > Afaik WB can ref EJBs from other deployments. > How does this issue work for those EJBs? > Since we probably only know which EJB is refed by examining WB bean? > e.g. examine each WB bean --> add external EJB-start dependency? This is what I thought while trying to get to sleep last night. WB knows all EJBs it is interested in (currently the all EJBs in the DU), so we can depend on them. Tangentially, I should alter the bootstrap so that we do EJB discovery (and class discovery) in the initialize phase I think, this just makes this better defined.

> Apart from EJBs, any other WB components that would need this too? * JMS (not yet impl'd in WB so...) * PersistenceUnits

* stuff injected via @Resource

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