[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "qui" on HPUX
by Dominik Pospisil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ]
Dominik Pospisil commented on WFCORE-929:
-----------------------------------------
My findings so far:
* Actually It's typing the 'u' character making the JVM to terminate
* The "Aesh InputStream Reader" seems to be causing the termination
* it happends somewhere on line AeshInputStream.readFromStream:126, it does not make it to line 127. Seems to be somewhere in JDK code.
> CLI is terminated unexpectedly after type "qui" on HPUX
> -------------------------------------------------------
>
> Key: WFCORE-929
> URL: https://issues.jboss.org/browse/WFCORE-929
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> *Description of problem:*
> CLI is terminated unexpectedly after type "qui" on HPUX
> *How reproducible:*
> Always on HPUX
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # qui
> #* type "qui" in console to CLI, do not press "enter"
> *Actual results:*
> CLI is terminated
> *Expected results:*
> CLI is not terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Dennis Reed (JIRA)
Dennis Reed created WFCORE-1029:
-----------------------------------
Summary: ManagedSocketFactory doesn't work for client sockets
Key: WFCORE-1029
URL: https://issues.jboss.org/browse/WFCORE-1029
Project: WildFly Core
Issue Type: Bug
Affects Versions: 2.0.0.CR5
Reporter: Dennis Reed
SocketBindingManagerImpl does not work with client sockets.
It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly
by Dennis Reed (JIRA)
Dennis Reed created WFLY-5449:
---------------------------------
Summary: 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
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, 2 months
[JBoss JIRA] (SECURITY-808) Password not passed into DatabaseServerLoginModule
by Lorenz Froihofer (JIRA)
[ https://issues.jboss.org/browse/SECURITY-808?page=com.atlassian.jira.plug... ]
Lorenz Froihofer commented on SECURITY-808:
-------------------------------------------
Tracked down the issue a little bit further (picketbox-4.9.2.Final in Wildfly 9.0.1.Final):
JBossCallbackHandler.getPassword() falls back to try the dynamic invocation of a method named "toCharArray":
{code:java}
Method m = credential.getClass().getMethod("toCharArray", types);
Object[] args = {};
password = (char[]) m.invoke(credential, args);
{code}
This fails with a NoSuchMethodException for a RemotingConnectionCredential object as this class does not offer such a method. The exception handling just tries to create a credential by using the "toString" method on the credential object (the RemotingConnectionCredential) - leading to a String such as org.jboss.as.security.remoting.RemotingConnectionCredential@22341334 instead of the real password.
As far as the code looks like, the RemotingConnectionCredential should allow for a callback to get the password, but looking at it or the wrapped Connection class, one can only get the username through org.jboss.remoting3.Connection.getUserInfo(), but no password.
This seems to be a more general issue not only related to the DatabaseServerLoginModule but to custom login modules as well: https://developer.jboss.org/message/866429
> Password not passed into DatabaseServerLoginModule
> --------------------------------------------------
>
> Key: SECURITY-808
> URL: https://issues.jboss.org/browse/SECURITY-808
> Project: PicketBox
> Issue Type: Bug
> Environment: WildFly8 on Windows 7 64-bit
> Reporter: Stefan Eder
> Assignee: Stefan Guilhen
> Priority: Critical
>
> Trying to migrate an application to WildFly (from AS6.1) the migration went pretty smooth except for using the security domain.
> The application uses a the ClientLoginModule on the client side and the DatabaseserverLoginModule on the server side.
>
> Though the DatabaseServerLoginModule is called the validation of the password fails. I debugged it and the reason seems to be that in {{org.jboss.security.auth.callback.JBossCallbackHandler.getPassword()}} a {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is not handled and hence instead of a password the String {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is passed through to the DatabaseLoginModule.
> See also [DatabaseServerLoginModule broken?|https://community.jboss.org/message/863295] and the related posts
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-935) tomcat7 unable to deploy Execution server
by Siarhei Yarkavy (JIRA)
Siarhei Yarkavy created DROOLS-935:
--------------------------------------
Summary: tomcat7 unable to deploy Execution server
Key: DROOLS-935
URL: https://issues.jboss.org/browse/DROOLS-935
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: Siarhei Yarkavy
Assignee: Edson Tirelli
Attachments: catalina.2015-10-01.zip
Unable to properly deploy Execution server into tomcat7 container.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months