March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-680: ------------------------------------------ Fix Version/s: 6.4.0.Final (was: 6.4.0.CR2) > "contains" operator behaves inconsistently when used with Maps > -------------------------------------------------------------- > > Key: DROOLS-680 > URL: https://issues.jboss.org/browse/DROOLS-680 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.4.0.Final > > > In a rule > {code} > Bean( map contains "x" ) // assuming "map" is a property of type Map > {code} > "contains" is arbitrarily interpreted as "containsKey" > The constrain will then fail after being jitted > The documentation explicitly states that "contains" applies to collections -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-670) Generalize inline casts to work with traits

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-670: ------------------------------------------ Fix Version/s: 6.4.0.Final (was: 6.4.0.CR2) > Generalize inline casts to work with traits > ------------------------------------------- > > Key: DROOLS-670 > URL: https://issues.jboss.org/browse/DROOLS-670 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 6.4.0.Final > > > The following constraint > {code} > Person( this#Worker( wage > 1000 ) ) > {code} > is admissible when Worker is a subtype of Person. > It should also be possible to use "#" when Worker is a donned trait. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ] Ladislav Thon commented on WFLY-6123: ------------------------------------- OK, you're right. I still think it should be there :-), but agree with the priority change. > Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode > ----------------------------------------------------------------------------------- > > Key: WFLY-6123 > URL: https://issues.jboss.org/browse/WFLY-6123 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Ladislav Thon > Assignee: Radoslav Husar > Priority: Trivial > > The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}: > bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA. > However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values: > - {{NONE}} > - {{BATCH}} > - {{NON_XA}} > - {{NON_DURABLE_XA}} > - {{FULL_XA}} > I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1447) Patch with wrong upgrade name should not be accepted

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFCORE-1447: ------------------------------------------ Summary: Patch with wrong upgrade name should not be accepted Key: WFCORE-1447 URL: https://issues.jboss.org/browse/WFCORE-1447 Project: WildFly Core Issue Type: Bug Reporter: Bartosz Baranowski -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

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

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6419: ------------------------------------ Summary: Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari Key: WFLY-6419 URL: https://issues.jboss.org/browse/WFLY-6419 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)

10 years, 1 month

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 updated WFLY-6413: --------------------------------- Priority: Blocker (was: Critical) > 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-701) Inconsistent domain server status reports between server-config resource and server resource

by Yeray Santana Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-701?page=com.atlassian.jira.plugin... ] Yeray Santana Borges reassigned WFCORE-701: ------------------------------------------- Assignee: Yeray Santana Borges > Inconsistent domain server status reports between server-config resource and server resource > -------------------------------------------------------------------------------------------- > > Key: WFCORE-701 > URL: https://issues.jboss.org/browse/WFCORE-701 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.CR4, 2.0.0.Alpha2 > Reporter: Brian Stansberry > Assignee: Yeray Santana Borges > Fix For: 3.0.0.Alpha1 > > > When a managed server fails in some way, the server status reporting is inconsistent between the /host=<host>/server-config=<server> resources and the /host=<host>/server=<server> resource. > To reproduce, run domain.sh, find the pid of a server process, and kill -9 <thepid>. Then with the CLI: > {code} > [domain@localhost:9990 /] /host=master/server-config=server-two:read-attribute(name=status) > { > "outcome" => "success", > "result" => "FAILED" > } > [domain@localhost:9990 /] /host=master/server=server-two:read-attribute(name=server-state) > { > "outcome" => "success", > "result" => "STOPPED" > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 Jason Holmberg (JIRA)

[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ] Jason Holmberg commented on WFLY-6413: -------------------------------------- [~swd847] It seems like the change you made might still end up leaving out the Accept-Ranges header since ACCEPT_RANGE_LISTENER is only register when range == null || range.size > 1. If returning a Content-Length header shouldn't you also return Accept-Ranges? > 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: Critical > > 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)

10 years, 1 month

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: -------------------------------------- I have fixed this in Undertow, will be in 1.3.20 > 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: Critical > > 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5773) Remove ASM from Hibernate module as its no longer needed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5773?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-5773: ------------------------------- Description: cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in: {quote} modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml modules/system/layers/base/org/hibernate/4.1/module.xml modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml modules/system/layers/base/org/hibernate/4.3/module.xml modules/system/layers/base/org/hibernate/main/module.xml {quote} was:cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer need it. > Remove ASM from Hibernate module as its no longer needed > -------------------------------------------------------- > > Key: WFLY-5773 > URL: https://issues.jboss.org/browse/WFLY-5773 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Affects Versions: 10.0.0.CR4 > Reporter: Scott Marlow > Assignee: Scott Marlow > > cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in: > {quote} > modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml > modules/system/layers/base/org/hibernate/4.1/module.xml > modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml > modules/system/layers/base/org/hibernate/4.3/module.xml > modules/system/layers/base/org/hibernate/main/module.xml > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016