[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7153 at 1/20/17 4:53 AM:
-----------------------------------------------------------
Resolved in Beta1 of elytron-subsystem. Need to update Fix version when will be upgraded in wildfly.
was (Author: honza889):
Resolved in Beta1 of elytron-subsystem. Need to update Fix version when will be in wildfly.
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7483) Credential store has configuration in "uri" attribute.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7483?page=com.atlassian.jira.plugin.... ]
Hynek Švábek commented on WFLY-7483:
------------------------------------
Hi [~brian.stansberry], are you comfortable with custom alternative to standard generic OBJECT introduced in uri parameter?
> Credential store has configuration in "uri" attribute.
> ------------------------------------------------------
>
> Key: WFLY-7483
> URL: https://issues.jboss.org/browse/WFLY-7483
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo)
> In my opinion the main intention for it is to have general solution for custom implementation.
> *Current state*
> {code}
> /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true")
> {code}
> *Suggestion for improvement:*
> Better solution to achieve this could be use a map.
> e.g. some like that:
> {code}
> /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file})
> {code}
> Now credential store name is in URI too, it can be get from resource name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2215) Unable to force replacement of deployment in domain with deploy <path> --force high level command
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2215?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-2215:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Unable to force replacement of deployment in domain with deploy <path> --force high level command
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2215
> URL: https://issues.jboss.org/browse/WFCORE-2215
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> The following failure is produced when trying to force replacement of deployments in JBoss EAP 7.1.0.DR10 with high level command:
> {code}[domain@localhost:9990 /] deploy ~/testing/eap/7.0.0/jboss-eap-7.0.0.GA-quickstarts/helloworld/target/jboss-helloworld.war --server-groups=main-server-group
> [domain@localhost:9990 /] deploy ~/testing/eap/7.0.0/jboss-eap-7.0.0.GA-quickstarts/helloworld/target/jboss-helloworld.war --force
> {"host-failure-descriptions" => {"hc1" => "WFLYDC0041: A slave domain controller cannot accept deployment content uploads"}}
> {code}
> This operation is referenced in community documentation: [Application deployment|https://docs.jboss.org/author/display/WFLY/Application+deployment]
> This operation works with JBoss EAP 7.0 and 6.4.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7921) JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-7921?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-7921:
---------------------------------
Steps to Reproduce:
Can be reproduced locally:
1. extract two instances of EAP 7.1.0.DR10, modify standalone-ha.xml (see Description)
2. add a clustered deployment
3. start the first server with standalone-ha configuration, and after few seconds start the second one
4. one of the two servers usually logs the NPE
> JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7921
> URL: https://issues.jboss.org/browse/WFLY-7921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Scenario: failover clustering test with enabled "AUTH" and "ASYM_ENCRYPT" protocols + JGroups default stack set to *TCP*. This issue doesn't occur when using UDP stack.
> {code:xml|title=TCP stack configuration}
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">false</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="AUTH">
> <property name="auth_class">org.jgroups.auth.MD5Token</property>
> <property name="auth_value">jdgservercluster</property>
> <property name="token_hash">MD5</property>
> </protocol>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> {code}
> During servers startup, after receiving a new cluster view, one of the servers usually logs this error message:
> {code}
> 08:35:36,707 ERROR [org.jgroups.blocks.RequestCorrelator] (thread-1,ee,node2) JGRP000225: failed unmarshalling buffer into return value: java.lang.NullPointerException
> at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
> at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
> at org.jboss.as.clustering.infinispan.ChannelFactoryTransport$1.objectFromBuffer(ChannelFactoryTransport.java:81)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:419)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
> at org.jgroups.protocols.AUTH.up(AUTH.java:150)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.EncryptBase.handleEncryptedMessage(EncryptBase.java:242)
> at org.jgroups.protocols.EncryptBase.handleUpMessage(EncryptBase.java:227)
> at org.jgroups.protocols.EncryptBase.up(EncryptBase.java:150)
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:116)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1873)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$547/364315896.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7921) JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-7921:
------------------------------------
Summary: JGRP000225: failed unmarshalling buffer into return value: NPE (ASYM_ENCRYPT + TCP, during server startup)
Key: WFLY-7921
URL: https://issues.jboss.org/browse/WFLY-7921
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Scenario: failover clustering test with enabled "AUTH" and "ASYM_ENCRYPT" protocols + JGrpous default stack set to *TCP*. This issue doesn't occur when using UDP stack.
{code:xml|title=TCP stack configuration}
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="ASYM_ENCRYPT">
<property name="encrypt_entire_message">false</property>
<property name="sym_keylength">128</property>
<property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
<property name="asym_keylength">512</property>
<property name="asym_algorithm">RSA</property>
</protocol>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="auth_value">jdgservercluster</property>
<property name="token_hash">MD5</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
{code}
During servers startup, after receiving a new cluster view, one of the servers usually logs this error message:
{code}
08:35:36,707 ERROR [org.jgroups.blocks.RequestCorrelator] (thread-1,ee,node2) JGRP000225: failed unmarshalling buffer into return value: java.lang.NullPointerException
at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at org.jboss.as.clustering.infinispan.ChannelFactoryTransport$1.objectFromBuffer(ChannelFactoryTransport.java:81)
at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:419)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
at org.jgroups.JChannel.up(JChannel.java:738)
at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
at org.jgroups.stack.Protocol.up(Protocol.java:380)
at org.jgroups.protocols.FORK.up(FORK.java:114)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1037)
at org.jgroups.protocols.AUTH.up(AUTH.java:150)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
at org.jgroups.protocols.EncryptBase.handleEncryptedMessage(EncryptBase.java:242)
at org.jgroups.protocols.EncryptBase.handleUpMessage(EncryptBase.java:227)
at org.jgroups.protocols.EncryptBase.up(EncryptBase.java:150)
at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:116)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD.up(FD.java:260)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
at org.jgroups.protocols.Discovery.up(Discovery.java:296)
at org.jgroups.protocols.MPING.up(MPING.java:178)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1873)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$547/364315896.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months