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

[Eduardo Sant´Ana da Silva]

Ok.

2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas at gmail.com>:

>
>
> 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
>
>


-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150330/7c93c876/attachment.html