[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-99:
-----------------------------------------------
Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from ON_QA to VERIFIED
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
> Key: LOGMGR-99
> URL: https://issues.jboss.org/browse/LOGMGR-99
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: James Perkins
> Priority: Critical
> Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2
>
> Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> {code}
> ...
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:527)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
> at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
> at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-119) Add resolve-expressions param to operation read-resource
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-119?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-119:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079197
> Add resolve-expressions param to operation read-resource
> --------------------------------------------------------
>
> Key: WFCORE-119
> URL: https://issues.jboss.org/browse/WFCORE-119
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Michael Voegele
> Assignee: Joe Wertz
> Labels: expression, read-resource
> Fix For: 1.0.0.Alpha9
>
>
> When reading a resource remotely, it would be nice to have the possibility to have expressions resolved.
> Following does of course not work, as the code runs in a separate jvm.
> {code:java}
> private void readRecursive(ModelNode modelNode, String modelNodeName, Map<String, Object> map) {
> switch (modelNode.getType()) {
> ...
> case EXPRESSION:
> // this would be great but won't work as it runs in a different jvm
> // ModelNode expression = modelNode.resolve();
> // readRecursive(expression, modelNodeName, map);
> map.put(modelNodeName, modelNode.asString());
> break;
> ...
> }
> {code}
> Therefore a param resolve-expressions for the read-resource operation would be good.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months