You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2010/06/02 04:41:09 UTC
SessionSynchronization annotations (was: Re: Hope to contribute OpenEJB project ;-)
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 <xh...@gmail.com>
>
>> 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
Re: SessionSynchronization annotations (was: Re: Hope to contribute OpenEJB project ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 9, 2010, at 7:43 PM, Ivan wrote:
> Hi, David :
> Seems that we could do the samething for AroundTimeout, if no one has
> begun the work, could you assign the JIRA OpenEJB-1172 to me ? I could like
> to work on it.
Excellent, will assign that one to you!
Thanks for the validation patch! We probably still want to expand the test a little more to cover the other checks and messages keys we added. More or less just prune out the unused message keys and write tests to cover the keys that are used.
There are more message keys than checks obviously, but I figured it would be good to commit them to svn anyway so at least they were some place safe if we wanted to add checks for them later. I mean, you took the time to write them already, why not at least get them checked in :)
[added checks]
Modified: openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/rules/CheckCallbacks.java
+ fail(bean, "callback.badModifier", type, callback.getMethodName(), callback.getClassName());
+ fail(bean, "calllback.invalidSessionSynchronizationUse", ejbClass.getName());
+ fail(bean, "callback.sessionSynchronization.invalidUse", ejbClass.getName());
[added keys]
Modified: openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/rules/Messages.properties
+1.callback.badModifier = {0} method must not be final and static
+1.callback.sessionSynchronization.invalidUse = Session synchronizatio...
+1.ann.sessionsynchronization.invalidModifier = @AfterBegin, @BeforeCo...
+1.ann.sessionsynchronization.invalidReturnValue = The return type of ...
+1.ann.sessionsynchronization.noBooleanParameter = The method annotate...
+1.ann.sessionsynchronization.noEmptyParameter = The method annotated ...
+1.ann.sessionSynchronization.invalidUse = Session synchronization ann...
+1.ann.sessionSynchronization.methodNotFound = The session synchroniza...
+1.ann.sessionsynchronization.duplicatedAnnotatedMethod = Each statefu...
No rush on this. Feel free to do it whenever is convenient.
-David
Re: SessionSynchronization annotations (was: Re: Hope to contribute
OpenEJB project ;-)
Posted by Ivan <xh...@gmail.com>.
Hi, David :
Seems that we could do the samething for AroundTimeout, if no one has
begun the work, could you assign the JIRA OpenEJB-1172 to me ? I could like
to work on it.
Thanks !
2010/6/9 Ivan <xh...@gmail.com>
>
>
> 2010/6/9 David Blevins <da...@visi.com>
>
> On Jun 7, 2010, at 4:40 PM, Ivan wrote:
>>
>> > Thanks for the comment, I attach another patch to the JIRA, if any
>> problem,
>> > please let me know :-)
>>
>> Wow. Wonderful patch, Ivan! Doesn't really get any better than that :)
>> Very thorough test case as well.
>>
>> I closed these JIRAs and marked them completed by you:
>>
>> OPENEJB-1147 javax.ejb.AfterBegin
>> OPENEJB-1148 javax.ejb.AfterCompletion
>> OPENEJB-1149 javax.ejb.BeforeCompletion
>> OPENEJB-1215 <after-begin-method> element
>> OPENEJB-1216 <before-completion-method> element
>> OPENEJB-1217 <after-completion-method> element
>> OPENEJB-1218 @AfterBegin overriding via <after-begin-method>
>> OPENEJB-1219 @AfterCompletion overriding via <after-completion-method>
>> OPENEJB-1220 @BeforeCompletion overriding via <before-completion-method>
>>
>>
>> A few more fun things we can tinker with:
>>
>> We can probably get rid of AppModulePreProcessor. This chunk of code can
>> go right into the AnnotationDeployer next to the related annotation:
>>
>> if (SessionSynchronization.class.isAssignableFrom(clazz)) {
>> sessionBean.getAfterBegin().add(new
>> LifecycleCallback(clazz.getName(), "afterBegin"));
>> sessionBean.getBeforeCompletion().add(new
>> LifecycleCallback(clazz.getName(), "beforeCompletion"));
>> sessionBean.getAfterCompletion().add(new
>> LifecycleCallback(clazz.getName(), "afterCompletion"));
>> } else {
>>
>> And this little chunk we can cleverly move into the SessionBean jaxb
>> class:
>>
>> if (sessionBean.getAfterBeginMethod() != null) {
>> sessionBean.getAfterBegin().add(new
>> LifecycleCallback(clazz.getName(),
>> sessionBean.getAfterBeginMethod().getMethodName()));
>> }
>> if (sessionBean.getBeforeCompletionMethod() != null) {
>> sessionBean.getBeforeCompletion().add(new
>> LifecycleCallback(clazz.getName(),
>> sessionBean.getBeforeCompletionMethod().getMethodName()));
>> }
>> if (sessionBean.getAfterCompletionMethod() != null) {
>> sessionBean.getAfterCompletion().add(new
>> LifecycleCallback(clazz.getName(),
>> sessionBean.getAfterCompletionMethod().getMethodName()));
>> }
>>
>> Take a look at the sneaky little trick we use in the MessageDrivenBean
>> jaxb class for handling the deprecated message-selector and
>> acknowledge-mode. :)
>>
>
> Actually that is what I did in the beginning, but after thinking it for a
> while, it might not work.
> a. AnnotationDeployer will not be invoked while META-COMPLETE is with
> value true, but we still need to configure those three methods, that is why
> I add the AppModulePreProssor class.
> b. Currently, we treat the session synchronization methods the same way as
> other lifecycle methods, but it has a little different, as in the past, we
> usually implment an interface if we intertested in those callbacks. So I
> would think that the bean class implment the SessionSynchronization
> interface should have the high priority IMO.
>
>
>
>>
>> On the validation front, let's expand the CheckInvalidCallbacksTest test
>> to cover the new checks we do. That test could really be expanded in
>> general, so feel free to have as much fun with it as you want. You can
>> attach that one to this JIRA:
>>
>> https://issues.apache.org/jira/browse/OPENEJB-1295
>
>
> Will check it soon !
>
>
>>
>>
>>
>> On our getParameters() TODO looks like we can expand that if block to
>> check if the operation is AFTER_COMPLETION and not throw the
>> IllegalArgumentException.
>>
>
> Just not sure whether it will break current spec definition, will add it.
>
>>
>>
>> Thanks so much for such a great patch!
>>
>>
>> -David
>>
>>
>
>
> --
> Ivan
>
--
Ivan
Re: SessionSynchronization annotations (was: Re: Hope to contribute
OpenEJB project ;-)
Posted by Ivan <xh...@gmail.com>.
2010/6/9 David Blevins <da...@visi.com>
> On Jun 7, 2010, at 4:40 PM, Ivan wrote:
>
> > Thanks for the comment, I attach another patch to the JIRA, if any
> problem,
> > please let me know :-)
>
> Wow. Wonderful patch, Ivan! Doesn't really get any better than that :)
> Very thorough test case as well.
>
> I closed these JIRAs and marked them completed by you:
>
> OPENEJB-1147 javax.ejb.AfterBegin
> OPENEJB-1148 javax.ejb.AfterCompletion
> OPENEJB-1149 javax.ejb.BeforeCompletion
> OPENEJB-1215 <after-begin-method> element
> OPENEJB-1216 <before-completion-method> element
> OPENEJB-1217 <after-completion-method> element
> OPENEJB-1218 @AfterBegin overriding via <after-begin-method>
> OPENEJB-1219 @AfterCompletion overriding via <after-completion-method>
> OPENEJB-1220 @BeforeCompletion overriding via <before-completion-method>
>
>
> A few more fun things we can tinker with:
>
> We can probably get rid of AppModulePreProcessor. This chunk of code can
> go right into the AnnotationDeployer next to the related annotation:
>
> if (SessionSynchronization.class.isAssignableFrom(clazz)) {
> sessionBean.getAfterBegin().add(new
> LifecycleCallback(clazz.getName(), "afterBegin"));
> sessionBean.getBeforeCompletion().add(new
> LifecycleCallback(clazz.getName(), "beforeCompletion"));
> sessionBean.getAfterCompletion().add(new
> LifecycleCallback(clazz.getName(), "afterCompletion"));
> } else {
>
> And this little chunk we can cleverly move into the SessionBean jaxb class:
>
> if (sessionBean.getAfterBeginMethod() != null) {
> sessionBean.getAfterBegin().add(new
> LifecycleCallback(clazz.getName(),
> sessionBean.getAfterBeginMethod().getMethodName()));
> }
> if (sessionBean.getBeforeCompletionMethod() != null) {
> sessionBean.getBeforeCompletion().add(new
> LifecycleCallback(clazz.getName(),
> sessionBean.getBeforeCompletionMethod().getMethodName()));
> }
> if (sessionBean.getAfterCompletionMethod() != null) {
> sessionBean.getAfterCompletion().add(new
> LifecycleCallback(clazz.getName(),
> sessionBean.getAfterCompletionMethod().getMethodName()));
> }
>
> Take a look at the sneaky little trick we use in the MessageDrivenBean jaxb
> class for handling the deprecated message-selector and acknowledge-mode. :)
>
Actually that is what I did in the beginning, but after thinking it for a
while, it might not work.
a. AnnotationDeployer will not be invoked while META-COMPLETE is with value
true, but we still need to configure those three methods, that is why I add
the AppModulePreProssor class.
b. Currently, we treat the session synchronization methods the same way as
other lifecycle methods, but it has a little different, as in the past, we
usually implment an interface if we intertested in those callbacks. So I
would think that the bean class implment the SessionSynchronization
interface should have the high priority IMO.
>
> On the validation front, let's expand the CheckInvalidCallbacksTest test to
> cover the new checks we do. That test could really be expanded in general,
> so feel free to have as much fun with it as you want. You can attach that
> one to this JIRA:
>
> https://issues.apache.org/jira/browse/OPENEJB-1295
Will check it soon !
>
>
>
> On our getParameters() TODO looks like we can expand that if block to check
> if the operation is AFTER_COMPLETION and not throw the
> IllegalArgumentException.
>
Just not sure whether it will break current spec definition, will add it.
>
>
> Thanks so much for such a great patch!
>
>
> -David
>
>
--
Ivan
Re: SessionSynchronization annotations (was: Re: Hope to contribute OpenEJB project ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 7, 2010, at 4:40 PM, Ivan wrote:
> Thanks for the comment, I attach another patch to the JIRA, if any problem,
> please let me know :-)
Wow. Wonderful patch, Ivan! Doesn't really get any better than that :) Very thorough test case as well.
I closed these JIRAs and marked them completed by you:
OPENEJB-1147 javax.ejb.AfterBegin
OPENEJB-1148 javax.ejb.AfterCompletion
OPENEJB-1149 javax.ejb.BeforeCompletion
OPENEJB-1215 <after-begin-method> element
OPENEJB-1216 <before-completion-method> element
OPENEJB-1217 <after-completion-method> element
OPENEJB-1218 @AfterBegin overriding via <after-begin-method>
OPENEJB-1219 @AfterCompletion overriding via <after-completion-method>
OPENEJB-1220 @BeforeCompletion overriding via <before-completion-method>
A few more fun things we can tinker with:
We can probably get rid of AppModulePreProcessor. This chunk of code can go right into the AnnotationDeployer next to the related annotation:
if (SessionSynchronization.class.isAssignableFrom(clazz)) {
sessionBean.getAfterBegin().add(new LifecycleCallback(clazz.getName(), "afterBegin"));
sessionBean.getBeforeCompletion().add(new LifecycleCallback(clazz.getName(), "beforeCompletion"));
sessionBean.getAfterCompletion().add(new LifecycleCallback(clazz.getName(), "afterCompletion"));
} else {
And this little chunk we can cleverly move into the SessionBean jaxb class:
if (sessionBean.getAfterBeginMethod() != null) {
sessionBean.getAfterBegin().add(new LifecycleCallback(clazz.getName(), sessionBean.getAfterBeginMethod().getMethodName()));
}
if (sessionBean.getBeforeCompletionMethod() != null) {
sessionBean.getBeforeCompletion().add(new LifecycleCallback(clazz.getName(), sessionBean.getBeforeCompletionMethod().getMethodName()));
}
if (sessionBean.getAfterCompletionMethod() != null) {
sessionBean.getAfterCompletion().add(new LifecycleCallback(clazz.getName(), sessionBean.getAfterCompletionMethod().getMethodName()));
}
Take a look at the sneaky little trick we use in the MessageDrivenBean jaxb class for handling the deprecated message-selector and acknowledge-mode. :)
On the validation front, let's expand the CheckInvalidCallbacksTest test to cover the new checks we do. That test could really be expanded in general, so feel free to have as much fun with it as you want. You can attach that one to this JIRA:
https://issues.apache.org/jira/browse/OPENEJB-1295
On our getParameters() TODO looks like we can expand that if block to check if the operation is AFTER_COMPLETION and not throw the IllegalArgumentException.
Thanks so much for such a great patch!
-David
Re: SessionSynchronization annotations (was: Re: Hope to contribute
OpenEJB project ;-)
Posted by Ivan <xh...@gmail.com>.
Thanks for the comment, I attach another patch to the JIRA, if any problem,
please let me know :-)
2010/6/8 David Blevins <da...@visi.com>
>
> On Jun 7, 2010, at 7:35 AM, Ivan wrote:
>
> > 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 :-(
>
> That frowny-face should be a smiley-face, I love questions :)
>
> > 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
> !
>
> Good catch. Hmmm. I can't think of anything simple and direct for bending
> the rules for this one method. Maybe for now we should just let it throw
> the IllegalStateException, at least temporarily.
>
> My gut says there must be some nice and elegant way to work around it, but
> my brain isn't cooperating with any answers :)
>
>
> -David
>
>
--
Ivan
Re: SessionSynchronization annotations (was: Re: Hope to contribute OpenEJB project ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 7, 2010, at 7:35 AM, Ivan wrote:
> 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 :-(
That frowny-face should be a smiley-face, I love questions :)
> 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 !
Good catch. Hmmm. I can't think of anything simple and direct for bending the rules for this one method. Maybe for now we should just let it throw the IllegalStateException, at least temporarily.
My gut says there must be some nice and elegant way to work around it, but my brain isn't cooperating with any answers :)
-David
Re: SessionSynchronization annotations (was: Re: Hope to contribute
OpenEJB project ;-)
Posted by Ivan <xh...@gmail.com>.
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 <da...@visi.com>
> 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 <da...@visi.com>
> >
> >> 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 <xh...@gmail.com>
> >>>
> >>>> 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
Re: SessionSynchronization annotations (was: Re: Hope to contribute OpenEJB project ;-)
Posted by David Blevins <da...@visi.com>.
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 <da...@visi.com>
>
>> 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 <xh...@gmail.com>
>>>
>>>> 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
Re: SessionSynchronization annotations (was: Re: Hope to contribute
OpenEJB project ;-)
Posted by Ivan <xh...@gmail.com>.
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) ?
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 ?
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.
Thanks !
2010/6/2 David Blevins <da...@visi.com>
> 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 <xh...@gmail.com>
> >
> >> 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