October 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (LOGTOOL-4) Reduce string constants in generated classes

by David Lloyd (JIRA)

Reduce string constants in generated classes -------------------------------------------- Key: LOGTOOL-4 URL: https://jira.jboss.org/browse/LOGTOOL-4 Project: Log Tool Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Priority: Minor The generated classes include pregenerated string constants e.g. "PROJECT-00001" etc. This can be wasteful of space and constant table entries. These prefixes should be programmatically generated at the time of message rendering. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (LOGTOOL-5) Support BasicLogger methods on logger interfaces

by David Lloyd (JIRA)

Support BasicLogger methods on logger interfaces ------------------------------------------------ Key: LOGTOOL-5 URL: https://issues.jboss.org/browse/LOGTOOL-5 Project: Log Tool Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta1 Reporter: David Lloyd Fix For: 1.0.0.Beta2 If a logger interface extends BasicLogger, then those methods should be implemented and delegated to the logger instance. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (LOGTOOL-27) Extended interfaces should find translations for the interface that was extended

by James Perkins (JIRA)

Extended interfaces should find translations for the interface that was extended -------------------------------------------------------------------------------- Key: LOGTOOL-27 URL: https://issues.jboss.org/browse/LOGTOOL-27 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Currently if an interface is extended both the super interface needs translation files and the sub-interface needs the same messages translated. Either the messages need to be discovered and generated into the subtype or the subtype needs to extend the supertypes implementation. Extending the supertypes implementation does leave the generated code more simple, but would require that any extended interfaces be annotated with @MessageLogger or @MessageBundle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (LOGTOOL-31) Allow exception methods to set fields on the exception object

by David Lloyd (JIRA)

Allow exception methods to set fields on the exception object ------------------------------------------------------------- Key: LOGTOOL-31 URL: https://issues.jboss.org/browse/LOGTOOL-31 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.0.0.Beta9 Create a new annotation called @Field which accepts a single string parameter. For methods which return an exception, the values of these parameters will be assigned to fields on the exception object with the corresponding name. For example: {code} @Message(id = 1000, "The transaction failed because blah blah %s") XAException transactionFailedBlah(String blah, @Field("errorCode") int errorCode); // should also continue to work with @Cause in conjunction with exceptions which don't have a cause param: @Message(id = 1001, "The operation was interrupted unexpectedly by %s") InterruptedIOException surprise(String reason, @Cause Throwable someCause, @Field("bytesTransferred") int bytesTransferred); {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
5
0 / 0

[JBoss JIRA] Created: (LOGTOOL-2) Message logger will not allow String return type

by James Perkins (JIRA)

Message logger will not allow String return type ------------------------------------------------ Key: LOGTOOL-2 URL: https://jira.jboss.org/browse/LOGTOOL-2 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta1 Reporter: James Perkins Assignee: David Lloyd Interfaces annotated with @MessageLogger should allow String return types if and only if the @LogMessage annotation is not present on the method. Also, the @LogMessage annotation should not be inherited on like named methods. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (LOGTOOL-21) Add mechanism to pass parameters to exception constructors

by David Lloyd (JIRA)

Add mechanism to pass parameters to exception constructors ---------------------------------------------------------- Key: LOGTOOL-21 URL: https://issues.jboss.org/browse/LOGTOOL-21 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: David Lloyd Assignee: James Perkins Fix For: 1.0.0.Beta8 We need a parameter annotation which allows log methods to pass additional parameters to the constructor of exceptions. Something like {{@Param}}. It would exclude that parameter from the list and instead apply those values to non-cause, non-message parameters of the constructor. For the purposes of resolution, assume the message parameter is the left-most String and the cause parameter is the left-most Throwable or subtype thereof. Parameters should be order-matched first, then type-matched to resolve ambiguity, throwing an exception if there is no unambiguous solution. The {{@Param}} annotation should allow an optional class name to be specified which would have to match the exact type of the parameter in question, to enable unambiguous resolution in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
4
0 / 0

[JBoss JIRA] Created: (AS7-1435) Modify cobertura maven plugin definition to use version 2.5

by Rostislav Svoboda (JIRA)

Modify cobertura maven plugin definition to use version 2.5 ----------------------------------------------------------- Key: AS7-1435 URL: https://issues.jboss.org/browse/AS7-1435 Project: Application Server 7 Issue Type: Task Reporter: Rostislav Svoboda Upgrade jboss-parent to use version 2.5 for cobertura maven plugin. Version 2.5 contains functionality for agregated report - http://jira.codehaus.org/browse/MCOBERTURA-65 Don't use version 2.5.1 because there is NPE bug - see http://jira.codehaus.org/browse/MCOBERTURA-151 Workaround: specify cobertura plugin version from command line mvn -Pcode-coverage -Dcobertura.aggregate=true -Dversion.cobertura.plugin=2.5 clean cobertura:clean cobertura:cobertura -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
6
0 / 0

