February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ] ehsavoie Hugonnet commented on WFLY-5715: ----------------------------------------- [~oleg.hoefling] Is there a way for you to connect to hipchat / irc for easier exchange ? Also could you attach your log files to https://issues.jboss.org/browse/WFCORE-1330 as this bug entry is closed. > Wildfly 9/10 removing deployments after a certain time > ------------------------------------------------------ > > Key: WFLY-5715 > URL: https://issues.jboss.org/browse/WFLY-5715 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final, 10.0.0.CR4 > Environment: Ubuntu 12.04.5 LTS > Reporter: Sven Ulrich > Assignee: ehsavoie Hugonnet > Attachments: Dummy.war, ifxjdbc_4.10.jar, server.log, standalone.xml > > > I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine. > Now I want to deploye my jar files (jdbc driver and jee apps). > All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080) > First I log into the web interface and navigate to the tab deployments. Then I use the button add. > In the popup window: > 1: Upload a new deployment > 2: I choose ifxjdbc_4.10.jar for e.g. > 3: In Verify upload enabled is set and everything else is standard > 4: The upload takes round about 30sec. > Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar. > It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :) > I have added my standalone.xml and the log with hopefully all needed information. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1313?page=com.atlassian.jira.plugi... ] Lin Gao reassigned WFCORE-1313: ------------------------------- Assignee: Lin Gao (was: Darran Lofthouse) > User with slash or backslash char in LDAP name cannot log in through security-realm > ----------------------------------------------------------------------------------- > > Key: WFCORE-1313 > URL: https://issues.jboss.org/browse/WFCORE-1313 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Lin Gao > Attachments: users.ldif > > > According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc. > I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there. > I can see this in Wireshark > *Slash/Char* > {code} > LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2 > {code} > You can see there quotation marks around *uid=Slash/Char*. > *Back\Slash* > {code} > LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6 > {code} > You can see there three backslash chars. > In my opinion problem can be somewhere around this > {code} > javax.naming.NameImpl.stringifyComp(String comp) > {code} > [1] https://tools.ietf.org/html/rfc2253#section-3 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1343) Memory leak in host controller

by Aparna Chaudhary (JIRA)

Aparna Chaudhary created WFCORE-1343: ---------------------------------------- Summary: Memory leak in host controller Key: WFCORE-1343 URL: https://issues.jboss.org/browse/WFCORE-1343 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Final Reporter: Aparna Chaudhary Assignee: Brian Stansberry Priority: Critical Attachments: WFCORE-992-HC-Leak.PNG The ManagedServerProxy class in host-controller contains a memory leak. The leak can be reproduced by performing multiple requests to HTTP management API. {noformat} http://<host>:9990/management/host/host0/server/server0/core-service/platform-mbean/type/memory?include-runtime=true {noformat} Applying the fix proposed in WFCORE-992 solves the leak. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-6096: ------------------------------------ Assignee: Paul Ferraro (was: Thomas Diesler) > ISPN-5876 changes need to be configurable > ----------------------------------------- > > Key: WFLY-6096 > URL: https://issues.jboss.org/browse/WFLY-6096 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Stephen Fikes > Assignee: Paul Ferraro > > When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default. > For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed. > As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out. > Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Tobias Lehr (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Tobias Lehr commented on WFLY-6097: ----------------------------------- out integrationtests confirm this bug. > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Richard Janík edited comment on WFLY-5932 at 2/1/16 2:40 AM: ------------------------------------------------------------- Hi Stuart, first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately. Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again. (I'm detailing the process in case you have something to say about it) What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems? tl;dr I don't think commit 394c7b8 fixes the issue - I'm still seeing it. edit: After discussion with Stuart, I've realized that the process above is unnecessarily complicated. Still, sso-fix branch doesn't seem to fix the issue. was (Author: rjanik): Hi Stuart, first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately. Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again. (I'm detailing the process in case you have something to say about it) What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems? tl;dr I don't think commit 394c7b8 fixes the issue - I'm still seeing it. > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-5484: ------------------------------------- After discussion with Stuart, we found that the problem was in my testing process. Undertow 1.3.16.Final really does fix this. > Calling HttpServletRequest.logout() with single sign-on enabled only works every second time > -------------------------------------------------------------------------------------------- > > Key: WFLY-5484 > URL: https://issues.jboss.org/browse/WFLY-5484 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: reproducer-jbeap-1282.zip > > > See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect > This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6102) Removing of non-existent mapping-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6102?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6102: ------------------------------- Component/s: Domain Management Security (was: CLI) > Removing of non-existent mapping-module finishes with outcome success > --------------------------------------------------------------------- > > Key: WFLY-6102 > URL: https://issues.jboss.org/browse/WFLY-6102 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Alexey Loubyansky > Priority: Minor > > In case when non-existent mapping-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6102) Removing of non-existent mapping-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6102?page=com.atlassian.jira.plugin.... ] Ondrej Lukas reassigned WFLY-6102: ---------------------------------- Assignee: Brian Stansberry (was: Alexey Loubyansky) > Removing of non-existent mapping-module finishes with outcome success > --------------------------------------------------------------------- > > Key: WFLY-6102 > URL: https://issues.jboss.org/browse/WFLY-6102 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when non-existent mapping-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ] Ondrej Lukas reassigned WFLY-6083: ---------------------------------- Assignee: Brian Stansberry (was: Dmitrii Tikhomirov) > Removing of non-existent login-module finishes with outcome success > ------------------------------------------------------------------- > > Key: WFLY-6083 > URL: https://issues.jboss.org/browse/WFLY-6083 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016