[JBoss JIRA] (WFLY-4245) redirect-socket="https" not explicit in default configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4245?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-4245.
-----------------------------
Resolution: Duplicate Issue
This is duplicate of WFLY-3913
> redirect-socket="https" not explicit in default configuration
> -------------------------------------------------------------
>
> Key: WFLY-4245
> URL: https://issues.jboss.org/browse/WFLY-4245
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Linux 64bit
> Reporter: Giuseppe Mazzotta
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
> {noformat}
> --- standalone.xml.orig 2015-01-13 11:33:57.956000250 +0100
> +++ standalone.xml 2015-01-13 11:34:04.456000250 +0100
> @@ -375,11 +375,10 @@
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> - <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> -</server>
> \ No newline at end of file
> +</server>
> {noformat}
> Failure in log is:
> {noformat}
> 11:10:23,601 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {"JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.ws.config"],
> "Services that may be the cause:" => [
> "jboss.binding.https",
> "jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
> ]
> }}
> 11:10:23,602 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> 11:10:23,603 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.ejb3.connector is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"]}
> 11:10:23,663 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.binding.https (missing) dependents: [service jboss.undertow.listener.default]
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service jboss.ejb3.connector]
> 11:10:23,674 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 11:10:23,675 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 11:10:23,675 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.2.0.Final "Tweek" started (with errors) in 3468ms - Started 175 of 231 services (3 services failed or missing dependencies, 81 services are lazy, passive or on-demand)
> {noformat}
> Is this expected behavior?
> *Edit:* due to configuration defaults, see below comments
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4050) data-source:enable is broken
by Pablo Vallaure Larre (JIRA)
[ https://issues.jboss.org/browse/WFLY-4050?page=com.atlassian.jira.plugin.... ]
Pablo Vallaure Larre commented on WFLY-4050:
--------------------------------------------
It is still not working with 8.2 version.
How can I reopen the bug until it is resolved in 8.x branch?
Thanks in advance.
> data-source:enable is broken
> ----------------------------
>
> Key: WFLY-4050
> URL: https://issues.jboss.org/browse/WFLY-4050
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Harald Pehl
> Assignee: Stefano Maestri
> Fix For: 9.0.0.Beta1
>
>
> Enabling a disabled datasource using the operation {{:enable()}} is broken. It remains disabled.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1796) Creating a pooled-connection-factory via the CLI requires confusing syntax
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1796?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1796:
-----------------------------------------------
Ondřej Kalman <okalman(a)redhat.com> changed the Status of [bug 1178229|https://bugzilla.redhat.com/show_bug.cgi?id=1178229] from ON_QA to VERIFIED
> Creating a pooled-connection-factory via the CLI requires confusing syntax
> --------------------------------------------------------------------------
>
> Key: WFLY-1796
> URL: https://issues.jboss.org/browse/WFLY-1796
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.0.0.Alpha3
> Reporter: Justin Bertram
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha4
>
>
> When creating a pooled-connection factory via the CLI the syntax for the "connector" is confusing. Here is a simple example:
> {noformat}
> /subsystem=messaging/hornetq-server=default/pooled-connection-factory=my-pooled-connection-factory/:add(connector={"in-vm" => "xyz"}, entries=["java:/MyPooledCF"])
> {noformat}
> The "connector" wants a list of name-value pairs, but only the name is taken into consideration. This command results in this XML:
> {noformat}
> <pooled-connection-factory name="my-pooled-connection-factory">
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/MyPooledCF"/>
> </entries>
> </pooled-connection-factory>
> {noformat}
> The "xyz" is completely unnecessary.
> I believe this is because {{org.jboss.as.messaging.jms.ConnectionFactoryAttributes.Common#CONNECTOR}} is defined as a {{org.jboss.as.controller.SimpleMapAttributeDefinition}} and it should probably just be a {{org.jboss.as.controller.PrimitiveListAttributeDefinition}} when used in the pooled-connection-factory.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-3723:
--------------------------------------
The PR mentioned above is for Wildfly 9.x/master, but I've also made a [PR for the 8.x branch|https://github.com/wildfly/wildfly/pull/7086].
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Romain Pelisse
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
Romain Pelisse updated WFLY-3723:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/429 (was: https://github.com/wildfly/wildfly/pull/7078)
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Romain Pelisse
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4239) Support Locale.forLanguageTag()
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4239?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4239:
--------------------------------------
The fix uses the unit test and the refactor done for this issue.
> Support Locale.forLanguageTag()
> --------------------------------
>
> Key: WFLY-4239
> URL: https://issues.jboss.org/browse/WFLY-4239
> Project: WildFly
> Issue Type: Feature Request
> Components: Localization
> Affects Versions: 9.0.0.Alpha1
> Environment: JDK 7
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The rules for Locale are different in JDK 6 vs 7, and this getLocale() method was written to conform to the JDK 6 rules. Hence it assumes 2 chars for language, 2 chars for country. Beginning with JDK 7 things are much more complex, and we don't support that. The language can be up to 8 chars, country can be [a-zA-Z]{2} | [0-9]{3}, there's the "script" element, and most importantly, Locale.forLanguageTag().
> It would be nice to at least support Locale.forLanguageTag().
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4239) Support Locale.forLanguageTag()
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4239?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4239:
--------------------------------------
I have a commit for this issue, but I cannot create the PR before WFLY-3723 is accepted.
> Support Locale.forLanguageTag()
> --------------------------------
>
> Key: WFLY-4239
> URL: https://issues.jboss.org/browse/WFLY-4239
> Project: WildFly
> Issue Type: Feature Request
> Components: Localization
> Affects Versions: 9.0.0.Alpha1
> Environment: JDK 7
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The rules for Locale are different in JDK 6 vs 7, and this getLocale() method was written to conform to the JDK 6 rules. Hence it assumes 2 chars for language, 2 chars for country. Beginning with JDK 7 things are much more complex, and we don't support that. The language can be up to 8 chars, country can be [a-zA-Z]{2} | [0-9]{3}, there's the "script" element, and most importantly, Locale.forLanguageTag().
> It would be nice to at least support Locale.forLanguageTag().
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months