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

Ok. 2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas(a)gmail.com&gt;: > > On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva < > eduardo.santanadasilva(a)gmail.com&gt; 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(a)redhat.com&gt;: >> >> 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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI