April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-118) Support suppressed exceptions in log formatting

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-118?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-118: ------------------------------------ Assignee: James Perkins > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-118 > URL: https://issues.jboss.org/browse/LOGMGR-118 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-118) Support suppressed exceptions in log formatting

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-118?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-118: -------------------------------------- Since this will be part of the formatter with the pattern formatter should we allow for a recursive depth? For example a value of 1 would only do {{Throwable.getSuppressed()}} on the cause. A value of 2 would be would be the cause and one level deep on each suppressed throwable. Maybe 0 would be no suppressed messages and anything less than 0 means exhaustively recurse. > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-118 > URL: https://issues.jboss.org/browse/LOGMGR-118 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4491) Add ability to disable security if not required

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-4491: ------------------------------------ Summary: Add ability to disable security if not required Key: WFLY-4491 URL: https://issues.jboss.org/browse/WFLY-4491 Project: WildFly Issue Type: Feature Request Components: Security Reporter: Stuart Douglas Assignee: Darran Lofthouse At the moment Web and EJB deployments will always attempt to set up a security context, even if a deployment does not use security or the security subsystem is not installed. If the subsystem is removed or excluded via jboss-deployment-structure.xml then no security related interceptors / setup should be used, in order to improve performance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4491) Add ability to disable security if not required

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4491?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-4491: ------------------------------------ Assignee: Stuart Douglas (was: Darran Lofthouse) > Add ability to disable security if not required > ----------------------------------------------- > > Key: WFLY-4491 > URL: https://issues.jboss.org/browse/WFLY-4491 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > At the moment Web and EJB deployments will always attempt to set up a security context, even if a deployment does not use security or the security subsystem is not installed. > If the subsystem is removed or excluded via jboss-deployment-structure.xml then no security related interceptors / setup should be used, in order to improve performance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBWEB-312?page=com.atlassian.jira.plugin.... ] Aaron Ogburn closed JBWEB-312. ------------------------------ Resolution: Done > response.setBufferSize() has no effect when using the response writer > --------------------------------------------------------------------- > > Key: JBWEB-312 > URL: https://issues.jboss.org/browse/JBWEB-312 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > > This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 > When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBWEB-312?page=com.atlassian.jira.plugin.... ] Aaron Ogburn reassigned JBWEB-312: ---------------------------------- Assignee: Aaron Ogburn (was: Remy Maucherat) > response.setBufferSize() has no effect when using the response writer > --------------------------------------------------------------------- > > Key: JBWEB-312 > URL: https://issues.jboss.org/browse/JBWEB-312 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > > This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 > When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBWEB-312?page=com.atlassian.jira.plugin.... ] Aaron Ogburn commented on JBWEB-312: ------------------------------------ 7.5.x: r2603 > response.setBufferSize() has no effect when using the response writer > --------------------------------------------------------------------- > > Key: JBWEB-312 > URL: https://issues.jboss.org/browse/JBWEB-312 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > > This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 > When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Aaron Ogburn (JIRA)

