[wildfly-dev] WFLY-4169 Wildfly doesn't fail on deployment EJB with CDI @Transactional
Brian Stansberry
brian.stansberry at redhat.com
Mon Mar 30 09:44:34 EDT 2015
DeploymentUnitProcessingException is fine. Whether that triggers
rollback of the deployment or not is not the concern of the DUP.
In this case it doesn't roll back because the deployment scanner is
configured not to roll back deployment ops on runtime failures:
<deployment-scanner path="deployments"
relative-to="jboss.server.base.dir" scan-interval="5000"
runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
Change that last attribute to "true" or use the CLI or console to
deploy, both of which use 'true' by default and you should see the
deployment rolled back.
On 3/30/15 7:05 AM, Eduardo Sant´Ana da Silva wrote:
> What exception should I throw to prevent the deployment? I'm using the
> DeploymentUnitProcessingException that seems to allow the deployment to
> continue.
>
>
> 08:56:08,487 INFO [org.jboss.as.server.deployment] (MSC service thread
> 1-3) WFLYSRV0027: Starting deployment of "WFLY-4169.jar" (runtime-name:
> "WFLY-4169.jar")
>
> 08:56:08,622 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
> MSC000001: Failed to start service
> jboss.deployment.unit."WFLY-4169.jar".PARSE:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment "WFLY-4169.jar"
>
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
>
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at java.lang.Thread.run(Thread.java:745)
>
> Caused by:
> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> WFLYEJB0468: Illegal Enterprise JavaBean annotation:
> javax.transaction.Transactional
>
> at
> org.jboss.as.ejb3.deployment.processors.ProhibitedEJBAnnotationsDeploymentUnitProcessor.deploy(ProhibitedEJBAnnotationsDeploymentUnitProcessor.java:52)
>
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>
> ... 5 more
>
>
> 08:56:08,654 ERROR [org.jboss.as.controller.management-operation]
> (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed
> - address: ([("deployment" => "WFLY-4169.jar")]) - failure description:
> {"WFLYCTL0080: Failed services" =>
> {"jboss.deployment.unit.\"WFLY-4169.jar\".PARSE" =>
> "org.jboss.msc.service.StartException in service
> jboss.deployment.unit.\"WFLY-4169.jar\".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment \"WFLY-4169.jar\"
>
> Caused by:
> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
> WFLYEJB0468: Illegal Enterprise JavaBean annotation:
> javax.transaction.Transactional"}}
>
> 08:56:08,763 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2)
> WFLYSRV0010: Deployed "WFLY-4169.jar" (runtime-name : "WFLY-4169.jar")
>
> 08:56:08,764 INFO [org.jboss.as.controller] (DeploymentScanner-threads
> - 2) WFLYCTL0183: Service status report
>
> WFLYCTL0186: Services which failed to start: service
> jboss.deployment.unit."WFLY-4169.jar".PARSE:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."WFLY-4169.jar".PARSE: WFLYSRV0153: Failed to
> process phase PARSE of deployment "WFLY-4169.jar"
>
>
>
> 2015-03-30 8:01 GMT-03:00 Eduardo Sant´Ana da Silva
> <eduardo.santanadasilva at gmail.com
> <mailto:eduardo.santanadasilva at gmail.com>>:
>
> Ok.
>
> 2015-03-29 19:16 GMT-03:00 Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>>:
>
>
>
> On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva
> <eduardo.santanadasilva at gmail.com
> <mailto: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:
>
> publicenumProhibitedEJBAnnotations{
>
> /**
> * 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 <mailto: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
> <mailto: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
>> <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/__mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
>
>
>
> --
> __________________________
> 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
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list