[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka reopened WFLY-10837:
------------------------------------
Hi Tomek,
I'm sorry but I haven't observed any change in the behaviour. If you don't mind I'm reopening the issue. If I can see your PR for the issue contains changes in the JacORB subsystem. I'm sorry for not describing it in better way but the issue is for the {{iiop-openjdk}} subsystem. What happens is that the configuration if stated as
{code}
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.1">
<initializers security="identity" transactions="spec"/>
<security server-requires-ssl="false" client-requires-ssl="false"/>
</subsystem>
{code}
does not work. Notice the only change from the default subsystem configuration is that I removed the {{<orb socket-binding="iiop"/>}} element.
The issue is two sided.
* First the {{jboss-cli}} does not require the attribute needs to be specified. The command {{/subsystem=iiop-openjdk:undefine-attribute(name=socket-binding)}} is ok with me to remove the attribute but {{reload}} then blame me.
* Second the attribute was not necessary to be defined in prior versions of WildFly. I was fine when my configuration does not specify it and the container was starting smoothly. I'm not sure if it could be some backward compatibility issue. Which could be as [~pkremens] stated in the comment above.
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1680:
------------------------------
Description:
{code}
[ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
{code}
If I switch order of certificates in chain, then test passes.
{code}
diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
index d8095867a..cda635beb 100644
--- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
+++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
@@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
Assert.assertNotNull(chain);
Assert.assertEquals(2, chain.length);
- Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
- Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
+ Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
+ Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
}
{code}
-For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
It takes long (5min) for debugger to attach to code.
was:
{code}
[ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
{code}
If I switch order of certificates in chain, then test passes.
{code}
diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
index d8095867a..cda635beb 100644
--- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
+++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
@@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
Assert.assertNotNull(chain);
Assert.assertEquals(2, chain.length);
- Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
- Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
+ Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
+ Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
}
{code}
For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10909) ConcurrentModificationException at ActivationSecurityUtil
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10909?page=com.atlassian.jira.plugin... ]
Martin Simka closed WFLY-10909.
-------------------------------
Resolution: Duplicate Issue
closing as duplicate, fixed by WFLY-10986
> ConcurrentModificationException at ActivationSecurityUtil
> ---------------------------------------------------------
>
> Key: WFLY-10909
> URL: https://issues.jboss.org/browse/WFLY-10909
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Richard Opalka
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 15.0.0.Alpha1
>
>
> org.jboss.as.test.smoke.deployment.rar.tests.multiactivation.MultipleActivationTestCase.testConfiguration: java.lang.AssertionError: CF1 not found
> at org.jboss.as.test.smoke.deployment.rar.tests.multiactivation.MultipleActivationTestCase.testConfiguration(MultipleActivationTestCase.java:126)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:246)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ------- Stdout: -------
> [31m08:51:51,219 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.resourceadapters.ra."archive.rar".Pool2: org.jboss.msc.service.StartException in service jboss.resourceadapters.ra."archive.rar".Pool2: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> at java.util.ArrayList$Itr.next(ArrayList.java:859)
> at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
> at org.jboss.as.connector.metadata.api.resourceadapter.ActivationSecurityUtil.isLegacySecurityRequired(ActivationSecurityUtil.java:41)
> at org.jboss.as.connector.subsystems.resourceadapters.ConnectionDefinitionService.start(ConnectionDefinitionService.java:68)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFLY-10339:
------------------------------------------
Isn't the use of capabilities be sufficient to fix this without creating new resources in the model ?
Those capability requirements are bound to attributes thus provisioning should be able to determinate the required features in the same way as using addresses.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JGRP-2294) ForkProtocolStack ignores UnknownForkHandler for message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2294?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2294:
--------------------------------
The same goes for missing fork-channel stacks; added unit tests {{testUnknownForkStack}} and {{testUnknownForkChannel}} to {{ForkChannelTest}}.
> ForkProtocolStack ignores UnknownForkHandler for message batches
> ----------------------------------------------------------------
>
> Key: JGRP-2294
> URL: https://issues.jboss.org/browse/JGRP-2294
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.13
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 4.0.15
>
>
> {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch:
> {code:java}
> log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id);
> {code}
> -I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.-
> I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months