[JBoss JIRA] (WFLY-4228) Fallback locale should be ROOT, and not Locale.getDefault()
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4228?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4228:
--------------------------------------
This issue was reported while investigating WFLY-3723, as it appeared as potential fix for it.
> Fallback locale should be ROOT, and not Locale.getDefault()
> -----------------------------------------------------------
>
> Key: WFLY-4228
> URL: https://issues.jboss.org/browse/WFLY-4228
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI, ConfigAdmin
> Affects Versions: 9.0.0.Alpha1
> Environment: Any system with default locale set to something diffirent from english
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> While investigating WFLY-3723, I found out that when a bundle for a specified locale can not be found, Wildfly code fallbacks to Locale.getDefault, rather than use the Locale.ROOT. This is a side effect on non-english system, because there is no bundle for "en_US", and root should be used in this case.
> I proposed to fix it by replacing all relevant occurences of Locale.getDefault() by Locale.ROOT.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-4228) Fallback locale should be ROOT, and not Locale.getDefault()
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-4228:
------------------------------------
Summary: Fallback locale should be ROOT, and not Locale.getDefault()
Key: WFLY-4228
URL: https://issues.jboss.org/browse/WFLY-4228
Project: WildFly
Issue Type: Enhancement
Components: CLI, ConfigAdmin
Affects Versions: 9.0.0.Alpha1
Environment: Any system with default locale set to something diffirent from english
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
While investigating WFLY-3723, I found out that when a bundle for a specified locale can not be found, Wildfly code fallbacks to Locale.getDefault, rather than use the Locale.ROOT. This is a side effect on non-english system, because there is no bundle for "en_US", and root should be used in this case.
I proposed to fix it by replacing all relevant occurences of Locale.getDefault() by Locale.ROOT.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Bertrand Donnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Bertrand Donnet commented on WFLY-3718:
---------------------------------------
Yes, would be great to have a backport or patch for 8.2.0
Thanks for the fix :)
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-1366:
------------------------------------
Assignee: Tomasz Adamski
> @DataSourceDefinition incorrectly requires other properties than name and class-name
> ------------------------------------------------------------------------------------
>
> Key: WFLY-1366
> URL: https://issues.jboss.org/browse/WFLY-1366
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Affects Versions: 8.0.0.Alpha1
> Reporter: arjan tijms
> Assignee: Tomasz Adamski
> Labels: spec, validation
>
> When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance:
> {code:xml}
> <data-source>
> <name>java:app/myDS</name>
> <class-name>com.example.MyDS</class-name>
> </data-source>
> {code}
> With such configuration, the following exception is thrown:
> {noformat}
> Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl
> at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385)
> at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116)
> at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76)
> at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373)
> at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116)
> {noformat}
> At the point where the exception is thrown, the code checks if there are any properties at all:
> {code}
> if (this.xaDataSourceProperty.isEmpty())
> throw new ValidateException(
> bundle.requiredElementMissing(
> Tag.XA_DATASOURCE_PROPERTY.getLocalName(),
> this.getClass().getCanonicalName()));
> {code}
> I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified.
> A workaround is to subclass the data source class and provide a dummy property, e.g.
> {code:xml}
> <data-source>
> <name>java:app/myDS</name>
> <class-name>com.example.MySubDS</class-name>
> <property>
> <name>dummy</name>
> <value>dummy</value>
> </property>
> </data-source>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months