[wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB with CDI @Transactional

[Stuart Douglas]

On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva <
eduardo.santanadasilva at gmail.com> wrote:

> Ok,
>
> My approach will be create the following classes:
>
> * ProhibitedEJBAnnotationsAnnotationMarker - Mark the deployment if it has
> EJB annotations that are not allowed (Similar to CDI Annotation marker no
> Weld)
>

I don't really see why you would need to mark the deployment if it has
invalid annotations, you should be able to just fail immediately.

I think all you need is a single DUP that looks at every EJB component
description for this annotation, and if it is present throw an exception.

Stuart


> * ProhibitedEJBAnnotationsDeploymentUnitProcessor - Do the deployment
> rollback in case of the marker is present.
>
>
> Add the proper cleanup of the attachments no EjbCleanUpProcessor
>
> Some auxilar classes to be created:
>
> public enum ProhibitedEJBAnnotations {
>
>     /**
>      * javax.transaction.Transactional annotation.
>
>      */
>
>     TRANSACTIONAL(Constants.JAVAX_TRANSACTION, "Transactional"),
>
> ...
>
>     private static class Constants {
>
>         /**
>          *  package javax.transaction
>          */
>
>         public static final DotName JAVAX_TRANSACTION =
> DotName.createSimple("javax.transaction");
>
> ...
>
> //////////////////////////////////////
> /**
>  * Marker for deployments that have prohibited EJB annotations present
>  */
>
> public final class ProhibitedEJBAnnotationsAnnotationMarker {    (Similar
> to CdiAnnotationMarker on Weld)
>
> ...
>
> public class ProhibitedEJBAnnotationsDeploymentUnitProcessor implements
>
> DeploymentUnitProcessor {
>
>
> If you guys came up with  better names it will be good.
>
> I was wondering as well if the CDIAnnotationMarker can be used directly
> from the Weld subsystem or it will be better isolate the subsystems?
>
> Thx
> __________________________
> Eduardo Sant'Ana da Silva
>
> 2015-03-28 15:05 GMT-03:00 Jason T. Greene <jason.greene at redhat.com>:
>
> Good question. The easiest solution is probably to change one of the EJB
>> dups that looks at annotations to also check for @Transactional and fail
>> accordingly.
>>
>> Sent from my iPhone
>>
>> On Mar 28, 2015, at 11:56 AM, Eduardo Sant´Ana da Silva <
>> eduardo.santanadasilva at gmail.com> wrote:
>>
>> I'm looking at this issue:
>> https://issues.jboss.org/browse/WFLY-4169
>>
>> In the ejb-3_2 specification :
>> It is illegal to associate JTA transactional interceptors (see [8]) with
>> Enterprise JavaBeans. The EJB Container should fail deployment of such
>> applications.[39]
>>
>> @Transaction annotation was introduced in JTA 1.2,
>>
>> As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on
>> Wildfly since version WildFly 8.0.0.Beta1, what should be done?
>>
>> Because this restriction could be removed in the future versions:
>>
>> [39] This restriction may be removed in a future release of this
>> specification
>>
>> If this is needed, how to proceed? Should be done on Weld subsystem,
>> something similar with the annotations markers, just to log the problem or
>> it will be more tricky, since the deployment should be rolled back (by the
>> specification)?
>> --
>> __________________________
>> Eduardo Sant'Ana da Silva
>>
>>  _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
>  _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150329/84d372a0/attachment.html