March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-72) Convert array parameters to a string before passing to formatter

by James Perkins (JIRA)

James Perkins created LOGTOOL-72: ------------------------------------ Summary: Convert array parameters to a string before passing to formatter Key: LOGTOOL-72 URL: https://issues.jboss.org/browse/LOGTOOL-72 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Array typed parameters should (maybe not always?) be converted to a String type before formatting. Possibly use something like {{Arrays.toString()}}. Maybe an annotation for the parameter to specify it should be created and whether or not to use a deep conversion or not. Maybe add a {{org.jboss.logging.annotations.Transform.TransformType}}. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time

by James Perkins (JIRA)

James Perkins created LOGTOOL-71: ------------------------------------ Summary: Allow messages to have expressions resolved at code generation time Key: LOGTOOL-71 URL: https://issues.jboss.org/browse/LOGTOOL-71 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Fix For: 1.2.0.Beta1 Allow messages in the {{@Message}} annotation to allow expressions in the format of: {code} ${property.name:default} {code} A warning message should be generated if the property name was not found. If not default is found an error should be generated. The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6549) Remote JNDI is not working with a HornetQ-only JMS bridge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6549?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6549: ---------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] Pull request for EAP 6.1.x sent: https://github.com/jbossas/jboss-eap/pull/82 > Remote JNDI is not working with a HornetQ-only JMS bridge > --------------------------------------------------------- > > Key: AS7-6549 > URL: https://issues.jboss.org/browse/AS7-6549 > Project: Application Server 7 > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes. > However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6549) Remote JNDI is not working with a HornetQ-only JMS bridge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6549?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6549: ---------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from ASSIGNED to MODIFIED > Remote JNDI is not working with a HornetQ-only JMS bridge > --------------------------------------------------------- > > Key: AS7-6549 > URL: https://issues.jboss.org/browse/AS7-6549 > Project: Application Server 7 > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes. > However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-93) Provide mechanism for preparing string representations of logged objects

by Gunnar Morling (JIRA)

Gunnar Morling created JBLOGGING-93: --------------------------------------- Summary: Provide mechanism for preparing string representations of logged objects Key: JBLOGGING-93 URL: https://issues.jboss.org/browse/JBLOGGING-93 Project: JBoss Logging Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jboss-logging-spi Affects Versions: 3.1.2.GA Reporter: Gunnar Morling Assignee: David Lloyd There are cases where a fine-grained control of the string representation of logged objects in log messages would be useful. When logging {{Class}} objects for instance, we would like to see the fully-qualified name of the given class in the log message. Currently we get _(class|interface) com.acme.Foo_, though, as per the implementation of {{j.l.Class#toString()}}, which prepends the type of the given class object. As workaround, we currently define the log method to accept a String parameter and pass {{myClass.getName()}} to it. Having a strongly typed log method which takes the "real" object as parameter seems preferable, though. A possible solution could be a mechanism which allows to register to-string converters for given types with a logger: {code} //Provided by JBoss Logging API public interface StringConverter<T> { String createString(T object); } //A project-specific implementation public class ClassStringConverter implements StringConverter<Class<?>> { public String createString(Class<?> object) { return object.getName(); } } //Project-specific logger, references 1..n converters @MessageLogger(projectCode = "HV", converters=ClassStringConverter.class) public interface Log extends BasicLogger { //implementation uses converter to create string representation of given class @LogMessage(level = INFO) @Message(id = 1, value = "Illegal class %s") void illegalClass(Class<?> clazz); } {code} Would such a feature make sense to you? -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6549) Remote JNDI is not working with a HornetQ-only JMS bridge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6549?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6549: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] Hi Jeff, fix for this issue did not get into EAP 6.1.0.ER3. Could you check with productization guys to where the fix should be committed? Thanks, Mirek > Remote JNDI is not working with a HornetQ-only JMS bridge > --------------------------------------------------------- > > Key: AS7-6549 > URL: https://issues.jboss.org/browse/AS7-6549 > Project: Application Server 7 > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes. > However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-79) ClassCastException when compiling a rule

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-79?page=com.atlassian.jira.plugin.... ] Mario Fusco resolved DROOLS-79. ------------------------------- Fix Version/s: 5.6 6.0.0.Alpha1 Resolution: Done > ClassCastException when compiling a rule > ---------------------------------------- > > Key: DROOLS-79 > URL: https://issues.jboss.org/browse/DROOLS-79 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5 > Reporter: Radai Rosenblatt > Assignee: Mario Fusco > Fix For: 5.6, 6.0.0.Alpha1 > > Attachments: JBRULES-79.zip > > > when compiling a rule on jboss i see this exception printed out to the log: > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) Exception in thread "Thread-264" java.lang.ClassCastException: org.mvel2.compiler.ExecutableLiteral cannot be cast to org.mvel2.compiler.ExecutableAccessor > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:173) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:174) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:108) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99) > 2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70) > 2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.lang.Thread.run(Thread.java:722) > attached to this bug is a maven project that reproduces the issue consistently -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-79) ClassCastException when compiling a rule

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-79?page=com.atlassian.jira.plugin.... ] Mario Fusco reassigned DROOLS-79: --------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > ClassCastException when compiling a rule > ---------------------------------------- > > Key: DROOLS-79 > URL: https://issues.jboss.org/browse/DROOLS-79 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5 > Reporter: Radai Rosenblatt > Assignee: Mario Fusco > Attachments: JBRULES-79.zip > > > when compiling a rule on jboss i see this exception printed out to the log: > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) Exception in thread "Thread-264" java.lang.ClassCastException: org.mvel2.compiler.ExecutableLiteral cannot be cast to org.mvel2.compiler.ExecutableAccessor > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:173) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:174) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:108) > 2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99) > 2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70) > 2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > 2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.lang.Thread.run(Thread.java:722) > attached to this bug is a maven project that reproduces the issue consistently -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-62) Is there anyway to control standalone/tmp/vfs folder incresing size?

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-62?page=com.atlassian.jira.plugin.... ] David Lloyd resolved LOGMGR-62. ------------------------------- Resolution: Rejected Don't use JIRA to ask questions. Go here instead: https://community.jboss.org/en/jbossas?view=discussions > Is there anyway to control standalone/tmp/vfs folder incresing size? > -------------------------------------------------------------------- > > Key: LOGMGR-62 > URL: https://issues.jboss.org/browse/LOGMGR-62 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: core > Reporter: Mahesh Khatal > Assignee: David Lloyd > > Hi, > my application gets sloved b'coz standalone/tmp/vfs folder size gets incresing. Is there any way to come out of 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-62) Is there anyway to control standalone/tmp/vfs folder incresing size?

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-62?page=com.atlassian.jira.plugin.... ] David Lloyd updated LOGMGR-62: ------------------------------ Due Date: 1/Apr/13 > Is there anyway to control standalone/tmp/vfs folder incresing size? > -------------------------------------------------------------------- > > Key: LOGMGR-62 > URL: https://issues.jboss.org/browse/LOGMGR-62 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: core > Reporter: Mahesh Khatal > Assignee: David Lloyd > > Hi, > my application gets sloved b'coz standalone/tmp/vfs folder size gets incresing. Is there any way to come out of 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

13 years, 1 month

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 March 2013