August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1697) Not displaying all possibilities for FS completion breaks from the command

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1697?page=com.atlassian.jira.plugi... ] Petr Kremensky moved JBEAP-5557 to WFCORE-1697: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1697 (was: JBEAP-5557) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: 3.0.0.Alpha4 (was: 7.1.0.DR2) > Not displaying all possibilities for FS completion breaks from the command > -------------------------------------------------------------------------- > > Key: WFCORE-1697 > URL: https://issues.jboss.org/browse/WFCORE-1697 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha4 > Reporter: Petr Kremensky > Assignee: Alexey Loubyansky > > Terminal gets cleared in case user select not to display all possibilities during FS completion. > *my use-case* > {noformat} > [disconnected /] module add --name=org.wildfly.extension.blocker-test > --dependencies=org.jboss.staxmapper,org.jboss.as.controller,org.jboss.msc > --resources=~/help/test-extension.jar --module-root-dir=../../../<TAB> > Display all 103 possibilities? (y or n)<n> > [disconnected /] > {noformat} > *reproduce* > _actual_ > {noformat} > [disconnected /] patch apply /etc/<TAB> > Display all 299 possibilities? (y or n)<n> > [disconnected /] > {noformat} > _expected_ > {noformat} > [disconnected /] patch apply /etc/<TAB> > Display all 299 possibilities? (y or n)<n> > [disconnected /] patch apply /etc/ > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-632: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1271673|https://bugzilla.redhat.com/show_bug.cgi?id=1271673] from POST to MODIFIED > 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 > Labels: affects_elytron > Fix For: 1.0.0.Beta4 > > > {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.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-127) Module naming does does not support slots

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-127?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-127: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1283482|https://bugzilla.redhat.com/show_bug.cgi?id=1283482] from MODIFIED to ON_QA > Module naming does does not support slots > ----------------------------------------- > > Key: LOGMGR-127 > URL: https://issues.jboss.org/browse/LOGMGR-127 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Livingston > Assignee: James Livingston > Fix For: 1.5.6.Final, 2.0.4.Final, 2.1.0.Beta1 > > > AbstractPropertyConfiguration$ModuleFinder uses ModuleIdentifier.create() rather than fromString(), which means it does not support specifying the slot via "module:slot" and can only use the main slot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-123?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-123: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295665|https://bugzilla.redhat.com/show_bug.cgi?id=1295665] from MODIFIED to ON_QA > TCP reconnect will only attempt to reconnect once > ------------------------------------------------- > > Key: LOGMGR-123 > URL: https://issues.jboss.org/browse/LOGMGR-123 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.2.Final, 2.1.0.Beta1 > > > The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6853) Picketlink does not return SessionIndex in LogoutRequest

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6853?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6853: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1353338|https://bugzilla.redhat.com/show_bug.cgi?id=1353338] from MODIFIED to ON_QA > Picketlink does not return SessionIndex in LogoutRequest > -------------------------------------------------------- > > Key: WFLY-6853 > URL: https://issues.jboss.org/browse/WFLY-6853 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Vlado Pakan > Assignee: Vlado Pakan > > When logged out from application SAML logout message does not contain SessionIndex tag. > See referenced bugzilla for more information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-125) Log rotation fails on Windows if target already exists

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-125?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-125: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1274572|https://bugzilla.redhat.com/show_bug.cgi?id=1274572] from MODIFIED to ON_QA > Log rotation fails on Windows if target already exists > ------------------------------------------------------ > > Key: LOGMGR-125 > URL: https://issues.jboss.org/browse/LOGMGR-125 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Livingston > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.4.Final, 2.1.0.Beta1 > > > PeriodicRotatingFileHandler (and others) use File.renameTo() to rename the file. That method is documented as having many implementation-defined aspects, see http://docs.oracle.com/javase/7/docs/api/java/io/File.html#renameTo%28jav... > One that can be a problem is that on Windows, it will fail if the target file already exists. If you use a ".dd" suffix, this will occur when it rolls over to a new month. It has rarely been a problem, since most people use the year month and day so they are unique. Files.move() can replace existing files, so may be better, and some of the costs of that are likely not to be a problem with how it is using here. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-123?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-123: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295660|https://bugzilla.redhat.com/show_bug.cgi?id=1295660] from MODIFIED to ON_QA > TCP reconnect will only attempt to reconnect once > ------------------------------------------------- > > Key: LOGMGR-123 > URL: https://issues.jboss.org/browse/LOGMGR-123 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.2.Final, 2.1.0.Beta1 > > > The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4316) InvalidBytecodeException when an EJB local interface declares static method

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4316?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4316: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1346242|https://bugzilla.redhat.com/show_bug.cgi?id=1346242] from MODIFIED to ON_QA > InvalidBytecodeException when an EJB local interface declares static method > --------------------------------------------------------------------------- > > Key: WFLY-4316 > URL: https://issues.jboss.org/browse/WFLY-4316 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 9.0.0.Beta1 > > > {noformat} > Caused by: org.jboss.classfilewriter.InvalidBytecodeException: Cannot load variable at 1. Local Variables: Local Variables: [StackEntry [descriptor=Ljava/lang/String;, type=OBJECT]] > at org.jboss.classfilewriter.code.CodeAttribute.aload(CodeAttribute.java:185) > at org.jboss.invocation.proxy.ProxyFactory$ProxyMethodBodyCreator.overrideMethod(ProxyFactory.java:150) > at org.jboss.invocation.proxy.AbstractSubclassFactory.overrideMethod(AbstractSubclassFactory.java:106) > at org.jboss.invocation.proxy.AbstractSubclassFactory.addInterface(AbstractSubclassFactory.java:363) > at org.jboss.invocation.proxy.ProxyFactory.generateClass(ProxyFactory.java:286) > at org.jboss.invocation.proxy.AbstractClassFactory.buildClassDefinition(AbstractClassFactory.java:207) > at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:160) > at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:150) > at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$3.configure(StatelessComponentDescription.java:150) > at org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:68) > at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81) > ... 6 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2800) Re-invoking InterceptorContext.proceed() throws CannotProceedException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2800?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2800: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1360851|https://bugzilla.redhat.com/show_bug.cgi?id=1360851] from MODIFIED to ON_QA > Re-invoking InterceptorContext.proceed() throws CannotProceedException > ---------------------------------------------------------------------- > > Key: WFLY-2800 > URL: https://issues.jboss.org/browse/WFLY-2800 > Project: WildFly > Issue Type: Bug > Reporter: Eric van der Maarel > Assignee: David Lloyd > Fix For: 8.0.0.Final > > > When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown. > This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-122: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295657|https://bugzilla.redhat.com/show_bug.cgi?id=1295657] from MODIFIED to ON_QA > Syslog handler is not generating correct timestamp format > --------------------------------------------------------- > > Key: LOGMGR-122 > URL: https://issues.jboss.org/browse/LOGMGR-122 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 2.0.0.Final > Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6 > Reporter: Ricardo Kagawa > Assignee: James Perkins > Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1 > > > The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October. > Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010"). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016