July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8636) Fix naming rebind resource-description

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-8636: ------------------------------ Description: The naming :rebind operation describes the "external-context" value as allowed for its binding-type attribute but the code will fail if that's the case. (was: The naming :rebind operation describes the "external-context" value as allowed for its binding-type attribute but the code will fails if that's the case.) > Fix naming rebind resource-description > -------------------------------------- > > Key: WFLY-8636 > URL: https://issues.jboss.org/browse/WFLY-8636 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 11.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > The naming :rebind operation describes the "external-context" value as allowed for its binding-type attribute but the code will fail if that's the case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8636) Fix naming rebind resource-description

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil reassigned WFLY-8636: --------------------------------- Assignee: Jeff Mesnil > Fix naming rebind resource-description > -------------------------------------- > > Key: WFLY-8636 > URL: https://issues.jboss.org/browse/WFLY-8636 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 11.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > The naming :rebind operation describes the "external-context" value as allowed for its binding-type attribute but the code will fails if that's the case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9111) Some tests from manualmode is unable to start with node0 and node1 properties

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-9111?page=com.atlassian.jira.plugin.... ] Richard Janík moved JBEAP-12238 to WFLY-9111: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9111 (was: JBEAP-12238) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA Test Suite (was: JCA) (was: Test Suite) Affects Version/s: (was: 7.1.0.ER2) > Some tests from manualmode is unable to start with node0 and node1 properties > ----------------------------------------------------------------------------- > > Key: WFLY-9111 > URL: https://issues.jboss.org/browse/WFLY-9111 > Project: WildFly > Issue Type: Bug > Components: JCA, Test Suite > Reporter: Richard Janík > Assignee: Richard Janík > > *Description of problem:* > Some tests from manualmode is unable to start with node0 and node1 properties. > It's caused by [these new containers in arquillian.xml|https://github.com/jbossas/jboss-eap7/pull/1935/files#diff...] > These tests are affected by this issue: > {noformat} > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase > org.jboss.as.test.manualmode.ejb.client.outbound.connection.security.ElytronRemoteOutboundConnectionTestCase > org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase > org.jboss.as.test.manualmode.jca.connectionlistener.ConnectionListenerTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmAlwaysTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmNeverTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmWatermarkTestCase > org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase > org.jboss.as.test.manualmode.messaging.ha.ReplicatedFailoverTestCase > org.jboss.as.test.manualmode.messaging.ha.SharedStoreFailoverTestCase > org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase > org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase > org.jboss.as.test.manualmode.security.SecuredDataSourceTestCase > org.jboss.as.test.manualmode.security.VaultSystemPropertyOnServerStartTestCase > org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > org.jboss.as.test.manualmode.web.ssl.CertificateRolesLoginModuleTestCase > org.jboss.as.test.manualmode.web.ssl.DatabaseCertLoginModuleTestCase > org.jboss.as.test.manualmode.web.ssl.HTTPSWebConnectorTestCase > org.jboss.as.test.manualmode.weld.extension.BeforeShutdownJNDILookupTestCase > org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase > org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase > {noformat} > *How reproducible:* > Always > *Steps to Reproduce:* > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Djboss.dist=/home/mkopecky/playground/eap/7.1.0.ER2.2/jboss-eap-7.1 -DtestLogToFile=false -Dts.noSmoke -Dts.manualmode -Dtest=RemoteOutboundConnectionReconnectTestCase > *StackTrace:* > {noformat} > Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [60] s > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:161) > ... 73 more > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3078) Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3078?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-3078: -------------------------------------- Description: There is an issue at boot for CredentialStore integration in SyslogHandler : this is due to the fact that AuditLogLoggerAddHandler will change the AuditLogger status in the RUNTIME phase that will log an event while the service may not be UP (since the fake service is at the handler level). https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... Sample of such a failure: https://ci.wildfly.org/viewLog.html?buildId=67476&buildTypeId=WildFlyCore... was: There is an issue at boot for CredentialStore integration in SyslogHandler : this is due to the fact that AuditLogLoggerAddHandler will change the AuditLogger status in the RUNTIME phase that will log an event while the service may not be UP (since the fake service is at the handler level). https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... > Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-3078 > URL: https://issues.jboss.org/browse/WFCORE-3078 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta28 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > There is an issue at boot for CredentialStore integration in SyslogHandler : this is due to the fact that AuditLogLoggerAddHandler will change the AuditLogger status in the RUNTIME phase that will log an event while the service may not be UP (since the fake service is at the handler level). > https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... > Sample of such a failure: https://ci.wildfly.org/viewLog.html?buildId=67476&buildTypeId=WildFlyCore... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3078) Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3078?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-3078: -------------------------------------- Priority: Blocker (was: Major) > Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-3078 > URL: https://issues.jboss.org/browse/WFCORE-3078 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta28 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > > There is an issue at boot for CredentialStore integration in SyslogHandler : this is due to the fact that AuditLogLoggerAddHandler will change the AuditLogger status in the RUNTIME phase that will log an event while the service may not be UP (since the fake service is at the handler level). > https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... > Sample of such a failure: https://ci.wildfly.org/viewLog.html?buildId=67476&buildTypeId=WildFlyCore... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3078) Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-3078: ----------------------------------------- Summary: Intermittent failure in AuditLogBootingSyslogTest shows that WFCORE-2923 doesn't cover every case Key: WFCORE-3078 URL: https://issues.jboss.org/browse/WFCORE-3078 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta28 Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet There is an issue at boot for CredentialStore integration in SyslogHandler : this is due to the fact that AuditLogLoggerAddHandler will change the AuditLogger status in the RUNTIME phase that will log an event while the service may not be UP (since the fake service is at the handler level). https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-140) JBMM 7.0 container builds for openjdk CVE fix

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-140?page=com.atlassian.jira.pl... ] Hayk Hovsepyan resolved HAWKULARQE-140. --------------------------------------- Resolution: Done All subtasks are done > JBMM 7.0 container builds for openjdk CVE fix > --------------------------------------------- > > Key: HAWKULARQE-140 > URL: https://issues.jboss.org/browse/HAWKULARQE-140 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Minor > > Smoke test (according to PaulG) > Middleware manager container buld: > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=574497 > Image URL: > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-mm-7-tech-preview/middleware-manager:7.0.0-21 > Cassandra container build: > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=574490 > Image URL: > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-mm-7-tech-preview/middleware-manager-datastore:7.0.0-9 > RCM ticket: https://projects.engineering.redhat.com/browse/RCM-18682 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8492) Cannot cleanly shutdown server disconnected inbound/outbound connections

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-8492?page=com.atlassian.jira.plugin.... ] Chao Wang reopened WFLY-8492: ----------------------------- > Cannot cleanly shutdown server disconnected inbound/outbound connections > ------------------------------------------------------------------------ > > Key: WFLY-8492 > URL: https://issues.jboss.org/browse/WFLY-8492 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > Customer impact: Server will not be possible to cleanly shutdown and must be killed. No simple management operation command which EAP provides can be used. Similar issue was reported by customers/users in the past and had to be solved by support. > Test Scenario: > * Start server 1 with queues InQueue and OutQueue > * Start server 2 with MDB consuming messages from InQueue and for each message sending 1 new message to OutQueue in XA transaction > * Send messages to InQueue to server 1 > * When MDB is processing messages then cleanly shutdown server 1 > * Cleanly shutdown server 2 with MDB > Result: > Server 2 does not shutdown. > Expected Result: > Server 2 with MDB will shutdown fast ( < 1 min). > Investigation: > Thread dump (attached) on server 2 shows types of waiting threads: > {code} > "Thread-6 (ActiveMQ-client-global-threads-304296137)" #193 daemon prio=5 os_prio=0 tid=0x00007fc63c6d4000 nid=0x924 waiting on condition [0x00007fc5d6e0c000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fda5f5f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:356) > - locked <0x00000000fda5f618> (a java.lang.Object) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:383) > at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1173) > at org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112) > at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674) > - locked <0x00000000fdb54128> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1298) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134) > at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:99) > at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:73) > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:69) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60) > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135) > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) > at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueToContaniner1$$$endpoint1.afterDelivery(Unknown Source) > at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:314) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) > 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) > {code} > and: > {code} > "Thread-21 (ActiveMQ-client-global-threads-304296137)" #196 daemon prio=5 os_prio=0 tid=0x00007fc62c040800 nid=0x928 waiting on condition [0x00007fc5d6a08000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fd4bc8a8> (a java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:136) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:819) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:744) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165) > at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207) > at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996) > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) > 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) > {code} > Those threads should be notified of server shutdown and "gracefully" stop do what they're doing. In case 1st thread: > {{at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250)}} > there is problem in code: > {code} > failoverCondition.await(); > {code} > This should be silently interrupted when component is stopping. > 2nd thread has problem that while() cycle does not finish when component is stopping: > {code} > while (clientProtocolManager.isAlive()) { > ... > try { > if (clientProtocolManager.waitOnLatch(interval)) { > ... > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas closed ELY-477. ---------------------------- Resolution: Out of Date Thanks [~ppalaga]. Closing this issue as Out of Date. > XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK > ---------------------------------------------------------- > > Key: ELY-477 > URL: https://issues.jboss.org/browse/ELY-477 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.1.0.Beta4 > Reporter: Ondrej Lukas > Fix For: 1.2.0.Beta1 > > > Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with: > {code} > expected:<-1> but was:<7> > and stacktrace: > java.lang.AssertionError: expected:<-1> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96) > ... > {code} > It is caused by undefined line number of XML parsing failure for IBM JDK. > Stacktrace of checked XMLStreamException for IBM JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} > Stacktrace of checked XMLStreamException for Oracle JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml:7:39: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9110) jboss-iiop-client 1.0.1.Final

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9110?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-12236 to WFLY-9110: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9110 (was: JBEAP-12236) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > jboss-iiop-client 1.0.1.Final > ----------------------------- > > Key: WFLY-9110 > URL: https://issues.jboss.org/browse/WFLY-9110 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Update to 1.0.1.Final so license information is included -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2017