[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-2897:
----------------------------------
For versions of JSF other than JSF 2.2.x, accidentally including a JSF implementation in the WAR file won't cause issues and WildFly's default JSF implementation will be the one that's used. It seems that this error only occurs when accidentally including JSF 2.2.x in the WAR file. WildFly's default JSF implementation will still be the one that's used but the error seems to occur when FaceletTaglibConfigProcessor attempts to process the facelets_jsf_core.taglib.xml file from the JSF JAR in the application's WEB-INF/lib directory:
{code}
2014-03-17 17:05:10,140 FINE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Processing facelet-taglibrary document: 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'
2014-03-17 17:05:10,141 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
{code}
The above log message does indicate that a JSF implementation has been included in the WAR file (it references 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'). It doesn't look like there's much that can be done in terms of additional error messages in this case since the JSF subsystem doesn't know that a WAR file includes a JSF implementation unless the WAR_BUNDLES_JSF_IMPL context param is specified.
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
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, 3 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Farah Juma closed WFLY-2897.
----------------------------
Resolution: Won't Fix
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
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, 3 months
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Dustin Minnich (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Dustin Minnich commented on WFLY-3033:
--------------------------------------
I want to be able to configure the Secure and HttpOnly attributes for JSESSIONIDSSO cookie.
> 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, 3 months
[JBoss JIRA] (SECURITY-806) SecurityVaultFactory caching problems
by Kabir Khan (JIRA)
Kabir Khan created SECURITY-806:
-----------------------------------
Summary: SecurityVaultFactory caching problems
Key: SECURITY-806
URL: https://issues.jboss.org/browse/SECURITY-806
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: PicketBox_4_0_21.Beta1
Reporter: Kabir Khan
Assignee: Anil Saldhana
In WildFly we can define the vault at both the 'core' level, and within the security subsystem. The intent is that the user can specify different vaults in the two places, so say for the core one we go with
{code}
<vault/>
{code}
Now, in the security subsystem I want to use some other vault implementation so I do:
{code}
<vault code="my.custom.Vault"/>
{code}
Assuming the core stuff gets loaded first, that will return the 'default' vault, which gets cached, and which will also be returned for the 'custom' one I want in the security subsystem.
--
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, 3 months
[JBoss JIRA] (WFLY-2881) org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-2881:
-------------------------------------
Assignee: Eduardo Martins (was: Tomaz Cerar)
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2881
> URL: https://issues.jboss.org/browse/WFLY-2881
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Frank Langelage
> Assignee: Eduardo Martins
> Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.
--
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, 3 months
[JBoss JIRA] (JBJCA-1156) encrypted datasource security , big performence hit.
by John L (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin... ]
John L reopened JBJCA-1156:
---------------------------
I did use forums and they told me to post this issue.
https://community.jboss.org/thread/237957
I don't think it is a picket code issue either.
The pool should defer getting passwords.
The code PoolBySubject.java and SubjectKey.java
and a few other classes in strategy package seem
to be the area that causes all this to happen.
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
> Key: JBJCA-1156
> URL: https://issues.jboss.org/browse/JBJCA-1156
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.12.Final
> Environment: using jboss 7.1.1 or jboss 7.1.3
> Reporter: John L
> Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
> <datasources>
> <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
> <security>
> <security-domain>some-encrypted-ds</security-domain>
> </security>
> </datasource>
>
> ...
> <security-domain name="some-encrypted-ds" cache-type="default">
> <authentication>
> <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
> <module-option name="username" value="some"/>
> <module-option name="password" value="-......."/>
> </login-module>
> </authentication>
> </security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
> <user-name>xxx</user-name>
> <password>yyy</password>
> </security>
--
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, 3 months
[JBoss JIRA] (JBJCA-1156) encrypted datasource security , big performence hit.
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin... ]
Jesper Pedersen closed JBJCA-1156.
----------------------------------
Resolution: Rejected
Pool your connections, and use a forum post to discuss this. Otherwise talk to the PicketBox people
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
> Key: JBJCA-1156
> URL: https://issues.jboss.org/browse/JBJCA-1156
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.12.Final
> Environment: using jboss 7.1.1 or jboss 7.1.3
> Reporter: John L
> Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
> <datasources>
> <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
> <security>
> <security-domain>some-encrypted-ds</security-domain>
> </security>
> </datasource>
>
> ...
> <security-domain name="some-encrypted-ds" cache-type="default">
> <authentication>
> <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
> <module-option name="username" value="some"/>
> <module-option name="password" value="-......."/>
> </login-module>
> </authentication>
> </security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
> <user-name>xxx</user-name>
> <password>yyy</password>
> </security>
--
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, 3 months
[JBoss JIRA] (JBJCA-1156) encrypted datasource security , big performence hit.
by John L (JIRA)
John L created JBJCA-1156:
-----------------------------
Summary: encrypted datasource security , big performence hit.
Key: JBJCA-1156
URL: https://issues.jboss.org/browse/JBJCA-1156
Project: IronJacamar
Issue Type: Bug
Affects Versions: 1.0.12.Final
Environment: using jboss 7.1.1 or jboss 7.1.3
Reporter: John L
Assignee: Jesper Pedersen
We setup our jboss7.1.3 to use encrypted datasource passwords:
<datasources>
<datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
.....
<security>
<security-domain>some-encrypted-ds</security-domain>
</security>
</datasource>
...
<security-domain name="some-encrypted-ds" cache-type="default">
<authentication>
<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
<module-option name="username" value="some"/>
<module-option name="password" value="-......."/>
</login-module>
</authentication>
</security-domain>
By using this our system took a 30% performance hit.
Some transactions might call getConnection 50 times.
It seems from looking at code that even if a connection already exists in the pool the password is
decrypted on every call to get a connection from the datasource.
Seems like it should only decrypt when a new connection is created to the database.
Moving back to unencrypted passwords solves the performance problem.
That is using:
<security xmlns="urn:jboss:domain:datasources:1.1">
<user-name>xxx</user-name>
<password>yyy</password>
</security>
--
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, 3 months
[JBoss JIRA] (WFLY-2395) RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2395?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-2395:
--------------------------------
Fix Version/s: (was: 8.0.1.Final)
> RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
> ------------------------------------------------------------------------------
>
> Key: WFLY-2395
> URL: https://issues.jboss.org/browse/WFLY-2395
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.
> Files left behind:
> {code}
> [root@build01 logging]# ls -l target/logs/
> total 0
> -rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
> {code}
--
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, 3 months