March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6304) Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6304?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-6304: ----------------------------------- Labels: deprecated (was: ) > Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6304 > URL: https://issues.jboss.org/browse/WFLY-6304 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Minor > Labels: deprecated > > RemotingLoginModule propagates javax.security.cert.X509Certificate but should use the newer API java.security.cert.X509Certificate. > David proposed the following: > The problem is at org.jboss.as.security.remoting.RemotingLoginModule line 126: session.getPeerCertificateChain() is called where session.getPeerCertificates() should be. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6304) Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6304?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-6304: ----------------------------------- Priority: Minor (was: Major) > Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6304 > URL: https://issues.jboss.org/browse/WFLY-6304 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Minor > > RemotingLoginModule propagates javax.security.cert.X509Certificate but should use the newer API java.security.cert.X509Certificate. > David proposed the following: > The problem is at org.jboss.as.security.remoting.RemotingLoginModule line 126: session.getPeerCertificateChain() is called where session.getPeerCertificates() should be. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento commented on JGRP-2022: -------------------------------------------------- Proper XSD validators will complain in any IDE with schema validation turned on (which is the case for Eclipse by default). Command-completion does not work at all in this case. An invalid schema is equivalent to Java code that will not compile. It is not just aesthetic. Please note that older jgroups.xsd versions worked fine. The problem seems to have arised when relay.xsd and fork-stacks.xsd were added to the mix. I'm no XSD expert either, but the error messages point to some kind of incorrect namespace handling. > XSD schemas do not properly validate > ------------------------------------ > > Key: JGRP-2022 > URL: https://issues.jboss.org/browse/JGRP-2022 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > Attachments: fork-stacks.xsd, jgroups.xsd, relay.xsd > > > Affected resources: > - jgroups.xsd > - relay.xsd > - fork-stacks.xsd > Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2022: -------------------------------- What's the diff? Admitting that I'm no XML/XSD expert, the schema works when command-completing configurations. What else do you want? Or, in other words, what is it that you cannot do with the current schema? > XSD schemas do not properly validate > ------------------------------------ > > Key: JGRP-2022 > URL: https://issues.jboss.org/browse/JGRP-2022 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > Attachments: fork-stacks.xsd, jgroups.xsd, relay.xsd > > > Affected resources: > - jgroups.xsd > - relay.xsd > - fork-stacks.xsd > Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6304) Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead

by Ivo Studensky (JIRA)

Ivo Studensky created WFLY-6304: ----------------------------------- Summary: Remoting login module's certificate propagation uses the old certificate API but should be using the new API instead Key: WFLY-6304 URL: https://issues.jboss.org/browse/WFLY-6304 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 10.0.0.Final Reporter: Ivo Studensky Assignee: Ivo Studensky RemotingLoginModule propagates javax.security.cert.X509Certificate but should use the newer API java.security.cert.X509Certificate. David proposed the following: The problem is at org.jboss.as.security.remoting.RemotingLoginModule line 126: session.getPeerCertificateChain() is called where session.getPeerCertificates() should be. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly

by Tom Fonteyne (JIRA)

