Jeremy Bauer wrote:
> Our interpretation has been that the transaction context is shared by
> the entire invocation context (not just the bean method) since the
> spec (8.3.7:pd1) defines that the only location where you can specify
> the transaction attribute is on the method on the bean class. For
> example:
>
> @Singleton @Interceptors(MyInterceptor.class)
> public class MySingleton { @PostConstruct
> @TransactionAttribute(NOT_SUPPORTED) void postConstruct() { } }
> public class MyInterceptor { @PostConstruct void
> postConstruct(InvocationContext ic) { /* runs in bean's NOT_SUPPORTED
> tx context */ } }
>
> Is this interpretation correct?
We would need to fix the interceptors spec :(. Can you file a JIRA?
(file under ejb as we don't have an active interceptor spec project).
> If so, I'm ambivalent whether it is named LifecycleInterceptor or
> LifecycleCallback. LifecycleInterceptor does seem to imply that the
> setting could be specified on an arbitrary interceptor class, which
> isn't the case.
Yes.
> On the other hand, "Timer" is actually for timer callbacks and we do
> not use "TimerCallback" so "LifecycleCallback" may introduce a minor
> inconsistency.
We can't fix the existing names, but (I think) we can be more precise
with the new ones.
Experts, if you have a name preference, let me know.
thanks,
-marina
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net
> Date: 06/28/2012 08:36 PM
> Subject: [jsr345-experts] Re: Extending method-intf type in
> deployment descriptor for wild-carding transactional lifecycle
> interceptor methods on a bean class (EJB_SPEC-49)
> ------------------------------------------------------------------------
>
>
>
> Marina Vatkina wrote:
> > Carlo de Wolf wrote:
> >> On 06/27/2012 01:29 AM, Marina Vatkina wrote:
> >>> Experts,
> >>>
> >>> The current list of possible method-intf types include the following:
> >>>
> >>> <xsd:complexType name="method-intfType">
> >>> ...
> >>> <xsd:enumeration value="Home"/>
> >>> <xsd:enumeration value="Remote"/>
> >>> <xsd:enumeration value="LocalHome"/>
> >>> <xsd:enumeration value="Local"/>
> >>> <xsd:enumeration value="ServiceEndpoint"/>
> >>> <xsd:enumeration value="Timer"/>
> >>> <xsd:enumeration value="MessageEndpoint"/>
> >>>
> >>> Which clearly misses an option to use it for the transaction
> >>> settings of the lifecycle callback methods on a singleton or a
> >>> stateful session bean class.
> >>>
> >>> To make it clear that the new type applies to the methods of the
> >>> bean class, not the Interceptor class, let's call it
> >>> "LifecycleCallback", and indeed add it to the xsd schema.
> >>
> >> I presume you mean it applies to the whole callback regardless of
> >> whether it involves methods defined in an interceptor class or the
> >> bean class?
> >
> > No, I mean it only applies to the methods on the bean class itself.
> > The spec allows to set tx attribute only on those methods.
> >
> >> Reading it as such I could interpret it as an interceptor lifecycle
> >> callback having an unspecified tx context.
> >
> > We hadn't change that.
>
> To be more specific, if this to be changed, it needs to be changed in
> the interceptor spec. Though there are some plans to may be have an MR
> for that spec, they are not clear yet...
>
> -marina
> >
> > -marina
> >>
> >> Carlo
> >>
> >>>
> >>> Please let me know if you think otherwise.
> >>>
> >>> thanks,
> >>> -marina
> >>>
> >>> Marina Vatkina wrote:
> >>>> Experts,
> >>>>
> >>>> Please let me and Jeremy know if you agree that such shortcuts in
> >>>> the ejb-jar.xml deployment descriptor are useful to be added.
> >>>>
> >>>> thanks,
> >>>> -marina
> >>>>
> >>>> -------- Original Message --------
> >>>> Subject: [ejb-spec issues] [JIRA] Commented: (EJB_SPEC-49) Add
> >>>> new method-intf type to deployment descriptor for transactional
> >>>> lifecycle interceptors
> >>>> Date: Mon, 14 May 2012 13:56:20 +0000 (GMT+00:00)
> >>>> From: jrbauer (JIRA) <jira-no-reply_at_java.net>
> >>>> Reply-To: issues_at_ejb-spec.java.net
> >>>> To: issues_at_ejb-spec.java.net
> >>>>
> >>>>
> >>>>
> >>>> [
> >>>>
> http://java.net/jira/browse/EJB_SPEC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339606#action_339606
> <http://java.net/jira/browse/EJB_SPEC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339606#action_339606>
>
> >>>> ]
> >>>> jrbauer commented on EJB_SPEC-49:
> >>>> ---------------------------------
> >>>>
> >>>> To further clarify -
> >>>>
> >>>> In particular, the new method-intf type would be useful with
> >>>> wild-carding since it let's you scope to a specific interface
> >>>> type. For example, to set NotSupported for the lifecycle methods
> >>>> without affecting other interfaces:
> >>>>
> >>>> <container-transaction>
> >>>> <method>
> >>>> <ejb-name>MySession</ejb-name>
> >>>> <method-intf>LifecycleInterceptor</method-intf>
> >>>> <method-name>*</method-name>
> >>>> </method>
> >>>> <trans-attribute>NotSupported</trans-attribute>
> >>>> </container-transaction>
> >>>>
> >>>>> Add new method-intf type to deployment descriptor for
> >>>>> transactional lifecycle interceptors
> >>>>>
> ------------------------------------------------------------------------------------------
>
> >>>>>
> >>>>>
> >>>>> Key: EJB_SPEC-49
> >>>>> URL: http://java.net/jira/browse/EJB_SPEC-49
> >>>>> Project: ejb-spec
> >>>>> Issue Type: Improvement
> >>>>> Affects Versions: 3.2
> >>>>> Reporter: jrbauer
> >>>>>
> >>>>> Given that lifecycle callbacks of singleton and stateful bean
> >>>>> interceptors can now run within container managed transactions, I
> >>>>> think we need to add a new method-intf type to the possible values
> >>>>> of the container-transaction->method definition in the DD. The
> >>>>> current values do not provide the ability to specifically target
> >>>>> transaction attributes to this style of interceptor via the DD.
> >>>>> The name "LifecycleInterceptor" seems a good fit. Thoughts?
> >>>>> I've seen at least one location in Javadoc that provides the list
> >>>>> of possible meta-inf values, so at least one, maybe more, updates
> >>>>> would be needed there as well.
> >>>>
> >>
>
>