[JBoss JIRA] (WFLY-4339) NPE when deployment contains a *-ds.xml in domain
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-4339?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-4339:
-------------------------------------
Assignee: Lin Gao (was: Stefano Maestri)
> NPE when deployment contains a *-ds.xml in domain
> -------------------------------------------------
>
> Key: WFLY-4339
> URL: https://issues.jboss.org/browse/WFLY-4339
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: James Perkins
> Assignee: Lin Gao
> Fix For: 9.0.0.CR1
>
>
> If you build the [kitchen-sink quickstart|https://github.com/wildfly/quickstart/tree/master/kitchensink] and attempt to deploy to domain servers you'll see the following error. Same deployment works fine in standalone.
> {code}
> [Server:server-one] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-two] at java.lang.Thread.run(Thread.java:745)
> [Server:server-two] Caused by: java.lang.NullPointerException
> [Server:server-two] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-two] ... 5 more
> [Server:server-two]
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-one] ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar edited comment on WFCORE-626 at 4/9/15 7:35 AM:
------------------------------------------------------------
Looking bit further into this, the fix that was done is not completely correct.
as *get-* operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
was (Author: ctomc):
Looking bit further into this, the fix that was done is not completely correct.
as "get-*" operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-626:
------------------------------------
Looking bit further into this, the fix that was done is not completely correct.
as "get-*" operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[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)
9 years, 9 months
[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)
9 years, 9 months
[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)
9 years, 9 months