Hi, David: I have finished most of the codes, but after I modeled all the session synchronization callbacks in the interceptor datas, even the methods from the bean class itself, some new questions are coming :-( The most problem is that in current spec, InvocationContext.getParameter should throw IllegalStateException within a lifecycle callback method, from my understanding, afterCompletion is also a lifecycle callback method (actually current OpenEJB codes also think so), but we need the getParameters to get the parameter values. What is your opinion ? Thanks !
2010/6/4 David Blevins <[email protected]> > 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 > > -- Ivan
