[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7260:
----------------------------------------
[~honza889] How relevant is this now? If both are set to true then 'need' will always have the highest priority - if one is set to false your latest code within Elytron handles that correctly now.
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-7260:
--------------------------------------
Assignee: Jan Kalina (was: Ilia Vassilev)
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-7150:
-----------------------------------
Component/s: CDI / Weld
Web (Undertow)
> EJB injection with indirection via web.xml is ignored
> -----------------------------------------------------
>
> Key: WFLY-7150
> URL: https://issues.jboss.org/browse/WFLY-7150
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected.
> This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code.
> Reproducer can be found here:
> git@github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5239 at 10/4/16 9:14 AM:
---------------------------------------------------------------
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster (or the tcp-bridge) and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
was (Author: rhusar):
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5239:
--------------------------------------
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1052:
------------------------------------------
Note that this behavior is problematic for the domain config in the context of an HA DC feature (WFCORE-338). It adds another path via which the domain-wide config can be changed underneath the cluster of HCs that are attempting to ensure that the domain is using the correct config.
> Add server-config parameter to :reload op
> -----------------------------------------
>
> Key: WFCORE-1052
> URL: https://issues.jboss.org/browse/WFCORE-1052
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
looks for that file in the snapshots directory
> [13:48] Kabir Khan:
> [standalone@localhost:9990 /] :list-snapshots
> {
> "outcome" => "success",
> "result" => {
> "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
> "names" => [
> "20151013-134523280standalone.xml",
> "20151013-134726769standalone.xml"
> ]
> }
> }
> Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail.
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1851) Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1851?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-6294 to WFCORE-1851:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1851 (was: JBEAP-6294)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha9
(was: 7.1.0.DR5)
(was: 7.1.0.DR6)
> Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1851
> URL: https://issues.jboss.org/browse/WFCORE-1851
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
> Attachments: jboss-kitchensink-ear.ear
>
>
> {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} operation returns inconsistent result depending on whether the deployment is exploded or not. Deployment attached.
> Archived:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/",
> "directory" => true
> }
> ]
> }
> {code}
> Exploded:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "META-INF/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7260:
-----------------------------------
Assignee: Ilia Vassilev
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1668) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1668:
-------------------------------------------------
Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1358556|https://bugzilla.redhat.com/show_bug.cgi?id=1358556] from ON_QA to VERIFIED
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1668
> URL: https://issues.jboss.org/browse/WFCORE-1668
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 3.0.0.Alpha4
>
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months