March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6446) Upgrade Narayana to 5.2.15.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-6446: ----------------------------------- Summary: Upgrade Narayana to 5.2.15.Final Key: WFLY-6446 URL: https://issues.jboss.org/browse/WFLY-6446 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 10.1.0.Final https://issues.jboss.org/browse/JBTM/fixforversion/12330016/?selectedTab=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1458) add-user.sh scripts change layout of properties files

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1458?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-4008 to WFCORE-1458: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1458 (was: JBEAP-4008) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Scripts (was: Scripts) Target Release: (was: 7.backlog.GA) Affects Version/s: 2.1.0.Final (was: 7.0.0.ER7) > add-user.sh scripts change layout of properties files > ----------------------------------------------------- > > Key: WFCORE-1458 > URL: https://issues.jboss.org/browse/WFCORE-1458 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.1.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > *Description of problem:* > add-user.sh scripts change layout of properties files: > * application-users.properties > * mgmt-users.properties > *How reproducible:* > Always > *Steps to Reproduce:* > # get fresh EAP > # ./add-user.sh -u admin2 -p Admin1** -s > # ./add-user.sh -a -u admin3 -p Admin1** -s > *Actual results:* > These comments are moved to the end of application-users.properties file: > {noformat} > # > #$REALM_NAME=ApplicationRealm$ This line is used by the add-user utility to identify the realm name already used in this file. > # > {noformat} > These comments are moved to the end of mgmt-users.properties file: > {noformat} > # > #$REALM_NAME=ManagementRealm$ This line is used by the add-user utility to identify the realm name already used in this file. > # > {noformat} > *Expected results:* > Comments have same order after execution of add-user.sh > CC: [~ctomc] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated WFLY-1066: -------------------------------------- Priority: Minor (was: Major) > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Sebastian Łaskawiec > Priority: Minor > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the information if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automatically to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1457) Embedded HC started with host-slave.xml uses incorrect hostname

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1457: ---------------------------------------- Summary: Embedded HC started with host-slave.xml uses incorrect hostname Key: WFCORE-1457 URL: https://issues.jboss.org/browse/WFCORE-1457 Project: WildFly Core Issue Type: Bug Reporter: Ken Wills Assignee: Ken Wills Fix For: 3.0.0.Alpha1 EmbeddedHostControllerFactory:282, authCode is being used as the hostname. This is reset if the name is present in the xml config, but since the default -slave.xml has no name, the hostname is displayed as the contents of authCode. We should probably extract the hostname code from HostControllerEnvironment:300 into its own method, and use that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1456) org.jboss.as.cli.scriptsupport.CLI prevents use of embed-server and embed-host-controller

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1456: ---------------------------------------- Summary: org.jboss.as.cli.scriptsupport.CLI prevents use of embed-server and embed-host-controller Key: WFCORE-1456 URL: https://issues.jboss.org/browse/WFCORE-1456 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.1.0.Final Reporter: Brian Stansberry Assignee: Alexey Loubyansky The org.jboss.as.cli.scriptsupport.CLI will throw an exception if the user invokes the cmd method before invoking one of the connect methods. But the connect/disconnect methods are oriented toward remote connections. The result is you can't really use this class with the offline CLI. I'm not sure what the best fix is here. Perhaps new method(s) analogous to connect/disconnect that establish a CommandContext but don't call connectController(). Or perhaps the checkNotConnected() call in the cmd method should just be dropped, and an unconnected command context created. But then the existing connect/disconnect methods would need to be reworked to deal with the fact that an unconnected command context may be present. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1413) Web console doesn't accept passwords with non-ascii characters

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1413?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1413: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1478 (was: https://github.com/wildfly/wildfly-core/pull/1440) > Web console doesn't accept passwords with non-ascii characters > -------------------------------------------------------------- > > Key: WFCORE-1413 > URL: https://issues.jboss.org/browse/WFCORE-1413 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Fix For: 3.0.0.Alpha1 > > > Firefox, Safari and IE use ISO-8859_1 character encoding when generating authentication header. If the credentials contain umlauts (eg. ü), the decoded string on the server is incorrect and authentication fails. > This affects web console authentication when LDAP is used as credentials store. > Web console can solve this by using https://issues.jboss.org/browse/UNDERTOW-595 which adds ability for Undertow to use user-agent patterns to choose correct charset during BASIC authentication. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6413: -------------------------------------- This is fixed in Undertow 1.3.20.Final which was released yesterday. > Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari > -------------------------------------------------------------------------------------------------- > > Key: WFLY-6413 > URL: https://issues.jboss.org/browse/WFLY-6413 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: WildFly 10.0.0.Final > Windows 7 or Mac 10.11.3 > Java 8 > Chrome, Firefox, Safari > Reporter: Jason Holmberg > Assignee: Stuart Douglas > Priority: Blocker > > Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled. > After enabling range headers as described here: > https://developer.jboss.org/message/953058#953058 > I made some range requests via `curl` to see what is being returned: > This is the result of a request to *WildFly* with the Range headers enabled: > {noformat} > $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4 > HTTP/1.1 200 OK > Connection: keep-alive > Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT > X-Powered-By: Undertow/1 > Server: WildFly/10 > Content-Type: video/mp4 > Content-Length: 8200890 > Date: Fri, 18 Mar 2016 16:59:55 GMT > {noformat} > This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*: > {noformat} > $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4 > HTTP/1.1 206 Partial Content > Server: Apache-Coyote/1.1 > Accept-Ranges: bytes > ETag: W/"8200890-1458232627000" > Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT > Content-Range: bytes 0-8200889/8200890 > Content-Type: video/mp4 > Content-Length: 8200890 > Date: Fri, 18 Mar 2016 17:00:08 GMT > {noformat} > I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2028) GMS sometimes ignores view bundling timeout

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2028?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-2028. -------------------------- > GMS sometimes ignores view bundling timeout > ------------------------------------------- > > Key: JGRP-2028 > URL: https://issues.jboss.org/browse/JGRP-2028 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.8 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.9, 4.0 > > > {{GMS.ViewHandler.run()}} has this code: > {code} > wait_time=timeout - (System.nanoTime() - start_time); > if(wait_time > 0 && firstRequest.canBeProcessedTogether(firstRequest)) { // JGRP-1438 > long wait_time_ms=TimeUnit.MILLISECONDS.convert(wait_time, TimeUnit.NANOSECONDS); > queue.waitUntilClosed(wait_time_ms); // misnomer: waits until element has been added or q closed > } > {code} > The problem is {{wait_time_ms}} will be {{0}} if {{0 < wait_time < 1_000_000}}. {{queue.waitUntilClosed(wait_time_ms)}} then calls {{Object.wait(0)}} and blocks forever. > Fortunately, the joiners re-sends the {{JOIN_REQ}} message after {{GMS.join_timeout}} (3s by default), so all that happens is that the view is delayed by 3s. It does cause some random failures in tests that expect the view to form in a precise amount of time, though. > {noformat} > 17:04:53,034 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644 > 17:04:53,034 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN] > 17:04:53,035 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644 > 17:04:53,035 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN] > 17:04:53,060 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN] > 17:04:53,060 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN] > 17:04:53,060 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeF-49399: #1, conn_id=0, first) > 17:04:53,060 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeG-49307: #1, conn_id=0, first) > 17:04:53,061 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#1 > 17:04:53,061 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#1 > 17:04:56,035 WARN (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: JOIN(NodeF-49399) sent to NodeE-37644 timed out (after 3000 ms), on try 1 > 17:04:56,035 WARN (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: JOIN(NodeG-49307) sent to NodeE-37644 timed out (after 3000 ms), on try 1 > 17:04:56,036 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644 > 17:04:56,036 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN] > 17:04:56,036 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644 > 17:04:56,036 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN] > 17:04:56,057 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN] > 17:04:56,057 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN] > 17:04:56,057 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#2 > 17:04:56,057 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#2 > # finally > 17:04:56,057 TRACE (ViewHandler,NodeE-37644:) [GMS] NodeE-37644: joiners=[NodeG-49307, NodeF-49399], suspected=[], leaving=[], new view: [NodeE-37644|1] (3) [NodeE-37644, NodeG-49307, NodeF-49399] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2033) Replace Java serialization with JGroups marshalling

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2033?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2033. ---------------------------- Resolution: Done > Replace Java serialization with JGroups marshalling > --------------------------------------------------- > > Key: JGRP-2033 > URL: https://issues.jboss.org/browse/JGRP-2033 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.9, 4.0 > > > In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}). Analysis of all occurrences of {{Util.objectFromXXX()}} calls. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6441: ------------------------------- Fix Version/s: 10.1.0.Final > naming context is not setup when starting the persistence unit > -------------------------------------------------------------- > > Key: WFLY-6441 > URL: https://issues.jboss.org/browse/WFLY-6441 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.1.0.Final > > > ookup of env-entry throws NameNotFoundException during persistence unit startup > Version-Release number of selected component (if applicable): > How reproducible: > always > Steps to Reproduce: > 1. add env-entry in application.xml > 2. try to lookup during persistent unit startup, e.g. > public class MyType implements UserType { > ... > @Override > public int[] sqlTypes() { > try { > Object ctx = new InitialContext().lookup("java:app/env"); > log.info("java:app/env from JPA = " + ctx); > } catch (Exception e) { > log.error("unable to get java:app/env from JPA", e); > } > return new int[] { Types.VARCHAR }; > } > Actual results: > NameNotFoundException > Expected results: > value of env-entry is available > Additional info: > On 21.03.2016 23:47, Stuart Douglas wrote: > > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace > > > > Stuart -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016