July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1641) CLI, completion for more than one header is not working

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1641: -------------------------------------------- Summary: CLI, completion for more than one header is not working Key: WFCORE-1641 URL: https://issues.jboss.org/browse/WFCORE-1641 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Alexey Loubyansky This can't be fixed until https://issues.jboss.org/browse/AESH-386 is fixed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1637) headers in Operation and Command are not properly completed

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1637?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1637: ---------------------------------------------- Item 2) can't be fixed due to Aesh current implementation: https://issues.jboss.org/browse/AESH-386 > headers in Operation and Command are not properly completed > ----------------------------------------------------------- > > Key: WFCORE-1637 > URL: https://issues.jboss.org/browse/WFCORE-1637 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > For example: > 1) ls --headers {allow-resource-service-restart <TAB> > doesn't give you the '=' > 2) ls --headers {allow-resource-service-restart=true; <TAB> > list you the commands one can type...not at al an header. > 3) NPE caused by WFCORE-1617 > ls --headers {allow-resource-service-restart=t<TAB> ==> NPE > Completion should properly complete each header. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6808: ------------------------------- Fix Version/s: 10.1.0.Final > DistributableSession validate method throw misleading exception message > ----------------------------------------------------------------------- > > Key: WFLY-6808 > URL: https://issues.jboss.org/browse/WFLY-6808 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Mathieu Lachance > Assignee: Paul Ferraro > Fix For: 10.1.0.Final > > > In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense): > {code} > public class DistributableSession implements io.undertow.server.session.Session { > private static void validate(Session<LocalSessionContext> session) { > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionNotFound(session.getId()); > } > } > } > {code} > The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session. > I would recommend we do instead: > {code} > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(); > } > {code} > or even better: > {code} > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId()); > } > {code} > but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message. > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1637) headers in Operation and Command are not properly completed

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1637?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1637: ----------------------------------------- Description: For example: 1) ls --headers {allow-resource-service-restart <TAB> doesn't give you the '=' 2) ls --headers {allow-resource-service-restart=true; <TAB> list you the commands one can type...not at al an header. 3) NPE caused by WFCORE-1617 ls --headers {allow-resource-service-restart=t<TAB> ==> NPE Completion should properly complete each header. was: For example: 1) ls --headers {allow-resource-service-restart <TAB> doesn't give you the '=' 2) ls --headers {allow-resource-service-restart=true; <TAB> list you the commands one can type...not at al an header. Completion should properly complete each header. > headers in Operation and Command are not properly completed > ----------------------------------------------------------- > > Key: WFCORE-1637 > URL: https://issues.jboss.org/browse/WFCORE-1637 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > For example: > 1) ls --headers {allow-resource-service-restart <TAB> > doesn't give you the '=' > 2) ls --headers {allow-resource-service-restart=true; <TAB> > list you the commands one can type...not at al an header. > 3) NPE caused by WFCORE-1617 > ls --headers {allow-resource-service-restart=t<TAB> ==> NPE > Completion should properly complete each header. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6813) JSP compiler doesn't work with JDK9

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6813?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6813: ------------------------------ Summary: JSP compiler doesn't work with JDK9 (was: Make JSP compiler doesn't work with JDK9) > JSP compiler doesn't work with JDK9 > ----------------------------------- > > Key: WFLY-6813 > URL: https://issues.jboss.org/browse/WFLY-6813 > Project: WildFly > Issue Type: Sub-task > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Currently because of issue http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources in jigsaw, our ecj compiler fails to properly load classes and as such fails to compile jsps. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1374) Make it build & work on JDK9

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1374?page=com.atlassian.jira.plugi... ] Tomaz Cerar reopened WFCORE-1374: --------------------------------- > Make it build & work on JDK9 > ---------------------------- > > Key: WFCORE-1374 > URL: https://issues.jboss.org/browse/WFCORE-1374 > Project: WildFly Core > Issue Type: Task > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha1 > > > Parent task to track all JDK9 related work in wildfly core. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6813) Make JSP compiler doesn't work with JDK9

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-6813: --------------------------------- Summary: Make JSP compiler doesn't work with JDK9 Key: WFLY-6813 URL: https://issues.jboss.org/browse/WFLY-6813 Project: WildFly Issue Type: Sub-task Components: Web (Undertow) Reporter: Tomaz Cerar Assignee: Tomaz Cerar Currently because of issue http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources in jigsaw, our ecj compiler fails to properly load classes and as such fails to compile jsps. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC

by István Tóth (JIRA)

[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ] István Tóth commented on WFLY-5739: ----------------------------------- I have sent a PR that fixes this: https://github.com/picketbox/picketbox/pull/62 > Subject not populated with groups/roles when authenticated via JASPIC > --------------------------------------------------------------------- > > Key: WFLY-5739 > URL: https://issues.jboss.org/browse/WFLY-5739 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Arjan t > Assignee: Darran Lofthouse > Labels: jacc, jaspic > > After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails. > For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role: > {code:java} > Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container"); > > boolean hasAccess = Policy.getPolicy().implies( > new ProtectionDomain( > new CodeSource(null, (Certificate[]) null), > null, null, > subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()]) > ), > new WebResourcePermission("/protected/Servlet", "GET")) > ; > {code} > As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles. > This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject": > {code:java} > String[] rolesArray = groupPrincipalCallback.getGroups(); > int sizeOfRoles = rolesArray != null ? rolesArray.length : 0; > > if( sizeOfRoles > 0 ) > { > List<Role> rolesList = new ArrayList<Role>(); > for( int i = 0; i < sizeOfRoles ; i++ ) > { > Role role = new SimpleRole( rolesArray[ i ] ); > rolesList.add( role ); > } > RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList ); > // if the current security context already has roles, we merge them with the incoming roles. > RoleGroup currentRoles = currentSC.getUtil().getRoles(); > // *** ROLES ARE ONLY SET HERE *** > if (currentRoles != null) { > currentRoles.addAll(roles.getRoles()); > } > else { > currentSC.getUtil().setRoles( roles ); > } > } > // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE > // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO > Subject subject = groupPrincipalCallback.getSubject(); > if( subject != null ) > { > // if the current security context already has an associated subject, we merge it with the incoming subject. > Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject(); > if (currentSubject != null) { > subject.getPrincipals().addAll(currentSubject.getPrincipals()); > subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials()); > subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials()); > } > currentSC.getSubjectInfo().setAuthenticatedSubject(subject); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6200) connection-url is required even when not used

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-6200: ------------------------------- I think [~mvera31] is saying that before this issue gets fixed, the {{connection_url}} is mandatory. After this issue gets fixed, it is not mandatory any longer. ;) > connection-url is required even when not used > --------------------------------------------- > > Key: WFLY-6200 > URL: https://issues.jboss.org/browse/WFLY-6200 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: Rich DiCroce > Assignee: Lin Gao > > Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start: > {noformat} > 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "datasources"), > ("data-source" => "GamingPortalDS") > ]) - failure description: "WFLYCTL0155: connection-url may not be null" > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6671. ---------------------------------- Resolution: Cannot Reproduce Bug I could not reproduce this > ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked' > ----------------------------------------------------------------------------------------- > > Key: WFLY-6671 > URL: https://issues.jboss.org/browse/WFLY-6671 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37 > Reporter: river shen > Assignee: Stuart Douglas > Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties > > > When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior: > if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. > It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port. > We have attached a minimal web application that reproduce this issue. > Also attached is the standalone.xml and the apache configuration file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 July 2016