[JBoss JIRA] (JBWEB-314) FormAuthenticator duplicates original request GET parameters
by Dominik Pospisil (JIRA)
[ https://issues.jboss.org/browse/JBWEB-314?page=com.atlassian.jira.plugin.... ]
Dominik Pospisil updated JBWEB-314:
-----------------------------------
Attachment: FormAuthenticator.diff
Attaching proposed patch.
> FormAuthenticator duplicates original request GET parameters
> ------------------------------------------------------------
>
> Key: JBWEB-314
> URL: https://issues.jboss.org/browse/JBWEB-314
> Project: JBoss Web
> Issue Type: Bug
> Reporter: Dominik Pospisil
> Assignee: Remy Maucherat
> Attachments: FormAuthenticator.diff
>
>
> The FormAuthenticator duplicates original request GET parameters. This is a regression since rev. 2320.
> The FormAuth does saved.addParameter(name, val) which results in parameter value stored twice.
> request.getParameter(String name) retutns the original value which is fine
> but request.getParameterValues(String name) returns String[] {val,val} incorrectly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JBWEB-314) FormAuthenticator duplicates original request GET parameters
by Dominik Pospisil (JIRA)
Dominik Pospisil created JBWEB-314:
--------------------------------------
Summary: FormAuthenticator duplicates original request GET parameters
Key: JBWEB-314
URL: https://issues.jboss.org/browse/JBWEB-314
Project: JBoss Web
Issue Type: Bug
Reporter: Dominik Pospisil
Assignee: Remy Maucherat
The FormAuthenticator duplicates original request GET parameters. This is a regression since rev. 2320.
The FormAuth does saved.addParameter(name, val) which results in parameter value stored twice.
request.getParameter(String name) retutns the original value which is fine
but request.getParameterValues(String name) returns String[] {val,val} incorrectly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-402) A wrapper KeyStore that can filter by alias
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-402?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-402:
------------------------------------
Assignee: Darran Lofthouse
> A wrapper KeyStore that can filter by alias
> -------------------------------------------
>
> Key: ELY-402
> URL: https://issues.jboss.org/browse/ELY-402
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta4
>
>
> A common request is that when a server is configured for SSL the alias to use from the KeyStore can be specified - this can be a little short sighted as a huge advantage of multiple entries in a single KeyStore is that different entries can be used depending on the selected cipher suite.
> A better option may be to add alias filtering so a wrapper KeyStore can still make a number of underlying entries available.
> Alias filtering is better handled at the KeyStore level as the KeyManager should be performing additional checks to ensure the keys and signatures are compatible with the current cipher suite.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-4682:
-------------------------------------
Issue Type: Enhancement (was: Bug)
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Enhancement
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months