February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-96) Make it easier to add custom pattern format characters

by Kyle Lape (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-96?page=com.atlassian.jira.plugin.... ] Kyle Lape commented on LOGMGR-96: --------------------------------- If any format chars are added to the {{FormatStringParser}} after this is added, then it has the potential to clash with a custom format char used by a custom pattern formatter. This could be resolved by allowing custom formatters to override format chars used by {{FormatStringParser}}, but this introduces issues of its own. > Make it easier to add custom pattern format characters > ------------------------------------------------------ > > Key: LOGMGR-96 > URL: https://issues.jboss.org/browse/LOGMGR-96 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kyle Lape > Assignee: Kyle Lape > > It would be nice to be able to add custom format characters without having to add each one directly to the LogManager project. For example, say someone wants to have {{%h}} represent the JBoss host name. This may not be desirable to keep in our codebase, but it would be reasonable to allow someone to easily customize our {{PatternFormatter}} to do something like this. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-96) Make it easier to add custom pattern format characters

by Kyle Lape (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-96?page=com.atlassian.jira.plugin.... ] Kyle Lape updated LOGMGR-96: ---------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/46 > Make it easier to add custom pattern format characters > ------------------------------------------------------ > > Key: LOGMGR-96 > URL: https://issues.jboss.org/browse/LOGMGR-96 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kyle Lape > Assignee: Kyle Lape > > It would be nice to be able to add custom format characters without having to add each one directly to the LogManager project. For example, say someone wants to have {{%h}} represent the JBoss host name. This may not be desirable to keep in our codebase, but it would be reasonable to allow someone to easily customize our {{PatternFormatter}} to do something like this. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-177) VFSUtils.unzip() does not preserve file modified time

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBVFS-177?page=com.atlassian.jira.plugin.... ] David Lloyd resolved JBVFS-177. ------------------------------- Assignee: Tomaz Cerar (was: David Lloyd) Resolution: Done This was resolved by Tomaz some months ago. > VFSUtils.unzip() does not preserve file modified time > ----------------------------------------------------- > > Key: JBVFS-177 > URL: https://issues.jboss.org/browse/JBVFS-177 > Project: JBoss VFS > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.0.1.GA > Reporter: Brad Hawthorne > Assignee: Tomaz Cerar > Attachments: VFSUtils.pat > > > Unzip does not set the last-modified time on the files it creates to that of the original ZipEntries, therefore they default to their creation time. This causes problems for JBAS, where web clients will always be forced to re-download files (and not use their cache) whenever the server is restarted or application is redeployed. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-96) Make it easier to add custom pattern format characters

by Kyle Lape (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-96?page=com.atlassian.jira.plugin.... ] Kyle Lape reassigned LOGMGR-96: ------------------------------- Assignee: Kyle Lape (was: David Lloyd) > Make it easier to add custom pattern format characters > ------------------------------------------------------ > > Key: LOGMGR-96 > URL: https://issues.jboss.org/browse/LOGMGR-96 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kyle Lape > Assignee: Kyle Lape > > It would be nice to be able to add custom format characters without having to add each one directly to the LogManager project. For example, say someone wants to have {{%h}} represent the JBoss host name. This may not be desirable to keep in our codebase, but it would be reasonable to allow someone to easily customize our {{PatternFormatter}} to do something like this. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-96) Make it easier to add custom pattern format characters

by Kyle Lape (JIRA)

Kyle Lape created LOGMGR-96: ------------------------------- Summary: Make it easier to add custom pattern format characters Key: LOGMGR-96 URL: https://issues.jboss.org/browse/LOGMGR-96 Project: JBoss Log Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kyle Lape Assignee: David Lloyd It would be nice to be able to add custom format characters without having to add each one directly to the LogManager project. For example, say someone wants to have {{%h}} represent the JBoss host name. This may not be desirable to keep in our codebase, but it would be reasonable to allow someone to easily customize our {{PatternFormatter}} to do something like this. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments

by Scott Hasse (JIRA)

