[JBoss JIRA] (ELY-1950) FORM authentication not working for URL encoded session IDs
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1950?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1950:
----------------------------
Fix Version/s: 1.13.0.CR3
(was: 1.13.0.CR2)
> FORM authentication not working for URL encoded session IDs
> -----------------------------------------------------------
>
> Key: ELY-1950
> URL: https://issues.redhat.com/browse/ELY-1950
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.13.0.CR3
>
>
> The session IDs are encoded as: -
> {code}
> /secure/j_security_check;jsessionid=kVzsBG9c3XxcOlzpa65ohiMeMNqXdSNQuOdvdpR3.flame
> {code}
> However the code that checks if this is a submission to j_security_check is: -
> {code:java}
> request.getRequestURI().getPath().endsWith(postLocation)
> {code}
> This code needs to trim the path at ';'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ELY-1994) Ensure the Elytron build works on Java 14
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1994?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1994:
----------------------------
Fix Version/s: 1.13.0.CR3
(was: 1.13.0.CR2)
> Ensure the Elytron build works on Java 14
> -----------------------------------------
>
> Key: ELY-1994
> URL: https://issues.redhat.com/browse/ELY-1994
> Project: WildFly Elytron
> Issue Type: Task
> Components: Testsuite
> Reporter: Darran Lofthouse
> Priority: Major
> Fix For: 1.13.0.CR3
>
>
> Overall the build is not doing too badly and doesn't fail until we get to the main testsuite.
>
> {code:java}
> [INFO] WildFly Elytron - Tests ............................ FAILURE [ 1.447 s]
> [INFO] WildFly Elytron .................................... SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 01:46 min
> [INFO] Finished at: 2020-06-11T11:25:23+01:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0-jboss-1:testCompile (default-testCompile) on project wildfly-elytron-tests: Compilation failure: Compilation failure:
> [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[31,25] package java.security.acl does not exist
> [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[107,40] cannot find symbol
> [ERROR] symbol: class Group
> [ERROR] location: class org.wildfly.security.auth.TestLoginModule
> [ERROR] -> [Help 1] {code}
> If this is all that is failing for us maybe we can revisit the test and see how appropriate it is and if it can be adapted to use available APIs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-13641:
---------------------------------
Labels: affects-migration (was: )
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13641
> URL: https://issues.redhat.com/browse/WFLY-13641
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.0.Final
> Reporter: Jens Viebig
> Assignee: Matěj Novotný
> Priority: Major
> Labels: affects-migration
>
> When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class:
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> Seems VFS cannot get hold of the classes.
> The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13662) Weld Conversation Context Logs when not using Conversation Context
by Cody Lerum (Jira)
[ https://issues.redhat.com/browse/WFLY-13662?page=com.atlassian.jira.plugi... ]
Cody Lerum edited comment on WFLY-13662 at 7/10/20 4:41 PM:
------------------------------------------------------------
Additionally had it trigger this on a websocket endpoint so not strictly JSF either
{code:java}
@ApplicationScoped
@ServerEndpoint(value = "/ws/global/{token}")
public class GlobalServerEndpoint {
....
} {code}
{code:java}
2020-07-10 20:30:43,442 WARN [org.jboss.weld.Servlet] (default task-31) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@2dba65fb when destroying request HttpServletRequestImpl [ GET /s/i/voice/voiceGroup/view.xhtml ]
2020-07-10 20:30:44,174 WARN [org.jboss.weld.Conversation] (default task-31) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /ws/global/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9]
{code}
was (Author: clerum):
Additionally had it trigger this on a websocket endpoint so not strictly JSF either
{code:java}
@ApplicationScoped
@ServerEndpoint(value = "/ws/global/{token}")
public class GlobalServerEndpoint {
....
} {code}
{code:java}
2020-07-10 20:30:43,442 WARN [org.jboss.weld.Servlet] (default task-31) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@2dba65fb when destroying request HttpServletRequestImpl [ GET /s/i/voice/voiceGroup/view.xhtml ]
2020-07-10 20:30:44,174 WARN [org.jboss.weld.Conversation] (default task-31) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /ws/global/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpbnRlcm5hbCI6ZmFsc2UsImlkIjoxNzk4NCwiZXhwIjoxNTk0NDE2NjQzLCJpYXQiOjE1OTQ0MTMwNDMsInVzZXJuYW1lIjoiYnJhZEBhZHZhbmNlZC10ZWxlY29tLmNvbSJ9.gHzKg7j2nJuI0cJ6DkNqsHZaagiInaIlpOJydF3xbEo ]
{code}
> Weld Conversation Context Logs when not using Conversation Context
> ------------------------------------------------------------------
>
> Key: WFLY-13662
> URL: https://issues.redhat.com/browse/WFLY-13662
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 20.0.1.Final
> Reporter: Cody Lerum
> Assignee: Matěj Novotný
> Priority: Major
>
> After upgrading to Widfly 20.0.1 from 18.0.1 I'm starting to receive show log errors regarding the CDI conversation context even though it is not used anywhere in the application.
> These did not present in the same application in 18.0.1.Final
> {code:java}
> 020-07-10 15:42:47,561 ERROR [io.undertow.request] (default task-273) UT005023: Exception handling request to /s/c/voice/fax/view.xhtml: java.lang.NullPointerException2020-07-10 15:42:47,562 WARN [org.jboss.weld.Servlet] (default task-273) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@25333df0 when destroying request HttpServletRequestImpl [ GET /s/c/voice/fax/view.xhtml ]
> 2020-07-10 15:42:48,165 WARN [org.jboss.weld.Conversation] (default task-273) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /i/ticket/46893 ] {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13662) Weld Conversation Context Logs when not using Conversation Context
by Cody Lerum (Jira)
[ https://issues.redhat.com/browse/WFLY-13662?page=com.atlassian.jira.plugi... ]
Cody Lerum edited comment on WFLY-13662 at 7/10/20 4:41 PM:
------------------------------------------------------------
Additionally had it trigger this on a websocket endpoint so not strictly JSF either
{code:java}
@ApplicationScoped
@ServerEndpoint(value = "/ws/global/{token}")
public class GlobalServerEndpoint {
....
} {code}
{code:java}
2020-07-10 20:30:43,442 WARN [org.jboss.weld.Servlet] (default task-31) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@2dba65fb when destroying request HttpServletRequestImpl [ GET /s/i/voice/voiceGroup/view.xhtml ]
2020-07-10 20:30:44,174 WARN [org.jboss.weld.Conversation] (default task-31) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /ws/global/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpbnRlcm5hbCI6ZmFsc2UsImlkIjoxNzk4NCwiZXhwIjoxNTk0NDE2NjQzLCJpYXQiOjE1OTQ0MTMwNDMsInVzZXJuYW1lIjoiYnJhZEBhZHZhbmNlZC10ZWxlY29tLmNvbSJ9.gHzKg7j2nJuI0cJ6DkNqsHZaagiInaIlpOJydF3xbEo ]
{code}
was (Author: clerum):
Additionally had it trigger this on a websocket endpoint so not strictly JSF either
{code:java}
@ApplicationScoped
@ServerEndpoint(value = "/ws/global/{token}")
public class GlobalServerEndpoint {
....
} {code}
{code:java}
2020-07-10 20:30:44,174 WARN [org.jboss.weld.Conversation] (default task-31) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /ws/global/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 ]
{code}
> Weld Conversation Context Logs when not using Conversation Context
> ------------------------------------------------------------------
>
> Key: WFLY-13662
> URL: https://issues.redhat.com/browse/WFLY-13662
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 20.0.1.Final
> Reporter: Cody Lerum
> Assignee: Matěj Novotný
> Priority: Major
>
> After upgrading to Widfly 20.0.1 from 18.0.1 I'm starting to receive show log errors regarding the CDI conversation context even though it is not used anywhere in the application.
> These did not present in the same application in 18.0.1.Final
> {code:java}
> 020-07-10 15:42:47,561 ERROR [io.undertow.request] (default task-273) UT005023: Exception handling request to /s/c/voice/fax/view.xhtml: java.lang.NullPointerException2020-07-10 15:42:47,562 WARN [org.jboss.weld.Servlet] (default task-273) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@25333df0 when destroying request HttpServletRequestImpl [ GET /s/c/voice/fax/view.xhtml ]
> 2020-07-10 15:42:48,165 WARN [org.jboss.weld.Conversation] (default task-273) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /i/ticket/46893 ] {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13662) Weld Conversation Context Logs when not using Conversation Context
by Cody Lerum (Jira)
[ https://issues.redhat.com/browse/WFLY-13662?page=com.atlassian.jira.plugi... ]
Cody Lerum commented on WFLY-13662:
-----------------------------------
Additionally had it trigger this on a websocket endpoint so not strictly JSF either
{code:java}
@ApplicationScoped
@ServerEndpoint(value = "/ws/global/{token}")
public class GlobalServerEndpoint {
....
} {code}
{code:java}
2020-07-10 20:30:44,174 WARN [org.jboss.weld.Conversation] (default task-31) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /ws/global/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 ]
{code}
> Weld Conversation Context Logs when not using Conversation Context
> ------------------------------------------------------------------
>
> Key: WFLY-13662
> URL: https://issues.redhat.com/browse/WFLY-13662
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 20.0.1.Final
> Reporter: Cody Lerum
> Assignee: Matěj Novotný
> Priority: Major
>
> After upgrading to Widfly 20.0.1 from 18.0.1 I'm starting to receive show log errors regarding the CDI conversation context even though it is not used anywhere in the application.
> These did not present in the same application in 18.0.1.Final
> {code:java}
> 020-07-10 15:42:47,561 ERROR [io.undertow.request] (default task-273) UT005023: Exception handling request to /s/c/voice/fax/view.xhtml: java.lang.NullPointerException2020-07-10 15:42:47,562 WARN [org.jboss.weld.Servlet] (default task-273) WELD-000717: Unable to deactivate context org.jboss.weld.module.web.context.http.LazyHttpConversationContextImpl@25333df0 when destroying request HttpServletRequestImpl [ GET /s/c/voice/fax/view.xhtml ]
> 2020-07-10 15:42:48,165 WARN [org.jboss.weld.Conversation] (default task-273) WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ GET /i/ticket/46893 ] {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13663) Fix modules with dependency on javax.xml.rpc.api
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13663?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13663:
------------------------------------
Labels: EE9 (was: )
> Fix modules with dependency on javax.xml.rpc.api
> ------------------------------------------------
>
> Key: WFLY-13663
> URL: https://issues.redhat.com/browse/WFLY-13663
> Project: WildFly
> Issue Type: Task
> Components: EJB, Transactions, Web Services
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Labels: EE9
> Fix For: 21.0.0.Beta1
>
>
> The following modules have a dep on the javax.xml.rpc.api module. JAX-RPC has been pruned from EE 9 so in the EE9 variant of WildFly I want to avoid shipping that module. Task here is to confirm these dependencies are needed, and if not prune them. Then for anything remaining determine how to handle the dep (e.g. make it optional).
> org.apache.ws.security
> org.jboss.as.ejb3
> org.jboss.as.webservices
> org.jboss.narayana.rts
> org.jboss.ws.common
> javax.ejb.api
> The javax.ejb.api one, the 4.0.0.RC2 version of jakarta.ejb:jakarta.ejb-api doesn't have any JAX-RPC dep so even though one is needed for the EE 8 version of the module.xml we can drop it from the EE 9 one. Spec API modules will have different module.xml files for EE 8 vs 9.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13663) Fix modules with dependency on javax.xml.rpc.api
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13663?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13663:
------------------------------------
Description:
The following modules have a dep on the javax.xml.rpc.api module. JAX-RPC has been pruned from EE 9 so in the EE9 variant of WildFly I want to avoid shipping that module. Task here is to confirm these dependencies are needed, and if not prune them. Then for anything remaining determine how to handle the dep (e.g. make it optional).
org.apache.ws.security
org.jboss.as.ejb3
org.jboss.as.webservices
org.jboss.narayana.rts
org.jboss.ws.common
javax.ejb.api
The javax.ejb.api one, the 4.0.0.RC2 version of jakarta.ejb:jakarta.ejb-api doesn't have any JAX-RPC dep so even though one is needed for the EE 8 version of the module.xml we can drop it from the EE 9 one. Spec API modules will have different module.xml files for EE 8 vs 9.
was:
The following modules have a dep on the javax.xml.rpc.api module. JAX-RPC has been pruned from EE 9 so in the EE9 variant of WildFly I want to avoid shipping that module. Task here is to confirm these dependencies are needed, and if not prune them. Then for anything remaining determine how to handle the dep (e.g. make it optional).
org.apache.ws.security
org.jboss.as.ejb3
org.jboss.as.webservices
org.jboss.narayana.rts
org.jboss.ws.common
javax.ejb.api
The javax.ejb.api one, the 4.0.0.RC2 version of jakarta.ejb:jakarta.ejb-api doesn't have any JAX-RPC dep so even if one is needed for the EE 8 version of the module.xml we can drop it from the EE 9 one. Spec API modules will have different module.xml files for EE 8 vs 9.
> Fix modules with dependency on javax.xml.rpc.api
> ------------------------------------------------
>
> Key: WFLY-13663
> URL: https://issues.redhat.com/browse/WFLY-13663
> Project: WildFly
> Issue Type: Task
> Components: EJB, Transactions, Web Services
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The following modules have a dep on the javax.xml.rpc.api module. JAX-RPC has been pruned from EE 9 so in the EE9 variant of WildFly I want to avoid shipping that module. Task here is to confirm these dependencies are needed, and if not prune them. Then for anything remaining determine how to handle the dep (e.g. make it optional).
> org.apache.ws.security
> org.jboss.as.ejb3
> org.jboss.as.webservices
> org.jboss.narayana.rts
> org.jboss.ws.common
> javax.ejb.api
> The javax.ejb.api one, the 4.0.0.RC2 version of jakarta.ejb:jakarta.ejb-api doesn't have any JAX-RPC dep so even though one is needed for the EE 8 version of the module.xml we can drop it from the EE 9 one. Spec API modules will have different module.xml files for EE 8 vs 9.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13663) Fix modules with dependency on javax.xml.rpc.api
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13663:
---------------------------------------
Summary: Fix modules with dependency on javax.xml.rpc.api
Key: WFLY-13663
URL: https://issues.redhat.com/browse/WFLY-13663
Project: WildFly
Issue Type: Task
Components: EJB, Transactions, Web Services
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 21.0.0.Beta1
The following modules have a dep on the javax.xml.rpc.api module. JAX-RPC has been pruned from EE 9 so in the EE9 variant of WildFly I want to avoid shipping that module. Task here is to confirm these dependencies are needed, and if not prune them. Then for anything remaining determine how to handle the dep (e.g. make it optional).
org.apache.ws.security
org.jboss.as.ejb3
org.jboss.as.webservices
org.jboss.narayana.rts
org.jboss.ws.common
javax.ejb.api
The javax.ejb.api one, the 4.0.0.RC2 version of jakarta.ejb:jakarta.ejb-api doesn't have any JAX-RPC dep so even if one is needed for the EE 8 version of the module.xml we can drop it from the EE 9 one. Spec API modules will have different module.xml files for EE 8 vs 9.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years