August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12356) remoting subsystem's http-connector is missing capability reference

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-12356?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty updated WFLY-12356: --------------------------------------- Comment: was deleted (was: A comment with security level 'Red Hat Employee' was removed.) > remoting subsystem's http-connector is missing capability reference > ------------------------------------------------------------------- > > Key: WFLY-12356 > URL: https://issues.redhat.com/browse/WFLY-12356 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 17.0.1.Final > Reporter: Radoslav Husar > Assignee: Ranabir Chakraborty > Priority: Major > Labels: ux > > http-remoting-connector is missing capability reference to the undertow connector. > {noformat} > [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=connector-ref,value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} > results in a cryptic error > {noformat} > 11:33:01,792 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings, service org.wildfly.ejb.remote] > WFLYCTL0448: 5 additional services are down due to their dependencies being missing or failed > 11:33:15,334 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.ejb.association (new available) > service jboss.ejb.remoting.connector.client-mappings (new available) > service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (no longer required) > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (new available) > service org.wildfly.clustering.cache.registry-factory.ejb.client-mappings (new available) > service org.wildfly.clustering.group.ejb (new available) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ] Jean Francois Denise commented on WFWIP-334: -------------------------------------------- [~mchoma], that could be a first step. User would enable cloud that enables KUBE_PING and apply this kind of script: if (outcome == success) of /subsystem=jgroups/stack=tcp/protocol=kubernetes.KUBE_PING:read-resource /subsystem=jgroups/stack=tcp/protocol=kubernetes.KUBE_PING:remove end-if if (outcome == success) of /subsystem=jgroups/stack=tcp:read-resource /subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING:add(add-index=0) /subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING/property=dns_query:add(value=${env.DNS_PING_SERVICE_NAME}) /subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING/property=async_discovery_use_separate_thread_per_request:add(value=true) end-if The user would name the env variable to set the ping service freely (eg: DNS_PING_SERVICE_NAME). > Bootable JAR - Cloud - Support for dns.DNS_PING > ----------------------------------------------- > > Key: WFWIP-334 > URL: https://issues.redhat.com/browse/WFWIP-334 > Project: WildFly WIP > Issue Type: Feature Request > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled. > KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done). > DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created. > I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element. > The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME > web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service). > [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ] Martin Choma commented on WFWIP-334: ------------------------------------ There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1] If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model? {code} OPENSHIFT_KUBE_PING_* OPENSHIFT_DNS_PING_* JGROUPS_* {code} My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible. [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > Bootable JAR - Cloud - Support for dns.DNS_PING > ----------------------------------------------- > > Key: WFWIP-334 > URL: https://issues.redhat.com/browse/WFWIP-334 > Project: WildFly WIP > Issue Type: Feature Request > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled. > KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done). > DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created. > I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element. > The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME > web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service). > [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13589) WildFly cannot connect to an infinispan-server cluster requiring authentication

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13589?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13589: -------------------------------- Description: Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] See also: [https://infinispan.org/docs/dev/titles/server/server.html#security] To future-proof this, we should also allow informal adhoc properties (like we already do for JGroups protocols and cache stores) - which are processed by the hotrod client before any formal properties from the model. was: Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] See also: [https://infinispan.org/docs/dev/titles/server/server.html#security] > WildFly cannot connect to an infinispan-server cluster requiring authentication > ------------------------------------------------------------------------------- > > Key: WFLY-13589 > URL: https://issues.redhat.com/browse/WFLY-13589 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. > See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] > See also: [https://infinispan.org/docs/dev/titles/server/server.html#security] > To future-proof this, we should also allow informal adhoc properties (like we already do for JGroups protocols and cache stores) - which are processed by the hotrod client before any formal properties from the model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-334: ------------------------------------------ Summary: Bootable JAR - Cloud - Support for dns.DNS_PING Key: WFWIP-334 URL: https://issues.redhat.com/browse/WFWIP-334 Project: WildFly WIP Issue Type: Feature Request Reporter: Jean Francois Denise Assignee: Jean Francois Denise Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled. KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done). DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created. I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element. The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service). [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1204) UI Automations - Overview Enable Disable Auto Injection

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1204?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1204. ----------------------------------- Resolution: Done all PRs merged > UI Automations - Overview Enable Disable Auto Injection > ------------------------------------------------------- > > Key: SWSQE-1204 > URL: https://issues.redhat.com/browse/SWSQE-1204 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://github.com/kiali/kiali-ui/pull/1875 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-333) Bootable JAR - Cloud - Remove https listener and self signed certificate

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-333: ------------------------------------------ Summary: Bootable JAR - Cloud - Remove https listener and self signed certificate Key: WFWIP-333 URL: https://issues.redhat.com/browse/WFWIP-333 Project: WildFly WIP Issue Type: Feature Request Reporter: Jean Francois Denise Assignee: Jean Francois Denise In a cloud context, having https listener and generation of self signed certificate is not recommended. When cloud is enabled, https listener and ssl identity will be removed. This does align with XP 1.0 S2i builder image configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-332) Bootable JAR - Cloud - Remove File handler from logging subsystem

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-332: ------------------------------------------ Summary: Bootable JAR - Cloud - Remove File handler from logging subsystem Key: WFWIP-332 URL: https://issues.redhat.com/browse/WFWIP-332 Project: WildFly WIP Issue Type: Feature Request Reporter: Jean Francois Denise Assignee: Jean Francois Denise For cloud, the logs are directed to the console not to a file, the subsystem must be updated to not configure a file handler. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5602) Review jbpm DMN examples version in codebase

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5602: -------------------------------------- Summary: Review jbpm DMN examples version in codebase Key: DROOLS-5602 URL: https://issues.redhat.com/browse/DROOLS-5602 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Fix For: 7.42.0.Final see Epic descr -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-13559: ----------------------------------------- Assignee: Bartosz Baranowski > Header response has changed and missing fields > ---------------------------------------------- > > Key: WFLY-13559 > URL: https://issues.redhat.com/browse/WFLY-13559 > Project: WildFly > Issue Type: Bug > Affects Versions: 19.0.0.Final, 19.1.0.Final, 20.0.0.Final > Reporter: Alexandru Ciouca > Assignee: Bartosz Baranowski > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war > > > I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? > Response WildFly 18.0.0.final: > {code} > HTTP/2 500 > cache-control: no-store, no-cache, must-revalidate > set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices > access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN > content-type: application/json > content-length: 182 > link: <http://test.com/afs/rest>; rel="profile" > date: Thu, 04 Jun 2020 07:34:10 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > Response WildFly 19.1.0.final: > {code} > HTTP/2 200 > set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices > content-type: application/json > content-length: 182 > date: Thu, 04 Jun 2020 07:27:57 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure > cache-control: private > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. > I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 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 August 2020