[JBoss JIRA] (ELY-359) Additional work on LDAP SecurityRealm
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-359:
------------------------------------
Summary: Additional work on LDAP SecurityRealm
Key: ELY-359
URL: https://issues.jboss.org/browse/ELY-359
Project: WildFly Elytron
Issue Type: Enhancement
Components: Realms
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta2
The credential loaders need to be created outside of the realm instance, this way multiple instances can be created with varying settings.
The PrincipalMapping class was only really intended to contain settings required to locate a prinicipal - however this has ended up containing credential loading settings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JGRP-1825) ReadWriteLock
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1825?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1825:
--------------------------------
What exactly do you want to achieve? Can't you implement the locking/isolation semantics with cache-local locks and using JGroups only as message transport?
I'm not entirely happy with the current {{LockService}}, as it doesn't handle partitions well. The {{j.u.c.l.Lock}} interface isn't amenable to takeing locks away from members, so I'm thinking about designing a new partitionable lock service. Not at the top of my todo list though...
Since I'm not happy with the current lock impl, I don't want to add something atm.
> ReadWriteLock
> -------------
>
> Key: JGRP-1825
> URL: https://issues.jboss.org/browse/JGRP-1825
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
> Attachments: JgroupTest.zip
>
>
> Adds a read/write lock to LockService. The impl is attached
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1033) ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1033?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1033:
-------------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED
> ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1033
> URL: https://issues.jboss.org/browse/WFCORE-1033
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.0.0.CR6
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> {noformat}
> &#27;[0m&#27;[31m14:51:47,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.NullPointerException
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.network.ManagedMulticastSocketBinding.bind(ManagedMulticastSocketBinding.java:78)
> at java.net.MulticastSocket.<init>(MulticastSocket.java:172)
> at org.jboss.as.network.ManagedMulticastSocketBinding.<init>(ManagedMulticastSocketBinding.java:54)
> at org.jboss.as.network.ManagedMulticastSocketBinding.create(ManagedMulticastSocketBinding.java:40)
> at org.jboss.as.network.SocketBindingManagerImpl.createMulticastSocket(SocketBindingManagerImpl.java:82)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactoryNew.createMulticastSocket(ManagedSocketFactoryNew.java:127)
> at org.jgroups.util.Util.createMulticastSocket(Util.java:3089)
> at org.jgroups.protocols.MPING.start(MPING.java:190)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> {noformat}
> This is because the MulticastSocket and DatagramSocket constructors call bind(...), but the ManagedBindingRegistry is not yet set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5449:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED
> Custom socket factory for JGroups subsystem not set correctly
> -------------------------------------------------------------
>
> Key: WFLY-5449
> URL: https://issues.jboss.org/browse/WFLY-5449
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR2
> Reporter: Dennis Reed
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR4
>
>
> Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport.
> This is not the correct API to use, and it gets overwritten when the JGroups channel starts.
> A custom socket factory should be set on the JChannel.
> The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months