June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-1825: ------------------------------------- [~Rikkola] If you need anything from UX let me know, thanks. > [Guided Decision Table] Ability to change HIT policy in a decision table anytime > -------------------------------------------------------------------------------- > > Key: DROOLS-1825 > URL: https://issues.jboss.org/browse/DROOLS-1825 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Ivo Bek > Assignee: Toni Rikkola > Priority: Critical > Labels: UX, UXTeam > Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy. > Thus, it should be possible to change HIT policy in a decision table anytime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Radovan Netuka reassigned WFCORE-3039: -------------------------------------- Assignee: Radovan Netuka > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Darran Lofthouse > Assignee: Radovan Netuka > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take up to cca 2 minutes to merge with TCP stack

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-9420: -------------------------------------- JGroups acknowledged the problem as JGRP-2281. > Cluster partitions can take up to cca 2 minutes to merge with TCP stack > ----------------------------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing seem to take significant amount of time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9530) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.

by Florin Spătar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9530?page=com.atlassian.jira.plugin.... ] Florin Spătar commented on WFLY-9530: ------------------------------------- Apparently this still happens in WildFly 12, but in a slightly different configuration: I don't use hibernate directly, but through JPA. In `persistence.xml` I have the following: {noformat} <property name="hibernate.cache.infinispan.ejb-embedded-server-4.0-SNAPSHOT.jar#embedded_test.embedded_test.memory.size" value="100000"/> {noformat} And the WARN is the same: {noformat} 16:17:44,696 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started ejb-embedded-server-4.0-SNAPSHOT.jar#embedded_test.embedded_test cache from hibernate container 16:17:44,697 WARN [org.infinispan.hibernate.cache.impl.BaseRegion] (ServerService Thread Pool -- 63) HHH025012: Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional. 16:17:44,706 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started ejb-embedded-server-4.0-SNAPSHOT.jar#embedded_test.embedded_test-pending-puts cache from hibernate container 16:17:44,748 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started ejb-embedded-server-4.0-SNAPSHOT.jar#embedded_test.embedded_test_collections cache from hibernate container 16:17:44,751 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started ejb-embedded-server-4.0-SNAPSHOT.jar#embedded_test.embedded_test_collections-pending-puts cache from hibernate container {noformat} Apparently if you try to configure anything on a cache region, it will inherit a NON_TRANSACTIONAL configuration. *PS*: the issue also reproduces in WildFly 13 {noformat} WARN [org.infinispan.hibernate.cache.v51.impl.BaseRegion] (ServerService Thread Pool -- 72) HHH025012: Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional. {noformat} > Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional. > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-9530 > URL: https://issues.jboss.org/browse/WFLY-9530 > Project: WildFly > Issue Type: Bug > Components: Clustering, JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > When deploying a legacy (non-JPA) Hibernate application with level 2 cache enabled, the following WARN is logged: > {code} > ... WARN [org.hibernate.cache.infinispan.impl.BaseRegion] ... Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-318) IstioOC over latest Kiali

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-318: ------------------------------------ Summary: IstioOC over latest Kiali Key: SWSQE-318 URL: https://issues.jboss.org/browse/SWSQE-318 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-10520: ------------------------------------- [~emartins] FYI, you may want to follow this jira, as it impacts migration of native Hibernate ORM 5.1 applications to ORM 5.3. Currently, we are logging (per application class) warnings every time the Hibernate native application deploys, which will be too much log output for the user to read. These warnings should probably instead be shown by the migration tooling. Have you started a Windup jira for migrating Hibernate native applications to WildFly 14 yet? [~gbadner] IMO, we should move the warnings into external migration tooling. > Add Hibernate ORM 5.3 compatibility transformer > ----------------------------------------------- > > Key: WFLY-10520 > URL: https://issues.jboss.org/browse/WFLY-10520 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Gail Badner > Assignee: Scott Marlow > Fix For: 14.0.0.CR1 > > > A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1. > From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w... > # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode(). > # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode() > # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result. > # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference. > # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead. > # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-10616?page=com.atlassian.jira.plugin... ] R Searls commented on WFLY-10616: --------------------------------- Please provide a simple app to demonstrate the failure. > ContextResolver doesn't work > ---------------------------- > > Key: WFLY-10616 > URL: https://issues.jboss.org/browse/WFLY-10616 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 13.0.0.Final > Reporter: George Trudeau > Assignee: R Searls > Fix For: 14.0.0.CR1 > > > I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final : > {code:java} > @Provider > public class DateResolver implements ContextResolver<ObjectMapper> > { > private final ObjectMapper mapper; > public DateResolver() > { > mapper = new ObjectMapper(); > mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")); > mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); > } > @Override > public ObjectMapper getContext(Class<?> type) { return mapper; } > } > {code} > The {{getContext}} method isn't called on 13.0.0.Final. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-301) Research Differences bewteen Istio 0.8.0 and Istio 0.7.1 to create Smoke Test

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-301?page=com.atlassian.jira.plugin.... ] Matt Mahoney closed SWSQE-301. ------------------------------ Resolution: Done We have now moved to 0.8.0. Closing. > Research Differences bewteen Istio 0.8.0 and Istio 0.7.1 to create Smoke Test > ----------------------------------------------------------------------------- > > Key: SWSQE-301 > URL: https://issues.jboss.org/browse/SWSQE-301 > Project: Kiali QE > Issue Type: QE Task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > From Hayk Email > Guilherme, could you please document the major differences between Istio > 0.8.0 and 0.7.1 in a scope of having influence on Kiali, like creation > of Route Rules, other Istio objects, etc.., and write down these areas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2281: -------------------------------- Looks like {{Event.FIND_MBRS}} can be changed directly rather than creating a new event, as this is only used by {{MERGE3}} and {{TP}}, and both can be changed to become reactive. > MERGE3 blocks unnecessarily in discovery when non-multicast transport is used > ----------------------------------------------------------------------------- > > Key: JGRP-2281 > URL: https://issues.jboss.org/browse/JGRP-2281 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.13 > > > When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to. > Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely no to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP. > h4. Solution: > * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received > * When the function gets invoked, it sends an INFO to the respective member > * This prevents up 1 thread from blocking for N seconds > See \[1\] for details. > \[1\] https://github.com/belaban/JGroups/pull/389 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3077) Operation removing http-connector requires full server reload but does not change the server state accordingly

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3077?page=com.atlassian.jira.plugi... ] Jiri Ondrusek resolved WFCORE-3077. ----------------------------------- Resolution: Cannot Reproduce Issue can not be reproduced because of fix https://issues.jboss.org/browse/WFCORE-3286. This fix causes current issue to be fixed, because error state can not happen. > Operation removing http-connector requires full server reload but does not change the server state accordingly > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3077 > URL: https://issues.jboss.org/browse/WFCORE-3077 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Michal Jurc > Assignee: Jiri Ondrusek > > Removing a {{http-connector}} with {{allow-resource-service-restart}} set to {{true}} will yield the following result: > {code}{ > "operation" => "remove", > "address" => [ > ("subsystem" => "remoting"), > ("http-connector" => "ejb3-tests") > ], > "operation-headers" => {"allow-resource-service-restart" => true} > } > {"outcome" => "success"}{code} > However, the removal of {{http-connector}} will only register after full server reload. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

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 June 2018