Aaron Ogburn created JBWEB-312: ---------------------------------- Summary: response.setBufferSize() has no effect when using the response writer Key: JBWEB-312 URL: https://issues.jboss.org/browse/JBWEB-312 Project: JBoss Web Issue Type: Bug Affects Versions: JBossWeb-7.5.0.GA Reporter: Aaron Ogburn Assignee: Remy Maucherat This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-623) ModelControllerClient.Factory lacks some variants

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-623?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-623: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/600 (was: https://github.com/wildfly/wildfly-core/pull/593, https://github.com/wildfly/wildfly-core/pull/600) > ModelControllerClient.Factory lacks some variants > ------------------------------------------------- > > Key: WFCORE-623 > URL: https://issues.jboss.org/browse/WFCORE-623 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta2 > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta4 > > > In the {{ModelControllerClient.Factory}} class, each factory method in fact has two varians: with a {{protocol}} as a first parameter, and without it. There are two exceptions -- two methods are lacking a {{protocol}}-less variant: > - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions)}} > - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions, final String clientBindAddress)}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-632: ----------------------------------------- I might do it this week; if not next. It looks fairly straightforward. > Subsystem deployment undeployed at startup > ------------------------------------------ > > Key: WFCORE-632 > URL: https://issues.jboss.org/browse/WFCORE-632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta3, 1.0.0.Beta4 > Reporter: Stan Silvert > Assignee: Brian Stansberry > Fix For: 1.0.0.CR1 > > > {noformat} > @BrianStansberry The "mixed approach" doesn't seem to work any more. https://developer.jboss.org/wiki/ExtendingAS7 > @BrianStansberry I'm using this to deploy keycloak WAR from the subsystem. > @BrianStansberry As soon as the server is started, something is calling stopService() on the Keycloak WAR. > Tomaz Cerar > 1:15 PM > @StanSilvert are you still working on AS7? https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8 > Stan Silvert > 1:16 PM > @ctomc No. this is WildFly 9. It still works on WildFly 8. > Tomaz Cerar > 1:16 PM > ah the war deployment, that could be regression > Brian Stansberry > 1:17 PM > @ctomc how so? > Stan Silvert > 1:17 PM > FYI. I did a Thread.dumpStack() and got this: > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) java.lang.Exception: Stack trace > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.dumpStack(Thread.java:1329) > 13:11:35,174 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:168) > 13:11:35,176 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java: > 113) > 13:11:35,179 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > 13:11:35,181 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.Serv > iceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > 13:11:35,184 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > 13:11:35,186 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:11:35,188 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:11:35,190 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745) > Hide full text > Tomaz Cerar > 1:18 PM > @BrianStansberry just reffering that war deployment from subsystem should still work > 1:19 PM > Jason Greene joined the room. > Tomaz Cerar > 1:19 PM > @StanSilvert what happens? as that thread dump makes no sense > Stan Silvert > 1:21 PM > http://pastebin.com/xQ2DNzEe > The WAR is simply undeployed as soon as WildFly finishes startup. > Brian Stansberry > 1:22 PM > @StanSilvert can you give me a link to your code that's doing the deploy stuff? > Stan Silvert > 1:22 PM > just a sec > Stan Silvert > 1:24 PM > https://github.com/keycloak/keycloak/tree/master/integration > The code that creates the operation is https://github.com/keycloak/keycloak/blob/master/integration > AuthServerUtil ^^^ > click on the second link > 1:27 PM > Darran Lofthouse left the room. > Brian Stansberry > 1:27 PM > @StanSilvert are you doing overlay stuff? I see some code there re: overlays > Stan Silvert > 1:28 PM > Yes, but not in this instance. > Brian Stansberry > 1:28 PM > ok. I'm asking just because that would add more complexity, better scope for some service dependency going missing, triggering stop > Stan Silvert > 1:29 PM > For this simple case there are no overlays. > Brian Stansberry > 1:29 PM > @StanSilvert interesting, your log looks like it's a true undeploy op, not just a service stop > Tomaz Cerar > 1:30 PM > @BrianStansberry should we use 6.x.0 or 6.x.latest for tranformers testing? > Tomaz Cerar goes get some diner > Stan Silvert > 1:30 PM > @BrianStansberry If that's the case then maybe some condition is triggering my own undeploy operation. > @BrianStansberry I'll look into that and see what I find. > Brian Stansberry > 1:31 PM > @ctomc 6.x.0 is ok by me; chasing CPs is too much hassle > @StanSilvert note this: > 13:11:35,294 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "main-auth-server.war" (runtime-name: "main-auth-server.war") > the thread -- DeploymentScanner-threads - 1 > looks like your deployment is exposed to the scanner? > oh, here's a guess! > the scanner sees "persistent" => false and treats it as under scanner control > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015