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

Mon Mar 30 08:05:32 EDT 2015

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

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

-- 
__________________________
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/aa9a9ca4/attachment-0001.html 