June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-40) Generated translations are being generated with the last message generated for all languages

by James Perkins (JIRA)

James Perkins created LOGTOOL-40: ------------------------------------ Summary: Generated translations are being generated with the last message generated for all languages Key: LOGTOOL-40 URL: https://issues.jboss.org/browse/LOGTOOL-40 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Final Reporter: James Perkins Assignee: James Perkins Priority: Blocker -- 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

13 years, 7 months

2
5
0 / 0

[JBoss JIRA] (LOGTOOL-39) readResolve methods should return type Object.

by James Perkins (JIRA)

James Perkins created LOGTOOL-39: ------------------------------------ Summary: readResolve methods should return type Object. Key: LOGTOOL-39 URL: https://issues.jboss.org/browse/LOGTOOL-39 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins -- 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

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] (LOGTOOL-42) Message.INHERIT does not property inherit the id on overloaded methods.

by James Perkins (JIRA)

James Perkins created LOGTOOL-42: ------------------------------------ Summary: Message.INHERIT does not property inherit the id on overloaded methods. Key: LOGTOOL-42 URL: https://issues.jboss.org/browse/LOGTOOL-42 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins When overloaded methods are used the the message id is set to be inherited, the message id is not really inherited unless the overloaded methods contain the exact same number of parameters (minus any @Param, @Field or @Cause annotated parameters). -- 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

13 years, 7 months

2
5
0 / 0

[JBoss JIRA] (LOGTOOL-41) Add better comments for parameter arguments in the skeleton files.

by James Perkins (JIRA)

James Perkins created LOGTOOL-41: ------------------------------------ Summary: Add better comments for parameter arguments in the skeleton files. Key: LOGTOOL-41 URL: https://issues.jboss.org/browse/LOGTOOL-41 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Add the parameter name and possibly the JavaDoc for the parameter in the skeleton translation files. {code:java} String sayHello(String name) {code} Should generate: {code} # Id: 100 # Level: Logger.Level.INFO # Message: Hello %s[1]. # [1]: name {code} -- 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

13 years, 7 months

2
5
0 / 0

[JBoss JIRA] (LOGTOOL-43) Double-byte characters are not correctly generated in the source

by James Perkins (JIRA)

James Perkins created LOGTOOL-43: ------------------------------------ Summary: Double-byte characters are not correctly generated in the source Key: LOGTOOL-43 URL: https://issues.jboss.org/browse/LOGTOOL-43 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Fix For: 1.0.2.Final When a translation file (a properties file) used double-byte characters, the generated source string is incorrect due to improper loading of the properties file. -- 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

13 years, 7 months

2
3
0 / 0

[JBoss JIRA] (LOGTOOL-46) jboss-logging-generator singletons don't play nice with Eclipse APT

by Fred Bricon (JIRA)

Fred Bricon created LOGTOOL-46: ---------------------------------- Summary: jboss-logging-generator singletons don't play nice with Eclipse APT Key: LOGTOOL-46 URL: https://issues.jboss.org/browse/LOGTOOL-46 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR5 Environment: Eclipse 3.7 Reporter: Fred Bricon Assignee: David Lloyd Attachments: jbosslogging-ap-errors.png While testing [m2e-apt|https://github.com/jbosstools/m2e-apt] on [hibernate-search|https://github.com/hibernate/hibernate-search], I got these strange errors : all the log methods are marked as being duplicate. My gut feeling is this is due to [MessageIdValidator being a singleton|https://github.com/jboss-logging/jboss-logging-tools/blob/4b437...] : all AP work in eclipse reuses the same instance between each incremental builds. So validating the same file more than once lead to these errors. -- 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

13 years, 7 months

3
8
0 / 0

[JBoss JIRA] (LOGTOOL-44) Make configurable whether @Override annotation shall be added

by Gunnar Morling (JIRA)

