Hi Ivan! On Jun 3, 2010, at 12:48 AM, Ivan wrote:
> Hi, David: > Thanks for your advice. > a. While trying to treat the session synchronization methods in the same > way as those bean lifecycle method, I encounter an issue. For the > afterCompletion method, it has method argment (boolean type), which is not > like those other methods. So, what is the formt if it is in intercept class, > something like > void <METHOD>(InvocationContext, boolean) ? I would go with plain 'void <METHOD>(InvocationContext)' which is similar to the AroundInvoke logic. The boolean will automatically be available via invocationContext.getParameters(); > b. I double check the schema file for > afterBegin/beforeCompletion/afterCompletion, they are : > ---> > <xsd:element name="after-begin-method" > type="javaee:named-methodType" > minOccurs="0"/> > <--- > Which means that it is of maxOccurs="1", not the same with other > lifecycle callbacks, so if we add them go ahead in the intercept defintion, > what should it like ? Let's still go with a list so that the processCallbacks logic can still be used equally for both interceptors and beans. > c. In the EJB 3.1 spec 4.1.9, one line writes "Each bean has at most one > session synchronization method for each of the three annotation types. In > the case of method overriding of session synchronization methods declared by > annotations, the most derived method takes precedence. " > Not sure I understand this line correctly, does it mean that if > methods annotated in parent class should not be considered, only the most > derived method will be considered ? If does, it might be different from > other lifecycle methods. That language is definitely more restrictive. Fortunately the code that sorts the CallbackInfo objects in the assembler will automatically sort them in order of most derived. So if the TCK has a problem with the added functionality, we can easily alter the code to just grab the last index of the InterceptorData list and use just that. Then we could just make a system property or something that can turn back on the "fully intercepted" approach. On a side note, don't worry about updating to the most recent AnnotationDeployer. Try and work with the one that's just before David J's commit. I'm going to try and rework it so it is just like it was (no subclassing) and simply uses different code to get the ClassFinder. Oh, and I recall from the previous patch that it did a "if has afterBegin method, invoke afterBegin". Instead we would just always create the ReflectiveInvocationContext and invoke it just like we do for @PostConstruct or @PostActivate callbacks which are also optional. I'm pretty excited. This will be a great competitive feature! -David > 2010/6/2 David Blevins <[email protected]> > >> Hi Ivan! >> >> Looks like a fantastic start! >> >> One quick note, is that <around-timeout> is a list and @AroundTimeout can >> be used multiple times due to inheritance. >> >> What we can do is model the @AfterBegin, etc. after the @PostActivate type >> code. So we could process them in AnnotationDeployer.processCallbacks with >> @PostActivate, etc. >> >> In terms of validation we could move that into the CheckCallbacks class so >> it works for xml as well. >> >> Also we should update the ejb-jar.xml used in the JeeTest to have the new >> elements. >> >> Interceptors can have @AfterBegin as well, just like they can have >> @PostActivate, etc. as well. So we'll want to add that into InterceptorInfo >> and related. >> >> I love the static/final validation check. We should definitely incorporate >> that into the CheckCallbacks class. As we could greatly improve the >> CheckInvalidCallbacksTest to have invalid static/final and use some >> incorrect signatures and return types. >> >> I'll try and commit this patch and we can work on the above in a second >> iteration. >> >> >> Really great work in general! Very surprised how quick you got it all put >> together! >> >> >> -David >> >> >> On May 31, 2010, at 6:21 PM, Ivan wrote: >> >>> Hi, devs: >>> I attached a patch to OpenEJB-1147, it contains support for those new >>> session synchronization, please help to review it when you are available. >>> By the way, could anyone add me to the contribution list, so that I could >>> assign the JIRA to myself :-) >>> Thanks ! >>> >>> 2010/5/27 Ivan <[email protected]> >>> >>>> Hi devs : >>>> I hope to try to do some contributions to the OpenEJB project, I >> found >>>> a JIRA OPENEJB-1133, it seems to list some unimplemented functions for >> EJB >>>> 3.1. I hope that someone could show me some start points ? >>>> Thanks ! >>>> -- >>>> Ivan >>>> >>> >>> >>> >>> -- >>> Ivan >> >> > > > -- > Ivan
