[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
[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
[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
[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