March 2016 - jboss-jira - Jboss List Archives

[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)

[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ] Tom Fonteyne commented on WFCORE-1417: -------------------------------------- not sure what the correct solution would be.... either for every applicable connect: public void connect() { checkAlreadyConnected(); try { ctx = CommandContextFactory.getInstance().newCommandContext(); ctx.connectController(); } catch (CliInitializationException e) { ctx = null; throw new IllegalStateException("Unable to initialize command context.", e); } catch (CommandLineException e) { ctx = null; throw new IllegalStateException("Unable to connect to controller.", e); } } or: public void terminateSession() { try { ctx.terminateSession(); } finally { ctx = null; } } and for every applicable connect: public void connect() { checkAlreadyConnected(); try { ctx = CommandContextFactory.getInstance().newCommandContext(); ctx.connectController(); } catch (CliInitializationException e) { terminateSession(); throw new IllegalStateException("Unable to initialize command context.", e); } catch (CommandLineException e) { terminateSession(); throw new IllegalStateException("Unable to connect to controller.", e); } } > 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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6257: -------------------------------- Description: Narayana has added a check of the action status service to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. (was: Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly.) > Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally > ------------------------------------------------------------------------------------------------- > > Key: WFLY-6257 > URL: https://issues.jboss.org/browse/WFLY-6257 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 11.0.0.Alpha1 > > > Narayana has added a check of the action status service to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6257: -------------------------------- Summary: Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally (was: Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager) > Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally > ------------------------------------------------------------------------------------------------- > > Key: WFLY-6257 > URL: https://issues.jboss.org/browse/WFLY-6257 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 11.0.0.Alpha1 > > > Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-430) Add HostnameVerifier implementation

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-430: ------------------------------------ Summary: Add HostnameVerifier implementation Key: ELY-430 URL: https://issues.jboss.org/browse/ELY-430 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta5 We should at the very least have a sensible default implementation checking the certificate against the host name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 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: ----------------------------------- 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)

8 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)

8 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)

8 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)

8 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)

8 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)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016