February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (REMJMX-136) RemotingConnector converts the AuthenticationContext to an anonymous context

by James Perkins (JIRA)

James Perkins created REMJMX-136: ------------------------------------ Summary: RemotingConnector converts the AuthenticationContext to an anonymous context Key: REMJMX-136 URL: https://issues.jboss.org/browse/REMJMX-136 Project: Remoting JMX Issue Type: Bug Reporter: James Perkins Assignee: James Perkins If no {{CallbackHandler}} or no JMX credentials are defined the {{org.jboss.remotingjmx.RemotingConnector}} the {{AuthenticationContext}} is converted to an anonymous context. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-135) Release Remoting JMX 3.0.0.Beta3

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-135: --------------------------------------- Summary: Release Remoting JMX 3.0.0.Beta3 Key: REMJMX-135 URL: https://issues.jboss.org/browse/REMJMX-135 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta3 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2270) Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2270: ------------------------------------- Description: CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place. There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example: 1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.) 2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config. I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior. was:CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place. > Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2270 > URL: https://issues.jboss.org/browse/WFCORE-2270 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place. > There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example: > 1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.) > 2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config. > I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2270) Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2270: ------------------------------------- Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2017-February/005758.html > Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2270 > URL: https://issues.jboss.org/browse/WFCORE-2270 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-930) Support appending a CallbackHandler to the CredentialSources

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-930: ------------------------------------ Summary: Support appending a CallbackHandler to the CredentialSources Key: ELY-930 URL: https://issues.jboss.org/browse/ELY-930 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta23 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly instead of String-based properties

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned JGRP-2063: ------------------------------------ Assignee: Radoslav Husar (was: Bela Ban) > JDBC_PING: allow supplying dataSource object directly instead of String-based properties > ---------------------------------------------------------------------------------------- > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 4.1 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly instead of String properties

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated JGRP-2063: --------------------------------- Summary: JDBC_PING: allow supplying dataSource object directly instead of String properties (was: JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook)) > JDBC_PING: allow supplying dataSource object directly instead of String properties > ---------------------------------------------------------------------------------- > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Bela Ban > Fix For: 4.1 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly instead of String-based properties

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated JGRP-2063: --------------------------------- Summary: JDBC_PING: allow supplying dataSource object directly instead of String-based properties (was: JDBC_PING: allow supplying dataSource object directly instead of String properties) > JDBC_PING: allow supplying dataSource object directly instead of String-based properties > ---------------------------------------------------------------------------------------- > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Bela Ban > Fix For: 4.1 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2272) Ctrl-C sent on command taking long time doesn't cancel the current operation

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2272: -------------------------------------------- Summary: Ctrl-C sent on command taking long time doesn't cancel the current operation Key: WFCORE-2272 URL: https://issues.jboss.org/browse/WFCORE-2272 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise For example, during a deploy that takes time, a user types Ctrl-C, this does unlock the prompt and the command "seems" to have been interrupted. Actually the command thread has been interrupted but not the remoting task that is in progress. So although the user can think its command has been aborted, it is silently processing in background. When interruption occurs in a command thread, current remoting task should be canceled. This is what we are doing today when a timeout is set on a command. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1428) DMN Decision Table not resolving variables in context

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-1428: ------------------------------------- Summary: DMN Decision Table not resolving variables in context Key: DROOLS-1428 URL: https://issues.jboss.org/browse/DROOLS-1428 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta6 Reporter: Edson Tirelli Assignee: Edson Tirelli Priority: Critical Fix For: 7.0.0.CR1, 7.0.0.Final Attachments: DT_in_context.dmn, image002.png While doing some test, we might have discovered an issue with inner decision table reusing previous context entry. This is the context: !image002.png|thumbnail! When I run this, I get no result for the decision. I would expect “red”. I’ve also attached the xml file. Let me know if anything on our serialization is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017