[JBoss JIRA] (WFLY-3737) JavaEE appclient "Main" replace "System.in"
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-3737:
------------------------------------
Summary: JavaEE appclient "Main" replace "System.in"
Key: WFLY-3737
URL: https://issues.jboss.org/browse/WFLY-3737
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Application Client
Affects Versions: 8.1.0.Final
Reporter: Wolfgang Knauf
Assignee: Stuart Douglas
"org.jboss.as.appclient.subsystem.Main.main" replaces System.in with a "NullInputStream" and thus you cannot use it to read user inputs.
I don't whether this is intentional, but it sounds like a bug to me
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-56) Improve 'cd' behavior in batch mode
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-56?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky moved WFLY-2946 to WFCORE-56:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-56 (was: WFLY-2946)
Affects Version/s: (was: 8.0.0.Final)
Component/s: CLI
(was: CLI)
> Improve 'cd' behavior in batch mode
> -----------------------------------
>
> Key: WFCORE-56
> URL: https://issues.jboss.org/browse/WFCORE-56
> Project: WildFly Core
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
>
> See discussion at https://community.jboss.org/message/858108#858108 for background.
> The problem is the 'cd' behavior discussed in my comment. A 'cd' in batch mode seems to have triggered the CLI validating the location (or some other op against the address), which fails since the previous batch step that created the location hasn't executed.
> Would it be better to simply accept the address in batch mode, or somehow be a bit smarter?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-55) bad error message for invalid <resource-root> path in module.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-55?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-3571 to WFCORE-55:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-55 (was: WFLY-3571)
Component/s: Domain Management
(was: Domain Management)
> bad error message for invalid <resource-root> path in module.xml
> ----------------------------------------------------------------
>
> Key: WFCORE-55
> URL: https://issues.jboss.org/browse/WFCORE-55
> Project: WildFly Core
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Karl Pietrzak
> Assignee: Brian Stansberry
> Priority: Minor
>
> h3. What
> If you have a typo in your path for your module.xml for a JDBC driver, e.g.,
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.0" name="com.mysql">
> <resources>
> <resource-root path="DOES.NOT.EXIST.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
> WF just says:
> {noformat}
> 16:22:26,770 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "com.mysql")
> {noformat}
> h3. Why
> This is not very informative, unfortunately. Maybe it's logged as level DEBUG instead of WARN? If someone points me to the name of the class that handles this kind of thing, I can submit a patch/pull request.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3662) CLI: non-batchable commands appearing in control flow statements executed regardless of condition
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3662?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFLY-3662.
-------------------------------------
Resolution: Done
This has been merged into the master.
> CLI: non-batchable commands appearing in control flow statements executed regardless of condition
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-3662
> URL: https://issues.jboss.org/browse/WFLY-3662
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Reporter: Stanley Hillner
> Assignee: Alexey Loubyansky
> Priority: Critical
> Labels: cli, command, command-line, script
> Fix For: 9.0.0.Beta1
>
>
> The CLI control flows, such as if-then-else, are not working for CLI commands, such as echo or module. Using commands in control flows results in the strange behavior that these commands are executed in each case without respecting to what the if-statement evaluated.
> I am trying to customize a fresh wildfly server with some modules and settings for our development process. I decided to add modules using a CLI script that gets executed by maven, but when the script declares the following the module command in the 'then' block is executed in each case:
> {noformat}
> if (outcome == failed) of /core-service=module-loading:list-resource-loader-paths(module=oracle.jdbcaq)
> module add --name=oracle.jdbcaq ...
> end-if
> ...
> {noformat}
> I've also verified this behavior with another structure that just checks a property and echos something and both echos were executed:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> /system-property=x:read-attribute(name=value)
> else
> echo "Else block"
> /system-property=x:read-attribute(name=value)
> end-if
> {noformat}
> The next thing is that if you just put echos into the if and else blocks, the CLI processor complains about an empty if-block. Try this one:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> else
> echo "Else block"
> end-if
> {noformat}
> This behavior has also been observed by other users (see the forum reference) and for me it is critical to our setup since the only alternative would be copying modules manually to the modules folder. Furthermore, there might be other commands required for us to adapt the standalone configuration that need to be nested in an if-statement.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3571) bad error message for invalid <resource-root> path in module.xml
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3571?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-3571:
----------------------------------------
Assignee: Bartosz Baranowski (was: Brian Stansberry)
> bad error message for invalid <resource-root> path in module.xml
> ----------------------------------------------------------------
>
> Key: WFLY-3571
> URL: https://issues.jboss.org/browse/WFLY-3571
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Karl Pietrzak
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> h3. What
> If you have a typo in your path for your module.xml for a JDBC driver, e.g.,
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.0" name="com.mysql">
> <resources>
> <resource-root path="DOES.NOT.EXIST.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
> WF just says:
> {noformat}
> 16:22:26,770 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "com.mysql")
> {noformat}
> h3. Why
> This is not very informative, unfortunately. Maybe it's logged as level DEBUG instead of WARN? If someone points me to the name of the class that handles this kind of thing, I can submit a patch/pull request.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3500) JMX - Non string attributes dont work well with expressions & min/max
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3500?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-3500:
----------------------------------------
Assignee: Bartosz Baranowski (was: Kabir Khan)
> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
> Key: WFLY-3500
> URL: https://issues.jboss.org/browse/WFLY-3500
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMX
> Reporter: Tomaz Cerar
> Assignee: Bartosz Baranowski
> Priority: Minor
> Fix For: 9.0.0.CR1
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3248) Clustering Extended testsuite is broken
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3248:
---------------------------------
Description: What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests. (was: What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI.)
> Clustering Extended testsuite is broken
> ---------------------------------------
>
> Key: WFLY-3248
> URL: https://issues.jboss.org/browse/WFLY-3248
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Test Suite
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3248) Clustering Extended testsuite is broken
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3248:
---------------------------------
Summary: Clustering Extended testsuite is broken (was: Removing ViewChangeListener* broke the extended clustering testsuite)
> Clustering Extended testsuite is broken
> ---------------------------------------
>
> Key: WFLY-3248
> URL: https://issues.jboss.org/browse/WFLY-3248
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Test Suite
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
> The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months