[JBoss JIRA] (WFCORE-668) Make the INFO logging from deprecated attributes configurable, also improve the message
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-668:
---------------------------------------
Summary: Make the INFO logging from deprecated attributes configurable, also improve the message
Key: WFCORE-668
URL: https://issues.jboss.org/browse/WFCORE-668
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.CR1
The INFO logging that AttributeDefinition generates when a deprecated attribute is used needs to be configurable, i.e. with a boolean flag so a dev can turn it off for attributes where it serves no purpose.
The logging only serves a purpose if an admin can take action to use some alternative config. If an attribute is deprecated only because in some future release it will go away, but there's no replacement now, the logging is just noise.
The log message itself should be improved:
1) Get rid of the ! at the end. It's not that exciting. ;)
2) Include the address of the resource
3) Point the user at the read-resource-description output from which they can learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4435) Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4435?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4435:
---------------------------------
Summary: Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added" (was: Mixed domain tests fail on infinispan/jgroups subsystems)
> Booting profile with infinispan/jgroups pre-3_0 subsystems fails with "Resource ... cannot be created until all ancestor resources have been added"
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4435
> URL: https://issues.jboss.org/browse/WFLY-4435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The same problem happens when attempting to use 2_0 version of these subsystems in current configuration.
> {noformat}
> [Host Controller] [0m[0m15:33:41,155 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[0m15:33:41,161 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-clustered-sfsb-cache is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[31m15:33:41,174 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([[0m
> [Host Controller] [31m ("profile" => "full-ha"),[0m
> [Host Controller] [31m ("subsystem" => "jgroups"),[0m
> [Host Controller] [31m ("channel" => "server")[0m
> [Host Controller] [31m]) - failure description: "WFLYCTL0175: Resource [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\")[0m
> [Host Controller] [31m] does not exist; a resource at address [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\"),[0m
> [Host Controller] [31m (\"channel\" => \"server\")[0m
> [Host Controller] [31m] cannot be created until all ancestor resources have been added"[0m
> [Host Controller] [31m[0m[31m15:33:41,183 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.[0m
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
by Joseph Hwang (JIRA)
[ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.... ]
Joseph Hwang commented on WFLY-3659:
------------------------------------
You mean I have to make another jira about this issue to Elytron? and have to wait again until fix version WildFly 10?
> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3659
> URL: https://issues.jboss.org/browse/WFLY-3659
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Joseph Hwang
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> == web.xml
> <security-role>
> <role-name>administrator</role-name>
> </security-role>
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
> <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
> <module-option name="principalsQuery" value="select password from credential where uid=?"/>
> <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="RFC2617"/>
> <module-option name="hashUserPassword" value="false"/>
> <module-option name="hashStorePassword" value="true"/>
> <module-option name="passwordIsA1Hash" value="true"/>
> <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
> <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
> </login-module>
> </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> String userName="admin";
> String realmName="WildFly8DigestRealm";
> String password="passwd123";
> String clearTextPassword=userName+":"+realmName+":"+password;
> String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword);
> System.out.println("clearTextPassword: "+clearTextPassword);
> System.out.println("hashedPassword: "+hashedPassword);
> }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
> at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> ... 49 more
> This cofiguration worked well in JBoss AS 7.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04
by Dennis Gesker (JIRA)
[ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.... ]
Dennis Gesker updated WFLY-4570:
--------------------------------
Steps to Reproduce:
Set variables in JBOSS_HOME/bin/init.d/wildfly.conf
ln -s JBOSS_HOME/bin/init.d/wildfly.conf /etc/default/wildfly
ln -s JBOSS_HOME/bin/init.d/wildfly-init-debian.sh /etc/init.d/wildfly
cd /etc/init.d
update-rc.d wildfly defaults
permissions and user/group are of course set to wildfly.wildfly
was:
Set variables in JBOSS_HOME/bin/init.d/wildfly.conf
ln -s JBOSS_HOME/bin/init.d/wildfly.conf /etc/default/wildfly
JBOSS_HOME/bin/init.d/wildfly-init-debian.sh /etc/init.d/wildfly
cd /etc/init.d
update-rc.d wildfly defaults
permissions and user/group are of course set to wildfly.wildfly
> wildfly-init-debian.sh fails on Ubuntu 15.04
> --------------------------------------------
>
> Key: WFLY-4570
> URL: https://issues.jboss.org/browse/WFLY-4570
> Project: WildFly
> Issue Type: Bug
> Components: ConfigAdmin
> Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
> Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
> Reporter: Dennis Gesker
> Assignee: Thomas Diesler
> Priority: Minor
> Fix For: 9.0.0.CR1
>
>
> Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
> Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
> Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04
by Dennis Gesker (JIRA)
Dennis Gesker created WFLY-4570:
-----------------------------------
Summary: wildfly-init-debian.sh fails on Ubuntu 15.04
Key: WFLY-4570
URL: https://issues.jboss.org/browse/WFLY-4570
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
Reporter: Dennis Gesker
Assignee: Thomas Diesler
Priority: Minor
Fix For: 9.0.0.CR1
Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S edited comment on WFLY-4561 at 4/28/15 3:57 PM:
-------------------------------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when an InputStream is closed with unread data.
was (Author: marks1900):
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S edited comment on WFLY-4561 at 4/28/15 3:57 PM:
-------------------------------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning when a InputStream is closed with unread data.
was (Author: marks1900):
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning that when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error
by Mark S (JIRA)
[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ]
Mark S commented on WFLY-4561:
------------------------------
I agree that calling close should be idempotent (i.e. Can be called multiple times with the same effect ). Yeah it was my mistake, I guess I was expecting at least a warning that when a InputStream is closed with unread data.
> Servlet Nonblocking I/O Suppressed InputStream Closed Error
> -----------------------------------------------------------
>
> Key: WFLY-4561
> URL: https://issues.jboss.org/browse/WFLY-4561
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Mark S
> Assignee: Stuart Douglas
> Attachments: AsyncIOServletTest.java
>
>
> Created a Nonblocking I/O Servlet by following JEE Tutorial example here:
> https://docs.oracle.com/javaee/7/tutorial/servlets013.htm
> Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement.
> {code}
> final ServletInputStream input = request.getInputStream();
> {code}
> Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been.
> --
> I have added the relevant source code to reproduce my situation. Please see attached code.
> In the attached source, I added an AsyncListener to monitor the life cycle.
> h4. Case 1
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output:
> {code}
> 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17
> 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3
> {code}
> Client Response:
> {code}
> <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> {code}
> h4. Case 2
> Client Request:
> {code}
> curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo
> {code}
> The handleRequestAsPerJeeTutorial method will give the following output:
> {code}
> 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..)
> 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..)
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable()
> 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead()
> 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed
> {code}
> Client Response:
> {code}
> ...the response...
> {code}
> ----
> It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-313:
------------------------------------
We do have some extra info on OperationDefinition that tells us what are parameters and what are reply attributes.
And it also know how to handle deprecated attributes.
> DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-313
> URL: https://issues.jboss.org/browse/WFCORE-313
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription.
> A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years