[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
James Livingston commented on LOGMGR-99:
----------------------------------------
guessClass()'s TCCL lookup and system CL lookup pass false for the second parameter so that the class is not initialised. The second forName() call which will use the log manager CL uses the single argument version which results in true being passed. It is not very likely that a log manager class would fail to initialise, but it may be worth changing "Class.forName(name)" to "Class.forName(name, false, Formatters.class.getClassLoader()" to be consistent although that wouldn't prevent this issue.
A naive solution would be set a (thread-local?) marker when performing the logging and abort if it attempts to log while logging. That would not however deal with Async loggers, which would make solving it more complex.
> 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
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: David Lloyd
> Priority: Critical
> 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
> ...
> 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)
> ...
--
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
[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
James Livingston updated LOGMGR-99:
-----------------------------------
Attachment: logmgr99.war
This is a simple reproducer (works on both JBoss EAP and WildFly). It contains a simple servlet which logs a RuntimeException, and two fake class files (org.wildfly.extension.undertow.deployment.UndertowDeploymentService and org.jboss.threads.JBossThread) which contain text not a class.
When guessClass() tried to load the class Modules will attempt to log the fact and triggers the recursion.
> 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
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: David Lloyd
> Priority: Critical
> 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
> ...
> 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)
> ...
--
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
[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 updated LOGMGR-99:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1071695
> 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
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: David Lloyd
> Priority: Critical
>
> 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
> ...
> 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)
> ...
--
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
[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Livingston (JIRA)
James Livingston created LOGMGR-99:
--------------------------------------
Summary: 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
Security Level: Public (Everyone can see)
Affects Versions: 1.5.1.Final
Reporter: James Livingston
Assignee: David Lloyd
Priority: Critical
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
...
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)
...
--
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
[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
James Livingston updated LOGMGR-99:
-----------------------------------
Workaround Description: Use %e in the formatter rather than %E
> 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
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: David Lloyd
> Priority: Critical
>
> 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
> ...
> 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)
> ...
--
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
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3033:
------------------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
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
[JBoss JIRA] (WFLY-3050) '=' character removed from request cookie
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3050?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3050:
--------------------------------------
This related to UNDERTOW-49, it looks like we missed adding a configuration option for this to Wildfly.
> '=' character removed from request cookie
> ------------------------------------------
>
> Key: WFLY-3050
> URL: https://issues.jboss.org/browse/WFLY-3050
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: windows 7
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> I'm saving encrypted user token in session cookie:
> Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
> The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
>
--
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
[JBoss JIRA] (DROOLS-446) Literals may be ambiguously resolved as classes on case insensitive filesystems
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-446:
-------------------------------------
Summary: Literals may be ambiguously resolved as classes on case insensitive filesystems
Key: DROOLS-446
URL: https://issues.jboss.org/browse/DROOLS-446
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final, 6.0.0.Final, 5.6.0.Final, 5.5.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Fix For: 6.1.0.CR1
When a candidate class literal is analyzed, e.g. :
{code}
declare Foo
f1 : Bar = new Bar()
f2 : boolean = false
end
{code}
"Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
However, even "false" is tentatively resolved as well.
On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
The same will happen to "true" and "null"
--
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
[JBoss JIRA] (WFLY-3050) '=' character removed from request cookie
by roy mizrachi (JIRA)
roy mizrachi created WFLY-3050:
----------------------------------
Summary: '=' character removed from request cookie
Key: WFLY-3050
URL: https://issues.jboss.org/browse/WFLY-3050
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Final
Environment: windows 7
Reporter: roy mizrachi
Assignee: Stuart Douglas
I'm saving encrypted user token in session cookie:
Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
--
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
[JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3001?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3001.
-------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
> ---------------------------------------------------------------------
>
> Key: WFLY-3001
> URL: https://issues.jboss.org/browse/WFLY-3001
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: Stuart Douglas
> Labels: cdi, npe, session, weld
> Fix For: 8.0.0.Final
>
>
> Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
> From that point on the _only_ possibility to access the application is clean of session cookies.
> Stacktrace:
> 2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
> nterException
> at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
> 53]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
> 6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
> -SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
> 6-SNAPSHOT]
--
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