October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9508?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9508: --------------------------------- Affects Version/s: 11.0.0.Final > Drop mod_cluster transformers for model versions prior to EAP 6.4 > ----------------------------------------------------------------- > > Key: WFLY-9508 > URL: https://issues.jboss.org/browse/WFLY-9508 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 11.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-3393: -------------------------------------------- Summary: Connection Timeout should take into account time spent in opening the channel Key: WFCORE-3393 URL: https://issues.jboss.org/browse/WFCORE-3393 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Jean-Francois Denise Assignee: Brian Stansberry The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8767) Changing the max-pool-size of the datasource pool should indicate a "reload required" in the CLI output

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8767?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8767: ----------------------------------------------- Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1405954|https://bugzilla.redhat.com/show_bug.cgi?id=1405954] from ASSIGNED to POST > Changing the max-pool-size of the datasource pool should indicate a "reload required" in the CLI output > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-8767 > URL: https://issues.jboss.org/browse/WFLY-8767 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Lin Gao > Assignee: varsha Kamble > Labels: downstream_dependency > Original Estimate: 2 days > Remaining Estimate: 2 days > > In EAP domain mode, when changing the max-pool-size attribute of a datasource via CLI, the response does not indicate that a reload is required. However, reading the statistics of that datasource does not reflect the Available count as per the new max pool value until a restart of the server is performed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1429) Elytron policy is not validated for write-attribute operation

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/ELY-1429?page=com.atlassian.jira.plugin.s... ] Michal Petrov updated ELY-1429: ------------------------------- Description: Editing a policy using {{write-attribute}} simply propagates the changes without any checking, making the service fail on subsequent reload. (was: When creating new Elytron policy required fields are validated immediately after creation and if the validation fails, the policy is not added . However when editing already existing policy and supplying it with invalid values, no validation error is shown. See attachement.) > Elytron policy is not validated for write-attribute operation > ------------------------------------------------------------- > > Key: ELY-1429 > URL: https://issues.jboss.org/browse/ELY-1429 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Michal Petrov > > Editing a policy using {{write-attribute}} simply propagates the changes without any checking, making the service fail on subsequent reload. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1429) Elytron policy is not validated for write-attribute operation

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/ELY-1429?page=com.atlassian.jira.plugin.s... ] Michal Petrov moved JBEAP-13673 to ELY-1429: -------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1429 (was: JBEAP-13673) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) > Elytron policy is not validated for write-attribute operation > ------------------------------------------------------------- > > Key: ELY-1429 > URL: https://issues.jboss.org/browse/ELY-1429 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Michal Petrov > > When creating new Elytron policy required fields are validated immediately after creation and if the validation fails, the policy is not added . However when editing already existing policy and supplying it with invalid values, no validation error is shown. See attachement. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9507) Session X is missing cache entry for attribute Y

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9507?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-13672 to WFLY-9507: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9507 (was: JBEAP-13672) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 11.0.0.Final 10.1.0.Final (was: 7.1.0.DR13) (was: 7.1.0.ER3) (was: 7.1.0.CR3) > Session X is missing cache entry for attribute Y > ------------------------------------------------ > > Key: WFLY-9507 > URL: https://issues.jboss.org/browse/WFLY-9507 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > *Server* logs WARN message during failover scenario *http-granular-shutdown-dist-sync*. > Server log message: > {code} > 21:37:42,027 WARN [org.wildfly.clustering.web.infinispan] (default task-29) WFLYCLWEBINF0011: Session NG5R9o7K2QmlflRasnUQQQbZRHepRHh4uBWVJtVP is missing cache entry for attribute org.jboss.test.clusterbench.common.session.CommonGranularHttpSessionServletSerial > {code} > Message occurs repetitively after new session was created: > {code} > 21:35:42,596 INFO [org.jboss.test.clusterbench.common.session.CommonGranularHttpSessionServlet] (default task-85) New session created: XvRFigJkUfFIrpfuDN4xLfpFArKWNS_b1_RMdH_E > {code} > New cluster view was received more than 3 minutes earlier: > {code} > 21:34:13,648 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-5) ISPN000094: Received new cluster view for channel hibernate: [perf19|3] (4) [perf19, perf20, perf21, perf18] > {code} > Link to server log: > http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9507) Session X is missing cache entry for attribute Y

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9507?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9507: --------------------------------- Affects Version/s: (was: 10.1.0.Final) > Session X is missing cache entry for attribute Y > ------------------------------------------------ > > Key: WFLY-9507 > URL: https://issues.jboss.org/browse/WFLY-9507 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > *Server* logs WARN message during failover scenario *http-granular-shutdown-dist-sync*. > Server log message: > {code} > 21:37:42,027 WARN [org.wildfly.clustering.web.infinispan] (default task-29) WFLYCLWEBINF0011: Session NG5R9o7K2QmlflRasnUQQQbZRHepRHh4uBWVJtVP is missing cache entry for attribute org.jboss.test.clusterbench.common.session.CommonGranularHttpSessionServletSerial > {code} > Message occurs repetitively after new session was created: > {code} > 21:35:42,596 INFO [org.jboss.test.clusterbench.common.session.CommonGranularHttpSessionServlet] (default task-85) New session created: XvRFigJkUfFIrpfuDN4xLfpFArKWNS_b1_RMdH_E > {code} > New cluster view was received more than 3 minutes earlier: > {code} > 21:34:13,648 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-5) ISPN000094: Received new cluster view for channel hibernate: [perf19|3] (4) [perf19, perf20, perf21, perf18] > {code} > Link to server log: > http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9348) Remove unnecessary port="0" from subsystem templates defining a multicast socket binding

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9348?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9348: --------------------------------- Fix Version/s: 12.0.0.Alpha1 > Remove unnecessary port="0" from subsystem templates defining a multicast socket binding > ---------------------------------------------------------------------------------------- > > Key: WFLY-9348 > URL: https://issues.jboss.org/browse/WFLY-9348 > Project: WildFly > Issue Type: Bug > Components: Clustering, mod_cluster > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > The port is optional and defaults to 0; since it's never used in these 2 bindings it should be removed from the default configuration. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2081) Drools Decision Table Templates doesn't work on Spring Boot

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2081?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-2081: ------------------------------------- Assignee: Toni Rikkola (was: Edson Tirelli) > Drools Decision Table Templates doesn't work on Spring Boot > ----------------------------------------------------------- > > Key: DROOLS-2081 > URL: https://issues.jboss.org/browse/DROOLS-2081 > Project: Drools > Issue Type: Bug > Environment: Spring Boot > Reporter: Sebastian Simrodt > Assignee: Toni Rikkola > Priority: Minor > > Spring Boot changes the classpath of files from > "com/example/spreadsheet.xls" > to > "BOOT-INF/classes/com/example/spreadsheet.xls" > Hence you do a string compare of the classpath, templates won't work on a Spring Boot Environment. > I guess the easiest way to fix it, would be to change equals to endsWith in > AbstractKieModule:addResourceToCompiler -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1774) JDK 9 with drools: Drools persistence tests fail on ClassNotFoundException: JAXBException

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1774?page=com.atlassian.jira.plugi... ] Petr Široký updated DROOLS-1774: -------------------------------- Fix Version/s: 7.5.0.Final > JDK 9 with drools: Drools persistence tests fail on ClassNotFoundException: JAXBException > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1774 > URL: https://issues.jboss.org/browse/DROOLS-1774 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Fix For: 7.5.0.Final > > > When tests from drools-persistence-jpa module are run with JDK 9, the tests fail with this stacktrace [1]. It is probably due to xml apis not being part of default Java 9 modules. > To see all failing test in the persistence module, please see this spreadsheet [2]. > [1] https://gist.github.com/baldimir/76bff4a7a5ad3786f865cc7d0eb59efe > [2] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017