[JBoss JIRA] (WFLY-7579) rts integration tests failed when building with jdk 9
by Jessica Lundberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-7579?page=com.atlassian.jira.plugin.... ]
Jessica Lundberg edited comment on WFLY-7579 at 5/20/17 4:19 PM:
-----------------------------------------------------------------
Hi,
I just installed the latest Wildfly 10.1 final release and the latest windows build for JDK 9 and I am getting this exception when I run domain.bat and also when I try standalone.bat. What is the fix? There isn't an option that I see to download the JDK 9 without jigsaw.
was (Author: jessicallundberg):
Hi,
I just installed the latest Wildfly 10.1 final release and the latest windows build for JDK 9 and I am getting this exception when I run domain.bat. What is the fix? There isn't an option that I see to download the JDK 9 without jigsaw.
> rts integration tests failed when building with jdk 9
> -----------------------------------------------------
>
> Key: WFLY-7579
> URL: https://issues.jboss.org/browse/WFLY-7579
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Amos Feng
> Assignee: Amos Feng
>
> It can not start the wildfly with the exception
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package java.lang.ClassLoader.getPackage(java.lang.String) accessible: module java.base does not "exports private java.lang" to unnamed module @77e4c80f
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7579) rts integration tests failed when building with jdk 9
by Jessica Lundberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-7579?page=com.atlassian.jira.plugin.... ]
Jessica Lundberg commented on WFLY-7579:
----------------------------------------
Hi,
I just installed the latest Wildfly 10.1 final release and the latest windows build for JDK 9 and I am getting this exception. What is the fix? There isn't an option that I see to download the JDK 9 without jigsaw.
> rts integration tests failed when building with jdk 9
> -----------------------------------------------------
>
> Key: WFLY-7579
> URL: https://issues.jboss.org/browse/WFLY-7579
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Amos Feng
> Assignee: Amos Feng
>
> It can not start the wildfly with the exception
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package java.lang.ClassLoader.getPackage(java.lang.String) accessible: module java.base does not "exports private java.lang" to unnamed module @77e4c80f
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8815) WeldApplication should extend ApplicationWrapper
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/WFLY-8815?page=com.atlassian.jira.plugin.... ]
Bauke Scholtz updated WFLY-8815:
--------------------------------
Description:
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper}} having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
was:
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper{{ having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
> WeldApplication should extend ApplicationWrapper
> ------------------------------------------------
>
> Key: WFLY-8815
> URL: https://issues.jboss.org/browse/WFLY-8815
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final with JSF 2.3
> Reporter: Bauke Scholtz
> Assignee: Stuart Douglas
>
> When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
> {code}
> Caused by: java.lang.UnsupportedOperationException
> at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
> at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
> ... 20 more
> {code}
> This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
> This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
> Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper}} having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
> Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8815) WeldApplication should extend ApplicationWrapper
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/WFLY-8815?page=com.atlassian.jira.plugin.... ]
Bauke Scholtz updated WFLY-8815:
--------------------------------
Description:
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper{{ having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
was:
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own `javax.faces.application.ApplicationWrapper` having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
> WeldApplication should extend ApplicationWrapper
> ------------------------------------------------
>
> Key: WFLY-8815
> URL: https://issues.jboss.org/browse/WFLY-8815
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final with JSF 2.3
> Reporter: Bauke Scholtz
> Assignee: Stuart Douglas
>
> When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
> {code}
> Caused by: java.lang.UnsupportedOperationException
> at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
> at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
> ... 20 more
> {code}
> This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
> This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
> Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper{{ having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
> Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8815) WeldApplication should extend ApplicationWrapper
by Bauke Scholtz (JIRA)
Bauke Scholtz created WFLY-8815:
-----------------------------------
Summary: WeldApplication should extend ApplicationWrapper
Key: WFLY-8815
URL: https://issues.jboss.org/browse/WFLY-8815
Project: WildFly
Issue Type: Feature Request
Components: CDI / Weld
Affects Versions: 10.1.0.Final
Environment: WildFly 10.1.0.Final with JSF 2.3
Reporter: Bauke Scholtz
Assignee: Stuart Douglas
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own `javax.faces.application.ApplicationWrapper` having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2849) Disallow addition of Stage.RUNTIME steps for /profile=*/subsystem=* resources
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2849:
----------------------------------------
Summary: Disallow addition of Stage.RUNTIME steps for /profile=*/subsystem=* resources
Key: WFCORE-2849
URL: https://issues.jboss.org/browse/WFCORE-2849
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
For WFCORE-389 we are considering relaxing our unenforced rule against registering runtime-only operations against domain profile resources. The reason for such registrations would be to allow the DC to roll out the op to all servers that are using the profile, not to introduce some notion of runtime services that back the profile on the DC process itself. To help emphasize this point and to guard against mistakes where subsystems register such op but neglect to code them properly to not execute their runtime work on the DC, this issue proposes that the kernel explicitly reject OSH attempts to add Stage.RUNTIME steps that target /profile=* child resource in the /profile=* tree.
This acts as a primary line of defense, with WFCORE-2815 acting as a secondary line.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2434) Elytron, log cause of LoginException during obraining ticket
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2434?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2434.
--------------------------------------
Fix Version/s: 3.0.0.Beta23
Resolution: Duplicate Issue
Covered by ELY-990.
> Elytron, log cause of LoginException during obraining ticket
> ------------------------------------------------------------
>
> Key: WFCORE-2434
> URL: https://issues.jboss.org/browse/WFCORE-2434
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Beta23
>
>
> I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user.
> In log there is
> {code:title=server.log}
> 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login.
> {code}
> But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log.
> Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup.
> Mesage
> {code:java|title=ElytronMessages}
> @Message(id = 1121, value = "Unable to perform initial JAAS login.")
> GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause);
> {code}
> is created in
> {code:java|title=GSSCredentialSecurityFactory.java#L283}
> } catch (LoginException e) {
> throw log.unableToPerformInitialLogin(e);
> }
> {code}
> and logged into log by
> {code:java|title=ServerAuthenticationContext.java#L847}
> } catch (GeneralSecurityException e) {
> // skip this credential
> log.trace(e);
> }
> {code}
> An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-990) Elytron, log cause of LoginException during obraining ticket
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-990?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-990:
------------------------------------
Assignee: Darran Lofthouse (was: David Lloyd)
> Elytron, log cause of LoginException during obraining ticket
> ------------------------------------------------------------
>
> Key: ELY-990
> URL: https://issues.jboss.org/browse/ELY-990
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Server
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta45
>
>
> I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user.
> In log there is
> {code:title=server.log}
> 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login.
> {code}
> But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log.
> Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup.
> Mesage
> {code:java|title=ElytronMessages}
> @Message(id = 1121, value = "Unable to perform initial JAAS login.")
> GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause);
> {code}
> is created in
> {code:java|title=GSSCredentialSecurityFactory.java#L283}
> } catch (LoginException e) {
> throw log.unableToPerformInitialLogin(e);
> }
> {code}
> and logged into log by
> {code:java|title=ServerAuthenticationContext.java#L847}
> } catch (GeneralSecurityException e) {
> // skip this credential
> log.trace(e);
> }
> {code}
> An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-990) Elytron, log cause of LoginException during obraining ticket
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-990?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-990:
---------------------------------
Fix Version/s: 1.1.0.Beta45
> Elytron, log cause of LoginException during obraining ticket
> ------------------------------------------------------------
>
> Key: ELY-990
> URL: https://issues.jboss.org/browse/ELY-990
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Server
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta45
>
>
> I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user.
> In log there is
> {code:title=server.log}
> 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login.
> {code}
> But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log.
> Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup.
> Mesage
> {code:java|title=ElytronMessages}
> @Message(id = 1121, value = "Unable to perform initial JAAS login.")
> GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause);
> {code}
> is created in
> {code:java|title=GSSCredentialSecurityFactory.java#L283}
> } catch (LoginException e) {
> throw log.unableToPerformInitialLogin(e);
> }
> {code}
> and logged into log by
> {code:java|title=ServerAuthenticationContext.java#L847}
> } catch (GeneralSecurityException e) {
> // skip this credential
> log.trace(e);
> }
> {code}
> An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2434) Elytron, log cause of LoginException during obraining ticket
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2434?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2434:
------------------------------------------
I am taking this but just to ensure the log.trace calls use the correct form that will log the Throwable they have access to instead of calling toString() on them - if we have additional exceptions being dropped we can review them as we find them in a new issue.
> Elytron, log cause of LoginException during obraining ticket
> ------------------------------------------------------------
>
> Key: WFCORE-2434
> URL: https://issues.jboss.org/browse/WFCORE-2434
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user.
> In log there is
> {code:title=server.log}
> 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login.
> {code}
> But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log.
> Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup.
> Mesage
> {code:java|title=ElytronMessages}
> @Message(id = 1121, value = "Unable to perform initial JAAS login.")
> GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause);
> {code}
> is created in
> {code:java|title=GSSCredentialSecurityFactory.java#L283}
> } catch (LoginException e) {
> throw log.unableToPerformInitialLogin(e);
> }
> {code}
> and logged into log by
> {code:java|title=ServerAuthenticationContext.java#L847}
> } catch (GeneralSecurityException e) {
> // skip this credential
> log.trace(e);
> }
> {code}
> An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months