[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- So finally I made it to point 8. I will admit there is an element of subjective preference in all of this, but it seems to me the vast majority of the points in favor or against default visibility of log4j, commons logging and slf4j can be discussed in an objective manner, and the points where there are speculation can be better quantified with meaningful dialogs with support customers, ISVs, RedHat consultants and the community. With respect to if the reasons for changing are convincing enough or not, I have invested a significant amount of time giving my best effort to represent your point of view and communicate my confusion and perspective on each of those points. At the end of the process, and having gotten no correction or clarifications despite asking multiple times, I still find myself not understanding why you think it is better to provide default visibility. I believe that the case for not providing default visibility is the significantly stronger one. So in that context I renew my request: Please consider re-thinking this decision moving forward. Regards, Scott > Log API dependencies should be included automatically in deployments > -------------------------------------------------------------------- > > Key: AS7-1389 > URL: https://issues.jboss.org/browse/AS7-1389 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.0.0.Final > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 7.1.0.Final > > > The following log APIs should be included by deployments by default: > * {{org.slf4j}} > * {{org.apache.commons.logging}} > * {{org.log4j}} > These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2415) Add configuration option to enable/disable Infinispan statistics

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2415: ----------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from NEW to POST > Add configuration option to enable/disable Infinispan statistics > ---------------------------------------------------------------- > > Key: WFLY-2415 > URL: https://issues.jboss.org/browse/WFLY-2415 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Scott Marlow > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > When the Infinispan MBean is enabled, Infinispan statistics are enabled by default. Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting? -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments

by Scott Hasse (JIRA)

[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- Concerning point 7, I will say I am glad that a simpler configuration mechanism is being implemented, and a support customer I work with has made a request to back-port that change to EAP 6, so hopefully we can avoid adding additional configuration to applications migrating to EAP 6 that will ultimately be extraneous anyway. However, when talking about a strategic decision in a future version of the platform, I don't think the relative ease of enabling/disabling a feature should be a strong consideration. Rather, I think the a choice should be made on the merits of the feature/facility as it stands. Regards, Scott > Log API dependencies should be included automatically in deployments > -------------------------------------------------------------------- > > Key: AS7-1389 > URL: https://issues.jboss.org/browse/AS7-1389 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.0.0.Final > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 7.1.0.Final > > > The following log APIs should be included by deployments by default: > * {{org.slf4j}} > * {{org.apache.commons.logging}} > * {{org.log4j}} > These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments

by Scott Hasse (JIRA)

[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- With respect to point 6, for the most part I understand where you are coming from. JEE vendors are encouraged to differentiate themselves on features and extensions. I think many people believe the JEE specification is deficient with respect to the lack of a specified logging facility beyond java.util.logging and the ServletContext's log methods. This makes container logging a potentially good opportunity for vendors to differentiate themselves. So more power to you to provide a logging facility as far as I am concerned. I would, however, take the position that vendor-specific container extensions should be disabled by default and explicitly enabled by those making the conscious choice to use those extensions. This is the typical vendor extension pattern I have encountered, best promotes portability (if that is your goal), and is I believe the most responsible vendor choice. I'm interested to understand if/why you think otherwise. Especially if your extension implementation results in core Java platform manageability features like the LoggingMXBean no longer being viable ("Don't expose the platform LoggingMXBean over management", https://issues.jboss.org/browse/AS7-2185), it seems most responsible to make use of that extension a conscious choice. Regards, Scott > Log API dependencies should be included automatically in deployments > -------------------------------------------------------------------- > > Key: AS7-1389 > URL: https://issues.jboss.org/browse/AS7-1389 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.0.0.Final > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 7.1.0.Final > > > The following log APIs should be included by deployments by default: > * {{org.slf4j}} > * {{org.apache.commons.logging}} > * {{org.log4j}} > These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments

by Scott Hasse (JIRA)

[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- Regarding point 5, I agree this is true as stated, although I don't understand why you would say "JBoss AS and its successor, WildFly, are not Java EE containers..." above. It seems clear to me that when deploying a JEE artifact they are JEE specification-compliant containers. I presume that EAP 7 will follow in the footsteps of EAP 4.x, 5.x and 6.x and obtain official specification compliance, the opportunity for which for JEE at least was hard fought and won by the Apache foundation and JBoss/RedHat. The enterprise customers I work with depend on that. To clarify, I believe the context of what we are discussing is container behavior when deploying JEE-specific artifacts such as ear and war files. In that context, I am still hard-pressed to find any EAP-provided extensions other than the third party logging APIs and implementations, so I don't understand what the "many" facilities are. But in any case what we are talking about is the logging implementation. Since in the context of a JEE deployment whether or not third party logging APIs and implementations are "good examples" of extensions overlaps somewhat with point 6, I can give you my perspective on that below. > Log API dependencies should be included automatically in deployments > -------------------------------------------------------------------- > > Key: AS7-1389 > URL: https://issues.jboss.org/browse/AS7-1389 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.0.0.Final > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 7.1.0.Final > > > The following log APIs should be included by deployments by default: > * {{org.slf4j}} > * {{org.apache.commons.logging}} > * {{org.log4j}} > These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}. -- 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, 2 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