February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3016) Prevent NullPointerException in JDR CommandLineMain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3016: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1069850|https://bugzilla.redhat.com/show_bug.cgi?id=1069850] from NEW to POST > Prevent NullPointerException in JDR CommandLineMain > --------------------------------------------------- > > Key: WFLY-3016 > URL: https://issues.jboss.org/browse/WFLY-3016 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDR > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3016) Prevent NullPointerException in JDR CommandLineMain

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.... ] Brad Maxwell commented on WFLY-3016: ------------------------------------ Move the prints into the try { } since if standaloneCollect throws an exception, the response object will be null > Prevent NullPointerException in JDR CommandLineMain > --------------------------------------------------- > > Key: WFLY-3016 > URL: https://issues.jboss.org/browse/WFLY-3016 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDR > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3016) Prevent NullPointerException in JDR CommandLineMain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3016: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1069850 > Prevent NullPointerException in JDR CommandLineMain > --------------------------------------------------- > > Key: WFLY-3016 > URL: https://issues.jboss.org/browse/WFLY-3016 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDR > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3016) Prevent NullPointerException in JDR CommandLineMain

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-3016: ---------------------------------- Summary: Prevent NullPointerException in JDR CommandLineMain Key: WFLY-3016 URL: https://issues.jboss.org/browse/WFLY-3016 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JDR Affects Versions: 8.0.0.Final Reporter: Brad Maxwell Assignee: Brad Maxwell -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2919) PostgreSQL check-valid-connection-sql doesn't work

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2919?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed WFLY-2919. --------------------------------- Resolution: Rejected Please, use forum for questions. Use <validate-on-match>true</validate-on-match> > PostgreSQL check-valid-connection-sql doesn't work > -------------------------------------------------- > > Key: WFLY-2919 > URL: https://issues.jboss.org/browse/WFLY-2919 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Environment: Windows 7, PostgreSQL 9.3beta2, PostgreSQL JDBC driver 9.3-1100, Spring framework 3.1.2 > Reporter: Sean Hsien > Assignee: Jesper Pedersen > > The {code:xml}<check-valid-connection-sql>{code} doesn't work. After starting my app, I shutdown postgres, then restart it. After restarting Wildfly continues to report the connection is closed. Note that the same test works as expected in JBoss AS 7.1.0. Below is an extract of my standalone.xml for my datasource: > {code:xml} > <datasource jta="true" jndi-name="java:jboss/datasources/testdb" pool-name="testdb" enabled="true" spy="true" use-ccm="true"> > <connection-url>jdbc:postgresql://localhost:5432/testdb</connection-url> > <driver>postgresql-9.3-1100.jdbc41.jar</driver> > <pool> > <min-pool-size>0</min-pool-size> > <max-pool-size>1</max-pool-size> > <use-strict-min>true</use-strict-min> > <flush-strategy>FailingConnectionOnly</flush-strategy> > </pool> > <security> > <user-name>user</user-name> > <password>password</password> > </security> > <validation> > <check-valid-connection-sql>SELECT 1</check-valid-connection-sql> > <background-validation>false</background-validation> > <background-validation-millis>1000</background-validation-millis> > </validation> > <statement> > <prepared-statement-cache-size>0</prepared-statement-cache-size> > <share-prepared-statements>false</share-prepared-statements> > </statement> > </datasource> > {code} > I've tried deploying the postgres jdbc driver in 2 ways: via the module and also by copying the jar directly into the standalone/deployments folder, both ways having the same error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2914) add cli xsd version 1.3 which is 1.2 plus vault configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2914?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-2914: ---------------------------------------- This should go in 9.x as 8.0.1.Final will be produced before any EAP GA release that has this schema in it. If we put 1.3 in a WF .Final and then there needs to be some change in EAP 6.3, EAP will have to move to 1.4. > add cli xsd version 1.3 which is 1.2 plus vault configuration > ------------------------------------------------------------- > > Key: WFLY-2914 > URL: https://issues.jboss.org/browse/WFLY-2914 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.1.Final > > > Originally, vault support was introduced in cli xsd 2.0. However, it had to included into the current EAP version which couldn't switch cli xsd 1.2 to 2.0. So, the decision was to create cli xsd 1.3 which is xsd 1.2 + the vault configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3008) System property substitution does not work in subnet-match

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3008?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3008: ----------------------------------- Fix Version/s: 8.0.1.Final I'm scheduling this for 8.0.1 mostly to get it in the 8.0.1 task list queries so it has a chance of getting done. It may not though; probably won't. > System property substitution does not work in subnet-match > ---------------------------------------------------------- > > Key: WFLY-3008 > URL: https://issues.jboss.org/browse/WFLY-3008 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Rich DiCroce > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.1.Final > > > Specifying a system property in subnet-match when defining an interface causes an exception on startup. Example: > {code:xml} > <property name="subnet" value="192.168.0.0/16"/> > ... > <interface name="public"> > <subnet-match value="${subnet}"/> > </interface> > {code} > Causes: > {code} > 12:36:13,457 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[311,46] > Message: JBAS014693: Invalid 'value' ${subnet} -- must be of the form address/mask > at org.jboss.as.server.parsing.CommonXml.validateAddressMask(CommonXml.java:605) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.CommonXml.parseSimpleInterfaceCriterion(CommonXml.java:587) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.CommonXml.parseInterfaceCriteria(CommonXml.java:467) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.CommonXml.parseInterfaces(CommonXml.java:644) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:465) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > ... 3 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reopened WFLY-2970: ------------------------------- Assignee: Richard Achmatowicz (was: Alexey Loubyansky) Sorry guys, looks like this was not fixed for jgroups mappings. > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Richard Achmatowicz > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2970: ------------------------------ Fix Version/s: (was: JBoss AS7 7.2.0.Final) > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Alexey Loubyansky > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2970: ------------------------------ Component/s: Clustering (was: CLI) > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Alexey Loubyansky > Fix For: JBoss AS7 7.2.0.Final > > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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 February 2014