[JBoss JIRA] (SECURITY-573) Improve handling of IOException thrown from NegotiationAuthenticator
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-573?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-573:
--------------------------------------
Fix Version/s: Negotiation_2_1_7
(was: Negotiation_2_1_6)
> Improve handling of IOException thrown from NegotiationAuthenticator
> --------------------------------------------------------------------
>
> Key: SECURITY-573
> URL: https://issues.jboss.org/browse/SECURITY-573
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2.0.3.GA
> Environment: JBoss EPP 5.1.GA with SPNEGO support, JBoss Negotiation 2.0.3, commons-http-client 3.1 used as HTTP client
> Reporter: Marek Posolda
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_1_7
>
>
> Currently if IOException is thrown from NegotiationAuthenticator (For example from line 123 from statement: NegotiationMessage requestMessage = mf.createMessage(authTokenIS); )
> then this exception is never logged but it's catched and ignored in CoyoteAdapter.service. Result is that client receives response code 200 OK and emtpy HTTP response. And there is nothing in server log, which can be used to recognize error. So I need to debug if I want to find the real cause of IO issue.
> Example for simulating of this issue can be using of Kerberos OID instead of SPNEGO OID as described in Jira SECURITY-572
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WFLY-3281) Cannot call getOutputStream(), getWriter() already called
by Jakob Munih (JIRA)
[ https://issues.jboss.org/browse/WFLY-3281?page=com.atlassian.jira.plugin.... ]
Jakob Munih resolved WFLY-3281.
-------------------------------
Fix Version/s: 8.1.0.Final
Resolution: Done
With the last the update of CXF to 2.7.11 which resolves CXF-5620 in master, the exception has gone.
> Cannot call getOutputStream(), getWriter() already called
> ---------------------------------------------------------
>
> Key: WFLY-3281
> URL: https://issues.jboss.org/browse/WFLY-3281
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR1
> Environment: linux
> Reporter: Jakob Munih
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 8.1.0.Final
>
>
> Similar to WFL-1276 I got “UT005023: Exception handling request to /hsb/web-services/: java.lang.IllegalStateException: UT010005: Cannot call getOutputStream(), getWriter() already called” when accessing CXFNonSpringServlet servlet that shows all web services deployed with ApacheCamel 2.13.0. The exception is was not present in WF 8.0. Even with the exception the servlet renders all available service correctly.
> Servlet:
> {code}
> import com.parsek.hsb.commons.Hsb;
> import org.apache.cxf.Bus;
> import org.apache.cxf.transport.servlet.CXFNonSpringServlet;
> import javax.inject.Inject;
> import javax.servlet.ServletConfig;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> // reuse camel bus
> @WebServlet(value = "/web-services/*", name = "HsbWebServices", asyncSupported = true, loadOnStartup = 1)
> public class ExposeCxf extends CXFNonSpringServlet {
> @Hsb
> @Inject
> private Bus bus;
> @Override
> public void init(ServletConfig sc) throws ServletException {
> setBus(bus);
> super.init(sc);
> }
> }
> {code}
> Exception
> {noformat}
> 11:12:05,900 ERROR [io.undertow.request] (default task-11) UT005023: Exception handling request to /hsb/web-services/: java.lang.IllegalStateException: UT010005: Cannot call getOutputStream(), getWriter() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getOutputStream(HttpServletResponseImpl.java:283) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at org.apache.cxf.transport.servlet.servicelist.ServiceListGeneratorServlet.renderStyleSheet(ServiceListGeneratorServlet.java:174) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at org.apache.cxf.transport.servlet.servicelist.ServiceListGeneratorServlet.service(ServiceListGeneratorServlet.java:89) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:170) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:167) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) [cxf-rt-transports-http-2.7.10.jar:2.7.10]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.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.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {noformat}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Lin Gao <lgao(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from ASSIGNED to POST
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (AS7-1859) AS won't boot with sun jmx enabled
by Robb Greathouse (JIRA)
[ https://issues.jboss.org/browse/AS7-1859?page=com.atlassian.jira.plugin.s... ]
Robb Greathouse commented on AS7-1859:
--------------------------------------
Does anyone know if this one has been fixed in EAP?
> AS won't boot with sun jmx enabled
> ----------------------------------
>
> Key: AS7-1859
> URL: https://issues.jboss.org/browse/AS7-1859
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.1.0.Alpha1
> Environment: sun jdk6 windows 7 as-7.1.0.Alpha1
> Reporter: Dan Hanley
> Assignee: David Lloyd
>
> This appears to be a regression to https://issues.jboss.org/browse/JBAS-7427 in AS7.1
> > set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> > standalone.bat
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: c:\jboss-as-7.1.0.Alpha1-SNAPSHOT
> JAVA: C:\Program Files\Java\jdk1.6.0_22\bin\java
> JAVA_OPTS: -Dprogram.name=standalone.bat -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+UseParallelGC -XX:PermSize=6g -XX:MaxPermSize=6g -Xms512m
> -Xmx4g -Xss256k -Dhornetq.server-id=119 -Dsqs.queue.name=danQ -Duser.timezone=gmt -Djava.net.preferIPv4Stack=true -Djms.server=193.131.98.79 -Djboss.bind.address=193.131.98.79 -Djb
> oss.partition.name=dan-pc -Djboss.partition.udpGroup=79 -Dpublic.firewall.address=dan-pc -Xrunjdwp:transport=dt_socket,address=8788,server=y,suspend=n -Dcom.sun.management.jmxrem
> ote -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl -server
> ===============================================================================
> Listening for transport dt_socket at address: 8788
> Could not load Logmanager "org.jboss.logmanager.LogManager"
> java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at java.util.logging.LogManager$1.run(LogManager.java:168)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.<clinit>(LogManager.java:158)
> at java.util.logging.Logger.getLogger(Logger.java:273)
> at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57)
> at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:42)
> at sun.management.jmxremote.ConnectorBootstrap.<clinit>(ConnectorBootstrap.java:760)
> at sun.management.Agent.startAgent(Agent.java:135)
> at sun.management.Agent.startAgent(Agent.java:239)
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.jboss.as.server.Main.main(Main.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogMana
> ger")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> ... 7 more
> Heap
> PSYoungGen total 152896K, used 23619K [0x00000002aaaa0000, 0x00000002b5540000, 0x00000002ffff0000)
> eden space 131072K, 18% used [0x00000002aaaa0000,0x00000002ac1b0f30,0x00000002b2aa0000)
> from space 21824K, 0% used [0x00000002b3ff0000,0x00000002b3ff0000,0x00000002b5540000)
> to space 21824K, 0% used [0x00000002b2aa0000,0x00000002b2aa0000,0x00000002b3ff0000)
> PSOldGen total 349568K, used 0K [0x00000001ffff0000, 0x0000000215550000, 0x00000002aaaa0000)
> object space 349568K, 0% used [0x00000001ffff0000,0x00000001ffff0000,0x0000000215550000)
> PSPermGen total 6291456K, used 10763K [0x000000007fff0000, 0x00000001ffff0000, 0x00000001ffff0000)
> object space 6291456K, 0% used [0x000000007fff0000,0x0000000080a72d30,0x00000001ffff0000)
> Press any key to continue . . .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years