[JBoss JIRA] (WFLY-8678) Re-enable tests temporarily disabled in -Delytron run.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8678?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-8678:
----------------------------------
Unignored and no failure. (except one which seem to be unrelated...)
> Re-enable tests temporarily disabled in -Delytron run.
> ------------------------------------------------------
>
> Key: WFLY-8678
> URL: https://issues.jboss.org/browse/WFLY-8678
> Project: WildFly
> Issue Type: Task
> Components: Security, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> The following tests are temporarily ignored: -
> Tests in error:
> ExportImportJournalTestCase.testExportImportJournal:136->sendMessage:77 » Communication
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSQueueManagementTestCase.addQueues:105 » Communication WFNAM00018: Failed to...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> JMSTopicManagementTestCase.before:89 » Communication WFNAM00018: Failed to con...
> PooledConnectionFactoryStatisticsTestCase.testStatistics:83 » Communication WF...
> RemoteNamingEjbTestCase.testDeploymentBinding:140 » Communication WFNAM00018: ...
> RemoteNamingEjbTestCase.testIt:99 » Communication WFNAM00018: Failed to connec...
> RemoteNamingTestCase.testNestedLookup:109 » Communication WFNAM00018: Failed t...
> RemoteNamingTestCase.testRemoteContextLookup:97 » Communication WFNAM00018: Fa...
> RemoteNamingTestCase.testRemoteLookup:85 » Communication WFNAM00018: Failed to...
> TransactionInflowTestCase.inflowTransactionCommit:138 » IllegalState EJBCLIENT...
> TransactionInflowTestCase.inflowTransactionRollback:156 » IllegalState EJBCLIE...
> Investigation needs to continue as it actually appears something running before these tests is the cause as running these tests in isolation does not cause a failure.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1149) Default CS implementation KeyStoreCredentialStore doesn't validate implementation properties
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/ELY-1149?page=com.atlassian.jira.plugin.s... ]
Chao Wang reassigned ELY-1149:
------------------------------
Assignee: Chao Wang (was: Darran Lofthouse)
> Default CS implementation KeyStoreCredentialStore doesn't validate implementation properties
> --------------------------------------------------------------------------------------------
>
> Key: ELY-1149
> URL: https://issues.jboss.org/browse/ELY-1149
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Chao Wang
> Priority: Critical
>
> I am able to pass any property into default KeyStoreCredentialStore implementation of credential store. I understand implementation-properties is general data holder for any implementation, so validation can't be made on subsystem level. But each delivered implementation knows which parameters are allowed for itself and thus should check it.
> {code}
> /subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,credential-reference={clear-text="pass123+"},implementation-properties={DOES_NOT_EXIST=anything},create=true,location=keystore.jks,modifiable=true)
> {code}
> It can prevent user from typo error. Also can help user to understand what is allowed for current implementation, as allowed properties can't be describe in model, because resource is for general usage.
> {code}
> "implementation-properties" => {
> "type" => OBJECT,
> "description" => "Map of credentials store implementation specific properties.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1153) Elytron: problem with Maven dependencies
by Josef Cacek (JIRA)
Josef Cacek created ELY-1153:
--------------------------------
Summary: Elytron: problem with Maven dependencies
Key: ELY-1153
URL: https://issues.jboss.org/browse/ELY-1153
Project: WildFly Elytron
Issue Type: Bug
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Critical
Majority of Elytron Maven dependencies have scope {{provided}}. It means they are not included when Elytron is used as a project dependency (e.g. together with EJB) and compilation fails.
We need either to make them {{compile}} scoped or provide an additional Elytron BOM package so users have a simple way for Elytron usage.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2755) Elytron Audit Logging: rotating-file-audit-log's event timestamp lacks information about seconds
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2755?page=com.atlassian.jira.plugi... ]
Jan Tymel updated WFCORE-2755:
------------------------------
Steps to Reproduce:
These steps could be followed in order to get a few records in Audit Log file:
# Follow steps _Configure Elytron (default profile)_ in [blog post|http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html] in order to change default configuration to Elytron
# (Optionally) Add user via add-user.sh (as Application User)
# Start server and deploy war attached to WFCORE-2625 (containing servlet secured with BASIC HTTP auth)
# (Optionally) see the format of _file-audit-log_ resource
## Access http://127.0.0.1:8080/protected/printRoles in a browser and fill in username and password
## Check _JBOSS_HOME/standalone/log/audit.log_
# Add _rotating-file-audit-log_ {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,relative-to=jboss.server.log.dir,suffix=y-M-d)}}
# Use added security-event-listener in ApplicationDomain {{/subsystem=elytron/security-domain=ApplicationDomain:write-attribute(name=security-event-listener,value=rotating-audit)}}
# Reload server {{:reload}}
# Access http://127.0.0.1:8080/protected/printRoles in a browser and fill in username and password
# Check _JBOSS_HOME/standalone/log/rotating-audit.log_
was:
These steps could be followed in order to get a few records in Audit Log file:
# Follow steps _Configure Elytron (default profile)_ in [blog post|http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html] in order to change default configuration to Elytron
# (Optionally) Add user via add-user.sh (as Application User)
# Start server and deploy attached war (containing servlet secured with BASIC HTTP auth)
# (Optionally) see the format of _file-audit-log_ resource
## Access http://127.0.0.1:8080/protected/printRoles in a browser and fill in username and password
## Check _JBOSS_HOME/standalone/log/audit.log_
# Add _rotating-file-audit-log_ {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,relative-to=jboss.server.log.dir,suffix=y-M-d)}}
# Use added security-event-listener in ApplicationDomain {{/subsystem=elytron/security-domain=ApplicationDomain:write-attribute(name=security-event-listener,value=rotating-audit)}}
# Reload server {{:reload}}
# Access http://127.0.0.1:8080/protected/printRoles in a browser and fill in username and password
# Check _JBOSS_HOME/standalone/log/rotating-audit.log_
> Elytron Audit Logging: rotating-file-audit-log's event timestamp lacks information about seconds
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2755
> URL: https://issues.jboss.org/browse/WFCORE-2755
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Yeray Borges
> Priority: Blocker
> Fix For: 3.0.0.Beta18
>
>
> The format of _rotating-file-audit-log's_ timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users.
> Furthermore the format of timestamp is inconsistent with the _file-audit-log_.
> _file-audit-log:_
> {code}
> 2017-05-03 13:44:07
> {code}
> _rotating-file-audit-log:_
> {code}
> 5/3/17 1:44 PM
> {code}
> Suggestions for improvement:
> Use the same format of timestamp in_rotating-file-audit-log_ as is already used in _file-audit-log_.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ondrej Lukas commented on WFCORE-2746:
--------------------------------------
Usage of {{(a)FixMethodOrder(MethodSorters.NAME_ASCENDING)}} is based on lexicographic order which seems very unwieldy and not so intuitive as Arquillian InSequence, but it would probably work. However I am talking here probably only about unit of test cases so this approach is applicable (I just tried to avoid to eventual rewriting test to something less intuitive). Once I will migrate some test case from our internal TS which will use mentioned above scenario I try to use {{(a)FixMethodOrder(MethodSorters.NAME_ASCENDING)}}. Thanks!
Another two suggestions are not applicable for following reasons:
# Making separate test still does not reduce number of server reloads since every separate test case will need it.
# As I understand your point 2. correctly it means that one test method would test more different scenarios. In case some of private test method will fail then another private test method will not be executed. It can hide another issue.
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2]
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8766) EJB@HTTP client fails with WFNAM00026: No provider for found for URI: ejb
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8766?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-10890 to WFLY-8766:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8766 (was: JBEAP-10890)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Naming
(was: EJB)
(was: Naming)
Affects Version/s: (was: 7.1.0.DR18)
> EJB@HTTP client fails with WFNAM00026: No provider for found for URI: ejb
> -------------------------------------------------------------------------
>
> Key: WFLY-8766
> URL: https://issues.jboss.org/browse/WFLY-8766
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Naming
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> This is a regression between EAP 7.1.0.DR17 and DR18.
> When using HTTP transport, I started getting this exception:
> {noformat}
> Exception in thread "main" javax.naming.OperationNotSupportedException: WFNAM00026: No provider for found for URI: ejb
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:490)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:149)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.Client.main(Client.java:37)
> {noformat}
> It seems that upstream tests for HTTP transport are passing, so this must somehow depend on how the dependencies are setup...?
> Reproducer at https://github.com/jmartisk/mock-artifacts/tree/17fca5083d68c3b77d277196f...
> when you downgrade the EJB client BOM (in {{client/pom.xml}}) from {{7.1.0.Beta1-redhat-3}} to {{7.1.0.Beta1-redhat-2}} (DR17), it will start working.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6642) Automatic creation of transport config in IOR settings
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6642?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-6642.
--------------------------------
Resolution: Done
> Automatic creation of transport config in IOR settings
> ------------------------------------------------------
>
> Key: WFLY-6642
> URL: https://issues.jboss.org/browse/WFLY-6642
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Minor
>
> I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. To configure required ssl connections server-requires-ssl field in security tag is introduced. If this field is set to true, then all SSL transport fields will be set as required, thus we will achieve factual transport description in ior-settings and provide user with simple SSL configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8764) The WildFly pom.xml is overriding the version of WildFly discovery client
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8764?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-8764:
-----------------------------------
Perhaps wildfly-core should have a BOM that can be imported into wildfly? I think right now core is just a plain dependency isn't it?
> The WildFly pom.xml is overriding the version of WildFly discovery client
> -------------------------------------------------------------------------
>
> Key: WFLY-8764
> URL: https://issues.jboss.org/browse/WFLY-8764
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> This was introduce under the following commit to address transitive dependency issues: -
> commit b49586d5c90e673aa1abceef3c047257da6cb19e
> Author: Tomaz Cerar <tomaz.cerar(a)gmail.com>
> Date: Mon Apr 24 17:13:16 2017 +0200
> JBEAP-10175 JBEAP-10174 Unmanaged transitive dependencies in EJB client BOM dependency tree
> However the version override means a version upgrade in core does not get applied to EAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months