Tom Fonteyne created WFCORE-1417: ------------------------------------ Summary: org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly Key: WFCORE-1417 URL: https://issues.jboss.org/browse/WFCORE-1417 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.1.0.CR1 Reporter: Tom Fonteyne Assignee: Tom Fonteyne Priority: Minor cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java public void connect() { checkAlreadyConnected(); try { ctx = CommandContextFactory.getInstance().newCommandContext(); ctx.connectController(); } catch (CliInitializationException e) { throw new IllegalStateException("Unable to initialize command context.", e); } catch (CommandLineException e) { throw new IllegalStateException("Unable to connect to controller.", e); } } also applicable to the other connects of course. If the connection fails in the connect method, a subsequent connect will hit: private void checkAlreadyConnected() { if (ctx != null) throw new IllegalStateException("Already connected to server."); } and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed. ergo, upon failure in connect, the ctx should be reset to avoid this -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento commented on JGRP-2022: -------------------------------------------------- You're thinking of XML validation, not XSD (schema) validation. The resources are valid XML, however they are invalid XSD. Create a new project in Eclipse (any kind will do), and make sure you have XML Schema Validator turned on (Preferences -> Validation -> check that "XML Schema Validator" is enabled). Copy the three attached files into the project, and you will get the following errors as soon as validation completes: src-resolve.4.1: Error resolving component 'RelayConfigurationType'. It was detected that 'RelayConfigurationType' has no namespace, but components with no target namespace are not referenceable from schema document 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/relay.xsd'. If 'RelayConfigurationType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'RelayConfigurationType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/relay.xsd'. src-resolve.4.1: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/jgroups.xsd'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/jgroups.xsd'. src-resolve.4.1: Error resolving component 'ForkStacksType'. It was detected that 'ForkStacksType' has no namespace, but components with no target namespace are not referenceable from schema document 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/fork-stacks.xsd'. If 'ForkStacksType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ForkStacksType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'file:///Users/Manuel/Development/workspace-mars/Test/WebContent/fork-stacks.xsd'. > XSD schemas do not properly validate > ------------------------------------ > > Key: JGRP-2022 > URL: https://issues.jboss.org/browse/JGRP-2022 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > Attachments: fork-stacks.xsd, jgroups.xsd, relay.xsd > > > Affected resources: > - jgroups.xsd > - relay.xsd > - fork-stacks.xsd > Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento updated JGRP-2022: --------------------------------------------- Attachment: relay.xsd jgroups.xsd fork-stacks.xsd > XSD schemas do not properly validate > ------------------------------------ > > Key: JGRP-2022 > URL: https://issues.jboss.org/browse/JGRP-2022 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > Attachments: fork-stacks.xsd, jgroups.xsd, relay.xsd > > > Affected resources: > - jgroups.xsd > - relay.xsd > - fork-stacks.xsd > Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1076) Initial opening of kie navigator server properties shows error dialog

by Tomas David (JIRA)

Tomas David created DROOLS-1076: ----------------------------------- Summary: Initial opening of kie navigator server properties shows error dialog Key: DROOLS-1076 URL: https://issues.jboss.org/browse/DROOLS-1076 Project: Drools Issue Type: Bug Components: eclipse plugin Environment: JBoss Developer Studio 9.1.0.Beta2 Drools plugin 6.4.0.201601201107 Reporter: Tomas David Assignee: Robert (Bob) Brodt Priority: Minor Attachments: kn_server_prop_error.png If you open server properties of the the kie navigator tool, you will get error dialog "The currently displayed page contains invalid values". This happens only when you create new server in server view and then you open server properties in kie navigator view. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6303) RemotingLoginModuleTestCase fails with the latest IBM jdk 20160108_01(SR2 FP10)

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-6303?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-3623 to WFLY-6303: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6303 (was: JBEAP-3623) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER6) > RemotingLoginModuleTestCase fails with the latest IBM jdk 20160108_01(SR2 FP10) > ------------------------------------------------------------------------------- > > Key: WFLY-6303 > URL: https://issues.jboss.org/browse/WFLY-6303 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Final > Environment: Java(TM) SE Runtime Environment (build pxa6480sr2fp10-20160108_01(SR2 FP10)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160106_284759 (JIT enabled, AOT enabled) > J9VM - R28_20160106_1341_B284759 > JIT - tr.r14.java_20151209_107110.02 > GC - R28_20160106_1341_B284759_CMPRSS > J9CL - 20160106_284759) > JCL - 20151231_01 based on Oracle jdk8u71-b15 > Reporter: Martin Choma > Assignee: Martin Choma > Priority: Minor > > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase starts failing with the latest IBM jdk. > {noformat} > ./integration-tests.sh clean test -Dmaven.repo.local=$REPO -Dts.noSmoke -Dts.basic -Dtest=RemotingLoginModuleTestCase > Running org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase > Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.546 sec <<< FAILURE! - in org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase > testNotAuthorizedClient(org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase) Time elapsed: 0.031 sec <<< ERROR! > javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [remote://127.0.0.1:14447 (javax.net.ssl.SSLException: Received fatal alert: handshake_failure)] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) > at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) > at javax.naming.InitialContext.lookup(InitialContext.java:428) > at org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient(RemotingLoginModuleTestCase.java:179) > > testAuthorizedClient(org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase) Time elapsed: 0.026 sec <<< ERROR! > javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [remote://127.0.0.1:14447 (javax.net.ssl.SSLException: Received fatal alert: handshake_failure)] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) > at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) > at javax.naming.InitialContext.lookup(InitialContext.java:428) > at org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient(RemotingLoginModuleTestCase.java:165) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016