[JBoss JIRA] (AS7-2163) CLONE - System properties propagated from command line using -D, -P or --properties aren't visible in CLI and console

by Rostislav Svoboda (Created) (JIRA)

CLONE - System properties propagated from command line using -D, -P or --properties aren't visible in CLI and console --------------------------------------------------------------------------------------------------------------------- Key: AS7-2163 URL: https://issues.jboss.org/browse/AS7-2163 Project: Application Server 7 Issue Type: Bug Components: CLI, Console, Domain Management Reporter: Rostislav Svoboda Assignee: Brian Stansberry Fix For: 7.1.0.CR1 CLI and console shows only properties defined in .xml configuration files. System properties propagated from command line using -D, -P or --properties args should be visible too. It would be useful for administrators when searching for possible problems, the same applies to devels. For domain I'd like to see sysprops on each instance and separate overview for DC. Previous versions of AS/EAP provide such overview in /web-console/SysProperties.jsp. NOTE: JVM based properties like java.vendor etc. would be beneficial too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-188) JGroups should not use System properties, because it's too restrictive

by Julien Kronegg (Commented) (JIRA)

[ https://issues.jboss.org/browse/JGRP-188?page=com.atlassian.jira.plugin.s... ] Julien Kronegg commented on JGRP-188: ------------------------------------- I would use a variant of Robert's suggestion (singleton that contains a Properties object), but simpler (I would argue that System Properties are global anyway, so using a singleton pattern would be a luxury). This would require to update [{{org.jgroups.util.Util}}|https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.java] as such: - add the field {{private static Properties globalProperties=null;}} - add a static setter for the {{globalProperties}} field - modify the {{_getProperty(String,String)}} method (at line ~4099) in order to first check for the {{prop}} key in the {{globalProperties}}, then, if not found, in the System Properties, and finally use the default value if no value was found: {code} private static String _getProperty(String var, String default_value) { if(var == null) return null; List<String list=parseCommaDelimitedStrings(var); if (list==null ||list.isEmpty()) { list=new ArrayList<String(1); list.add(var); } for (String prop:list) { retval = (globalProperties!=null?globalProperties.get(prop):null); if (retval==null) { // no value found from the global properties => look into the System Properties try { retval=System.getProperty(prop); } catch (Throwable e) { // failed to get the system property => do nothing } } if (retval!=null) { return retval; } } return default_value; } {code} Thus, when the {{globalProperties}} are not set, the System Properties will be used (unchanged behavior). Users who care about security would use the {{globalProperties}} and others will still use System Properties. The documentation may also be updated in order to warn the users about the (small) security risk of information disclosure. Note that the {{getProperty(...)}} method at line ~3076 also uses {{System.getProperty(String)}}, but I did not check if a modification is required here. > JGroups should not use System properties, because it's too restrictive > ---------------------------------------------------------------------- > > Key: JGRP-188 > URL: https://issues.jboss.org/browse/JGRP-188 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.8, 2.2.9, 2.2.9.1 > Environment: all > Reporter: Robert Stevenson > Assignee: Bela Ban > Priority: Minor > Fix For: 2.4 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > JGroups should not use System properties for configuration, it should instead use a Global Configurator class (singleton), similar to log4j; which just contains a Properties object. This would allow JGroups to be much easier to move around to different environments. For example : (Applet), which does not have access to easily change System properties, on a per applet basis. > This new class could have a mapping/conversion method to make the current -D command line options be put into this new Properties Configurator for backward compatibility -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (AS7-815) Fix or remove ignored tests in WSTestCase

by Thomas Diesler (JIRA)

Fix or remove ignored tests in WSTestCase ----------------------------------------- Key: AS7-815 URL: https://issues.jboss.org/browse/AS7-815 Project: Application Server 7 Issue Type: Sub-task Reporter: Thomas Diesler Assignee: Alessio Soldano We are in the process of a major test infrastructure update. For this I migrated all smoke tests the the managed container. The arquillian subsystem has been replaced by a on-demand deployment. Your test might be @Ignored because I could not fix it easily or it has already been ignored for some time. Please have a look if you can fix it, otherwise I'd like to know why it should be ignored. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

7
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2011