[JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers as modules with no driver
by Jeff Zhang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.... ]
Jeff Zhang resolved WFLY-2655.
------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> Show warning for JDBC drivers as modules with no driver
> -------------------------------------------------------
>
> Key: WFLY-2655
> URL: https://issues.jboss.org/browse/WFLY-2655
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: James Livingston
> Assignee: Jeff Zhang
> Fix For: 8.0.1.Final
>
>
> If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers.
> When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot the problem.
--
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 commented on WFLY-2897:
----------------------------------
I've created this post in the JSF forum to help anyone else who happens to come across this issue:
https://community.jboss.org/thread/238150
> 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] (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 commented on JBJCA-1156:
-------------------------------
A complete pool definition we are using:
<datasource jta="false" jndi-name="java:/SomeDS"
pool-name="SomeDS" enabled="true" use-java-context="true" xmlns="urn:jboss:domain:datasources:1.1">
<connection-url>jdbc:jtds:sqlserver://localhost:1433/Some
</connection-url>
<driver>jtds</driver>
<new-connection-sql>select 1</new-connection-sql>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<pool>
<min-pool-size>1</min-pool-size>
<max-pool-size>100</max-pool-size>
<prefill>false</prefill>
<use-strict-min>false</use-strict-min>
</pool>
<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="34959585858585"/>
</login-module>
</authentication>
</security-domain>
Every connection retrieved from datasource via jndi lookup from pool
decrypts the password using blowfish even though the connection is already connected to db.
The blowfish decrypts adds up to a large performance hit.
> 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-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on WFLY-2897:
------------------------------------------
Hmm... couldn't the JSF subsystem tell that the path is coming from a deployment and not from a core module? Just a thought. I never like to suggest using path logic to fix issues like this, but it's just a thought that came to mind. It should be possible to use ClassLoader logic; however, that might be a little bit safer I suppose. This is just an unfortunate problem, but perhaps the easiest solution is to make sure that google can find good information about this error :)
> 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 Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on WFLY-2897:
------------------------------------------
Hmm... couldn't the JSF subsystem tell that the path is coming from a
deployment and not from a core module? Just a thought. I never like to
suggest using path logic to fix issues like this, but it's just a thought
that came to mind. It should be possible to use ClassLoader logic; however,
that might be a little bit safer I suppose. This is just an unfortunate
problem, but perhaps the easiest solution is to make sure that google can
find good information about this error :)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
> 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-922) <vault> does not have module option
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-922?page=com.atlassian.jira.plugin.s... ]
Kabir Khan resolved WFLY-922.
-----------------------------
Resolution: Duplicate Issue
Replaced by WFLY-3118
> <vault> does not have module option
> -----------------------------------
>
> Key: WFLY-922
> URL: https://issues.jboss.org/browse/WFLY-922
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: James Livingston
> Assignee: Peter Skopek
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
--
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