[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1325?page=com.atlassian.jira.plugin... ]
Ivo Studensky updated JBJCA-1325:
---------------------------------
Fix Version/s: WildFly/IronJacamar 1.3.5.Final
1.2.8.Final
> Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
> -------------------------------------------------------------------------
>
> Key: JBJCA-1325
> URL: https://issues.jboss.org/browse/JBJCA-1325
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Martin Simka
> Assignee: Ivo Studensky
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> {code:java}
> value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error");
> if (value != null && !value.trim().equals(""))
> {
> if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value))
> {
> doSetRollbackOnly = Boolean.parseBoolean(value);
> }
> else
> {
> StringTokenizer st = new StringTokenizer(value, ",");
> while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ...
> {
> if (getPool().getName().equals(st.nextToken()))
> doSetRollbackOnly = false;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q.
However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*!
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7158:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7158:
-----------------------------
Description:
In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
{code}
/subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
{code}
was:
In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
That is pretty inconvinient. Probably introducing alias attribute on key-manager would be more intuitive solution to this situation.
{code}
/subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
{code}
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7027:
-----------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1372096|https://bugzilla.redhat.com/show_bug.cgi?id=1372096] from NEW to ASSIGNED
> MBeans with ObjectName attributes throw ClassNotFoundException
> --------------------------------------------------------------
>
> Key: WFLY-7027
> URL: https://issues.jboss.org/browse/WFLY-7027
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.0.0.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Baranowski
> Fix For: 11.0.0.Alpha1
>
>
> An MBean with:
> public void setObj(javax.management.ObjectName someObject)
> <mbean ...>
> <attribute name="Obj" />
> causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\"
> org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months