[JBoss JIRA] (WFLY-4353) Incompliant CDI behavior since WFLY-4185
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4353?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-4353:
---------------------------------
Description:
WFLY-4185/WFLY-4350 introduced an ability to specify producers in Servlet listeners and other non-EJB Java-EE components.
This behavior is not compliant per CDI-spec, as discussed in WELD-1872.
Specifically, "Servlet listeners are not considered beans (even though they support injection and interception)." Therefore, no producers should be registered on servlet listeners to ensure portable compliant behavior.
However, current behavior is also not acceptable, since no warnings or errors are produced in response to encountering the producers in components that should have none.
Therefore, I propose:
# Revert WFLY-4185
# Add
## at a minimum, warning-level log messages when encountering managed bean annotations for non-bean components; or
## fail the deployment for strict compliance with the spec when encountering managed bean annotations for non-bean components
was:
WFLY-4185/WFLY-4350 introduced an ability to specify producers in Servlet listeners and other non-EJB components.
This behavior is not compliant per CDI-spec, as discussed in WELD-1872.
Specifically, "Servlet listeners are not considered beans (even though they support injection and interception)." Therefore, no producers should be registered on servlet listeners to ensure portable compliant behavior.
However, current behavior is also not acceptable, since no warnings or errors are produced in response to encountering the producers in components that should have none.
Therefore, I propose:
# Revert WFLY-4185
# Add
## at a minimum, warning-level log messages when encountering managed bean annotations for non-bean components; or
## fail the deployment for strict compliance with the spec when encountering managed bean annotations for non-bean components
> Incompliant CDI behavior since WFLY-4185
> ----------------------------------------
>
> Key: WFLY-4353
> URL: https://issues.jboss.org/browse/WFLY-4353
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Arcadiy Ivanov
> Assignee: Stuart Douglas
> Priority: Minor
>
> WFLY-4185/WFLY-4350 introduced an ability to specify producers in Servlet listeners and other non-EJB Java-EE components.
> This behavior is not compliant per CDI-spec, as discussed in WELD-1872.
> Specifically, "Servlet listeners are not considered beans (even though they support injection and interception)." Therefore, no producers should be registered on servlet listeners to ensure portable compliant behavior.
> However, current behavior is also not acceptable, since no warnings or errors are produced in response to encountering the producers in components that should have none.
> Therefore, I propose:
> # Revert WFLY-4185
> # Add
> ## at a minimum, warning-level log messages when encountering managed bean annotations for non-bean components; or
> ## fail the deployment for strict compliance with the spec when encountering managed bean annotations for non-bean components
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4353) Incompliant CDI behavior since WFLY-4185
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-4353:
------------------------------------
Summary: Incompliant CDI behavior since WFLY-4185
Key: WFLY-4353
URL: https://issues.jboss.org/browse/WFLY-4353
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Reporter: Arcadiy Ivanov
Assignee: Stuart Douglas
Priority: Minor
WFLY-4185/WFLY-4350 introduced an ability to specify producers in Servlet listeners and other non-EJB components.
This behavior is not compliant per CDI-spec, as discussed in WELD-1872.
Specifically, "Servlet listeners are not considered beans (even though they support injection and interception)." Therefore, no producers should be registered on servlet listeners to ensure portable compliant behavior.
However, current behavior is also not acceptable, since no warnings or errors are produced in response to encountering the producers in components that should have none.
Therefore, I propose:
# Revert WFLY-4185
# Add
## at a minimum, warning-level log messages when encountering managed bean annotations for non-bean components; or
## fail the deployment for strict compliance with the spec when encountering managed bean annotations for non-bean components
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4272?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4272:
-----------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1181132|https://bugzilla.redhat.com/show_bug.cgi?id=1181132] from NEW to POST
> Data inconsistency for CMR when connection is broken after database resource commits
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4272
> URL: https://issues.jboss.org/browse/WFLY-4272
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Tom Jenkinson
> Assignee: Jesper Pedersen
>
> Cloned from:
> https://bugzilla.redhat.com/show_bug.cgi?id=1181132
> Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote:
> We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction.
> That ends in situation where db resource was committed and other XA participants are rollbacked.
> This is test flow:
> - prepare DB xa resource
> - prepare test xa resource
> - commit DB xa resource
> - DB commits
> - before confirmation is received by TM the connection crashes
> - jdbc driver returns XAException.XA_RBROLLBACK as connection is down
> - doAbort is called for the transaction
> - test xa resource is rollbacked
> - doForget is called and no information about the inconsistent transaction remains in object store
> - recovery manager does nothing
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBJCA-1244) LocalXAResourceImpl returns RBROLLBACK in certain scenarios which violate the XA specification
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1244?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1244:
------------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1181132|https://bugzilla.redhat.com/show_bug.cgi?id=1181132] from NEW to POST
> LocalXAResourceImpl returns RBROLLBACK in certain scenarios which violate the XA specification
> ----------------------------------------------------------------------------------------------
>
> Key: JBJCA-1244
> URL: https://issues.jboss.org/browse/JBJCA-1244
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.30.Final
> Reporter: Tom Jenkinson
> Assignee: Jesper Pedersen
> Fix For: 1.0.31.Final, 1.2.3.Final
>
>
> The XA specification states the following about the RBROLLBACK error code for xa_commit():
> {quote}
> [XA_RB∗]
> The resource manager did not commit the work done on behalf of the transaction branch. Upon return, the resource manager has rolled back the branch’s work and has released all held resources. These values may be returned only if TMONEPHASE is set in flags:
> [XA_RBROLLBACK]
> The resource manager rolled back the transaction branch for an unspecified reason
> {quote}
> It is clear that the RBROLLBACK code may only be returned if the branch is known to have rolled back (and indeed if the onePhase flag is set to true).
> To cater for scenarios where the XAResource is not able to determine the outcome of the resource managers commit. In those scenarios the XA specification is clear that the only legal error code to return is:
> {quote}
> [XAER_RMFAIL]
> An error occurred that makes the resource manager unavailable.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-4185 at 2/16/15 9:26 AM:
---------------------------------------------------------------
Stuart, this change, while certainly fixing PicketLink problem, makes WildFly incompliant with Java EE spec.
Per Martin in WELD-1872: "Servlet listeners are not considered beans (even though they support injection and interception). See also 3.6. Java EE components. It's recommended not to define producer methods on Java EE components. So at least this will not be portable."
was (Author: arcivanov):
Stuart, this change, while certainly fixing PicketLink problem, make WildFly incompliant with Java EE spec.
Per Martin in WELD-1872: "Servlet listeners are not considered beans (even though they support injection and interception). See also 3.6. Java EE components. It's recommended not to define producer methods on Java EE components. So at least this will not be portable."
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-4185:
--------------------------------------
Stuart, this change, while certainly fixing PicketLink problem, make WildFly incompliant with Java EE spec.
Per Martin in WELD-1872: "Servlet listeners are not considered beans (even though they support injection and interception). See also 3.6. Java EE components. It's recommended not to define producer methods on Java EE components. So at least this will not be portable."
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1900) Programmatic channel creation ignores system properties for protocol attrs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1900?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1900:
--------------------------------
OK, variables don't exist outside of an XML config, so this doesn't make any sense. However, we can substitute default values, e.g. {{TP.bind_addr}} with the value of system prop {{jgroups.bind_addr}}.
> Programmatic channel creation ignores system properties for protocol attrs
> --------------------------------------------------------------------------
>
> Key: JGRP-1900
> URL: https://issues.jboss.org/browse/JGRP-1900
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.2
>
>
> When using programmatic creation of a JChannel
> * Variables are not substituted, e.g. {{myvar="$\{my.port:10\}"}}
> * System properties are ignored, e.g. {{-Djgroups.bind_addr=192.168.1.5}} does *not* set {{TP.bind_addr}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months