April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-759) GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling rules that contain line with only spaces in LHS

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-759: ------------------------------------ Summary: GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling rules that contain line with only spaces in LHS Key: DROOLS-759 URL: https://issues.jboss.org/browse/DROOLS-759 Project: Drools Issue Type: Bug Reporter: Tibor Zimányi Assignee: Michael Anstis Priority: Minor GuidedDecisionTreeModelUnmarshallingVisitor don't support rules that contain lines with only spaces in LHS. These empty lines should be thrown away in preprocessing in RuleModelDRLPersistenceImpl. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-608) Using ? as control character in .inputrc causes CLI to terminate immediately.

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-608?page=com.atlassian.jira.plugin... ] Bartosz Baranowski reopened WFCORE-608: --------------------------------------- > Using ? as control character in .inputrc causes CLI to terminate immediately. > ------------------------------------------------------------------------------ > > Key: WFCORE-608 > URL: https://issues.jboss.org/browse/WFCORE-608 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Environment: Linux > Reporter: Jay Kumar SenSharma > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Beta1 > > > - When using *[wildfly-8.2.0.Final]* When user has a '.inputrc' in the user home directory with the following content: > {code} > # Control characters > "\C-?": backward-delete-char > {code} > - The it fails with the the following Stack Trace: > {code} > ./jboss-cli.sh > java.lang.RuntimeException: ERROR parsing ? keys to aesh. Check your inputrc. > at org.jboss.aesh.edit.mapper.KeyMapper.convertRandomControlKeys(KeyMapper.java:161) > at org.jboss.aesh.edit.mapper.KeyMapper.mapRandomKeys(KeyMapper.java:138) > at org.jboss.aesh.edit.mapper.KeyMapper.mapKeys(KeyMapper.java:108) > at org.jboss.aesh.edit.mapper.KeyMapper.mapQuoteKeys(KeyMapper.java:49) > at org.jboss.aesh.console.Config.parseInputrc(Config.java:127) > at org.jboss.aesh.console.Console.reset(Console.java:150) > at org.jboss.aesh.console.Console.<init>(Console.java:105) > at org.jboss.aesh.console.Console.<init>(Console.java:101) > at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85) > at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78) > at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {code} > - Expectation is that CLI should not have terminated suddenly rather the exception should have been handled in a proper way. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-608) Using ? as control character in .inputrc causes CLI to terminate immediately.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-608?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-608: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1203997|https://bugzilla.redhat.com/show_bug.cgi?id=1203997] from NEW to ASSIGNED > Using ? as control character in .inputrc causes CLI to terminate immediately. > ------------------------------------------------------------------------------ > > Key: WFCORE-608 > URL: https://issues.jboss.org/browse/WFCORE-608 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Environment: Linux > Reporter: Jay Kumar SenSharma > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Beta1 > > > - When using *[wildfly-8.2.0.Final]* When user has a '.inputrc' in the user home directory with the following content: > {code} > # Control characters > "\C-?": backward-delete-char > {code} > - The it fails with the the following Stack Trace: > {code} > ./jboss-cli.sh > java.lang.RuntimeException: ERROR parsing ? keys to aesh. Check your inputrc. > at org.jboss.aesh.edit.mapper.KeyMapper.convertRandomControlKeys(KeyMapper.java:161) > at org.jboss.aesh.edit.mapper.KeyMapper.mapRandomKeys(KeyMapper.java:138) > at org.jboss.aesh.edit.mapper.KeyMapper.mapKeys(KeyMapper.java:108) > at org.jboss.aesh.edit.mapper.KeyMapper.mapQuoteKeys(KeyMapper.java:49) > at org.jboss.aesh.console.Config.parseInputrc(Config.java:127) > at org.jboss.aesh.console.Console.reset(Console.java:150) > at org.jboss.aesh.console.Console.<init>(Console.java:105) > at org.jboss.aesh.console.Console.<init>(Console.java:101) > at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85) > at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78) > at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {code} > - Expectation is that CLI should not have terminated suddenly rather the exception should have been handled in a proper way. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4464) JDBC driver module-slot is not persisted in domain mode

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-4464?page=com.atlassian.jira.plugin.... ] Lin Gao reassigned WFLY-4464: ----------------------------- Assignee: Lin Gao (was: Jesper Pedersen) > JDBC driver module-slot is not persisted in domain mode > ------------------------------------------------------- > > Key: WFLY-4464 > URL: https://issues.jboss.org/browse/WFLY-4464 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.2.0.Final > Reporter: Lin Gao > Assignee: Lin Gao > > The module-slot of jdbc-driver is NOT persisted in domain mode, but it is persisted in standalone mode. > After debugging, I found that the performRuntime() method of JdbcDriverAdd.java is not called in domain mode, but is called in standalone mode. > For more information about the issue, please refer to the thread: https://developer.jboss.org/thread/253654 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-65) Filesystem deployment scanner deployment failure removes other scanners ' deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-65?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFCORE-65: -------------------------------------- Assignee: Brian Stansberry > Filesystem deployment scanner deployment failure removes other scanners ' deployments > ------------------------------------------------------------------------------------- > > Key: WFCORE-65 > URL: https://issues.jboss.org/browse/WFCORE-65 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: ehsavoie Hugonnet > Assignee: Brian Stansberry > > There is no way to associate a deployment to a specific scanner thus if one deployment fails for a scanner during startup all deployments not persistent will be removed -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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: ----------------------------------------- https://github.com/bstansberry/wildfly-core/commits/WFCORE-65 has a fix for this. I haven't added any test cases but I believe it should correct the problem. > 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)

11 years, 1 month

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

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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 April 2015