[JBoss JIRA] (ELY-1898) ServiceFactory<Credential> used in API is too strict
by Tristan Tarrant (Jira)
Tristan Tarrant created ELY-1898:
------------------------------------
Summary: ServiceFactory<Credential> used in API is too strict
Key: ELY-1898
URL: https://issues.jboss.org/browse/ELY-1898
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Affects Versions: 1.11.0.CR1
Reporter: Tristan Tarrant
In several places in the API, `SecurityFactory<Credential>` is used, but its …
[View More]bound is too strict, disallowing passing in specific instances, e.g. `SecurityFactory<GSSKerberosCredential>`.
These should all be replaced with `SecurityFactory<? extends Credential>`.
An example of code that doesn't work:
{code:java}
SecurityFactory<GSSKerberosCredential> ksf = ...;
CredentialSource cs = CredentialSource.fromSecurityFactory(ksf); // Compiler error: required SecurityFactory<Credential> provided SecurityFactory<GSSCredential>
{code}
Similar issue in the following method:
{code:java}
MechanismConfiguration.setServerCredential(SecurityFactory<Credential> credentialFactory)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
[View Less]
5 years, 4 months
[JBoss JIRA] (ELY-1898) ServiceFactory<Credential> used in API is too strict
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ELY-1898?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant updated ELY-1898:
---------------------------------
Priority: Blocker (was: Major)
> ServiceFactory<Credential> used in API is too strict
> ----------------------------------------------------
>
> Key: ELY-1898
> URL: https://issues.jboss.org/browse/ELY-1898
> Project: WildFly Elytron
> Issue Type: Bug
> …
[View More] Components: API / SPI
> Affects Versions: 1.11.0.CR1
> Reporter: Tristan Tarrant
> Priority: Blocker
>
> In several places in the API, `SecurityFactory<Credential>` is used, but its bound is too strict, disallowing passing in specific instances, e.g. `SecurityFactory<GSSKerberosCredential>`.
> These should all be replaced with `SecurityFactory<? extends Credential>`.
> An example of code that doesn't work:
> {code:java}
> SecurityFactory<GSSKerberosCredential> ksf = ...;
> CredentialSource cs = CredentialSource.fromSecurityFactory(ksf); // Compiler error: required SecurityFactory<Credential> provided SecurityFactory<GSSCredential>
> {code}
> Similar issue in the following method:
> {code:java}
> MechanismConfiguration.setServerCredential(SecurityFactory<Credential> credentialFactory)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
[View Less]
5 years, 4 months
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ]
Bela Ban reopened JGRP-2394:
----------------------------
> Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2394
> URL: https://issues.jboss.org/browse/JGRP-…
[View More]2394
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Nistor Adrian
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
> So we propose adding someting like this:
> JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
> which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
[View Less]
5 years, 4 months
[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3580?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3580:
---------------------------------------
[~manstis] can I ask you please to clone/link a ticket for this in BAPL for product tracking. Definitively not for 7.6, but we should look into 7.7 timeframe.
> [DMN Designer] Decision Table: Add support for merged view
> ----------------------------------------------------------
>
> Key: DROOLS-3580
> …
[View More] URL: https://issues.jboss.org/browse/DROOLS-3580
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.17.0.Final
> Reporter: Edson Tirelli
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> Add support for viewing the {{DecisionTableGrid}} in _merged_ mode.
> The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged..
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
[View Less]
5 years, 4 months
[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ]
Nistor Adrian commented on JGRP-2394:
-------------------------------------
[~belaban] Unfortunately I realized just now we also need the same treatment for unregistration, so I made a quick PR https://github.com/belaban/JGroups/pull/445
This PR also adds the type=channel/type=protocol ObjectName keys internally so the resulting names will match the previous conventions and do not rely on the user to provide …
[View More]them.
> Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2394
> URL: https://issues.jboss.org/browse/JGRP-2394
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Nistor Adrian
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.8
>
>
> The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case.
> So we propose adding someting like this:
> JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols)
> which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
[View Less]
5 years, 4 months