[JBoss JIRA] (WFLY-5043) Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5043?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-493 to WFLY-5043:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5043 (was: UNDERTOW-493)
Issue Type: Feature Request (was: Bug)
Affects Version/s: (was: 1.3.0.Beta3)
Component/s: Web (Undertow)
(was: Proxy)
> Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5043
> URL: https://issues.jboss.org/browse/WFLY-5043
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Labels: mod_cluster
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Implement & Display node's Elected, Read, Transferred and Connected stats
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> Furthermore, at a glance, it appears that a part of the needed stats is a mere placeholder at the moment: [NodeStats.java|https://github.com/undertow-io/undertow/blob/master/core/s...]
> h3. Call to action
> Display the aforementioned stats for each node. Let me set priorities according to what is really used in the battlefield:
> * {color:red}Critical{color}: *Elected* (it is often correlated with *Load* during load metric *history* and *capacity* tuning)
> * {color:green}Minor{color}: *Read*
> * {color:green}Minor{color}: *Transferred*
> * {color:green}Minor{color}: *Connected*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (WFCORE-855) Intermittent Disconnection from CLI After Reload in domain mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from NEW to POST
> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
> Key: WFCORE-855
> URL: https://issues.jboss.org/browse/WFCORE-855
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Joe Wertz
> Assignee: Joe Wertz
> Fix For: 2.0.0.Alpha12
>
> Original Estimate: 3 minutes
> Remaining Estimate: 3 minutes
>
> Description of problem:
> CLI scripts for management of managed domain
> Version-Release number of selected component (if applicable):
> 6.4.3.CP.CR1
> How reproducible:
> Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Additional info:
> - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
> - using --timeout doesn't workaround the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1548:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from ASSIGNED to POST
> Add fallback querry to jconsole plugin
> --------------------------------------
>
> Key: WFLY-1548
> URL: https://issues.jboss.org/browse/WFLY-1548
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 8.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Darran Lofthouse
> Labels: JConsole, JMX, Plugin
> Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (AS7-6911) jconsole fails if trying to connect to a standalone EAP instance running with offset ports
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6911?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6911:
----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from ASSIGNED to POST
> jconsole fails if trying to connect to a standalone EAP instance running with offset ports
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6911
> URL: https://issues.jboss.org/browse/AS7-6911
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Stan Silvert
> Labels: cli
>
> If JBoss AS7/8 is started using port-offset as following:
> ie. with -Djboss.socket.binding.port-offset=100
> Then While connecting to it using "jconsole.sh" as a Local Process it throws the following Exception:
> +++++++++++++++++++++++++++++
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
> at java.awt.EventQueue.access$000(EventQueue.java:84)
> at java.awt.EventQueue$1.run(EventQueue.java:607)
> at java.awt.EventQueue$1.run(EventQueue.java:605)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> +++++++++++++++++++++++
> And the Code "org.jboss.as.cli.gui.JConsoleCLIPlugin" classes Line 109 throws NullPointerException, Because "cliGuiCtx" object is null and not initialized earlier:
> 109 JOptionPane.showMessageDialog(cliGuiCtx.getMainWindow(), message);
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny edited comment on SECURITY-784 at 8/1/15 10:36 AM:
-----------------------------------------------------------------
In my project, I've found the solution is that moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. This it to ensure that class loader which is not lost and It's working fine for me :)
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try {
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
was (Author: nguyennhatkhanh206):
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try {
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Pedro Igor
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny edited comment on SECURITY-784 at 8/1/15 10:29 AM:
-----------------------------------------------------------------
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try {
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
was (Author: nguyennhatkhanh206):
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try
{
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Pedro Igor
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny edited comment on SECURITY-784 at 8/1/15 10:29 AM:
-----------------------------------------------------------------
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try
{
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
was (Author: nguyennhatkhanh206):
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try
{
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Pedro Igor
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny commented on SECURITY-784:
----------------------------------------
In my project, I've moved SecurityActions.setContextClassLoader(null) after ctx = constructInitialLdapContext(bindDN, bindCredential); where loads custom socket. It's working fine.
org.jboss.security.auth.spi.LdapExtLoginModule#createLdapInitContext
InitialLdapContext ctx = null;
ClassLoader currentTCCL = SecurityActions.getContextClassLoader();
try
{
ctx = constructInitialLdapContext(bindDN, bindCredential);
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
...
} finally {
if (ctx != null)
ctx.close();
if (currentTCCL != null)
SecurityActions.setContextClassLoader(currentTCCL);
}
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Pedro Igor
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month
[JBoss JIRA] (DROOLS-868) Custom metadata declared at field-level is not available at runtime
by Andrew Bickerton (JIRA)
Andrew Bickerton created DROOLS-868:
---------------------------------------
Summary: Custom metadata declared at field-level is not available at runtime
Key: DROOLS-868
URL: https://issues.jboss.org/browse/DROOLS-868
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Andrew Bickerton
Assignee: Mario Fusco
DROOLS-619 introduced a bug that means custom metadata declared at the field level is not available at runtime via FactField.getMetaData(). None of the existing test cases cover this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years, 1 month