5:56 p.m.
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
7:05 p.m.
New subject: WFLY-4169 Wildfly doesn't fail on deployment EJB with CDI @Transactional
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> 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
12:34 p.m.
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)
* 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>:
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> 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
12:16 a.m.
On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva <
eduardo.santanadasilva(a)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(a)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(a)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(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
1:01 p.m.
Ok.
2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas(a)gmail.com>:
On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva <
eduardo.santanadasilva(a)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(a)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(a)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(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
2:05 p.m.
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(a)gmail.com>:
Ok.
2015-03-29 19:16 GMT-03:00 Stuart Douglas <stuart.w.douglas(a)gmail.com>:
>
> On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva <
> eduardo.santanadasilva(a)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(a)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(a)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(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
--
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
3:44 p.m.
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(a)gmail.com
<mailto:eduardo.santanadasilva@gmail.com>>:
Ok.
2015-03-29 19:16 GMT-03:00 Stuart Douglas
<stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>>:
On Sun, 29 Mar 2015 at 21:34 Eduardo Sant´Ana da Silva
<eduardo.santanadasilva(a)gmail.com
<mailto:eduardo.santanadasilva@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(a)redhat.com <mailto:jason.greene@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(a)gmail.com
<mailto:eduardo.santanadasilva@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(a)lists.jboss.org
> <mailto:wildfly-dev@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 <mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3314
days inactive
3316
days old
6 comments
4 participants
participants (4)
-
Brian Stansberry -
Eduardo Sant´Ana da Silva -
Jason T. Greene -
Stuart Douglas