April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ] Kabir Khan commented on WFLY-10269: ----------------------------------- [~pferraro] [~mposolda] commenting here rather than on the PR as I don't know Marek's GitHub name. Are there any changes to what the user can configure? I think not, but need to make sure. Does this need some extra testing somewhere? > Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder > -------------------------------------------------------------------------------------------- > > Key: WFLY-10269 > URL: https://issues.jboss.org/browse/WFLY-10269 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Marek Posolda > Assignee: Paul Ferraro > > Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this: > Socket binding in standalone-ha.xml > {code} > <outbound-socket-binding name="remote-cache"> > <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/> > </outbound-socket-binding> > {code} > And remote-store something like this: > {code} > <replicated-cache name="work" mode="SYNC"> > <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true"> > </remote-store> > </replicated-cache> > {code} > Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" . > The issue is, that HotRod client won't be able to see this change and will still try to connect to old address. > Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address. > If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3763) Upgrade JBoss MSC 1.4.1.Final

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3763?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-3763: ----------------------------------- Fix Version/s: 5.0.0.Alpha4 > Upgrade JBoss MSC 1.4.1.Final > ----------------------------- > > Key: WFCORE-3763 > URL: https://issues.jboss.org/browse/WFCORE-3763 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Jeff Mesnil > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3763) Upgrade JBoss MSC 1.4.1.Final

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3763?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-3763: ----------------------------------- Component/s: Server > Upgrade JBoss MSC 1.4.1.Final > ----------------------------- > > Key: WFCORE-3763 > URL: https://issues.jboss.org/browse/WFCORE-3763 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Jeff Mesnil > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3763) Upgrade JBoss MSC to 1.4.1.Final

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3763?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-3763: ----------------------------------- Summary: Upgrade JBoss MSC to 1.4.1.Final (was: Upgrade JBoss MSC 1.4.1.Final) > Upgrade JBoss MSC to 1.4.1.Final > -------------------------------- > > Key: WFCORE-3763 > URL: https://issues.jboss.org/browse/WFCORE-3763 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Jeff Mesnil > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-178) Abstract Details Page - Parser

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-178: ------------------------------------ Summary: Abstract Details Page - Parser Key: SWSQE-178 URL: https://issues.jboss.org/browse/SWSQE-178 Project: Kiali QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley For each Details page we have in Kiali UI, we need a separate Object to get the fields and use them in tests assertions. But it requires special Abstract class for generally Details page for React, which will parse and read all values into a Matrix, so each extended class will use that matrix cells for returning field related getter method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-178) Abstract Details Page - Parser

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-178?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated SWSQE-178: --------------------------------- Team: Automation Sprint: Kiali QE Sprint 4 > Abstract Details Page - Parser > ------------------------------ > > Key: SWSQE-178 > URL: https://issues.jboss.org/browse/SWSQE-178 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > > For each Details page we have in Kiali UI, we need a separate Object to get the fields and use them in tests assertions. > But it requires special Abstract class for generally Details page for React, which will parse and read all values into a Matrix, so each extended class will use that matrix cells for returning field related getter method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2487) Make Parallel Rules Build Threshold configurable.

by Duncan Doyle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2487?page=com.atlassian.jira.plugi... ] Duncan Doyle reassigned DROOLS-2487: ------------------------------------ Assignee: Duncan Doyle (was: Mario Fusco) > Make Parallel Rules Build Threshold configurable. > ------------------------------------------------- > > Key: DROOLS-2487 > URL: https://issues.jboss.org/browse/DROOLS-2487 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Duncan Doyle > Assignee: Duncan Doyle > > Currently, the threshold for parallel rules build is fixed and set to 10. It would be nice if we can configure this threshold, and even be able to fully disable parallel builds (for example by setting the value to -1) in case of problems with the parallel builds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2487) Make Parallel Rules Build Threshold configurable.

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-2487: ------------------------------------ Summary: Make Parallel Rules Build Threshold configurable. Key: DROOLS-2487 URL: https://issues.jboss.org/browse/DROOLS-2487 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.7.0.Final Reporter: Duncan Doyle Assignee: Mario Fusco Currently, the threshold for parallel rules build is fixed and set to 10. It would be nice if we can configure this threshold, and even be able to fully disable parallel builds (for example by setting the value to -1) in case of problems with the parallel builds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10285) Upgrade Weld to 3.0.4.Final

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-10285?page=com.atlassian.jira.plugin... ] Martin Kouba reassigned WFLY-10285: ----------------------------------- Assignee: Matej Novotny (was: Martin Kouba) > Upgrade Weld to 3.0.4.Final > --------------------------- > > Key: WFLY-10285 > URL: https://issues.jboss.org/browse/WFLY-10285 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Matej Novotny > Fix For: 13.0.0.Beta1 > > > Also upgrade Weld API to 3.0.SP3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10029) bean-discovery-mode="annotated" is not working like described in the spec

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-10029?page=com.atlassian.jira.plugin... ] Martin Kouba resolved WFLY-10029. --------------------------------- Resolution: Cannot Reproduce Feel free to reopen and provide a reproducer, i.e. a minimal "failing" app so that we could investigate the problem. > bean-discovery-mode="annotated" is not working like described in the spec > ------------------------------------------------------------------------- > > Key: WFLY-10029 > URL: https://issues.jboss.org/browse/WFLY-10029 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 10.1.0.Final > Reporter: Ralph Soika > Assignee: Martin Kouba > Priority: Minor > Labels: beans.xml > > I think we have a problem in Wildfly 10 concerning scanning of CDI Beans. Take a look at the following example: > {code:java} > @Stateless > @LocalBean > public class SomeService { > ... > } > public class SomeClass { > @EJB > SomeService someService; > .... > } > {code} > We have a stateless session ejb an a bean which is not annotated with a scope but is injecting the service EJB. If you use a beans.xml with the tag: > {noformat} > bean-discovery-mode="annotated" > {noformat} > this works in wildfly 10 - the _someService_ is injected into the _someClass_ which is treated as a CDI bean. But this is not a correct behavior as stated in the specification. It says, that in this case only beans with a scope annotation should be treated as CDI which is not the case for SomeClass. Normally, as a developer, you would not complain much about this. So this is only a minor issue. > I recognized this after I tried to run my application on Glassfish/Payara4 which did no longer work until I changed the beans.xml tag to: > {noformat} > bean-discovery-mode="all" > {noformat} > Now it works in both application servers. I think in wildfly we are misinterpreting the attribute "bean-discovery-mode". I think this should be changed in the next versions for EE8. I don't know if this behavior is a known issue and maybe it is still under development. > I know also that with such a change some projects (also my own ones) will break. So maybe a new configuration switch like "strict-cdi-scanning" is helpful. What do you think? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018