Gunnar Morling created LOGTOOL-44: ------------------------------------- Summary: Make configurable whether @Override annotation shall be added Key: LOGTOOL-44 URL: https://issues.jboss.org/browse/LOGTOOL-44 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.1.Final Reporter: Gunnar Morling Assignee: David Lloyd The annotation processor adds the {{(a)java.lang.Override}} annotation to the methods of generated log or message bundle classes. For methods implementing interface methods this is allowed only in Java 6 and above, while in Java 5 {{@Override}} is only allowed for methods overriding methods from superclasses. Therefore compilation of the generated classes fails using Java 5. To address this issue, the annotation should be added conditionally based on the current source level. -- 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

13 years, 7 months

4
19
0 / 0

[JBoss JIRA] (LOGTOOL-45) Avoid unnecessary calls to String#format()

by Gunnar Morling (JIRA)

Gunnar Morling created LOGTOOL-45: ------------------------------------- Summary: Avoid unnecessary calls to String#format() Key: LOGTOOL-45 URL: https://issues.jboss.org/browse/LOGTOOL-45 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gunnar Morling Assignee: David Lloyd Generated message bundle methods always contain an invocation of {{String#format()}} also if there actually is no parameter to be replaced, e.g. like this: {code} @Override public final String mustNotBeNull() { String result = String.format(mustNotBeNull0$str()); return result; } {code} AFAICS the invocation of {{format()}} seems superfluous, instead the String might directly be returned for performance reasons. -- 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

13 years, 7 months

4
10
0 / 0

[JBoss JIRA] (JGRP-1484) SEQUENCER and merge-views broken

by David Hotham (JIRA)

David Hotham created JGRP-1484: ---------------------------------- Summary: SEQUENCER and merge-views broken Key: JGRP-1484 URL: https://issues.jboss.org/browse/JGRP-1484 Project: JGroups Issue Type: Bug Affects Versions: 3.0.10 Reporter: David Hotham Assignee: Bela Ban Here's a new way in which putting SEQUENCER below GMS is broken. Start with A having view B|4 [B,A], while B, C and D all have view B|7 [B,C,D]. Now we start a merge, in which B is coordinator. B creates the view C|8 [C, D, A, B]. (I've opened a pull request saying that B surely shouldn't issue a view where the ViewID says that C was the creator. But I think that this is incidental, and not key to the bug that I'm reporting here). Now B sends INSTALL_MERGE_VIEW to B (a coordinator) and A (a merge participant, per Util.determineMergeParticipants). B gets this first and broadcasts the new view to [B, C, D]. In particular, B is now not a coordinator. Then A gets the INSTALL_MERGE_VIEW, and it too tries broadcasting the new view. SEQUENCER gets involved, and forwards the broadcast to B (as the coordinator in the old view). B discards this; it's no longer a coordinator. So the new view is not installed at A. All future broadcasts from A are forwarded to B, who discards them. The group is fractured, and none of A's broadcasts are delivered. I'm not sure what the right fix would be. I wonder whether things should be arranged so that in a merge: - coordinators behave as today, broadcasting the new view to their own sub-groups - but mere participants do not do this: they should just have the new view installed on them. -- 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

13 years, 7 months

2
32
0 / 0

[JBoss JIRA] (AS7-4567) Weld does not find CDI Beans within AS7 modules

by Gernot P (JIRA)

Gernot P created AS7-4567: ----------------------------- Summary: Weld does not find CDI Beans within AS7 modules Key: AS7-4567 URL: https://issues.jboss.org/browse/AS7-4567 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.1.Final, 7.1.0.Final Reporter: Gernot P Assignee: David Lloyd I've a my.jar which contains cdi beans and cdi producer methods and a META-INF/beans.xml file. Putting this jar to WEB-INF/lib in my war, the web app can use the cdi producer methods of my.jar. After moving my.jar from WEB-INF/lib to a AS7 module(and adding a dependency in the war's MANIFEST.MF) AS7 reports org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [BeanXY] with qualifiers [@Default] at injection point [[field] @Inject It seams that weld does not (or cannot) scan my.jar which is inside AS7 module. (instantiating BeanXY directly ("new BeanXY()") works - so the module is loaded correctly) -- 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

13 years, 7 months

4
6
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 June 2012