February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ] James Livingston commented on LOGMGR-95: ---------------------------------------- Logger a = Logger.getLogger("a"); Logger abc = Logger.getLogger("a.b.c"); Logger ab = Logger.getLogger("a.b"); With the log4j bridge, abc.getParent().getName() == "a" but with original log4j it is "a.b". An alternative would be to have Logger.getParent() get the parent node and then convert that back to a Logger (so dropping updateParents() altogether), but I believe that would require Logger to have changes from upstream which it doesn't currently have. Logger.getParent() isn't particularly well documented as to what it is supposed to do, but the bridge's current behaviour is not identical to Log4J's. > Log4j Logger.getParent() inconsistent > ------------------------------------- > > Key: LOGMGR-95 > URL: https://issues.jboss.org/browse/LOGMGR-95 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Livingston > Assignee: David Lloyd > > Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in. > Consider: > Logger.getLogger("a"); > Logger.getLogger("a.b.c"); > Logger.getLogger("a.b"); > When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3023) JDR CommandLineMain defaults to port 9999

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3023: -------------------------------------- Summary: JDR CommandLineMain defaults to port 9999 Key: WFLY-3023 URL: https://issues.jboss.org/browse/WFLY-3023 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JDR Affects Versions: 8.0.0.Final Reporter: Brian Stansberry Assignee: Jesse Jaggars If the user doesn't provide a port, CommandLineMain defaults to 9999, but with protocol http-remoting. That combo won't work. It should use 9990 since that will be the default management port. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3022) Make LogStoreResource's 'type' attribute read-only

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3022: -------------------------------------- Summary: Make LogStoreResource's 'type' attribute read-only Key: WFLY-3022 URL: https://issues.jboss.org/browse/WFLY-3022 Project: WildFly Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Transactions Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 9.0.0.CR1 See parent issue. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3021) LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3021: -------------------------------------- Summary: LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute Key: WFLY-3021 URL: https://issues.jboss.org/browse/WFLY-3021 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 8.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.1.Final The 'type' attribute of LogStoreResource isn't really read-write. Its value is determined by attributes of the parent resource. The OSH for write-attribute is ReloadRequiredWriteAttributeHandler, and when the reload happens whatever value is set will be lost. For 8.0.1 I'll have the OSH just log a WARN. The attribute should be made read-only for 9. I could make it read-only for 8.0.1 but I don't want to do a management API bump, introduce transformation etc. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3020) LogStoreProbeHandler overwrites the LogStoreResource root model

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3020: -------------------------------------- Summary: LogStoreProbeHandler overwrites the LogStoreResource root model Key: WFLY-3020 URL: https://issues.jboss.org/browse/WFLY-3020 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 8.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.1.Final LogStoreProbeHandler replaces the 'delegate' held by LogStoreResource. Doing this removes any data from the existing delegate's 'model' field, i.e. the "type" attribute. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3019) Shutdown on startup error

by Takayoshi Kimura (JIRA)

Takayoshi Kimura created WFLY-3019: -------------------------------------- Summary: Shutdown on startup error Key: WFLY-3019 URL: https://issues.jboss.org/browse/WFLY-3019 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 8.0.0.Final Reporter: Takayoshi Kimura Currently WildFly starts and up running although it got critical errors during boot. For example, 8080 port is being used by the other process and undertow subsystem was not functioning, transaction manager and logging subsystems are failed to boot due to file permission error, or someone started the instance twice by mistake. It would be nice if we can have an option to trigger shutdown the non-healthy instance in these boot error situations, for subsystem level errors and for deployment errors. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3018) Upgrade to MSC 1.2.1.Final

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3018?page=com.atlassian.jira.plugin.... ] Richard Opalka updated WFLY-3018: --------------------------------- Component/s: MSC > Upgrade to MSC 1.2.1.Final > -------------------------- > > Key: WFLY-3018 > URL: https://issues.jboss.org/browse/WFLY-3018 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: MSC > Reporter: Richard Opalka > -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3018) Upgrade to MSC 1.2.1.Final

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3018?page=com.atlassian.jira.plugin.... ] Richard Opalka reassigned WFLY-3018: ------------------------------------ Assignee: Richard Opalka > Upgrade to MSC 1.2.1.Final > -------------------------- > > Key: WFLY-3018 > URL: https://issues.jboss.org/browse/WFLY-3018 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: MSC > Reporter: Richard Opalka > Assignee: Richard Opalka > -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3018) Upgrade to MSC 1.2.1.Final

by Richard Opalka (JIRA)

Richard Opalka created WFLY-3018: ------------------------------------ Summary: Upgrade to MSC 1.2.1.Final Key: WFLY-3018 URL: https://issues.jboss.org/browse/WFLY-3018 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Reporter: Richard Opalka -- 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

10 years, 10 months

1
0
0 / 0

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

by Sean Hsien (JIRA)

[ https://issues.jboss.org/browse/WFLY-2919?page=com.atlassian.jira.plugin.... ] Sean Hsien commented on WFLY-2919: ---------------------------------- I didn't think that was a question, but a bug report, especially since the same config worked in JBoss AS 7.1.0 Final, as stated in the original post. Sorry if it wasn't worded right. > 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014